<pre>Network Working Group                                          D. Pinkas
Request for Comments: 3379                                          Bull
Category: Informational                                       R. Housley
                                                        RSA Laboratories
                                                          September 2002


        <span class="h1">Delegated Path Validation and Delegated Path Discovery</span>
                         <span class="h1">Protocol Requirements</span>

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.

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.

<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>

   This document specifies the requirements for Delegated Path
   Validation (DPV) and Delegated Path Discovery (DPD) for Public Key
   Certificates, using two main request/response pairs.

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

   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.

   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.



<span class="grey">Pinkas &amp; Housley             Informational                      [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   A third request/response pair allows clients to obtain references for
   the policies supported by a DPV or DPD server.

<span class="h3"><a class="selflink" id="section-1.1" href="#section-1.1">1.1</a>. Terminology</span>

   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 [<a href="./rfc2119">RFC2119</a>].

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Rationale and Benefits for DPV (Delegated Path Validation)</span>

   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.

   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.

   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 [<a href="#ref-PKIX-1" title="&quot;Internet X.509 Public Key Infrastructure Certificate and CRL Profile&quot;">PKIX-1</a>].

   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.










<span class="grey">Pinkas &amp; Housley             Informational                      [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   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.

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Rationale and Benefits for DPD (Delegated Path Discovery)</span>

   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.

   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 [<a href="#ref-OCSP" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">OCSP</a>] 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&amp;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.

   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.

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Delegated Path Validation Protocol Requirements</span>

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. Basic Protocol</span>

   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.



<span class="grey">Pinkas &amp; Housley             Informational                      [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   If the DPV server does not support the client requested validation
   policy, then the DPV server MUST return an error.

   If the DPV request does not specify a validation policy, the server
   response MUST indicate the validation policy that was used.

   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.

   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.

   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.

   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.

   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 [<a href="#ref-ESS" title="&quot;Enhanced Security Services for S/MIME&quot;">ESS</a>] or OtherSigningCertificate as
   defined in [<a href="#ref-ES-F" title="&quot;Electronic Signature Formats for long term electronic signatures&quot;">ES-F</a>].

   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.








<span class="grey">Pinkas &amp; Housley             Informational                      [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   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.

   The DPV response MUST indicate one of the following status
   alternatives:

   1) the certificate is valid according to the validation policy.

   2) the certificate is not valid according to the validation policy.

   3) the validity of the certificate is unknown according to the
      validation policy.

   4) the validity could not be determined due to an error.

   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.

   b) the DPV server successfully constructed a certification path, but
      it was not valid according to the validation algorithm in
      [<a href="#ref-PKIX-1" title="&quot;Internet X.509 Public Key Infrastructure Certificate and CRL Profile&quot;">PKIX-1</a>].

   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.

   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




<span class="grey">Pinkas &amp; Housley             Informational                      [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   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.

   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.

   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.

   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.

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

   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.

   The DPV server MAY require client authentication, therefore, the DPV
   request MUST be able to be authenticated.

   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.

   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.




<span class="grey">Pinkas &amp; Housley             Informational                      [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. Relaying, Re-direction and Multicasting</span>

   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.

   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.

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

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

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Delegated Path Discovery Protocol Requirements</span>

   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



<span class="grey">Pinkas &amp; Housley             Informational                      [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   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.

   Clients MUST be able to specify whether they want, in addition to the
   certification path, the revocation information associated with the
   path, for the end-entity certificate, for the CA certificates, or for
   both.

   If the DPD server does not support the client requested path
   discovery policy, the DPD server MUST return an error.  Some forms of
   path discovery policy can be simple.  In that case it is acceptable
   to pass the parameters from the path discovery policy with each
   individual request.  For example, the client might provide a set of
   trust anchors and separate revocation status conditions for the end-
   entity certificate and for the other certificates.  The DPD request
   MUST allow more elaborated path discovery policies to be referenced.
   However, it is expected that most of the time clients will only be
   aware of the referenced path discovery policy for a given
   application.

   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.

   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.

   Path discovery MUST be performed according to the path discovery
   policy.  The DPD response MUST indicate one of the following status
   alternatives:




<span class="grey">Pinkas &amp; Housley             Informational                      [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   1) one or more certification paths was found according to the path
      discovery policy, with all of the requested revocation information
      present.

   2) one or more certification paths was found according to the path
      discovery policy, with a subset of the requested revocation
      information present.

   3) one or more certification paths was found according to the path
      discovery policy, with none of the requested revocation
      information present.

   4) no certification path was found according to the path discovery
      policy.

   5) path construction could not be performed due to an error.

   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.

   The DPD server MAY require client authentication, allowing the DPD
   request MUST to be authenticated.

   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.

<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. DPV and DPD Policy Query</span>

   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.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Validation Policy</span>

   A validation policy is a set of rules against which the validation of
   the certificate is performed.




