RFC2792 日本語訳

Network Working Group                                           M. Blaze
Request for Comments: 2792                                  J. Ioannidis
Category: Informational                             AT&T Labs - Research
                                                            A. Keromytis
                                                      U. of Pennsylvania
                                                              March 2000

コメントを求めるワーキンググループM.炎の要求をネットワークでつないでください: 2792年のJ.Ioannidisカテゴリ: 情報のAT&T研究室--2000年3月にペンシルバニアのA.Keromytis U.について研究してください。

             DSA and RSA Key and Signature Encoding for the
                    KeyNote Trust Management System

基調信用マネージメントシステムのためのDSA、RSAキー、および署名コード化

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

Copyright(C)インターネット協会(2000)。 All rights reserved。

Abstract

要約

   This memo describes RSA and DSA key and signature encoding, and
   binary key encoding for version 2 of the KeyNote trust-management
   system.

このメモはKeyNote信用マネージメントシステムのバージョン2のためのRSA、DSAキー、および署名のコード化していて、2進の主要なコード化について説明します。

1.  Introduction

1. 序論

   KeyNote is a simple and flexible trust-management system designed to
   work well for a variety of large- and small-scale Internet-based
   applications.  It provides a single, unified language for both local
   policies and credentials.  KeyNote policies and credentials, called
   `assertions', contain predicates that describe the trusted actions
   permitted by the holders of specific public keys.  KeyNote assertions
   are essentially small, highly-structured programs.  A signed
   assertion, which can be sent over an untrusted network, is also
   called a `credential assertion'.  Credential assertions, which also
   serve the role of certificates, have the same syntax as policy
   assertions but are also signed by the principal delegating the trust.
   For more details on KeyNote, see [BFIK99].  This document assumes
   reader familiarity with the KeyNote system.

KeyNoteはさまざまな大きくて小規模のインターネットを利用するアプリケーションにうまくいくように設計された簡単でフレキシブルな信用マネージメントシステムです。 それはローカルの方針と信任状の両方に単一の、そして、統一された言語を提供します。 '主張'と呼ばれるKeyNote方針と信任状は特定の公開鍵の所有者によって可能にされた信じられた動作について説明する述部を含んでいます。 KeyNote主張は本質的には小さくて、非常に構造化されたプログラムです。また、サインされた主張(信頼されていないネットワークの上に送ることができる)は'信任している主張'と呼ばれます。 信任している主張(また、証明書の役割を受ける)は、方針主張と同じ構文を持っていますが、また、信用を代表として派遣する校長によってサインされます。 KeyNoteに関するその他の詳細に関しては、[BFIK99]を見てください。 このドキュメントはKeyNoteシステムへの読者親しみを仮定します。

   Cryptographic keys may be used in KeyNote to identify principals.  To
   facilitate interoperation between different implementations and to
   allow for maximal flexibility, keys must be converted to a normalized
   canonical form (depended on the public key algorithm used) for the
   purposes of any internal comparisons between keys.  For example, an

暗号化キーは、校長を特定するのにKeyNoteで使用されるかもしれません。 異なった実現の間でinteroperationを容易にして、最大限度の柔軟性を考慮するために、キーは間のどんな内部の比較の目的のためにも正常にされた標準形に変換された(使用される公開鍵アルゴリズムによる)キーでなければなりません。 例えば

Blaze, et al.                Informational                      [Page 1]

RFC 2792         Key and Signature Encoding for KeyNote       March 2000

炎、他 情報[1ページ]のRFC2792キーと基調のために2000年3月をコード化する署名

   RSA [RSA78] key may be encoded in base64 ASCII in one credential, and
   in hexadecimal ASCII in another.  A KeyNote implementation must
   internally convert the two encodings to a normalized form that allows
   for comparison between them.  Furthermore, the internal structure of
   an encoded key must be known for an implementation to correctly
   decode it.

RSA[RSA78]キーは1つの信任状のbase64ASCII、および別のものの16進ASCIIでコード化されるかもしれません。 KeyNote実現は内部的にそれらでの比較を考慮する正規形に2encodingsを変換しなければなりません。 その上、実現が正しくそれを解読するのをコード化されたキーの内部の構造を知らなければなりません。

   In some applications, other types of values, such as a passphrase or
   a random nonce, may be used as principal identifiers.  When these
   identifiers contain characters that may not appear in a string (as
   defined in [BFIK99]), a simple ASCII encoding is necessary to allow
   their use inside KeyNote assertions.  Note that if the identifier
   only contains characters that can appear in a string, it may be used
   as-is.  Naturally, such identifiers may not be used to sign an
   assertion, and thus no related signature encoding is defined.

