RFC4312 日本語訳

Network Working Group                                            A. Kato
Request for Comments: 4312                      NTT Software Corporation
Category: Standards Track                                      S. Moriai
                                        Sony Computer Entertainment Inc.
                                                                M. Kanda
                              Nippon Telegraph and Telephone Corporation
                                                           December 2005

コメントを求めるワーキンググループA.加藤の要求をネットワークでつないでください: 4312年のNTTソフトウェア株式会社カテゴリ: 標準化過程S.Moriai株式会社ソニー・コンピュータエンタテインメントM.神田日本電信電話会社2005年12月

          The Camellia Cipher Algorithm and Its Use With IPsec

ツバキ暗号アルゴリズムとIPsecとのその使用

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.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

Abstract

要約

   This document describes the use of the Camellia block cipher
   algorithm in Cipher Block Chaining Mode, with an explicit
   Initialization Vector, as a confidentiality mechanism within the
   context of the IPsec Encapsulating Security Payload (ESP).

このドキュメントはCipher Block Chaining ModeにおけるCamelliaブロック暗号アルゴリズムの使用について説明します、明白な初期設定Vectorと共に、IPsec Encapsulating Security有効搭載量(超能力)の文脈の中の秘密性メカニズムとして。

1.  Introduction

1. 序論

   This document describes the use of the Camellia block cipher
   algorithm in Cipher Block Chaining Mode, with an explicit
   Initialization Vector, as a confidentiality mechanism within the
   context of the IPsec Encapsulating Security Payload (ESP).

このドキュメントはCipher Block Chaining ModeにおけるCamelliaブロック暗号アルゴリズムの使用について説明します、明白な初期設定Vectorと共に、IPsec Encapsulating Security有効搭載量(超能力)の文脈の中の秘密性メカニズムとして。

   Camellia was selected as a recommended cryptographic primitive by the
   EU NESSIE (New European Schemes for Signatures, Integrity and
   Encryption) project [NESSIE] and was included in the list of
   cryptographic techniques for Japanese e-Government systems that was
   selected by the Japan CRYPTREC (Cryptography Research, Evaluation
   Committees) [CRYPTREC].  Camellia has been submitted to several other
   standardization bodies, such as ISO (ISO/IEC 18033) and the IETF
   S/MIME Mail Security Working Group [Camellia-CMS].

ツバキは、お勧めの暗号のEUネッシーによる原始(Signatures、Integrity、およびEncryptionのための新しいヨーロッパのSchemes)のプロジェクト[ネッシー]として選択されて、日本CRYPTREC(暗号Research、Evaluation Committees)[CRYPTREC]によって選択された日本の電子政府システムのための暗号のテクニックのリストに含まれていました。 他のいくつかの標準化本体にツバキを提出しました、ISO(ISO/IEC18033)やIETF S/MIMEメールSecurity作業部会[ツバキ-CMS]のように。

Kato, et al.                Standards Track                     [Page 1]

RFC 4312                    Camellia Cipher                December 2005

加藤、他 規格はツバキ暗号2005年12月にRFC4312を追跡します[1ページ]。

   Camellia supports 128-bit block size and 128-, 192-, and 256-bit key
   lengths, i.e., the same interface specifications as the Advanced
   Encryption Standard (AES) [AES].

ツバキサポート128ビットのブロック・サイズ、および128、192、およびすなわち、256ビットのキー長、同じくらいはエー・イー・エス(AES)[AES]として仕様を連結します。

   Camellia is a symmetric cipher with a Feistel structure.  Camillia
   was developed jointly by NTT and Mitsubishi Electric Corporation in
   2000.  It was designed to withstand all known cryptanalytic attacks,
   and it has been scrutinized by worldwide cryptographic experts.
   Camellia is suitable for implementation in software and hardware,
   offering encryption speed in software and hardware implementations
   that is comparable to AES.

