Internet Draft Michael Myers draft-ietf-pkix-ocspv2-02.txt TraceRoute Security March, 2001 Rich Ankney Expires in six months Certco Carlisle Adams Entrust Stephen Farrell Baltimore Carlin Covey Cylink Online Certificate Status Protocol, version 2 draft-ietf-pkix-ocspv2-02.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 document advances the specification of RFC 2560 [RFC2560] towards the acquisition of any data relevant to determining a digital certificate's reliability; interoperability with [RFC2560] is maintained. Such data include a certificate's revocation status, it's validation status and ancillary information supporting these assertions. Three services are defined: Online Revocation Status (ORS); Delegated Path Validation (DPV); and Delegated Path Discovery (DPD). Ancillary extensions defined in [RFC2560] are also maintained. The means by which a certificate may be identified is also expanded. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document (in uppercase, as shown) are to be interpreted as described in [RFC2119]. Myers, et al. [Page 1] Internet Draft OCSPv2 March 2001 TABLE OF CONTENTS 1. Abstract 1 2. Protocol Overview 3 3. General Protocol Requirements 4 3.1 Requests 4 3.1.1 Service Identification 5 3.1.2 Certificate Identification 5 3.1.3 Signed Requests 6 3.2 Response Envelope 6 3.2.1 Definition of Basic OCSP Response 7 3.2.2 Error Responses 7 3.2.3 Signed Responses 8 3.2.4 Response Acceptance Criteria 8 3.3 Certificate Content 8 3.4 Authorized Responders 8 3.5 Use of ASN.1 Syntax 10 3.6 Application to Attribute Certificates 10 3.7 Mandatory and Optional Cryptographic Algorithms 10 4. Service Deployment Requirements 10 5. Online Revocation Status 11 5.1 Request 11 5.2 Response 11 5.2.1 Interpretation of CertStatus Field 11 5.2.2 Response Signature Production and Validation 12 5.2.3 Interpretation of Time-related Fields 12 5.2.4 Other Fields 13 5.2.5 CA Key Revocation 13 6. Delegated Path Validation 13 6.1 Request 13 6.2 Response 14 6.2.1 Interpretation of CertStatus Field 14 6.3 Processing Considerations 15 7. Delegated Path Discovery 15 7.1 Request 15 7.2 Response 16 7.3 Processing Considerations 17 8. Extensions 17 8.1 Nonce 17 8.2 CRL References 17 8.3 Acceptable Response Types 18 8.4 Archive Cutoff 18 8.5 Service Locator 18 8.6 CRL Entry Extensions 19 9. Security Considerations 19 10. Acknowledgments 19 11. References 19 12. Authors' Addresses 20 13. Appendix A. OCSP over HTTP 20 14. Appendix B. OCSP in ASN.1 21 15. Appendix C. MIME registrations 21 Myers, et al. [Page 2] Internet Draft OCSPv2 March 2001 2. Protocol Overview OCSP is a online request-response PKI information acquisition protocol composed of generic envelope and a set of standardized request and response types. An OCSP request message is composed of protocol version number, a request type object identifier and other request data relevant to a particular request type. Requests may be digitally signed. Responses are correspondingly structured as an OID and associated response data. Responses may or may not be digitally signed depending on service request type or error processing. A request-response pair defines a service type. The Online Revocation Status (ORS), Delegated Path Validation (DPV) and Delegated Path Discovery (DPD) service types are of particular interest. The ORS service enables certificate processing software to obtain timely information regarding the revocation status of a certificate beyond that typically available through the use of CRLs. While useful to the deployment of this service in certain instances, CRLs are not mandatory to implement ORS. The DPV service enables an environment to offload certificate path validation complexity to a centralized server, thereby yielding benefits to thin clients and enterprise security policy management. DPV provides client-side control points whereby a client may govern essential aspects of a server's technical behavior. These are: a. OID-based specification of policies relevant to path validation logic; b. specification of paths or partial paths to be respected by the server; c. a means to specify a time context for historical references; d. inclusion of revocation information, whether CRLs or OCSP; and e. flags that stimulate a DPV server to return ancillary information, including: the path used, the revocation information relied on, a timestamp on the entire process and an OID-based identification of the policy or policies enforced in the validation process. DPV control points are optional elements. Minimally, the relationship between a DPV client and a DPV server is an answer to the question "is this certificate valid now?" The control points enable a client to dynamically tailor its definition of "valid" in accordance with localized policies. The DPD service enables certificate processing software to acquire the certificate and revocation data a DPV server might otherwise use, thereby yielding benefits in integrating a single PKI information access protocol across a potentially diverse set of more general data retrieval mechanisms (e.g. X.500, LDAP, HTTP, FTP, etc.) As with DPV, the DPD service specification provides for optional client-side control points. These are: a. an iterative mechanism that enables a client to walk through several technically valid paths to discover an path acceptable to the client's operational policies (should such multiple paths exist); Myers, et al. [Page 3] Internet Draft OCSPv2 March 2001 b. OID-based specification of policies relevant to path validation logic; c. specification of paths or partial paths to be respected by the server; d. a means to specify a time context for historical references; and e. flags that stimulate a DPD server to return ancillary information, including: a timestamp on the entire process; an OID-based identification of the policy or policies enforced in the path construction process; and whether or not the client prefers CRLs, OCSP responses or either (in some instances one or the other might not be available to a DPD server). OCSP also provides for the use of extensions that enable specialization of service types towards unique circumstances. These extensions, originally defined by [RFC2560] and carried forward in this document, include: a. Nonces useful for replay detection needs; b. CRL references, enable clients to acquire the CRLs used; c. Archive Cutoff specification applicable to historical references; d. CRL entry extensions for a acquisition of specific CRL content; and e. Service Locator mechanism that enables client-driven server redirection. 3. General Protocol Requirements Service requests and responses SHALL conform to this Section 3.0. Service definitions MAY extend these requirements. 3.1 Requests Requests SHALL include the following content: OCSPRequest ::= SEQUENCE { tbsRequest TBSRequest, optionalSignature [0] EXPLICIT Signature OPTIONAL } TBSRequest ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, requestorName [1] EXPLICIT GeneralName OPTIONAL, requestList SEQUENCE OF Request, requestExtensions [2] EXPLICIT Extensions OPTIONAL } Version ::= INTEGER { v1(0), v2(1) } Myers, et al. [Page 4] Internet Draft OCSPv2 March 2001 A requestExtensions field SHALL ONLY be included if the requestExtensions field contains one or more values, else the field SHALL be omitted from OCSPRequest. 3.1.1 Service Identification As a general rule, service request types are identified by an OID in the requestExtensions field of TBSRequest. An exception is made for the Online Revocation Status (ORS) service. Other than ORS, the requests of all OCSP-based service SHALL be an OID identifying the requested service in the requestExtensions field of TBSRequest; he ORS service MAY be so identified. To determine if an request is or is not a request for ORS service, servers SHALL implement logic equivalent to the following: a. Upon receipt of a request, examine the contents of the requestExtensions field. b. If the requestExtensions field is absent, the request SHALL be considered an ORS service request. c. If the requestExtensions field contains one or more OIDs, then if any one of those values matches the ORS service type OID defined in this document, the request SHALL be considered an ORS service request. 3.1.2 Certificate Identification The ReqCert structure enables clients to identify a certificate in the means most suitable to the technical constraints of their local environment. This structure interoperably extends the CertID definition defined in [RFC2560]. The following options are available: ReqCert ::= CHOICE { certID CertID, issuerSerial [0] IssuerandSerialNumber, pKCert [1] Certificate, name [2] GeneralName, certHash [3] OCTET STRING} CertID ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, issuerNameHash OCTET STRING, -- Hash of Issuer's DN issuerKeyHash OCTET STRING, -- Hash of Issuers public key serialNumber CertificateSerialNumber } As noted, [RFC2560] interoperablity can be obtained through the use of the certID element of the ReqCert CHOICE. If certID is used in ReqCert, the value for version in the tbsRequest field of OCSPRequest SHALL be v1. If any other choice in ReqCert is used, the value for version SHALL be v2. Clients claiming compliance to this specification SHALL support either issuerSerial OR PKCert. Servers claiming compliance to this specification SHALL be capable of responding to both. Support for other options is STRONGLY ENCOURAGED. Myers, et al. [Page 5] Internet Draft OCSPv2 March 2001 The value for issuerNameHash SHALL be calculated over the DER encoding of the issuer's name field in the certificate being checked. The value for issuerKeyHash SHALL be calculated over the value of the BIT STRING subjectPublicKey key field (excluding tag and length) in the issuer's certificate. The hash algorithm used for both these hashes, is identified in hashAlgorithm. serialNumber is the serial number of the certificate for which status is being requested. 3.1.3 Signed Requests Service definitions MAY require the use of digital signatures over requests. When required, signed request SHALL be produced as follows: Signature ::= SEQUENCE { signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} Request ::= SEQUENCE { reqCert ReqCert, singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL } Signed requests SHALL identify the requestor in the requestorName field of TBSRequest (see Section 3.1). Signed requests MAY include in the certs field of the Signature element certificates that assist the OCSP responder in verifying the requestor's signature. 3.2 Response Envelope Responses SHALL contain a responseStatus field. A value for the responseBytes field SHALL be included if the value for responseStatus is "successful". A value for the responseBytes field MAY be included for responseStatus values other than "successful". The responseBytes field SHALL be composed of an OBJECT IDENTIFIER identifying the response type and the bytes of the actual response encoded as an OCTET STRING. OCSPResponse ::= SEQUENCE { responseStatus OCSPResponseStatus, responseBytes [0] EXPLICIT ResponseBytes OPTIONAL } OCSPResponseStatus ::= ENUMERATED { successful (0), malformedRequest (1), internalError (2), tryLater (3), --(4) is not used for legacy reasons sigRequired (5), unauthorized (6), noMoreData (7) } Myers, et al. [Page 6] Internet Draft OCSPv2 March 2001 ResponseBytes ::= SEQUENCE { responseType OBJECT IDENTIFIER, response OCTET STRING } 3.2.1 Definition of Basic OCSP Response This section defines syntax useful to both the ORS and DPV services. Other services MAY reuse this syntax as needs dictate. In cases where this syntax is used, service definitions SHALL provide a definition for the certStatus field of SingleResponse. BasicOCSPResponse ::= SEQUENCE { tbsResponseData ResponseData, signatureAlgorithm AlgorithmIdentifier, signature BIT STRING, certs [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL } ResponseData ::= SEQUENCE { version [0] EXPLICIT Version DEFAULT v1, responderID ResponderID, producedAt GeneralizedTime, responses SEQUENCE OF SingleResponse, responseExtensions [1] EXPLICIT Extensions OPTIONAL } ResponderID ::= CHOICE { byName [1] Name, byKey [2] KeyHash } SingleResponse ::= SEQUENCE { reqCert ReqCert, certStatus CertStatus, thisUpdate GeneralizedTime, nextUpdate [0] EXPLICIT GeneralizedTime OPTIONAL, singleExtensions [1] EXPLICIT Extensions OPTIONAL } 3.2.2 Error Responses A server produces the "malformedRequest" response if the request received does not conform to the required syntax. The response "internalError" indicates that the server reached an inconsistent internal state. The query should be retried, potentially with another responder. In the event that a server is operational but unable to return a status for the requested certificate, the "tryLater" response can be used to indicate that the service exists, but is temporarily unable to respond. The response "sigRequired" is returned in cases where the server requires the client sign the request in order to construct a response. The response "unauthorized" is returned in cases where the client is not authorized to make this query to this server. Myers, et al. [Page 7] Internet Draft OCSPv2 March 2001 The response "noMoreData" is returned in cases where the server has previously returned the last positive response to a related sequence of requests. 3.2.3 Signed Responses Response messages containing only a value for responseStatus SHALL NOT be digitally signed. Response signatures SHALL be computed over the DER encoding of the tbsRequest structure. 3.2.4 Response Acceptance Criteria Clients SHALL reject as invalid any response that does not satisfy all of the following criteria: a. the certificate(s) identified in a received response matches that (or those) identified in the corresponding request; b. the signature on the response is valid; c. the identity of the signer matches the intended recipient of the request; d. the signer is currently authorized to sign the response; e. when available, the time at which the status being indicated is known to be correct is sufficiently recent; and f. when available, the time at or before which newer information will be available is greater than the current time. 3.3 Certificate Content Certificate-producing entities SHALL be capable of including the AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1) in certificates. Alternatively, the accessLocation for the OCSP provider may be configured locally at the OCSP client. Certificate-producing entities supporting this protocol SHALL be capable of providing for the inclusion of a value for a uniformResourceIndicator (URI) accessLocation and the OID value id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE. The value of the accessLocation field in the subject certificate defines the transport (e.g. HTTP) used to access the OCSP responder and may contain other transport dependent information (e.g. a URL). 3.4 Authorized Responders The key that signs a certificate's status information need not be the same key that signed the certificate. It is necessary however to ensure that the entity signing this information is authorized to do so. Therefore, a certificate's issuer SHALL either: Myers, et al. [Page 8] Internet Draft OCSPv2 March 2001 a. sign the OCSPresponses itself using a private key under the control of the issuer; or b. explicitly delegate this authority to another entity. OCSP signing delegation SHALL be designated by the inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate extension included in the OCSP response signer's certificate. This certificate MUST be issued directly by the CA that issued the certificate in question. Explicit delegation of OCSP signing authority SHALL be indicated by inclusion of the following value in the extendedKeyUsage extension of certificate needed to validate an OCSP response signature produced by such an entity: id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9} Systems or applications that rely on OCSP responses SHALL be capable of detecting and enforcing use of the id-ad-ocspSigning value as described above. They MAY provide a means of locally configuring one or more OCSP signing authorities, and specifying the set of CAs for which each signing authority is trusted. They SHALL reject the response if the certificate required to validate the signature on the response fails to meet at least one of the following criteria:ee a. Matches a local configuration of OCSP signing authority for the certificate in question; b. is a certificate corresponding to a private key under control of the CA that issued the certificate in question; or c. includes a value of id-ad-ocspSigning in an ExtendedKeyUsage extension and is issued by the CA that issued the certificate. Additional acceptance or rejection criteria may apply to either the response itself or to the certificate used to validate the signature on the response. Since an Authorized Responder provides status information for one or more CAs, OCSP clients need to know how to check that an Authorized Responder's certificate has not been revoked. CAs may choose to deal with this problem in one of three ways: - A CA may specify that an OCSP client can trust an Authorized Responder for the lifetime of the responder's certificate. The CA does so by including the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical extension. The value of the extension is NULL. CAs issuing such a certificate should realize that a compromise of the Authorized Responder's key, is as serious as the compromise of a CA key used to sign CRLs, at least for the validity period of this certificate. CAs may choose to issue this type of certificate with a very short lifetime and renew it frequently. id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 } Myers, et al. [Page 9] Internet Draft OCSPv2 March 2001 - A CA may specify how the responder's certificate is to be checked for revocation. This can be done using CRL Distribution Points if the check should be done using CRLs or CRL Distribution Points, or Authority Information Access if the check should be done in some other way. Details for specifying either of these two mechanisms are available in [RFC2459]. - A CA may choose not to specify any method of revocation checking for the responder's certificate, in which case, it would be up to the OCSP client's local security policy to decide whether that certificate should be checked for revocation or not. 3.5 Use of ASN.1 Syntax The ASN.1 syntax used in this document imports terms defined in [RFC2459] and [RFC2630]. For Signature calculation, the data to be signed is encoded using the ASN.1 distinguished encoding rules (DER) [X.690]. ASN.1 EXPLICIT tagging is used as a default unless specified otherwise. The terms imported from elsewhere are: Extensions, CertificateSerialNumber, SubjectPublicKeyInfo, Name, AlgorithmIdentifier, CRLReason and IssuerAndSerialNumber. 3.6 Application to Attribute Certificates OCSP MAY be used without modification to provide status on attribute certificates (ACs) conforming to [ACPROF]. Note that since [ACPROF], section 4.2.3, mandates that the issuer field uses a single X.500 name to identify the AC issuer, and also ([ACPROF], section 4.5) mandates that an AC issuer cannot also be a PKC issuer (at least using the same name/key), there are no syntactic changes required to support ACs. An OCSP responder that only supports PKCs will treat a request for status on an AC in the same way as it would treat a request for an issuer/serial combination for which it had no information. That is, a conforming OCSP responder need not have any specific ability to handle ACs. 3.7 Mandatory and Optional Cryptographic Algorithms Clients and servers SHALL support the RSA signature algorithm in accordance with RFC 2437 [RFC2437] and the SHA1 hashing algorithm as defined in FIPS Pub 180-1 [SHA1]. DSA signature support MAY be provided. If provided, this algorithm SHALL be implemented in accordance with FIPS Pub 186 [DSS]. 4. Service Deployment Requirements This document defines three standard services: Online Revocation Status (ORS), Delegated Path Validation (DPD) and Delegated Path Discovery (DPD). Other services MAY be defined for environments with more local needs. Environments MAY deploy any or all of these services in any combination. That is, a server MAY be implemented and operated to only perform the DPD service.Equivalently, delivery of the ORS service is NOT required to deliver the DPV service. Servers SHOULD be capable of delivering all three services. Myers, et al. [Page 10] Internet Draft OCSPv2 March 2001 5. Online Revocation Status This section defines the Online Revocation Status (ORS) service. This service enables certificate processing software to determine if a certificate is or is not revoked. This information MAY be recorded in non-CRL formats. While useful to the deployment of this service in certain instances, CRLs are NOT required to implement ORS. Responders SHALL be capable of producing responses of the id-pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be capable of receiving and processing responses of the id-pkix-ocsp-basic response type. The value for response SHALL be the DER encoding of BasicOCSPResponse. 5.1 Request An ORS request SHALL conform to the specifications detailed in Section 3.1 of this document. An ORS request MAY be digitally signed. Clients are STRONGLY ENCOURAGED to include a value of id-pkix-ocsp-ors-req as a value for the requestExtensions field. Servers claiming compliance to this OCSPv2 specification SHALL: 1) be capable of recognizing the id-pkix-ocsp-ors-req value; and 2) be capable of identifying ORS requests according to the mechanisms described in Section 3.1.1 of this document. id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-ors-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } 5.2 Response The responseType field of an ORS response SHALL contain a value of id-pkix-ocsp- basic: id-pkix-ocsp OBJECT IDENTIFIER ::= { id-ad-ocsp } id-pkix-ocsp-basic OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 } The responseBytes field of an ORS response SHALL be composed of the BasicOCSPResponse syntax defined in Section 3.2.1 of this document. 5.2.1 Interpretation of CertStatus Field The CertStatus field of BasicOCSPResponse SHALL be interpreted as follows when the value of responseType is id-pkix-ocsp-basic. ORSCertStatus ::= CHOICE { good [0] IMPLICIT NULL, revoked [1] IMPLICIT RevokedInfo, unknown [2] IMPLICIT UnknownInfo } RevokedInfo ::= SEQUENCE { revocationTime GeneralizedTime, revocationReason [0] EXPLICIT CRLReason OPTIONAL } Myers, et al. [Page 11] Internet Draft OCSPv2 March 2001 UnknownInfo ::= NULL -- this can be replaced with an enumeration The "good" state indicates that the certificate has not been revoked. It does not indicate that the certificate was ever issued, is or is in its validity interval. The "revoked" state indicates that the certificate has been revoked (either permanantly or temporarily (on hold)). The "unknown" state indicates that the responder doesn't know about the certificate being requested. 5.2.2 Response Signature Production and Validation ORS response messages SHALL be digitally signed if and only if they contain a value for responseBytes. ORS signature calculation and production SHALL conform to Section 3.2 of this document. The key used to sign an ORS response MAY be any key trusted by the client for this purpose. The means by which this key is established is beyond the scope of the document. Such keys include: 1. the key used to sign the subject certificate; 2. a key associated with the CA (i.e. a CA's "OCSP Signing" key); 3. a key certified by the issuing CA as an Authorized Responder; or 4. a key otherwise trusted by the requestor. The key that signs a certificate's status information need not be the same key that signed the certificate. A certificate's issuer explicitly delegates OCSP signing authority by issuing a certificate containing a unique value for extendedKeyUsage in the OCSP signer's certificate. This certificate MUST be issued directly to the responder by the cognizant CA. Responders MAY pre-produce signed responses. The time at which the status was known to be correct SHALL be reflected in the thisUpdate field of the response. The time at or before which newer information will be available SHALL be indicated in the nextUpdate field. The time at which the response was produced SHALL appear in the producedAt field. 5.2.3 Interpretation of Time-related Fields The thisUpdate, nextUpdate and producedAt fields SHALL be interpreted as follows: - thisUpdate: The time at which the status being indicated is known to be correct - nextUpdate: The time at or before which newer information will be available about the status of the certificate - producedAt: The time at which the responder signed the response. Myers, et al. [Page 12] Internet Draft OCSPv2 March 2001 If nextUpdate is not set, the responder is indicating that newer revocation information is available all the time. The thisUpdate and nextUpdate fields define a recommended validity interval. If CRLs are used as the basis for basic response production, this interval corresponds to the {thisUpdate, nextUpdate} interval in those CRLs; otherwise it corresponds to equivalent database management functions. Responses whose nextUpdate value is earlier than the local system time value SHOULD be considered unreliable. Responses whose thisUpdate time is later than the local system time SHOULD be considered unreliable. Responses where the nextUpdate value is not set are equivalent to a CRL with no time for nextUpdate. 5.2.4 Other Fields When the byKey CHOICE of ResponderID is used, the value for KeyHash SHALL be calculated over the value of the BIT STRING subjectPublicKey key field (excluding tag and length) in the issuer's certificate. 5.2.5 CA Key Revocation If a responder knows that a particular CA's private key has been revoked, it MAY return the "revoked" state for all certificates issued by that CA. 6. Delegated Path Validation This section identifies and defines the Delegated Path Validation (DPV) service. This service may be useful to environments that wish to offload [RFC2459]- compliant certificate validation functions to a centralized server. 6.1 Request A DPV request SHALL include a value of id-pkix-ocsp-valid-req in the requestExtensions field of TBSRequest. id-pkix-ocsp-valid-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } The corresponding value of the associated requestExtensions element SHALL contain the following: DPVOptions :: = SEQUENCE{ pathParams PathParameters OPTIONAL, validAt [2] GeneralizedTime OPTIONAL, revInfo [3] SEQUENCE OF RevocationInfo OPTIONAL, dPVFLags [4] DPVFlags OPTIONAL } PathParameters ::= SEQUENCE { initialPolicySet [0] PolicyList OPTIONAL, trustPoints [1] SEQUENCE OF ReqCert OPTIONAL } Myers, et al. [Page 13] Internet Draft OCSPv2 March 2001 DPVFlags ::= BIT STRING { returnpath (0), returnrevinfo (1), returntsp (2), returnpolicy (3) } RevocationInfo ::= CHOICE { cRL CertificateList, oCSP OCSPResponse } PolicyList ::= SEQUENCE SIZE (1..MAX) OF OBJECT IDENTIFIER The initialPolicySet option enables a requestor to establish one or more initial policy identifiers as defined in [RFC2459]. 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. If included, a successful validation request will pass through at least one of these trust points, else an "unknown" response will be generated. A client request MAY specify the time relative to which the validation is to be performed. If omitted, the current time SHALL be assumed. 6.2 Response A DPV response SHALL contain a value of id-pkix-ocsp-valid-rsp in the ResponseType field of the ResponseBytes syntax. id-pkix-ocsp-valid-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } The responseBytes field of an DPV response SHALL be composed of the BasicOCSPResponse syntax defined in Section 3.2.1 of this document. Servers that produce DPV responses SHALL execute path validation logic that produces outputs compliant with [RFC2459]. 6.2.1 Interpretation of CertStatus Field 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 NULL, 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 [RFC2459]. Servers MAY further predicate production of a "valid" response upon additional and locally- defined authorization criteria. Myers, et al. [Page 14] Internet Draft OCSPv2 March 2001 The "invalid" state SHALL be interpreted as indicating that the subject certificate does not satisfy one or more conditions necessary to the production of a "valid" state. The "unknown" state SHALL be interpreted as indicating that the server has no knowledge of the subject certificate. If a DPV 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 DPV request contains a non-NULL value for trustPoints, the receiving server SHALL attempt to produce a response that incorporates these certificates. If the receiving server cannot form such a path, the server SHALL return a status value of "unknown" in the response. 6.3 Processing Considerations [additional work needed on the various options] 7. 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 among other 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) service addresses these needs. 7.1 Request A DPD request SHALL contain a value of id-pkix-ocsp-path-req in the ResponseType field of the ResponseBytes syntax. id-pkix-ocsp-path-req OBJECT IDENTIFIER ::= { id-pkix-ocsp X } The corresponding value of the associated requestExtensions element SHALL contain the following: DPDOptions :: = SEQUENCE{ retryReference OCTET STRING, initialPolicySet [0] EXPLICIT PolicyList OPTIONAL, trustPoints [1] SEQUENCE OF ReqCert OPTIONAL, validAt [2] GeneralizedTime OPTIONAL, dDPFlags [3] DPDFlags OPTIONAL} Myers, et al. [Page 15] Internet Draft OCSPv2 March 2001 DPDFlags ::= BIT STRING { returnTSP (0), returnpolicy (1), crlonly (2), ocsponly (3), either (4) } 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 SHALL 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). 7.2 Response A DPD response SHALL contain a value of id-pkix-ocsp-path-rsp in the ResponseType field of the ResponseBytes syntax. id-pkix-ocsp-path-rsp OBJECT IDENTIFIER ::= { id-pkix-ocsp X } The responseBytes field of a DPD response SHALL consists of the following information. 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 SHALL 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. Myers, et al. [Page 16] Internet Draft OCSPv2 March 2001 7.3 Processing Considerations DPD servers SHALL: a. 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]; b. 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 c. 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. [additional work needed on the various options] 8. Extensions This section defines several extensions that could be of use in specific instances. Support for any specific extension is OPTIONAL. Additional extensions MAY be defined in additional RFCs. Unrecognized extensions MUST be ignored (unless they have the critical flag set and are not understood). 8.1 Nonce The nonce cryptographically binds a request and a response to prevent replay attacks (assuming that the requester-generated nonce is a large random number that the requester has not used previously). The nonce is included as one of the requestExtensions in requests, while in responses it would be included as one of the responseExtensions. In both the request and the response, the nonce will be identified by the object identifier id-pkix-ocsp-nonce, while the extnValue is the value of the nonce. id-pkix-ocsp-nonce OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 } 8.2 CRL References It may be desirable for the OCSP responder to indicate the CRL on which a revoked or onHold certificate is found. This can be useful where OCSP is used between repositories, and also as an auditing mechanism. The CRL may be specified by a URL (the URL at which the CRL is available), a number (CRL number) or a time (the time at which the relevant CRL was created). These extensions will be specified as singleExtensions. The identifier for this extension will be id-pkix-ocsp-crl, while the value will be CrlID. id-pkix-ocsp-crl OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 } Myers, et al. [Page 17] Internet Draft OCSPv2 March 2001 CrlID ::= SEQUENCE { crlUrl [0] EXPLICIT IA5String OPTIONAL, crlNum [1] EXPLICIT INTEGER OPTIONAL, crlTime [2] EXPLICIT GeneralizedTime OPTIONAL } For the choice crlUrl, the IA5String will specify the URL at which the CRL is available. For crlNum, the INTEGER will specify the value of the CRL number extension of the relevant CRL. For crlTime, the GeneralizedTime will indicate the time at which the relevant CRL was issued. 8.3 Acceptable Response Types An OCSP client MAY wish to specify the kinds of response types it understands. To do so, it SHOULD use an extension with the OID id-pkix-ocsp-response, and the value AcceptableResponses. This extension is included as one of the requestExtensions in requests. The OIDs included in AcceptableResponses are the OIDs of the various response types this client can accept (e.g., id-pkix-ocsp- basic). id-pkix-ocsp-response OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 } AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER 8.4 Archive Cutoff An OCSP responder MAY retain information relevant to a certificate's validity beyond a certificate's expiration. The date obtained by subtracting this retention interval value from the producedAt time in an ORS or DPV response is defined as the certificate's "archive cutoff" date. Applications would use an archive cutoff date to contribute to a proof that a digital signature was (or was not) reliable on the date it was produced even if the certificate needed to validate the signature has long since expired. OCSP servers SHOULD include an archive cutoff date extension in responses where applicable. If included, this value SHALL be provided as an OCSP singleExtensions extension identified by id- pkix-ocsp-archive-cutoff and of syntax GeneralizedTime. id-pkix-ocsp-archive-cutoff OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 } ArchiveCutoff ::= GeneralizedTime To illustrate, if a server is operated with a 7-year retention interval policy and status was produced at time t1 then the value for ArchiveCutoff in the response would be (t1 - 7 years). 8.5 Service Locator An OCSP server may be operated in a mode whereby the server receives a request and routes it to the OCSP server which is known to be authoritative for the identified certificate. The serviceLocator request extension is defined for this purpose. This extension is included as one of the singleRequestExtensions in requests. id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 } Myers, et al. [Page 18] Internet Draft OCSPv2 March 2001 ServiceLocator ::= SEQUENCE { issuer Name, locator AuthorityInfoAccessSyntax OPTIONAL } Values for these fields are obtained from the corresponding fields in the subject certificate. 8.6 CRL Entry Extensions All the extensions specified as CRL Entry Extensions - in Section 5.3 of [RFC2459] - are also supported as singleExtensions. 9. Security Considerations For this service to be effective, certificate using systems must connect to the certificate status service provider. In the event such a connection cannot be obtained, certificate-using systems could implement CRL processing logic as a fall-back position. A denial of service vulnerability is evident with respect to a flood of queries. The production of a cryptographic signature significantly affects response generation cycle time, thereby exacerbating the situation. Unsigned error responses open up the protocol to another denial of service attack, where the attacker sends false error responses. The use of precomputed responses allows replay attacks in which an old (good) response is replayed prior to its expiration date but after the certificate has been revoked. Deployments of OCSP should carefully evaluate the benefit of precomputed responses against the probability of a replay attack and the costs associated with its successful execution. Requests do not contain the responder they are directed to. This allows an attacker to replay a request to any number of OCSP responders. The reliance of HTTP caching in some deployment scenarios may result in unexpected results if intermediate servers are incorrectly configured or are known to possess cache management faults. Implementors are advised to take the reliability of HTTP cache mechanisms into account when deploying OCSP over HTTP. 10. Acknowledgments The authors appreciate the hard work of all members of the IETF PKIX Working Group in refining the text of this specification. We extend special thanks to Denis Pinkas, Ambarish Malpani, and Peter Gutman for their efforts and support. 11. References [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and CRL Profile", RFC 2459, January 1999. Myers, et al. [Page 19] Internet Draft OCSPv2 March 2001 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [URL] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). [ACPROF] Farrell, S., Housley, R., "An Internet Attribute Certificate Profile for Authorization", Internet Draft draft-ietf-pkix- ac509prof-xx.txt (work in progress). [SHA1] National Institute of Standards and Technology. FIPS Pub 180-1: Secure Hash Standard. 17 April 1995. [RFC2437] Kaliski, B., "PKCS #1: RSA Encryption, Version 2.0", RFC 2437, October 1998. [DSS] National Institute of Standards and Technology. FIPS Pub 186: Digital Signature Standard. 19 May 1994. 12. Authors' Addresses Michael Myers TraceRoute Security, Inc. myers@coastside.net +415.819.1362 Rich Ankney rankney@erols.com Carlisle Adams Entrust Technologies cadams@entrust.com 13. Appendix A. OCSP over HTTP A.1 OCSP over HTTP This section describes the formatting that will be done to the request and response to support HTTP. Myers, et al. [Page 20] Internet Draft OCSPv2 March 2001 A.1.1 Request HTTP based OCSP requests can use either the GET or the POST method to submit their requests. To enable HTTP caching, small requests (that after encoding are less than 255 bytes), MAY be submitted using GET. If HTTP caching is not important, or the request is greater than 255 bytes, the request SHOULD be submitted using POST. Where privacy is a requirement, OCSP transactions exchanged using HTTP MAY be protected using either TLS/SSL or some other lower layer protocol. An OCSP request using the GET method is constructed as follows: GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest} where {url} may be derived from the value of AuthorityInfoAccess or other local configuration of the OCSP client. An OCSP request using the POST method is constructed as follows: The Content-Type header has the value "application/ocsp-request" while the body of the message is the binary value of the DER encoding of the OCSPRequest. A.1.2 Response An HTTP-based OCSP response is composed of the appropriate HTTP headers, followed by the binary value of the DER encoding of the OCSPResponse. The Content-Type header has the value "application/ocsp-response". The Content-Length header SHOULD specify the length of the response. Other HTTP headers MAY be present and MAY be ignored if not understood by the requestor. 14. Appendix B. OCSP in ASN.1 [MODULE TO BE AGGREGATED AND IDENTIFIED] 15. Appendix C. MIME registrations C.1 application/ocsp-request To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-request MIME media type name: application MIME subtype name: ocsp-request Required parameters: None Optional parameters: None Encoding considerations: binary Myers, et al. [Page 21] Internet Draft OCSPv2 March 2001 Security considerations: Carries a request for information. This request may optionally be cryptographically signed. Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Online Certificate Status Protocol - OCSP Applications which use this media type: OCSP clients Additional information: Magic number(s): None File extension(s): .ORQ Macintosh File Type Code(s): none Person & email address to contact for further information: Ambarish Malpani Intended usage: COMMON Author/Change controller: Ambarish Malpani C.2 application/ocsp-response To: ietf-types@iana.org Subject: Registration of MIME media type application/ocsp-response MIME media type name: application MIME subtype name: ocsp-response Required parameters: None Optional parameters: None Encoding considerations: binary Security considerations: Carries a cryptographically signed response Interoperability considerations: None Published specification: IETF PKIX Working Group Draft on Online Certificate Status Protocol - OCSP Applications which use this media type: OCSP servers Additional information: Magic number(s): None File extension(s): .ORS Macintosh File Type Code(s): none Myers, et al. [Page 22] Internet Draft OCSPv2 March 2001 Person & email address to contact for further information: Ambarish Malpani Intended usage: COMMON Author/Change controller: Ambarish Malpani ambarish@valicert.com Myers, et al. [Page 23]