RFC5081 日本語訳

Network Working Group                               N. Mavrogiannopoulos
Request for Comments: 5081                                   Independent
Category: Experimental                                     November 2007

Mavrogiannopoulosがコメントのために要求するワーキンググループN.をネットワークでつないでください: 5081年の独立しているカテゴリ: 実験的な2007年11月

  Using OpenPGP Keys for Transport Layer Security (TLS) Authentication

トランスポート層セキュリティ(TLS)認証にOpenPGPキーを使用します。

Status of This Memo

このメモの状態

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard of any kind.
   Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。

Abstract

要約

   This memo proposes extensions to the Transport Layer Security (TLS)
   protocol to support the OpenPGP key format.  The extensions discussed
   here include a certificate type negotiation mechanism, and the
   required modifications to the TLS Handshake Protocol.

このメモは、OpenPGPが主要な形式であるとサポートするためにTransport Layer Security(TLS)プロトコルに拡大を提案します。 ここで議論した拡大は証明書タイプ交渉メカニズム、およびTLS Handshakeプロトコルへの必要な変更を含んでいます。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Changes to the Handshake Message Contents .......................2
      3.1. Client Hello ...............................................2
      3.2. Server Hello ...............................................3
      3.3. Server Certificate .........................................3
      3.4. Certificate Request ........................................4
      3.5. Client Certificate .........................................5
      3.6. Other Handshake Messages ...................................5
   4. Security Considerations .........................................5
   5. IANA Considerations .............................................6
   6. Acknowledgements ................................................6
   7. References ......................................................6
      7.1. Normative References .......................................6
      7.2. Informative References .....................................7

1. 序論…2 2. 用語…2 3. 握手メッセージ内容への変化…2 3.1. クライアント、こんにちは…2 3.2. サーバ、こんにちは…3 3.3. サーバ証明書…3 3.4. 要求を証明してください…4 3.5. クライアント証明書…5 3.6. 他の握手メッセージ…5 4. セキュリティ問題…5 5. IANA問題…6 6. 承認…6 7. 参照…6 7.1. 標準の参照…6 7.2. 有益な参照…7

Mavrogiannopoulos             Experimental                      [Page 1]

RFC 5081                   Using OpenPGP Keys              November 2007

キー2007年11月にOpenPGPを使用するMavrogiannopoulosの実験的な[1ページ]RFC5081

1.  Introduction

1. 序論

   The IETF has two sets of standards for public key certificates, one
   set for use of X.509 certificates [PKIX] and one for OpenPGP
   certificates [OpenPGP].  At the time of writing, TLS [TLS] standards
   are defined to use only X.509 certificates.  This document specifies
   a way to negotiate use of OpenPGP certificates for a TLS session, and
   specifies how to transport OpenPGP certificates via TLS.  The
   proposed extensions are backward compatible with the current TLS
   specification, so that existing client and server implementations
   that make use of X.509 certificates are not affected.

IETFには、公開鍵証明書のための2セットの規格、X.509証明書の使用のための1セット[PKIX]、およびOpenPGP証明書のための1つ[OpenPGP]があります。 これを書いている時点で、TLS[TLS]規格は、X.509証明書だけを使用するために定義されます。 このドキュメントは、OpenPGP証明書のTLSセッションの使用を交渉する方法を指定して、TLSを通してOpenPGP証明書を輸送する方法を指定します。 提案された拡大が現在のTLS仕様と互換性があった状態で後方であるので、X.509証明書を利用するその既存のクライアントとサーバ実装は影響を受けません。

2.  Terminology

2. 用語

   The term "OpenPGP key" is used in this document as in the OpenPGP
   specification [OpenPGP].  We use the term "OpenPGP certificate" to
   refer to OpenPGP keys that are enabled for authentication.

「OpenPGPキー」という用語はOpenPGP仕様[OpenPGP]のように本書では使用されます。 私たちは、認証のために可能にされるOpenPGPキーについて言及するのに「OpenPGP証明書」という用語を使用します。

   This document uses the same notation and terminology used in the TLS
   Protocol specification [TLS].

このドキュメントはTLSプロトコル仕様[TLS]で使用される同じ記法と用語を使用します。

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

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

3.  Changes to the Handshake Message Contents

3. 握手メッセージ内容への変化

   This section describes the changes to the TLS handshake message
   contents when OpenPGP certificates are to be used for authentication.

