Network Working Group                                           M. MyersRequest for Comments: 2560                                      VeriSignCategory: Standards Track                                      R. Ankney                                                                  CertCo                                                              A. Malpani                                                                ValiCert                                                             S. Galperin                                                                  My CFO                                                                C. Adams                                                    Entrust Technologies                                                               June 1999                X.509 Internet Public Key Infrastructure               Online Certificate Status Protocol - OCSPStatus of this Memo   This document specifies an Internet standards track protocol for the   Internet community, and requests discussion and suggestions for   improvements.  Please refer to the current edition of the "Internet   Official Protocol Standards" (STD 1) for the standardization state   and status of this protocol.  Distribution of this memo is unlimited.Copyright Notice   Copyright (C) The Internet Society (1999).  All Rights Reserved.1.  Abstract   This document specifies a protocol useful in determining the current   status of a digital certificate without requiring CRLs. Additional   mechanisms addressing PKIX operational requirements are specified in   separate documents.   An overview of the protocol is provided in section 2. Functional   requirements are specified in section 4. Details of the protocol are   in section 5. We cover security issues with the protocol in section   6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1   syntactic elements and appendix C specifies the mime types for the   messages.   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.               Standards Track                     [Page 1]RFC 2560                       PKIX OCSP                       June 19992.  Protocol Overview   In lieu of or as a supplement to checking against a periodic CRL, it   may be necessary to obtain timely information regarding the   revocation status of a certificate (cf. [RFC2459], Section 3.3).   Examples include high-value funds transfer or large stock trades.   The Online Certificate Status Protocol (OCSP) enables applications to   determine the (revocation) state of an identified certificate. OCSP   may be used to satisfy some of the operational requirements of   providing more timely revocation information than is possible with   CRLs and may also be used to obtain additional status information. An   OCSP client issues a status request to an OCSP responder and suspends   acceptance of the certificate in question until the responder   provides a response.   This protocol specifies the data that needs to be exchanged between   an application checking the status of a certificate and the server   providing that status.2.1  Request   An OCSP request contains the following data:   -- protocol version   -- service request   -- target certificate identifier   -- optional extensions which MAY be processed by the OCSP Responder   Upon receipt of a request, an OCSP Responder determines if:   1. the message is well formed   2. the responder is configured to provide the requested service and   3. the request contains the information needed by the responder If   any one of the prior conditions are not met, the OCSP responder   produces an error message; otherwise, it returns a definitive   response.2.2  Response   OCSP responses can be of various types.  An OCSP response consists of   a response type and the bytes of the actual response. There is one   basic type of OCSP response that MUST be supported by all OCSP   servers and clients. The rest of this section pertains only to this   basic response type.Myers, et al.               Standards Track                     [Page 2]RFC 2560                       PKIX OCSP                       June 1999   All definitive response messages SHALL be digitally signed. The key   used to sign the response MUST belong to one of the following:   -- the CA who issued the certificate in question   -- a Trusted Responder whose public key is trusted by the requester   -- a CA Designated Responder (Authorized Responder) who holds a      specially marked certificate issued directly by the CA, indicating      that the responder may issue OCSP responses for that CA   A definitive response message is composed of:   -- version of the response syntax   -- name of the responder   -- responses for each of the certificates in a request   -- optional extensions   -- signature algorithm OID   -- signature computed across hash of the response   The response for each of the certificates in a request consists of   -- target certificate identifier   -- certificate status value   -- response validity interval   -- optional extensions   This specification defines the following definitive response   indicators for use in the certificate status value:   -- good   -- revoked   -- unknown   The "good" state indicates a positive response to the status inquiry.   At a minimum, this positive response indicates that the certificate   is not revoked, but does not necessarily mean that the certificate   was ever issued or that the time at which the response was produced   is within the certificate's validity interval. Response extensions   may be used to convey additional information on assertions made by   the responder regarding the status of the certificate such as   positive statement about issuance, validity, etc.   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.Myers, et al.               Standards Track                     [Page 3]RFC 2560                       PKIX OCSP                       June 19992.3  Exception Cases   In case of errors, the OCSP Responder may return an error message.   These messages are not signed. Errors can be of the following types:   -- malformedRequest   -- internalError   -- tryLater   -- sigRequired   -- unauthorized   A server produces the "malformedRequest" response if the request   received does not conform to the OCSP syntax.   The response "internalError" indicates that the OCSP responder   reached an inconsistent internal state. The query should be retried,   potentially with another responder.   In the event that the OCSP responder 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.2.4  Semantics of thisUpdate, nextUpdate and producedAt   Responses can contain three times in them - thisUpdate, nextUpdate   and producedAt. The semantics of these fields are:   - 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 OCSP responder signed this                 response.   If nextUpdate is not set, the responder is indicating that newer   revocation information is available all the time.Myers, et al.               Standards Track                     [Page 4]RFC 2560                       PKIX OCSP                       June 19992.5  Response Pre-production   OCSP responders MAY pre-produce signed responses specifying the   status of certificates at a specified time. 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 is reflected in the nextUpdate field, while the   time at which the response was produced will appear in the producedAt   field of the response.2.6  OCSP Signature Authority Delegation   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.2.7  CA Key Compromise   If an OCSP responder knows that a particular CA's private key has   been compromised, it MAY return the revoked state for all   certificates issued by that CA.3.  Functional Requirements3.1  Certificate Content   In order to convey to OCSP clients a well-known point of information   access, CAs SHALL provide the capability to include the   AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1)   in certificates that can be checked using OCSP.  Alternatively, the   accessLocation for the OCSP provider may be configured locally at the   OCSP client.   CAs that support an OCSP service, either hosted locally or provided   by an Authorized Responder, MUST provide 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).Myers, et al.               Standards Track                     [Page 5]RFC 2560                       PKIX OCSP                       June 19993.2  Signed Response Acceptance Requirements   Prior to accepting a signed response as valid, OCSP clients SHALL   confirm that:   1. The certificate identified in a received response corresponds to   that which was identified in the corresponding request;   2. The signature on the response is valid;   3. The identity of the signer matches the intended recipient of the   request.   4. The signer is currently authorized to sign the response.   5. The time at which the status being indicated is known to be   correct (thisUpdate) is sufficiently recent.   6. When available, the time at or before which newer information will   be available about the status of the certificate (nextUpdate) is   greater than the current time.4.  Detailed Protocol   The ASN.1 syntax imports terms defined in [RFC2459]. 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, CRLReason4.1  Requests   This section specifies the ASN.1 specification for a confirmation   request. The actual formatting of the message could vary depending on   the transport mechanism used (HTTP, SMTP, LDAP, etc.).4.1.1  Request Syntax   OCSPRequest     ::=     SEQUENCE {       tbsRequest                  TBSRequest,       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }   TBSRequest      ::=     SEQUENCE {Myers, et al.               Standards Track                     [Page 6]RFC 2560                       PKIX OCSP                       June 1999       version             [0]     EXPLICIT Version DEFAULT v1,       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,       requestList                 SEQUENCE OF Request,       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }   Signature       ::=     SEQUENCE {       signatureAlgorithm      AlgorithmIdentifier,       signature               BIT STRING,       certs               [0] EXPLICIT SEQUENCE OF Certificate   OPTIONAL}   Version         ::=             INTEGER  {  v1(0) }   Request         ::=     SEQUENCE {       reqCert                     CertID,       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }   CertID          ::=     SEQUENCE {       hashAlgorithm       AlgorithmIdentifier,       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key       serialNumber        CertificateSerialNumber }   issuerNameHash is the hash of the Issuer's distinguished name. The   hash shall be calculated over the DER encoding of the issuer's name   field in the certificate being checked. issuerKeyHash is the hash of   the Issuer's public key. The hash shall be calculated over the value   (excluding tag and length) of the subject public key field 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.4.1.2  Notes on the Request Syntax   The primary reason to use the hash of the CA's public key in addition   to the hash of the CA's name, to identify the issuer, is that it is   possible that two CAs may choose to use the same Name (uniqueness in   the Name is a recommendation that cannot be enforced). Two CAs will   never, however, have the same public key unless the CAs either   explicitly decided to share their private key, or the key of one of   the CAs was compromised.   Support for any specific extension is OPTIONAL. The critical flag   SHOULD NOT be set for any of them.  Section 4.4 suggests several   useful extensions.  Additional extensions MAY be defined in   additional RFCs. Unrecognized extensions MUST be ignored (unless they   have the critical flag set and are not understood).Myers, et al.               Standards Track                     [Page 7]RFC 2560                       PKIX OCSP                       June 1999   The requestor MAY choose to sign the OCSP request. In that case, the   signature is computed over the tbsRequest structure. If the request   is signed, the requestor SHALL specify its name in the requestorName   field. Also, for signed requests, the requestor MAY include   certificates that help the OCSP responder verify the requestor's   signature in the certs field of Signature.4.2  Response Syntax   This section specifies the ASN.1 specification for a confirmation   response. The actual formatting of the message could vary depending   on the transport mechanism used (HTTP, SMTP, LDAP, etc.).4.2.1  ASN.1 Specification of the OCSP Response   An OCSP response at a minimum consists of a responseStatus field   indicating the processing status of the prior request. If the value   of responseStatus is one of the error conditions, responseBytes are   not set.   OCSPResponse ::= SEQUENCE {      responseStatus         OCSPResponseStatus,      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }   OCSPResponseStatus ::= ENUMERATED {       successful            (0),  --Response has valid confirmations       malformedRequest      (1),  --Illegal confirmation request       internalError         (2),  --Internal error in issuer       tryLater              (3),  --Try again later                                   --(4) is not used       sigRequired           (5),  --Must sign the request       unauthorized          (6)   --Request unauthorized   }