ツバキはFeistel構造がある左右対称の暗号です。 Camilliaは2000年にNTTと三菱電機によって共同で開発されました。 それはすべての知られているcryptanalytic攻撃に耐えるように設計されました、そして、世界的な暗号の専門家によって精査されました。 ツバキはソフトウェアとハードウェアの実装に適しています、ソフトウェアとハードウェア実装におけるAESに匹敵する暗号化速度を提供して。

   The Camellia homepage [Camellia-Web] contains a wealth of information
   about camellia, including detailed specification, security analysis,
   performance figures, reference implementation, test vectors, and
   intellectual property information.

Camelliaホームページ[ツバキウェブ]はツバキの豊富な情報を含んでいます、仕様詳細、証券分析、性能の数字、参照実装、テストベクトル、および知的所有権情報を含んでいて。

   The remainder of this document specifies the use of Camellia within
   the context of IPsec ESP.  For further information on how the various
   pieces of ESP fit together to provide security services, please refer
   to [ARCH], [ESP], and [ROAD].

このドキュメントの残りはIPsecの文脈の中でCamelliaの使用を指定します。超能力。 超能力の様々な断片がセキュリティー・サービスを提供するためにどう一緒に合うかに関する詳細について、[ARCH]、[超能力]、および[ROAD]を参照してください。

1.1.  Specification of Requirements

1.1. 要件の仕様

   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" that
   appear in this document are to be interpreted as described in
   [RFC-2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「」 「5月」、「任意」は「推薦され」て、現れる中[RFC-2119]で説明されるように本書では解釈しないべきであることですか?

2.  The Camellia Cipher Algorithm

2. ツバキ暗号アルゴリズム

   All symmetric block cipher algorithms share common characteristics
   and variables, including mode, key size, weak keys, block size, and
   rounds.  The following sections contain descriptions of the relevant
   characteristics of Camellia.

すべての左右対称のブロック暗号アルゴリズムがモード、主要なサイズ、弱いキー、ブロック・サイズ、およびラウンドを含む共通する特徴と変数を共有します。 以下のセクションはCamelliaの関連特性の記述を含みます。

   The algorithm specification and object identifiers are described in
   [Camellia-Desc].

アルゴリズム仕様とオブジェクト識別子は[ツバキ-Desc]で説明されます。

2.1.  Mode

2.1. モード

   NIST has defined five modes of operation for AES and other FIPS-
   approved ciphers [SP800-38a]: CBC (Cipher Block Chaining), ECB
   (Electronic CodeBook), CFB (Cipher FeedBack), OFB (Output FeedBack),
   and CTR (Counter).  The CBC mode is well defined and well understood
   for symmetric ciphers, and it is currently required for all other ESP
   ciphers.  This document specifies the use of the Camellia cipher in
   CBC mode within ESP.  This mode requires an Initialization Vector

NISTはAESのために5つの運転モードを定義しました、そして、他のFIPSは暗号[SP800-38a]を承認しました: CBC(暗号ブロック連鎖)、ECB(電子符号表)、CFB(暗号フィードバック)、OFB(出力フィードバック)、およびCTR(カウンタ)。 CBCモードは、よく定義されて、左右対称の暗号のためによく理解されています、そして、それが現在、他のすべての超能力暗号に必要です。 このドキュメントは超能力の中でCBCモードにおけるCamellia暗号の使用を指定します。 このモードは初期設定Vectorを必要とします。

Kato, et al.                Standards Track                     [Page 2]

RFC 4312                    Camellia Cipher                December 2005

加藤、他 規格はツバキ暗号2005年12月にRFC4312を追跡します[2ページ]。

   (IV) size that is the same as the block size.  Use of a randomly
   generated IV prevents generation of identical cipher text from
   packets that have identical data spanning the first block of the
   cipher algorithm's block size.

ブロック・サイズと同じ(IV)サイズ。 手当たりしだいに発生しているIVの使用によって、同じデータを持っているパケットからの同じ暗号テキストの世代は暗号アルゴリズムのブロック・サイズの最初のブロックを測ることができません。

   The CBC IV is XOR'd with the first plaintext block before it is
   encrypted.  Then, for successive blocks, the previous cipher text
   block is XOR'd with the current plain text before it is encrypted.
   More information on CBC mode can be obtained in [SP800-38a,
   CRYPTO-S].

CBC IVによるXORがそれの前の最初の平文ブロックで暗号化されたということです。 そして、連続したブロックに関して、前の暗号テキストブロックはXORがそれの前の現在のプレーンテキストで暗号化されたということです。 [SP800-38a、CRYPTO-S]でCBCモードに関する詳しい情報を得ることができます。

2.2.  Key Size

2.2. 主要なサイズ

   Camellia supports three key sizes: 128 bits, 192 bits, and 256 bits.
   The default key size is 128 bits, and all implementations MUST
   support this key size.  Implementations MAY also support key sizes of
   192 bits and 256 bits.

ツバキは3つの主要なサイズをサポートします: 128ビット、192ビット、および256ビット。 デフォルトキーサイズは128ビットです、そして、すべての実装がこの主要なサイズをサポートしなければなりません。 また、実装は192ビットと256ビットの主要なサイズをサポートするかもしれません。

   Camellia uses a different number of rounds for each of the defined
   key sizes.  When a 128-bit key is used, implementations MUST use 18
   rounds.  When a 192-bit key is used, implementations MUST use 24
   rounds.  When a 256-bit key is used, implementations MUST use 24
   rounds.

ツバキはそれぞれの定義された主要なサイズに異なった数のラウンドを使用します。 128ビットのキーが使用されているとき、実装は18ラウンドを使用しなければなりません。 192ビットのキーが使用されているとき、実装は24ラウンドを使用しなければなりません。 256ビットのキーが使用されているとき、実装は24ラウンドを使用しなければなりません。

2.3.  Weak Keys

2.3. 弱いキー

   At the time of writing this document, there are no known weak keys
   for Camellia.

このドキュメントを書く時点で、Camelliaに、弱いキーは知られていません。

2.4.  Block Size and Padding

2.4. ブロック・サイズと詰め物

   Camellia uses a block size of sixteen octets (128 bits).

ツバキは16の八重奏(128ビット)のブロック・サイズを使用します。

   Padding is required by the algorithms to maintain a 16-octet
   (128-bit) block size.  Padding MUST be added, as specified in [ESP],
   such that the data to be encrypted (which includes the ESP Pad Length
   and Next Header fields) is a multiple of 16 octets.

詰め物は、16八重奏(128ビット)のブロック・サイズを維持するためにアルゴリズムによって必要とされます。 詰め物を加えなければなりません、[超能力]で指定されるように、暗号化されるべきデータ(超能力Pad LengthとNext Header分野を含んでいる)が16の八重奏の倍数であるように。

   Because of the algorithm-specific padding requirement, no additional
   padding is required to ensure that the ciphertext terminates on a
   4-octet boundary.  That is, maintaining a 16-octet block size
   guarantees that the ESP Pad Length and Next Header fields will be
   right-aligned within a 4-octet word).  Additional padding MAY be
   included, as specified in [ESP], as long as the 16-octet block size
   is maintained.

