rfc3379.txt

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.

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.

1. Introduction

   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.



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


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

1.1. Terminology

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

2. Rationale and Benefits for DPV (Delegated Path Validation)

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










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


   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.

3. Rationale and Benefits for DPD (Delegated Path Discovery)

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

   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.

4. Delegated Path Validation Protocol Requirements

4.1. Basic Protocol

   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.



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


   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 [ESS] or OtherSigningCertificate as
   defined in [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.








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


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

   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




Pinkas & Housley             Informational                      [Page 5]