draft-ietf-pkix-ocsp-dpvdpd-00.txt

PKIX的RFC英文文档

Internet Draft                                                     Michael Myers
draft-ietf-pkix-ocsp-dpvdpd-00.txt                             Heatherdale Group
January, 2003
Expires in six months

DPV and DPD over OCSP
draft-ietf-pkix-ocsp-dpvdpd-00.txt

Status of this memo

This document is an Internet-Draft and is in full conformance with all pro-
visions of Section 10 of RFC 2026.

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.

1.	Abstract

This specification standardizes means by which the extensibility mechanisms of 
OCSP are to be used for Delegated Path Validation (DPV) and Delegated Path Dis-
covery (DPD). Familiarity with OCSP core syntax [RFC2560] is assumed.

2.	Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in upper-
case, as shown) are to be interpreted as described in [RFC2119].

3.	Overview

An OCSP request consists of a protocol version number, a service-specific object 
identifier (OID) and service-specific request data.  As defined by [RFC2560], 
this structure may be extended.   An OCSP response similarly consists of a 
structure that can be extended to address a requestor's need for ancillary data 
related to a given service.  [RFC2560] defines one such basic service.  For the 
purposes of this specification, that service is referred to as the Online Revo-
cation Service (ORS).  The new services of Delegated Path Validation (DPV) and 
Delegated Path Discovery (DPD) are of recent and particular interest.

The DPV mechanisms defined in this document use the BasicOCSPResponse syntax de-
fined in [RFC2560].  Closed, self-contained environments may find that the minor 
variations in the shared use of this syntax optimizes their investment in PKI.  

Myers                                                                   [Page 1]
Internet Draft                 DPV&DPD Over OCSP                    January 2003

Existing OCSP implementations are enabled to address simple DPV needs by: 1) use 
of a DPV-specific OID in the request; 2) responder's performance of compliant 
path validation logic; 3) use of a DPV-specific OID in the response in place of 
the ietf-pkix-ocsp-basic OID; and 4) requestor interpretation the {valid, inva-
lid, unknown} binding of certStatus syntax as compared to the {good, revoked, 
unknown) binding defined by ietf-pkix-ocsp-basic.

However, the requirements of [RFC3379] motivate the definition of ExtendedOC-
SPRequest and ExtendedOCSPResponse to accommodate more complex environments.  
Additionally, the DPV and DPD services defined here share a high degree of com-
monality regarding their use of policy-related syntax.

4.	Definition of Extended OCSP Request and Extended OCSP Response

This section defines syntax useful to both the DPV and DPD services.  Require-
ments governing use of this syntax within the OCSP transaction envelope defined 
by [RFC2560] are in each instance established in following relevant sections.

ExtendedOCSPRequest:: = SEQUENCE{
    intialPolicySet   [0]  SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER OPTIONAL,
    trustPoints       [1]  SEQUENCE OF ReqCert OPTIONAL,
    token             [2]  OCTET STRING OPTIONAL,
    revInfo           [3]  SEQUENCE OF RevocationInfo OPTIONAL,
    numPaths          [4]  INTEGER OPTIONAL,
    flags             [5]  Flags OPTIONAL }

Flags ::= BIT STRING {
    returnPath        (0),
    returnEERevInfo   (1),
    returnCARevInfo   (2),
    returnCRL         (3),
    returnOcsp        (4),
    returnTsp         (5),
    returnReq         (6) }

ExtendedOCSPResponse  ::= SEQUENCE {
    pathInfo      [0] SEQUENCE OF SEQUENCE OF PathInfo OPTIONAL;
    timeStamp     [1] OCTET STRING OPTIONAL;
    policy        [2] OBJECT IDENTIFIER OPTIONAL,
    token         [3] OCTET STRING OPTIONAL,
    paramHash     [4] OCTET STRING OPTIONAL,
    reqContents   [5] DPVOptions OPTIONAL,
    reqID         [6] GeneralName OPTIONAL }

PathInfo :: = SEQUENCE {
    path          Certificate
    revInfo       RevInfo }

RevInfo::= CHOICE {
    cRL            [0] CertificateList,
    oCSP           [1] OCSPResponse }


