Delegated Path Validation and Delegated Path Discovery Protocol Requirements
RFC 3379

Document Type RFC - Informational (September 2002; No errata)
Authors Russ Housley  , Denis Pinkas 
Last updated 2015-10-14
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3379 (Informational)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Jeffrey Schiller
IESG note Responsible: RFC Editor
Send notices to <>
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.


   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

   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",
   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
Show full document text