アルゴリズム特有の詰め物要件のために、どんな追加詰め物も、暗号文が4八重奏の境界で終わるのを保証するのに必要ではありません。 すなわち、16八重奏のブロック・サイズが、超能力Pad LengthとNext Header分野が4八重奏の単語の中でまさしく並べるようになるのを保証すると主張します) 16八重奏のブロック・サイズが維持される限り、追加詰め物は[超能力]で指定されるように含まれるかもしれません。

Kato, et al.                Standards Track                     [Page 3]

RFC 4312                    Camellia Cipher                December 2005

加藤、他 規格はツバキ暗号2005年12月にRFC4312を追跡します[3ページ]。

2.5.  Performance

2.5. パフォーマンス

   Performance figures of Camellia are available at [Camellia-Web].
   This web site also includes performance comparison with the AES
   cipher and other AES finalists.  The NESSIE project [NESSIE] has
   reported performance of Optimized Implementations independently.

Camelliaのパフォーマンス図形は[ツバキウェブ]で利用可能です。 また、このウェブサイトはAES暗号と他のAES決勝戦出場者との性能比較を含んでいます。 ネッシープロジェクト[ネッシー]は独自にOptimized Implementationsの性能を報告しました。

3.  ESP Payload

3. 超能力有効搭載量

   The ESP payload is made up of the IV followed by raw cipher-text.
   Thus, the payload field, as defined in [ESP], is broken down
   according to the following diagram:

