Network Working Group                                          D. PinkasRequest for Comments: 3379                                          BullCategory: Informational                                       R. Housley                                                        RSA Laboratories                                                          September 2002        Delegated Path Validation and Delegated Path Discovery                         Protocol RequirementsStatus 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 Requirements4.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 validationPinkas & Housley             Informational                      [Page 5]