OpenPGP証明書が認証に使用されることであるときに、このセクションはTLS握手メッセージ内容に変化を説明します。

3.1.  Client Hello

3.1. クライアント、こんにちは。

   In order to indicate the support of multiple certificate types,
   clients MUST include an extension of type "cert_type" (see Section 5)
   to the extended client hello message.  The hello extension mechanism
   is described in [TLSEXT].

クライアントが複数の証明書タイプのサポートを示すためにタイプ「本命_タイプ」(セクション5を見る)の拡大を拡張クライアントに入れなければならない、こんにちは、メッセージ。 こんにちは、拡張機能は[TLSEXT]で説明されます。

   This extension carries a list of supported certificate types the
   client can use, sorted by client preference.  This extension MUST be
   omitted if the client only supports X.509 certificates.  The
   "extension_data" field of this extension contains a
   CertificateTypeExtension structure.

クライアント好みによって分類されて、この拡大はクライアントが使用できるサポートしている証明書タイプのリストを運びます。 クライアントがX.509に証明書を支えるだけであるなら、この拡大を省略しなければなりません。 この拡大の「拡大_データ」分野はCertificateTypeExtension構造を含んでいます。

Mavrogiannopoulos             Experimental                      [Page 2]

RFC 5081                   Using OpenPGP Keys              November 2007

キー2007年11月にOpenPGPを使用するMavrogiannopoulosの実験的な[2ページ]RFC5081

      enum { client, server } ClientOrServerExtension;

クライアント、サーバをenumする、ClientOrServerExtension。

      enum { X.509(0), OpenPGP(1), (255) } CertificateType;

X.509(0)、OpenPGP(1)、(255)をenumする、CertificateType。

      struct {
         select(ClientOrServerExtension) {
            case client:
               CertificateType certificate_types<1..2^8-1>;
            case server:
               CertificateType certificate_type;
         }
      } CertificateTypeExtension;

structに、ケースクライアント: サーバをケースに入れてください: CertificateTypeが_タイプを証明するというCertificateType証明書_タイプ<1..2^8-1>を選択してください、(ClientOrServerExtension)CertificateTypeExtension。

   No new cipher suites are required to use OpenPGP certificates.  All
   existing cipher suites that support a compatible, with the key, key
   exchange method can be used in combination with OpenPGP certificates.

どんな新しい暗号スイートもOpenPGP証明書を使用する必要はありません。 OpenPGP証明書と組み合わせてキーとのコンパチブル、そして、主要な交換がメソッドであるとサポートするすべての既存の暗号スイートは使用できます。

3.2.  Server Hello

3.2. サーバ、こんにちは。

   If the server receives a client hello that contains the "cert_type"
   extension and chooses a cipher suite that requires a certificate,
   then two outcomes are possible.  The server MUST either select a
   certificate type from the certificate_types field in the extended
   client hello or terminate the connection with a fatal alert of type
   "unsupported_certificate".

サーバがクライアントを受ける、こんにちは、当時の2つの結果がそれが「本命_タイプ」拡大を含んでいて、証明書を必要とする暗号スイートを選ぶのが可能です。 サーバは証明書を選択しなければなりません。_タイプが拡張クライアントでさばく証明書からこんにちはをタイプするか、または「サポートされない_は証明する」タイプの致命的な警戒との関係を終えてください。

   The certificate type selected by the server is encoded in a
   CertificateTypeExtension structure, which is included in the extended
   server hello message using an extension of type "cert_type".  Servers
   that only support X.509 certificates MAY omit including the
   "cert_type" extension in the extended server hello.

サーバによって選ばれた証明書タイプが拡張サーバに含まれているCertificateTypeExtension構造でコード化される、こんにちは、タイプ「本命_タイプ」の拡張子を使用するメッセージ。 X.509が証明書であるとサポートするだけであるサーバは、拡張サーバに「本命_タイプ」拡大を含んでいるのを忘れるかもしれません。こんにちは。

3.3.  Server Certificate

3.3. サーバ証明書

   The contents of the certificate message sent from server to client
   and vice versa are determined by the negotiated certificate type and
   the selected cipher suite's key exchange algorithm.

証明書メッセージの内容は、交渉された証明書タイプと選択された暗号スイートの主要な交換アルゴリズムでサーバからクライアントに送って、逆もまた同様に決定しています。

   If the OpenPGP certificate type is negotiated, then it is required to
   present an OpenPGP certificate in the certificate message.  The
   certificate must contain a public key that matches the selected key
   exchange algorithm, as shown below.