超能力ペイロードは生の暗号文があとに続いたIVで作られます。 したがって、以下のダイヤグラムによると、[超能力]で定義されるペイロード分野は砕けています:

   +---------------+---------------+---------------+---------------+
   |                                                               |
   +               Initialization Vector (16 octets)               +
   |                                                               |
   +---------------+---------------+---------------+---------------+
   |                                                               |
   ~ Encrypted Payload (variable length, a multiple of 16 octets)  ~
   |                                                               |
   +---------------------------------------------------------------+

+---------------+---------------+---------------+---------------+ | | + 初期設定Vector(16の八重奏)+| | +---------------+---------------+---------------+---------------+ | | ~ 暗号化された有効搭載量(可変長、16の八重奏の倍数)~| | +---------------------------------------------------------------+

   The IV field MUST be the same size as the block size of the cipher
   algorithm being used.  The IV MUST be chosen at random, and MUST be
   unpredictable.

IV分野は使用される暗号アルゴリズムのブロック・サイズと同じサイズであるに違いありません。 IVは無作為に選ばなければならなくて、予測できるはずがありません。

   Including the IV in each datagram ensures that each received datagram
   can be decrypted, even when some datagrams are dropped or re-ordered
   in transit.

各データグラムにIVを含んでいるのは、それぞれの容認されたデータグラムを解読することができるのを確実にします、いくつかのデータグラムを下げるか、またはトランジットで再注文さえするとき。

   To avoid CBC encryption of very similar plaintext blocks in different
   packets, implementations MUST NOT use a counter or other low
   Hamming-distance source for IVs.

異なったパケットの非常に同様の平文ブロックのCBC暗号化を避けるために、実装はIVsにカウンタか他の低いハミング距離ソースを使用してはいけません。

3.1.  ESP Algorithmic Interactions

3.1. 超能力のアルゴリズムの相互作用

   Currently, there are no known issues regarding interactions between
   the Camellia and other aspects of ESP, such as the use of certain
   authentication schemes.

現在、超能力のCamelliaと他の局面との相互作用に関する問題は知られていません、ある認証体系の使用などのように。

3.2.  Keying Material

3.2. 材料を合わせます。

   The minimum number of bits sent from the key exchange protocol to the
   ESP algorithm must be greater than or equal to the key size.  The
   cipher's encryption and decryption key is taken from the first 128,
   192, or 256 bits of the keying material.

主要な交換プロトコルから超能力アルゴリズムに送られた最小の数のビットはそう以上であるに違いありません。主要なサイズ。 合わせることの材料の最初の128、192、または256個のかけらから暗号の暗号化と復号化キーを取ります。

Kato, et al.                Standards Track                     [Page 4]

RFC 4312                    Camellia Cipher                December 2005

加藤、他 規格はツバキ暗号2005年12月にRFC4312を追跡します[4ページ]。

4.  Interaction with Internet Key Exchange [IKE]

4. インターネット・キー・エクスチェンジとの相互作用[イケ]

   Camellia was designed to follow the same API as the AES cipher.
   Therefore, this section defines only Phase 1 Identifier and Phase 2
   Identifier.  Any other consideration related to interaction with IKE
   is the same as that of the AES cipher.  Details can be found in
   [AES-IPSEC].

ツバキは、AES暗号と同じAPIに続くように設計されました。 したがって、このセクションはPhase1IdentifierとPhase2Identifierだけを定義します。 IKEとの相互作用に関連するいかなる他の考慮もAES暗号のものと同じです。 [AES-IPSEC]で詳細を見つけることができます。

4.1.  Phase 1 Identifier

4.1. フェーズ1識別子

   For Phase 1 negotiations, IANA has assigned an Encryption Algorithm
   ID of 8 for CAMELLIA-CBC.

Phase1交渉のために、IANAはCAMELLIA-CBCのための8のEncryption Algorithm IDを割り当てました。

4.2.  Phase 2 Identifier

4.2. フェーズ2識別子

   For Phase 2 negotiations, IANA has assigned an ESP Transform
   Identifier of 22 for ESP_CAMELLIA.

