ネットワーク WG
Request for Comments: 3657
分類: スタンダードトラック

盛合 志帆
株式会社ソニー・コンピュータエンタテインメント
加藤 明洋
NTT ソフトウェア株式会社
2004 年 1月

English

 

CMS における Camellia 暗号化アルゴリズムの使用法
(Use of the Camellia Encryption Algorithm in Cryptographic Message Syntax (CMS))

 

本書の位置づけ

本書は、インターネット・コミュニティに対して、インターネット標準化過程プロトコルを定義し、その向上のための議論や提案を求めるものである。このプロトコルの標準化状況やステータスについては 、"Internet Official Protocol Standards" (STD 1) の最新版を参照のこと。本書の配布は、制限されていない。

著作権表記

Copyright (C) The Internet Society (2004). All Rights Reserved.

要旨

本書は、Cryptographic Message Syntax (CMS:暗号メッセージ構文)での暗号化のために Camellia 暗号アルゴリズムを使う規定を定義する。

 

1. はじめに English

本書は、Cryptographic Message Syntax (CMS:暗号メッセージ構文)での暗号化のために Camellia 暗号アルゴリズム [CamelliaSpec] を使う規定を定義する。関係するオブジェクト識別子(object identifiers (OID))と処理ステップも提示しており、それにより、Camellia は、コンテントとキーの暗号化に対して、CMS 仕様(RFC 3369、RFC 3370)での使用が可能となる。

注意: 本書は、最初の著者が NTT に勤務している時に作成されたものである。

1.1. Camellia English

Camellia は、2000年、NTT と三菱電機により共同で開発された。Camellia は、128 bit のブロック・サイズと 128、192 および 256 bit キー・サイズを定義する。これは、AED(Advanced Encryption Standard)と同じインターフェースである。Camellia は、ソフトウェアとハードウェアの両方の 実装に対する適性、そして、高度なレベルのセキュリティが特徴である。実用面からの観点から見ると、Camellia は、インターネットや多くのアプリケーションで広く使われている 32 bit プロセッサ、スマート・カードで使われる 8 bit プロセッサ、暗号ハードウェア、組み込みシステムなどでのソフトウェアおよびハードウェアの実装において柔軟性を確保するよう設計されている [CamelliaTech]。さらに、そのキーセットアップ時間は特に優れており、そのキーの「軽快さ」は 、AES のものよりずっと優れている。

Camellia は、暗号アルゴリズムを検証するためのいくつかのプロジェクトで、広範囲な暗号コミュニティにより精査されている。特に、Camellia は、EU NESSIE (New European Schemes for Signatures, Integrity and Encryption)プロジェクト [NESSIE] により「推薦暗号プリミティブ」として選択されており、また、日本の電子政府システム(e-Government systems)に対する暗号技術のリストに含まれている。(これらの技術は、Japan CRYPTREC (Cryptography Research and Evaluation Committees) [CRYPTREC])によって選択されているものである)。

1.2. 用語 English

本書における"MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" および "OPTIONAL" という (このように大文字で示されている)キー・ワードは 、[RFC2119] において説明されているように解釈されるものとする。

 

2. コンテントおよびキーの暗号化用オブジェクト識別子 English

本項は、Camellia が CMS でコンテントとキーを暗号化するのに使う必要のある OID と処理情報を説明する。

Camellia は、2種類の異なるオブジェクト識別子(OID)を提供することによって、CMS での対称暗号アルゴリズム(オプション)セットに追加される。ひとつの OID クラスは、コンテント暗号化アルゴリズムを定義し、もうひとつは、キー暗号化アルゴリズムを定義する。したがって、CMS エージェントは、正しいオブジェクト識別子を選択し、必要なパラメータを提供し、そして、プログラム・コードを実行することによりコンテントを暗号化するか、あるいは、キーを暗号化するために Camellia を適用することができる。

2.1. コンテント暗号化用 OID English

Camelliaは、[CMSALG] で定義されている対称暗号アルゴリズムセットに追加される。3 種類の異なるキー・サイズに対して、Camellia のコンテント暗号化アルゴリズム(CBC(Cipher Block Chaining)モード)は、以下のオブジェクト識別子によって識別される。

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) }

AlgorithmIdentifier パラメータ・フィールドは、存在していなければならない(MUST)。そして、このパラメータ・フィールドはIVの値を持っていなければならない(MUST)

CamelliaCBCParameter ::= CamelliaIV -- 初期化ベクター

CamelliaIV ::= OCTET STRING (SIZE(16))

プレーン・テキストは、[CMS] の 6.3 節で指定されているようにパディングされる。

2.2. キー暗号化用 OID English

