Appendix A.

A.1 OCSP over HTTP

   This section describes the formatting that will be done to the
   request and response to support HTTP.

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.














 
RFC 2560                       PKIX OCSP                       June 1999


Appendix B.  OCSP in ASN.1

OCSP DEFINITIONS EXPLICIT TAGS::=

BEGIN

IMPORTS

      -- Directory Authentication Framework (X.509)
             Certificate, AlgorithmIdentifier, CRLReason
             FROM AuthenticationFramework { joint-iso-itu-t ds(5)
                      module(1) authenticationFramework(7) 3 }


-- PKIX Certificate Extensions
             AuthorityInfoAccessSyntax
          FROM PKIX1Implicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-implicit-88(2)}


          Name, GeneralName, CertificateSerialNumber, Extensions,
           id-kp, id-ad-ocsp
             FROM PKIX1Explicit88 {iso(1) identified-organization(3)
                  dod(6) internet(1) security(5) mechanisms(5) pkix(7)
                  id-mod(0) id-pkix1-explicit-88(1)};

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 }

Signature       ::=     SEQUENCE {
    signatureAlgorithm   AlgorithmIdentifier,
    signature            BIT STRING,
    certs                [0] EXPLICIT SEQUENCE OF Certificate OPTIONAL }

Version  ::=  INTEGER  {  v1(0) }