doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc5019.txt b/doc/rfc/rfc5019.txt
new file mode 100644
index 0000000..a3403d6
--- /dev/null
+++ b/doc/rfc/rfc5019.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                          A. Deacon
+Request for Comments: 5019                                      VeriSign
+Category: Standards Track                                       R. Hurst
+                                                               Microsoft
+                                                          September 2007
+
+
+   The Lightweight Online Certificate Status Protocol (OCSP) Profile
+                      for High-Volume Environments
+
+Status of This Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Abstract
+
+   This specification defines a profile of the Online Certificate Status
+   Protocol (OCSP) that addresses the scalability issues inherent when
+   using OCSP in large scale (high volume) Public Key Infrastructure
+   (PKI) environments and/or in PKI environments that require a
+   lightweight solution to minimize communication bandwidth and client-
+   side processing.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deacon & Hurst              Standards Track                     [Page 1]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Requirements Terminology ...................................4
+   2. OCSP Message Profile ............................................4
+      2.1. OCSP Request Profile .......................................4
+           2.1.1. OCSPRequest Structure ...............................4
+           2.1.2. Signed OCSPRequests .................................5
+      2.2. OCSP Response Profile ......................................5
+           2.2.1. OCSPResponse Structure ..............................5
+           2.2.2. Signed OCSPResponses ................................6
+           2.2.3. OCSPResponseStatus Values ...........................6
+           2.2.4. thisUpdate, nextUpdate, and producedAt ..............7
+   3. Client Behavior .................................................7
+      3.1. OCSP Responder Discovery ...................................7
+      3.2. Sending an OCSP Request ....................................7
+   4. Ensuring an OCSPResponse Is Fresh ...............................8
+   5. Transport Profile ...............................................9
+   6. Caching Recommendations .........................................9
+      6.1. Caching at the Client .....................................10
+      6.2. HTTP Proxies ..............................................10
+      6.3. Caching at Servers ........................................12
+   7. Security Considerations ........................................12
+      7.1. Replay Attacks ............................................12
+      7.2. Man-in-the-Middle Attacks .................................13
+      7.3. Impersonation Attacks .....................................13
+      7.4. Denial-of-Service Attacks .................................13
+      7.5. Modification of HTTP Headers ..............................14
+      7.6. Request Authentication and Authorization ..................14
+   8. Acknowledgements ...............................................14
+   9. References .....................................................14
+      9.1. Normative References ......................................14
+      9.2. Informative References ....................................15
+   Appendix A. Example OCSP Messages .................................16
+      A.1. OCSP Request ..............................................16
+      A.2. OCSP Response .............................................16
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deacon & Hurst              Standards Track                     [Page 2]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+1.  Introduction
+
+   The Online Certificate Status Protocol [OCSP] specifies a mechanism
+   used to determine the status of digital certificates, in lieu of
+   using Certificate Revocation Lists (CRLs).  Since its definition in
+   1999, it has been deployed in a variety of environments and has
+   proven to be a useful certificate status checking mechanism.  (For
+   brevity we refer to OCSP as being used to verify certificate status,
+   but only the revocation status of a certificate is checked via this
+   protocol.)
+
+   To date, many OCSP deployments have been used to ensure timely and
+   secure certificate status information for high-value electronic
+   transactions or highly sensitive information, such as in the banking
+   and financial environments.  As such, the requirement for an OCSP
+   responder to respond in "real time" (i.e., generating a new OCSP
+   response for each OCSP request) has been important.  In addition,
+   these deployments have operated in environments where bandwidth usage
+   is not an issue, and have run on client and server systems where
+   processing power is not constrained.
+
+   As the use of PKI continues to grow and move into diverse
+   environments, so does the need for a scalable and cost-effective
+   certificate status mechanism.  Although OCSP as currently defined and
+   deployed meets the need of small to medium-sized PKIs that operate on
+   powerful systems on wired networks, there is a limit as to how these
+   OCSP deployments scale from both an efficiency and cost perspective.
+   Mobile environments, where network bandwidth may be at a premium and
+   client-side devices are constrained from a processing point of view,
+   require the careful use of OCSP to minimize bandwidth usage and
+   client-side processing complexity. [OCSPMP]
+
+   PKI continues to be deployed into environments where millions if not
+   hundreds of millions of certificates have been issued.  In many of
+   these environments, an even larger number of users (also known as
+   relying parties) have the need to ensure that the certificate they
+   are relying upon has not been revoked.  As such, it is important that
+   OCSP is used in such a way that ensures the load on OCSP responders
+   and the network infrastructure required to host those responders are
+   kept to a minimum.
+
+   This document addresses the scalability issues inherent when using
+   OCSP in PKI environments described above by defining a message
+   profile and clarifying OCSP client and responder behavior that will
+   permit:
+
+
+
+
+
+
+Deacon & Hurst              Standards Track                     [Page 3]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+   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.
+
+   It is intended that the normative requirements defined in this
+   profile will be adopted by OCSP clients and OCSP responders operating
+   in very large-scale (high-volume) PKI environments or PKI
+   environments that require a lightweight solution to minimize
+   bandwidth and client-side processing power (or both), as described
+   above.  As OCSP does not have the means to signal responder
+   capabilities within the protocol, clients needing to differentiate
+   between OCSP responses produced by responders conformant with this
+   profile and those that are not need to rely on out-of-band mechanisms
+   to determine when a responder operates according to this profile and,
+   as such, when the requirements of this profile apply.  In the case
+   where out-of-band mechanisms may not be available, this profile
+   ensures that interoperability will still occur between a fully
+   conformant OCSP 2560 client and a responder that is operating in a
+   mode as described in this specification.
+
+1.1.  Requirements Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [RFC2119].
+
+2.  OCSP Message Profile
+
+   This section defines a subset of OCSPRequest and OCSPResponse
+   functionality as defined in [OCSP].
+
+2.1.  OCSP Request Profile
+
+2.1.1.  OCSPRequest Structure
+
+   OCSPRequests conformant to this profile MUST include only 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.
+
+   Clients SHOULD NOT include the requestExtensions structure.  If a
+   requestExtensions structure is included, this profile RECOMMENDS that
+   it contain only the nonce extension (id-pkix-ocsp-nonce).  See
+   Section 4 for issues concerning the use of a nonce in high-volume
+   OCSP environments.
+
+
+
+Deacon & Hurst              Standards Track                     [Page 4]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+2.1.2.  Signed OCSPRequests
+
+   Clients SHOULD NOT 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 contain the
+   requestorName field, but must realize that the provided value is not
+   authenticated.
+
+2.2.  OCSP Response Profile
+
+2.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
+   include only 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.  As specified in
+   [OCSP], clients MUST ignore unrecognized non-critical
+   responseExtensions in the response.
+
+   In the case where a responder does not have the ability to respond to
+   an OCSP request containing a option not supported by the server, it
+   SHOULD return the most complete response it can.  For example, in the
+   case where a responder only supports pre-produced responses and does
+   not have the ability to respond to an OCSP request containing a
+   nonce, it SHOULD return a response that does not include a nonce.
+
+   Clients SHOULD attempt to process a response even if the response
+   does not include a nonce.  See Section 4 for details on validating
+   responses that do not contain a nonce.  See also Section 7 for
+   relevant security considerations.
+
+   Responders that do not have the ability to respond to OCSP requests
+   that contain an unsupported option such as a nonce MAY forward the
+   request to an OCSP responder capable of doing so.
+
+   The responder MAY include the singleResponse.singleResponse
+   extensions structure.
+
+
+
+
+
+Deacon & Hurst              Standards Track                     [Page 5]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+2.2.2.  Signed OCSPResponses
+
+   Clients MUST validate the signature on the returned OCSPResponse.
+
+   If the response is signed by a delegate of the issuing certification
+   authority (CA), a valid responder certificate MUST be referenced in
+   the BasicOCSPResponse.certs structure.
+
+   It is RECOMMENDED that the OCSP responder's certificate contain the
+   id-pkix-ocsp-nocheck extension, as defined in [OCSP], to indicate to
+   the client that it need not check the certificate's status.  In
+   addition, it is RECOMMENDED that neither an OCSP authorityInfoAccess
+   (AIA) extension nor cRLDistributionPoints (CRLDP) extension be
+   included in the OCSP responder's certificate.  Accordingly, the
+   responder's signing certificate SHOULD be relatively short-lived and
+   renewed regularly.
+
+   Clients MUST be able to identify OCSP responder certificates using
+   both the byName and byKey ResponseData.ResponderID choices.
+   Responders SHOULD use byKey to further reduce the size of the
+   response in scenarios where reducing bandwidth is an issue.
+
+2.2.3.  OCSPResponseStatus Values
+
+   As long as the OCSP infrastructure has authoritative records for a
+   particular certificate, an OCSPResponseStatus of "successful" will be
+   returned.  When access to authoritative records for a particular
+   certificate is not available, the responder MUST return an
+   OCSPResponseStatus of "unauthorized".  As such, this profile extends
+   the RFC 2560 [OCSP] definition of "unauthorized" as follows:
+
+      The response "unauthorized" is returned in cases where the client
+      is not authorized to make this query to this server or the server
+      is not capable of responding authoritatively.
+
+   For example, OCSP responders that do not have access to authoritative
+   records for a requested certificate, such as those that generate and
+   distribute OCSP responses in advance and thus do not have the ability
+   to properly respond with a signed "successful" yet "unknown"
+   response, will respond with an OCSPResponseStatus of "unauthorized".
+   Also, 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.  Requests from clients for
+   certificates whose record has been removed will result in an
+   OCSPResponseStatus of "unauthorized".
+
+   Security considerations regarding the use of unsigned responses are
+   discussed in [OCSP].
+
+
+
+Deacon & Hurst              Standards Track                     [Page 6]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+2.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 will be
+                 available about the status of the certificate.
+                 Responders MUST always include this value to aid in
+                 response caching.  See Section 6 for additional
+                 information on caching.
+
+   producedAt    The time at which the OCSP response was signed.
+
+   Note: In many cases the value of thisUpdate and producedAt will be
+   the same.
+
+   For the purposes of this profile, ASN.1-encoded 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.
+
+3.  Client Behavior
+
+3.1.  OCSP Responder Discovery
+
+   Clients MUST support the authorityInfoAccess extension as defined in
+   [PKIX] and MUST recognize the id-ad-ocsp access method.  This enables
+   CAs to inform clients how they can contact the OCSP service.
+
+   In the case where a client is checking the status of a certificate
+   that contains both an authorityInformationAccess (AIA) extension
+   pointing to an OCSP responder and a cRLDistributionPoints extension
+   pointing to a CRL, the client SHOULD attempt to contact the OCSP
+   responder first.  Clients MAY attempt to retrieve the CRL if no
+   OCSPResponse is received from the responder after a locally
+   configured timeout and number of retries.
+
+3.2.  Sending an OCSP Request
+
+   To avoid needless network traffic, applications MUST verify the
+   signature of signed data before asking an OCSP client to check the
+   status of certificates used to verify the data.  If the signature is
+   invalid or the application is not able to verify it, an OCSP check
+   MUST NOT be requested.
+
+
+
+Deacon & Hurst              Standards Track                     [Page 7]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+   Similarly, an application MUST validate the signature on certificates
+   in a chain, before asking an OCSP client to check the status of the
+   certificate.  If the certificate signature is invalid or the
+   application is not able to verify it, an OCSP check MUST NOT be
+   requested.  Clients SHOULD NOT make a request to check the status of
+   expired certificates.
+
+4.  Ensuring an OCSPResponse Is Fresh
+
+   In order to ensure that 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, both clients and
+   responders 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 2.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 nonexistent 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 2.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 the 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.
+
+
+
+Deacon & Hurst              Standards Track                     [Page 8]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+   See the security considerations in Section 7 for additional details
+   on replay and man-in-the-middle attacks.
+
+5.  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
+   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 6.2 for details on the use of these headers.
+
+6.  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.
+
+
+
+Deacon & Hurst              Standards Track                     [Page 9]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+6.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.
+
+6.2.  HTTP Proxies
+
+   The responder SHOULD set the HTTP headers of the OCSP response in
+   such a way as 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.
+
+
+
+Deacon & Hurst              Standards Track                    [Page 10]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+                * 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.
+
+   For example, assume that an OCSP response has the following timestamp
+   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 include 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).
+
+
+
+
+
+
+
+
+Deacon & Hurst              Standards Track                    [Page 11]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+6.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.
+
+   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].
+
+7.  Security Considerations
+
+   The following considerations apply in addition to the security
+   considerations addressed in Section 5 of [OCSP].
+
+7.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 a 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.
+
+
+
+
+
+
+Deacon & Hurst              Standards Track                    [Page 12]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+   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
+   nonexistent expected nonce, but MUST fall back to validating the
+   OCSPResponse based on time.
+
+7.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.
+
+   The use of signed responses in OCSP serves 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.
+
+7.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.
+
+7.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.
+
+
+
+
+
+Deacon & Hurst              Standards Track                    [Page 13]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+7.5.  Modification of HTTP Headers
+
+   Values included in HTTP headers, as described in Sections 5 and 6,
+   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.
+
+7.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.
+
+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 References
+
+   [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, "X.509 Internet 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.
+
+
+
+
+
+Deacon & Hurst              Standards Track                    [Page 14]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+   [TLSEXT]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
+             and T. Wright, "Transport Layer Security (TLS) Extensions",
+             RFC 4366, April 2006.
+
+9.2.  Informative References
+
+   [OCSPMP]  "OCSP Mobile Profile V1.0", Open Mobile Alliance,
+             www.openmobilealliance.org.
+
+   [RFC3143] Cooper, I. and J. Dilley, "Known HTTP Proxy/Caching
+             Problems", RFC 3143, June 2001.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deacon & Hurst              Standards Track                    [Page 15]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+Appendix A.  Example OCSP Messages
+
+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
+              }
+            }
+          }
+        }
+      }
+
+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] {
+                  SEQUENCE {
+                    SET {
+                      SEQUENCE {
+                        OBJECT IDENTIFIER organizationName (2 5 4 10)
+                        PrintableString 'Example Trust Network'
+                        }
+                      }
+
+
+
+Deacon & Hurst              Standards Track                    [Page 16]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+                    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
+                      }
+                    }
+                  }
+                }
+              SEQUENCE {
+                OBJECT IDENTIFIER
+                  sha1withRSAEncryption (1 2 840 113549 1 1 5)
+                NULL
+                }
+
+
+
+Deacon & Hurst              Standards Track                    [Page 17]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+              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
+                               'Example CA'
+                            }
+                          }
+                        }
+                      SEQUENCE {
+
+
+
+Deacon & Hurst              Standards Track                    [Page 18]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+                        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
+                              [ Another 1 bytes skipped ]
+                            INTEGER 65537
+                            }
+                          }
+
+
+
+Deacon & Hurst              Standards Track                    [Page 19]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+                        }
+                      [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
+                      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
+
+
+
+Deacon & Hurst              Standards Track                    [Page 20]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+                      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
+                    }
+                  }
+                }
+              }
+            }
+          }
+        }
+      }
+
+Authors' Addresses
+
+   Alex Deacon
+   VeriSign, Inc.
+   487 E. Middlefield Road
+   Mountain View, CA  94043
+   USA
+
+   Phone:  1-650-426-3478
+   EMail:  alex@verisign.com
+
+
+   Ryan Hurst
+   Microsoft
+   One Microsoft Way
+   Redmond, WA  98052
+   USA
+
+   Phone:  1-425-707-8979
+   EMail:  rmh@microsoft.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Deacon & Hurst              Standards Track                    [Page 21]
+
+RFC 5019                Lightweight OCSP Profile          September 2007
+
+
+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.
+
+   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 & Hurst              Standards Track                    [Page 22]
+