OpenPGP証明書タイプが交渉されるなら、それが、証明書メッセージのOpenPGP証明書を提示するのに必要です。 証明書は以下に示されるように選択された主要な交換アルゴリズムに合っている公開鍵を含まなければなりません。

Mavrogiannopoulos             Experimental                      [Page 3]

RFC 5081                   Using OpenPGP Keys              November 2007

キー2007年11月にOpenPGPを使用するMavrogiannopoulosの実験的な[3ページ]RFC5081

      Key Exchange Algorithm  OpenPGP Certificate Type

主要な交換アルゴリズムOpenPGP証明書タイプ

      RSA                     RSA public key that can be used for
                              encryption.

暗号化に使用できるRSA RSA公開鍵。

      DHE_DSS                 DSS public key that can be used for
                              authentication.

認証に使用できるDHE_DSS DSS公開鍵。

      DHE_RSA                 RSA public key that can be used for
                              authentication.

認証に使用できるDHE_RSA RSA公開鍵。

   An OpenPGP certificate appearing in the certificate message is sent
   using the binary OpenPGP format.  The certificate MUST contain all
   the elements required by Section 11.1 of [OpenPGP].

証明書メッセージに現れるOpenPGP証明書に2進のOpenPGP形式を使用させます。 証明書は[OpenPGP]のセクション11.1によって必要とされたすべての要素を含まなければなりません。

   The option is also available to send an OpenPGP fingerprint, instead
   of sending the entire certificate.  The process of fingerprint
   generation is described in Section 12.2 of [OpenPGP].  The peer shall
   respond with a "certificate_unobtainable" fatal alert if the
   certificate with the given fingerprint cannot be found.  The
   "certificate_unobtainable" fatal alert is defined in Section 4 of
   [TLSEXT].

また、オプションも、全体の証明書を送ることの代わりにOpenPGP指紋を送るために利用可能です。 指紋世代の経過は[OpenPGP]のセクション12.2で説明されます。 与えられた指紋がある証明書を見つけることができないなら、同輩は致命的な「証明書_入手不可能な」警戒で応じるものとします。 致命的な「証明書_入手不可能な」警戒は[TLSEXT]のセクション4で定義されます。

      enum {
           cert_fingerprint (0), cert (1), (255)
      } OpenPGPCertDescriptorType;

本命_指紋(0)、本命(1)、(255)をenumする、OpenPGPCertDescriptorType。

      opaque OpenPGPCertFingerprint<16..20>;

OpenPGPCertFingerprint<16について不透明にしてください。20>。

      opaque OpenPGPCert<0..2^24-1>;

OpenPGPCert<0について不透明にしてください。2^24-1>。

      struct {
           OpenPGPCertDescriptorType descriptorType;
           select (descriptorType) {
                case cert_fingerprint: OpenPGPCertFingerprint;
                case cert: OpenPGPCert;
           }
      } Certificate;

OpenPGPCertDescriptorType descriptorType; ケース本命_指紋: OpenPGPCertFingerprintケース本命: (OpenPGPCert)を選択するのを(descriptorType)structする、証明書。

3.4.  Certificate Request

3.4. 証明書要求

   The semantics of this message remain the same as in the TLS
   specification.  However, if this message is sent, and the negotiated
   certificate type is OpenPGP, the "certificate_authorities" list MUST
   be empty.

このメッセージの意味論はTLS仕様のように同じままで残っています。 しかしながら、このメッセージを送って、交渉された証明書タイプがOpenPGPであるなら、「証明書_当局」リストは空であるに違いありません。

Mavrogiannopoulos             Experimental                      [Page 4]

RFC 5081                   Using OpenPGP Keys              November 2007

キー2007年11月にOpenPGPを使用するMavrogiannopoulosの実験的な[4ページ]RFC5081

3.5.  Client Certificate

3.5. クライアント証明書

   This message is only sent in response to the certificate request
   message.  The client certificate message is sent using the same
   formatting as the server certificate message, and it is also required
   to present a certificate that matches the negotiated certificate
   type.  If OpenPGP certificates have been selected and no certificate
   is available from the client, then a certificate structure that
   contains an empty OpenPGPCert vector MUST be sent.  The server SHOULD
   respond with a "handshake_failure" fatal alert if client
   authentication is required.

