RFC3379 日本語訳
3379 Delegated Path Validation and Delegated Path Discovery ProtocolRequirements. D. Pinkas, R. Housley. September 2002. (Format: TXT=32455 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Pinkas
Request for Comments: 3379 Bull
Category: Informational R. Housley
RSA Laboratories
September 2002
コメントを求めるワーキンググループD.ピンカスの要求をネットワークでつないでください: 3379年の雄牛カテゴリ: 情報のR.Housley RSA研究所2002年9月
Delegated Path Validation and Delegated Path Discovery
Protocol Requirements
代表として派遣された経路合法化と代表として派遣された経路発見プロトコル要件
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 (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
Abstract
要約
This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) for Public Key Certificates. It also specifies the requirements for DPV and DPD policy management.
このドキュメントはDelegated Path Validation(DPV)とDelegated Pathディスカバリー(DPD)のための要件をPublic Key Certificatesに指定します。 また、それはDPVのための要件とDPD政策管理を指定します。
1. Introduction
1. 序論
This document specifies the requirements for Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) for Public Key Certificates, using two main request/response pairs.
このドキュメントはDelegated Path Validation(DPV)とDelegated Pathディスカバリー(DPD)のための要件をPublic Key Certificatesに指定します、2主な要求/応答組を使用して。
Delegated processing provides two primary services: DPV and DPD. Some clients require a server to perform certification path validation and have no need for data acquisition, while some other clients require only path discovery in support of local path validation.
代表として派遣された処理は2つの一次業務を提供します: DPVとDPD。 何人かのクライアントが、サーバが証明経路合法化を実行して、データ取得の必要性を全く持っていないのを必要とします、ある他のクライアントは地方の経路合法化を支持して経路発見だけを必要としますが。
The DPV request/response pair, can be used to fully delegate path validation processing to an DPV server, according to a set of rules, called a validation policy.
DPV要求/応答組、経路合法化処理をDPVサーバへ完全に代表として派遣するのに使用できます、合法化方針と呼ばれる1セットの規則に従って。
The DPD request/response pair can be used to obtain from a DPD server all the information needed (e.g., the end-entity certificate, the CA certificates, full CRLs, delta-CRLs, OCSP responses) to locally validate a certificate. The DPD server uses a set of rules, called a path discovery policy, to determine which information to return.
DPDサーバから局所的に証明書を有効にするのに必要である(例えば、終わり実体証明書、カリフォルニア証明書、完全なCRLs、デルタ-CRLs、OCSP応答)すべての情報を得るのにDPD要求/応答組を使用できます。 DPDサーバは、どの情報を返したらよいかを決定するのに経路発見方針と呼ばれる1セットの規則を使用します。
Pinkas & Housley Informational [Page 1] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[1ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
A third request/response pair allows clients to obtain references for the policies supported by a DPV or DPD server.
3番目の要求/応答組はクライアントにDPVかDPDサーバによってサポートされた方針の参照を得させます。
1.1. Terminology
1.1. 用語
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、このドキュメント(中で大文字してください、示されるように)で「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように解釈されることであるべきですか?
2. Rationale and Benefits for DPV (Delegated Path Validation)
2. DPVのための原理と利益(代表として派遣された経路合法化)
DPV allows a server to perform a real time certificate validation for a validation time T, where T may be the current time or a time in the recent past.
DPVはサーバに合法化時間Tリアルタイムの証明書合法化を実行させます、Tが最近において現在の時間か1時間であるかもしれないところで。
In order to validate a certificate, a chain of multiple certificates, called a certification path, may be needed, comprising a certificate of the public key owner (the end entity) signed by one CA, and zero or more additional certificates of CAs signed by other CAs.
証明書を有効にするために、証明経路と呼ばれる複数の証明書のチェーンが必要であったかもしれません、公開鍵所有者(終わりの実体)の証明書を包括するのは1カリフォルニア、およびゼロで署名したか、またはCAsの、より多くの追加証明書が他のCAsで署名しました。
Offloading path validation to a server may be required by a client that lacks the processing, and/or communication capabilities to fetch the necessary certificates and revocation information, perform certification path construction, and perform local path validation.
経路合法化をサーバへ積み下ろすのは処理、そして/または、必要な証明書と取消し情報をとって来て、証明経路工事を実行して、地方の経路合法化を実行するコミュニケーション能力を欠いているクライアントによって必要とされるかもしれません。
In constrained execution environments, such as telephones and PDAs, memory and processing limitations may preclude local implementation of complete, PKIX-compliant certification path validation [PKIX-1].
電話やPDAなどの強制的な実行環境では、メモリと処理制限は完全で、PKIX対応することの証明経路合法化[PKIX-1]の地方の実装を排除するかもしれません。
In applications where minimum latency is critical, delegating validation to a trusted server can offer significant advantages. The time required to send the target certificate to the validation server, receive the response, and authenticate the response, can be considerably less than the time required for the client to perform certification path discovery and validation. Even if a certification path were readily available to the client, the processing time associated with signature verification for each certificate in the path might (especially when validating very long paths or using a limited processor) be greater than the delay associated with use of a validation server.
最小の潜在が重要であるアプリケーションでは、信じられたサーバへ合法化を代表として派遣すると、重要な利点を示すことができます。 目標証明書を合法化サーバに送って、応答を受けて、応答を認証するのに必要である時間、時間がクライアントが証明経路発見と合法化を実行するのが必要であるというよりもかなり少ない場合があります。 クライアントには、証明経路が容易に利用可能であったとしても、経路の各証明書のための署名照合に関連している処理時間は合法化サーバの使用に関連している遅れよりすばらしいでしょうに(特に、非常に長い経路を有効にするか、または限られたプロセッサを使用するとき)。
Pinkas & Housley Informational [Page 2] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[2ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
Another motivation for offloading path validation is that it allows validation against management-defined validation policies in a consistent fashion across an enterprise. Clients that are able to do their own path validation may rely on a trusted server to do path validation if centralized management of validation policies is needed, or the clients rely on a trusted server to maintain centralized records of such activities.
経路合法化を積み下ろすことに関する別の動機は企業の向こう側に一貫したファッションで経営者側によって定義された合法化方針に対して合法化を許すということです。 合法化方針の集中的管理が必要であるなら、それら自身の経路合法化ができるクライアントが経路合法化をするために信じられたサーバを当てにするかもしれませんか、またはクライアントは、そのような活動の集結された記録を保守するために信じられたサーバを当てにします。
When a client uses this service, it inherently trusts the server as much as it would its own path validation software (if it contained such software). Clients can direct the server to perform path validation in accordance with a particular validation policy.
クライアントがこのサービスを利用すると、それは本来サーバをそれ自身の経路合法化ソフトウェア(そのようなソフトウェアを含んだなら)を信じるほど信じます。 クライアントは、特定の合法化方針に従って経路合法化を実行するようサーバに指示できます。
3. Rationale and Benefits for DPD (Delegated Path Discovery)
3. DPDのための原理と利益(代表として派遣された経路発見)
DPD is valuable for clients that do much of the PKI processing themselves and simply want a server to collect information for them. The server is trusted to return the most current information that is available to it (which may not be the most current information that has been issued). The client will ultimately perform certification path validation.
自分たちを処理しながらPKIの多くのことをして、単にサーバに彼らのための情報を集めて欲しいクライアントにとって、DPDは貴重です。 サーバがそれ(発行された中で最も現在の情報でないかもしれない)に利用可能な最も現在の情報を返すと信じられます。 クライアントは結局、証明経路合法化を実行するでしょう。
A client that performs path validation for itself may get benefit in several ways from using a server to acquire certificates, CRLs, and OCSP responses [OCSP] as inputs to the validation process. In this context, the client is relying on the server to interact with repositories to acquire the data that the client would otherwise have to acquire using LDAP, HTTP, FTP [LDAP, FTP&HTTP] or another repository access protocol. Since these data items are digitally signed, the client need not trust the server any more than the client would trust the repositories.
それ自体のための経路合法化を実行するクライアントは合法化への入力が処理されるとき証明書、CRLs、およびOCSP応答[OCSP]を獲得するのにサーバを使用するのから利益をいくつかの方法で得るかもしれません。 このような関係においては、クライアントは、LDAP、HTTP、FTP[LDAP、FTP、およびHTTP]または別の倉庫アクセス・プロトコルを使用することでそうでなければクライアントが取得しなければならないデータを取得するために倉庫と対話するためにサーバを当てにしています。 これらのデータ項目がデジタルに署名されるので、クライアントはクライアントが倉庫を信じるだろうよりサーバを信じる必要はありません。
DPD provides several benefits. For example, a single query to a server can replace multiple repository queries, and caching by the server can reduce latency. Another benefit to the client system is that it need not incorporate a diverse set of software to interact with various forms of repositories, perhaps via different protocols, nor to perform the graph processing necessary to discover certification paths, separate from making the queries to acquire path validation data.
DPDはいくつかの利益を提供します。 例えば、サーバへのただ一つの質問は複数の倉庫質問に取って代わることができます、そして、サーバによるキャッシュはレイテンシを減少させることができます。 クライアントシステムへの別の利益は恐らく異なったプロトコルで様々な形式の倉庫と対話して、証明経路を発見するのに必要なグラフ処理を実行するためにさまざまのソフトウェアを組み込む必要はないということです、経路合法化データを取得するために質問をするのから、別々です。
4. Delegated Path Validation Protocol Requirements
4. 代表として派遣された経路合法化プロトコル要件
4.1. Basic Protocol
4.1. 基本プロトコル
The Delegated Path Validation (DPV) protocol allows a server to validate one or more public key certificates on behalf of a client according to a validation policy.
Delegated Path Validation(DPV)プロトコルで、合法化方針によると、サーバはクライアントを代表して1通以上の公開鍵証明書を有効にすることができます。
Pinkas & Housley Informational [Page 3] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[3ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
If the DPV server does not support the client requested validation policy, then the DPV server MUST return an error.
DPVサーバがクライアントの要求された合法化方針をサポートしないなら、DPVサーバは誤りを返さなければなりません。
If the DPV request does not specify a validation policy, the server response MUST indicate the validation policy that was used.
DPV要求が合法化方針を指定しないなら、サーバ応答は使用された合法化方針を示さなければなりません。
Policy definitions can be quite long and complex, and some policies may allow for the setting of a few parameters (such as root self- signed certificates). The protocol MUST allow the client to include these policy dependent parameters in the DPV request; however, it is expected that most clients will simply reference a validation policy for a given application or accept the DPV server's default validation policy.
方針定義は、かなり長くて、複雑である場合があります、そして、いくつかの方針がいくつかのパラメタ(証明書であると署名される根自己などの)の設定を考慮するかもしれません。 プロトコルで、クライアントはDPV要求でこれらの方針に依存するパラメタを入れることができなければなりません。 しかしながら、ほとんどのクライアントが単に当然のことのアプリケーションのための合法化方針に参照をつけるか、またはDPVサーバのデフォルト合法化方針を受け入れると予想されます。
The client can request that the server determines the certificate validity at a time other than the current time. The DPV server MUST obtain revocation status information for the validation time in the client request.
クライアントは、現在の時間を除いて、サーバが一度に証明書の正当性を決定するよう要求できます。 DPVサーバはクライアント要求で合法化時間の取消し状態情報を得なければなりません。
In order to obtain the revocation status information of any certificate from the certification path, the DPV server might use, in accordance with the validation policy, different sources of revocation information. For example, a combination of OCSP responses, CRLs, and delta CRLs could be used. Alternatively, a response from another DPV server could be used.
証明経路からどんな証明書の取消し状態情報も得るために、合法化方針によると、DPVサーバは取消し情報のさまざまな原因を使用するかもしれません。 例えば、OCSP応答、CRLs、およびデルタCRLsの組み合わせを使用できました。 あるいはまた、別のDPVサーバからの応答を使用できました。
If the revocation status information for the requested validation time is unavailable, then the DPV server MUST return a status indicating that the certificate is invalid. Additional information about the reason for invalidity MAY also be provided.
要求された合法化時間の取消し状態情報が入手できないなら、DPVサーバは証明書が無効であることを示す状態を返さなければなりません。 また、無効の理由に関する追加情報を提供するかもしれません。
The certificate to be validated MUST either be directly provided in the request or unambiguously referenced, such as the CA distinguished name, certificate serial number, and the hash of the certificate, like ESSCertID as defined in [ESS] or OtherSigningCertificate as defined in [ES-F].
直接有効にされるべき証明書に、要求に提供しなければならないか、または明白に参照をつけなければなりません、証明書のカリフォルニア分類名や、証明書通し番号や、ハッシュなどのように、[ESS]で定義されるESSCertIDや[ES-F]で定義されるOtherSigningCertificateのように。
The DPV client MUST be able to provide to the validation server, associated with each certificate to be validated, useful certificates, as well as useful revocation information. Revocation information includes OCSP responses, CRLs, and delta CRLs. As an example, an S/MIME message might include such information, and the client can simply copy that information into the DPV request.
DPVクライアントは、有効にされるために合法化サーバに提供できて、各証明書に関連していなければなりません、役に立つ証明書、役に立つ取消し情報と同様に。 取消し情報はOCSP応答、CRLs、およびデルタCRLsを含んでいます。 例として、S/MIMEメッセージはそのような情報を含むかもしれません、そして、クライアントは単にDPV要求にその情報をコピーできます。
Pinkas & Housley Informational [Page 4] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[4ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
The DPV server MUST have the certificate to be validated. When the certificate is not provided in the request, the server MUST obtain the certificate and then verify that the certificate is indeed the one being unambiguous referenced by the client. The DPV server MUST include either the certificate or an unambiguous reference to the certificate (in case of a CA key compromise) in the DPV response.
DPVサーバには、有効にされるべき証明書がなければなりません。 証明書が要求に提供されないと、サーバは、証明書を入手して、本当に、証明書が明白であるのがクライアントで参照をつけたものであることを確かめなければなりません。 DPVサーバはDPV応答に証明書(カリフォルニアの主要な感染の場合の)の証明書か明白な指示するもののどちらかを含まなければなりません。
The DPV response MUST indicate one of the following status alternatives:
DPV応答は以下の状態代替手段の1つを示さなければなりません:
1) the certificate is valid according to the validation policy.
1) 合法化方針によると、証明書は有効です。
2) the certificate is not valid according to the validation policy.
2) 合法化方針によると、証明書は有効ではありません。
3) the validity of the certificate is unknown according to the
validation policy.
3) 合法化方針によると、証明書の正当性は未知です。
4) the validity could not be determined due to an error.
4) 正当性は誤りのため決定できませんでした。
When the certificate is not valid according to the validation policy, then the reason MUST also be indicated. Invalidity reasons include:
また、合法化方針によると、証明書が有効でないと、理由を示さなければなりません。 無効理由は:
a) the DPV server cannot determine the validity of the certificate
because a certification path cannot be constructed.
a) DPVサーバは、証明経路を構成できないので、証明書の正当性を決定できません。
b) the DPV server successfully constructed a certification path, but
it was not valid according to the validation algorithm in
[PKIX-1].
b) DPVサーバは首尾よく証明経路を構成しましたが、[PKIX-1]の合法化アルゴリズムによると、それは有効ではありませんでした。
c) the certificate is not valid at this time. If another request
could be made later on, the certificate could possibly be
determined as valid. This condition may occur before a
certificate validity period has begun or while a certificate is
suspended.
c) 証明書はこのとき、有効ではありません。 後で別の要求をすることができるなら、証明書は有効であるとして決定できるでしょうに。 この状態は証明書有効期間が始まる前か証明書が吊している間現れるかもしれません。
The protocol MUST prevent replay attacks, and the replay prevention mechanism employed by the protocol MUST NOT rely on synchronized clocks.
プロトコルは反射攻撃を防がなければなりません、そして、プロトコルによって使われた再生防止メカニズムは連動している時計を当てにしてはいけません。
The DPV request MUST allow the client to request that the server include in its response additional information which will allow relying parties not trusting the DPV server to be confident that the certificate validation has correctly been performed. Such information may (not necessarily exclusively) consist of a certification path, revocation status information from authorized CRL issuers or authorized OCSP responders, revocation status information from CRL issuers or OCSP responders trusted under the validation
DPV要求で、クライアントは、サーバが、応答追加情報にどれがDPVサーバが証明書合法化が正しく実行されたと確信していると信じないパーティーを信用に許容するかを含んでいるよう要求できなければなりません。 そのような情報は証明経路から成るかもしれません(必ず排他的であるというわけではなく)、と認可されたCRL発行人か認可されたOCSP応答者からの取消し状態情報、CRL発行人からの取消し状態情報またはOCSP応答者が合法化中に信じました。
Pinkas & Housley Informational [Page 5] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[5ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
policy, time-stamp tokens from TSAs responders trusted under the validation policy, or a DPV response from a DPV server that is trusted under the validation policy. When the certificate is valid according to the validation policy, the server MUST, upon request, include that information in the response. However, the server MAY omit that information when the certificate is invalid or when it cannot determine the validity.
方針、合法化方針の下で信じられたTSAs応答者からのタイムスタンプトークン、または合法化方針の下で信じられるDPVサーバからのDPV応答。 合法化方針によると、証明書が要求のときに有効であるときに、サーバは応答にその情報を含まなければなりません。 しかしながら、サーバは証明書がいつ無効であるか、そして、またはそれがいつ正当性を決定できないかというその情報を省略するかもしれません。
The DPV server MUST be able, upon request, copy a text field provided by the client into the DPV response. As an example, this field may relate to the nature or reason for the DPV query.
DPVサーバは要求、テキストフィールドがクライアントでDPV応答に提供したコピーでできるに違いありません。 例として、この分野はDPV質問の自然か理由に関連するかもしれません。
The DPV response MUST be bound to the DPV request so that the client can be sure that all the parameters from the request have been taken into consideration by the DPV server to build the response. This can be accomplished by including a one-way hash of the request in the response.
クライアントが要求からのすべてのパラメタがDPVサーバによって考慮に入れられて、応答を組み込んだのを確信するように、DPV要求にDPV応答を縛らなければなりません。 応答における要求の一方向ハッシュを含んでいることによって、これを達成できます。
In some environments it may be necessary to present only a DPV response to another relying party without the corresponding request. In this case the response MUST be self contained. This can be accomplished by repeating only the important components from the request in the response.
いくつかの環境で、対応する要求なしで別の信用パーティーへのDPV応答だけを提示するのが必要であるかもしれません。 この場合、応答は自給自足であるに違いありません。 応答における要求から重要なコンポーネントだけを繰り返すことによって、これを達成できます。
For the client to be confident that the certificate validation was handled by the expected DPV server, the DPV response MUST be authenticated, unless an error is reported (such as a badly formatted request or unknown validation policy).
クライアントが証明書合法化が予想されたDPVサーバによって扱われて、誤りが報告されない場合DPV応答を認証しなければならないと確信している(ひどくフォーマットされた要求か未知の合法化方針などの)ように。
For the client to be able prove to a third party that trusts the same DPV server that the certificate validation was handled correctly, the DPV response MUST be digitally signed, unless an error is reported. The DPV server's certificate MUST authenticate the DPV server.
クライアントができるために、証明書合法化が正しく扱われて、DPV応答にデジタルに署名しなければならないと同じDPVサーバを信じる第三者に立証してください、誤りが報告されない場合。 DPVサーバの証明書はDPVサーバを認証しなければなりません。
The DPV server MAY require client authentication, therefore, the DPV request MUST be able to be authenticated.
DPVサーバはクライアント認証を必要とするかもしれません、したがって、DPV要求が認証できなければなりません。
When the DPV request is authenticated, the client SHOULD be able to include a client identifier in the request for the DPV server to copy into the response. Mechanisms for matching this identifier with the authenticated identity depends on local DPV server conditions and/or the validation policy. The DPV server MAY choose to blindly copy the identifier, omit the identifier, or return an error response.
いつが認証されるかDPVが、要求する、クライアントSHOULD。DPVサーバが応答にコピーされるという要求にクライアント識別子を含むことができてください。 この識別子を認証されたアイデンティティに合わせるためのメカニズムは地方のDPVサーバ状態、そして/または、合法化方針によります。 DPVサーバは、盲目的に識別子をコピーするのを選ぶか、識別子を省略するか、または誤り応答を返すかもしれません。
There are no specific confidentiality requirements within this application layer protocol. However, when confidentiality is needed, it can be achieved with a lower-layer security protocol.
この応用層プロトコルの中にどんな特定の機密保持の要求事項もありません。 しかしながら、秘密性が必要であるときに、下層セキュリティプロトコルでそれを達成できます。
Pinkas & Housley Informational [Page 6] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[6ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
4.2. Relaying, Re-direction and Multicasting
4.2. リレー、リダイレクション、およびマルチキャスティング
In some network environments, especially ones that include firewalls, a DPV server might not be able to obtain all of the information that it needs to process a request. However, the DPV server might be configured to use the services of one or more other DPV servers to fulfill all requests. In such cases, the client is unaware that the queried DPV server is using the services of other DPV servers, and the client-queried DPV server acts as a DPV client to another DPV server. Unlike the original client, the DPV server is expected to have moderate computing and memory resources, enabling the use of relay, re-direct or multicasting mechanisms. The requirements in this section support DPV server-to-DPV server exchanges without imposing them on DPV client-to-DPV server exchanges.
いくつかのネットワーク環境、特にファイアウォールを含んでいるものでは、DPVサーバは要求を処理するのが必要であるという情報のすべてを得ることができないかもしれません。 しかしながら、DPVサーバは、すべての要求を実現させるのに他の1つ以上のDPVサーバのサービスを利用するために構成されるかもしれません。 そのような場合、クライアントは質問されたDPVサーバが他のDPVサーバのサービスを利用しているのを気づきません、そして、クライアントによって質問されたDPVサーバはDPVクライアントとして別のDPVサーバに機能します。DPVクライアントからDPVへのサーバ交換にそれらを課さないで、リレーの使用を可能にして、オリジナルのクライアントと異なって、DPVサーバには適度のコンピューティングとメモリリソースがあると予想されます、再直接である、またはマルチキャスティングメカニズムこのセクションの要件はDPVのサーバからDPVにサーバ交換をサポートします。
Protocols designed to satisfy these requirements MAY include optional fields and/or extensions to support relaying, re-direction or multicasting. However, DPV clients are not expected to support relay, re-direct or multicast. If the protocol supports such features, the protocol MUST include provisions for DPV clients and DPV servers that do not support such features, allowing them to conform to the basic set of requirements.
これらの要件を満たすように設計されたプロトコルは、リレー、リダイレクションまたはマルチキャスティングをサポートするために任意の分野、そして/または、拡大を含むかもしれません。 しかしながら、DPVクライアントが再直接でリレーを支えないと予想されます。または、マルチキャスト。 プロトコルがそのような特徴をサポートするなら、プロトコルはそのような特徴をサポートしないDPVクライアントとDPVサーバのための条項を含まなければなりません、それらが基本的なセットの要件に従うのを許容して。
- When a server supports a relay mechanism, a mechanism to detect
loops or repetition MUST be provided.
- サーバがリレーメカニズムをサポートすると、検出するメカニズムが輪にされるか、または反復を提供しなければなりません。
- When a protocol provides the capability for a DPV server to re-
direct a request to another DPV server (that is, the protocol
chooses to provide a referral mechanism), a mechanism to provide
information to be used for the re-direction SHOULD be supported.
If such re-direction information is sent back to clients, then the
protocol MUST allow conforming clients to ignore it.
- プロトコルが能力を提供するときには、DPVサーバが、リダイレクションSHOULDに使用されるよう別のDPVサーバ(すなわち、プロトコルは、紹介メカニズムを提供するのを選ぶ)への要求、情報を供給するメカニズムに再指示するように、サポートされてください。 そのようなリダイレクション情報がクライアントに送り返されるなら、プロトコルで、それを無視するためにクライアントを従わせなければなりません。
- Optional parameters in the protocol request and/or response MAY be
provide support for relaying, re-direction or multicasting. DPV
clients that ignore any such optional parameters MUST be able to
use the DPV service. DPV servers that ignore any such optional
parameters MUST still be able to offer the DPV service, although
they might not be able to overcome the limitations imposed by the
network topology. In this way, protocol implementers do not need
to understand the syntax or semantics of any such optional
parameters.
- プロトコル要求、そして/または、応答における任意のパラメタはリレー、リダイレクションまたはマルチキャスティングのサポートを提供することであるかもしれません。 そのようなどんな任意のパラメタも無視するDPVクライアントはDPVサービスを利用できなければなりません。 そのようなどんな任意のパラメタも無視するDPVサーバはまだDPVサービスを提供できなければなりません、ネットワーク形態によって課された限界を克服できないかもしれませんが。 このように、プロトコルimplementersはそのようなどんな任意のパラメタの構文か意味論も理解する必要はありません。
5. Delegated Path Discovery Protocol Requirements
5. 代表として派遣された経路発見プロトコル要件
The Delegated Path Discovery (DPD) protocol allows the client to use a single request to collect at one time from a single server the data elements available at the current time that might be collected using
Delegated Pathディスカバリー(DPD)プロトコルで、クライアントはひところただ一つのサーバから集まっている使用であるかもしれない現在の時間に有効なデータ要素を集めるというただ一つの要求を使用できます。
Pinkas & Housley Informational [Page 7] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[7ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
different protocols (such as LDAP, HTTP, FTP, or OCSP) or by querying multiple servers, to locally validate a public key certificate according to a single path discovery policy. The returned information can be used to locally validate one or more certificates for the current time.
異なったプロトコル(LDAP、HTTP、FTP、またはOCSPなどの)かただ一つの経路発見方針によると、局所的に公開鍵証明書を有効にするために複数のサーバについて質問すること。 局所的に現在の時間の1通以上の証明書を有効にするのに返された情報を使用できます。
Clients MUST be able to specify whether they want, in addition to the certification path, the revocation information associated with the path, for the end-entity certificate, for the CA certificates, or for both.
クライアントは、彼らが、証明経路に加えて取消し情報に経路に関連していて欲しいかどうか指定できなければなりません、カリフォルニア証明書、または両方のための終わり実体証明書のために。
If the DPD server does not support the client requested path discovery policy, the DPD server MUST return an error. Some forms of path discovery policy can be simple. In that case it is acceptable to pass the parameters from the path discovery policy with each individual request. For example, the client might provide a set of trust anchors and separate revocation status conditions for the end- entity certificate and for the other certificates. The DPD request MUST allow more elaborated path discovery policies to be referenced. However, it is expected that most of the time clients will only be aware of the referenced path discovery policy for a given application.
DPDサーバがクライアントの要求された経路発見方針をサポートしないなら、DPDサーバは誤りを返さなければなりません。 いくつかのフォームの経路発見方針は簡単である場合があります。 その場合、それぞれの個々の要求のときに経路発見方針からパラメタを通過するのは許容できます。 例えば、クライアントは終わりの実体証明書と他の証明書のための1セットの信頼アンカーと別々の取消し状態状態を提供するかもしれません。 DPD要求は、さらに練られた経路発見方針が参照をつけられるのを許容しなければなりません。 しかしながら、たいてい、クライアントが与えられたアプリケーションのための参照をつけられた経路発見方針を意識するだけであると予想されます。
The DPD server response includes zero, one, or several certification paths. Each path consists of a sequence of certificates, starting with the certificate to be validated and ending with a trust anchor. If the trust anchor is a self-signed certificate, that self-signed certificate MUST NOT be included. In addition, if requested, the revocation information associated with each certificate in the path MUST also be returned.
DPDサーバ応答はゼロ、1、またはいくつかの証明経路を含んでいます。 各経路は証明書の系列から成ります、信頼アンカーと共に有効にされて、証明書から終わり始めていて。 信頼アンカーが自己署名入りの証書であるなら、その自己署名入りの証書を含んではいけません。 また、さらに、要求するなら、経路の各証明書に関連している取消し情報を返さなければなりません。
By default, the DPD server MUST return a single certification path for each end-entity certificate in the DPD request. However, the returned path may need to match some additional local criteria known only to the client. For example, the client might require the presence of a particular certificate extension or a particular name form. Therefore, the DPD client MUST have a means of obtaining more than one certification path for each end-entity certificate in the DPD request. At the same time, the mechanism for obtaining additional certification paths MUST NOT impose protocol state on the DPD server. Avoiding the maintenance of state information associated with previous requests minimizes potential denial of service attacks and other problems associated with server crashes.
デフォルトで、DPDサーバはDPD要求におけるそれぞれの終わり実体証明書のためにただ一つの証明経路を返さなければなりません。 しかしながら、返された経路は、クライアントだけにおいて知られているいくつかの追加地方の評価基準を合わせる必要があるかもしれません。 例えば、クライアントは特定の証明書拡張子か特定の名前フォームを存在に要求するかもしれません。 したがって、DPDクライアントには、DPD要求におけるそれぞれの終わり実体証明書あたり1つ以上の証明経路を得る手段がなければなりません。 同時に、プロトコル状態は追加証明経路を得るためのメカニズムによってDPDサーバに課されてはいけません。前の要求に関連している州の情報のメインテナンスを避けると、潜在的サービス不能攻撃とサーバクラッシュに関連している他の問題は最小にされます。
Path discovery MUST be performed according to the path discovery policy. The DPD response MUST indicate one of the following status alternatives:
経路発見方針によると、経路発見を実行しなければなりません。 DPD応答は以下の状態代替手段の1つを示さなければなりません:
Pinkas & Housley Informational [Page 8] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[8ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
1) one or more certification paths was found according to the path
discovery policy, with all of the requested revocation information
present.
1) 経路発見方針によると、1つ以上の証明経路が見つけられました、要求された取消し情報のすべてが出席していた状態で。
2) one or more certification paths was found according to the path
discovery policy, with a subset of the requested revocation
information present.
2) 経路発見方針によると、1つ以上の証明経路が見つけられました、要求された取消し情報の部分集合が存在していた状態で。
3) one or more certification paths was found according to the path
discovery policy, with none of the requested revocation
information present.
3) 経路発見方針によると、1つ以上の証明経路が見つけられました、要求された取消し情報のいずれも存在していなかった状態で。
4) no certification path was found according to the path discovery
policy.
4) 経路発見方針によると、証明経路は全く見つけられませんでした。
5) path construction could not be performed due to an error.
5) 誤りのため経路工事を実行できませんでした。
When no errors are detected, the information that is returned consists of one or more certification paths and, if requested, its associated revocation status information for each certificate in the path.
誤りが全く検出されないとき、返される情報は経路の各証明書のための1つ以上の証明経路と要求されているときのその関連取消し状態情報から成ります。
For the client to be confident that all of the elements from the response originate from the expected DPD server, an authenticated response MAY be required. For example, the server might sign the response or data authentication might also be achieved using a lower-layer security protocol.
クライアントが応答からの要素のすべてが予想されたDPDサーバから発すると確信しているように、認証された応答が必要であるかもしれません。 例えば、サーバは応答に署名するかもしれませんか、またはまた、データ認証が、下層セキュリティプロトコルを使用することで実現されるかもしれません。
The DPD server MAY require client authentication, allowing the DPD request MUST to be authenticated.
DPDサーバは、クライアント認証、DPD要求がそうしなければならない許容が認証されるのを必要とするかもしれません。
There are no specific confidentiality requirement within the application layer protocol. However, when confidentiality is needed, it can be achieved with a lower-layer security protocol.
応用層プロトコルの中にどんな特定の機密保持の要求事項もありません。 しかしながら、秘密性が必要であるときに、下層セキュリティプロトコルでそれを達成できます。
6. DPV and DPD Policy Query
6. DPVとDPD方針質問
Using a separate request/response pair, the DPV or DPD client MUST be able to obtain references for the default policy or for all of the policies supported by the server. The response can include references to previously defined policies or to a priori known policies.
別々の要求/応答組、DPVまたはDPDクライアントを使用すると、デフォルト方針かサーバによってサポートされた方針のすべての参照を得ることができなければなりません。応答は、以前に定義された方針か先験的な知られている方針の指示するものを含むことができます。
7. Validation Policy
7. 合法化方針
A validation policy is a set of rules against which the validation of the certificate is performed.
合法化方針は証明書の合法化が実行される1セットの規則です。
Pinkas & Housley Informational [Page 9] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[9ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
A validation policy MAY include several trust anchors. A trust anchor is defined as one public key, a CA name, and a validity time interval; a trust anchor optionally includes additional constraints. The use of a self-signed certificate is one way to specify the public key to be used, the issuer name, and the validity period of the public key.
合法化方針は数人の信頼アンカーを含むかもしれません。 信頼アンカーは1つの公開鍵、カリフォルニア名、および正当性時間間隔と定義されます。 信頼アンカーは任意に追加規制を入れます。 自己署名入りの証書の使用は使用されるべき公開鍵、発行人名、および公開鍵の有効期間を指定することにおいて一方通行です。
Additional constraints for each trust anchor MAY be defined. These constraints might include a set of certification policy constraints or a set of naming constraints. These constraints MAY also be included in self-signed certificates.
それぞれの信頼アンカーの追加規制は定義されるかもしれません。 これらの規制は、1セットの証明方針規制か1セットについて規制を命名するのを含むかもしれません。 また、これらの規制は自己署名入りの証書に含まれるかもしれません。
Additional conditions that apply to the certificates in the path MAY also be specified in the validation policy. For example, specific values could be provided for the inputs to the certification path validation algorithm in [PKIX-1], such as user-initial-policy-set, initial-policy-mapping-inhibit, initial-explicit-policy, or initial- any-policy-inhibit.
また、経路の証明書に適用される追加条件は合法化方針で指定されるかもしれません。 例えば、[PKIX-1]の証明経路合法化アルゴリズムへの入力に特定の値を提供できました、ユーザの初期の方針セット、マッピングが禁止する初期の方針、初期の明白な方針、または方針が禁止する初期のいずれなどのようにも。
Additional conditions that apply to the end-entity certificate MAY also be specified in the validation policy. For example, a specific name form might be required.
また、終わり実体証明書に適用される追加条件は合法化方針で指定されるかもしれません。 例えば、種名フォームが必要であるかもしれません。
In order to succeed, one valid certification path (none of the certificates in the path are expired or revoked) MUST be found between an end-entity certificate and a trust anchor and all constraints that apply to the certification path MUST be verified.
成功するように、終わり実体証明書と信頼アンカーの間で1つの有効な証明経路(経路の証明書のいずれも、吐き出されるか、または取り消されない)を見つけなければなりません、そして、証明経路に適用されるすべての規制について確かめなければなりません。
7.1. Components for a Validation Policy
7.1. 合法化方針のためのコンポーネント
A validation policy is built from three components:
合法化方針は3つのコンポーネントから築き上げられます:
1. Certification path requirements,
1. 証明経路要件
2. Revocation requirements, and
2. そして取消し要件。
3. End-entity certificate specific requirements.
3. 終わり実体は決められた一定の要求を証明します。
Note: [ES-P] defines ASN.1 data elements that may be useful while defining the components of a validation policy.
以下に注意してください。 [ES-P]は合法化方針の成分を定義している間に役に立つかもしれないASN.1データ要素を定義します。
7.2. Certificate Path Requirements
7.2. 証明書経路要件
The path requirements identify a sequence of trust anchors used to start certification path processing and initial conditions for certification path validation as defined in [PKIX-1].
経路要件は[PKIX-1]で定義されるように証明経路合法化のための証明経路処理と初期条件を始めるのに使用される信頼アンカーの系列を特定します。
Pinkas & Housley Informational [Page 10] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[10ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
7.3. Revocation Requirements
7.3. 取消し要件
Revocation information might be obtained through CRLs, delta CRLs or OCSP responses. Certificate revocation requirements are specified in terms of checks required on the end-entity certificate and CA certificates.
CRLs、デルタCRLsまたはOCSP応答で取消し情報を得るかもしれません。 証明書取消し要件は終わり実体証明書とカリフォルニア証明書の上に必要であるチェックで指定されます。
Revocation requirements for the end-entity certificate may not be the same as the requirements for the CA certificates. For example, an OCSP response may be needed for the end-entity certificate while CRLs may be sufficient for the CA certificates.
終わり実体証明書のための取消し要件はカリフォルニア証明書のための要件と同じでないかもしれません。 例えば、CRLsがカリフォルニア証明書に十分であるかもしれない間、OCSP応答が終わり実体証明書に必要であるかもしれません。
The validation policy MUST specify the source of revocation information:
合法化方針は取消し情報の源を指定しなければなりません:
- full CRLs (or full Authority Revocation Lists) have to be
collected.
- 完全なCRLs(または、完全なAuthority Revocation Lists)は集められなければなりません。
- OCSP responses, using [OCSP], have to be collected.
- [OCSP]を使用して、OCSP応答は集められなければなりません。
- delta CRLs and the relevant associated full CRLs (or full Authority
Revocation Lists) are to be collected.
- デルタCRLsと関連関連完全なCRLs(または、完全なAuthority Revocation Lists)は集められることになっています。
- any available revocation information has to be collected.
- どんな利用可能な取消し情報も集められなければなりません。
- no revocation information need be collected.
- 取消し情報は全く集められる必要はありません。
7.4. End-entity Certificate Specific Requirements
7.4. 終わり実体証明書決められた一定の要求
The validation policy might require the end-entity certificate to contain specific extensions with specific types or values (it does not matter whether they are critical or non-critical). For example, the validation policy might require an end-entity certificate that contains an electronic mail address (either in the rfc822 subject alt name or in the emailAddress naming attribute in the subject name).
合法化方針は、終わり実体証明書が特定のタイプか値がある特定の拡大を含むのを必要とするかもしれません(それらが重要であるか、または非臨界であるかが重要ではありません)。 例えば、合法化方針は電子メールアドレス(rfc822の対象のalt名か対象の名前のemailAddress命名属性における)を含む終わり実体証明書を必要とするかもしれません。
8. Path Discovery Policy
8. 経路発見方針
A path discovery policy is a set of rules against which the discovery of a certification path is performed. A path discovery policy is a subset of a validation policy. A path discovery policy MAY either be a reference to a validation policy or contain only some major elements from a validation policy, such as the trust anchors.
経路発見方針は証明経路の発見が実行される1セットの規則です。 経路発見方針は合法化方針の部分集合です。 経路発見方針は、合法化方針の参照であるか合法化方針からいくつかだけの多量栄養素を含むかもしれません、信頼アンカーなどのように。
Since the DPD client is "PKI aware", it can locally apply additional selection criteria to the certification paths returned by the server. Thus, a simpler policy can be defined and used for path discovery.
DPDクライアントが「PKI意識している」ので、それは局所的にサーバによって返された証明経路に追加選択評価基準を適用できます。その結果、経路発見により簡単な方針は、定義して、使用できます。
Pinkas & Housley Informational [Page 11] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[11ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
8.1. Components for a Path Discovery Policy
8.1. 経路発見方針のためのコンポーネント
The path discovery policy includes certification path requirements, revocation requirements, and end-entity certificate specific requirements. These requirements are the same as those specified in sections 7.2, 7.3, and 7.4, respectively.
経路発見方針は証明経路要件、取消し要件、および終わり実体証明書決められた一定の要求を含んでいます。 これらの要件はものがセクション7.2、7.3、および7.4で指定したのとそれぞれ同じです。
9. Security Considerations
9. セキュリティ問題
A DPV client must trust a DPV server to provide the correct answer. However, this does not mean that all DPV clients will trust the same DPV servers. While a positive answer might be sufficient for one DPV client, that same positive answer will not necessarily convince another DPV client.
DPVクライアントは、正解を提供するためにDPVサーバを信じなければなりません。 しかしながら、これは、すべてのDPVクライアントが同じDPVサーバを信じることを意味しません。 積極的な答えは1人のDPVクライアントに十分であるかもしれませんが、その同じ積極的な答えは必ず別のDPVクライアントに納得させるというわけではないでしょう。
Other clients may trust their own DPV servers, or they might perform certification path validation themselves. DPV clients operating under an organizational validation policy must ensure that each of the DPV servers they trust is operating under that organizational validation policy.
他のクライアントがそれら自身のDPVサーバを信じるかもしれませんか、またはそれらは自分たちで証明経路合法化を実行するかもしれません。 それらは、組織的な合法化方針の下で働いているDPVクライアントが、それぞれのDPVサーバがその組織的な合法化方針の下で作動しているのを保証しなければならないと信じます。
When no policy reference is present in the DPV request, the DPV client ought to verify that the policy selected by the DPV server is appropriate.
どんな方針参照もDPV要求に存在していないとき、DPVクライアントは、DPVサーバによって選択された方針が適切であることを確かめるべきです。
The revocation status information is obtained for the validation time. In case of a digital signature, it is not necessarily identical to the time when the private key was used. The validation time ought to be adjusted by the DPV client to compensate for:
取消し状態情報を合法化時間に得ます。 デジタル署名の場合には、それは必ず秘密鍵が使用された時と同じであるというわけではありません。 合法化時間は補うDPVクライアントによって調整されるべきです:
1) time for the end-entity to realize that its private key has been
or could possibly be compromised, and/or
そして/または1) 終わり実体が換金される秘密鍵が持っている時間にあるか、または感染することができた。
2) time for the end-entity to report the key compromise, and/or
そして/または2)終わり実体が主要な感染を報告する時間。
3) time for the revocation authority to process the revocation
request from the end-entity, and/or
そして/または3)終わり実体から取消し要求を処理する取消し権威のための時間。
4) time for the revocation authority to update and distribute the
revocation status information.
4)取消し状態情報をアップデートして、分配する取消し権威のための時間。
10. Acknowledgments
10. 承認
These requirements have been refined after some valuable inputs from Trevor Freeman, Paul Hoffman, Ambarish Malpani, Mike Myers, Tim Polk, and Peter Sylvester.
これらの要件はトレバー・フリーマン、ポール・ホフマン、Ambarish Malpani、マイク・マイアーズ、ティム・ポーク、およびピーター・シルベスターからのいくつかの貴重な入力の後に洗練されました。
Pinkas & Housley Informational [Page 12] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[12ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
11. References
11. 参照
11.1. Normative References
11.1. 引用規格
[PKIX-1] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 3280, April 2002.
[PKIX-1] HousleyとR.とフォードとW.とポークとW.と一人で生活して、「インターネットX.509公開鍵基盤の証明書とCRLは輪郭を描く」D.、RFC3280、2002年4月。
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[OCSP] マイアーズ、M.、Ankney、R.、Malpani、A.、ガリペリン、S.、およびC.アダムス、「X.509のインターネットの公開鍵暗号基盤のオンライン証明書状態は議定書を作ります--OCSP」、RFC2560、1999年6月。
11.2. Informative References
11.2. 有益な参照
[ES-F] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
Formats for long term electronic signatures", RFC 3126,
September 2001.
[ES-F] ピンカスとD.とロスとJ.とN.ポープ、「長期の電子署名のための電子Signature Formats」、RFC3126、2001年9月。
[ES-P] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
Policies", RFC 3125, September 2001.
[ES-P] ピンカスとD.とロスとJ.とN.ポープ、「電子署名方針」、RFC3125、2001年9月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC
2634, June 1999.
[ESS]ホフマン、P.、「S/MIMEのための警備の強化サービス」、RFC2634、1999年6月。
[ISO-X509] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
Technology - Open Systems Interconnection: The Directory:
Authentication Framework," 1997 edition.
[ISO-X509]ISO/IEC ITU9594-8/T推薦X.509、「情報技術--オープン・システム・インターコネクション:、」 ディレクトリ: 「認証Framework」、1997年の版。
[FTP&HTTP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure. Operational Protocols: FTP and HTTP", RFC
2585, May 1999.
[FTPとHTTP] HousleyとR.とP.ホフマン、「インターネットX.509公開鍵基盤。」 操作上のプロトコル: 「FTPとHTTP」(RFC2585)は1999がそうするかもしれません。
[LDAP] Boeyen, S., Howes, T. and P. Richard, "Internet X.509
Public Key Infrastructure Operational Protocols LDAPv2",
RFC 2559, April 1999.
[LDAP] BoeyenとS.とハウズとT.とP.リチャード、「インターネットのX.509の公開鍵暗号基盤の操作上のプロトコルLDAPv2"、RFC2559、1999年4月。」
Pinkas & Housley Informational [Page 13] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[13ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
12. Authors' Addresses
12. 作者のアドレス
Denis Pinkas Bull Rue Jean-Jaures - BP 68 78340 Les Clayes-sous-Bois FRANCE
デニス・ピンカス・雄牛Rueジーン-ジョーレス--BP68 78340レス・Clayes小銭Boisフランス
EMail: Denis.Pinkas@bull.net
メール: Denis.Pinkas@bull.net
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley RSA研究所918は小山Driveヴァージニア20170ハーンドン(米国)を跳ばせます。
EMail: rhousley@rsasecurity.com
メール: rhousley@rsasecurity.com
Pinkas & Housley Informational [Page 14] RFC 3379 DPV and DPD Protocol Requirements September 2002
ピンカス、Housleyの情報[14ページ]のRFC3379DPV、およびDPDプロトコル要件2002年9月
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。
Pinkas & Housley Informational [Page 15]
ピンカスとHousley情報です。[15ページ]
一覧
スポンサーリンク
