[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

PKIX Working Group                                          M. Branchaud
INTERNET-DRAFT                                                     Xcert
Expires in six months                                         April 1998

                   Internet Public Key Infrastructure
             Caching the Online Certificate Status Protocol
                  draft-ietf-pkix-ocsp-caching-00.txt

1.  Status of this Memo

   This document is an Internet-Draft.  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 6 months
   and may be updated, replaced, or rendered obsolete 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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific
   Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

   Distribution of this document is unlimited.

   This Internet Draft expires in October 1998.

2.  Abstract

   The Online Certificate Status Protocol [OCSP] specifies how a client
   process may obtain certificate status information online from a
   server.  In order for OCSP to scale beyond small communities of
   users, a method to cache certificate status information at
   intermediary servers is required.

   This document describes the requirements of and assumptions behind
   OCSP caching, and defines the mechanisms through which such caching
   can be accomplished.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document (in uppercase, as shown) are to be interpreted as described
   in [RFC2119].




Branchaud                                                       [Page 1]


INTERNET DRAFT                OCSP Caching                    April 1998



3.  Change Log

   This is the first draft of this document.















































Branchaud                                                       [Page 2]


INTERNET DRAFT                OCSP Caching                    April 1998



4.  Contents

  1.  Status of this Memo ............................................ 1
  2.  Abstract ....................................................... 1
  3.  Change Log ..................................................... 2
  4.  Contents ....................................................... 3
  5.  Introduction ................................................... 4
  6.  Cached OCSP Overview ........................................... 5
      6.1 OCSP Entities .............................................. 5
      6.2 OCSP Example ............................................... 6
  7.  OCSP Caching ................................................... 9
      7.1 Correctness of Cache Entries ............................... 9
      7.2 Age Calculations .......................................... 10
      7.3 Server Cache Management ................................... 12
      7.4 OCSP Cache Entry Validation ............................... 12
  8.  Caching Enhancements to OCSP .................................. 14
      8.1 The unchanged Certificate Status Value .................... 14
      8.2 The Presumed Status Extension ............................. 14
      8.3 The Cache Warnings Extension .............................. 15
      8.4 The Cache Status Information Extension .................... 16
      8.5 The Request Cache Parameters Extension .................... 17
      8.6 The Response Cache Parameters Extension ................... 18
  9.  HTTP and OCSP Caching ......................................... 20
  10. Security Considerations ....................................... 23
  11. Patent Considerations ......................................... 24
  12. References .................................................... 24
  13. Author's Address .............................................. 24
  14. Appendix - Collected ASN.1 .................................... 25






















Branchaud                                                       [Page 3]


INTERNET DRAFT                OCSP Caching                    April 1998



5.  Introduction

   OCSP can allow a certificate processing entity to obtain certificate
   status information directly from a Certification Authority (CA).
   However, on the global Internet, it is impractical for any entity to
   directly contact the CAs of each certificate it encounters.  For one
   thing, such behavior would require that the entity securely obtain a
   copy of every CA's OCSP responder key.  For another, CAs would
   quickly find themselves overwhelmed by the volume of OCSP requests.

   One solution to these impracticalities is to employ OCSP servers as
   intermediaries between the entities and the CAs, and to allow those
   servers to cache certificate status information.  While this allows
   CAs to distribute their OCSP loads, caching introduces an extra layer
   of complexity that must be addressed.

   In particular, cached data can not be transparently passed to a
   querying entity.  Because of the way certificates are used, it is
   important for an entity to know how long a status value has been
   cached.  The entity may be much more willing to accept a particular
   status response if it was created two seconds ago than if it is two
   weeks old.

   The nature of certificate-using systems also requires that they be
   able to override OCSP caches as needed.  An entity's policies for
   most of its applications may allow it to accept status information
   that has been cached for, say, less than a day.  However, those
   policies may also dictate that for a particular application it must
   obtain status that has been cached for no more than 1 hour.

   The OCSP caching mechanisms described in this document are designed
   to permit this kind of flexibility.  The following section presents
   an overview and example of cached OCSP, to illustrate the basic
   operations expected of OCSP participants.  The details of OCSP
   caching are described in Section 7.  Definitions of the OCSP
   extensions required for caching are presented in Section 8.  OCSP's
   caching closely resembles that defined in HTTP 1.1, and a discussion
   of the relationship between the two systems is in Section 9.












Branchaud                                                       [Page 4]


INTERNET DRAFT                OCSP Caching                    April 1998



6.  Cached OCSP Overview

   This section describes the requirements and assumptions behind cached
   OCSP by presenting an overview of the protocol.  We first define the
   entities that participate in cached OCSP, then provide an example of
   the protocol's operation.

6.1  OCSP Entities

   Three types of entities participate in the cached OCSP protocol:

    o Clients - entities which request a certificate's status;

    o Servers - entities which cache status information and respond to
      clients' requests;

    o CAs - the entities with authoritative information about the status
      of some certificates.

6.1.1  OCSP Clients

   OCSP clients request certificate status information from OCSP
   servers.  An OCSP client MAY be another OCSP server or CA, or it MAY
   be an "end" entity: one that originates a status request.  Any client
   MAY cache a response.  Indeed, OCSP servers usually cache the
   responses they receive, but OCSP's caching mechanisms are flexible
   enough to allow end entities to also cache responses and use them,
   for example, in offline operations.

   In general, clients that are not themselves OCSP servers SHOULD use
   only a few, usually one, OCSP server.  This is because such clients
   need to have complete trust in their OCSP server's public key, to the
   same extent that they would trust a root CA's key.  In particular,
   clients MUST obtain a server's key in a trusted fashion as it would
   the key of a trusted root CA.  When a client obtains a server's key
   in this way, the client is said to "trust" the server.  Clients MAY
   accept in-band revocation notification of a server's key, however
   they MUST NOT accept an in-band replacement for a revoked server key.
   When a client is made aware of the revocation of a server's key,
   whether through in-band or out-of-band notification, it MUST NOT use
   that server for OCSP processing until it obtains a new key for the
   server via an out-of-band channel.

6.1.2  OCSP Servers

   OCSP servers reply to OCSP requests.  In creating a response, a
   server MAY used cached information if it is appropriate, or it MAY
   forward the requests to other OCSP servers.


Branchaud                                                       [Page 5]


INTERNET DRAFT                OCSP Caching                    April 1998



   When an OCSP server receives a query, it first checks its local store
   of certificate information to see if it can fulfill the request with
   cached data.  This local store is mostly made up of cached
   information but can also include authoritative information from a co-
   located CA (see below).  If the OCSP server can fulfill the request
   from its local store, it does so.  Otherwise, the server MAY make one
   or more queries to other OCSP servers that it trusts.  If it receives
   a definitive response from those queries (as opposed to a "status
   unknown" or error response), it SHOULD store that information in its
   local cache before returning the response to the client.  Note that
   the client need not have any knowledge of the keys of the other OCSP
   servers.

6.1.3  OCSP CAs

   All OCSP CAs are also OCSP servers and act in an identical fashion
   except that there is no need for an OCSP CA to "cache" the status of
   its own certificates.  Any CA that supports cached OCSP MUST operate
   an OCSP server, and that server is said to be "co-located" with that
   CA.  A single OCSP server MAY be co-located with more than one CA.
   When a caching OCSP server is co-located with a CA, it does not cache
   certificate status information for that CA's certificates.  It
   instead has access to the CA's own authoritative information about
   those certificates.  That is, the co-located OCSP server is the
   source of its CA's OCSP information.  It is most likely that the co-
   located OCSP server has direct, local access to, or is even
   integrated with, the CA's directory service.

   Authoritative certificate information consists simply of the
   certificate and its status.  How these two pieces of information are
   associated is beyond the scope of this document.  The certificate's
   directory entry MAY have a status attribute, or the certificate's
   status MAY be defined by how the certificate is stored in the
   directory, or status MAY be determined by some other means.
   Regardless, a co-located OCSP server MUST have direct and immediate
   access to a CA's internal certificate status information.  The co-
   located OCSP server MUST NOT receive that information via a CRL or
   some other periodic means.  Note that a server that is not co-located
   with a CA MAY receive status information from that CA periodically.

   This document uses the term "CA" interchangeably with "co-located
   OCSP server."

6.2  OCSP Example

   The best way to understand OCSP caching is to study an example of it
   in operation.  This section presents such an example that depicts the
   typical behavior expected of the various OCSP entities.  This example


Branchaud                                                       [Page 6]


INTERNET DRAFT                OCSP Caching                    April 1998



   glosses over the finer points of OCSP caching in order to focus on
   the basic principles of the protocol.


                          +----+     +----+  +-->e
                     e2<--| S2 |<----| S3 |--+---->e
                          +----+     +----+
                                        ^
                                        |
                                        |
              +-----+     +----+     +-----+  +-->e
          e<--| CA1 |<----| S1 |<--->| CA2 |--+----->e
              +-----+     +----+     +-----+  +--->e
                |           |           |
            e<--+-->e       +-->e1      +-->e
                        e<--+---->e

            Figure 1 -- OCSP Entity Relationships


   Figure 1 depicts the typical relationships among the OCSP entities
   (end entity clients are represented by a lowercase e, servers by an S
   and CAs by the letters CA).  The arrows indicate the distribution of
   OCSP public key values: The entity at the source of an arrow has
   distributed its public key to the entity at the head of an arrow.
   These OCSP keys are distributed securely, as described above.

   OCSP queries flow oppositely to the directions depicted by the
   arrows.  Let's say that e1, an end entity client of S1, wishes to
   determine the status of a certificate, C1, issued by CA1.  Assuming
   that no entity has cached any information yet, e1 would send a status
   query to S1.  Since S1 has obtained CA1's public key, it "recognizes"
   the issuer of certificate C1 and sends its own query to that issuer:
   CA1.

   CA1 returns a response containing the certificate's status.  S1 can
   verify the authenticity of the response because it knows CA1's public
   OCSP key.  S1 can now cache and return the response to e1, and e1 can
   authenticate S1's response because it knows S1's public key.  In this
   way, e1 can obtain C1's status without having direct knowledge of
   CA1's public OCSP key.  If e1 makes another query for the status of
   C1, S1 can return its cached value if it's acceptable to e1.

   Let's add an extra level of indirection and consider how e2, a client
   of S2, would obtain the status of the a certificate, C2, issued by
   CA2.  When e2 sends its query to S2, the server does not recognize
   C2's issuer because the server has not securely obtained CA2's public
   OCSP key.  However, the server can be configured to query a number of


Branchaud                                                       [Page 7]


INTERNET DRAFT                OCSP Caching                    April 1998



   default servers when it encounters a certificate that it doesn't
   recognize.  Here, S2 would send a query to S3, and now the process
   would proceed in the same manner as before, with both S3 and S2
   caching the response.  In fact, S3 would act no differently than it
   would if the query came from any other kind of client.

   Note that the clients of CA1 can not obtain the status of any
   certificates issued by CA2 since CA1 does not have a copy of any of
   the servers' public keys, and so it can not make any external OCSP
   queries.  However, clients of CA2 can obtain the status of CA1's
   certificates, since CA2 has exchanged public keys with S1 (notice the
   two-way arrow between S1 and CA2).

   As we conclude this section, notice that the OCSP relationships
   between entities represent the trust relationships for the PKI.  That
   is, OCSP relationships are similar to those established under cross-
   certification.  If one entity trusts another to provide status
   information, then it can become an OCSP client to that entity by
   obtaining its public key.  Thus, trust relationships are expressed
   through an explicit decision to trust an entity for status
   information.  Also, an entity can require its consent before it is
   trusted, by simply refusing to answer any queries from entities that
   it doesn't recognize.

   This discussion glossed over the finer points of OCSP caching.  The
   next section deals with caching, but first note that OCSP caching
   does not change the mapping between OCSP relationships and trust
   relationships, nor does it affect the basic OCSP procedures described
   above.  Instead, the caching allows the end-to-end requirement for
   OCSP messages - that a query must reach the authoritative CA - to be
   relaxed when appropriate.



















Branchaud                                                       [Page 8]


INTERNET DRAFT                OCSP Caching                    April 1998



7.  OCSP Caching

   OCSP uses caching to improve performance across the network.  Caching
   certificate status information leads to the possibility of a cached
   status value becoming invalid but still being accepted as accurate.
   In an extreme sense, the same could be said of any copy of
   certificate status held outside the CA (such as a CRL).  The value
   being copied could even become invalid in transit, and so the copy
   could be invalid before it even exists.  Physical limitations,
   prevent absolutely accurate status information from being instantly
   available to all concerned parties.  Even if such propagation were
   possible, network bandwidth is a scarce resource that should be used
   sparingly.  OCSP's caching is designed with these constraints in mind
   to provide the most practical, online propagation of certificate
   status information.  In particular, OCSP caching was designed to meet
   the following criteria:

    o A relying party MUST always be able to override any intermediary
      caches between it and the CA, so that it MAY (at its discretion)
      obtain the most up-to-date status information possible.  OCSP
      clients can formulate their requests with a number of cache
      parameters that allow them to finely tune requests to suit their
      needs.

    o A relying party MUST always be given enough information to
      determine if a given certificate status value is acceptable for
      its purpose.  To this end, OCSP clients are provided with the
      amount of time that has elapsed since the status value was
      generated by the CA.  This elapsed time is called the age of the
      status value.

    o A CA MUST always be able to specify how the status for a
      particular certificate should be cached.  OCSP CAs MAY include
      recommended caching parameters in their replies that other OCSP
      entities SHOULD observe.  Note that entities may be forced to
      ignore a CA's caching requirements (for example, if the entity
      can't establish a connection to the CA), but do so at their own
      peril.

   With these criteria in mind, we now describe OCSP caching.  First, we
   define how a server determines if it can respond to a query with a
   cached value.

7.1  Correctness of Cache Entries

   An OCSP cache entry is said to be correct when an OCSP server can use
   the entry to reply to a request.  An OCSP cache entry is correct if
   it meets either of the following criteria:


Branchaud                                                       [Page 9]


INTERNET DRAFT                OCSP Caching                    April 1998



   1. It is "fresh enough" (see Section 7.2.2).  By default, this means
      that it meets the caching requirements of the client, the server
      and the CA.;

   2. It includes a warning if the cache requirements of the client or
      the CA are not met.

   If an OCSP server receives a response that it would normally forward
   to a client, and that response is no longer fresh, the server should
   forward the response to the client without attaching any warnings.
   An OCSP server SHOULD NOT attempt to revalidate a response that
   became stale in transit, as this might lead to an infinite loop.

   Whenever an OCSP server returns a response that is not "fresh enough"
   it MUST attach an appropriate warning to the response (see Section
   8.3).

7.2  Age Calculations

   In order to know if a cache entry is fresh, its current age MUST be
   compared to its freshness lifetime (the age at which it becomes
   stale).  This section describes how to calculate those two values,
   and how to determine if an entry is fresh.

7.2.1  Current Age

   OCSP entities calculate the current age of a response using the
   following values:

   now: The current local time of the entity performing the age
      calculation.

   producedAt: This value is the time at which the response was
      generated by the CA.  CAs MAY include this value in their
      responses.  When a response is generated from a CRL, the value of
      producedAt SHOULD be the value of the thisUpdate field of the CRL.

   requested_time: This is the receiving entity's local time when it
      sent the request that triggered this response.

   received_time: This is the receiving entity's local time when it
      received the response.

   age_value: This is the value of the age field in the response.  This
      is the current age of the response as calculated by the entity
      sending the response at the time of transmission.  All entities
      MUST include an age value in any response.  OCSP ages are
      expressed in seconds.


Branchaud                                                      [Page 10]


INTERNET DRAFT                OCSP Caching                    April 1998



   The calculation is outlined below.

   apparent_age       = max (0, received_time - producedAt)
   received_age       = max (apparent_age, age_value)
   entry_creation_age = received_age + (received_time - requested_time)
   entry_local_age    = now - received_time
   current_age        = entry_creation_age + entry_local_age

   If the response does not include a producedAt value, then the
   received_age SHOULD be set to age_value and the first two steps above
   SHOULD be skipped.

   Essentially, this calculation provides a conservative estimate of the
   sum of the number of seconds the response has been resident in each
   of the caches between the calculating entity and the CA, plus the
   number of seconds the response has spent in transit.

   When an OCSP server sends a response to any entity, it MUST calculate
   its current_age and include it as the value of the age field in the
   response.  CAs SHOULD provide an age value of 0 in their responses.
   This helps inquirers to determine if the response comes directly from
   an authoritative source.

   Finally, note that if there is a significant difference between the
   clocks of the calculating entity and the CA, this calculation may
   lead to inordinately old age values.  For this reason, entities MAY
   ignore the producedAt value in a response and proceed as if it were
   not present.

7.2.2  Freshness Calculation

   The freshness lifetime of a cache entry is defined by the maxAge
   value specified by the CA in its authoritative response to a request.
   If this value is not present in the response, the calculating entity
   MAY use a locally-defined heuristic to determine the entry's
   freshness lifetime.  For example, an entity might be configured with
   a 24 hour freshness lifetime for (entries for) email certificates,
   while it may only have a 5 second freshness lifetime for any
   aircraft-carrier-purchasing certificates.

   Once a freshness lifetime is obtained, the freshness of an entry is
   calculated by simply comparing its freshness lifetime to its
   current_age:

   entry_is_fresh = (freshness_lifetime > current_age)





Branchaud                                                      [Page 11]


INTERNET DRAFT                OCSP Caching                    April 1998



7.2.3  Disambiguating Multiple Responses

   A client MAY send out more than one request message to determine the
   status of a single certificate (e.g. a query MAY be sent to several
   OCSP servers).  Thus, an entity may receive responses from multiple
   paths.  To disambiguate these responses, the client SHOULD use the
   one with the lowest age value.

7.3  Server Cache Management

   Servers are at liberty to manage their caches in any way they see
   fit.  This section merely presents some recommendations that they MAY
   wish to adopt.

   When a server recovers from a crash or is restarted after being down
   for some reason, it SHOULD erase its cache.  This provides the most
   secure and easiest to implement startup environment.  If a server
   elects to keep its cache data between downtimes, it MUST at least
   ensure that the current ages of all the entries are appropriately
   adjusted for the missing time.

   Servers MAY elect to refresh their caches periodically.  A server may
   "pull" status information for multiple certificates by including all
   the certificates in a single "batch" query submitted to the CA.  The
   point here is that a server need not wait for a query to trigger a
   refresh of a cached value.

7.4  OCSP Cache Entry Validation

   When an OCSP query includes a status value for the identified
   certificate (see Section 8.2), the query is called a "validation".
   Only CAs MAY reply to validations, and they MUST only reply to
   validations of certificates for which they are authoritative (a CA,
   and other servers, MAY still relay the validation to another CA or
   server, and return their response).  OCSP servers MUST NOT use cached
   data to reply to a validation.  A CA MAY reply to a validation with a
   normal response, or it MAY follow the procedure described in this
   section.

   The purpose of a validation is to provide entities with a fast and
   efficient method to determine if a certificate's status has changed
   since it was last obtained.  This is often done to see if a stale
   entry is still accurate (if so, the entry MAY be refreshed).  The
   client includes its current notion of the certificate's status in the
   query.  Servers relay the query to the certificate's CA.  When the CA
   receives this message, it compares the presented status with the
   certificate's actual current status.



Branchaud                                                      [Page 12]


INTERNET DRAFT                OCSP Caching                    April 1998



   If the statuses match, then the CA MAY return a response consisting
   of the certID and a responseStatus field with the value "unchanged"
   (see Section 8.1).  The CA MAY include any optional fields or
   extensions in the response.

   If the statuses do not match (i.e. the status and / or time values
   are different), then the CA MUST respond to the query as if it were a
   normal query.  The CA MUST ignore the presumedStatus value presented
   in the validation query (see Section 8.2).

   An entity that receives a responseStatus value of "unchanged" in
   response to a validation may recalculate the current age of its cache
   entry for the response's certificate.  It MUST do so by setting
   received_age equal to the response's age value in the response and
   skipping the first two steps of the calculation described in Section
   7.2.1.  If a server is configured to perform this recalculation, and
   it is going to forward the response of the validation to a client,
   then it MUST perform the recalculation before relaying the response.
   That is, the age value of the relayed response MUST be set to the
   newly calculated current_age.






























Branchaud                                                      [Page 13]


INTERNET DRAFT                OCSP Caching                    April 1998



8.  Caching Enhancements to OCSP

   This sections presents detailed definitions of the additions and
   extensions OCSP requires for caching, and further specifies the
   behavior of the OCSP entities.  Most of these enhancements are
   defined as extensions to the basic OCSP protocol.  These extensions
   are not optional for cached OCSP, and implementations MUST support
   them as required below.

8.1  The unchanged Certificate Status Value

   A new certificate status is defined for cached OCSP: unchanged.

     OCSPResponseStatus ::= ENUMERATED {
         successful         (0),   -- Response has valid confirmations
         malformedRequest   (1),   -- Illegal confirmation request
         internalError      (2),   -- Internal error in issuer
         tryLater           (3),   -- Try again later
         notFound           (4),   -- Certificate not on record
         certRequired       (5),   -- Must supply certificate
         unchanged          (6)    -- Status has not changed
     }

   The unchanged state is used in response to an OCSP cache entry
   validation (see Section 7.4).  A CA MUST NOT use this state in
   response to a normal query.  When responding to a validation, a CA
   MAY use this state if the current state of the certificate being
   validated matches the presumed state sent in the validation.

8.2  The Presumed Status Extension

   This extension is used to create validation queries.  That is, a
   query that includes this extension MAY be treated as a validation
   query.  Responses MUST NOT contain this extension.  It contains the
   client's current notion of the certificate's status.

     presumedStatus EXTENSION ::= {
         SYNTAX PresumedStatusSyntax
         IDENTIFIED BY id-ocsp-presumedStatus
     }

     PresumedStatusSyntax ::= OCSPResponseStatus

     id-ocsp-presumedStatus OBJECT IDENTIFIER ::= TBA

   OCSP clients MUST NOT use the "unchanged" status value in a
   validation query.  CAs which receive a query with this extension MAY
   treat the query as a validation (see Section 7.4), unless the


Branchaud                                                      [Page 14]


INTERNET DRAFT                OCSP Caching                    April 1998



   extension's value is

   set to "unchanged."  In that case the CA MUST NOT treat the query as
   a validation.  Note that queries which include an "unchanged" value
   in this extension do not conform to the cached OCSP protocol.

   This extension SHALL NOT be marked critical.

8.3  The Cache Warnings Extension

   This extension contains warnings about the cache status of a
   certificate status response.  This extension SHALL NOT be marked
   critical.  It is defined as follows:

     cacheWarnings EXTENSION ::= {
         SYNTAX CacheWarningsSyntax
         IDENTIFIED BY id-ocsp-cacheWarnings
     }

     CacheWarningsSyntax ::= SEQUENCE SIZE (1..MAX) of
     SingleCacheWarning

     SingleCacheWarning ::= SEQUENCE {
       warning      CacheWarningValue,
       text         UTF8String    OPTIONAL,
       warningData  OCTET STRING  OPTIONAL
     }

     CacheWarningValue ::= INTEGER {
         stale                   (0),
         revalidationFailed      (1),
         disconnectedOperation   (2)
     }

     id-ocsp-cacheWarnings OBJECT IDENTIFIER ::= TBA

   Each warning is assigned a number and MAY include an explanatory text
   and/or some additional data.  Responses MAY include more than one
   warning.  Some warnings MUST be preserved by OCSP servers.  That is,
   when an OCSP server receives a response that contains such a warning,
   it MUST pass that warning along when it relays the response, whether
   directly or from its cache, to a client.  Warnings that must be
   preserved are identified in their definitions below.

   The following warnings are defined.  Other warnings may be defined in
   other documents.




Branchaud                                                      [Page 15]


INTERNET DRAFT                OCSP Caching                    April 1998



   stale (0): OCSP servers MUST include this warning whenever they
      return a response using stale cached data.  A server MAY add this
      warning to any response, but MUST NOT remove it until the response
      is known to be fresh.  Servers MUST preserve this warning.

   revalidationFailed (1): OCSP servers MUST include this warning if
      they return a stale response because attempts to revalidate
      failed.  A server MAY add this warning to any response, but MUST
      NOT remove it until the response is successfully revalidated.
      Servers MUST preserve this warning.

   disconnectedOperation (2): OCSP servers SHOULD include this warning
      in all responses if the server is aware that it is not connected
      to the rest of the network.  A server MAY conclude it is not
      connected after a number of network operations fail, or it MAY be
      told it is not connected by an administrator.  Servers MUST
      preserve this warning.  An OCSP server MUST include this warning
      when it can not reply to a noCache query with authoritative data
      (either from its own store or from another OCSP server).  See the
      description of the noCache parameter in Section 8.5

8.4  The Cache Status Information Extension

   This extension contains information about the age of the status data
   in the response.  It consists of two fields:

   age: This is the age, in seconds, of the response when it was sent by
      an OCSP server.  All OCSP servers MUST include a value for age in
      all their responses.  When a co-located OCSP server responds to a
      request about a certificate for which it is authoritative, it MUST
      include an age value of 0 in the response.  See Section 7.2.1 for
      details on how the age value is otherwise calculated.

   producedAt: This is the local time when the authoritative CA
      generated the response.  Only OCSP servers that are co-located
      with a CA MAY include this value in a response.  An OCSP server
      MUST NOT create this value in a response for a certificate for
      which it is not authoritative.  An OCSP server that receives and
      caches a response containing a producedAt value MUST NOT modify or
      remove it when the response is used to reply to queries.

   This extension SHALL NOT be marked critical.

     cacheStatusInfo EXTENSION ::= {
         SYNTAX CacheStatusInfoSyntax
         IDENTIFIED BY id-ocsp-cacheStatusInfo
     }



Branchaud                                                      [Page 16]


INTERNET DRAFT                OCSP Caching                    April 1998



     CacheStatusInfoSyntax ::= SEQUENCE {
          age                 INTEGER,
          producedAt          GeneralTime    OPTIONAL
     }

     id-ocsp-cacheStatusInfo OBJECT IDENTIFIER ::= TBA

8.5  The Request Cache Parameters Extension

   The request cache parameters extension allows the client to specify
   required cache characteristics for the response.  Those
   characteristics are defined by the following fields:

   noCache: The client requests that the response be retrieved from the
      CA, i.e.  that any intermediary OCSP servers ignore their caches
      when replying to this request.  A server that receives a request
      with the noCache parameter MUST NOT reply with cached data.  The
      server MUST either reply with authoritative information, or it
      MUST forward the request, including the noCache parameter, to
      another OCSP server.  If a server is unable to do either, then it
      MUST reply with a status value of unknown accompanied by a
      "disconnected operation" warning.

   maxAge: The client requests that the response can come from a cache
      provided it is no older than maxAge seconds.  See Section 7.2 for
      a description of cache entry age calculations.  If a server
      receives a request that specifies a maxAge of 0 then it MUST
      attempt to validate its entry (see Section 7.4), or retrieve a
      fresh response from another OCSP server or, if appropriate, from
      its authoritative store.  Only if those attempts are unsuccessful
      MAY a server return a cached response older than the specified
      maxAge, and in doing so the server MUST include a staleness
      warning with the response (see Section 8.3).

   minFresh: The server MAY return a cached response as long as that
      response it at least minFresh seconds away from becoming stale.
      See Section 7.2 for a definition of stale.

   maxStale: The server MAY return a cached response as long as no more
      than maxStale seconds have elapsed since the response became
      stale. See Section 7.2for a definition of stale.

   noValidate: The client will accept a stale response from the server.
      That is, the server MAY return a stale cache entry without first
      validating it.  Note that any stale response MUST always include
      an appropriate warning (see Section 8.3).

   The maxAge parameter MAY be combined with either the minFresh or the


Branchaud                                                      [Page 17]


INTERNET DRAFT                OCSP Caching                    April 1998



   maxStale parameters.  When a server receives a request containing
   either combination, it MUST reply with a cached entry only if that
   entry satisfies both parameters, or all attempts to retrieve a
   satisfactory response from other servers are unsuccessful (in which
   case the server MUST include a warning in the response).

   The noCache parameter MUST NOT be combined with any other parameter,
   while the noValidate flag MAY accompany any other parameter (except
   noCache).

   This extension SHALL NOT be marked critical.

     requestCacheParameters EXTENSION ::= {
         SYNTAX RequestCacheParametersSyntax
         IDENTIFIED BY id-ocsp-requestCacheParameters
     }

     RequestCacheParametersSyntax ::= SEQUENCE {
       noCache     BOOLEAN  OPTIONAL,
       maxAge      INTEGER  OPTIONAL,
       minFresh    INTEGER  OPTIONAL,
       maxStale    INTEGER  OPTIONAL,
       noValidate  BOOLEAN  OPTIONAL
     }

     id-ocsp-requestCacheParameters OBJECT IDENTIFIER ::= TBA

8.6  The Response Cache Parameters Extension

   This extension allows a CA to specify required caching
   characteristics for the response.  That is, the CA MAY specify how
   the client's cache (if any) should handle the response.

   A server that receives a response containing this extension MUST NOT
   remove or alter the extension when sending replies based on that
   response.  That is, the server MUST preserve this extension in the
   same way that some warnings must be preserved (see Section 8.3).

   Response cache parameters are defined by the following fields:

   noCache: The receiver MUST NOT cache the response at all.

   maxAge: The receiver MAY cache the response but MUST consider it
      stale once the cached entry's current age exceeds maxAge.
      Responses with a maxAge of 0 MUST be revalidated every time they
      are used.  See Section 7.2.2 for a description of how this field
      is used in cache entry freshness calculations.



Branchaud                                                      [Page 18]


INTERNET DRAFT                OCSP Caching                    April 1998



   Implementations MUST NOT generate responses that include both noCache
   and maxAge.  The ASN.1 code for this extension precludes this.

   This extension SHALL NOT be marked critical.

     responseCacheParameters EXTENSION ::= {
         SYNTAX ResponseCacheParametersSyntax
         IDENTIFIED BY id-ocsp-responseCacheParameters
     }

     ResponseCacheParametersSyntax ::= CHOICE {
       noCache   [0]  BOOLEAN,
       maxAge    [1]  INTEGER
     }

     id-ocsp-responseCachParameters OBJECT IDENTIFIER ::= TBA


































Branchaud                                                      [Page 19]


INTERNET DRAFT                OCSP Caching                    April 1998



9.  HTTP and OCSP Caching

   [
     Author's Note -- The issues surrounding an HTTP proxy caching OCSP
     responses are largely unresolved.  Here's a quick list of some
     problems:

     1. HTTP proxies can't sign responses.  Therefore, they can't
        provide a signed record of how old a response is.  That may be
        acceptable in some circumstances (e.g. when non-repudiation of
        responses isn't required), but if so the response should still
        be transmitted over a TLS (or SSL) authenticated channel.  That
        is, the client should authenticate the proxy before accepting a
        cached response from it.  The problem here is that HTTP proxies
        are normally transparent to HTTPS requests.

     2. Can an OCSP client really tell an HTTP proxy to refresh its
        cache on demand (if, say, the client won't accept an entry older
        than x, but the age of the HTTP proxy's entry is > x)?

     3. There are many broken HTTP caching implementations.  Blindly
        relying upon them to perform OCSP caching properly can lead to
        problems.

     Since these and other issues still need to be resolved, this
     section currently reflects only the author's views of HTTP caching.
     The fact that what's here may seem somewhat muddled only reflects
     the need for resolution.
   ]

   Most of OCSP's caching mechanism is borrowed from HTTP 1.1.  Readers
   familiar with [HTTP] will have recognized the similarities.  The main
   differences are:

    o OCSP's caching is transport independent (OCSP can be implemented
      over protocols other than HTTP);

    o OCSP cache parameters can be signed to allow for a non-repudiable
      record of request and response parameters;

    o OCSP responses are always origin-authenticated, either via signed
      responses or SSL/TLS.

   This section describes the relationship between OCSP caching
   parameters and HTTP Cache-control directives.

   When OCSP is transported over HTTP 1.1 or higher, the caching
   parameters of the OCSP messages SHALL take precedence over any Cache-


Branchaud                                                      [Page 20]


INTERNET DRAFT                OCSP Caching                    April 1998



   control directives in the HTTP messages.  Where an implementation
   wishes to use HTTP Cache-control directives when transmitting OCSP
   messages, it SHOULD ensure that corresponding HTTP directives and
   OCSP cache parameters, as defined below, have the same values
   (although see below).  HTTP cache-control parameters MUST NOT be used
   as a replacement for OCSP caching parameters.  The following table
   shows the equivalences between OCSP caching parameters and HTTP 1.1
   Cache-control directives.

   OCSP Caching Parameter    HTTP 1.1 Cache-control Directive or Header
   ----------------------    ------------------------------------------
   noCache                   no-cache directive
   maxAge                    max-age directive
   minFresh                  min-fresh directive
   maxStale                  max-stale directive
   noValidate                only-if-cached directive
   producedAt                Date header
   age                       Age header

   The above correlations are not an invitation to blindly use a plain
   HTTP caching proxy as an OCSP cache.  HTTP proxy caching is uneven
   territory.  Many HTTP caches do not function properly, and many also
   do not support the HTTP 1.1 directives.  What is particularly
   troubling is that transporting OCSP requests over HTTP can lead to
   the client receiving invalid OCSP responses if there is an
   intermediate HTTP proxy.  Consider the situation in Figure 2.


          +--------+    +------------+    +----+
          | Client |----| HTTP Proxy |----| CA |
          +--------+    +------------+    +----+

            Figure 2 -- An HTTP Proxy in OCSP


   If the client uses HTTP to contact the CA, responses from the CA
   might be transparently cached by the proxy.  If a previous response
   from the CA had an age value of, say, 10 seconds, a client making a
   second query (for the same certificate) through the HTTP Proxy might
   receive the cached 10-second-old response, which may by then be
   wrong.  The client has no way of knowing if the response came from
   the CA or from the cache.  The client's only recourse would be to
   make sure it never received a cached entry (by, say, using the nonce
   extension).

   Because of these issues, this profile recommends that HTTP caching
   SHOULD NOT be used for OCSP.  When an OCSP message is sent via HTTP,
   the HTTP no-cache directive SHOULD be used.  Although a properly-


Branchaud                                                      [Page 21]


INTERNET DRAFT                OCSP Caching                    April 1998



   functioning HTTP 1.1 proxy MAY be employed as an OCSP cache,
   implementations MUST NOT assume that an HTTP proxy they're dealing
   with is functioning properly.  Also, note that simply because a
   directly-connected HTTP cache is functionally correct does not mean
   that any other caches it contacts will be, and the OCSP client has no
   way of determining the compliance of any HTTP cache.  Note, too, that
   some caches even ignore the no-cache directive.

   At a minimum, if use of an HTTP proxy is unavoidable (say, to
   transport OCSP across a firewall) then that proxy MUST at least
   recognize and obey the no-cache directive.  However, since an
   implementation has no way of determining if this is true, it is up to
   installation administrators to ensure that their HTTP proxies are
   compliant.

   Still, in general, it is better to avoid HTTP caching for OCSP.


































Branchaud                                                      [Page 22]


INTERNET DRAFT                OCSP Caching                    April 1998



10.  Security Considerations

   Many attacks, such as spoofing, are attenuated by the authentication
   inherent in the basic OCSP protocol.  The main threat that basic OCSP
   does not address is a denial of service attack.  Note that service
   may be denied not only because of a malicious attacker but also
   because of more benign sources, such as heavy network traffic.

   OCSP clients may require servers to contact other servers (or CAs) to
   respond to a request.  In the event that such contact is impossible,
   the server MAY reply with cached information even though the client
   would consider such a response to be stale.  When the server responds
   with data it knows would not be acceptable to a client, the server
   MUST include one or more of the warnings described in Section 8.3.

   Such warnings allow the client to be made aware of the situation, and
   to take appropriate steps (which will depend on the client's local
   policies).  For example, a client that receives a
   disconnectedOperation warning in a response MAY notify its user of
   the age of the response and ask for the user's permission to proceed.

   Other security considerations arise when a non-OCSP entity, such as
   an HTTP proxy, is used to cache OCSP responses.  This sitution SHOULD
   be avoided.  For more, see Section 9.


























Branchaud                                                      [Page 23]


INTERNET DRAFT                OCSP Caching                    April 1998



11.  Patent Considerations

   [ Humour impaired: Please plant tongue firmly in cheek before
   proceeding. ]

   As of April 1998, the author is unaware of any patents in any
   jurisdiction that might cover any aspect of the OCSP caching protocol
   described in this document.  It is possible that the publication of
   this document under the auspices of the IETF will prevent this
   protocol from being patented in the future.

   However the author is neither omniscient nor prescient, and so
   implementors SHOULD take steps to ensure that they are not infringing
   on any patents filed in their respective jurisdictions.

   Aspects external to this document, such as the basic OCSP protocol,
   any application of certificates, the use of a computers or a network
   thereof to do anything, or anything else you might think is a good
   idea, may already or probably someday will be subject to a patent.
   Implementors MAY take this as a sign of impending apocalypse.

12.  References

      [OCSP] M. Myers, A. Malpani, R. Ankney, C. Adams and S. Galperin,
             "Online Certificate Status Protocol - OCSP" (draft).

   [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

      [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
             2068, January 1997.

13.  Author's Address

   Marc Branchaud
   Xcert Software Inc.
   Suite 1001
   701 W. Georgia Street
   Vancouver, BC, Canada
   V7Y 1C6

   Phone: +1 604-640-6227
   Fax:   +1 604-640-6220
   Email: marcnarc@xcert.com





Branchaud                                                      [Page 24]


INTERNET DRAFT                OCSP Caching                    April 1998



14.  Appendix - Collected ASN.1

   --
   -- New OCSPResponseStatus definition
   --

   OCSPResponseStatus ::= ENUMERATED {
       successful         (0),   -- Response has valid confirmations
       malformedRequest   (1),   -- Illegal confirmation request
       internalError      (2),   -- Internal error in issuer
       tryLater           (3),   -- Try again later
       notFound           (4),   -- Certificate not on record
       certRequired       (5),   -- Must supply certificate
       unchanged          (6)    -- Status has not changed
   }

   --
   -- Presumed Status extension
   --

   presumedStatus EXTENSION ::= {
       SYNTAX PresumedStatusSyntax
       IDENTIFIED BY id-ocsp-presumedStatus
   }

   PresumedStatusSyntax ::= OCSPResponseStatus

   --
   -- Cache Warnings extension
   --

   cacheWarnings EXTENSION ::= {
       SYNTAX CacheWarningsSyntax
       IDENTIFIED BY id-ocsp-cacheWarnings
   }

   CacheWarningsSyntax ::= SEQUENCE SIZE (1..MAX) of SingleCacheWarning

   SingleCacheWarning ::= SEQUENCE {
     warning      CacheWarningValue,
     text         UTF8String    OPTIONAL,
     warningData  OCTET STRING  OPTIONAL
   }

   CacheWarningValue ::= INTEGER {
       stale                   (0),
       revalidationFailed      (1),
       disconnectedOperation   (2)


Branchaud                                                      [Page 25]


INTERNET DRAFT                OCSP Caching                    April 1998



   }

   --
   -- Cache Status Info extension
   --

   cacheStatusInfo EXTENSION ::= {
       SYNTAX CacheStatusInfoSyntax
       IDENTIFIED BY id-ocsp-cacheStatusInfo
   }

   CacheStatusInfoSyntax ::= SEQUENCE {
        age                 INTEGER,
        producedAt          GeneralTime    OPTIONAL
   }

   --
   -- Request Cache Parameters extension
   --

   requestCacheParameters EXTENSION ::= {
       SYNTAX RequestCacheParametersSyntax
       IDENTIFIED BY id-ocsp-requestCacheParameters
   }

   RequestCacheParametersSyntax ::= SEQUENCE {
     noCache     BOOLEAN  OPTIONAL,
     maxAge      INTEGER  OPTIONAL,
     minFresh    INTEGER  OPTIONAL,
     maxStale    INTEGER  OPTIONAL,
     noValidate  BOOLEAN  OPTIONAL
   }

   --
   -- Response Cache Parameters extension
   --

   responseCacheParameters EXTENSION ::= {
       SYNTAX ResponseCacheParametersSyntax
       IDENTIFIED BY id-ocsp-responseCacheParameters
   }

   ResponseCacheParametersSyntax ::= CHOICE {
     noCache   [0]  BOOLEAN,
     maxAge    [1]  INTEGER
   }

   --


Branchaud                                                      [Page 26]


INTERNET DRAFT                OCSP Caching                    April 1998



   -- Collected OIDs
   --

   id-ocsp-presumedStatus OBJECT IDENTIFIER ::= TBA
   id-ocsp-cacheWarnings OBJECT IDENTIFIER ::= TBA
   id-ocsp-cacheStatusInfo OBJECT IDENTIFIER ::= TBA
   id-ocsp-requestCacheParameters OBJECT IDENTIFIER ::= TBA
   id-ocsp-responseCachParameters OBJECT IDENTIFIER ::= TBA










































Branchaud                                                      [Page 27]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/