Delegated Path Discovery with OCSP
draft-ietf-pkix-ocsp-path-00

Versions: 00                                                            
INTERNET-DRAFT                                           Michael Myers, VeriSign
draft-ietf-pkix-ocsp-path-00.txt                      Stephen Farrell, Baltimore
Expires in six months                                    Carlisle Adams, Entrust
September 2000

                          Delegated Path Discovery with OCSP
                          <draft-ietf-pkix-ocsp-path-00.txt>

Status of this Memo

This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of [RFC2026].

Internet-Drafts are working documents of the Internet Engineering Task Force
(IETF), its areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. Internet-Drafts are draft
documents valid for a maximum of six months and may be updated, replaced, or
obsoleted by other documents at any time. It is inappropriate to use Internet-
Drafts as reference material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

OCSP [RFC2560] establishes the Internet standard for online certificate status.
An OCSP path discovery responder is an enhanced OCSP responder that provides
requestors with certification paths.  The technological and geographic diversity
of the sources of these data motivates existence of service that enables
relying-party software to acquire certification path data from an OCSP server
rather than replicate the same functionality. This specification establishes an
Internet standard extension to OCSP to address this need.

1.  Delegated Path Discovery

The path validation logic defined by [RFC2459] requires certificate-processing
systems to accumulate the set of certificates from which certificate chains may
be constructed as well as revocation data for each such certificate.  These data
may originate from diverse sources.  Commonly used technologies for retrieving
this information include X.500, LDAP, HTTP, FTP and SMTP as well as proprietary
methods.  Delegating this acquisition process to a separate server greatly
simplifies and reduces the size of public-key based credential validation
systems or other relying party software.  It may also be useful to such software
to be able to select from among various trust paths in the event multiple paths
exist.  The Delegated Path Discovery (DPD) extension to OCSP addresses these
needs.

The DPD extension to OCSP request applies to the requestExtensions syntax of the
OCSP request as outlined below (prior knowledge of [RFC2560] is assumed):




Myers et. al.                                                           [Page 1]


Internet Draft               Delegated Path Discovery                 Sept. 2000

OCSP REQUEST
------------
In the requestExtensions field of TBSRequest, one extension MUST have an OID of
id-pkix-ocsp-path-req and a value of RetryReference, where

RetryReference ::= OCTET STRING

The RetryReference enables a requestor to acquire the next of potentially
several valid paths known to the OCSP server based on a previous response. If
this field is omitted then the request is considered to be a "new" request and
the responder may return any path that meets the request criteria. If a client
does specify a RetryReference then the responder MUST NOT return any path that
was previously returned with that reference (i.e. the responder MUST either
return a different path meeting the request or an error).

A DPD response consists of the following information:

OCSP RESPONSE
-------------
In the responseBytes field of OCSPResponse, responseType MUST have a value of
id-pkix-ocsp-path-rsp and response MUST have a value of DPDOCSPResponse, where

   DPDOCSPResponse ::= SEQUENCE OF PathResponse
   -- one for each certificate included in the requestList field of TBSRequest

   PathResponse ::= SEQUENCE {
      retryReference   BIT STRING,
      certificates     SEQUENCE OF Certificate,
      crls             SEQUENCE SIZE (1..MAX) OF CertificateList OPTIONAL,
      ocspReps         SEQUENCE SIZE (1..MAX) OF OCSPResponse OPTIONAL
   }

The sequence of certificates MUST form a potentially valid certification path,
in order, from end-entity certificate (element 0 of the sequence), up to and
including a "final" CA certificate, (which need not, but MAY be self-certified).

The RetryReference SHOULD uniquely refer to all path validation data (including
the data in the current response) that has been returned to the requester with
respect to this request.

The responder MAY also include a set of CRLs and/or OCSP responses which, if
included, SHOULD relate to the certificates in the set of certificates.

2. Conformance Requirements

An OCSP server claiming compliance to this specification SHALL:

1. Upon receipt of an authorized path discovery request, where possible, deliver
to the requestor a collection of certificates and optionally CRLs and other OCSP
responses that may be used to validate a certificate according to [RFC2459];




Myers et. al.                                                           [Page 2]


Internet Draft               Delegated Path Discovery                 Sept. 2000

2. Either establish a stateful association enabling a requestor to serially ask
for the next path via the retry option, to the extent that multiple validation
paths exist and the receiving OCSP server is aware of these paths or respond
with a noStateMaintained error to all retry requests if the server does not
maintain state; and

3. In the event that the server is stateful and a prior response was the last
path known to the responder, respond to subsequent retry requests with a
noMoreData value in OSCPResponseStatus.

Requestors and responders SHALL at a minimum support the issuerSerial
identification form of the ReqCert syntax of OCSP.  Other identification forms
MAY be supported according to local needs.

3. Security Considerations

A responder that only supports this service need not be trusted by a client for
certificate status since it only supplies data that is signed by CAs. However,
the client is trusting the responder to make an "honest effort" to find a path
(or an additional path, if more than one exist). Since the client is presumably
using the certificates for some important function, denial-of-service attacks on
the responder are still potentially very serious and implementers should take
steps to ensure the robustness of their implementations.

MORE TBD

4. References

[RFC2560]  Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C.,
           "X.509 Internet Public Key Infrastructure Online Certificate
           Status Protocol", RFC 2560

[RFC2459]  Housley, R., Ford, W., Polk, T, & Solo, D., "Internet
           Public Key Infrastructure - X.509 Certificate and CRL
           profile", RFC2459.

5. Author's Addresses

Michael Myers
VeriSign, Inc.
mmyers@verisign.com

Stephen Farrell
Baltimore Technologies
stephen.farrell@baltimore.ie

Carlisle Adams
Entrust Technologies
cadams@entrust.com





Myers et. al.                                                           [Page 3]

Internet Draft               Delegated Path Discovery                 Sept. 2000


Appendix A : Collected Syntax

PathDiscovery DEFINITIONS EXPLICIT TAGS ::=
            {iso(1) identified-organization(3)
             dod(6) internet(1) security(5) mechanisms(5) pkix(7)
             X -- TBS -- }

BEGIN

IMPORTS

      -- PKIX
            Certificate, CertificateList
             FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5)
                   pkix(7) id-mod(0) id-pkix1-explicit-88(1)}

      -- OCSP
             id-pkix-ocsp
             FROM OCSP {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5)
                  pkix(7) X -- TBD -- };

-- Delegated Path Discovery request
id-pkix-ocsp-path-req    OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

-- the only indicator in the request
RetryReference ::= OCTET STRING --return next path, if one exists }

-- Delegated Path Discovery response
id-pkix-ocsp-path-rsp    OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

DPDResponse  :: =  SEQUENCE {
      ref           RetryReference,
      certs         SEQUENCE OF Certificate,
      crls      [0] SEQUENCE OF CertificateList OPTIONAL,
      otherResps    SEQUENCE OF OCSPResponse OPTIONAL}


END