使用目的によっては、他のタイプのパスフレーズか無作為の一回だけなどの値は主要な識別子として使用されるかもしれません。 これらの識別子がストリングに現れないかもしれないキャラクタを含むとき([BFIK99]で定義されるように)、簡単なASCIIコード化が、KeyNote主張で彼らの使用を許すのに必要です。 識別子がストリングに現れることができるキャラクタを含むだけであるなら、それがそのままで使用されるかもしれないことに注意してください。 当然、そのような識別子は主張にサインするのに使用されないかもしれません、そして、このようにして関係づけられなかった署名コード化は定義されます。

   This document specifies RSA and DSA [DSA94] key and signature
   encodings, and binary key encodings for use in KeyNote.

このドキュメントはRSA、DSA[DSA94]のキーと署名encodings、および2進の主要なencodingsをKeyNoteにおける使用に指定します。

2.  Key Normalized Forms

2. 主要な正規形

2.1  DSA Key Normalized Form

2.1 DSAの主要な正規形

   DSA keys in KeyNote are identified by four values:

KeyNoteのDSAキーは4つの値によって特定されます:

   - the public value, y
   - the p parameter
   - the q parameter
   - the g parameter

- 公共の値、y--pパラメタ--qパラメタ--gパラメタ

   Where the y, p, q, and g are the DSA parameters corresponding to the
   notation of [Sch96]. These four values together make up the DSA key
   normalized form used in KeyNote.  All DSA key comparisons in KeyNote
   occur between normalized forms.

y、p、q、およびgが[Sch96]の記法に対応するDSAパラメタであるところ。 一緒にこれらの4つの値がKeyNoteで使用されるDSAの主要な正規形を作ります。 KeyNoteでのすべてのDSAの主要な比較が正規形の間に起こります。

2.2  RSA Key Normalized Form

2.2 RSAの主要な正規形

   RSA keys in KeyNote are identified by two values:

KeyNoteのRSAキーは2つの値によって特定されます:

   - the public exponent
   - the modulus

- 公共の解説者--係数

   These two values together make up the RSA key normalized form used in
   KeyNote.  All RSA key comparisons in KeyNote occur between normalized
   forms.

一緒にこれらの2つの値がKeyNoteで使用されるRSAの主要な正規形を作ります。 KeyNoteでのすべてのRSAの主要な比較が正規形の間に起こります。

Blaze, et al.                Informational                      [Page 2]

RFC 2792         Key and Signature Encoding for KeyNote       March 2000

炎、他 情報[2ページ]のRFC2792キーと基調のために2000年3月をコード化する署名

2.3  Binary Identifier Normalized Form

2.3 2進の識別子正規形

   The normalized form of a Binary Identifier is the binary identifier's
   data.  Thus, Binary Identifier comparisons are essentially binary-
   string comparisons of the Identifier values.

Binary Identifierの正規形は2進の識別子のデータです。 したがって、Binary Identifier比較は本質的にはIdentifier値のバイナリーストリング比較です。

3.  Key Encoding

3. 主要なコード化

3.1  DSA Key Encoding

3.1 DSAの主要なコード化

   DSA keys in KeyNote are encoded as an ASN1 SEQUENCE of four ASN1
   INTEGER objects.  The four INTEGER objects are the public value and
   the p, q, and g parameters of the DSA key, in that order.

4ASN1 INTEGERのASN1 SEQUENCEが反対するようにKeyNoteのDSAキーはコード化されます。 4個のINTEGER物が、そのオーダーで主要なDSAの公共の値と、pと、qと、gパラメタです。

   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
   encoded (e.g., as a string of hex digits or base64 characters).

KeyNote信任状における使用のために、そして、ASN1 SEQUENCEはコード化された(例えば、一連の十六進法ケタかbase64キャラクタとして)ASCIIです。

   DSA keys encoded in this way in KeyNote must be identified by the
   "dsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
   "base64").  Other ASCII encoding schemes may be defined in the
   future.

