|
ネットワーク WG Request for Comments： 4051 分類： スタンダードトラック |
D. Eastlake 3rd Motorola Laboratories 2005年4月 |
本書は、インターネット・コミュニティに対して、 インターネット標準化過程プロトコルを定義し、 その向上のための議論や提案を求めるものである。 このプロトコルの標準化状況やステータスについては"Internet Official Protocol Standards" (STD 1)の最新版を参照のこと。 本書の配布は、制限されていない。
Copyright (C) The Internet Society (2005).
XMLディジタル署名、 暗号化および正規化(Canonicalization)に使われるいくつかのURI (Uniform Resource Identifiers)が定義されている。 これらのURIは、キーイング情報のアルゴリズムとタイプを識別する。
XMLディジタル署名、暗号化および正規化(Canonicalization)は、 W3Cと合同のIETF/W3C XMLDSIGワーキンググループによって標準化されている。 これらのすべては、現在では、W3C勧告(W3C Recommendation)およびIETF情報または標準化過程(IETF Informational Standards Track)文書となっている。
| IETF level | W3C REC | Topic |
|---|---|---|
| [RFC3275] Draft Std | [XMLDSIG] | XMLデジタル署名 |
| [RFC3076] Info | [CANON] | Canonical XML |
| - - - - - - | [XMLENC] | XML Encryption |
| [RFC3741] Info | [EXCANON] | Exclusive XML Canonicalization |
これらのすべての標準と勧告は、 アルゴリズムとキーイング情報タイプを識別するためにURI [RFC2396] を使う。 本書は、使いやすいURIのリファレンスリストを提供する。 そして、大きな関心はあるが、 メインの文書には含めることができないアルゴリズムを説明する。 注意： IETFにおいて、XMLディジタル署名を草稿標準(Draft Standard)へ格上げするのに、 メインの標準文書からインターオペラビリティが証明されていないいずれのアルゴリズムの削除が必要であった。 引き続き関心があると思われる最小正規(Minimal Canonicalization)アルゴリズムの削除(必要とされた)は、 標準化過程仕様(standards track specification)からは外されている。 それは、本書に含まれている。
本書における "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY"および "OPTIONAL"というキーワードは、 [RFC2119] で説明されているように解釈されるものとする。
URI [RFC2396] は、 プロポーズト標準(Proposed Standard)からドラフト標準(Draft Standard)への転換という理由により標準からはずされているが、 これは、 元のプリフィックスと共に2.4節に含まれている。 それにより、XMLDSIG標準のネームスペースを変更する必要がない。
http://www.w3.org/2000/09/xmldsig#
追加のアルゴリズムも以下で始まる URI に与えられている。：
http://www.w3.org/2001/04/xmldsig-more#
"xmldsig-more"をもつURIは、 これらのアルゴリズムや識別子に対する公式なW3Cステータスを意味するものではないし、 または、それらはディジタル署名でのみ有効である。 現在、そのようなURIのデリファレンシング(dereferencing)が、 仮のプレースホルダー文書を作成するかしないかは不明である。 このURIプリフィックスを使用する許可は、 W3Cによって与えられている。
これらのアルゴリズムは、 DigestMethodエレメントが発生する場合は、常に使用可能である。
MD5アルゴリズム [RFC1321] は、 明示的なパラメータを取らない。 MD5 DigestAlgorithmエレメントの例は以下のとおり。
<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#md5"/>
MD5ダイジェスト(MD5 digest)は、128bit文字列である。 DigestValueエレメントの中身は、 base64 [RFC2405] となり、 このビット文字列を16オクテットのオクテットストリームとしてコード化する。
SHA-224アルゴリズム [FIPS-180-2change, RFC3874] は、 明示的なパラメータを取らない。 SHA-224 DigestAlgorithmエレメントの例は、以下のとおり。
<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha224" />
SHA-224ダイジェスト(SHA-224 digest)は、224bit文字列である。 DigestValueエレメントの中身は、 base64 [RFC2405] となり、 このビット文字列を28オクテットのオクテットストリームとしてコード化する。 SHA-224メッセージ・ダイジェストを計算するには、 SHA-256ダイジェストと同じぐらいの労力が必要となり、そして、 XMLアプリケーションにおいては、通常、簡潔さは必要条件ではないため、 別の方法としてSHA-256の使用を考慮するべきである。
SHA-384アルゴリズム [FIPS-180-2] は、明示的なパラメータを取らない。 SHA-384 DigestAlgorithmエレメントの例は、以下のとおり。：
<DigestAlgorithm Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha384" />
SHA-384ダイジェスト(SHA-384 digest)は、224bit文字列である。 DigestValueエレメントの中身は、base64 [RFC2405] となり、 このビット文字列を48オクテットのオクテットストリームとしてコード化する。 SHA-384メッセージダイジェストを計算するには、 SHA-512ダイジェストと同じぐらいの労力が必要となり、そして、 XML アプリケーションにおいては、通常、簡潔さは必要条件ではないため、 別の方法としてSHA-512の使用を考慮するべきである。
注意： 本項のいくつかの文は、読者の便宜を考慮して、 [RFC3275] から複写されている。 矛盾がある場合、RFC 3275が規範となる。
HMACアルゴリズム [RFC2104] は、 ビットでの切り捨て長をパラメータとして取る。 パラメータが指定されていない場合、 ハッシュのすべてのビットがアウトプットとなる。 HMAC-MD5 SignatureMethodエレメントの例は、以下のとおり。：
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-md5">
HMACOutputLength>112</HMACOutputLength>
</SignatureMethod>
HMACアルゴリズムのアウトプットが、最終的には、 選択されているダイジェストアルゴリズムのアウトプット(おそらくは切り捨てられている)となる。 この値は、 ダイジェストアルゴリズムのアウトプットと同じように簡単な方法でコード化されるbase64 [RFC2405] となる。 例えば、HMAC-MD5ダイジェストに対するSignatureValueエレメントは 、 次のようになる。
9294727A 3638BB1C 13F48EF8 158BFC9D
[RFC2104] からのテスト・ベクターから以下のようになる。
kpRyejY4uxwT9I74FYv8nQ==
<simpleType name="HMACOutputLength">
<restriction base="integer"/>
</simpleType>
<!ELEMENT HMACOutputLength (#PCDATA) >
上記のSchema DefinitionとDTDは、 [RFC3275] からのものである。
最近、以下のようにRSA-MD5などの署名にMD5を使うということに対して、 ある程度の暗号的疑念が生じているが、そのことは、 HMACでMD5を使用することには影響を与えない。
SHA-224、SHA-256, SHA-384およびSHA-512 [FIPS-180-2, FIPS-180-2change, RFC3874] も、 HMAC-MD5に関して 2.2.1節で説明されているようにHMACで使うことができる。
RIPEMD-160 [RIPEMD-160] も、 HMAC-MD5に関して2.2.1節で説明されているようにHMACで使うことができる。
これらのアルゴリズムは、公開鍵キーを使うという点で、 2.2節の方法とは異なっている。 認証キーは、署名キー(signing key)とは異なり、 その署名キーからは取り出すことはできないものである。
RSA-MD5は、[RFC3447] に記述されているPKCS#1 v1.5パディングアルゴリズムを意味します。 この一例は、下記のとおり。
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-md5" />
RSA-MD5署名に対するSignatureValueの中身は、base64 [RFC3447] であり、 8.1.1 節(signature generation for the RSASSA-PKCS1-v1_5 signature scheme)の通り計算されたオクテット文字列をコード化する。 [RFC3447, 9.2.1 節] でのEMSA-PKCS1-V1_5-ENCOD関数で指定されているように、 署名関数へ入力される値は、 ハッシュ関数に対して「前もって保留された」(pre-pend)アルゴリズムオブジェクト識別子を含んでいなければならない(MUST)が、 しかし、ASN.1パーサのアベイラビリティと、OIDの認識は、 署名ベリファイヤに必要ではない。 PKCS#1 v1.5は、以下のように表現される。
CRYPT (PAD (ASN.1 (OID, DIGEST (data))))
注意：パディングされたASN.1は、以下の形式となる。
01 | FF* | 00 | prefix | hash
垂直バー("|")は連結を表す。 "01"、"FF"および"00"は、対応するHEX値の固定オクテットであり、 "FF"の後のアステリスク("*")は繰り返しを意味する。 "hash"は、データのMD5ダイジェストである。 "prefix"は、PKCS #1 [RFC3447] で必要とされるASN.1 BER MD5アルゴリズム指定子プリフィックスであり、 次のようになる。
hex 30 20 30 0c 06 08 2a 86 48 86 f7 0d 02 05 05 00 04 10
このプリフィックスは、 標準暗号ライブラリの使用を簡単にするために含まれている。 FFオクテットは、暗号化されている量の値が、RSA係数よりも、 ちょうど1オクテット短くなるよう充分な回数繰り返されなければならない(MUST)。
コンピュータの処理能力の増大や暗号技術の進化により、 RSA-MD5の使用は、推薦されない。
これは、2.3.1節で説明されているように、 PKCS#1 v1.5パディング・アルゴリズム [RFC3447] を意味するが、しかし、 ASN.1 BER SHA-256アルゴリズム指定子プリフィックスがついているものである。 使用の例は、以下のとおり。
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
これは、2.3.1節で説明されているように、 PKCS#1 v1.5パディング・アルゴリズム [RFC3447] を意味するが、しかし、 ASN.1 BER SHA-384アルゴリズム指定子プリフィックスがついているものである。 使用例は、以下のとおり。
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha384" />
SHA-384メッセージ・ダイジェストを計算するには、 SHA-512メッセージダイジェストと同じ労力がかかるため、 RSA-SHA384の代わりでできるだけRSA-SHA512が使われることが推薦される。
これは、2.3.1節で説明されているように、 PKCS#1 v1.5パディング・アルゴリズム [RFC3447] を意味するが、しかし、 ASN.1 BER SHA-512アルゴリズム指定子プリフィックスがついているものである。 使用例は、以下のとおり。
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha512" />
これは、2.3.1節で説明されているように、 PKCS#1 v1.5パディング・アルゴリズム [RFC3447] を意味するが、しかし、 ASN.1 BER RIPEMD160アルゴリズム指定子プリフィックスが付いているものである。 使用例は、以下のとおり。
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more/rsa-ripemd160" />
ECDSA (Elliptic Curve Digital Signature Algorithm) [FIPS-186-2] は、 DSA (DSS)署名メソッドの楕円曲線アナログである。 これをSHAハッシュ関数とXML Digital Signature どのように使うかの詳細仕様については [X9.62] と [ECDSA] を参照。
[IEEE-P1363a] で定義されているESGNアルゴリズムは、 整数分解問題に基づいた署名スキームである。 これは、以前のディジタル署名よりもずっと高速であり、したがって、 ESIGNは、特別なコプロセッサ無しでスマートカードに組み込むことができる。
以下に使用例が示されている。
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#esign-sha1" />
現在までに、 Minimal Canonicalization(最小正規化)の2つのインターオペラブルな独立したインプリメンテーションは発表されていない。 したがって、XML Digital Signatureが、 Proposed Standard(提案標準) [RFC3075] からDraft Standard(草稿標準) [RFC3275] に格上げされた場合、Minimal Canonicalization(最小正規化)は、 標準追跡文書からは除去された。 しかし、Minimal Canonicalization(最小正規化)には、今後、 使用される可能性を含めまだ関心がありある。 その定義については [RFC3075] 6.5.1節を参照のこと。
参考： その識別子は、以下のままである。
http://www.w3.org/2000/09/xmldsig#minimal
注意：すべてのCanonicalizationMethodアルゴリズムは、 変換アルゴリズムとしても使うことができる。
この変換アルゴリズムは、[XPointer] を明示的パラメータとして読み込む。 使用の例は以下のとおり [RFC3092]。：
<Transform Algorithm="http://www.w3.org/2001/04/xmldsig-more/xptr">
<XPointer xmlns="http://www.w3.org/2001/04/xmldsig-more/xptr">
xpointer(id("foo"))
xmlns(bar=http://foobar.example)
xpointer(//bar:Zab[@Id="foo"])
</XPointer>
</Transform>
<element name="XPointer" type="string">
<!ELEMENT XPointer (#PCDATA) >
この変換へのインプットはオクテット・ストリーム(その後、 XMLにパースされる)である。
この変換からアウトプットは、ノード・セットであり、XPointerの結果は、 同じ文書XPointerに対してXMLDSIG仕様 [RFC3275] で定義されているように処理される。
本項は、いくつかのEncryptionMethodアルゴリズムの識別子や情報を説明する。
ARCFOURは、高速で、単純なストリームの暗号化アルゴリズムであり、 RSA SecurityのRC4アルゴリズムと互換性がある。 ARCFOURを使ったEncryptionMethodエレメントの例は、以下のとおり。
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#arcfour">
<KeySize>40</KeySize>
</EncryptionMethod>
注意：ARCFOURは、[XMLENC] で仕様定義されている汎用KeySizeパラメータを使う。
Camelliaは、AES [Camellia, RFC3713] と同じインタフェース(つまり、128bitのブロック・サイズと128bit、 192bitおよび256bitの鍵長)を持つ効率的でセキュアなブロック暗号である。 XML Encryption(XML暗号化)では、Camelliaは、AESと同じ方法で使われている。 つまり、それは、128bitの初期化ベクター(IV)を持つCBC (Cipher Block Chaining)モードで使われる。 結果の暗号テキストは、IVがプリフィックスとして付いている。 それがもしXMLアウトプットに含まれると、 base64エンコードされることになる。 CamelliaのEncryptionMethodの例が以下に示されている。
<EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#camellia128-cbc" />
Camellia [Camellia, RFC3713] キー・ラップは、 XML Encryption(XML暗号化)標準で定義されているAESキーラップアルゴリズム [RFC3394] と同じである。 (この場合、"AES"を”Camellia"に置き換えて読むだけである。) AESキーラップと同じように、チェック値は、 0xA6A6A6A6A6A6A6A6である。
このアルゴリズムは、 ラッピングで使われるCamelliaキー(キー暗号化キー(key encrypting key)またKEKと呼ばれる)のサイズに関係なく同じである。 Camelliaのインプリメンテーションはオプショナルである。 しかし、それがサポートされているのであれば、 KEKサイズとラップされた鍵長の組み合わせがサポートされるべきか、 オプションでサポートされるべきかは、 同じインプリメンテーションガイドラインがAESに従うべきである。 つまり、Camelliaキー・ラップがサポートされるのであれば、 128bitキーのラッピング(128bit KEKで)と256bitキーのラッピング(256bit KEKで)が要求され(REQUIRED)、 そして、他のすべての組み合わせは 、任意(OPTIONAL)である。)
以下に使用例が示されている。
<EncryptionMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#kw-camellia128" />
PSEC-KEMアルゴリズム([ISO/IEC-18033-2] で定義されている)は、 楕円形曲線暗号化を使った鍵カプセル化メカニズムである。
以下に使用例が示されている。：
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#psec-kem">
<ECParameters>
<Version>version</Version>
<FieldID>id</FieldID>
<Curve>curve</Curve>
<Base>base</Base>
<Order>order</Order>
<Cofactor>cofactor</Cofactor>
</ECParameters>
</EncryptionMethod>
上記のパラメータに関する情報については [ISO/IEC-18033-2] を参照のこと。
3.1節に、新しいKeyInfoエレメントの子が定義されている。 これに対して、3.2節では、 RetrievalMethodでの使用に対して追加のKeyInfo Type値が定義されている。
PKCS #7 [RFC2315] の"signedData"も、 bag of certificates(認証群)やCRL (certificate revocation list：認証取り消しリスト)として使うことができる。 PKCS7signedDataエレメントは、 KeyInfor内でのそのような構造に対応するよう定義されている。 バイナリPKCS #7構造は、 base64 [RFC2405] でコード化されている。 提示されているいずれの署名者(signer)情報は、無視される。 以下は、 base64データを除去する例である [RFC3092]。
<foo:PKCS7signedData xmlns:foo="http://www.w3.org/2001/04/xmldsig-more"> ... </foo:PKCS7signedData>
RetrievalMethodのType属性は、 取り出されるべきデータのタイプを示すオプショナルの識別子である。 XML構造をもつすべてのKeyInfoタイプに対するRetrievalMethodリファレンスをデリファレンスした結果は、 XMLエレメントと、あるいは、そのエレメントをルートとする文書である。 各種の生の("raw")キー情報タイプは、バイナリ値を返却する。 したがって、それらは、明確にパースができないために、 Type属性を必要とする。
人は彼ら自身のユニークなURI [RFC2396] を構築し、 おそらくは、W3Cから(適切であれば)からURIを得ることも容易ではあるが、 本書で順列化されている以上の追加の"http://www.w3.org/2001/04/xmldsig-more#"URLが作成されることは意図されていない。 (W3C Namespace安定性基準は、 "http://www.w3.org/2000/09/xmldsig#"下での新しいURIの作成を禁じている。)
コンピュータの速度は暗号技術の進展から、 DigestMethodとしてMD5を使うこと、そして、 RSA-MD5 SignatureMethodでMD5を使うことは、 推薦されていない(NOT RECOMMENDED)。 懸念されている暗号面での進化は、 HMAC-MD5のセキュリティには影響を与えないが、しかし、 SHAシリーズのアルゴリズムのひとつを使わないという理由はほとんどない。
Glenn Adams, Merlin Hughs, Gregor Karlinger, Brian LaMachia, Shiho Moriai, Joseph Reagle, Russ Housley, and Joel Halpern.
| [Camellia] |
"Camellia: A 128-bit Block Cipher Suitable for
Multiple Platforms - Design and Analysis -", K.
Aoki, T. Ichikawa, M. Matsui, S. Moriai, J.
Nakajima, T. Tokita, 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年. |
| [ECDSA] |
Blake-Wilson, S., Karlinger, G., Kobayashi, T., and Y. Wang, "Using the Elliptic Curve Signature Algorithm (ECDSA) for XML Digital Signatures", RFC 4050, 2005年4月. |
| [FIPS-180-2] |
"Secure Hash Standard"(SHA-1/256/384/512), US Federal Information Processing Standard, NIST, 2002年8月1日. |
| [FIPS-180-2change] |
"FIPS 180-2, Secure Hash Standard Change Notice 1", SHA-224を [FIPS 180-2] に追加, 2004年2月25日. |
| [FIPS-186-2] |
"Digital Signature Standard", US Federal Information Processing Standard, NIST, 2000年. |
| [IEEE-P1363a] | "Standard Specifications for Public Key Cryptography: Additional Techniques", 2002年10月. |
| [ISO/IEC-18033-2] | "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Asymmetric ciphers", CD, 2002年10月. |
| [RFC1321] |
Rivest, R., "The MD5 Message-Digest Algorithm ", RFC 1321, 1992年4月. |
| [RFC2104] |
Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, 1997年2月. |
| [RFC2119] |
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, 1997年3月. |
| [RFC2396] |
Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, 1998年8月. |
| [RFC2405] |
Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher Algorithm With Explicit IV", RFC 2405, 1998年11月. |
| [RFC2315] |
Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, 1998年3月. |
| [RFC3075] |
Eastlake 3rd, D., Reagle, J., and D. Solo, "XML- Signature Syntax and Processing", RFC 3075, 2001年3月. (RFC 3075 was obsoleted by RFC 3275 but is referenced in this document for its description of Minimal Canonicalization which was dropped in RFC 3275.) |
| [RFC3275] |
Eastlake 3rd, D., Reagle, J., and D. Solo, "(Extensible Markup Language) XML-Signature Syntax and Processing", RFC 3275, 2002年3月. |
| [RFC3394] |
Schaad, J. and R. Housley, "Advanced Encryption Standard (AES) Key Wrap Algorithm", RFC 3394, 2002年9月. |
| [RFC3447] |
Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", RFC 3447(English), 2003年2月. |
| [RFC3713] |
Matsui, M., Nakajima, J., and S. Moriai, "A Description of the Camellia Encryption Algorithm", RFC 3713, 2004年4月. |
| [RFC3874] |
Housley, R., "A 224-bit One-way Hash Function: SHA-224", RFC 3874, 2004年9月. |
| [RIPEMD-160] | ISO/IEC 10118-3:1998, "Information Technology - Security techniques - Hash-functions - Part3: Dedicated hash- functions", ISO, 1998年. |
| [X9.62] |
X9.62-200X, "Public Key Cryptography for the Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", Accredited Standards Committee X9, American National Standards Institute. |
| [XMLDSIG] |
"XML-Signature Syntax and Processing", D. Eastlake 3rd, J. Reagle, & D. Solo, 12 2002年2月. <http://www.w3.org/TR/xmldsig-core/> |
| [XMLENC] |
"XML Encryption Syntax and Processing", J. Reagle, D. Eastlake, 2002年12月. <http://www.w3.org/TR/2001/RED-xmlenc-core- 20021210/> |
| [XPointer] |
"XML Pointer Language (XPointer) Version 1.0", W3C working draft, Steve DeRose, Eve Maler, Ron Daniel Jr., 2001年1月. <http://www.w3.org/TR/2001/WD-xptr-20010108> |
| [CANON] |
"Canonical XML Version 1.0", John Boyer. <http://www.w3.org/TR/2001/REC-xml-c14n-20010315>. |
| [EXCANON] |
"Exclusive XML Canonicalization Version 1.0", D.
Eastlake, J. Reagle, 2002年7月18日. <http://www.w3.org/TR/REC-xml-enc-c14n-20020718/>. |
| [RFC3076] |
Boyer, J., "Canonical XML Version 1.0", RFC 3076, 2001年3月. |
| [RFC3092] |
Eastlake 3rd, D., Manros, C., and E. Raymond, "Etymology of "Foo"", RFC 3092, 2001年. |
| [RFC3741] |
Boyer, J., Eastlake 3rd, D., and J. Reagle, "Exclusive XML Canonicalization, Version 1.0", RFC 3741, 2004年3月. |
Donald E. Eastlake 3rd
Motorola Laboratories
155 Beaver Street Milford,
MA 01757 USA
電話： +1-508-786-7554 (w)
+1-508-634-2066 (h)
EMail： Donald.Eastlake＠motorola.com
Copyright (C) The Internet Society (2005).
本書は、BCP 78に含まれている権利、 ライセンスおよび制限の対象となっており、 本書で明記されている場合を除いて、 著者がそれらのすべての権利を有するものとする。
本書および本書に含まれている情報は、 「そのまま」の状態で提供されるものとし、寄稿者、その寄稿者が代表する、 または、それにより後援されている組織(ある場合)、 インターネット・ソサエティ(INTERNET SOCIETY)およびインターネット・エンジニアリング・タスク・フォースは、 明示的にも暗黙のうちにも、そうとは限定されないが、本書での情報が、 いかなる権利をも侵害しないとか、 特定の目的に対して商品性や適性を意図した保証を含むすべての保証を拒否するものである。
この文書に記述される技術の実装および使用に関係すると主張される、 知的財産権およびその他の権利の有効性または範囲に関して、 またこのような権利の下でのあらゆる権利が効力を持つ範囲に関して、 IETFはいかなる立場もとらず、また、 IETFはそのような権利を確認するためのいかなる取り組みを行ったことも表明しない。 RFC文書における権利に関する手続きの情報は、 BCP 78およびBCP 79に記述されている。
IETF事務局に提出されたIPR公開文書のコピーおよび利用可能となるライセンス保証のコピー、 あるいは、この仕様の実装者やユーザによる所有権の使用に対する一般的な権利や許可を得るために行われた試みの結果は、 IETFオンラインIPRリポジリ(http://www.ietf.org/ipr)から入手可能である。
IETFは、どのような利害関係者に対しても、 この標準を実装するために必要な技術をカバーする著作権や特許、特許出願、 その他の所有権に対して注意を払うように依頼する。 IETF(ietf-ipr@ietf.org)までその情報を送ってください。
RFCエディター機能に対する資金提供は、現在、 インターネット・ソサエティ(Internet Society)により提供されている。