[要約] RFC 3657は、暗号化メッセージ構文（CMS）でのCamellia暗号アルゴリズムの使用に関する規格です。このRFCの目的は、CMSでのCamelliaの使用を定義し、セキュアなメッセージの暗号化と復号化を可能にすることです。
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)
暗号メッセージ構文（CMS）でのCamellia暗号化アルゴリズムの使用
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright（C）The Internet Society（2004）。全著作権所有。
Abstract
概要
This document specifies the conventions for using the Camellia encryption algorithm for encryption with the Cryptographic Message Syntax (CMS).
このドキュメントでは、暗号メッセージ構文（CMS）での暗号化にCamellia暗号化アルゴリズムを使用するための規則を指定します。
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.
このドキュメントでは、暗号メッセージ構文（CMS）[CMS]での暗号化にCamellia暗号化アルゴリズム[CamelliaSpec]を使用するための規則を指定します。コンテンツとキーの暗号化のためにCMS仕様（RFC 3369、RFC 3370）でCamelliaを使用できるように、関連するオブジェクト識別子（OID）と処理手順が提供されています。
Note: This work was done when the first author worked for NTT.
注：この作業は、最初の作成者がNTTに勤務したときに行われました。
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は2000年に日本電信電話株式会社と三菱電機株式会社によって共同開発されました。Camelliaは、128ビットのブロックサイズと128ビット、192ビット、および256ビットのキーサイズを指定し、Advanced Encryption Standard（AES）と同じインターフェイスです。 。 Camelliaの特徴は、ソフトウェアとハードウェアの両方の実装への適合性と、高レベルのセキュリティです。実用的な観点から見ると、インターネットや多くのアプリケーションで広く使用されている32ビットプロセッサ、スマートカード、暗号化ハードウェア、組み込みシステムなどで使用されている8ビットプロセッサでソフトウェアとハードウェアを柔軟に実装できるように設計されています[CamelliaTech ]。さらに、そのキーのセットアップ時間は優れており、そのキーの俊敏性は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].
Camelliaは、暗号アルゴリズムを評価するためのいくつかのプロジェクトの期間中に、幅広い暗号コミュニティによって精査されてきました。特に、カメリアは、EU NESSIE（署名、整合性、および暗号化のための新しいヨーロッパのスキーム）プロジェクト[NESSIE]によって推奨される暗号プリミティブとして選択され、また、日本CRYPTREC（暗号研究評価委員会）[CRYPTREC]。
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].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、大文字で表記されていますが、 [RFC2119]で説明されているように解釈されます。
This section provides the OIDs and processing information necessary for Camellia to be used for content and key encryption in CMS.
このセクションでは、CMSでコンテンツとキーの暗号化にCamelliaを使用するために必要なOIDと処理情報を提供します。
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.
Camelliaは、CMSのオプションの対称暗号化アルゴリズムのセットに追加され、一意のオブジェクト識別子（OID）の2つのクラスを提供します。 1つのOIDクラスはコンテンツ暗号化アルゴリズムを定義し、もう1つはキー暗号化アルゴリズムを定義します。したがって、CMSエージェントは、対応するオブジェクト識別子を選択し、必要なパラメーターを指定して、プログラムコードを開始することにより、コンテンツまたはキーの暗号化にCamelliaを適用できます。
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:
Camelliaは、[CMSALG]で定義されている対称コンテンツ暗号化アルゴリズムのセットに追加されます。暗号ブロックチェーン（CBC）モードの3つの異なる鍵サイズに対するCamelliaコンテンツ暗号化アルゴリズムは、次のオブジェクト識別子によって識別されます。
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:
AlgorithmIdentifierパラメータフィールドが存在しなければならず、パラメータフィールドにはIVの値が含まれている必要があります。
CamelliaCBCParameter ::= CamelliaIV -- Initialization Vector
CamelliaIV ::= OCTET STRING (SIZE(16))
The plain text is padded according to Section 6.3 of [CMS].
プレーンテキストは、[CMS]のセクション6.3に従ってパディングされます。
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.
Camelliaコンテンツ暗号化キー（CEK）をCamelliaキー暗号化キー（KEK）で暗号化/復号化するために使用されるキーラップ/アンラップ手順は、セクション3で指定されています。キー暗号化キーの生成と配布は、このドキュメント。
The Camellia key-encryption algorithm has the following object identifier:
Camellia鍵暗号化アルゴリズムには、次のオブジェクト識別子があります。
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) }
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.
すべてのケースで、AlgorithmIdentifierのパラメーターフィールドはABSENTである必要があります。これは、キーラッピングプロシージャ自体が、IVをいつどのように使用するかを定義するためです。 OIDはKEKキーのサイズを示しますが、ラップされたCamellia CEKのサイズについては何も述べていません。実装は、異なるKEKおよびCEKサイズを使用する場合があります。実装は、同じ長さのCEKとKEKをサポートする必要があります。異なる長さがサポートされている場合、KEKはCEKと同じかそれより長くなければなりません。
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.
CamelliaとAESは同じブロックとキーのサイズ、つまり128ビットのブロックサイズと128、192、256ビットのキーサイズを持つため、CamelliaのキーのラップとアンラップはAESキーラップアルゴリズム[RFC3394]に準拠して行われます。 。
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
Camellia（K、W）キーKでCamelliaコードブックを使用してWを暗号化しますCamellia-1（K、W）キーKでCamelliaコードブックを使用してWを復号化しますMSB（j、W）Wの最上位jビットを返しますLSB（j、 W）Wの最下位jビットを返すB1 ^ B2 B1とB2のビット単位の排他的論理和（XOR）B1 | B2連結B1およびB2 Kキー暗号化キーK n 64ビットキーデータブロックの数sラッピングプロセスのステップ数s = 6n P [i] i番目の平文キーデータブロックC [i] i番目の暗号文データブロックA 64ビットの整合性チェックレジスタR [i] 64ビットレジスタの配列i = 0、1、2、...、n
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.
A [t]、R [t] [i]暗号化ステップt後のレジスタAおよびR [i]の内容。 IVラッピングプロセス中に使用される64ビットの初期値。
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.
キーラップアルゴリズムでは、連結関数を使用して64ビット量を連結し、Camelliaコードブックへの128ビット入力を形成します。抽出関数は、Camelliaコードブックからの128ビット出力を2つの64ビット量に分割するために使用されます。
Key wrapping with Camellia is identical to Section 2.2.1 of [RFC3394] with "AES" replaced by "Camellia".
Camelliaでの鍵のラッピングは[RFC3394]のセクション2.2.1と同じで、「AES」が「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.
キーラッピングプロセスへの入力は、KEKとラップされるプレーンテキストです。平文はn個の64ビットブロックで構成され、ラップされるキーデータが含まれています。鍵のラッピングプロセスを以下に説明します。
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]}.
入力：平文、n 64ビット値{P [1]、P [2]、...、P [n]}、およびキーK（KEK）。出力：暗号文、（n + 1）64ビット値{C [0]、C [1]、...、C [n]}。
1) Initialize variables.
1）変数を初期化します。
Set A[0] to an initial value (see Section 3.4) For i = 1 to n R[0][i] = P[i]
A [0]を初期値に設定します（セクション3.4を参照）i = 1からnまでR [0] [i] = P [i]
2) Calculate intermediate values.
2）中間値を計算します。
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.
3）結果を出力します。
Set C[0] = A[t] For i = 1 to n C[i] = R[t][i]
C [0] = A [t]をi = 1からnに設定C [i] = R [t] [i]
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]}.
入力：平文、n 64ビット値{P [1]、P [2]、...、P [n]}、およびキーK（KEK）。出力：暗号文、（n + 1）64ビット値{C [0]、C [1]、...、C [n]}。
1) Initialize variables.
1）変数を初期化します。
Set A = IV, an initial value (see Section 3.4) For i = 1 to n R[i] = P[i]
初期値としてA = IVを設定します（セクション3.4を参照）i = 1からnまでR [i] = P [i]
2) Calculate intermediate values.
2）中間値を計算します。
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.
3）結果を出力します。
Set C[0] = A For i = 1 to n C[i] = R[i]
C [0] = Aをi = 1からnに設定C [i] = R [i]
Key unwrapping with Camellia is identical to Section 2.2.2 of [RFC3394], with "AES" replaced by "Camellia".
Camelliaでの鍵のアンラップは[RFC3394]のセクション2.2.2と同じで、「AES」が「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.
アンラッププロセスへの入力は、以前にラップされたキーで構成される暗号テキストのKEKおよび（n + 1）64ビットブロックです。復号化された鍵データのn個の64ビットブロックで構成されるプレーンテキストのn個のブロックを返します。
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]}.
入力：暗号文、（n + 1）64ビット値{C [0]、C [1]、...、C [n]}、およびキーK（KEK）。出力：平文、n 64ビット値{P [1]、P [2]、...、P [n]}。
1) Initialize variables.
1）変数を初期化します。
Set A[s] = C[0] where s = 6n For i = 1 to n R[s][i] = C[i]
A [s] = C [0]を設定します。ここで、s = 6n i = 1〜nの場合R [s] [i] = C [i]
2) Calculate the intermediate values.
2）中間値を計算します。
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.
3）結果を出力します。
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
A [0]が適切な初期値である場合（セクション3.4を参照）、i = 1からnまでの場合P [i] = R [0] [i]そうでなければエラーを返します。
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]}.
入力：暗号文、（n + 1）64ビット値{C [0]、C [1]、...、C [n]}、およびキーK（KEK）。出力：平文、n 64ビット値{P [0]、P [1]、...、P [n]}。
1) Initialize variables.
1）変数を初期化します。
Set A = C[0] For i = 1 to n R[i] = C[i]
セットA = C [0] i = 1からnまでR [i] = C [i]
2) Calculate intermediate values.
2）中間値を計算します。
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)
3) Output results.
3）結果を出力します。
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
Aが適切な初期値である場合（セクション3.4を参照）、i = 1からnまでP [i] = R [i]そうでなければエラーを返します
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.
初期値（IV）は、ラッピングプロセスの最初のステップでA [0]に割り当てられた値を指します。この値は、キーデータの整合性チェックを取得するために使用されます。アンラッピングプロセスの最後のステップでは、A [0]の回復された値がA [0]の期待値と比較されます。一致する場合、キーは有効として受け入れられ、アンラップアルゴリズムがそれを返します。一致しない場合、キーは拒否され、アンラップアルゴリズムはエラーを返します。
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）の間にキーデータの整合性をサポートするデフォルトの初期値を定義します。代替の初期値をサポートするためのプロビジョニングも行われています（3.4.2項）。
The default initial value (IV) is defined to be the hexadecimal constant:
デフォルトの初期値（IV）は、16進定数として定義されています。
A[0] = IV = A6A6A6A6A6A6A6A6
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.
IVとして定数を使用すると、ラップされている期間中、キーデータの強力な整合性チェックがサポートされます。アンラップによりA [0] = A6A6A6A6A6A6A6A6が生成される場合、キーデータが破損している可能性は2 ^ -64です。アンラップがA [0]の他の値を生成する場合、アンラップはエラーを返し、キーデータを返さない必要があります。
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 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.
鍵のラップがより大きな鍵管理プロトコルまたはシステムの一部として使用される場合、データ整合性の望ましい範囲は、鍵のデータだけではなく、ラップされる期間だけではなく、望ましい期間でもあります。また、鍵データが単なるCamellia鍵ではない場合、必ずしも64ビットの倍数であるとは限りません。初期値の代替定義を使用して、このような問題に対処できます。 [RFC3394]によれば、NISTは必要に応じて将来の鍵管理出版物で代替の初期値を定義する予定です。時間の経過とともに変化する可能性のある一連の選択肢に対応するために、アプリケーション固有ではないキーラップ実装では、初期値の設定とテストの方法にある程度の柔軟性が必要になります。
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.
S / MIMEクライアントは、S / MIME機能属性を使用して、サポートする暗号化機能のセットを通知する必要があります（SHOULD）。この属性は、暗号化機能のOIDの部分的なリストを提供し、クライアントによって署名される必要があります。関数のOIDは論理的に機能カテゴリに分けられるべきであり（SHOULD）、それらの優先順位に従って順序付けされなければなりません（MUST）。
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.
RFC 2633 [RFC2633]のセクション2.5.2は、SMIMECapabilitiesを通知するソフトウェアがサポートできるアルゴリズムの部分的なリストを指定するために使用されるSMIMECapabilities署名済み属性（SMIMECapability SEQUENCEのSEQUENCEとして定義）を定義しています。
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.
S / MIMEクライアントがCamelliaでの対称暗号化をサポートする必要がある場合、capabilities属性には、対称アルゴリズムのカテゴリで上記で指定されたCamellia OIDが含まれている必要があります。このOIDに関連付けられているパラメーターはCamelliaSMimeCapabilityである必要があります。
CamelliaSMimeCapabilty ::= NULL
The SMIMECapability SEQUENCE representing Camellia MUST be DER-encoded as the following hexadecimal strings:
Camelliaを表すSMIMECapability SEQUENCEは、次の16進文字列としてDERエンコードする必要があります。
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
キーサイズ機能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.
送信エージェントは、暗号化されたメッセージを作成するときに、使用する暗号化アルゴリズムのタイプを決定する必要があります。一般に、決定プロセスには、受信者から受信したメッセージに含まれる機能リストから取得した情報、および私的な合意、ユーザー設定、法的制限などの他の情報が含まれます。ユーザーが対称暗号化にCamelliaを必要とする場合は、送信側と受信側の両方のS / MIMEクライアントでサポートされている必要があり、ユーザー設定で設定する必要があります。
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].
このドキュメントでは、CMSメッセージのコンテンツを暗号化するため、およびCMSメッセージのコンテンツを暗号化するために使用される対称キーを暗号化するためのCamelliaの使用を指定します。その他のメカニズムは既存のものと同じです。したがって、CMS仕様[CMS] [CMSALG]およびAESキーラップアルゴリズム[RFC3394]で説明されているセキュリティの考慮事項をこのドキュメントに適用できます。 Camellia [CRYPTREC] [NESSIE]でセキュリティ上の問題は見つかりませんでした。
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.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるまたは適用されない範囲に関して、いかなる立場も取らない。利用可能。また、そのような権利を特定するために何らかの努力をしたことも表していません。標準化過程および標準化関連文書の権利に関するIETFの手順に関する情報は、BCP-11にあります。公開のために利用可能にされた権利の主張および利用可能にされるライセンスの保証のコピー、またはこの仕様の実装者またはユーザーによる一般的なライセンスまたはそのような所有権の使用の許可を得ようとした試みの結果を入手できます。 IETF事務局から。
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.
IETFは、この規格を実践するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、利害関係者に呼びかけます。 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.
IETFは、このドキュメントに含まれている仕様の一部またはすべてに関して主張されている知的財産権について通知を受けています。詳細については、主張されている権利のオンラインリストを参照してください。
[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.
[CMS] Housley、R。、「Cryptographic Message Syntax」、RFC 3369、2002年8月。
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
[CMSALG] Housley、R。、「Cryptographic Message Syntax（CMS）Algorithms」、RFC 3370、2002年8月。
[RFC2633] Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633, June 1999.
[RFC2633] Ramsdell、B。、編集者、「S / MIMEバージョン3メッセージ仕様」、RFC 2633、1999年6月。
[RFC3565] Schaad, J., "Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)", RFC 3565, July 2003.
[RFC3565] Schaad、J。、「暗号化メッセージ構文（CMS）でのAdvanced Encryption Standard（AES）暗号化アルゴリズムの使用」、RFC 3565、2003年7月。
[RFC3394] Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, September 2002.
[RFC3394] Schaad、J。およびR. Housley、「Advanced Encryption Standard（AES）Key Wrap Algorithm」、RFC 3394、2002年9月。
[DES] National Institute of Standards and Technology. FIPS Pub 46: Data Encryption Standard. 15 January 1977.
[DES]米国国立標準技術研究所。 FIPS Pub 46：Data Encryption Standard。 1977年1月15日。
[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.
[CamelliaTech]青木健一、市川武、神田真、松井真、森井真、中島純、時田剛、「Camellia：128ビットブロック暗号複数のプラットフォーム-設計と分析-」、暗号化の選択された領域、第7回年次国際ワークショップ、SAC 2000、2000年8月、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
[NESSIE]署名、整合性、暗号化のための新しいヨーロッパ方式（NESSIE）プロジェクト。 http://www.cryptonessie.org
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
Appendix A ASN.1 Module
付録A ASN.1モジュール
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
-CBCチェーンモードを使用した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は、上記のすべてのオブジェクト識別子のパラメーターです。
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.
-Camellia Key Wrap Algorithm識別子-パラメーターがありません。
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) }
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)
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
あきひろ かと んっｔ そｆとぁれ こｒぽらちおん Ｐほね： ＋８１ー４５ー２１２ー７９３４ ふぁｘ： ＋８１ー４５ー２１２ー９８００ えまいｌ： あかと＠ぽ。んっｔｓ。こ。ｊｐ
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
Copyright（C）The Internet Society（2004）。全著作権所有。
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.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。