Ambarish Malpani   ValiCert, Inc.   1215 Terra Bella Ave.   Mountain View, CA 94043   Phone: 650.567.5457   EMail: ambarish@valicert.com   Slava Galperin   My CFO, Inc.   1945 Charleston Road   Mountain View, CA   EMail: galperin@mycfo.com   Carlisle Adams   Entrust Technologies   750 Heron Road, Suite E08   Ottawa, Ontario   K1V 1A7   Canada   EMail: cadams@entrust.comMyers, et al.               Standards Track                    [Page 16]RFC 2560                       PKIX OCSP                       June 1999Appendix 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.Myers, et al.               Standards Track                    [Page 17]RFC 2560                       PKIX OCSP                       June 1999Appendix B.  OCSP in ASN.1OCSP DEFINITIONS EXPLICIT TAGS::=BEGINIMPORTS      -- 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) }Request ::=     SEQUENCE {    reqCert                    CertID,    singleRequestExtensions    [0] EXPLICIT Extensions OPTIONAL }Myers, et al.               Standards Track                    [Page 18]RFC 2560                       PKIX OCSP                       June 1999CertID ::= SEQUENCE {    hashAlgorithm            AlgorithmIdentifier,    issuerNameHash     OCTET STRING, -- Hash of Issuer's DN    issuerKeyHash      OCTET STRING, -- Hash of Issuers public key    serialNumber       CertificateSerialNumber }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}ResponseBytes ::=       SEQUENCE {    responseType   OBJECT IDENTIFIER,    response       OCTET STRING }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 }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,Myers, et al.               Standards Track                    [Page 19]RFC 2560                       PKIX OCSP                       June 1999   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 enumerationArchiveCutoff ::= GeneralizedTimeAcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIERServiceLocator ::= SEQUENCE {    issuer    Name,    locator   AuthorityInfoAccessSyntax }-- Object Identifiersid-kp-OCSPSigning            OBJECT IDENTIFIER ::= { id-kp 9 }id-pkix-ocsp                 OBJECT IDENTIFIER ::= { id-ad-ocsp }id-pkix-ocsp-basic           OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }id-pkix-ocsp-nonce           OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }id-pkix-ocsp-crl             OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }id-pkix-ocsp-response        OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }id-pkix-ocsp-nocheck         OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }ENDMyers, et al.               Standards Track                    [Page 20]RFC 2560                       PKIX OCSP                       June 1999Appendix C. MIME registrationsC.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   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 <ambarish@valicert.com>   Intended usage: COMMON   Author/Change controller:   Ambarish Malpani <ambarish@valicert.com>C.2 application/ocsp-response   To: ietf-types@iana.org   Subject: Registration of MIME media type application/ocsp-response   MIME media type name: applicationMyers, et al.               Standards Track                    [Page 21]RFC 2560                       PKIX OCSP                       June 1999   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   Person & email address to contact for further information:   Ambarish Malpani <ambarish@valicert.com>   Intended usage: COMMON   Author/Change controller:   Ambarish Malpani <ambarish@valicert.com>Myers, et al.               Standards Track                    [Page 22]RFC 2560                       PKIX OCSP                       June 1999Full Copyright Statement   Copyright (C) The Internet Society (1999).  All Rights Reserved.   This document and translations of it may be copied and furnished to   others, and derivative works that comment on or otherwise explain it   or assist in its implementation may be prepared, copied, published   and distributed, in whole or in part, without restriction of any   kind, provided that the above copyright notice and this paragraph are   included on all such copies and derivative works.  However, this   document itself may not be modified in any way, such as by removing   the copyright notice or references to the Internet Society or other   Internet organizations, except as needed for the purpose of   developing Internet standards in which case the procedures for   copyrights defined in the Internet Standards process must be   followed, or as required to translate it into languages other than   English.   The limited permissions granted above are perpetual and will not be   revoked by the Internet Society or its successors or assigns.   This document and the information contained herein is provided on an   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.Acknowledgement   Funding for the RFC Editor function is currently provided by the   Internet Society.Myers, et al.               Standards Track                    [Page 23]