Myers                                                                   [Page 2]
Internet Draft                 DPV&DPD Over OCSP                    January 2003

Note that the pathInfo field of ExtendedOCSPResponse is a sequence of a sequence 
of the pair {certificate, revocation info}.  A single path is defined by the in-
terior SEQ OF while the exterior SEQ OF enables delivery of multiple paths in 
means that enable requestors to easily identify the presence of and parse multi-
ple paths.  This structure also has the benefit of putting a certificate's revo-
cation information directly alongside the certificate.

5.	Delegated Path Validation (DPV)

At a minimum, a DPV transaction consists of:

1. an OCSP request with an OID value of id-pkix-ocsp-valid-req in the    
   requestExtensions field of TBSRequest; and

2. a response of BasicOCSPResponse with an OID value of id-pkix-ocsp-valid-rsp 
   in the ResponseType field of the ResponseBytes syntax.

That is, in the minimal case, a requestor (and, correspondingly, existing imple-
mentations) see very little difference in bits on the wire between RFC2560-based 
Online Revocation Service (ORS) and DPV.  The important difference occurs on the 
responder's side, where full compliance to the path validation logic of 
[RFC3280] is mandated and where other centralized security policy relevant proc-
esses may occur.

Requestors can ask for ancillary information related to the responder's valida-
tion processes.  In this instance, an OID value of id-pkix-ocsp-valid-ext-rsp is 
used in the responseExtensions field of ResponseData of BasicOCSPResponse syntax 
to signal the presence of ExtendedOCSPResponse syntax in responseExtensions.

In instances where it is important to authenticate the identity of a responder 
prior to acceptance of its response, lower layer security protocols could be 
used to establish the identity of the intended responder.  Authoritative DPV re-
sponses are required to be digitally signed.  To the extent the identity con-
tained in the certificate used to validate a response is an acceptable form of 
response authentication, this method may suffice.

In instances when it is useful for the DPV transaction to identify a requestor 
in the response, requestors MAY include a value for requestorName in the TBSRe-
quest element of OCSPRequest.
    
5.1	DPV Request Requirements

A DPV request SHALL include a value of id-pkix-ocsp-valid-req in the requestEx-
tensions field of TBSRequest.

id-pkix-ocsp-valid-req   OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

A NULL value SHALL be included as the value of the extension when no other pa-
rameters are to be included in the request.  Otherwise, requestors SHALL use the 
ExtendedOCSPRequest syntax to specify such parameters.




Myers                                                                   [Page 3]
Internet Draft                 DPV&DPD Over OCSP                    January 2003

5.1.1	Use of Extended OCSP Request

A DPV requestor MAY use the ExtendedOCSPRequest syntax to specify policy-
dependant parameters.

The initialPolicySet option enables a requestor to establish one or more initial 
policy identifiers.  Definition of such policies is beyond the scope of this 
specification.

The trustPoints option enables specification of one or more certificates 
relevant to the relying party's trust model.

The token field enables a requestor to specify a value to be included in the re-
sponder's response.  This field may relate to the nature or reason for the 
query.

5.2	DPV Response Requirements

5.2.1	Use of Basic OCSP Response

DPV responders SHALL execute the path validation logic defined by [RFC3280].  
The responseBytes field of a DPV response SHALL contain the OID id-pkix-ocsp-
valid-rsp in the ResponseType field of the ResponseBytes syntax.  DPV response 
messages SHALL be digitally signed if and only if they contain a value for re-
sponseBytes. Errors SHALL be reported via the OCSPResponseStatus element of OC-
SPResponse (see [RFC2560]).  Such responses are unsigned.

id-pkix-ocsp-valid-rsp    OBJECT IDENTIFIER ::= { id-pkix-ocsp X }

If a DPV request contains a non-NULL value for initialPolicySet, all OIDs in-
cluded in that set SHALL be used as initial policy identifier values in the path 
validation logic defined by [RFC3280].

If a DPV request contains a non-NULL value for trustPoints, the responder
SHALL attempt to produce a response that traverses at least one of these trust 
points.  A responder MAY cease production of a response upon detection of the 
first valid state. If the responder cannot form a path that traverses at least 
one of these trust points, the responder SHALL return a status value of unknown.