Internet Draft                                               A .Deacon
 Category: Informational                                       VeriSign
 Document: draft-deacon-lightweight-ocsp-profile-00.txt        R. Hurst
 Expires: May 2004                                            Microsoft
                                                          November 2003
 
           Lightweight OCSP Profile for High Volume Environments
 
 Status of this Memo
 
    This document is an Internet-Draft and is in full conformance with
    all provisions of Section 10 of RFC2026 [KEYWORDS].
 
    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/1id-abstracts.html
 
    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html
 
 Abstract
 
    This document defines a lightweight profile of OCSP (RFC 2560) for
    use in very large PKI environments such as SSL/TLS, code signing
    and secure messaging.  In these environments there exists a large
    client base (in the 100's of millions) and thus the ability to
    scale OCSP request handling is very important.
 
 Table of Contents
 
    Introduction.....................................................2
    1. OCSP Message Profile..........................................2
       1.1 OCSP Request Profile......................................2
       1.1.1 OCSPRequest Structure...................................2
       1.1.2 Signed OCSPRequests.....................................3
       1.2 OCSP Response Profile.....................................3
       1.2.1 OCSPResponse Structure..................................3
       1.2.2 Signed OCSPResponses....................................4
       1.2.3 OCSPResponseStatus Values...............................4
       1.2.4 thisUpdate, nextUpdate and producedAt...................4
 
 
 Deacon                    Expires - May 2004                  [Page 1]


                        Lightweight OCSP Profile          November 2003
 
 
    2. Ensuring an OCSPResponse is Fresh.............................5
    3. Transport Profile.............................................6
    4. Caching Recommendations.......................................7
       4.1 Caching at the Client.....................................7
       4.2 HTTP Proxies..............................................7
       4.3 Caching at Servers........................................8
    5. Security Considerations.......................................9
       5.1 Replay attacks............................................9
       5.2 Man-in-the-middle attacks................................10
       5.3 Impersonation attacks....................................10
       5.4 Denial of service attacks................................10
       5.5 Modification of HTTP Headers.............................10
    6. Acknowledgements.............................................11
    7. References...................................................11
       7.1 Normative................................................11
       7.2 Informative..............................................11
    8. Author's Addresses...........................................12
    Appendix A. Useful Response Extensions..........................12
       Appendix A.1. nextPublish Response Extension.................12
    Appendix B.  Example OCSP Messages..............................12
       Appendix B.1: OCSP Request...................................12
       Appendix B.2: OCSP Response..................................13
 
 Introduction
 
    This document addresses the OCSP [OCSP] scalability issues inherent
    in high volume PKI environments by defining an OCSP message profile
    that will permit:
 
    1) OCSP response pre-production and distribution
    2) Reduced OCSP message size to lower bandwidth usage
    3) Response message caching both in the network and on the client
 
 1.     OCSP Message Profile
 
    This section defines a subset of OCSPRequest and OCSPResponse
    functionality as defined in [OCSP].
 
 1.1      OCSP Request Profile
 
 1.1.1 OCSPRequest Structure
 
    OCSPRequests conformant to this profile MUST only include one
    Request in the OCSPRequest.RequestList structure.
 
    Clients MUST use SHA1 as the hashing algorithm for the
    CertID.issuerNameHash and the CertID.issuerKeyHash values.
 
    Clients MUST NOT include the singleRequestExtensions structure.
 
 
 Deacon                    Expires - May 2004                  [Page 2]


                        Lightweight OCSP Profile          November 2003
 
 
 
    Clients SHOULD NOT include the requestExtensions structure.  If a
    requestExtensions structure is included, this profile RECOMMENDS
    that it only contain the nonce extension (id-pkix-ocsp-nonce).  See
    Section 2 for issues concerning the use of a nonce in high volume
    OCSP environments.
 
 1.1.2 Signed OCSPRequests
 
    Clients SHOULD NOT create or send signed OCSPRequests.  Responders
    MAY ignore the signature on OCSPRequests.
 
    If the OCSPRequest is signed, the client SHALL specify its name in
    the OCSPRequest.requestorName field, otherwise clients SHOULD NOT
    include the requestorName field in the OCSPRequest. OCSP servers
    MUST be prepared to receive unsigned OCSP requests that contains
    the requestorName field, but must realize that the provided value
    is not authenticated.
 
    Note: The suggested use of unsigned requests in this environment
    does not enable a responder to determine the authenticity of
    incoming request.  Thus, access to the responder is implicitly
    given to any relying party.
 
 1.2      OCSP Response Profile
 
 1.2.1 OCSPResponse Structure
 
    Responders MUST generate a BasicOCSPResponse as identified by the
    id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a
    BasicOCSPResponse.  OCSPResponses conformant to this profile SHOULD
    only include one SingleResponse in the ResponseData.responses
    structure, but MAY include additional SingleResponse elements if
    necessary to improve response pre-generation performance or cache
    efficiency.
 
    The responder SHOULD NOT include responseExtensions. Clients MUST
    NOT fail if they encounter non-critical responseExtensions in the
    response.
 
    In the case a responder does not have the ability to respond to an
    OCSP request containing a nonce, such as if it only has the ability
    to use pre-produced responses, it SHOULD return a response that
    does not include a nonce. Clients SHOULD attempt to accept a
    response even if the response does not include a nonce.  See
    Section 2 for details on validating responses that do not contain a
    nonce.  See also Section 5 for relevant security considerations.
 
 
 
 
 Deacon                    Expires - May 2004                  [Page 3]


                        Lightweight OCSP Profile          November 2003
 
 
    Responders that cannot respond to OCSP requests that contain a
    nonce MAY forward the request to an OCSP responder capable of
    generating a real-time response.
 
    The responder MAY include the singleResponse extensions structure.
 
 1.2.2 Signed OCSPResponses
 
    Responders MUST use the sha1WithRSAEncryption signature algorithm
    when signing the OCSPResponse.  Clients MUST validate the signature
    on the returned OCSPResponse.
 
    If the response is signed by a delegate of the issuing CA the
    responder certificate MUST be referenced in the
    BasicOCSPResponse.certs structure.
    The responder's certificate MUST have a validity window greater
    than or equal to the validity window of the responses it issues.
    In addition, it is RECOMMENDED that the OCSP responder's
    certificate contain the id-ocsp-nocheck EKU OID to indicate to the
    client that it need not check its status.  Accordingly, the
    responders' signing certificate SHOULD be relatively short-lived
    and rolled over regularly.
 
    Clients MUST be able to identify OCSP responder certificates using
    both the byName and byKey ResponseData.ResponderID choices.
    Responders MAY use byKey to further reduce the size of the response
    in scenarios where reducing bandwidth is an issue.
 
 1.2.3 OCSPResponseStatus Values
 
    As long as the responder has records for a particular certificate,
    an OCSPResponseStatus of "successful" will be returned.
    In order to ensure the database of revocation information does not
    grow unbounded over time, the responder MAY remove the status
    records of expired certificates.
 
    The responder will return an OCSPResponseStatus of "unauthorized"
    when processing requests for which it is not capable of responding
    authoritatively.
 
 1.2.4 thisUpdate, nextUpdate and producedAt
 
    When pre-producing OCSPResponse messages, the responder MUST set
    the thisUpdate, nextUpdate and producedAt times 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
 
 
 Deacon                    Expires - May 2004                  [Page 4]


                        Lightweight OCSP Profile          November 2003
 
 
                   will be available about the status of the
                   certificate.  Responders MUST always include
                   this value to aid in response caching.  See
                   Section 3 for additional information on
                   caching.
 
    producedAt    The time at which the OCSP response is signed.
 
    Note: In many cases the value of thisUpdate and producedAt will be
    the same.
 
    For the purposes of this profile, GeneralizedTime values such as
    thisUpdate, nextUpdate and producedAt MUST be expressed Greenwich
    Mean Time (Zulu) and MUST include seconds (i.e.,times are
    YYYYMMDDHHMMSSZ), even where the number of seconds is zero.
    GeneralizedTime values MUST NOT include fractional seconds.
 
 2.     Ensuring an OCSPResponse is Fresh
 
    In order to ensure a client does not accept an out of date response
    that indicates a 'good' status when in fact there is a more up to
    date response that specifies the status of 'revoked', a client must
    ensure the responses they receive are fresh.
 
    In general, two mechanisms are available to clients to ensure a
    response is fresh.  The first uses nonces, and the second is based
    on time.  In order for time based mechanisms to work, clients MUST
    have access to an accurate source of time.
 
    Because this profile specifies that clients SHOULD NOT include a
    requestExtensions structure in OCSPRequests (See Section 1.1)
    clients MUST be able to determine OCSPResponse freshness based on
    an accurate source of time.  Clients that opt to include a nonce in
    the request MUST NOT reject a corresponding OCSPResponse solely on
    the basis of the non-existent expected nonce, but MUST fall back to
    validating the OCSPResponse based on time.
 
    If a client includes a nonce in an OCSPRequest, and receives a
    nonce in the corresponding OCSPResponse it MUST ensure that the
    nonce included in the OCSPRequest matches the nonce received in the
    OCSPRequest.  If the nonces do not match the client MUST reject the
    response as invalid.  Clients that do not include a nonce in the
    request MUST ignore any nonce that may be present in the response.
 
    If there is no nonce in the OCSPResponse, clients MUST check for
    the existence of the nextUpdate field.  If the nextUpdate field is
    absent, and there's no other way for the client to determine the
    freshness of the response, the client MUST reject the response.
 
 
 
 Deacon                    Expires - May 2004                  [Page 5]


                        Lightweight OCSP Profile          November 2003
 
 
    If the nextUpdate field is present the client MUST ensure that it
    is not earlier than current time.  If the current local time on the
    client is later than the time specified in the nextUpdate field,
    the client MUST reject the response as stale.  Clients MAY allow
    configuration of a small tolerance period for acceptance of
    responses after nextUpdate to handle minor clock differences
    relative to responders and caches.  This tolerance period should be
    no more than a few minutes to avoid introducing increased security
    risks.
 
    See the security considerations in Section 5 for additional details
    on replay and man-in-the-middle attacks.
 
 3.     Transport Profile
 
    The OCSP responder MUST support requests and responses over HTTP.
    When sending requests that are less than 255 bytes in total (after
    encoding) including the method (http://), server name and base64
    encoded OCSPReqeust structure, clients MUST use the GET method (to
    enable for OCSP response caching). OCSP requests larger than 255
    bytes SHOULD be submitted using the POST method. In all cases,
    clients MUST follow the descriptions in A.1.1 of [OCSP] when
    constructing these messages.
 
    Clients MUST base64 encode the OCSPRequest structure and append it
    to the URI specified in the AIA extension [PKIX].  Clients MUST NOT
    include CR or LF characters in the base64-encoded string.  Clients
    MUST properly url-encode the base64 encoded OCSPRequest, e.g.
 
      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL
      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg
      %3D%3D
 
    In response to a properly formatted OCSPRequest that do not contain
    a nonce, the responder will include the binary value of the DER
    encoding of the OCSPResponse preceded by the following HTTP
    headers.
 
      content-type=application/ocsp-response
      content-transfer-encoding=binary
      content-length=<OCSP response length>
      last-modified: <producedAt HTTP date>
      expires: <nextUpdate HTTP date>                                                                               cache-control: max-age=<n>, public, no-transform, must-revalidate
      date: <current HTTP date>
 
    See Section 4.2 for details on the use of these headers.
 
 
 
 
 Deacon                    Expires - May 2004                  [Page 6]


                        Lightweight OCSP Profile          November 2003
 
 
 
 4.     Caching Recommendations
 
    The ability to cache OCSP Responses throughout the network is an
    important factor in high volume OCSP deployments.  This section
    discusses the recommended caching behavior of OCSP clients and HTTP
    proxies and the steps that should be taken to minimize the number
    of times that OCSP clients "hit the wire".   In addition the
    concept of piggybacking OCSP responses in protocols, such as TLS,
    is also discussed.
 
 4.1      Caching at the Client
 
    To minimize bandwidth usage, clients MUST locally cache
    authoritative OCSP responses. (i.e. those with an
    OCSPResponseStatus of ‘successful')  Once cached, the client SHOULD
    NOT send a new OCSP request until the nextUpdate time in the cached
    response.
 
    To ensure a large subset of clients don't request a new
    OCSPResponse for a popular certificate at the same time thus
    causing a spike in responder load, the client MAY use a locally
    configured value to determine when to begin attempting to retrieve
    more recent revocation information slightly in advance of the
    nextUpdate period.  (See Appendix A.1 for details of how a
    responder can specify this value to the client.)
 
    Clients SHOULD NOT request the status of expired certificates.
    Clients MUST validate the signature on certificates and SHOULD NOT
    request the status for certificates with signatures that cannot be
    validated.
 
 4.2      HTTP Proxies
 
    The responder SHOULD set the HTTP headers of the OCSP response in
    such a way to allow for the intelligent use of HTTP proxy servers.
 
    HTTP Header    Description
    ===========    ====================================================
    date           The date and time at which the OCSP server generated
                   the HTTP response.
 
    last-modified  This value specifies the date and time at which the
                   OCSP responder last modified the response.  This
                   date and time will be the same as the thisUpdate
                   timestamp in the request itself.
 
    expires        Specifies how long the response is considered fresh.
 
 
 Deacon                    Expires - May 2004                  [Page 7]


                        Lightweight OCSP Profile          November 2003
 
 
                   This date and time will be the same as the
                   nextUpdate timestamp in the OCSP response itself.
 
    cache-control  Contains a number of caching directives.
 
                   * max-age=<n> - where n is the nextUpdate time
                                   minus the time the response is
                                   generated (i.e. the Date header)
                                   in seconds.
                   * public -      makes normally  uncachable response
                                   cachable by both shared and
                                   nonshared caches.
                   * no-transform -specifies that a proxy cache cannot
                                   change the type, length , or
                                   encoding of the object content.
                   * must-revalidate - prevents caches from
                                       intentionally returning stale
                                       responses.
 
    For example, assume that an OCSP response has the following time
    stamp values:
 
      thisUpdate = May 1, 2003  01:00:00 GMT
      nextUpdate = May 3, 2003 01:00:00 GMT
      productedAt = May 1, 2003 01:00:00 GMT
 
    and that an OCSP client requests the response on May 2, 2003
    01:00:00 GMT.  In this scenario the HTTP response will look like
    this:
 
      content-type: application/ocsp-response
      content-transfer-encoding: binary
      content-length: <OCSP response length>
      date: Fri, 02 May 2003 01:00:00 GMT
      last-modified: Thu, 01 May 2003 01:00:00 GMT
      expires: Sat, 03 May 2003 01:00:00 GMT
      cache-control: max-age=86400, public, no-transform, must-
      revalidate
      <...>
 
    If a client encounters an expired response, it may be a result of
    an intermediate proxy caching stale data, as such clients SHOULD
    resend the requestspecifying that proxies should be bypassed by
    including an appropriate HTTP header in the request (i.e. Pragma:
    no-cache or Cache-Control: no-cache).
 
 4.3      Caching at Servers
 
 
 
 Deacon                    Expires - May 2004                  [Page 8]


                        Lightweight OCSP Profile          November 2003
 
 
    In some scenarios it is advantageous to include OCSP response
    information within the protocol being utilized between the client
    and server.  "Piggybacking" OCSP responses in this manner has a few
    attractive effects.
 
    First, it allows for the caching of OCSP responses on the server,
    thus lowering the number of hits to the OCSP responder.
 
    Second, it simplifies the client side OCSP implementation by
    enabling a situation where the client only needs the ability to
    parse and recognize OCSP responses.
 
    Third, it reduces the number of round trips the client needs to
    make in order to validate a certificate.
 
    Fourth, it enables certificate validation in the event the client
    is not connected to a network and thus eliminates the need for
    clients to establish a new HTTP session with the responder.
 
    This functionality has been specified as an extension to the TLS
    [TLS] protocol in Section 3.6 [TLSEXT], but can be applied to any
    client-server protocol.
 
    This profile RECOMMENDS that both TLS clients and servers implement
    the certificate status request extension mechanism for TLS.
 
 5.     Security Considerations
 
    The following considerations apply in addition to the security
    consideration addressed in Section 5 of [OCSP]
 
 5.1      Replay attacks
 
    Because the use of nonce's in this profile is optional, there is a
    possibility that an out of date OCSP response could be replayed,
    thus causing a client to accept good response when in fact there is
    a more up to date response that specifies the status of revoked.
    In order to mitigate this attack, clients MUST have access to an
    accurate source of time and ensure that the OCSP responses they
    receive are sufficiently fresh.
 
    Required clock accuracy is relative to the validity duration of the
    client's OCSP responses.  A client using responses that are good
    for one hour SHOULD have a clock that is within a few minutes
    correct time, while a client with 24-hour responses SHOULD be
    within an hour of correct time.
 
    Clients that do not have an accurate source of date and time are
    vulnerable to service disruption due to rejection of fresh OCSP
 
 
 Deacon                    Expires - May 2004                  [Page 9]


                        Lightweight OCSP Profile          November 2003
 
 
    responses.  If this problem is not repaired, a client with a
    sufficiently slow clock may also incorrectly accept expired
    responses for currently revoked certificates.
 
 
 5.2      Man-in-the-middle attacks
 
    To prevent this class of attack, the client must properly validate
    the signature on the response.
 
    The use of signed responses in OCSP serves the purpose to
    authenticate the identity of the OCSP responder that has authority
    to sign request on the CA's behalf.
 
    Clients MUST ensure that they are communicating with an authorized
    responder by the rules described in [OCSP] Section 4.2.2.2.
 
 5.3      Impersonation attacks
 
    The use of signed responses in OCSP serves the purpose to
    authenticate the identity of OCSP Responder.
 
    Clients must properly validate the signature of the OCSP response
    and the signature(s) on the OCSP response signer certificate to
    ensure an authorized responder created it.
 
 5.4      Denial of service attacks
 
    OCSP responders should take measures to prevent or mitigate denial
    of service attacks. In particular OCSP responders should not
    perform an unlimited number of resource intensive operations.
 
    In the case where client requests are not signed, as specified by
    this profile, OCSP responders should take additional steps to
    detect an attack of this kind.
 
    One such technique could be to attempt to match which response to
    send based on the hash of the request, this would protect against
    decode related attacks. However since extensions are supported not
    all requests for the same certificate will be the same as such it
    would also be necessary to support a full decode based lookup. As
    such this technique would only help defend against accidental
    attacks.
 
 5.5      Modification of HTTP Headers
 
    Values included in HTTP headers as described in Section 3 and 4,
    are not cryptographically protected, they may be manipulated by an
    attacker.  Clients SHOULD use these values for caching guidance
 
 
 Deacon                    Expires - May 2004                 [Page 10]


                        Lightweight OCSP Profile          November 2003
 
 
    only and should ultimately rely on the values present in the signed
    OCSPResponse.
 
 6.     Acknowledgements
 
    The authors wish to thank Magnus Nystrom Of RSA Security, Inc.,
    Jagjeet Sondh of Vodafone Group R&D and David Engberg of
    CoreStreet, Ltd. for their contributions to this specification.
 
 7.     References
 
 7.1      Normative
 
    [HTTP]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
             Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
             Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
 
    [KEYWORDS]  Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.
 
    [OCSP]   Myers, M., Ankney, R., Malpani, A., Galperin, S. and
             C. Adams, "Internet X.509 Public Key Infrastructure:
             Online Certificate Status Protocol - OCSP", RFC 2560,
             June 1999.
 
    [PKIX]   Housley, R., Polk, W., Ford, W. and D. Solo, "Internet
             Public Key Infrastructure - Certificate and
             Certificate Revocation List (CRL) Profile", RFC 3280,
             April 2002.
 
    [TLS]    Dierks, T. and C. Allen, "The TLS Protocol Version
             1.0", RFC 2246, January 1999.
 
    [TLSEXT] Blake-Wilson, et. al., "Transport Layer Security (TLS)
             Extensions", RFC 3546, June 2003.
 
 7.2      Informative
 
    [URI]    Berners-Lee, T., Fielding, R. and L. Masinter,
             "Uniform Resource Identifiers (URI): Generic Syntax",
             RFC 2396, August 1998
 
    [PKIOP]  Housley, R. and P. Hoffman, "Internet X.509 Public Key
             Infrastructure - Operation Protocols: FTP and HTTP",
             RFC 2585, May 1999.
 
    [OCSPMP] "OCSP Mobile Profile", OpenMobileAlliance,
             www.openmobilalliance.org.
 
 
 
 Deacon                    Expires - May 2004                 [Page 11]


                        Lightweight OCSP Profile          November 2003
 
 
 8.     Author's Addresses
 
    Alex Deacon
    VeriSign, Inc.
    487 E. Middlefield Road      Phone:  1-650-426-3478
    Mountain View, CA. USA       Email:  a1ex@verisign.com
 
    Ryan Hurst
    Microsoft
    One Microsoft Way            Phone:  1-425-707-8979
    Redmond, WA. USA             Email:  rmh@microsoft.com
 
 
 Appendix A. Useful Response Extensions
 
 Appendix A.1. nextPublish Response Extension
 
    Support for this extension is optional. This extension indicates
    the time at which the server will be issuing new information about
    the status of the certificate. If present can be used by the
    relying party to determine when it is acceptable to begin attempts
    for new revocationinformation.
 
    The time specified in the nextPublish extension SHOULD be before
    the time specified in the nextUpdate field.
 
    This profile RECOMMENDEDS this value be used by clients to
    determine when it is possible to check for more up to date
    information.
 
       id-msft-nextPublish OBJECT IDENTIFIER ::= {1.3.6.1.4.1.311.21.4}
 
        nextPublish EXTENSION ::= {
         SYNTAX          nextPublishSyntax
         IDENTIFIED BY   id-msft-nextPublish
       }
 
       nextPublishSyntax ::= Time
 
       Time ::= CHOICE {
          utcTime        UTCTime,
          generalTime    GeneralizedTime
      }
 
 
 Appendix B.  Example OCSP Messages
 
 Appendix B.1: OCSP Request
 
    SEQUENCE {
 
 
 Deacon                    Expires - May 2004                 [Page 12]


                        Lightweight OCSP Profile          November 2003
 
 
      SEQUENCE {
        SEQUENCE {
          SEQUENCE {
            SEQUENCE {
              SEQUENCE {
                OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
                NULL
                }
              OCTET STRING
                C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
                1A B7 BF C0
              OCTET STRING
                0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
                15 7C D4 F6
              INTEGER
                6B 26 79 83 A4 9A B7 C2 3D FF 58 E8 81 AA A5 0E
              }
            }
          }
        }
      }
 
 Appendix B.2: OCSP Response
 
    SEQUENCE {
       ENUMERATED 0
       [0] {
         SEQUENCE {
           OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1)
           OCTET STRING, encapsulates {
             SEQUENCE {
               SEQUENCE {
                 [1] {
                   SEQUENCE {
                     SET {
                       SEQUENCE {
                         OBJECT IDENTIFIER organizationName (2 5 4 10)
                         PrintableString 'Example, Inc.'
                         }
                       }
                     SET {
                       SEQUENCE {
                         OBJECT IDENTIFIER
                           organizationalUnitName (2 5 4 11)
                         PrintableString Example Trust Network'
                         }
                       }
                     SET {
                       SEQUENCE {
 
 
 Deacon                    Expires - May 2004                 [Page 13]


                        Lightweight OCSP Profile          November 2003
 
 
                         OBJECT IDENTIFIER
                           organizationalUnitName (2 5 4 11)
                         PrintableString
                       'Terms of use at https://www.example.com/rpa'
                       '(c)02'
                         }
                       }
                     SET {
                       SEQUENCE {
                         OBJECT IDENTIFIER commonName (2 5 4 3)
                         PrintableString
                       'Example Class 3 International Server OCSP'
                       'Responder'
                         }
                       }
                     }
                   }
                 GeneralizedTime 11/09/2003 14:55:57 GMT
                 SEQUENCE {
                   SEQUENCE {
                     SEQUENCE {
                       SEQUENCE {
                         OBJECT IDENTIFIER sha1 (1 3 14 3 2 26)
                         NULL
                         }
                       OCTET STRING
                       C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2
                       1A B7 BF C0
                       OCTET STRING
                       0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D
                       15 7C D4 F6
                       INTEGER
                       6B 26 79 83 A4 9A B7 C2 3D FF 58 E8 81 AA A5 0E
                       }
                     [0]
                       Error: Object has zero length.
                     GeneralizedTime 11/09/2003 14:55:57 GMT
                     }
                   }
                 }
               SEQUENCE {
                 OBJECT IDENTIFIER
                   sha1withRSAEncryption (1 2 840 113549 1 1 5)
                 }
               BIT STRING
                 17 C3 A3 0B 87 1A A5 C9 39 D2 1E E4 49 9C 84 48
                 DC E7 9A 68 89 77 BE 25 60 97 D9 FB 8C D0 C5 E8
                 9B D2 25 F6 52 E9 BA 22 C8 FE C4 B6 B3 9F 1F 71
                 58 FC BE 39 DC 9D 4E 85 00 8C F1 A9 92 CD 25 CA
 
 
 Deacon                    Expires - May 2004                 [Page 14]


                        Lightweight OCSP Profile          November 2003
 
 
                 3C DC B9 61 46 76 87 BD A1 E9 F6 41 E2 B3 D6 7E
                 E1 FD A1 5D 2D 08 7C 01 3F 2C 3A 39 60 F1 53 AD
                 1E 81 E0 57 55 02 F7 D3 FC 9A F8 CA 09 DA 87 1E
                 8A 93 01 58 E0 31 72 A1 4A 05 F7 3E 21 2F D7 93
               [0] {
                 SEQUENCE {
                   SEQUENCE {
                     SEQUENCE {
                       [0] {
                         INTEGER 2
                         }
                       INTEGER
                       24 D4 27 7D 62 AC 2D 92 F8 D3 4E B1 A5 19 84 78
                       SEQUENCE {
                         OBJECT IDENTIFIER
                           sha1withRSAEncryption (1 2 840 113549 1 1 5)
                         NULL
                         }
                       SEQUENCE {
                         SET {
                           SEQUENCE {
                             OBJECT IDENTIFIER
                               organizationName (2 5 4 10)
                             PrintableString "Example Trust Network'
                             }
                           }
                         SET {
                           SEQUENCE {
                             OBJECT IDENTIFIER
                               organizationalUnitName (2 5 4 11)
                             PrintableString 'Example, Inc.'
                             }
                           }
                         SET {
                           SEQUENCE {
                             OBJECT IDENTIFIER
                               organizationalUnitName (2 5 4 11)
                             PrintableString
                       'Example International Server CA - Class 3'
                             }
                           }
                         }
                       SEQUENCE {
                         UTCTime 09/07/2002 00:00:00 GMT
                         UTCTime 24/10/2011 23:59:59 GMT
                         }
                       SEQUENCE {
                         SET {
                           SEQUENCE {
 
 
 Deacon                    Expires - May 2004                 [Page 15]


                        Lightweight OCSP Profile          November 2003
 
 
                             OBJECT IDENTIFIER
                               organizationName (2 5 4 10)
                             PrintableString 'Example, Inc.'
                             }
                           }
                         SET {
                           SEQUENCE {
                             OBJECT IDENTIFIER
                               organizationalUnitName (2 5 4 11)
                             PrintableString 'Example Trust Network'
                             }
                           }
                         SET {
                           SEQUENCE {
                             OBJECT IDENTIFIER commonName (2 5 4 3)
                             PrintableString
                                  'Example OCSP Responder'
                             }
                           }
                         }
                       SEQUENCE {
                         SEQUENCE {
                           OBJECT IDENTIFIER
                             rsaEncryption (1 2 840 113549 1 1 1)
                           NULL
                           }
                         BIT STRING, encapsulates {
                           SEQUENCE {
                             INTEGER
                       00 CF 50 81 96 9A F5 D8 E2 DE 0B CF A3 A6 FB 46
                       3E 88 0F 34 0F 5B 28 93 6D 32 EC D1 D0 0B 9B B4
                       5C 9E 12 F0 22 79 1E 6E 0D C6 39 7E A8 C5 01 A7
                       9F D8 93 D4 48 61 19 28 9A 93 7F ED 2A C4 CA 2C
                       E3 47 0C 49 D6 7E D2 FB BC 2C 08 0D 9C FF 05 E6
                       B0 EC 4B 93 1C AF 8E A9 F3 00 07 09 CF 9B 60 F6
                       ED D1 B9 62 6F F1 A7 D3 61 0A 64 30 93 C9 43 4A
                       0E 3E A3 3E 47 D7 B2 0D B4 65 53 CC 0A FE CF E5
                               [ Another 1 bytes skipped ]
                             INTEGER 65537
                             }
                           }
                         }
                       [3] {
                         SEQUENCE {
                           SEQUENCE {
                             OBJECT IDENTIFIER
                               basicConstraints (2 5 29 19)
                             OCTET STRING, encapsulates {
                               SEQUENCE {}
 
 
 Deacon                    Expires - May 2004                 [Page 16]


                        Lightweight OCSP Profile          November 2003
 
 
                               }
                             }
                           SEQUENCE {
                             OBJECT IDENTIFIER
                               certificatePolicies (2 5 29 32)
                             OCTET STRING, encapsulates {
                               SEQUENCE {
                                 SEQUENCE {
                                   OBJECT IDENTIFIER
                                           '2 16 840 1 1 1 7 23 3'
                                   SEQUENCE {
                                     SEQUENCE {
                                       OBJECT IDENTIFIER
                                         cps (1 3 6 1 5 5 7 2 1)
                                       IA5String
                                         'https://www.example.com/rpa'
                                       }
                                     }
                                   }
                                 }
                               }
                             }
                           SEQUENCE {
                             OBJECT IDENTIFIER extKeyUsage (2 5 29 37)
                             OCTET STRING, encapsulates {
                               SEQUENCE {
                                 OBJECT IDENTIFIER
                                   ocspSigning (1 3 6 1 5 5 7 3 9)
                                 }
                               }
                             }
                           SEQUENCE {
                             OBJECT IDENTIFIER keyUsage (2 5 29 15)
                             OCTET STRING, encapsulates {
                               BIT STRING 7 unused bits
                                 '1'B (bit 0)
                               }
                             }
                           SEQUENCE {
                             OBJECT IDENTIFIER
                               ocspNoCheck (1 3 6 1 5 5 7 48 1 5)
                             OCTET STRING, encapsulates {
                               NULL
                               }
                             }
                           }
                         }
                       }
                     SEQUENCE {
 
 
 Deacon                    Expires - May 2004                 [Page 17]


                        Lightweight OCSP Profile          November 2003
 
 
                       OBJECT IDENTIFIER
                         sha1withRSAEncryption (1 2 840 113549 1 1 5)
                       NULL
                       }
                     BIT STRING
                       91 C2 C6 73 75 63 9A 6E A9 A6 F1 4D 99 F6 63 93
                       83 78 2A DB DE 56 DE 86 B5 9A B5 E7 27 44 35 28
                       2E F3 62 B4 9F 17 9F 2B 21 31 90 00 B0 86 E3 AE
                       B6 2C 72 08 9B B8 9D A3 58 61 A8 01 35 8B 3C 6C
                       6A D4 FF 01 FA E7 25 0D E8 D4 A5 8D 8E DF 3A 39
                       11 DE 8E 7A 41 BC 56 48 98 A5 06 86 64 4E AD 0F
                       5B D1 C7 BB 11 57 45 D4 06 F6 FF 3C 7E C5 78 7B
                       68 C1 B6 71 9D 45 79 1D F7 03 0E 9E 6A 75 24 51
                     }
                   }
                 }
               }
             }
           }
         }
       }
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 Deacon                    Expires - May 2004                 [Page 18]