Network Working Group D. Pinkas
Request for Comments: 3379 Bull
Category: Informational R. Housley
RSA Laboratories
September 2002
Delegated Path Validation and Delegated Path Discovery
Protocol Requirements
Status of this 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.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書は、公開鍵証明書のための委任パス検証（DPV）と委任パス発見（DPD）の要件を指定します。また、DPVとDPDポリシー管理のための要件を指定します。
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.
この文書では、主に2つの要求/応答のペアを使用して、公開鍵証明書のための委任パス検証（DPV）と委任パス発見（DPD）の要件を指定します。
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.
DPVとDPD：委任処理は、2つの主要なサービスを提供しています。いくつかの他のクライアントは、ローカルパス検証をサポートする唯一のパスの検出を必要としながら、いくつかのクライアントは、証明書パス検証を実行するためにサーバを必要とし、データ収集を必要としません。
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サーバにパス検証処理を委任するために使用することができ、ルールのセットに従って、検証ポリシーと呼ばれます。
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要求/応答のペアは、局所的にDPDサーバから必要なすべての情報（例えば、エンドエンティティ証明書、CA証明書、完全なCRLに、デルタのCRL、OCSP応答）を得るために使用することができる証明書を検証します。 DPDサーバは、返却する情報を決定するために、経路発見ポリシーと呼ばれる、一連の規則を使用します。
A third request/response pair allows clients to obtain references for the policies supported by a DPV or DPD server.
第三の要求/応答のペアは、クライアントがDPV又はDPDサーバによってサポートされるポリシーの参照を取得することを可能にします。
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"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHALL NOT"、（この文書では、 "SHOULD"、 "推奨" "NOT SHOULD"、 "MAY"、および "OPTIONAL" ）に示すように、大文字で、[RFC2119]に記載されているように解釈されるべきです。
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、のためのリアルタイムの証明書の検証を行うことができます。
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.
証明書、複数の証明書のチェーン、認証パスと呼ばを検証するためには、CAによって署名された公開鍵所有者（エンドエンティティ）によって署名されたCAのゼロまたはそれ以上の追加の証明書の証明書を含む、必要とされるかもしれません他のCA。
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.
最小の待ち時間が重要なアプリケーションでは、信頼できるサーバに検証を委任することは重要な利点を提供することができます。 、検証サーバにターゲット証明書を送って応答を受信し、応答を認証するために必要な時間は、証明書パスの検出および検証を実行するためのクライアントのために必要な時間よりもかなり小さくすることができます。認証パスをクライアントに容易に利用可能であったとしても、パス内の各証明書の署名検証に関連付けられた処理時間が（非常に長いパスを有効または限定されたプロセッサを使用する場合は特に）バリデーションの使用に関連する遅延よりも大きいかもしれませんサーバ。
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.
クライアントは、このサービスを使用する場合、それは本質的に同じくらい、それは（それは、このようなソフトウェアが含まれている場合）は、独自のパス検証ソフトウェアを同じようにサーバーを信頼します。クライアントは、特定の検証ポリシーに従ってパス検証を実行するために、サーバーに指示することができます。
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.
DPDは、自分自身を処理PKIの多くを行うと、単にサーバが彼らのために情報を収集するクライアントのために貴重です。サーバが（発行された最新の情報ではない可能性がある）、それに利用可能な最新の情報を返すために信頼されています。クライアントは、最終的には証明書パスの検証を実行します。
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.
自身のパス検証を実行し、クライアントは、検証プロセスへの入力として[OCSP]証明書、CRLの、及び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は、いくつかの利点を提供します。たとえば、サーバーへの単一のクエリでは、複数のリポジトリクエリを置き換えることができ、およびサーバーによってキャッシュは待ち時間を短縮することができます。クライアント・システムへの別の利点は、おそらく、異なるプロトコルを介して、リポジトリの様々な形態と相互作用するソフトウェアの多様なセットを組み込む必要はなく、また証明書パスを発見する必要グラフ処理を実行するために、パスを取得するためにクエリを行うこととは別のことです検証データ。
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.
委任パス検証（DPV）プロトコルは、サーバが検証ポリシーに従って、クライアントに代わって、一つ以上の公開鍵証明書を検証することができます。
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応答、CRLの、およびデルタのCRLの組み合わせを使用することができます。また、別の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]またはOtherSigningCertificateで定義されるように検証される証明書は直接ES [ESSCertIDように、そのようなCA識別名、証明書のシリアル番号、および証明書のハッシュとして、要求において提供または明確に参照しなければならないのいずれかで-F]。
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応答、CRLを、およびデルタCRLを含んでいます。例として、S / MIMEメッセージには、このような情報が含まれる場合がありますし、クライアントは単にDPV要求にその情報をコピーすることができます。
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応答の証明書または（CAキー妥協の場合）証明書への明確な基準のいずれかを含まなければなりません。
The DPV response MUST indicate one of the following status alternatives:
DPV応答は以下のステータスの選択肢のいずれかを示す必要があります：
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 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.
DPV要求は、クライアントがサーバが証明書の検証が正しく行われたことを確信するためにDPVサーバを信頼当事者にない頼ることができますその応答の追加情報に含めることを要求することを可能にしなければなりません。そのような情報は、（必ずしも排他的にではない）認証パスから構成されてもよい、許可CRL発行者または許可OCSPレスポンダ、CRL発行者またはOCSPレスポンダから失効状態情報から失効状態情報が検証方針の下で、信頼できる、のTSA応答者からタイムスタンプトークンは下トラステッド検証ポリシー、または検証ポリシーの下で信頼されている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要求が認証されると、クライアントは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.
このアプリケーション層プロトコル内には、特定の機密性の要件はありません。機密性が必要な場合しかし、それは下位層のセキュリティプロトコルを用いて達成することができます。
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サーバに再直接要求（つまりプロトコルが紹介メカニズムを提供することを選択し、である）に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サービスを提供することができなければなりません。このように、プロトコルの実装者は、このようなオプションのパラメータの構文や意味を理解する必要はありません。
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 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.
委任パス発見（DPD）プロトコルでは、クライアントは、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.
クライアントは、CA証明書の、またはその両方のために、エンドエンティティ証明書、証明書パス、パスに関連付けられている失効情報に加えて、彼らが望むかどうかを指定することができなければなりません。
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サーバがエラーを返さなければなりません。パスディスカバリポリシーのいくつかの形態をシンプルにすることができます。その場合、個々の要求に経路発見ポリシーからパラメータを渡すために許容可能です。例えば、クライアントが信頼アンカーとエンドエンティティ証明書と他の証明書用に別の失効状態の条件のセットを提供するかもしれません。 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要求で各エンドエンティティ証明書に複数の証明書パスを取得する手段を持たなければなりません。これと同時に、追加の証明書パスを取得するためのメカニズムは、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) one or more certification paths was found according to the path discovery policy, with all of the requested revocation information present.
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要求を認証するMUST可能、クライアント認証が必要な場合があります。
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.
アプリケーション層プロトコル内には、特定の機密性の要件はありません。機密性が必要な場合しかし、それは下位層のセキュリティプロトコルを用いて達成することができます。
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クライアントは、デフォルトのポリシーまたはサーバーでサポートされているすべてのポリシーのための参照を取得できなければなりません。応答は、事前に定義されたポリシーまたは先験的知ら政策への参照を含めることができます。
A validation policy is a set of rules against which the validation of the certificate is performed.
検証ポリシーは、証明書の検証が行われ、それに対してルールのセットです。
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つの公開鍵、CAの名前、および有効期限の間隔として定義されます。トラストアンカーは、必要に応じて追加の制約を含んでいます。自己署名証明書の使用は、使用する公開鍵、発行者名、および公開鍵の有効期間を指定するための一つの方法です。
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.
各トラストアンカーのための追加の制約を定義することができます。これらの制約は、認証ポリシーの制約のセットまたは命名制約のセットが含まれる場合があります。これらの制約は、自己署名証明書に含まれるかもしれません。
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]における認証パス検証アルゴリズムへの入力のために提供することができます-any-ポリシー禁止。
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.
成功するためには、つの有効な証明書パスは、（パス内の証明書のいずれも有効期限が切れていないか、無効化されている）、エンドエンティティ証明書の間に見なければならないとトラストアンカーと証明のパスに適用されるすべての制約が検証されなければなりません。
A validation policy is built from three components:
検証ポリシーは、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データ要素を定義します。
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]で定義されるように経路要求は、認証パス処理及び認証パス検証のための初期条件を開始するために使用されるトラストアンカーの配列を同定します。
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.
失効情報は、CRLを、デルタCRLのか、OCSPレスポンスを介して取得される可能性があります。証明書の失効要件は、エンドエンティティ証明書およびCA証明書に必要なチェックの観点で指定されています。
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.
エンドエンティティ証明書の失効要件は、CA証明書の要件と同じではないかもしれません。 CRLはCA証明書のために十分であり得るが、例えば、OCSP応答は、エンドエンティティ証明書のために必要とされてもよいです。
The validation policy MUST specify the source of revocation information:
検証ポリシーは失効情報のソースを指定する必要があります。
- full CRLs (or full Authority Revocation Lists) have to be collected.
- フルのCRL（または完全な権限失効リスト）を収集する必要があります。
- 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.
- デルタCRLと関連する関連フルのCRL（または完全な権限の失効リスト）を収集すべきです。
- any available revocation information has to be collected.
- 使用可能な任意の失効情報を収集する必要があります。
- no revocation information need be collected.
- 何の失効情報を収集する必要はありません。
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対象代替名またはサブジェクト名に属性を命名EMAILADDRESSのいずれかで）、電子メールアドレスが含まれているエンドエンティティ証明書が必要な場合があります。
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.
経路発見ポリシーは、証明書パスの検出が行われるに対するルールのセットです。パスディスカバリポリシーは、検証ポリシーのサブセットです。パスディスカバリポリシーは、どちらかの検証ポリシーを参照することや、信頼アンカーとして検証ポリシーからのみいくつかの主要な要素を含んでいてもよいです。
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対応」であるので、それはローカルサーバから返された証明書パスに追加の選択基準を適用することができます。このように、単純なポリシーが定義されており、パスの検出のために使用することができます。
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.4セクション7.2、7.3で指定されたものと同じである、と。
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）失効状態情報を更新し、配布する取消し権威のための時間を。
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、マイク・マイヤーズ、ティムポーク、そしてピーター・シルベスターからいくつかの貴重な入力をした後、洗練されています。
[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.およびD.ソロ、 "インターネットX.509公開鍵暗号基盤証明書とCRLプロファイル"、RFC 3280、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.、Galperin、S.とC.アダムス、 "X.509のインターネット公開鍵暗号基盤のオンライン証明書状態プロトコル - OCSP"、RFC 2560、1999年6月。
[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.ポープ、 "長期電子署名する電子署名フォーマット"、RFC 3126、2001年9月。
[ES-P] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Policies", RFC 3125, September 2001.
[ES-P]ピンカス、D.、ロス、J.およびN.ポープ、 "電子署名ポリシー"、RFC 3125、2001年9月。
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.
[ESS]ホフマン、P.、 "S / MIMEのためのセキュリティサービスの強化"、RFC 2634、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 9594から8 / ITU-T勧告X.509、 "情報技術 - 開放型システム間相互接続：ディレクトリ：認証フレームワーク、" 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"、RFC 2585、1999年5月。
[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"、RFC 2559、1999年4月。
Denis Pinkas Bull Rue Jean-Jaures - BP 68 78340 Les Clayes-sous-Bois FRANCE
デニスピンカスブルルージャンJauresの - BP 68 78340レClayes-スーボワFRANCE
EMail: Denis.Pinkas@bull.net
メールアドレス：Denis.Pinkas@bull.net
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousleyのRSA Laboratories社918春小山Driveハーンドン、VA 20170 USA
EMail: rhousley@rsasecurity.com
メールアドレス：rhousley@rsasecurity.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。