<span class="grey">Pinkas &amp; Housley             Informational                      [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


   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.

   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 [<a href="#ref-PKIX-1" title="&quot;Internet X.509 Public Key Infrastructure Certificate and CRL Profile&quot;">PKIX-1</a>], such as user-initial-policy-set,
   initial-policy-mapping-inhibit, initial-explicit-policy, or initial-
   any-policy-inhibit.

   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.

<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Components for a Validation Policy</span>

   A validation policy is built from three components:

   1. Certification path requirements,

   2. Revocation requirements, and

   3. End-entity certificate specific requirements.

   Note:  [<a href="#ref-ES-P" title="&quot;Electronic Signature Policies&quot;">ES-P</a>] defines ASN.1 data elements that may be useful while
   defining the components of a validation policy.

<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Certificate Path Requirements</span>

   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 [<a href="#ref-PKIX-1" title="&quot;Internet X.509 Public Key Infrastructure Certificate and CRL Profile&quot;">PKIX-1</a>].





<span class="grey">Pinkas &amp; Housley             Informational                     [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Revocation Requirements</span>

   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.

   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.

   The validation policy MUST specify the source of revocation
   information:

   - full CRLs (or full Authority Revocation Lists) have to be
     collected.

   - OCSP responses, using [<a href="#ref-OCSP" title="&quot;X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP&quot;">OCSP</a>], have to be collected.

   - delta CRLs and the relevant associated full CRLs (or full Authority
     Revocation Lists) are to be collected.

   - any available revocation information has to be collected.

   - no revocation information need be collected.

<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. End-entity Certificate Specific Requirements</span>

   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 <a href="./rfc822">rfc822</a> subject alt
   name or in the emailAddress naming attribute in the subject name).

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Path Discovery Policy</span>

   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.




<span class="grey">Pinkas &amp; Housley             Informational                     [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


<span class="h3"><a class="selflink" id="section-8.1" href="#section-8.1">8.1</a>. Components for a Path Discovery Policy</span>

   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 <a href="#section-7.2">7.2</a>, <a href="#section-7.3">7.3</a>, and <a href="#section-7.4">7.4</a>, respectively.

<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>

   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.

   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.

   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.

   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:

   1) time for the end-entity to realize that its private key has been
      or could possibly be compromised, and/or

   2) time for the end-entity to report the key compromise, and/or

   3) time for the revocation authority to process the revocation
      request from the end-entity, and/or

   4) time for the revocation authority to update and distribute the
      revocation status information.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. Acknowledgments</span>

   These requirements have been refined after some valuable inputs from
   Trevor Freeman, Paul Hoffman, Ambarish Malpani, Mike Myers, Tim Polk,
   and Peter Sylvester.





<span class="grey">Pinkas &amp; Housley             Informational                     [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. References</span>

<span class="h3"><a class="selflink" id="section-11.1" href="#section-11.1">11.1</a>. Normative References</span>

   [<a id="ref-PKIX-1">PKIX-1</a>]   Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
              X.509 Public Key Infrastructure Certificate and CRL
              Profile", <a href="./rfc3280">RFC 3280</a>, April 2002.

   [<a id="ref-OCSP">OCSP</a>]     Myers, M., Ankney, R., Malpani, A., Galperin, S. and C.
              Adams, "X.509 Internet Public Key Infrastructure Online
              Certificate Status Protocol - OCSP", <a href="./rfc2560">RFC 2560</a>, June 1999.

<span class="h3"><a class="selflink" id="section-11.2" href="#section-11.2">11.2</a>. Informative References</span>

   [<a id="ref-ES-F">ES-F</a>]     Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
              Formats for long term electronic signatures", <a href="./rfc3126">RFC 3126</a>,
              September 2001.

   [<a id="ref-ES-P">ES-P</a>]     Pinkas, D., Ross, J. and N. Pope, "Electronic Signature
              Policies", <a href="./rfc3125">RFC 3125</a>, September 2001.

   [<a id="ref-ESS">ESS</a>]      Hoffman, P., "Enhanced Security Services for S/MIME", <a href="./rfc2634">RFC</a>
              <a href="./rfc2634">2634</a>, June 1999.

   [<a id="ref-ISO-X509">ISO-X509</a>] ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
              Technology - Open Systems Interconnection: The Directory:
              Authentication Framework," 1997 edition.

   [FTP&amp;HTTP] Housley, R. and P. Hoffman, "Internet X.509 Public Key
              Infrastructure. Operational Protocols: FTP and HTTP", <a href="./rfc2585">RFC</a>
              <a href="./rfc2585">2585</a>, May 1999.

   [<a id="ref-LDAP">LDAP</a>]     Boeyen, S., Howes, T. and P. Richard, "Internet X.509
              Public Key Infrastructure Operational Protocols LDAPv2",
              <a href="./rfc2559">RFC 2559</a>, April 1999.
















<span class="grey">Pinkas &amp; Housley             Informational                     [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Authors' Addresses</span>

   Denis Pinkas
   Bull
   Rue Jean-Jaures - 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

   EMail: rhousley@rsasecurity.com

































<span class="grey">Pinkas &amp; Housley             Informational                     [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc3379">RFC 3379</a>           DPV and DPD Protocol Requirements      September 2002</span>


<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Full Copyright Statement</span>

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

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   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.



















Pinkas &amp; Housley             Informational                     [Page 15]
</pre>