rfc3379.txt

RFC 的详细文档！


RFC 3379           DPV and DPD Protocol Requirements      September 2002


   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.




Pinkas & Housley             Informational                      [Page 6]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


4.2. Relaying, Re-direction and Multicasting

   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.

5. Delegated Path Discovery Protocol Requirements

   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



Pinkas & Housley             Informational                      [Page 7]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


   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:




Pinkas & Housley             Informational                      [Page 8]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


   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.

6. DPV and DPD Policy Query

   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.

7. Validation Policy

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




Pinkas & Housley             Informational                      [Page 9]

RFC 3379           DPV and DPD Protocol Requirements      September 2002


   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 [PKIX-1], 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.

7.1. Components for a Validation Policy

   A validation policy is built from three components:

   1. Certification path requirements,

   2. Revocation requirements, and

   3. End-entity certificate specific requirements.

   Note:  [ES-P] defines ASN.1 data elements that may be useful while
   defining the components of a validation policy.

7.2. Certificate Path Requirements

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





Pinkas & Housley             Informational                     [Page 10]

RFC 3379           DPV and DPD Protocol Requirements      September 2002