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. The CertStatus field of BasicOCSPResponse SHALL be interpreted as follows when the value of responseType is id-pkix-ocsp-valid. DPVCertStatus ::= CHOICE { valid [0] IMPLICIT NULL, invalid [1] IMPLICIT OCTET STRING Reasons, unknown [2] IMPLICIT NULL } The valid state SHALL be interpreted as indicating that the certificate at a minimum satisfies the path validation rules defined in [RFC3280]. Responders MAY further predicate production of a valid response on additional criteria. Myers [Page 4] Internet Draft DPV&DPD Over OCSP January 2003 The invalid state SHALL be interpreted as indicating that the certificate does not satisfy one or more conditions necessary to the production of a valid state. Responders MAY indicate in Reasons the relevant condition(s). The unknown state SHALL be interpreted as indicating that the responder has in- sufficient knowledge of the certificate's status. 5.2.2 Use of Extended OCSP Response If a request does not indicate a validation policy, responders SHALL include Ex- tendedOCSPResponse in BasicOCSPResponse and SHALL identify in the policy field of ExtendedOCSPResponse syntax the OID identifying the policy in effect when the response was produced. In the event that the organization operating the re- sponder has not acquired an OID for this purpose a NULL value SHALL be used. If Flags is present in RequestOptions, responders SHALL produce ExtendedOCSPRe- sponse as follows: a. if the returnPath bit is set, responders SHALL return in the path field all certificates used to validate the subject certificate; b. if the returnEERevInfo bit is set, responders SHALL return those data used to establish the subject certificate's validity in the revInfo field; c. if the returnTSP bit is set, responders SHALL return a time stamp in the timeStamp field. d. if the returnPolicy bit is set, responders SHALL return in the policy field the OID identifying the policy in effect when the response was produced. e. if the returnReq bit is set, responders SHALL return in reqContents field the contents of the received DPVOptions in order to present to another relying party the important components of the request. Responders SHALL otherwise include ExtendedOCSPResponse as follows: If a value for token is present in the params field of DPVOptions, responders SHALL copy the token value into the token field of the ExtendedOCSPResponse. If a value for requestExtensions is present in the DPV request (thus indicating the presence of requestor-specified parameters), responders shall perform a hash across this value using the SHA-1 algorithm and include this resulting value in the paramHash field. If requestorName is included the TBSRequest element of OCSPRequest (see [RFC2560]), responders SHALL include this value in the reqID field of Extende- dOCSPResponse. Where client authentication is important to the responder's pol- icy (e.g. authorization to access the service), a lower-layer protocol may be used to establish this authentication. If used, responders SHOULD copy the cli- ent-auth identity into the reqID field of ExtendedOCSPResponse. Myers [Page 5] Internet Draft DPV&DPD Over OCSP January 2003 6. Delegated Path Discovery (DPD) [RFC3280] requires certificate-processing systems to accumulate the set of cer- tificates from which certificate chains may be constructed as well as revocation data for each such certificate. These data may originate from diverse sources using diverse technologies. Delegating this aggregation simplifies relying party certificate validation. This section defines means by which OCSP can be used to integrate PKI information acquisition across these diverse technology platforms. 6.1 DPD Request A DPD request SHALL be identified by the id-pkix-ocsp-path-req OID in the re- questExtensions field of TBSRequest. id-pkix-ocsp-path-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } A NULL value SHALL be included as the value of the extension in the event no other parameters are to be included in the request. Otherwise, requestors SHALL use the ExtendedOCSPRequest syntax to specify such parameters. It may be useful for requestors to acquire a given path from among several. In this case requestors SHALL indicate in the numPaths field of ExtendedOCSPRequest the maximum number of paths to be included in the response. Requestors then ap- ply local path selection logic to determine if the intended path is among that set. In the event a target path is not delivered, requestors can increase the value of numPaths and try again. Requestors should note that two successive re- sponses bearing the same number of paths indicates that the responder has no more candidate paths. 6.2 DPD Response A DPD response SHALL be identified by the id-pkix-ocsp-path-rsp OID in the Re- sponseType field of the ResponseBytes syntax. An authoritative DPD response (that is, no errors) SHALL consist of ExtendedOC- SPResponse which SHALL, at a minimum, contain a value for the pathInfo field UNLESS no paths are available in which case an error SHALL be returned. Respond- ers SHALL present ExtendedOCSPResponse as the value of response in the response- Bytes syntax of ResponseBytes (see [RFC2560]). Responders SHALL develop a path or paths correspondent to a requestor-specified path discovery policy when such is indicated in the request. If a request does not indicate a path discovery policy, responders SHALL include ExtendedOCSPRe- sponse in BasicOCSPResponse and SHALL identify in the policy field of Extende- dOCSPResponse syntax the OID identifying the policy in effect when the response was produced. In the event that the organization operating the responder has not acquired an OID for this purpose a NULL value SHALL be used. Responders aware of multiple candidate paths that satisfy requestor-specified parameters SHALL respond with the lesser of the number of qualified paths or the number of paths specified by the requestor in numPaths. Myers [Page 6] Internet Draft DPV&DPD Over OCSP January 2003 If the requestor did not specify numPaths then, by default, the responder MUST return a single certification path for each end-entity certificate in the DPD request. The returned path (or paths), if any, SHALL be in serial order from end-entity certificate up to and including the trust anchor UNLESS the trust anchor is a self-signed certificate in which case that certificate SHALL NOT be included in the path. If no paths are discoverable, this state SHALL be indicated by a NULL value for the pathInfo field of ExtendedOCSPResponse. If Flags is present in ExtendedOCSPRequest, responders SHALL further produce Ex- tendedOCSPResponse as follows: a. setting returnPath is redundant for a DPD request; b. if the returnEERevInfo bit is set, responders SHALL return those data used to establish the subject certificate's validity in the revInfo field of ExtendedOCSPResponse. c. if the returnCARevInfo bit is set, responders SHALL return those data used to establish the validity of the path in the revInfo field of ExtendedOCSPResponse. d. revocation information MAY be either CRLs, OCSP responses or both according to the settings of the returnCRL and returnOCSP bits. If neither of these bits is set when either returnEERevInfo or returnCARevInfo is set, responders SHALL include CRLs and MAY include OCSP responses. If requestorName is included the TBSRequest element of OCSPRequest (see [RFC2560]), responders SHALL include this value in the reqID field of Extende- dOCSPResponse. Where client authentication is important to the responder's pol- icy (e.g. authorization to access the service), a lower-layer protocol may be used to establish this authentication. If used, responders SHOULD copy the cli- ent-auth identity into the reqID field of ExtendedOCSPResponse. 6.3 Determination of Response States [RFC3379] defines five closely related DPD response states that requestors must be able to discern from a DPD response. In abbreviated form, these are: 1. one or more policy-compliant paths, all requested revInfo present; 2. one or more policy-compliant paths, some requested revInfo present; 3. one or more policy-compliant paths, no requested revInfo present; 4. no policy-compliant paths were discovered; and 5. an error occurred in path construction. Requestors can derive these states from a DPD response as follows. Myers [Page 7] Internet Draft DPV&DPD Over OCSP January 2003 Errors are reported as OCSPResponseStatus (see [RFC2560]) in which case no path data is present in the response. A value of successful in OCSPResponseStatus indicates the presence of pathInfo in ExtendedOCSPResponse. This value may be NULL, indicating that no paths were discovered. Requestors that did not request revInfo will not receive revInfo. Else each certificate in each path returned via the pathInfo structure may or may not have revInfo associated with it. Ab- sence of revInfo for a given certificate in the pathInfo structure enables re- questor determination of the first three states noted above. 7. Security Considerations This protocol enables the projection of trust across diverse domains. It can only be as reliable as the key management foundation upon which it is deployed. Implementers and integrators are strongly encouraged to consider the principles of sound key management prior to deploying this protocol. 8. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., Adams, C., "Online Certificate Status Protocol -û OCSP", RFC 2560, June 1999. [RFC3280] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, April 2002. [RFC3379] Pinkas, D., Housley, R., "DPV and DPD Protocol Requirements", RFC 3379, September 2002. 9. Author Address Michael Myers Heatherdale Group LLC Mesa, AZ mmyers@fastq.com +602.739.7744 10. ASN.1 Module TBSL Myers [Page 8]