doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc3657.txt b/doc/rfc/rfc3657.txt
new file mode 100644
index 0000000..a5a0680
--- /dev/null
+++ b/doc/rfc/rfc3657.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          S. Moriai
+Request for Comments: 3657              Sony Computer Entertainment Inc.
+Category: Standards Track                                        A. Kato
+                                                NTT Software Corporation
+                                                            January 2004
+
+
+               Use of the Camellia Encryption Algorithm
+                 in Cryptographic Message Syntax (CMS)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+Abstract
+
+   This document specifies the conventions for using the Camellia
+   encryption algorithm for encryption with the Cryptographic Message
+   Syntax (CMS).
+
+1.  Introduction
+
+   This document specifies the conventions for using the Camellia
+   encryption algorithm [CamelliaSpec] for encryption with the
+   Cryptographic Message Syntax (CMS) [CMS].  The relevant object
+   identifiers (OIDs) and processing steps are provided so that Camellia
+   may be used in the CMS specification (RFC 3369, RFC 3370) for content
+   and key encryption.
+
+   Note:  This work was done when the first author worked for NTT.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 1]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+1.1.  Camellia
+
+   Camellia was jointly developed by Nippon Telegraph and Telephone
+   Corporation and Mitsubishi Electric Corporation in 2000.  Camellia
+   specifies the 128-bit block size and 128-, 192-, and 256-bit key
+   sizes, the same interface as the Advanced Encryption Standard (AES).
+   Camellia is characterized by its suitability for both software and
+   hardware implementations as well as its high level of security.  From
+   a practical viewpoint, it is designed to enable flexibility in
+   software and hardware implementations on 32-bit processors widely
+   used over the Internet and many applications, 8-bit processors used
+   in smart cards, cryptographic hardware, embedded systems, and so on
+   [CamelliaTech].  Moreover, its key setup time is excellent, and its
+   key agility is superior to that of AES.
+
+   Camellia has been scrutinized by the wide cryptographic community
+   during several projects for evaluating crypto algorithms.  In
+   particular, Camellia was selected as a recommended cryptographic
+   primitive by the EU NESSIE (New European Schemes for Signatures,
+   Integrity and Encryption) project [NESSIE] and also included in the
+   list of cryptographic techniques for Japanese e-Government systems
+   which were selected by the Japan CRYPTREC (Cryptography Research and
+   Evaluation Committees) [CRYPTREC].
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT",
+   "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase,
+   as shown) are to be interpreted as described in [RFC2119].
+
+2.  Object Identifiers for Content and Key Encryption
+
+   This section provides the OIDs and processing information necessary
+   for Camellia to be used for content and key encryption in CMS.
+
+   Camellia is added to the set of optional symmetric encryption
+   algorithms in CMS by providing two classes of unique object
+   identifiers (OIDs).  One OID class defines the content encryption
+   algorithms and the other defines the key encryption algorithms.  Thus
+   a CMS agent can apply Camellia either for content or key encryption
+   by selecting the corresponding object identifier, supplying the
+   required parameter, and starting the program code.
+
+
+
+
+
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 2]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+2.1.  OIDs for Content Encryption
+
+   Camellia is added to the set of symmetric content encryption
+   algorithms defined in [CMSALG].  The Camellia content-encryption
+   algorithm, in Cipher Block Chaining (CBC) mode, for the three
+   different key sizes are identified by the following object
+   identifiers:
+
+      id-camellia128-cbc OBJECT IDENTIFIER ::=
+          { iso(1) member-body(2) 392 200011 61 security(1)
+            algorithm(1) symmetric-encryption-algorithm(1)
+            camellia128-cbc(2) }
+
+      id-camellia192-cbc OBJECT IDENTIFIER ::=
+          { iso(1) member-body(2) 392 200011 61 security(1)
+            algorithm(1) symmetric-encryption-algorithm(1)
+            camellia192-cbc(3) }
+
+      id-camellia256-cbc OBJECT IDENTIFIER ::=
+          { iso(1) member-body(2) 392 200011 61 security(1)
+            algorithm(1) symmetric-encryption-algorithm(1)
+            camellia256-cbc(4) }
+
+   The AlgorithmIdentifier parameters field MUST be present, and the
+   parameters field MUST contain the value of IV:
+
+      CamelliaCBCParameter ::= CamelliaIV  --  Initialization Vector
+
+      CamelliaIV ::= OCTET STRING (SIZE(16))
+
+   The plain text is padded according to Section 6.3 of [CMS].
+
+2.2.  OIDs for Key Encryption
+
+   The key-wrap/unwrap procedures used to encrypt/decrypt a Camellia
+   content-encryption key (CEK) with a Camellia key-encryption key (KEK)
+   are specified in Section 3.  Generation and distribution of key-
+   encryption keys are beyond the scope of this document.
+
+   The Camellia key-encryption algorithm has the following object
+   identifier:
+
+     id-camellia128-wrap OBJECT IDENTIFIER ::=
+                 { iso(1) member-body(2) 392 200011 61 security(1)
+                   algorithm(1) key-wrap-algorithm(3)
+                   camellia128-wrap(2) }
+
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 3]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+     id-camellia192-wrap OBJECT IDENTIFIER ::=
+                 { iso(1) member-body(2) 392 200011 61 security(1)
+                    algorithm(1) key-wrap-algorithm(3)
+                    camellia192-wrap(3) }
+
+     id-camellia256-wrap OBJECT IDENTIFIER ::=
+                 { iso(1) member-body(2) 392 200011 61 security(1)
+                   algorithm(1) key-wrap-algorithm(3)
+                   camellia256-wrap(4) }
+
+   In all cases the parameters field of AlgorithmIdentifier MUST be
+   ABSENT, because the key wrapping procedure itself defines how and
+   when to use an IV.  The OID gives the KEK key size, but does not make
+   any statements as to the size of the wrapped Camellia CEK.
+   Implementations MAY use different KEK and CEK sizes.  Implementations
+   MUST support the CEK and the KEK having the same length.  If
+   different lengths are supported, the KEK MUST be of equal or greater
+   length than the CEK.
+
+3.  Key Wrap Algorithm
+
+   Camellia key wrapping and unwrapping are done in conformance with the
+   AES key wrap algorithm [RFC3394], because Camellia and AES have the
+   same block and key sizes, i.e., the block size of 128 bits and key
+   sizes of 128, 192, and 256 bits.
+
+3.1.  Notation and Definitions
+
+   The following notation is used in the description of the key wrapping
+   algorithms:
+
+   Camellia(K, W)
+                 Encrypt W using the Camellia codebook with key K
+   Camellia-1(K, W)
+                   Decrypt W using the Camellia codebook with key K
+   MSB(j, W)     Return the most significant j bits of W
+   LSB(j, W)     Return the least significant j bits of W
+   B1 ^ B2       The bitwise exclusive or (XOR) of B1 and B2
+   B1 | B2       Concatenate B1 and B2
+   K             The key-encryption key K
+   n             The number of 64-bit key data blocks
+   s             The number of steps in the wrapping process, s = 6n
+   P[i]          The ith plaintext key data block
+   C[i]          The ith ciphertext data block
+   A             The 64-bit integrity check register
+   R[i]          An array of 64-bit registers where
+                     i = 0, 1, 2, ..., n
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 4]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+   A[t], R[t][i] The contents of registers A and R[i] after encryption
+                     step t.
+   IV            The 64-bit initial value used during the wrapping
+                     process.
+
+   In the key wrap algorithm, the concatenation function will be used to
+   concatenate 64-bit quantities to form the 128-bit input to the
+   Camellia codebook.  The extraction functions will be used to split
+   the 128-bit output from the Camellia codebook into two 64-bit
+   quantities.
+
+3.2.  Camellia Key Wrap
+
+   Key wrapping with Camellia is identical to Section 2.2.1 of [RFC3394]
+   with "AES" replaced by "Camellia".
+
+   The inputs to the key wrapping process are the KEK and the plaintext
+   to be wrapped.  The plaintext consists of n 64-bit blocks, containing
+   the key data being wrapped.  The key wrapping process is described
+   below.
+
+   Inputs:      Plaintext, n 64-bit values {P[1], P[2], ..., P[n]},
+                and Key, K (the KEK).
+   Outputs:     Ciphertext, (n+1) 64-bit values {C[0], C[1], ...,
+                C[n]}.
+
+   1) Initialize variables.
+
+       Set A[0] to an initial value (see Section 3.4)
+       For i = 1 to n
+            R[0][i] = P[i]
+
+   2) Calculate intermediate values.
+
+       For t = 1 to s, where s = 6n
+           A[t] = MSB(64, Camellia(K, A[t-1] | R[t-1][1])) ^ t
+           For i = 1 to n-1
+               R[t][i] = R[t-1][i+1]
+           R[t][n] = LSB(64, Camellia(K, A[t-1] | R[t-1][1]))
+
+   3) Output the results.
+
+       Set C[0] = A[t]
+       For i = 1 to n
+           C[i] = R[t][i]
+
+
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 5]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+   An alternative description of the key wrap algorithm involves
+   indexing rather than shifting.  This approach allows one to calculate
+   the wrapped key in place, avoiding the rotation in the previous
+   description.  This produces identical results and is more easily
+   implemented in software.
+
+   Inputs:  Plaintext, n 64-bit values {P[1], P[2], ..., P[n]},
+            and Key, K (the KEK).
+   Outputs: Ciphertext, (n+1) 64-bit values {C[0], C[1], ...,
+            C[n]}.
+
+   1) Initialize variables.
+
+       Set A = IV, an initial value (see Section 3.4)
+       For i = 1 to n
+           R[i] = P[i]
+
+   2) Calculate intermediate values.
+
+       For j = 0 to 5
+           For i=1 to n
+               B = Camellia(K, A | R[i])
+               A = MSB(64, B) ^ t where t = (n*j)+i
+               R[i] = LSB(64, B)
+
+   3) Output the results.
+
+       Set C[0] = A
+       For i = 1 to n
+           C[i] = R[i]
+
+3.3.  Camellia Key Unwrap
+
+   Key unwrapping with Camellia is identical to Section 2.2.2 of
+   [RFC3394], with "AES" replaced by "Camellia".
+
+   The inputs to the unwrap process are the KEK and (n+1) 64-bit blocks
+   of ciphertext consisting of previously wrapped key.  It returns n
+   blocks of plaintext consisting of the n 64-bit blocks of the
+   decrypted key data.
+
+   Inputs:  Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
+            and Key, K (the KEK).
+   Outputs: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}.
+
+
+
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 6]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+   1) Initialize variables.
+
+       Set A[s] = C[0] where s = 6n
+       For i = 1 to n
+           R[s][i] = C[i]
+
+   2) Calculate the intermediate values.
+
+       For t = s to 1
+           A[t-1] = MSB(64, Camellia-1(K, ((A[t] ^ t) | R[t][n]))
+           R[t-1][1] = LSB(64, Camellia-1(K, ((A[t]^t) | R[t][n]))
+           For i = 2 to n
+               R[t-1][i] = R[t][i-1]
+
+   3) Output the results.
+
+       If A[0] is an appropriate initial value (see Section 3.4),
+       Then
+           For i = 1 to n
+               P[i] = R[0][i]
+       Else
+           Return an error
+
+   The unwrap algorithm can also be specified as an index based
+   operation, allowing the calculations to be carried out in place.
+   Again, this produces the same results as the register shifting
+   approach.
+
+   Inputs:  Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]},
+            and Key, K (the KEK).
+   Outputs: Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}.
+
+   1) Initialize variables.
+
+       Set A = C[0]
+       For i = 1 to n
+           R[i] = C[i]
+
+   2) Calculate intermediate values.
+
+       For j = 5 to 0
+           For i = n to 1
+               B = Camellia-1(K, (A ^ t) | R[i]) where t = n*j+i
+               A = MSB(64, B)
+               R[i] = LSB(64, B)
+
+
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 7]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+   3) Output results.
+
+   If A is an appropriate initial value (see Section 3.4),
+   Then
+       For i = 1 to n
+           P[i] = R[i]
+   Else
+       Return an error
+
+3.4.  Key Data Integrity -- the Initial Value
+
+   The initial value (IV) refers to the value assigned to A[0] in the
+   first step of the wrapping process.  This value is used to obtain an
+   integrity check on the key data.  In the final step of the unwrapping
+   process, the recovered value of A[0] is compared to the expected
+   value of A[0].  If there is a match, the key is accepted as valid,
+   and the unwrapping algorithm returns it.  If there is not a match,
+   then the key is rejected, and the unwrapping algorithm returns an
+   error.
+
+   The exact properties achieved by this integrity check depend on the
+   definition of the initial value.  Different applications may call for
+   somewhat different properties; for example, whether there is need to
+   determine the integrity of key data throughout its lifecycle or just
+   when it is unwrapped.  This specification defines a default initial
+   value that supports integrity of the key data during the period it is
+   wrapped (in Section 3.4.1).  Provision is also made to support
+   alternative initial values (in Section 3.4.2).
+
+3.4.1.  Default Initial Value
+
+   The default initial value (IV) is defined to be the hexadecimal
+   constant:
+
+      A[0] = IV = A6A6A6A6A6A6A6A6
+
+   The use of a constant as the IV supports a strong integrity check on
+   the key data during the period that it is wrapped.  If unwrapping
+   produces A[0] = A6A6A6A6A6A6A6A6, then the chance that the key data
+   is corrupt is 2^-64.  If unwrapping produces A[0] any other value,
+   then the unwrap must return an error and not return any key data.
+
+3.4.2.  Alternative Initial Values
+
+   When the key wrap is used as part of a larger key management protocol
+   or system, the desired scope for data integrity may be more than just
+   the key data or the desired duration for more than just the period
+   that it is wrapped.  Also, if the key data is not just a Camellia
+
+
+
+Moriai & Kato               Standards Track                     [Page 8]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+   key, it may not always be a multiple of 64 bits.  Alternative
+   definitions of the initial value can be used to address such
+   problems.  According to [RFC3394], NIST will define alternative
+   initial values in future key management publications as needed.  In
+   order to accommodate a set of alternatives that may evolve over time,
+   key wrap implementations that are not application-specific will
+   require some flexibility in the way that the initial value is set and
+   tested.
+
+4.  SMIMECapabilities Attribute
+
+   An S/MIME client SHOULD announce the set of cryptographic functions
+   it supports by using the S/MIME capabilities attribute.  This
+   attribute provides a partial list of OIDs of cryptographic functions
+   and MUST be signed by the client.  The functions' OIDs SHOULD be
+   logically separated in functional categories and MUST be ordered with
+   respect to their preference.
+
+   RFC 2633 [RFC2633], Section 2.5.2 defines the SMIMECapabilities
+   signed attribute (defined as a SEQUENCE of SMIMECapability SEQUENCEs)
+   to be used to specify a partial list of algorithms that the software
+   announcing the SMIMECapabilities can support.
+
+   If an S/MIME client is required to support symmetric encryption with
+   Camellia, the capabilities attribute MUST contain the Camellia OID
+   specified above in the category of symmetric algorithms.  The
+   parameter associated with this OID MUST be CamelliaSMimeCapability.
+
+      CamelliaSMimeCapabilty ::= NULL
+
+   The SMIMECapability SEQUENCE representing Camellia MUST be DER-
+   encoded as the following hexadecimal strings:
+
+      Key Size                   Capability
+       128          30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 02 05 00
+       196          30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 03 05 00
+       256          30 0f 06 0b 2a 83 08 8c 9a 4b 3d 01 01 01 04 05 00
+
+   When a sending agent creates an encrypted message, it has to decide
+   which type of encryption algorithm to use.  In general the decision
+   process involves information obtained from the capabilities lists
+   included in messages received from the recipient, as well as other
+   information such as private agreements, user preferences, legal
+   restrictions, and so on.  If users require Camellia for symmetric
+   encryption, it MUST be supported by the S/MIME clients on both the
+   sending and receiving side, and it MUST be set in the user
+   preferences.
+
+
+
+
+Moriai & Kato               Standards Track                     [Page 9]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+5.  Security Considerations
+
+   This document specifies the use of Camellia for encrypting the
+   content of a CMS message and for encrypting the symmetric key used to
+   encrypt the content of a CMS message, and the other mechanisms are
+   the same as the existing ones.  Therefore, the security
+   considerations described in the CMS specifications [CMS][CMSALG] and
+   the AES key wrap algorithm [RFC3394] can be applied to this document.
+   No security problem has been found on Camellia [CRYPTREC][NESSIE].
+
+6.  Intellectual Property Statement
+
+   The IETF takes no position regarding the validity or scope of any
+   intellectual property or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; neither does it represent that it
+   has made any effort to identify any such rights.  Information on the
+   IETF's procedures with respect to rights in standards-track and
+   standards-related documentation can be found in BCP-11.  Copies of
+   claims of rights made available for publication and any assurances of
+   licenses to be made available, or the result of an attempt made to
+   obtain a general license or permission for the use of such
+   proprietary rights by implementors or users of this specification can
+   be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   The IETF has been notified of intellectual property rights claimed in
+   regard to some or all of the specification contained in this
+   document.  For more information consult the online list of claimed
+   rights.
+
+7.  References
+
+7.1.  Normative References
+
+   [CamelliaSpec] Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai,
+                  S., Nakajima, J., and Tokita, T., "Specification of
+                  Camellia - a 128-bit Block Cipher".
+                  http://info.isl.ntt.co.jp/camellia/
+
+   [CMS]          Housley, R., "Cryptographic Message Syntax", RFC 3369,
+                  August 2002.
+
+
+
+Moriai & Kato               Standards Track                    [Page 10]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+   [CMSALG]       Housley, R., "Cryptographic Message Syntax (CMS)
+                  Algorithms", RFC 3370, August 2002.
+
+   [RFC2633]      Ramsdell, B., Editor, "S/MIME Version 3 Message
+                  Specification", RFC 2633, June 1999.
+
+   [RFC3565]      Schaad, J., "Use of the Advanced Encryption Standard
+                  (AES) Encryption Algorithm in Cryptographic Message
+                  Syntax (CMS)", RFC 3565, July 2003.
+
+   [RFC3394]      Schaad, J. and R. Housley, "Advanced Encryption
+                  Standard (AES) Key Wrap Algorithm", RFC 3394,
+                  September 2002.
+
+7.2.  Informative References
+
+   [DES]          National Institute of Standards and Technology.  FIPS
+                  Pub 46: Data Encryption Standard.  15 January 1977.
+
+   [CamelliaTech] Aoki, K., Ichikawa, T., Kanda, M., Matsui, M., Moriai,
+                  S., Nakajima, J., and Tokita, T., "Camellia: A 128-Bit
+                  Block Cipher Suitable for Multiple Platforms - Design
+                  and Analysis -", In Selected Areas in Cryptography,
+                  7th Annual International Workshop, SAC 2000, August
+                  2000, Proceedings, Lecture Notes in Computer Science
+                  2012, pp.39-56, Springer-Verlag, 2001.
+
+   [CRYPTREC]     Information-technology Promotion Agency (IPA), Japan,
+                  CRYPTREC.
+                  http://www.ipa.go.jp/security/enc/CRYPTREC/index-
+                  e.html
+
+   [NESSIE]       New European Schemes for Signatures, Integrity and
+                  Encryption (NESSIE) project.
+                  http://www.cryptonessie.org
+
+   [RFC2119]      Bradner, S., "Key words for use in RFCs to Indicate
+                  Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriai & Kato               Standards Track                    [Page 11]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+Appendix A  ASN.1 Module
+
+CamelliaEncryptionAlgorithmInCMS
+    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
+      pkcs9(9) smime(16) modules(0) id-mod-cms-camellia(23) }
+
+DEFINITIONS IMPLICIT TAGS ::=
+BEGIN
+
+-- Camellia using CBC-chaining mode for key sizes of 128, 192, 256
+
+id-camellia128-cbc OBJECT IDENTIFIER ::=
+    { iso(1) member-body(2) 392 200011 61 security(1)
+      algorithm(1) symmetric-encryption-algorithm(1)
+      camellia128-cbc(2) }
+
+id-camellia192-cbc OBJECT IDENTIFIER ::=
+   { iso(1) member-body(2) 392 200011 61 security(1)
+     algorithm(1) symmetric-encryption-algorithm(1)
+     camellia192-cbc(3) }
+
+id-camellia256-cbc OBJECT IDENTIFIER ::=
+   { iso(1) member-body(2) 392 200011 61 security(1)
+     algorithm(1) symmetric-encryption-algorithm(1)
+     camellia256-cbc(4) }
+
+-- Camellia-IV is the parameter for all the above object identifiers.
+
+Camellia-IV ::= OCTET STRING (SIZE(16))
+
+-- Camellia S/MIME Capabilty parameter for all the above object
+-- identifiers.
+
+CamelliaSMimeCapability ::= NULL
+
+-- Camellia Key Wrap Algorithm identifiers - Parameter is absent.
+
+id-camellia128-wrap OBJECT IDENTIFIER ::=
+    { iso(1) member-body(2) 392 200011 61 security(1)
+      algorithm(1) key-wrap-algorithm(3)
+      camellia128-wrap(2) }
+
+id-camellia192-wrap OBJECT IDENTIFIER ::=
+    { iso(1) member-body(2) 392 200011 61 security(1)
+      algorithm(1) key-wrap-algorithm(3)
+      camellia192-wrap(3) }
+
+
+
+
+
+Moriai & Kato               Standards Track                    [Page 12]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+id-camellia256-wrap OBJECT IDENTIFIER ::=
+    { iso(1) member-body(2) 392 200011 61 security(1)
+      algorithm(1) key-wrap-algorithm(3)
+      camellia256-wrap(4) }
+
+END
+
+Authors' Addresses
+
+   Shiho Moriai
+   Sony Computer Entertainment Inc.
+   Phone: +81-3-6438-7523
+   Fax:   +81-3-6438-8629
+   EMail: camellia@isl.ntt.co.jp (Camellia team)
+          shiho@rd.scei.sony.co.jp (Shiho Moriai)
+
+
+   Akihiro Kato
+   NTT Software Corporation
+   Phone: +81-45-212-7934
+   Fax:   +81-45-212-9800
+   EMail: akato@po.ntts.co.jp
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriai & Kato               Standards Track                    [Page 13]
+
+RFC 3657          Use of the Camellia Algorithm in CMS      January 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assignees.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Moriai & Kato               Standards Track                    [Page 14]
+