Phase2交渉のために、IANAは超能力_CAMELLIAのための22の超能力Transform Identifierを割り当てました。

5.  Security Considerations

5. セキュリティ問題

   Implementations are encouraged to use the largest key sizes they can,
   taking into account performance considerations for their particular
   hardware and software configuration.  Note that encryption
   necessarily affects both sides of a secure channel, so such
   consideration must take into account not only the client side, but
   also the server.  However, a key size of 128 bits is considered
   secure for the foreseeable future.

実装がそうすることができる中で最も大きい主要なサイズを使用するよう奨励されます、それらの特定のハードウェアとソフトウェア構成によって性能問題を考慮に入れて。 そのような考慮がクライアント側だけではなく、サーバも考慮に入れなければならないように、暗号化が必ず安全なチャンネルの両側に影響することに注意してください。しかしながら、128ビットの主要なサイズは安全であると予見できる未来と考えられます。

   No security problem has been found on Camellia [CRYPTREC][NESSIE].

警備上の問題は全くCamellia[CRYPTREC][ネッシー]で見つけられていません。

6.  IANA Considerations

6. IANA問題

   IANA has assigned Encryption Algorithm ID = 8 to CAMELLIA-CBC.

IANAはEncryption Algorithm ID=8をCAMELLIA-CBCに割り当てました。

   IANA has assigned ESP Transform Identifier = 22 to ESP_CAMELLIA.

IANAは超能力Transform Identifier=22を超能力_CAMELLIAに割り当てました。

7.  Acknowledgements

7. 承認

    Portions of this text were unabashedly borrowed from [AES-IPSEC].
    This work was done when the first author worked for NTT.

[AES-IPSEC]から本稿の部分を平気で借りました。 第1代作者がNTTで働いていたとき、この仕事をしました。

Kato, et al.                Standards Track                     [Page 5]

RFC 4312                    Camellia Cipher                December 2005

加藤、他 規格はツバキ暗号2005年12月にRFC4312を追跡します[5ページ]。

8.  References

8. 参照

8.1.  Normative References

8.1. 引用規格

   [Camellia-Desc]  Matsui, M., Nakajima, J., and S. Moriai, "A
                    Description of the Camellia Encryption Algorithm",
                    RFC 3713, April 2004.

[ツバキ-Desc] 松井、M.、Nakajima、J.、およびS.Moriai、「ツバキ暗号化アルゴリズムの記述」、RFC3713、2004年4月。

   [ESP]            Kent, S., "IP Encapsulating Security Payload (ESP)",
                    RFC 4303, December 2005.

[超能力] ケント、S.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC4303、2005年12月。

8.2.  Informative References

8.2. 有益な参照

   [AES]            NIST, FIPS PUB 197, "Advanced Encryption Standard
                    (AES)," November 2001.
                    http://csrc.nist.gov/publications/fips/fips197/
                    fips-197.{ps,pdf}.

[AES]NIST、FIPS PUB197、「エー・イー・エス(AES)」11月2001日の http://csrc.nist.gov/publications/fips/fips197/ fips-197ps、pdf。

   [AES-IPSEC]      Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
                    Cipher Algorithm and Its Use With IPsec," RFC 3602,
                    September 2003.

[AES-IPSEC] フランケル、S.、グレン、R.、およびS.ケリー、「AES-CBCはIPsecと共にアルゴリズムとその使用を解きます」、RFC3602、2003年9月。

   [ARCH]           Kent, S. and R. Atkinson, "Security Architecture for
                    the Internet Protocol", RFC 2401, November 1998.

[アーチ形に曲げます] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。

   [Camellia-CMS]   Moriai, S. and A. Kato, "Use of the Camellia
                    Encryption Algorithm in Cryptographic Message Syntax
                    (CMS)", RFC 3657, January 2004.

[ツバキcm] MoriaiとS.とA.加藤、「暗号のメッセージ構文(cm)におけるツバキ暗号化アルゴリズムの使用」、RFC3657、2004年1月。

   [Camellia-Web]   Camellia web site:
                    http://info.isl.ntt.co.jp/camellia/.

