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]
