RFC2818 日本語訳

Network Working Group                                       E. Rescorla
Request for Comments: 2818                                   RTFM, Inc.
Category: Informational                                        May 2000

コメントを求めるワーキンググループE.レスコラの要求をネットワークでつないでください: 2818年のRTFM Inc.カテゴリ: 情報の2000年5月

                             HTTP Over TLS

TLSの上のHTTP

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 how to use TLS to secure HTTP connections over
   the Internet. Current practice is to layer HTTP over SSL (the
   predecessor to TLS), distinguishing secured traffic from insecure
   traffic by the use of a different server port. This document
   documents that practice using TLS. A companion document describes a
   method for using HTTP/TLS over the same port as normal HTTP
   [RFC2817].

このメモはHTTPがインターネットの上の関係であると機密保護するのにTLSを使用する方法を説明します。 現在の習慣はSSL(TLSへの前任者)の上でHTTPを層にすることになっています、不安定なトラフィックと異なったサーバポートの使用で機密保護しているトラフィックを区別して。 このドキュメントは、TLSを使用することでその習慣を記録します。 仲間ドキュメントは正常なHTTP[RFC2817]と同じポートの上でHTTP/TLSを使用するためのメソッドを説明します。

Table of Contents

目次

   1. Introduction  . . . . . . . . . . . . . . . . . . . . . . 2
   1.1. Requirements Terminology  . . . . . . . . . . . . . . . 2
   2. HTTP Over TLS . . . . . . . . . . . . . . . . . . . . . . 2
   2.1. Connection Initiation . . . . . . . . . . . . . . . . . 2
   2.2. Connection Closure  . . . . . . . . . . . . . . . . . . 2
   2.2.1. Client Behavior . . . . . . . . . . . . . . . . . . . 3
   2.2.2. Server Behavior . . . . . . . . . . . . . . . . . . . 3
   2.3. Port Number . . . . . . . . . . . . . . . . . . . . . . 4
   2.4. URI Format  . . . . . . . . . . . . . . . . . . . . . . 4
   3. Endpoint Identification . . . . . . . . . . . . . . . . . 4
   3.1. Server Identity . . . . . . . . . . . . . . . . . . . . 4
   3.2. Client Identity . . . . . . . . . . . . . . . . . . . . 5
   References . . . . . . . . . . . . . . . . . . . . . . . . . 6
   Security Considerations  . . . . . . . . . . . . . . . . . . 6
   Author's Address . . . . . . . . . . . . . . . . . . . . . . 6
   Full Copyright Statement . . . . . . . . . . . . . . . . . . 7

1. 序論. . . . . . . . . . . . . . . . . . . . . . 2 1.1。 要件用語. . . . . . . . . . . . . . . 2 2 TLS. . . . . . . . . . . . . . . . . . . . . . 2 2.1の上のHTTP。 接続開始. . . . . . . . . . . . . . . . . 2 2.2。 接続閉鎖. . . . . . . . . . . . . . . . . . 2 2.2.1。 クライアントの振舞い. . . . . . . . . . . . . . . . . . . 3 2.2.2。 サーバの振舞い. . . . . . . . . . . . . . . . . . . 3 2.3。 No.. . . . . . . . . . . . . . . . . . . . . . 4 2.4を移植してください。 URI形式. . . . . . . . . . . . . . . . . . . . . . 4 3。 終点識別. . . . . . . . . . . . . . . . . 4 3.1。 サーバのアイデンティティ. . . . . . . . . . . . . . . . . . . . 4 3.2。 クライアントのアイデンティティ. . . . . . . . . . . . . . . . . . . . 5参照. . . . . . . . . . . . . . . . . . . . . . . . . 6セキュリティ問題. . . . . . . . . . . . . . . . . . 6作者のアドレスの.6の完全な著作権宣言文. . . . . . . . . . . . . . . . . . 7

Rescorla                     Informational                      [Page 1]

RFC 2818                     HTTP Over TLS                      May 2000

TLS2000年5月の間のレスコラ情報[1ページ]のRFC2818HTTP

1.  Introduction