key-wrap/unwrap(キー・ラップ/アンラップ)プロシジャは、Camellia キー暗号化キー(KEK)で Camellia コンテント暗号化キー(CEK)を暗号化/復号に使われるが、これらの手順は、3 章において定義されている。キー暗号化キーの生成と配布は、本書の範囲外である。

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) }

いずれの場合でも、AlgorithmIdentifier のパラメータ・フィールドは「不在」でなければならない(MUST)。なぜなら、キー・ラッピング・プロシジャ自体が、IV をどのように使うか、いつ使うかを定義するからである。OID は 、KEKキー・サイズを指定するが、ラップされた Camellia CEK のサイズに関して、いかなる指定も行わない。実装は、異なる KEK および CEK サイズを使うことができる(MAY)。実装は、同じ長さを持つ CEK と KEK をサポートしなければならない。もし、異なる長さがサポートされている場合、KEK は、CEK の長さ以上でなければならない(MUST)

 

3. キー・ラップ・アルゴリズム English

Camellia キー・ラッピングおよびアンラッピングは、AES キー・ラップ・アルゴリズム [RFC3394] に遵守して行われる。なぜなら、Camellia と AES は 、同じブロック・サイズとキー・サイズを持っている(つまり、128 bit のブロック・サイズおよび 128 bit、192 bit および 256 bit のキー・サイズ)からである。

3.1. 表記法と定義 English

キー・ラッピング・アルゴリズムの説明においては、以下の表記法が使われる。:

Camellia(K, W) キーKで Camellia コードブックを使って W を暗号化する。
Camellia-1(K, W) キーKで Camellia コードブックを使い W を解読する。
MSB(j, W) W の最上位 j bit を返却する。
LSB(j, W) W の最下位 j bit を返却する。
B1 ^ B2 B1 と B2 のビットごとの排他的論理和(XOR)。
B1 | B2 B1 と B2 を連結する。
K キーKのキー暗号化。
n 64 bit キー・データ・ブロックの数。
s ラッピング・プロセスのステップ数:s = 6n
P[i] i 番目のプレーンテキスト・データ・ブロック
C[i] i 番目の暗号テキスト・データ・ブロック
A 64 bit インテグリティ・チェック・レジスタ
R[i] 64 bit レジスタ配列(i = 0, 1, 2, ..., n)
A[t], R[t][i] 暗号ステップ t 後のレジスタ A と R[i] の中身。
IV ラッピング・プロセス中に使われる 64 bit 初期値。

キー・ラップ・アルゴリズムでは、Camellia コードブックへの 128 bit インプットを形成する場合、64 bit 単位のデータを連結するのに連結(concatenation)関数が使われる。Camellia コードブックからの 128 アウトプットを 2つの 64 bit 単位のデータに分割するのに抽出(extraction)関数が使われる。

3.2. Camellia キー・ラップ English

Camellia でのキー・ラップは、[RFC3394] の 2.2.1 節と同じであり、その場合、"AES" を "Camellia" に置き換えて読むことができる。

キー・ラッピング・プロセスに対するインプットは、KEK と、ラップされるプレーンテキストとなる。プレーンテキストは、64 bit ブロックから構成され、それらのブロックは、ラップされるキー・データを含んでいる。キー・ラッピング・プロセスが以下で説明されている。

インプット: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and Key, K (the KEK).

アウトプット: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.

1) 変数を初期化する。

A[0] を初期値に設定する(参照: 3.4 節)。

For i = 1 to n

    R[0][i] = P[i]

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) 結果を出力する。

Set C[0] = A[t]

For i = 1 to n C[i] = R[t][i]

キー・ラップ・アルゴリズムを別に説明すると、シフト(shifting)の代わりにインデックス(indexing)を使うことができる。このアプローチは、ラップされたキーを特定の場所で計算するのを可能にし、前述でのローテーションをしないようにすることができる。これは 、まったく同じ結果となり、ソフトウェアでの実装がより簡単である。

インプット: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}, and Key, K (the KEK).

アウトプット: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}.

1) 変数を初期化する。

A = IV(初期値)と設定する(参照: 3.4 節)。

For i = 1 to n

    R[i] = P[i]

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) 結果を出力する。

Set C[0] = A

For i = 1 to n

    C[i] = R[i]

3.3. Camellia キー・アンラップ English

Camellia でのキー・アンラップは、[RFC3394] の 2.2.2 節と同じであり、その場合、"AES" を "Camellia" に置き換えて読むことができる。

アンラップ・プロセスへのインプットは、KEK と、以前にラップされたキーから構成されている暗号テキスト(ciphertext)の (n+1) 個の 64 bit ブロックである。このプロセスは、復号されたキー・データの n 個の 64 bit ブロックから構成されているプレーンテキストの n 個のブロックを返却する。