証明書要求メッセージに対応してこのメッセージを送るだけです。 サーバ証明書メッセージと同じ形式を使用することでクライアント証明書メッセージを送ります、そして、また、交渉された証明書タイプに合っている証明書を提示するためにそれを必要とします。 OpenPGP証明書が選択されて、どんな証明書もクライアントから利用可能でないなら、空のOpenPGPCertベクトルを含む証明書構造を送らなければなりません。 クライアント認証が必要であるなら、サーバSHOULDは「握手_失敗」致命的な警戒で応じます。

3.6.  Other Handshake Messages

3.6. 他の握手メッセージ

   All the other handshake messages are identical to the TLS
   specification.

他のすべての握手メッセージがTLS仕様と同じです。

4.  Security Considerations

4. セキュリティ問題

   All security considerations discussed in [TLS], [TLSEXT], and
   [OpenPGP] apply to this document.  Considerations about the use of
   the web of trust or identity and certificate verification procedure
   are outside the scope of this document.  These are considered issues
   to be handled by the application layer protocols.

[TLS]、[TLSEXT]、および[OpenPGP]で議論したすべてのセキュリティ問題がこのドキュメントに適用されます。 このドキュメントの範囲の外に信頼かアイデンティティと証明書検証手続のウェブの使用に関する問題があります。 これらは、応用層プロトコルによって扱われるために問題であると考えられます。

   The protocol for certificate type negotiation is identical in
   operation to ciphersuite negotiation of the [TLS] specification with
   the addition of default values when the extension is omitted.  Since
   those omissions have a unique meaning and the same protection is
   applied to the values as with ciphersuites, it is believed that the
   security properties of this negotiation are the same as with
   ciphersuite negotiation.

拡大が省略されるとき、証明書タイプ交渉のためのプロトコルは稼働中でありデフォルト値の追加との[TLS]仕様のciphersuite交渉と同じです。 それらの省略にはユニークな意味があって、同じ保護がciphersuitesのように値に適用されるので、この交渉のセキュリティの特性がciphersuite交渉と同じであると信じられています。

   When using OpenPGP fingerprints instead of the full certificates, the
   discussion in Section 6.3 of [TLSEXT] for "Client Certificate URLs"
   applies, especially when external servers are used to retrieve keys.
   However, a major difference is that although the
   "client_certificate_url" extension allows identifying certificates
   without including the certificate hashes, this is not possible in the
   protocol proposed here.  In this protocol, the certificates, when not
   sent, are always identified by their fingerprint, which serves as a
   cryptographic hash of the certificate (see Section 12.2 of
   [OpenPGP]).

完全な証明書の代わりにOpenPGP指紋を使用するとき、「クライアント証明書URL」のための[TLSEXT]のセクション6.3における議論は適用されます、特に外部のサーバがキーを検索するのに使用されるとき。 しかしながら、主要な違いは「クライアント_証明書_url」拡大で証明書ハッシュを含んでいなくて証明書を特定しますが、これがここで提案されたプロトコルでは可能でないということです。 このプロトコルで、送られないと、証明書は彼らの指紋によっていつも特定されます([OpenPGP]のセクション12.2を見てください)。(それは、証明書の暗号のハッシュとして機能します)。

   The information that is available to participating parties and
   eavesdroppers (when confidentiality is not available through a
   previous handshake) is the number and the types of certificates they
   hold, plus the contents of certificates.

参加団体と立ち聞きする者(秘密性が前の握手で利用可能でないときに)にとって、利用可能な情報は、数と、それらが保持する証明書のタイプと、証明書のコンテンツです。

Mavrogiannopoulos             Experimental                      [Page 5]

RFC 5081                   Using OpenPGP Keys              November 2007

キー2007年11月にOpenPGPを使用するMavrogiannopoulosの実験的な[5ページ]RFC5081

5.  IANA Considerations

5. IANA問題

   This document defines a new TLS extension, "cert_type", assigned a
   value of 9 from the TLS ExtensionType registry defined in [TLSEXT].
   This value is used as the extension number for the extensions in both
   the client hello message and the server hello message.  The new
   extension type is used for certificate type negotiation.

このドキュメントは新しいTLS拡張子を定義して、「本命_タイプ」は[TLSEXT]で定義されたTLS ExtensionType登録から9の値を割り当てました。 この値が両方のクライアントでの拡大に内線電話番号として使用される、こんにちは、メッセージとサーバ、こんにちは、メッセージ。 新しい拡大タイプは証明書タイプ交渉に使用されます。

   The "cert_type" extension contains an 8-bit CertificateType field,
   for which a new registry, named "TLS Certificate Types", is
   established in this document, to be maintained by IANA.  The registry
   is segmented in the following way:

「本命_タイプ」拡大は8ビットのCertificateType分野を含んでいます。(IANAによって維持されるように、「TLS証明書タイプ」という新しい登録はそれにおいて本書では確立されます)。 登録は以下の方法で区分されます:

   1.  Values 0 (X.509) and 1 (OpenPGP) are defined in this document.

1. 値0(X.509)と1(OpenPGP)は本書では定義されます。

   2.  Values from 2 through 223 decimal inclusive are assigned via IETF
       Consensus [RFC2434].

2. 2〜223小数から包括的な値はIETF Consensus[RFC2434]を通して割り当てられます。

   3.  Values from 224 decimal through 255 decimal inclusive are
       reserved for Private Use [RFC2434].

3. 224小数から255小数まで包括的な値は兵士のUse[RFC2434]のために予約されます。

6.  Acknowledgements

6. 承認

   This document was based on earlier work made by Will Price and
   Michael Elkins.

このドキュメントはウィルPriceとマイケル・エルキンズによってされた以前の仕事に基づきました。

   The author wishes to thank Werner Koch, David Taylor, Timo Schulz,
   Pasi Eronen, Jon Callas, Stephen Kent, Robert Sparks, and Hilarie
   Orman for their suggestions on improving this document.

作者はこのドキュメントを改良するときの彼らの提案についてヴェルナー・コッホ、デヴィッド・テイラー、ティモ・シュルツ、パシEronen、ジョン・カラス、スティーブン・ケント、ロバート・スパークス、およびHilarie Ormanに感謝したがっています。

7.  References

7. 参照

7.1.  Normative References

7.1. 引用規格

   [TLS]      Dierks, T. and E. Rescorla, "The TLS Protocol Version
              1.1", RFC 4346, April 2006.

[TLS] Dierks、T.、およびE.レスコラ、「TLSは2006年4月にバージョン1.1インチ、RFC4346について議定書の中で述べます」。

   [OpenPGP]  Callas, J., Donnerhacke, L., Finey, H., Shaw, D., and R.
              Thayer, "OpenPGP Message Format", RFC 4880, November 2007.

[OpenPGP] カラスとJ.とDonnerhackeとL.とFineyとH.とショー、D.とR.セイヤー、「OpenPGPメッセージ・フォーマット」、RFC4880、2007年11月。

   [TLSEXT]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

[TLSEXT]ブレーク-ウィルソン、S.、ニストロム、M.、Hopwood(D.、ミッケルセン、J.、およびT.ライト)は「層のセキュリティ(TLS)拡大を輸送します」、RFC4366、2006年4月。

   [RFC2434]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", RFC 2434,
              October 1998.

[RFC2434] NartenとT.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」、RFC2434、1998年10月。

Mavrogiannopoulos             Experimental                      [Page 6]

RFC 5081                   Using OpenPGP Keys              November 2007

キー2007年11月にOpenPGPを使用するMavrogiannopoulosの実験的な[6ページ]RFC5081

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

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

7.2.  Informative References

7.2. 有益な参照

   [PKIX]     Housley, R., Ford, W., Polk, W., and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and
              Certificate Revocation List (CRL) Profile", RFC 3280,
              April 2002.

[PKIX] Housley、R.、フォード、W.、ポーク、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。

Author's Address

作者のアドレス

   Nikos Mavrogiannopoulos
   Independent
   Arkadias 8
   Halandri, Attiki  15234
   Greece

ニコスMavrogiannopoulosの独立しているArkadias8Halandri、Attiki15234ギリシア

   EMail: nmav@gnutls.org
   URI:   http://www.gnutls.org/

メール: nmav@gnutls.org ユリ: http://www.gnutls.org/

Mavrogiannopoulos             Experimental                      [Page 7]

RFC 5081                   Using OpenPGP Keys              November 2007

キー2007年11月にOpenPGPを使用するMavrogiannopoulosの実験的な[7ページ]RFC5081

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The IETF Trust (2007).

IETFが信じる著作権(C)(2007)。

   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, THE IETF TRUST 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.

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

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に情報を扱ってください。

Mavrogiannopoulos             Experimental                      [Page 8]

Mavrogiannopoulos実験的です。[8ページ]