Internet Draft Michael Myers, VeriSign draft-ietf-pkix-ocsp-valid-00.txt Carlisle Adams, Entrust August, 2000 Stephen Farrell, Baltimore Expires in six months Delegated Path Validation draft-ietf-pkix-ocsp-valid-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.0 Abstract OCSP [RFC2560] establishes the Internet standard for online certificate status. The baseline response type defined in [RFC2560] supports acquisition of the revocation state of a certificate. This specification builds on the OCSP framework's extensibility by defining an Internet-standard extension to OCSP that can be used to fully delegate all path validation processing to an OCSP server. 2.0 Delegated Path Validation In order to determine if a certificate is valid an application must have knowledge of the certificate itself, a set of trusted public keys from which relevant certificate chains may be constructed and the validation status of every certificate used to construct the trust chain. These data may originate from multiple sources. An industry consortium root may issue CA certificates to members of the consortium while members themselves use those CA certificates to either establish subordinate CAs or directly issue end- entity certificates. Equally, a certificate or certificate path established within one trust domain may be "cross certified" into another trust domain. Locating the certificate validation process within a trusted server reduces the technical footprint of certificate using applications and may ease integration of certificate path processing with other authorization data. The Delegated Path Validation (DPV) extension to OCSP addresses this need. Myers et. al. [Page 1]
Internet Draft Delegated Path Validation Sept. 2000 A DPV request differs from the basic request defined in [RFC2560] by the inclusion of id-pkix-ocsp-valid-req request OID and request options (if any) as illustrated below (prior knowledge of [RFC2560] is assumed): OCSP REQUEST ------------ In the requestExtensions field of TBSRequest, one extension MUST have an OID of id-pkix-ocsp-valid-req and a value of DPVOptions (see below for syntax). The initialPolicySet option enables a requestor to establish one or more initial policy identifiers as defined in [RFC2459]. The trustPoints option enables specification of one or more certificates relevant to the relying party's trust model. If included, a successful validation request will pass through at least one of these trust points, else an "unknown" response will be generated. A DPV response differs from the basic response defined in [RFC2560] in the substitution of id-pkix-ocsp-valid-rsp for id-pkix-ocsp-basic in the ResponseType field of the ResponseBytes syntax. This is illustrated as follows (again, prior knowledge of [RFC2560] is assumed): OCSP RESPONSE ------------- In the responseBytes field of OCSPResponse, responseType MUST have a value of id-pkix-ocsp-valid-rsp and response MUST have a value of DPVOCSPResponse, where DPVOCSPResponse ::= BasicOCSPResponse 4.0 Delegated Path Validation Requirements Relying party software desiring to delegate path validation to an OCSP server SHALL include a value of id-pkix-ocsp-valid-req as a requestExtension in the OCSPRequest syntax defined by [RFC2560]. id-pkix-ocsp-valid-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } One or more policy OIDs MAY be included to enable policy-based control on the OCSP server's path construction and path validation processes. Definition of any such policies and their corresponding OIDs is beyond the scope of this specification. One or more certificates MAY be included to express trust points relevant to the relying party's trust model. DPVOptions :: = SEQUENCE{ initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, trustPoints SEQUENCE OF ReqCert OPTIONAL } If neither initialPolicySet nor trustPoints are included in the request, the DPVOptions structure SHALL omit both optional fields. OCSP servers operated to perform delegated path validation SHALL include a value of id-pkix-ocsp-valid-rsp in the responseType field of the ResponseBytes syntax upon receipt of a request containing a value of id-pkix-ocsp-valid-req as defined above. Myers et. al. [Page 2]
Internet Draft Delegated Path Validation Sept. 2000 id-pkix-ocsp-valid-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } Servers that produce id-pkix-ocsp-valid-rsp responses SHALL execute path validation logic that produces outputs compliant with [RFC2459]. OCSP servers claiming compliance to this specification SHALL support the DPVOptions request syntax as follows. If a request contains a non-NULL value for initialPolicySet, all OIDs included in that set SHALL be used as initial policy identifier values in the validation logic according to [RFC2459]. If a request contains a non-NULL value for trustPoints, the receiving server MUST attempt to produce a response that incorporates at least one of these certificates. If the receiving server cannot form such a path, the server SHALL return a status value of "unknown" in the response. 5.0 Security Considerations TBD 6.0 Collected Syntax PathValidation DEFINITIONS EXPLICIT TAGS ::= {iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) X } BEGIN IMPORTS -- PKIX Extensions 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 } -- Directory Authentication Framework (X.509) Certificate FROM AuthenticationFramework { joint-iso-itu-t ds(5) module(1) authenticationFramework(7) 3 }; -- Delegated Path Validation request id-pkix-ocsp-valid-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } DPVOptions :: = SEQUENCE{ initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, trustPoints SEQUENCE OF Certificate OPTIONAL } Myers et. al. [Page 3]
Internet Draft Delegated Path Validation Sept. 2000 PolicyList ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER -- Delegated Path Validation response id-pkix-ocsp-valid-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } END 5. 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. 6. Author's Address Michael Myers VeriSign, Inc. mmyers@verisign.com Stephen Farrell Baltimore Technologies stephen.farrell@baltimore.ie Carlisle Adams Entrust Technologies cadams@entrust.com