インプット: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, and Key, K (the KEK).

アウトプット: Plaintext, n 64-bit values {P[1], P[2], ..., P[n]}.

1) 変数を初期化する。

A[s] = C[0]と設定する(s = 6n)

For i = 1 to n

    R[s][i] = C[i]

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) 結果を出力する。

A[0] が正しい初期値であれば(参照:3.4 節):

Then

    For i = 1 to n

         P[i] = R[0][i]

Else

    Return an error

アンラップ・アルゴリズムは、計算を特定の場所で行うようにするのを可能にするインデックス・ベースのオペレーションとしても定義することができる。ここでも、これは、レジスタ・シフト・アプローチと同じ結果を出す。

インプット: Ciphertext, (n+1) 64-bit values {C[0], C[1], ..., C[n]}, and Key, K (the KEK).

アウトプット: Plaintext, n 64-bit values {P[0], P[1], ..., P[n]}.

1) 変数を初期化する。

Set A = C[0]

For i = 1 to n

    R[i] = C[i]

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) 結果を出力する。

A が正しい初期値であれば(参照:3.4 節):

Then

    For i = 1 to n

         P[i] = R[i]

Else

    Return an error

3.4. キー・データのインテグリティ:初期値 English

初期値(IV)は、ラッピング・プロセスの最初のステップでの A[0] に割り当てられる値を意味する。この値は、キー・データでのインテグリティ・チェックを得るために使われる。アンラッピング・プロセスの最初のステップでは、A[0] のリカバリーされた値が、A[0] の期待値と比較される。それらが一致すると、キーは正しいものとして受け入れられ、アンラッピング・アルゴリズムはそれを返却する。それらが一致しない場合、キーは拒否され、アンラッピング・アルゴリズムはエラーを返却する。

このインテグリティ・チェックにより達成される正確な特性というのは、初期値の定義に依存する。異なるアプリケーションは、ある程度異なる特性を必要とする。例えば、キー・データのライフサイクル全体でインテグリティを判断する必要あるか、あるいは、キー・データがアンラップされる場合にのみ必要かである。本仕様は、キー・データがラップされる間に、そのキー・データのインテグリティをサポートするディフォルト初期値を定義する(3.4.1 節)。また、別の初期値をサポートするための設定も提供されている(3.4.2 節)。

3.4.1. ディフォルト初期値 English

ディフォルト初期値(IV)は、HEX定数と定義されている。

A[0] = IV = A6A6A6A6A6A6A6A6

IVとして定数を使うことにより、キー・データがラップされている間、そのキー・データでの強力なインテグリティ・チェックをサポートすることになる。アンラッピングが、A[0] = A6A6A6A6A6A6A6A6 を生成するのであれば、キー・データが不正となる可能性は 、2^-64 となる。アンラッピングが A[0]= 他の値を生成する場合、そのアンラッピングは、エラーを返却する必要があり、いかなるキー・データをも返却してはならない。

3.4.2. 別の初期値 English

キー・ラップが、より大きなキー・マネジメント・プロトコルやシステムの一部として使われる場合、データ・インテグリティに対して必要とされる範囲は、キー・データ以上におよぶか、または、キー・データがラップされる期間以上の期間が必要となる。また、キー・データが単なる Camellia キーではない場合、そのキー・データは、常に、64 bit の倍数になるとは限らない。初期値の別の定義は、そのような問題に対処するのに使うことができる。[RFC3394] によれば、NIST は、必要に応じて、今後のキー・マネジメントの発表において別の初期値を定義するとしている。今後多くなるであろう一連の別の初期値に対処するために、アプリケーション特有でないキー・ラップ・ 実装は、初期値がどのように設定されテストされるかについてなんらかの柔軟性を必要とするであろう。

 

4. SMIMECapabilities 属性 English

S/MIME クライアントは、それがサポートする一連の暗号関数を、S/MIME capabilities 属性を使って発表する必要がある(SHOULD)。この属性は、暗号関数の OID の部分的リストを提供し、クライアントにより署名されなければならない(MUST)。それらの関数 の OID は、関数カテゴリーで論理的に分離されている必要があり(SHOULD)、それらのプリファレンスに関して順列化されなければならない(MUST)

RFC 2633 [RFC2633] の 2.5.2 節は、SMIMECapabilities 署名属性(SMIMECapabilities signed attribute)が、アルゴリズムの部分リストを定義するのに(SMIMECapabilities を発表するソフトウェアがサポートできると)使われることを定義する(SMIMECapability SEQUENCE の SEQUENCE として定義されている)。

