[要約] RFC 3379は、委任されたパスの検証と委任されたパスの発見プロトコルの要件に関するものです。このRFCの目的は、セキュリティ上の課題を解決するために、委任されたパスの検証と発見に関するプロトコルの要件を定義することです。

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.

Copyright(c)The Internet Society(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ポリシー管理の要件も指定します。

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.

このドキュメントは、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要求/応答ペアを使用して、必要なすべての情報(例えば、エントエンティティ証明書、CA証明書、完全なCRLS、Delta-CRL、OCSP応答、OCSP応答など)をDPDサーバーから取得できます。DPDサーバーは、パスディスカバリーポリシーと呼ばれる一連のルールを使用して、どの情報を返すかを決定します。

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].

キーワードは「必須」、「必要」、「必須」、「「shall」、「shall」、「wuth "of"、 "low" of "、" becommended "、" may "、および" optional ")(optional」(上級では、[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は最近の時期または時間である可能性があります。

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つのCAが署名した公開キー所有者(最終事業体)の証明書、および署名された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.

最小レイテンシーが重要なアプリケーションでは、信頼できるサーバーへの検証を委任することは大きな利点を提供できます。ターゲット証明書を検証サーバーに送信し、応答を受信し、応答を認証するのに必要な時間は、クライアントが認定パスの発見と検証を実行するために必要な時間よりもかなり短くなる可能性があります。クライアントが認証パスを容易に利用できる場合でも、パス内の各証明書の署名検証に関連付けられた処理時間(特に非常に長いパスを検証する場合、または限られたプロセッサを使用する場合)は、検証の使用に関連する遅延よりも大きくなる可能性があります。サーバ。

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.

オフロードパス検証のもう1つの動機は、企業全体で一貫した方法で、管理定義の検証ポリシーに対する検証を可能にすることです。独自のPATH検証を行うことができるクライアントは、検証ポリシーの集中管理が必要な場合、またはクライアントがそのようなアクティビティの集中記録を維持するために信頼できるサーバーに依存している場合、PATH検証を行うために信頼できるサーバーに依存する場合があります。

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.

クライアントがこのサービスを使用すると、独自のPATH検証ソフトウェアと同じくらい本質的にサーバーを信頼します(そのようなソフトウェアが含まれている場合)。クライアントは、特定の検証ポリシーに従ってパス検証を実行するようサーバーに指示できます。

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.

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.

それ自体のパス検証を実行するクライアントは、サーバーを使用して証明書、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はいくつかの利点を提供します。たとえば、サーバーへの単一のクエリは複数のリポジトリクエリを置き換えることができ、サーバーによるキャッシュは遅延を減らすことができます。クライアントシステムのもう1つの利点は、さまざまな形式のリポジトリと対話するために、おそらく異なるプロトコルを介して、認証パスを発見するために必要なグラフ処理を実行して、パスを取得するためのクエリの作成とは別に、さまざまな形式のリポジトリと対話するために、多様なソフトウェアセットを組み込む必要がないことです。検証データ。

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.

委任されたパス検証(DPV)プロトコルにより、サーバーは、検証ポリシーに従ってクライアントに代わって1つ以上の公開キー証明書を検証することができます。

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]で定義されているesscertidまたは[esで定義されている他のcertificateのように、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応答者からの取消ステータス情報、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要求が認証されている場合、クライアントは、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.

このアプリケーションレイヤープロトコル内には、特定の機密性要件はありません。ただし、機密性が必要な場合は、低レイヤーセキュリティプロトコルで達成できます。

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サーバーのサービスを使用していることを認識しておらず、クライアントQueried 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サービスを提供できる必要がありますが、ネットワークトポロジによって課される制限を克服できない場合があります。このようにして、プロトコルの実装者は、そのようなオプションのパラメーターの構文やセマンティクスを理解する必要はありません。

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 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: 1) one or more certification paths was found according to the path discovery policy, with all of the requested revocation information present.

パスディスカバリーポリシーに従ってパスディスカバリーを実行する必要があります。DPD応答は、次のステータスの選択肢のいずれかを示す必要があります。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) Path Discoveryポリシーに従って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.

検証ポリシーとは、証明書の検証が実行されるルールのセットです。

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名、および有効期間間隔として定義されます。Trustアンカーには、オプションで追加の制約が含まれます。自己署名証明書の使用は、使用する公開鍵、発行者名、および公開鍵の有効期間を指定する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.

各トラストアンカーの追加の制約を定義できます。これらの制約には、認証ポリシーの制約のセットまたは命名制約のセットが含まれる場合があります。これらの制約は、自己署名証明書にも含まれる場合があります。

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.

パス内の証明書に適用される追加の条件も、検証ポリシーで指定できます。たとえば、ユーザーInitial-policy-set、initial-policy-mapping inhibit、initial-xplicit-policy、またはinitialなど、[pkix-1]の認証パス検証アルゴリズムへの入力の特定の値を提供できます。 - Any-Policy阻害。

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]で定義されているように、認証パス処理の開始と認証パス検証の初期条件を開始するために使用されるトラストアンカーのシーケンスを識別します。

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、Delta CRLS、または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証明書の要件と同じではない場合があります。たとえば、End-Entity証明書にはOCSP応答が必要になる場合がありますが、CRLはCA証明書に十分である場合があります。

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.

- Delta CRLと関連する関連する完全なCRL(または完全な権限の取り消しリスト)を収集する必要があります。

- 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名のいずれか、または件名名の電子メールアドレス命名属性)。

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.

パスディスカバリーポリシーは、認証パスの発見が実行されるルールのセットです。パスディスカバリーポリシーは、検証ポリシーのサブセットです。Path Discoveryポリシーは、検証ポリシーへの参照であるか、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 Aware」であるため、サーバーによって返される認定パスに追加の選択基準をローカルに適用できます。したがって、より単純なポリシーを定義し、パスディスカバリーに使用できます。

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.

これらの要件は、Trevor Freeman、Paul Hoffman、Amvarish Malpani、Mike Myers、Tim Polk、Peter Sylvesterからの貴重なインプットの後に洗練されています。

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.、Ford、W.、Polk、W。and D. Solo、「インターネット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] Myers、M.、Ankney、R.、Malpani、A.、Galperin、S.、およびC. Adams、「X.509インターネット公開キーインフラストラクチャオンライン証明書ステータスプロトコル」、RFC 2560、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] Pinkas、D.、Ross、J。、およびN. Pope、「長期電子署名用の電子署名形式」、RFC 3126、2001年9月。

[ES-P] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Policies", RFC 3125, September 2001.

[ES-P] Pinkas、D.、Ross、J。およびN. Pope、「電子署名ポリシー」、RFC 3125、2001年9月。

[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999.

[ESS] Hoffman、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. Hoffman、「インターネット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.、Howes、T。and P. Richard、「Internet X.509公開キーインフラストラクチャ運用プロトコルLDAPV2」、RFC 2559、1999年4月。

12. Authors' Addresses
12. 著者のアドレス

Denis Pinkas Bull Rue Jean-Jaures - BP 68 78340 Les Clayes-sous-Bois FRANCE

デニス・ピンカス・ブル・ルー・ジャン・ジェアーズ-BP 68 78340 Les Clayes-Sous-Bois France

   EMail: Denis.Pinkas@bull.net
        

Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA

Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon、VA 20170 USA

   EMail: rhousley@rsasecurity.com
        
13. 完全な著作権声明

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

Copyright(c)The Internet Society(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エディター機能の資金は現在、インターネット協会によって提供されています。