The value for responseBytes consists of an OBJECT IDENTIFIER and a   response syntax identified by that OID encoded as an OCTET STRING.   ResponseBytes ::=       SEQUENCE {       responseType   OBJECT IDENTIFIER,       response       OCTET STRING }   For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.   id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }   id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }Myers, et al.               Standards Track                     [Page 8]RFC 2560                       PKIX OCSP                       June 1999   OCSP 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.   BasicOCSPResponse       ::= SEQUENCE {      tbsResponseData      ResponseData,      signatureAlgorithm   AlgorithmIdentifier,      signature            BIT STRING,      certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }   The value for signature SHALL be computed on the hash of the DER   encoding ResponseData.   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 }   KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key   (excluding the tag and length fields)   SingleResponse ::= SEQUENCE {      certID                       CertID,      certStatus                   CertStatus,      thisUpdate                   GeneralizedTime,      nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,      singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }   CertStatus ::= CHOICE {       good        [0]     IMPLICIT NULL,       revoked     [1]     IMPLICIT RevokedInfo,       unknown     [2]     IMPLICIT UnknownInfo }   RevokedInfo ::= SEQUENCE {       revocationTime              GeneralizedTime,       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }   UnknownInfo ::= NULL -- this can be replaced with an enumerationMyers, et al.               Standards Track                     [Page 9]RFC 2560                       PKIX OCSP                       June 19994.2.2  Notes on OCSP Responses4.2.2.1  Time   The thisUpdate and nextUpdate fields define a recommended validity   interval. This interval corresponds to the {thisUpdate, nextUpdate}   interval in CRLs. 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 (see   Section 2.4).   The producedAt time is the time at which this response was signed.4.2.2.2  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 MUST either sign the OCSP   responses itself or it MUST explicitly designate 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.   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}   Systems or applications that rely on OCSP responses MUST 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 MUST reject the   response if the certificate required to validate the signature on the   response fails to meet at least one of the following criteria:   1. Matches a local configuration of OCSP signing authority for the   certificate in question; or   2. Is the certificate of the CA that issued the certificate in   question; or   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage   extension and is issued by the CA that issued the certificate in   question."Myers, et al.               Standards Track                    [Page 10]RFC 2560                       PKIX OCSP                       June 1999   Additional acceptance or rejection criteria may apply to either the   response itself or to the certificate used to validate the signature   on the response.4.2.2.2.1  Revocation Checking of an Authorized Responder   Since an Authorized OCSP 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 a 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 should be NULL. CAs issuing   such a certificate should realized that a compromise of the   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. CA's   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 }   - A CA may specify how the responder's certificate 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.4.3  Mandatory and Optional Cryptographic Algorithms   Clients that request OCSP services SHALL be capable of processing   responses signed used DSA keys identified by the DSA sig-alg-oid   specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be   capable of processing RSA signatures as specified in section 7.2.1 of   [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.4.4  Extensions   This section defines some standard extensions, based on the extension   model employed in X.509 version 3 certificates see [RFC2459]. Support   for all extensions is optional for both clients and responders.  ForMyers, et al.               Standards Track                    [Page 11]RFC 2560                       PKIX OCSP                       June 1999   each extension, the definition indicates its syntax, processing   performed by the OCSP Responder, and any extensions which are   included in the corresponding response.4.4.1  Nonce   The nonce cryptographically binds a request and a response to prevent   replay attacks. 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 }4.4.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 }   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.4.4.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).Myers, et al.               Standards Track                    [Page 12]RFC 2560                       PKIX OCSP                       June 1999   id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }   AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER   As noted in section 4.2.1, OCSP responders SHALL be capable of   responding with 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.4.4.4  Archive Cutoff   An OCSP responder MAY choose to retain revocation information beyond   a certificate's expiration. The date obtained by subtracting this   retention interval value from the producedAt time in a response is   defined as the certificate's "archive cutoff" date.   OCSP-enabled applications would use an OCSP 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 that provide support for such historical reference   SHOULD include an archive cutoff date extension in responses.  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).4.4.5  CRL Entry Extensions   All the extensions specified as CRL Entry Extensions - in Section 5.3   of [RFC2459] - are also supported as singleExtensions.4.4.6  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.Myers, et al.               Standards Track                    [Page 13]RFC 2560                       PKIX OCSP                       June 1999   id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }   ServiceLocator ::= SEQUENCE {       issuer    Name,       locator   AuthorityInfoAccessSyntax OPTIONAL }   Values for these fields are obtained from the corresponding fields in   the subject certificate.5.  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.Myers, et al.               Standards Track                    [Page 14]RFC 2560                       PKIX OCSP                       June 19996.  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.   [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).Myers, et al.               Standards Track                    [Page 15]RFC 2560                       PKIX OCSP                       June 19997.  Authors' Addresses   Michael Myers   VeriSign, Inc.   1350 Charleston Road   Mountain View, CA 94043   EMail: mmyers@verisign.com   Rich Ankney   CertCo, LLC   13506 King Charles Dr.   Chantilly, VA  20151   EMail: rankney@erols.com