Skip to main content

The Lightweight Online Certificate Status Protocol (OCSP) Profile for High-Volume Environments
draft-ietf-pkix-lightweight-ocsp-profile-11

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5019.
Authors Ryan Hurst , Alex Deacon
Last updated 2020-01-21 (Latest revision 2007-06-14)
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Proposed Standard
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state (None)
Document shepherd (None)
IESG IESG state Became RFC 5019 (Proposed Standard)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Russ Housley
Send notices to (None)
draft-ietf-pkix-lightweight-ocsp-profile-11
#x27;, 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, both clients 
   and responders MUST have access to an accurate source of time.   
    

  
  
 Deacon                 Expires - December 2007               [Page 7] 

                        Lightweight OCSP Profile             June 2007 
  
  
   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 SHOULD 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.    
    
   Clients that do not include a nonce in the request MUST ignore any 
   nonce that may be present in the response.   
    
   Clients MUST check for the existence of the nextUpdate field and 
   MUST ensure the current time, expressed in GMT time as described in 
   Section 1.2.4,  falls between the thisUpdate and nextUpdate times.  
   If the nextUpdate field is absent the client MUST reject the 
   response. 
    
   If the nextUpdate field is present the client MUST ensure that it is 
   not earlier than current time.  If the current 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 chosen based on the 
   accuracy and precision of time synchronization technology available 
   to the calling application environment. For example, Internet peers 
   with low latency connections typically expect NTP time 
   synchronization to keep them accurate within parts of a second; 
   higher latency environments or where an NTP analogue is not 
   available may have to be more liberal in their tolerance. 
    
   See the security considerations in Section 6 for additional details 
   on replay and man-in-the-middle attacks.   
    
 4. Transport Profile 
    
   The OCSP responder MUST support requests and responses over HTTP.  
   When sending requests that are less than or equal to 255 bytes in 
   total (after encoding) including the scheme and delimiters  
   (http://), server name and base64 encoded OCSPRequest structure, 
   clients MUST use the GET method (to enable 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. 
    
   When constructing a GET message, OCSP 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 

  
  
 Deacon                 Expires - December 2007               [Page 8] 

                        Lightweight OCSP Profile             June 2007 
  
  
   the base64-encoded string.  Clients MUST properly url-encode the 
   base64 encoded OCSPRequest. For example:   
    
      http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL
      2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg
      %3D%3D 
    
   In response to properly formatted OCSPRequests that are cachable 
   (i.e. responses that contain a nextUpdate value), the responder will 
   include the binary value of the DER encoding of the OCSPResponse 
   preceded by the following HTTP [HTTP] headers. 
    
      content-type: application/ocsp-response 
      content-length: <OCSP response length> 
      last-modified: <producedAt [HTTP] date> 
      ETag: "<strong validator>" 
      expires: <nextUpdate [HTTP] date> 
      cache-control: max-age=<n>, public, no-transform, must-revalidate 
      date: <current [HTTP] date> 
    
   See Section 5.2 for details on the use of these headers. 
    
 5. 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 
   including OCSP responses in protocol exchanges (aka stapling or 
   piggybacking), such as has been defined in TLS, is also discussed.   
    
 5.1 Caching at the Client 
    
   To minimize bandwidth usage, clients MUST locally cache 
   authoritative OCSP responses. (i.e., a response with a signature 
   that has been successfully validated and that indicate an 
   OCSPResponseStatus of 'successful')   
    
   Most OCSP clients will send OCSPrequests at or near the nextUpdate 
   time (when a cached response expires). To avoid large spikes in 
   responder load that might occur when many clients refresh cached 
   responses for a popular certificate, responders MAY indicate when 
   the client should fetch an updated OCSP response by using the cache-
   control:max-age directive.  Clients SHOULD fetch the updated OCSP 
   Response on or after the max-age time.  To ensure that clients 
   receive an updated OCSP response, OCSP Responders MUST refresh the 
   OCSP response before the max-age time.   
         
  
  
 Deacon                 Expires - December 2007               [Page 9] 

                        Lightweight OCSP Profile             June 2007 
  
  
 5.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 intermediate HTTP 
   proxy servers.  See [HTTP] for the full definition of these headers 
   and the proper format of any date and time values.   
    
   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. 
                   This date and time will be the same as the  
                   nextUpdate timestamp in the OCSP response itself.   
    
   ETag            A string that identifies a particular version of 
                   the associated data.  This profile RECOMMENDS that 
                   the ETag value be the ASCII HEX representation of  
                   the SHA1 hash of the OCSPResponse structure.   
    
   cache-control   Contains a number of caching directives. 
      
                * max-age=<n>- where n is a time value later than  
                               thisUpdate but earlier than nextUpdate.  
                * 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.  
    
    
   OCSP responders MUST NOT include a "Pragma: no-cache", "Cache-
   Control: no-cache" or "Cache-Control: no-store" header in 
   authoritative OCSP responses. 
    
   OCSP responders SHOULD include one or more of these headers in non-
   authoritative OCSP responses. 
    

  
  
 Deacon                 Expires - December 2007              [Page 10] 

                        Lightweight OCSP Profile             June 2007 
  
  
   For example, assume that an OCSP response has the following time 
   stamp values: 
    
      thisUpdate = May 1, 2005  01:00:00 GMT 
      nextUpdate = May 3, 2005 01:00:00 GMT 
      productedAt = May 1, 2005 01:00:00 GMT 
    
   and that an OCSP client requests the response on May 2, 2005 
   01:00:00 GMT.  In this scenario the HTTP response may look like 
   this: 
    
      content-type: application/ocsp-response 
      content-length: 1000 
      date: Fri, 02 May 2005 01:00:00 GMT 
      last-modified: Thu, 01 May 2005 01:00:00 GMT 
      ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713" 
      expires: Sat, 03 May 2005 01:00:00 GMT 
      cache-control: max-age=86000,public,no-transform,must-revalidate 
      <...> 
    
   OCSP clients MUST NOT included a no-cache header in OCSP request 
   messages, unless the client encounters an expired response which may 
   be a result of an intermediate proxy caching stale data.   In this 
   situation clients SHOULD resend the request specifying that proxies 
   should be bypassed by including an appropriate HTTP header in the 
   request (i.e. Pragma: no-cache or Cache-Control: no-cache).   
    
 5.3 Caching at Servers 
    
   In some scenarios it is advantageous to include OCSP response 
   information within the protocol being utilized between the client 
   and server.  Including 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 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. 
    
   Third, it reduces the number of round trips the client needs to make 
   in order to complete a handshake.   
    
   Fourth, it simplifies the client side OCSP implementation by 
   enabling a situation where the client need only the ability to parse 
   and recognize OCSP responses.  
    

  
  
 Deacon                 Expires - December 2007              [Page 11] 

                        Lightweight OCSP Profile             June 2007 
  
  
   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.  
    
   Further information regarding caching issues can be obtained from 
   RFC 3143 [RFC3143].   
    
 6. Security Considerations  
    
   The following considerations apply in addition to the security 
   consideration addressed in Section 5 of [OCSP].  
    
 6.1 Replay attacks 
    
   Because the use of nonces 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.   
  
   Clients that do not have an accurate source of date and time are 
   vulnerable to service disruption.  For example, a client with a 
   sufficiently fast clock may reject a fresh OCSP response.  Similarly 
   a client with a sufficiently slow clock may incorrectly accept 
   expired valid responses for certificates that may in fact be 
   revoked. 
    
   Future versions of the OCSP protocol may provide a way for the 
   client to know whether the server supports nonces or does not 
   support nonces.  If a client can determine that the server supports 
   nonces, it MUST reject a reply that does not contain an expected 
   nonce.  Otherwise, clients that opt to include a nonce in the 
   request SHOULD 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. 
    
    
 6.2 Man-in-the-middle attacks 
    
   To mitigate risk associated with this class of attack, the client 
   must properly validate the signature on the response.   
    

  
  
 Deacon                 Expires - December 2007              [Page 12] 

                        Lightweight OCSP Profile             June 2007 
  
  
   The use of signed responses in OCSP serves the purpose to 
   authenticate the identity of the OCSP responder and to verify that 
   it is authorized to sign responses 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. 
    
 6.3 Impersonation attacks 
    
   The use of signed responses in OCSP serves to authenticate the 
   identity of OCSP Responder. 
    
   As detailed in [OCSP], clients must properly validate the signature 
   of the OCSP response and the signature on the OCSP response signer 
   certificate to ensure an authorized responder created it. 
    
 6.4 Denial of service attacks 
    
   OCSP responders should take measures to prevent or mitigate denial 
   of service attacks.  As this profile specifies the use of unsigned 
   OCSPRequests, access to the responder may be implicitly given to 
   everyone who can send a request to a responder, and thus the ability 
   to mount a denial of service attack via a flood of requests may be 
   greater.  For example a responder could limit the rate of incoming 
   requests from a particular IP address if questionable behavior is 
   detected.   
    
 6.5 Modification of HTTP Headers 
    
   Values included in HTTP headers as described in Section 4 and 5, are 
   not cryptographically protected, they may be manipulated by an 
   attacker.  Clients SHOULD use these values for caching guidance only 
   and ultimately SHOULD rely only on the values present in the signed 
   OCSPResponse.  Clients SHOULD NOT rely on cached responses beyond 
   the nextUpdate time. 
    
 6.6 Request Authentication and Authorization 
    
   The suggested use of unsigned requests in this environment removes 
   an option that allows the responder to determine the authenticity of 
   incoming request.  Thus, access to the responder may be implicitly 
   given to everyone who can send a request to a responder.  
   Environments where explicit authorization to access the OCSP 
   responder is necessary can utilize other mechanisms to authenticate 
   requestors or restrict or meter service. 
    
 7. IANA Considerations 
    
   This document has no actions for IANA. 
  
  
 Deacon                 Expires - December 2007              [Page 13] 

                        Lightweight OCSP Profile             June 2007 
  
  
    
 8. 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. 
    
 9. References 
    
 9.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. 
    
   [RFC2119] 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 E. Rescorla, "The Transport Layer Security 
             Protocol Version  1.1", RFC 4346, April 2006. 
    
   [TLSEXT]  Blake-Wilson, et. al., "Transport Layer Security (TLS) 
             Extensions", RFC 4366, April 2006. 
    
    
 9.2 Informative 
    
    
   [OCSPMP]  "OCSP Mobile Profile V1.0", Open Mobile Alliance,  
             www.openmobilalliance.org.   
    
   [RFC3143] Cooper, I., Dilley, J., "Known HTTP Proxy/Caching  
             Problems", RFC 3143, June 2001 
    
 10. Author's Addresses  
    
   Alex Deacon  
   VeriSign, Inc.  
   487 E. Middlefield Road      Phone:  1-650-426-3478  
  
  
 Deacon                 Expires - December 2007              [Page 14] 

                        Lightweight OCSP Profile             June 2007 
  
  
   Mountain View, CA. USA       Email:  alex@verisign.com 
    
   Ryan Hurst  
   Microsoft  
   One Microsoft Way            Phone:  1-425-707-8979  
   Redmond, WA. USA             Email:  rmh@microsoft.com 
    
    
 Appendix A.  Example OCSP Messages 
    
 Appendix A.1: OCSP Request 
    
   SEQUENCE { 
      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 
                09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA 
              } 
            } 
          } 
        } 
      } 
    
 Appendix A.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 { 
                [0] { 
                  INTEGER 0 
                  } 
                [1] { 
  
  
 Deacon                 Expires - December 2007              [Page 15] 

                        Lightweight OCSP Profile             June 2007 
  
  
                  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 OCSP Responder' 
                        } 
                      } 
                    } 
                  } 
                GeneralizedTime 07/11/2005 23:52:44 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 
                      09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA 
                      } 
                    [0] 
                      Error: Object has zero length. 
                      GeneralizedTime 07/11/2005 23:52:44 GMT 
                    [0] { 
                      GeneralizedTime 14/11/2005 23:52:44 GMT 
                      } 
                    } 
                  } 
  
  
 Deacon                 Expires - December 2007              [Page 16] 

                        Lightweight OCSP Profile             June 2007 
  
  
                } 
              SEQUENCE { 
                OBJECT IDENTIFIER 
                  sha1withRSAEncryption (1 2 840 113549 1 1 5) 
                NULL 
                } 
              BIT STRING 
                0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2 
                F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98 
                8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7 
                3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84 
                EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1 
                42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A 
                A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC 
                BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30 
              [0] { 
                SEQUENCE { 
                  SEQUENCE { 
                    SEQUENCE { 
                      [0] { 
                        INTEGER 2 
                        } 
                      INTEGER 
                      49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA 
                      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 
  
  
 Deacon                 Expires - December 2007              [Page 17] 

                        Lightweight OCSP Profile             June 2007 
  
  
                               'Example CA' 
                            } 
                          } 
                        } 
                      SEQUENCE { 
                        UTCTime 08/10/2005 00:00:00 GMT 
                        UTCTime 06/01/2006 23:59:59 GMT 
                        } 
                      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 OCSP Responder' 
                            } 
                          } 
                        } 
                      SEQUENCE { 
                        SEQUENCE { 
                          OBJECT IDENTIFIER 
                            rsaEncryption (1 2 840 113549 1 1 1) 
                          NULL 
                          } 
                        BIT STRING, encapsulates { 
                          SEQUENCE { 
                            INTEGER 
                      00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D 
                      D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A 
                      00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F 
                      81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C 
                      A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5 
                      0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41 
                      04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E 
                      D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2 
  
  
 Deacon                 Expires - December 2007              [Page 18] 

                        Lightweight OCSP Profile             June 2007 
  
  
                              [ Another 1 bytes skipped ] 
                            INTEGER 65537 
                            } 
                          } 
                        } 
                      [3] { 
                        SEQUENCE { 
                          SEQUENCE { 
                            OBJECT IDENTIFIER 
                              basicConstraints (2 5 29 19) 
                            OCTET STRING, encapsulates { 
                              SEQUENCE {} 
                              } 
                            } 
                          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 { 
                      OBJECT IDENTIFIER 
                        sha1withRSAEncryption (1 2 840 113549 1 1 5) 
                      NULL 
                      } 
                    BIT STRING 
                      3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE 
                      1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73 
                      C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB 
  
  
 Deacon                 Expires - December 2007              [Page 19] 

                        Lightweight OCSP Profile             June 2007 
  
  
                      80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29 
                      14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5 
                      8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B 
                      9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4 
                      3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A 
                    } 
                  } 
                } 
              } 
            } 
          } 
        } 
      } 
    
 Full Copyright Statement 
    
   Copyright (C) The IETF Trust (2007). 
    
   This document is subject to the rights, licenses and restrictions 
   contained in BCP 78, and except as set forth therein, the authors 
   retain all their rights. 
  
   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. 

    
 Intellectual Property 
    
   The IETF takes no position regarding the validity or scope of any 
   Intellectual Property Rights or other rights that might be claimed 
   to pertain to the implementation or use of the technology described 
   in this document or the extent to which any license under such 
   rights might or might not be available; nor does it represent that 
   it has made any independent effort to identify any such rights.  
   Information on the procedures with respect to rights in RFC 
   documents can be found in BCP 78 and BCP 79. 
    
   Copies of IPR disclosures made to the IETF Secretariat and any 
   assurances of licenses to be made available, or the result of an 
   attempt made to obtain a general license or permission for the use 
   of such proprietary rights by implementers or users of this 
   specification can be obtained from the IETF on-line IPR repository 
   at http://www.ietf.org/ipr. 
    
  
  
 Deacon                 Expires - December 2007              [Page 20] 

                        Lightweight OCSP Profile             June 2007 
  
  
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights that may cover technology that may be required to implement 
   this standard.  Please address the information to the IETF at 
   ietf-ipr@ietf.org. 
    

  
  
 Deacon                 Expires - December 2007              [Page 21]