[ツバキウェブ] ツバキウェブサイト: http://info.isl.ntt.co.jp/camellia/ 。

   [CRYPTO-S]       Schneier, B., "Applied Cryptography Second Edition",
                    John Wiley & Sons, New York, NY, 1995, ISBN 0-471-
                    12845-7.

[暗号S] シュナイアーとB.と「適用された暗号第2版」とジョン・ワイリーと息子、ニューヨーク、ニューヨーク1995、ISBN0-471- 12845-7。

   [CRYPTREC]       Information-technology Promotion Agency (IPA),
                    Japan, CRYPTREC.
                    http://www.ipa.go.jp/security/enc/CRYPTREC/ index-
                    e.html.

CRYPTREC[CRYPTREC]情報技術Promotion Agency(IPA)、日本 http://www.ipa.go.jp/security/enc/CRYPTREC/ はe.htmlに索引をつけます。

   [IKE]            Harkins, D. and D. Carrel, "The Internet Key
                    Exchange (IKE)", RFC 2409, November 1998.

[IKE]ハーキンとD.とD.個人閲覧室、「インターネット・キー・エクスチェンジ(IKE)」、RFC2409 1998年11月。

   [SP800-38a]      Dworkin, M., "Recommendation for Block Cipher Modes
                    of Operation - Methods and Techniques", NIST Special
                    Publication 800-38A, December 2001.

[SP800-38a] ドーキンと、M.と、「操作--メソッドのブロック暗号モードのための推薦とテクニック」、NISTの特別な公表800-38A、12月2001

Kato, et al.                Standards Track                     [Page 6]

RFC 4312                    Camellia Cipher                December 2005

加藤、他 規格はツバキ暗号2005年12月にRFC4312を追跡します[6ページ]。

   [NESSIE]         The NESSIE project (New European Schemes for
                    Signatures, Integrity and Encryption),
                    http://www.cosic.esat.kuleuven.ac.be/nessie/.

[ネッシー] ネッシープロジェクト(Signatures、Integrity、およびEncryptionのための新しいヨーロッパのSchemes)、 http://www.cosic.esat.kuleuven.ac.be/nessie/ 。

   [ROAD]           Thayer, R., Doraswamy, N., and R. Glenn, "IP
                    Security Document Roadmap", RFC 2411, November 1998.

[道路] セイヤーとR.とDoraswamy、N.とR.グレン、「IPセキュリティドキュメント道路地図」、RFC2411、1998年11月。

   [RFC-2119]       Bradner, S., "Key words for use in RFCs to Indicate
                    Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Authors' Addresses

作者のアドレス

   Akihiro Kato
   NTT Software Corporation

Akihiro加藤NTTソフトウェア株式会社

   Phone: +81-45-212-7934
   Fax:   +81-45-212-7410
   EMail: akato@po.ntts.co.jp

以下に電話をしてください。 +81-45-212-7934 Fax: +81-45-212-7410 メールしてください: akato@po.ntts.co.jp

   Shiho Moriai
   Sony Computer Entertainment Inc.

Shiho Moriai株式会社ソニー・コンピュータエンタテインメント

   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)

以下に電話をしてください。 +81-3-6438-7523 Fax: +81-3-6438-8629 メールしてください: camellia@isl.ntt.co.jp (ツバキチーム) shiho@rd.scei.sony.co.jp (Shiho Moriai)

   Masayuki Kanda
   Nippon Telegraph and Telephone Corporation

Masayuki神田NTT

   Phone: +81-46-859-2437
   Fax:   +81-46-859-3365
   EMail: kanda@isl.ntt.co.jp

以下に電話をしてください。 +81-46-859-2437 Fax: +81-46-859-3365 メールしてください: kanda@isl.ntt.co.jp

Kato, et al.                Standards Track                     [Page 7]

RFC 4312                    Camellia Cipher                December 2005

加藤、他 規格はツバキ暗号2005年12月にRFC4312を追跡します[7ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2005).

Copyright(C)インターネット協会(2005)。

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Kato, et al.                Standards Track                     [Page 8]

加藤、他 標準化過程[8ページ]