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 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