1. 序論

   HTTP [RFC2616] was originally used in the clear on the Internet.
   However, increased use of HTTP for sensitive applications has
   required security measures. SSL, and its successor TLS [RFC2246] were
   designed to provide channel-oriented security. This document
   describes how to use HTTP over TLS.

HTTP[RFC2616]は元々、インターネットに関する明確で使用されました。 しかしながら、HTTPの敏感なアプリケーションの増強された使用は安全策を必要としました。 SSL、および後継者TLS[RFC2246]は、チャンネル指向のセキュリティを提供するように設計されました。 このドキュメントはTLSの上でHTTPを使用する方法を説明します。

1.1.  Requirements Terminology

1.1. 要件用語

   Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT" and
   "MAY" that appear in this document are to be interpreted as described
   in [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHOULD"、「」 現れる「5月」は中[RFC2119]で説明されるように本書では解釈されることになっているべきです。

2.  HTTP Over TLS

2. TLSの上のHTTP

   Conceptually, HTTP/TLS is very simple. Simply use HTTP over TLS
   precisely as you would use HTTP over TCP.

概念的に、HTTP/TLSは非常に簡単です。 まさにTCPの上でHTTPを使用するようにTLSの上で単にHTTPを使用してください。

2.1.  Connection Initiation

2.1. 接続開始

   The agent acting as the HTTP client should also act as the TLS
   client.  It should initiate a connection to the server on the
   appropriate port and then send the TLS ClientHello to begin the TLS
   handshake. When the TLS handshake has finished. The client may then
   initiate the first HTTP request.  All HTTP data MUST be sent as TLS
   "application data".  Normal HTTP behavior, including retained
   connections should be followed.

また、HTTPクライアントとして務めているエージェントはTLSクライアントとして務めるべきです。 それは、適切なポートの上のサーバに接続を開始して、次に、TLS握手を始めるためにTLS ClientHelloを送るべきです。 TLS握手が終わったとき。 そして、クライアントは最初のHTTP要求を開始するかもしれません。 TLS「アプリケーションデータ」としてすべてのHTTPデータを送らなければなりません。 通常のHTTPの振舞い、保有された接続を含んでいるということになられるべきです。

2.2.  Connection Closure

2.2. 接続閉鎖

   TLS provides a facility for secure connection closure. When a valid
   closure alert is received, an implementation can be assured that no
   further data will be received on that connection.  TLS
   implementations MUST initiate an exchange of closure alerts before
   closing a connection. A TLS implementation MAY, after sending a
   closure alert, close the connection without waiting for the peer to
   send its closure alert, generating an "incomplete close".  Note that
   an implementation which does this MAY choose to reuse the session.
   This SHOULD only be done when the application knows (typically
   through detecting HTTP message boundaries) that it has received all
   the message data that it cares about.

TLSは安全な接続閉鎖に施設を提供します。 有効な閉鎖警戒が受け取られているとき、詳しいデータが全くその接続のときに受け取られないことを実装を保証できます。 接続を終える前に、TLS実装は閉鎖警戒の交換を起こさなければなりません。 同輩が閉鎖警戒を送るのを待たない、閉鎖警戒を送った後にTLS実装は接続を終えるかもしれません、「不完全な閉鎖」を生成して。 これをする実装が、セッションを再利用するのを選ぶかもしれないことに注意してください。 このSHOULD、アプリケーションが、心配するすべてのメッセージデータを受け取ったのを知っていた(通常、HTTPメッセージ限界を検出することで)ら単にしてください。

   As specified in [RFC2246], any implementation which receives a
   connection close without first receiving a valid closure alert (a
   "premature close") MUST NOT reuse that session.  Note that a
   premature close does not call into question the security of the data
   already received, but simply indicates that subsequent data might

[RFC2246]で指定されるように、近くで最初に有効な閉鎖警戒(「時期尚早な閉鎖」)を受けないで接続を受けるどんな実装もそのセッションを再利用してはいけません。 時期尚早な閉鎖が、既に受け取られたデータのセキュリティを疑いませんが、順次データがそうするかもしれないのを単に示すことに注意してください。

Rescorla                     Informational                      [Page 2]

RFC 2818                     HTTP Over TLS                      May 2000

TLS2000年5月の間のレスコラ情報[2ページ]のRFC2818HTTP

   have been truncated. Because TLS is oblivious to HTTP
   request/response boundaries, it is necessary to examine the HTTP data
   itself (specifically the Content-Length header) to determine whether
   the truncation occurred inside a message or between messages.

先端を切られてください、そうした。 TLSがHTTP要求/応答境界に気づかないので、トランケーションがメッセージの中、または、メッセージの間に起こったかどうか決定するために、HTTPデータ(明確にContent-長さのヘッダー)自体を調べるのが必要です。

2.2.1.  Client Behavior

2.2.1. クライアントの振舞い

   Because HTTP uses connection closure to signal end of server data,
   client implementations MUST treat any premature closes as errors and
   the data received as potentially truncated.  While in some cases the
   HTTP protocol allows the client to find out whether truncation took
   place so that, if it received the complete reply, it may tolerate
   such errors following the principle to "[be] strict when sending and
   tolerant when receiving" [RFC1958], often truncation does not show in
   the HTTP protocol data; two cases in particular deserve special note:

HTTPがサーバデータの終わりに合図するのに接続閉鎖を使用するので、クライアント実装はどんな時期尚早な閉鎖も誤りとして扱わなければなりません、そして、データは潜在的に先端を切られるように受信されました。 中でHTTPプロトコルがトランケーションが行われたかどうかからそうがそれであることがわかるのをクライアントを許容するいくつかのケースをゆったり過ごしてください、完全な回答を受け取りました、と原則に従うそのような誤りを許容するかもしれない、「[あります] 」 [RFC1958]を受けると、発信すると厳しくて、許容性があります、しばしば、トランケーションはHTTPプロトコルデータで目立つというわけではありません。 2つのケースが特別な注意に特に値します:

     A HTTP response without a Content-Length header. Since data length
     in this situation is signalled by connection close a premature
     close generated by the server cannot be distinguished from a
     spurious close generated by an attacker.

Content-長さのヘッダーのないHTTP応答。 この状況におけるデータの長さが接続によって示されるので、近くでは、攻撃者によって生成された偽りの閉鎖とサーバによって生成された時期尚早な閉鎖は区別できません。

     A HTTP response with a valid Content-Length header closed before
     all data has been read. Because TLS does not provide document
     oriented protection, it is impossible to determine whether the
     server has miscomputed the Content-Length or an attacker has
     truncated the connection.

すべてのデータが読まれる前に有効なContent-長さのヘッダーによるHTTP応答は終えられました。 TLSが提供しないので、指向の保護を記録してください、サーバがContent-長さをmiscomputedしたかどうか決定するのが不可能であるか、または攻撃者は接続に先端を切らせました。

   There is one exception to the above rule. When encountering a
   premature close, a client SHOULD treat as completed all requests for
   which it has received as much data as specified in the Content-Length
   header.

上の規則への1つの例外があります。 時期尚早な閉鎖に遭遇するとき、SHOULDが扱うクライアントはそれがContent-長さのヘッダーで指定されるのと同じくらい多くのデータを受け取ったすべての要求を終了しました。

   A client detecting an incomplete close SHOULD recover gracefully.  It
   MAY resume a TLS session closed in this fashion.

SHOULDが優雅に回復する不完全な閉鎖を検出するクライアント。 それはこんなやり方で終えられたTLSセッションを再開するかもしれません。

   Clients MUST send a closure alert before closing the connection.
   Clients which are unprepared to receive any more data MAY choose not
   to wait for the server's closure alert and simply close the
   connection, thus generating an incomplete close on the server side.

接続を終える前に、クライアントは閉鎖警戒を送らなければなりません。 それ以上のデータを受け取るために用意ができていていないクライアントは、サーバの閉鎖警戒を待って、接続を絶対に終えないのを選ぶかもしれません、その結果、サーバ側で不完全な閉鎖を生成します。

2.2.2.  Server Behavior

2.2.2. サーバの振舞い

   RFC 2616 permits an HTTP client to close the connection at any time,
   and requires servers to recover gracefully.  In particular, servers
   SHOULD be prepared to receive an incomplete close from the client,
   since the client can often determine when the end of server data is.
   Servers SHOULD be willing to resume TLS sessions closed in this
   fashion.

RFC2616は、HTTPクライアントがいつでも接続を終えるのを可能にして、優雅に回復するためにサーバを必要とします。 特定のサーバSHOULDでは、クライアントから不完全な閉鎖を受けるように用意してください、クライアントが、しばしばサーバデータの終わりがいつであるかを決心できるので。 サーバは履歴書TLSセッションまでこんなやり方で閉じましたSHOULDが望んでいる。

Rescorla                     Informational                      [Page 3]

RFC 2818                     HTTP Over TLS                      May 2000

TLS2000年5月の間のレスコラ情報[3ページ]のRFC2818HTTP

   Implementation note: In HTTP implementations which do not use
   persistent connections, the server ordinarily expects to be able to
   signal end of data by closing the connection. When Content-Length is
   used, however, the client may have already sent the closure alert and
   dropped the connection.

実装注意: パーシステントコネクションを使用しないHTTP実装では、通常、サーバは、接続を終えることによってデータの終わりに合図できると予想します。 Content-長さが使用されているとき、しかしながら、クライアントは、既に閉鎖警戒を送って、接続を下げたかもしれません。

   Servers MUST attempt to initiate an exchange of closure alerts with
   the client before closing the connection. Servers MAY close the
   connection after sending the closure alert, thus generating an
   incomplete close on the client side.

サーバは、接続を終える前のクライアントとの閉鎖警戒の交換を起こすのを試みなければなりません。 閉鎖警戒を送って、その結果、クライアント側で不完全な閉鎖を生成した後に、サーバは接続を終えるかもしれません。

2.3.  Port Number

2.3. ポートナンバー

   The first data that an HTTP server expects to receive from the client
   is the Request-Line production. The first data that a TLS server (and
   hence an HTTP/TLS server) expects to receive is the ClientHello.
   Consequently, common practice has been to run HTTP/TLS over a
   separate port in order to distinguish which protocol is being used.
   When HTTP/TLS is being run over a TCP/IP connection, the default port
   is 443. This does not preclude HTTP/TLS from being run over another
   transport. TLS only presumes a reliable connection-oriented data
   stream.

HTTPサーバがクライアントから受け取ると予想する最初のデータはRequest-流れ作業です。 TLSサーバ(そして、したがって、HTTP/TLSサーバ)が受け取ると予想する最初のデータはClientHelloです。 その結果、一般的な習慣はどのプロトコルを区別するかためにHTTP/TLSを別々のポートの上に実行するのが、使用された状態であるということです。 HTTP/TLSがTCP/IP接続の上に実行されているとき、デフォルトポートは443です。 これは、別の輸送の上に実行されるので、HTTP/TLSを排除しません。 TLSは信頼できる接続指向のデータ・ストリームを推定するだけです。

2.4.  URI Format

2.4. URI形式

   HTTP/TLS is differentiated from HTTP URIs by using the 'https'
   protocol identifier in place of the 'http' protocol identifier. An
   example URI specifying HTTP/TLS is:

HTTP/TLSは、HTTP URIと'http'プロトコル識別子に代わって'https'プロトコル識別子を使用することによって、区別されます。 HTTP/TLSを指定する例のURIは以下の通りです。

     https://www.example.com/~smith/home.html

https://www.example.com/~smith/home.html

3.  Endpoint Identification

3. 終点識別

3.1.  Server Identity

3.1. サーバのアイデンティティ

   In general, HTTP/TLS requests are generated by dereferencing a URI.
   As a consequence, the hostname for the server is known to the client.
   If the hostname is available, the client MUST check it against the
   server's identity as presented in the server's Certificate message,
   in order to prevent man-in-the-middle attacks.

一般に、HTTP/TLS要求は、URIに「反-参照をつけ」ることによって、生成されます。 結果として、サーバのためのホスト名はクライアントにとって知られています。 ホスト名が利用可能であるなら、クライアントはサーバのCertificateメッセージに示されるようにサーバのアイデンティティに対してそれをチェックしなければなりません、介入者攻撃を防ぐために。

   If the client has external information as to the expected identity of
   the server, the hostname check MAY be omitted. (For instance, a
   client may be connecting to a machine whose address and hostname are
   dynamic but the client knows the certificate that the server will
   present.) In such cases, it is important to narrow the scope of
   acceptable certificates as much as possible in order to prevent man

サーバの予想されたアイデンティティに関してクライアントに外部の情報があるなら、ホスト名チェックは省略されるかもしれません。 (例えば、クライアントはアドレスとホスト名がダイナミックであるマシンに接続しているかもしれませんが、クライアントはサーバが提示する証明書を知っています。) そのような場合、許容できる証明書の範囲をできるだけ狭くするのは、男性を防ぐために重要です。

Rescorla                     Informational                      [Page 4]

RFC 2818                     HTTP Over TLS                      May 2000

TLS2000年5月の間のレスコラ情報[4ページ]のRFC2818HTTP

   in the middle attacks.  In special cases, it may be appropriate for
   the client to simply ignore the server's identity, but it must be
   understood that this leaves the connection open to active attack.

中央攻撃で。 特別な場合では、クライアントが単にサーバのアイデンティティを無視するのが、適切であるかもしれませんが、これが接続を活発な攻撃に開かれているままにするのを理解しなければなりません。

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

タイプdNSNameのsubjectAltName拡張子が存在しているなら、アイデンティティとしてそれを使用しなければなりません。 さもなければ、証明書のSubject分野における(最も特定)の俗称分野を使用しなければなりません。 俗称の使用は既存の習慣ですが、それは推奨しないです、そして、Certification Authoritiesが代わりにdNSNameを使用するよう奨励されます。

   Matching is performed using the matching rules specified by
   [RFC2459].  If more than one identity of a given type is present in
   the certificate (e.g., more than one dNSName name, a match in any one
   of the set is considered acceptable.) Names may contain the wildcard
   character * which is considered to match any single domain name
   component or component fragment. E.g., *.a.com matches foo.a.com but
   not bar.foo.a.com. f*.com matches foo.com but not bar.com.

マッチングは、[RFC2459]によって指定された合っている規則を使用することで実行されます。 与えられたタイプの1つ以上のアイデンティティが証明書に存在しているなら(例えば、1つ以上のdNSName名、セットのどれかにおけるマッチは許容できると考えられます。) 名前はどんな単一領域名前コンポーネントやコンポーネント断片も合わせると考えられるワイルドカードキャラクタ*を含むかもしれません。 *例えば、.a. comはbar.comではなく、bar.foo.a. com. f*.comマッチfoo.comではなく、foo.a. comに合っています。

   In some cases, the URI is specified as an IP address rather than a
   hostname. In this case, the iPAddress subjectAltName must be present
   in the certificate and must exactly match the IP in the URI.

いくつかの場合、URIはホスト名よりむしろIPアドレスとして指定されます。 この場合、iPAddress subjectAltNameは証明書に存在していなければならなくて、まさにURIでIPに合わなければなりません。

   If the hostname does not match the identity in the certificate, user
   oriented clients MUST either notify the user (clients MAY give the
   user the opportunity to continue with the connection in any case) or
   terminate the connection with a bad certificate error. Automated
   clients MUST log the error to an appropriate audit log (if available)
   and SHOULD terminate the connection (with a bad certificate error).
   Automated clients MAY provide a configuration setting that disables
   this check, but MUST provide a setting which enables it.

ホスト名が証明書のアイデンティティに合っていないなら、ユーザ指向のクライアントは、ユーザ(クライアントはどのような場合でも、接続を続行する機会をユーザに与えるかもしれない)に通知しなければならないか、または悪い証明書誤りとの関係を終えなければなりません。 自動化されたクライアントは適切な監査ログに誤りを登録しなければなりません、そして、(利用可能であるなら)SHOULDは接続(悪い証明書誤りがある)を終えます。 自動化されたクライアントは、それを設定すると無効にされる構成にこのチェックを提供するかもしれませんが、それを可能にする設定を提供しなければなりません。

   Note that in many cases the URI itself comes from an untrusted
   source. The above-described check provides no protection against
   attacks where this source is compromised. For example, if the URI was
   obtained by clicking on an HTML page which was itself obtained
   without using HTTP/TLS, a man in the middle could have replaced the
   URI.  In order to prevent this form of attack, users should carefully
   examine the certificate presented by the server to determine if it
   meets their expectations.

URI自体が信頼できないソースから来させる多くの場合でそれに注意してください。 上で説明されたチェックはこのソースが感染されるところに攻撃に対するノー・プロテクションを提供します。 例えば、HTTP/TLSを使用しないで得られた1HTML形式のページをクリックすることによってURIを得たなら、中央の男性はURIを取り替えたかもしれません。 この形式の攻撃を防ぐために、ユーザは慎重にサーバによって提示された、それが彼らの期待に合うかどうか決定した証明書を調べるべきです。

3.2.  Client Identity

3.2. クライアントのアイデンティティ

   Typically, the server has no external knowledge of what the client's
   identity ought to be and so checks (other than that the client has a
   certificate chain rooted in an appropriate CA) are not possible. If a
   server has such knowledge (typically from some source external to
   HTTP or TLS) it SHOULD check the identity as described above.

サーバには通常、クライアントのアイデンティティが何であるべきであるかに関するどんな外部の知識もないので、チェック(クライアントが適切なカリフォルニアに証明書チェーンを根づかせるのを除いて)は可能ではありません。 サーバにはそのような知識がaであるならあります。(通常HTTPかTLS) それへの外部のソースから、SHOULDは上で説明されるようにアイデンティティをチェックします。

Rescorla                     Informational                      [Page 5]

RFC 2818                     HTTP Over TLS                      May 2000

TLS2000年5月の間のレスコラ情報[5ページ]のRFC2818HTTP

References

参照

   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
             Public Key Infrastructure: Part I: X.509 Certificate and
             CRL Profile", RFC 2459, January 1999.

[RFC2459] Housley、R.、フォード、W.、ポーク、W.、およびD.が独奏される、「インターネット公開鍵基盤:」 部分I: 「X.509証明書とCRLプロフィール」、RFC2459、1月1999日

   [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter,
             L., Leach, P. and T. Berners-Lee, "Hypertext Transfer
             Protocol, HTTP/1.1", RFC 2616, June 1999.

[RFC2616] フィールディングとR.とGettysとJ.とムガール人とJ.とFrystykとH.とMasinterとL.とリーチとP.とT.バーナーズ・リー、「ハイパーテキスト転送プロトコル、HTTP/1.1インチ、RFC2616、1999年6月。」

   [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナー、S.、「RFCsにおける使用がRequirement Levelsを示す主要なワーズ」、BCP14、RFC2119、3月1997日

   [RFC2246] Dierks, T. and C. Allen, "The TLS Protocol", RFC 2246,
             January 1999.

[RFC2246] DierksとT.とC.アレン、「TLSプロトコル」、RFC2246、1999年1月。

   [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
             HTTP/1.1", RFC 2817, May 2000.

「HTTP/1.1インチ、RFC2817、2000年5月中にTLSにアップグレードする」[RFC2817]Khare、R.、およびS.ローレンス。

Security Considerations

セキュリティ問題

   This entire document is about security.

この全体のドキュメントはセキュリティに関するものです。

Author's Address

作者のアドレス

   Eric Rescorla
   RTFM, Inc.
   30 Newell Road, #16
   East Palo Alto, CA 94303

エリックレスコラRTFM Inc.30ヌーエルRoad、東パロアルト、#16カリフォルニア 94303

   Phone: (650) 328-8631
   EMail: ekr@rtfm.com

以下に電話をしてください。 (650) 328-8631 メールしてください: ekr@rtfm.com

Rescorla                     Informational                      [Page 6]

RFC 2818                     HTTP Over TLS                      May 2000

TLS2000年5月の間のレスコラ情報[6ページ]のRFC2818HTTP

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

Rescorla                     Informational                      [Page 7]

レスコラInformationalです。[7ページ]