datatracker.ietf.org
Sign in
Version 5.7.1.p2, 2014-10-29
Report a bug

Delegated Path Validation and Delegated Path Discovery Protocol Requirements
RFC 3379

Document type: RFC - Informational (September 2002; No errata)
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Consensus: Unknown
Document shepherd: No shepherd assigned

IESG State: RFC 3379 (Informational)
Responsible AD: Jeffrey Schiller
IESG Note: Responsible: RFC Editor
Send notices to: <kent@bbn.com>, <wpolk@nist.gov>

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

[include full document text]