KeyNoteでこのようにコード化されたDSAキーを特定しなければならない、「dsa-XXX:」 または、アルゴリズム名、(「十六進法」、「base64")。」そこではXXXはASCIIコード化です。 計画をコード化する他のASCIIは将来、定義されるかもしれません。

3.2  RSA Key Encoding

3.2 RSAの主要なコード化

   RSA keys in KeyNote are encoded as an ASN1 SEQUENCE of two ASN1
   INTEGER objects.  The two INTEGER objects are the public exponent and
   the modulus of the DSA key, in that order.

2ASN1 INTEGERのASN1 SEQUENCEが反対するようにKeyNoteのRSAキーはコード化されます。 2個のINTEGER物が、そのオーダーで主要なDSAの公共の解説者と係数です。

   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
   encoded (e.g., as a string of hex digits or base64 characters).

KeyNote信任状における使用のために、そして、ASN1 SEQUENCEはコード化された(例えば、一連の十六進法ケタかbase64キャラクタとして)ASCIIです。

   RSA keys encoded in this way in KeyNote must be identified by the
   "rsa-XXX:" algorithm name, where XXX is an ASCII encoding ("hex" or
   "base64").  Other ASCII encoding schemes may be defined in the
   future.

KeyNoteでこのようにコード化されたRSAキーを特定しなければならない、「rsa-XXX:」 または、アルゴリズム名、(「十六進法」、「base64")。」そこではXXXはASCIIコード化です。 計画をコード化する他のASCIIは将来、定義されるかもしれません。

3.3  Binary Identifier Encoding

3.3 2進の識別子コード化

   Binary Identifiers in KeyNote are assumed to have no internal
   encoding, and are treated as a sequence of binary digits.  The Binary
   Identifiers are ASCII-encoded, similarly to RSA or DSA keys.

KeyNoteの2進のIdentifiersは内部のコード化でないのを持っていると思われて、バイナリー・ディジットの系列として扱われます。 Binary IdentifiersはASCIIによって同様にコード化されています。RSAかDSAキーに。

   Binary Identifiers encoded in this way in KeyNote must be identified
   by the "binary-XXX:" algorithm name, where XXX is an ASCII encoding
   ("hex" or "base64").  Other ASCII encoding schemes may be defined in
   the future.

KeyNoteでこのようにコード化された2進のIdentifiersを特定しなければならない、「バイナリー-XXX:」 または、アルゴリズム名、(「十六進法」、「base64")。」そこではXXXはASCIIコード化です。 計画をコード化する他のASCIIは将来、定義されるかもしれません。

Blaze, et al.                Informational                      [Page 3]

RFC 2792         Key and Signature Encoding for KeyNote       March 2000

炎、他 情報[3ページ]のRFC2792キーと基調のために2000年3月をコード化する署名

4.  Signature Computation and Encoding

4. 署名計算とコード化

4.1  DSA Signature Computation and Encoding

4.1 DSA署名計算とコード化

   DSA signatures in KeyNote are computed over the assertion body
   (starting from the beginning of the first keyword, up to and
   including the newline character immediately before the "Signature:"
   keyword) and the signature algorithm name (including the trailing
   colon character, e.g., "sig-dsa-sha1-base64:")

KeyNoteのDSA署名が主張本体の上で計算される、(直前にニューラインキャラクタを含めて最初のキーワードの始まりから始める、「署名:」 キーワード、)、署名アルゴリズム名(例えば引きずっているコロンキャラクタを含んでいる、「sig-dsa-sha1-base64:」、)

   DSA signatures are then encoded as an ASN1 SEQUENCE of two ASN1
   INTEGER objects.  The two INTEGER objects are the r and s values of a
   DSA signature [Sch96], in that order.

そして、2ASN1 INTEGERのASN1 SEQUENCEが反対するようにDSA署名はコード化されます。 2個のINTEGER物が、そのオーダーで、DSA署名[Sch96]のrとs値です。

   For use in KeyNote credentials, the ASN1 SEQUENCE is then ASCII-
   encoded (as a string of hex digits or base64 characters).

KeyNote信任状における使用のために、そして、ASN1 SEQUENCEはコード化された(一連の十六進法ケタかbase64キャラクタとして)ASCIIです。

   DSA signatures encoded in this way in KeyNote must be identified by
   the "sig-dsa-XXX-YYY:" algorithm name, where XXX is a hash function
   name ("sha1", for the SHA1 [SHA1-95] hash function is currently the
   only hash function that may be used with DSA) and YYY is an ASCII
   encoding ("hex" or "base64").

KeyNoteでこのようにコード化されたDSA署名を特定しなければならない、「sig-dsa-XXX-YYY:」 または、XXXがハッシュ関数名であるアルゴリズム名、(「sha1"、SHA1[現在、SHA1-95] ハッシュ関数はDSAと共に使用されるかもしれない唯一のハッシュ関数である)とYYYがASCIIコード化である、(「十六進法」、「base64")、」

4.2  RSA Signature Computation and Encoding

4.2 RSA署名計算とコード化

   RSA signatures in KeyNote are computed over the assertion body
   (starting from the beginning of the first keyword, up to and
   including the newline character immediately before the "Signature:"
   keyword) and the signature algorithm name (including the trailing
   colon character, e.g., "sig-rsa-sha1-base64:")

KeyNoteのRSA署名が主張本体の上で計算される、(直前にニューラインキャラクタを含めて最初のキーワードの始まりから始める、「署名:」 キーワード、)、署名アルゴリズム名(例えば引きずっているコロンキャラクタを含んでいる、「sig-rsa-sha1-base64:」、)

   RSA signatures are then encoded as an ASN1 OCTET STRING object,
   containing the signature value.

そして、署名値を含んでいて、RSA署名はASN1 OCTET STRING物としてコード化されます。

   For use in KeyNote credentials, the ASN1 OCTET STRING is then ASCII-
   encoded (as a string of hex digits or base64 characters).

KeyNote信任状における使用のために、そして、ASN1 OCTET STRINGはコード化された(一連の十六進法ケタかbase64キャラクタとして)ASCIIです。

   RSA signatures encoded in this way in KeyNote must be identified by
   the "sig-rsa-XXX-YYY:" algorithm name, where XXX is a hash function
   name ("md5" or "sha1", for the MD5 [Riv92] and SHA1 [SHA1-95] hash
   algorithms respectively, may be used with RSA) and YYY is an ASCII
   encoding ("hex" or "base64").

KeyNoteでこのようにコード化されたRSA署名を特定しなければならない、「sig-rsa-XXX-YYY:」 または、または、XXXがハッシュ関数名であるアルゴリズム名、(「md5"、「MD5[Riv92]とSHA1[SHA1-95]がそれぞれアルゴリズムを論じ尽くして、RSAと共に使用されるかもしれないのでsha1"、YYYがASCIIコード化である、(「十六進法」、「base64")」

4.3  Binary Signature Computation and Encoding

4.3 2進の署名計算とコード化

   Binary Identifiers are unstructured sequences of binary digits, and
   are not associated with any cryptographic algorithm.  Thus, they may
   not be used to validate an assertion.

2進のIdentifiersはバイナリー・ディジットの不統一な系列であり、どんな暗号アルゴリズムにも関連づけられません。 したがって、それらは、主張を有効にするのに使用されないかもしれません。

Blaze, et al.                Informational                      [Page 4]

RFC 2792         Key and Signature Encoding for KeyNote       March 2000

炎、他 情報[4ページ]のRFC2792キーと基調のために2000年3月をコード化する署名

5.  Security Considerations

5. セキュリティ問題

   This document discusses the format of RSA and DSA keys and signatures
   and of Binary principal identifiers as used in KeyNote.  The security
   of KeyNote credentials utilizing such keys and credentials is
   directly dependent on the strength of the related public key
   algorithms.  On the security of KeyNote itself, see [BFIK99].

このドキュメントはKeyNoteで使用されるようにRSAと、DSAキーと署名とBinaryの主要な識別子の形式について議論します。 そのようなキーと信任状を利用するKeyNote信任状のセキュリティは直接関連する公開鍵アルゴリズムの強さに依存しています。KeyNote自身のセキュリティでは、[BFIK99]を見てください。

6.  IANA Considerations

6. IANA問題

   Per [BFIK99], IANA should provide a registry of reserved algorithm
   identifiers.  The following identifiers are reserved by this document
   as public key and binary identifier encodings:

[BFIK99]に従って、IANAは予約されたアルゴリズム識別子の登録を提供するはずです。 以下の識別子は公開鍵と2進の識別子encodingsとしてこのドキュメントによって予約されます:

   - "rsa-hex"
   - "rsa-base64"
   - "dsa-hex"
   - "dsa-base64"
   - "binary-hex"
   - "binary-base64"

- 「rsa-十六進法」--、「「dsa-十六進法」というrsa-base64"、「dsa-base64"--「2進の十六進法」--"binary-base64""

   The following identifiers are reserved by this document as signature
   encodings:

以下の識別子は署名encodingsとしてこのドキュメントによって予約されます:

   - "sig-rsa-md5-hex"
   - "sig-rsa-md5-base64"
   - "sig-rsa-sha1-hex"
   - "sig-rsa-sha1-base64"
   - "sig-dsa-sha1-hex"
   - "sig-dsa-sha1-base64"

- 「sig-rsa-md5-十六進法」--、「「sig-rsa-sha1-十六進法」というsig-rsa-md5-base64"、「sig-rsa-sha1-base64"--「sig-dsa-sha1-十六進法」--"sig-dsa-sha1-base64""

   Note that the double quotes are not part of the algorithm
   identifiers.

二重引用符がアルゴリズム識別子の一部でないことに注意してください。

7.  Acknowledgments

7. 承認

   This work was sponsored by the DARPA Information Assurance and
   Survivability (IA&S) program, under BAA 98-34.

この仕事はBAA98-34の下でDARPA情報保証とSurvivability(アイオワとS)プログラムで後援されました。

References

参照

   [Sch96]   Bruce Schneier, Applied Cryptography 2nd Edition, John
             Wiley & Sons, New York, NY, 1996.

[Sch96]ブルース・シュナイアー、暗号の第2適用された版、ジョン・ワイリー、および息子、ニューヨーク(ニューヨーク)1996。

   [BFIK99]  Blaze, M., Feigenbaum, J., Ioannidis, J. and A. Keromytis,
             "The KeyNote Trust-Management System Version 2", RFC 2704,
             September 1999.

[BFIK99] 炎とM.とファイゲンバウムとJ.とIoannidisとJ.とA.Keromytis、「基調信用管理システムバージョン2インチ、RFC2704、1999年9月。」

Blaze, et al.                Informational                      [Page 5]

RFC 2792         Key and Signature Encoding for KeyNote       March 2000

炎、他 情報[5ページ]のRFC2792キーと基調のために2000年3月をコード化する署名

   [DSA94]   NIST, FIPS PUB 186, "Digital Signature Standard", May 1994.

FIPSパブ186、「デジタル署名基準」という[DSA94]NISTは1994がそうするかもしれません。

   [Riv92]   Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
             April 1992.

[Riv92] Rivest、R.、「MD5メッセージダイジェストアルゴリズム」、RFC1321、1992年4月。

   [RSA78]   R. L. Rivest, A. Shamir, L. M. Adleman, "A Method for
             Obtaining Digital Signatures and Public-Key Cryptosystems",
             Communications of the ACM, v21n2. pp 120-126, February
             1978.

[RSA78] v21n2R.L.Rivest、A.シャミル、L.M.Adleman、「デジタル署名と公開カギ暗号系を得るための方法」、ACMのCommunications、pp120-126(1978年2月)。

   [SHA1-95] NIST, FIPS PUB 180-1, "Secure Hash Standard", April 1995.
             http://csrc.nist.gov/fips/fip180-1.txt (ascii)
             http://csrc.nist.gov/fips/fip180-1.ps  (postscript)

[SHA1-95]NIST、FIPSパブ180-1、「安全な細切れ肉料理規格」、4月1995日の http://csrc.nist.gov/fips/fip180-1.txt (ASCII) http://csrc.nist.gov/fips/fip180-1.ps (追伸)

Contacts

接触

   Comments about this document should be discussed on the
   keynote-users@nsa.research.att.com mailing list.

keynote-users@nsa.research.att.com メーリングリストでこのドキュメントの周りのコメントについて議論するべきです。

   Questions about this document can also be directed to the authors as
   a group at the keynote@research.att.com alias, or to the individual
   authors at:

また、 keynote@research.att.com 別名におけるグループとしての作者、または、以下の個々の作者にこのドキュメントに関する質問を向けることができます。

   Matt Blaze
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0000

マット炎のAT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932-0000

   EMail: mab@research.att.com

メール: mab@research.att.com

   John Ioannidis
   AT&T Labs - Research
   180 Park Avenue
   Florham Park, New Jersey 07932-0000

ジョンIoannidis AT&T研究室--研究180パーク・アベニューFlorham公園、ニュージャージー07932-0000

   EMail: ji@research.att.com

メール: ji@research.att.com

   Angelos D. Keromytis
   Distributed Systems Lab
   CIS Department, University of Pennsylvania
   200 S. 33rd Street
   Philadelphia, Pennsylvania  19104-6389

ペンシルバニア大学200秒間Angelos D.Keromytis分散システム研究室CIS部、第33通りフィラデルフィア、ペンシルバニア19104-6389

   EMail: angelos@cis.upenn.edu

メール: angelos@cis.upenn.edu

Blaze, et al.                Informational                      [Page 6]

RFC 2792         Key and Signature Encoding for KeyNote       March 2000

炎、他 情報[6ページ]のRFC2792キーと基調のために2000年3月をコード化する署名

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2000)。 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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   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機能のための基金は現在、インターネット協会によって提供されます。

Blaze, et al.                Informational                      [Page 7]

炎、他 情報[7ページ]