S/MIME クライアントが、Camellia で対称暗号をサポートすることと求められる場合、capabilities 属性は、その対称的アルゴリズムのカテゴリーで、上記で定義された Camellia OID を含んでいなければならない(MUST)。この OID に関連付けられているパラメータは、CamelliaSMimeCapability でなければならない(MUST)

CamelliaSMimeCapabilty ::= NULL

Camellia を表す SMIMECapability シーケンスは、以下の HEX 文字列として DER エンコードされなければならない(MUST)

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

 

送信側エージェントが、暗号化されたメッセージを作成する場合、そのエージェントは、どのタイプの暗号化アルゴリズムを使うかを決める必要がある。通常、その決定プロセスは、受信者から受け取ったメッセージに含まれている capabilities(機能)リストから得られた情報や、個々の合意、ユーザ・プリファレンス、法律的規制などの他の情報が関与している。ユーザが、対称暗号に Camellia を求める場合、それは、送信側と受信側の両方で、S/MIME クライアントによってサポートされなければならない(MUST)し、そして、それはユーザ・プリファレンスで設定されていなければならない(MUST)。」

 

5. セキュリティについての考慮事項 English

本書は、CMS メッセージのコンテントを暗号化するための、そして、CMS メッセージのコンテントを暗号化するために使われる対称キーを暗号化するためのCamellia の使用を定義する。そして、他のメカニズムは、既存のものと同じである。したがって、CMS 仕様 [CMS] [CMSALG] で説明されているセキュリティに関する事柄や、AES キー・ラップ・アルゴリズム [RFC3394] は 、本書に適用することが可能である。Camellia では、いずれのセキュリティ問題は発見されていない[CRYPTREC][NESSIE]。

 

6. 知的財産権表記 English

IETF は、実装の特許申請、あるいは、本書に記述された以外の技術の利用、もしくは、そのような権利のもとで利用可能/利用不可なライセンスの程度について主張される可能性があるいかなる知的財産権もしくは他の権利の正当性もしくは範囲について中立である。; また、そのような権利を識別するためのあらゆる努力をしてきたと表現するものではない。スタンダードトラックと標準関連文書における権利に関する IETF の手順についての情報は、BCP-11 にある。入手可能な権利の主張と、あらゆる入手可能なライセンスの証明、もしくは、一般ライセンスを入手する試みの結果、もしくは、この仕様について、そのような財産権を実装者またはユーザが使用する許可についてのコピーは、 IETF 事務局から入手可能である。

IETF は、この標準を施行するために要求される可能性がある技術にあたる可能性があるあらゆる著作権、特許もしくは特許利用、あるいは他の財産権への注目を寄せる、いかなる利益主体も受け付けている。IETF エグゼクティブディレクター宛に情報を寄せていただきたい。

IETF には、本書に含まれている仕様の一部、または、すべてに関して主張されている知的所有権について通知がなされている。詳細は、主張されている権利のオンライン・リストを参照のこと。

 

7. 参考文献

7.1. 規範的参考文献

[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(English), 2002年 8月.
 
[CMSALG] Housley, R.,
"Cryptographic Message Syntax (CMS) Algorithms",
RFC 3370, 2002年 8月.
 
[RFC2633] Ramsdell, B., Editor,
"S/MIME Version 3 Message Specification",
RFC 2633(English), 1999年 6月.
 
[RFC3565] Schaad, J.,
"Use of the Advanced Encryption Standard (AES) Encryption Algorithm in Cryptographic Message Syntax (CMS)",
RFC 3565, 2003年 7月.
 
[RFC3394] Schaad, J. and R. Housley,
"Advanced Encryption Standard (AES) Key Wrap Algorithm",
RFC 3394, 2002年 9月.

7.2. 参考文献

[DES] National Institute of Standards and Technology.
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, 2000年 8月, Proceedings, Lecture Notes in Computer Science 2012, pp.39-56, Springer-Verlag, 2001年.
 
[CRYPTREC] 独立行政法人 情報処理推進機構(IPA)の 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.,
「RFC において要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」,
BCP 14, RFC 2119, 1997年 3月.

 

付録 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) }

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

 

著者・翻訳者の連絡先

盛合 志帆
株式会社ソニー・コンピュータエンタテインメント
電話: +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)

加藤 明洋
NTT ソフトウェア株式会社
電話: +81-45-212-7934
Fax: +81-45-212-9800
EMail: akato@po.ntts.co.jp

 

著作権表記全文

Copyright (C) The Internet Society (2004). All Rights Reserved.

この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。

上で認めた制限された許諾は、永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。

この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。

謝辞

RFC エディター機能に対する資金提供は、現在、インターネット・ソサエティ(Internet Society)により提供されている。