Network Working Group D. Pinkas
Request for Comments: 3379 Bull
Category: Informational R. Housley
RSA Laboratories
September 2002
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.
本文档使用两个主请求/响应对指定公钥证书的委托路径验证（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。有些客户端需要服务器来执行认证路径验证，不需要数据采集，而有些客户端只需要路径发现来支持本地路径验证。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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.
通过使用服务器获取证书、CRL和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提供了几个好处。例如，对服务器的单个查询可以替换多个存储库查询，服务器缓存可以减少延迟。客户机系统的另一个好处是，它不需要合并一组不同的软件来与各种形式的存储库交互（可能通过不同的协议），也不需要执行发现认证路径所需的图形处理，而只需要进行查询以获取路径验证数据。
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].
要验证的证书必须直接在请求中提供或明确引用，如CA可分辨名称、证书序列号和证书哈希，如[ESS]中定义的ESSCertID或[ES-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
DPV请求必须允许客户端请求服务器在其响应中包含附加信息，这将允许不信任DPV服务器的依赖方确信已正确执行证书验证。此类信息可能（不一定是排他性的）包括认证路径、来自授权CRL发行人或授权OCSP响应者的撤销状态信息、来自CRL发行人或受验证信任的OCSP响应者的撤销状态信息
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.
策略，来自验证策略下受信任的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服务器可能被配置为使用一个或多个其他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
委托路径发现（DPD）协议允许客户端使用单个请求一次性从单个服务器收集当前可用的数据元素，这些数据元素可以使用
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）或通过查询多个服务器，根据单个路径发现策略本地验证公钥证书。返回的信息可用于在本地验证当前时间的一个或多个证书。
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服务器响应包括零、一或多个认证路径。每个路径由一系列证书组成，从要验证的证书开始，以信任锚点结束。如果信任锚点是自签名证书，则不得包括该自签名证书。此外，如果请求，还必须返回与路径中的每个证书关联的吊销信息。
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) 根据路径发现策略找到了一个或多个证书路径，并且存在请求的吊销信息的子集。
3) one or more certification paths was found according to the path discovery policy, with none of the requested revocation information present.
3) 根据路径发现策略找到了一个或多个证书路径，但不存在任何请求的吊销信息。
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.
当未检测到错误时，返回的信息包括一个或多个证书路径以及路径中每个证书的相关吊销状态信息（如果请求）。
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.
应用层协议中没有特定的保密要求。然而，当需要保密时，可以使用较低层的安全协议来实现。
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.
验证策略可以包括多个信任锚。信任锚定义为一个公钥、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]中的认证路径验证算法的输入提供特定值，例如用户初始策略集、初始策略映射禁止、初始显式策略或初始任何策略禁止。
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:
验证策略由三个组件构成：
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数据元素，这些数据元素在定义验证策略的组件时可能有用。
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证书的要求不同。例如，终端实体证书可能需要OCSP响应，而CA证书可能需要CRL。
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 subject alt name中或在subject name中的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.2、7.3和7.4节中规定的要求相同。
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服务器。虽然一个积极的回答可能对一个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.
在特雷弗·弗里曼、保罗·霍夫曼、安巴里什·马尔帕尼、迈克·迈尔斯、蒂姆·波尔克和彼得·西尔维斯特提供了一些有价值的信息后，这些需求得到了改进。
[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.和D.Solo，“互联网X.509公钥基础设施证书和CRL配置文件”，RFC 32802002年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互联网公钥基础设施在线证书状态协议-OCSP”，RFC 25601999年6月。
[ES-F] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Formats for long term electronic signatures", RFC 3126, September 2001.
[E-F]Pinkas，D.，Ross，J.和N.Pope，“长期电子签名的电子签名格式”，RFC3126，2001年9月。
[ES-P] Pinkas, D., Ross, J. and N. Pope, "Electronic Signature Policies", RFC 3125, September 2001.
[E-P]Pinkas，D.，Ross，J.和N.Pope，“电子签名政策”，RFC 31252001年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 25851999年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.和P.Richard，“互联网X.509公钥基础设施操作协议LDAPv2”，RFC 2559，1999年4月。
Denis Pinkas Bull Rue Jean-Jaures - BP 68 78340 Les Clayes-sous-Bois FRANCE
Denis Pinkas Bull Rue Jean Jaures-英国石油公司68 78340法国南部粘土
EMail: Denis.Pinkas@bull.net
EMail: Denis.Pinkas@bull.net
Russell Housley RSA Laboratories 918 Spring Knoll Drive Herndon, VA 20170 USA
美国弗吉尼亚州赫恩登斯普林诺尔大道918号拉塞尔·霍斯利RSA实验室，邮编：20170
EMail: rhousley@rsasecurity.com
EMail: 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编辑功能的资金目前由互联网协会提供。