idnits 2.17.1 draft-ietf-pkix-ocsp-caching-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-23) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([RFC2119], [OCSP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 1998) is 9505 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 1038 -- Looks like a reference, but probably isn't: '1' on line 1039 -- Possible downref: Non-RFC (?) normative reference: ref. 'OCSP' ** Obsolete normative reference: RFC 2068 (ref. 'HTTP') (Obsoleted by RFC 2616) Summary: 12 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group M. Branchaud 3 INTERNET-DRAFT Xcert 4 Expires in six months April 1998 6 Internet Public Key Infrastructure 7 Caching the Online Certificate Status Protocol 8 draft-ietf-pkix-ocsp-caching-00.txt 10 1. Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of 6 months 18 and may be updated, replaced, or rendered obsolete by other documents 19 at any time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 To view the entire list of current Internet-Drafts, please check the 23 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 24 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 25 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 26 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 28 Distribution of this document is unlimited. 30 This Internet Draft expires in October 1998. 32 2. Abstract 34 The Online Certificate Status Protocol [OCSP] specifies how a client 35 process may obtain certificate status information online from a 36 server. In order for OCSP to scale beyond small communities of 37 users, a method to cache certificate status information at 38 intermediary servers is required. 40 This document describes the requirements of and assumptions behind 41 OCSP caching, and defines the mechanisms through which such caching 42 can be accomplished. 44 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 45 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 46 document (in uppercase, as shown) are to be interpreted as described 47 in [RFC2119]. 49 3. Change Log 51 This is the first draft of this document. 53 4. Contents 55 1. Status of this Memo ............................................ 1 56 2. Abstract ....................................................... 1 57 3. Change Log ..................................................... 2 58 4. Contents ....................................................... 3 59 5. Introduction ................................................... 4 60 6. Cached OCSP Overview ........................................... 5 61 6.1 OCSP Entities .............................................. 5 62 6.2 OCSP Example ............................................... 6 63 7. OCSP Caching ................................................... 9 64 7.1 Correctness of Cache Entries ............................... 9 65 7.2 Age Calculations .......................................... 10 66 7.3 Server Cache Management ................................... 12 67 7.4 OCSP Cache Entry Validation ............................... 12 68 8. Caching Enhancements to OCSP .................................. 14 69 8.1 The unchanged Certificate Status Value .................... 14 70 8.2 The Presumed Status Extension ............................. 14 71 8.3 The Cache Warnings Extension .............................. 15 72 8.4 The Cache Status Information Extension .................... 16 73 8.5 The Request Cache Parameters Extension .................... 17 74 8.6 The Response Cache Parameters Extension ................... 18 75 9. HTTP and OCSP Caching ......................................... 20 76 10. Security Considerations ....................................... 23 77 11. Patent Considerations ......................................... 24 78 12. References .................................................... 24 79 13. Author's Address .............................................. 24 80 14. Appendix - Collected ASN.1 .................................... 25 82 5. Introduction 84 OCSP can allow a certificate processing entity to obtain certificate 85 status information directly from a Certification Authority (CA). 86 However, on the global Internet, it is impractical for any entity to 87 directly contact the CAs of each certificate it encounters. For one 88 thing, such behavior would require that the entity securely obtain a 89 copy of every CA's OCSP responder key. For another, CAs would 90 quickly find themselves overwhelmed by the volume of OCSP requests. 92 One solution to these impracticalities is to employ OCSP servers as 93 intermediaries between the entities and the CAs, and to allow those 94 servers to cache certificate status information. While this allows 95 CAs to distribute their OCSP loads, caching introduces an extra layer 96 of complexity that must be addressed. 98 In particular, cached data can not be transparently passed to a 99 querying entity. Because of the way certificates are used, it is 100 important for an entity to know how long a status value has been 101 cached. The entity may be much more willing to accept a particular 102 status response if it was created two seconds ago than if it is two 103 weeks old. 105 The nature of certificate-using systems also requires that they be 106 able to override OCSP caches as needed. An entity's policies for 107 most of its applications may allow it to accept status information 108 that has been cached for, say, less than a day. However, those 109 policies may also dictate that for a particular application it must 110 obtain status that has been cached for no more than 1 hour. 112 The OCSP caching mechanisms described in this document are designed 113 to permit this kind of flexibility. The following section presents 114 an overview and example of cached OCSP, to illustrate the basic 115 operations expected of OCSP participants. The details of OCSP 116 caching are described in Section 7. Definitions of the OCSP 117 extensions required for caching are presented in Section 8. OCSP's 118 caching closely resembles that defined in HTTP 1.1, and a discussion 119 of the relationship between the two systems is in Section 9. 121 6. Cached OCSP Overview 123 This section describes the requirements and assumptions behind cached 124 OCSP by presenting an overview of the protocol. We first define the 125 entities that participate in cached OCSP, then provide an example of 126 the protocol's operation. 128 6.1 OCSP Entities 130 Three types of entities participate in the cached OCSP protocol: 132 o Clients - entities which request a certificate's status; 134 o Servers - entities which cache status information and respond to 135 clients' requests; 137 o CAs - the entities with authoritative information about the status 138 of some certificates. 140 6.1.1 OCSP Clients 142 OCSP clients request certificate status information from OCSP 143 servers. An OCSP client MAY be another OCSP server or CA, or it MAY 144 be an "end" entity: one that originates a status request. Any client 145 MAY cache a response. Indeed, OCSP servers usually cache the 146 responses they receive, but OCSP's caching mechanisms are flexible 147 enough to allow end entities to also cache responses and use them, 148 for example, in offline operations. 150 In general, clients that are not themselves OCSP servers SHOULD use 151 only a few, usually one, OCSP server. This is because such clients 152 need to have complete trust in their OCSP server's public key, to the 153 same extent that they would trust a root CA's key. In particular, 154 clients MUST obtain a server's key in a trusted fashion as it would 155 the key of a trusted root CA. When a client obtains a server's key 156 in this way, the client is said to "trust" the server. Clients MAY 157 accept in-band revocation notification of a server's key, however 158 they MUST NOT accept an in-band replacement for a revoked server key. 159 When a client is made aware of the revocation of a server's key, 160 whether through in-band or out-of-band notification, it MUST NOT use 161 that server for OCSP processing until it obtains a new key for the 162 server via an out-of-band channel. 164 6.1.2 OCSP Servers 166 OCSP servers reply to OCSP requests. In creating a response, a 167 server MAY used cached information if it is appropriate, or it MAY 168 forward the requests to other OCSP servers. 170 When an OCSP server receives a query, it first checks its local store 171 of certificate information to see if it can fulfill the request with 172 cached data. This local store is mostly made up of cached 173 information but can also include authoritative information from a co- 174 located CA (see below). If the OCSP server can fulfill the request 175 from its local store, it does so. Otherwise, the server MAY make one 176 or more queries to other OCSP servers that it trusts. If it receives 177 a definitive response from those queries (as opposed to a "status 178 unknown" or error response), it SHOULD store that information in its 179 local cache before returning the response to the client. Note that 180 the client need not have any knowledge of the keys of the other OCSP 181 servers. 183 6.1.3 OCSP CAs 185 All OCSP CAs are also OCSP servers and act in an identical fashion 186 except that there is no need for an OCSP CA to "cache" the status of 187 its own certificates. Any CA that supports cached OCSP MUST operate 188 an OCSP server, and that server is said to be "co-located" with that 189 CA. A single OCSP server MAY be co-located with more than one CA. 190 When a caching OCSP server is co-located with a CA, it does not cache 191 certificate status information for that CA's certificates. It 192 instead has access to the CA's own authoritative information about 193 those certificates. That is, the co-located OCSP server is the 194 source of its CA's OCSP information. It is most likely that the co- 195 located OCSP server has direct, local access to, or is even 196 integrated with, the CA's directory service. 198 Authoritative certificate information consists simply of the 199 certificate and its status. How these two pieces of information are 200 associated is beyond the scope of this document. The certificate's 201 directory entry MAY have a status attribute, or the certificate's 202 status MAY be defined by how the certificate is stored in the 203 directory, or status MAY be determined by some other means. 204 Regardless, a co-located OCSP server MUST have direct and immediate 205 access to a CA's internal certificate status information. The co- 206 located OCSP server MUST NOT receive that information via a CRL or 207 some other periodic means. Note that a server that is not co-located 208 with a CA MAY receive status information from that CA periodically. 210 This document uses the term "CA" interchangeably with "co-located 211 OCSP server." 213 6.2 OCSP Example 215 The best way to understand OCSP caching is to study an example of it 216 in operation. This section presents such an example that depicts the 217 typical behavior expected of the various OCSP entities. This example 218 glosses over the finer points of OCSP caching in order to focus on 219 the basic principles of the protocol. 221 +----+ +----+ +-->e 222 e2<--| S2 |<----| S3 |--+---->e 223 +----+ +----+ 224 ^ 225 | 226 | 227 +-----+ +----+ +-----+ +-->e 228 e<--| CA1 |<----| S1 |<--->| CA2 |--+----->e 229 +-----+ +----+ +-----+ +--->e 230 | | | 231 e<--+-->e +-->e1 +-->e 232 e<--+---->e 234 Figure 1 -- OCSP Entity Relationships 236 Figure 1 depicts the typical relationships among the OCSP entities 237 (end entity clients are represented by a lowercase e, servers by an S 238 and CAs by the letters CA). The arrows indicate the distribution of 239 OCSP public key values: The entity at the source of an arrow has 240 distributed its public key to the entity at the head of an arrow. 241 These OCSP keys are distributed securely, as described above. 243 OCSP queries flow oppositely to the directions depicted by the 244 arrows. Let's say that e1, an end entity client of S1, wishes to 245 determine the status of a certificate, C1, issued by CA1. Assuming 246 that no entity has cached any information yet, e1 would send a status 247 query to S1. Since S1 has obtained CA1's public key, it "recognizes" 248 the issuer of certificate C1 and sends its own query to that issuer: 249 CA1. 251 CA1 returns a response containing the certificate's status. S1 can 252 verify the authenticity of the response because it knows CA1's public 253 OCSP key. S1 can now cache and return the response to e1, and e1 can 254 authenticate S1's response because it knows S1's public key. In this 255 way, e1 can obtain C1's status without having direct knowledge of 256 CA1's public OCSP key. If e1 makes another query for the status of 257 C1, S1 can return its cached value if it's acceptable to e1. 259 Let's add an extra level of indirection and consider how e2, a client 260 of S2, would obtain the status of the a certificate, C2, issued by 261 CA2. When e2 sends its query to S2, the server does not recognize 262 C2's issuer because the server has not securely obtained CA2's public 263 OCSP key. However, the server can be configured to query a number of 264 default servers when it encounters a certificate that it doesn't 265 recognize. Here, S2 would send a query to S3, and now the process 266 would proceed in the same manner as before, with both S3 and S2 267 caching the response. In fact, S3 would act no differently than it 268 would if the query came from any other kind of client. 270 Note that the clients of CA1 can not obtain the status of any 271 certificates issued by CA2 since CA1 does not have a copy of any of 272 the servers' public keys, and so it can not make any external OCSP 273 queries. However, clients of CA2 can obtain the status of CA1's 274 certificates, since CA2 has exchanged public keys with S1 (notice the 275 two-way arrow between S1 and CA2). 277 As we conclude this section, notice that the OCSP relationships 278 between entities represent the trust relationships for the PKI. That 279 is, OCSP relationships are similar to those established under cross- 280 certification. If one entity trusts another to provide status 281 information, then it can become an OCSP client to that entity by 282 obtaining its public key. Thus, trust relationships are expressed 283 through an explicit decision to trust an entity for status 284 information. Also, an entity can require its consent before it is 285 trusted, by simply refusing to answer any queries from entities that 286 it doesn't recognize. 288 This discussion glossed over the finer points of OCSP caching. The 289 next section deals with caching, but first note that OCSP caching 290 does not change the mapping between OCSP relationships and trust 291 relationships, nor does it affect the basic OCSP procedures described 292 above. Instead, the caching allows the end-to-end requirement for 293 OCSP messages - that a query must reach the authoritative CA - to be 294 relaxed when appropriate. 296 7. OCSP Caching 298 OCSP uses caching to improve performance across the network. Caching 299 certificate status information leads to the possibility of a cached 300 status value becoming invalid but still being accepted as accurate. 301 In an extreme sense, the same could be said of any copy of 302 certificate status held outside the CA (such as a CRL). The value 303 being copied could even become invalid in transit, and so the copy 304 could be invalid before it even exists. Physical limitations, 305 prevent absolutely accurate status information from being instantly 306 available to all concerned parties. Even if such propagation were 307 possible, network bandwidth is a scarce resource that should be used 308 sparingly. OCSP's caching is designed with these constraints in mind 309 to provide the most practical, online propagation of certificate 310 status information. In particular, OCSP caching was designed to meet 311 the following criteria: 313 o A relying party MUST always be able to override any intermediary 314 caches between it and the CA, so that it MAY (at its discretion) 315 obtain the most up-to-date status information possible. OCSP 316 clients can formulate their requests with a number of cache 317 parameters that allow them to finely tune requests to suit their 318 needs. 320 o A relying party MUST always be given enough information to 321 determine if a given certificate status value is acceptable for 322 its purpose. To this end, OCSP clients are provided with the 323 amount of time that has elapsed since the status value was 324 generated by the CA. This elapsed time is called the age of the 325 status value. 327 o A CA MUST always be able to specify how the status for a 328 particular certificate should be cached. OCSP CAs MAY include 329 recommended caching parameters in their replies that other OCSP 330 entities SHOULD observe. Note that entities may be forced to 331 ignore a CA's caching requirements (for example, if the entity 332 can't establish a connection to the CA), but do so at their own 333 peril. 335 With these criteria in mind, we now describe OCSP caching. First, we 336 define how a server determines if it can respond to a query with a 337 cached value. 339 7.1 Correctness of Cache Entries 341 An OCSP cache entry is said to be correct when an OCSP server can use 342 the entry to reply to a request. An OCSP cache entry is correct if 343 it meets either of the following criteria: 345 1. It is "fresh enough" (see Section 7.2.2). By default, this means 346 that it meets the caching requirements of the client, the server 347 and the CA.; 349 2. It includes a warning if the cache requirements of the client or 350 the CA are not met. 352 If an OCSP server receives a response that it would normally forward 353 to a client, and that response is no longer fresh, the server should 354 forward the response to the client without attaching any warnings. 355 An OCSP server SHOULD NOT attempt to revalidate a response that 356 became stale in transit, as this might lead to an infinite loop. 358 Whenever an OCSP server returns a response that is not "fresh enough" 359 it MUST attach an appropriate warning to the response (see Section 360 8.3). 362 7.2 Age Calculations 364 In order to know if a cache entry is fresh, its current age MUST be 365 compared to its freshness lifetime (the age at which it becomes 366 stale). This section describes how to calculate those two values, 367 and how to determine if an entry is fresh. 369 7.2.1 Current Age 371 OCSP entities calculate the current age of a response using the 372 following values: 374 now: The current local time of the entity performing the age 375 calculation. 377 producedAt: This value is the time at which the response was 378 generated by the CA. CAs MAY include this value in their 379 responses. When a response is generated from a CRL, the value of 380 producedAt SHOULD be the value of the thisUpdate field of the CRL. 382 requested_time: This is the receiving entity's local time when it 383 sent the request that triggered this response. 385 received_time: This is the receiving entity's local time when it 386 received the response. 388 age_value: This is the value of the age field in the response. This 389 is the current age of the response as calculated by the entity 390 sending the response at the time of transmission. All entities 391 MUST include an age value in any response. OCSP ages are 392 expressed in seconds. 394 The calculation is outlined below. 396 apparent_age = max (0, received_time - producedAt) 397 received_age = max (apparent_age, age_value) 398 entry_creation_age = received_age + (received_time - requested_time) 399 entry_local_age = now - received_time 400 current_age = entry_creation_age + entry_local_age 402 If the response does not include a producedAt value, then the 403 received_age SHOULD be set to age_value and the first two steps above 404 SHOULD be skipped. 406 Essentially, this calculation provides a conservative estimate of the 407 sum of the number of seconds the response has been resident in each 408 of the caches between the calculating entity and the CA, plus the 409 number of seconds the response has spent in transit. 411 When an OCSP server sends a response to any entity, it MUST calculate 412 its current_age and include it as the value of the age field in the 413 response. CAs SHOULD provide an age value of 0 in their responses. 414 This helps inquirers to determine if the response comes directly from 415 an authoritative source. 417 Finally, note that if there is a significant difference between the 418 clocks of the calculating entity and the CA, this calculation may 419 lead to inordinately old age values. For this reason, entities MAY 420 ignore the producedAt value in a response and proceed as if it were 421 not present. 423 7.2.2 Freshness Calculation 425 The freshness lifetime of a cache entry is defined by the maxAge 426 value specified by the CA in its authoritative response to a request. 427 If this value is not present in the response, the calculating entity 428 MAY use a locally-defined heuristic to determine the entry's 429 freshness lifetime. For example, an entity might be configured with 430 a 24 hour freshness lifetime for (entries for) email certificates, 431 while it may only have a 5 second freshness lifetime for any 432 aircraft-carrier-purchasing certificates. 434 Once a freshness lifetime is obtained, the freshness of an entry is 435 calculated by simply comparing its freshness lifetime to its 436 current_age: 438 entry_is_fresh = (freshness_lifetime > current_age) 440 7.2.3 Disambiguating Multiple Responses 442 A client MAY send out more than one request message to determine the 443 status of a single certificate (e.g. a query MAY be sent to several 444 OCSP servers). Thus, an entity may receive responses from multiple 445 paths. To disambiguate these responses, the client SHOULD use the 446 one with the lowest age value. 448 7.3 Server Cache Management 450 Servers are at liberty to manage their caches in any way they see 451 fit. This section merely presents some recommendations that they MAY 452 wish to adopt. 454 When a server recovers from a crash or is restarted after being down 455 for some reason, it SHOULD erase its cache. This provides the most 456 secure and easiest to implement startup environment. If a server 457 elects to keep its cache data between downtimes, it MUST at least 458 ensure that the current ages of all the entries are appropriately 459 adjusted for the missing time. 461 Servers MAY elect to refresh their caches periodically. A server may 462 "pull" status information for multiple certificates by including all 463 the certificates in a single "batch" query submitted to the CA. The 464 point here is that a server need not wait for a query to trigger a 465 refresh of a cached value. 467 7.4 OCSP Cache Entry Validation 469 When an OCSP query includes a status value for the identified 470 certificate (see Section 8.2), the query is called a "validation". 471 Only CAs MAY reply to validations, and they MUST only reply to 472 validations of certificates for which they are authoritative (a CA, 473 and other servers, MAY still relay the validation to another CA or 474 server, and return their response). OCSP servers MUST NOT use cached 475 data to reply to a validation. A CA MAY reply to a validation with a 476 normal response, or it MAY follow the procedure described in this 477 section. 479 The purpose of a validation is to provide entities with a fast and 480 efficient method to determine if a certificate's status has changed 481 since it was last obtained. This is often done to see if a stale 482 entry is still accurate (if so, the entry MAY be refreshed). The 483 client includes its current notion of the certificate's status in the 484 query. Servers relay the query to the certificate's CA. When the CA 485 receives this message, it compares the presented status with the 486 certificate's actual current status. 488 If the statuses match, then the CA MAY return a response consisting 489 of the certID and a responseStatus field with the value "unchanged" 490 (see Section 8.1). The CA MAY include any optional fields or 491 extensions in the response. 493 If the statuses do not match (i.e. the status and / or time values 494 are different), then the CA MUST respond to the query as if it were a 495 normal query. The CA MUST ignore the presumedStatus value presented 496 in the validation query (see Section 8.2). 498 An entity that receives a responseStatus value of "unchanged" in 499 response to a validation may recalculate the current age of its cache 500 entry for the response's certificate. It MUST do so by setting 501 received_age equal to the response's age value in the response and 502 skipping the first two steps of the calculation described in Section 503 7.2.1. If a server is configured to perform this recalculation, and 504 it is going to forward the response of the validation to a client, 505 then it MUST perform the recalculation before relaying the response. 506 That is, the age value of the relayed response MUST be set to the 507 newly calculated current_age. 509 8. Caching Enhancements to OCSP 511 This sections presents detailed definitions of the additions and 512 extensions OCSP requires for caching, and further specifies the 513 behavior of the OCSP entities. Most of these enhancements are 514 defined as extensions to the basic OCSP protocol. These extensions 515 are not optional for cached OCSP, and implementations MUST support 516 them as required below. 518 8.1 The unchanged Certificate Status Value 520 A new certificate status is defined for cached OCSP: unchanged. 522 OCSPResponseStatus ::= ENUMERATED { 523 successful (0), -- Response has valid confirmations 524 malformedRequest (1), -- Illegal confirmation request 525 internalError (2), -- Internal error in issuer 526 tryLater (3), -- Try again later 527 notFound (4), -- Certificate not on record 528 certRequired (5), -- Must supply certificate 529 unchanged (6) -- Status has not changed 530 } 532 The unchanged state is used in response to an OCSP cache entry 533 validation (see Section 7.4). A CA MUST NOT use this state in 534 response to a normal query. When responding to a validation, a CA 535 MAY use this state if the current state of the certificate being 536 validated matches the presumed state sent in the validation. 538 8.2 The Presumed Status Extension 540 This extension is used to create validation queries. That is, a 541 query that includes this extension MAY be treated as a validation 542 query. Responses MUST NOT contain this extension. It contains the 543 client's current notion of the certificate's status. 545 presumedStatus EXTENSION ::= { 546 SYNTAX PresumedStatusSyntax 547 IDENTIFIED BY id-ocsp-presumedStatus 548 } 550 PresumedStatusSyntax ::= OCSPResponseStatus 552 id-ocsp-presumedStatus OBJECT IDENTIFIER ::= TBA 554 OCSP clients MUST NOT use the "unchanged" status value in a 555 validation query. CAs which receive a query with this extension MAY 556 treat the query as a validation (see Section 7.4), unless the 557 extension's value is 559 set to "unchanged." In that case the CA MUST NOT treat the query as 560 a validation. Note that queries which include an "unchanged" value 561 in this extension do not conform to the cached OCSP protocol. 563 This extension SHALL NOT be marked critical. 565 8.3 The Cache Warnings Extension 567 This extension contains warnings about the cache status of a 568 certificate status response. This extension SHALL NOT be marked 569 critical. It is defined as follows: 571 cacheWarnings EXTENSION ::= { 572 SYNTAX CacheWarningsSyntax 573 IDENTIFIED BY id-ocsp-cacheWarnings 574 } 576 CacheWarningsSyntax ::= SEQUENCE SIZE (1..MAX) of 577 SingleCacheWarning 579 SingleCacheWarning ::= SEQUENCE { 580 warning CacheWarningValue, 581 text UTF8String OPTIONAL, 582 warningData OCTET STRING OPTIONAL 583 } 585 CacheWarningValue ::= INTEGER { 586 stale (0), 587 revalidationFailed (1), 588 disconnectedOperation (2) 589 } 591 id-ocsp-cacheWarnings OBJECT IDENTIFIER ::= TBA 593 Each warning is assigned a number and MAY include an explanatory text 594 and/or some additional data. Responses MAY include more than one 595 warning. Some warnings MUST be preserved by OCSP servers. That is, 596 when an OCSP server receives a response that contains such a warning, 597 it MUST pass that warning along when it relays the response, whether 598 directly or from its cache, to a client. Warnings that must be 599 preserved are identified in their definitions below. 601 The following warnings are defined. Other warnings may be defined in 602 other documents. 604 stale (0): OCSP servers MUST include this warning whenever they 605 return a response using stale cached data. A server MAY add this 606 warning to any response, but MUST NOT remove it until the response 607 is known to be fresh. Servers MUST preserve this warning. 609 revalidationFailed (1): OCSP servers MUST include this warning if 610 they return a stale response because attempts to revalidate 611 failed. A server MAY add this warning to any response, but MUST 612 NOT remove it until the response is successfully revalidated. 613 Servers MUST preserve this warning. 615 disconnectedOperation (2): OCSP servers SHOULD include this warning 616 in all responses if the server is aware that it is not connected 617 to the rest of the network. A server MAY conclude it is not 618 connected after a number of network operations fail, or it MAY be 619 told it is not connected by an administrator. Servers MUST 620 preserve this warning. An OCSP server MUST include this warning 621 when it can not reply to a noCache query with authoritative data 622 (either from its own store or from another OCSP server). See the 623 description of the noCache parameter in Section 8.5 625 8.4 The Cache Status Information Extension 627 This extension contains information about the age of the status data 628 in the response. It consists of two fields: 630 age: This is the age, in seconds, of the response when it was sent by 631 an OCSP server. All OCSP servers MUST include a value for age in 632 all their responses. When a co-located OCSP server responds to a 633 request about a certificate for which it is authoritative, it MUST 634 include an age value of 0 in the response. See Section 7.2.1 for 635 details on how the age value is otherwise calculated. 637 producedAt: This is the local time when the authoritative CA 638 generated the response. Only OCSP servers that are co-located 639 with a CA MAY include this value in a response. An OCSP server 640 MUST NOT create this value in a response for a certificate for 641 which it is not authoritative. An OCSP server that receives and 642 caches a response containing a producedAt value MUST NOT modify or 643 remove it when the response is used to reply to queries. 645 This extension SHALL NOT be marked critical. 647 cacheStatusInfo EXTENSION ::= { 648 SYNTAX CacheStatusInfoSyntax 649 IDENTIFIED BY id-ocsp-cacheStatusInfo 650 } 651 CacheStatusInfoSyntax ::= SEQUENCE { 652 age INTEGER, 653 producedAt GeneralTime OPTIONAL 654 } 656 id-ocsp-cacheStatusInfo OBJECT IDENTIFIER ::= TBA 658 8.5 The Request Cache Parameters Extension 660 The request cache parameters extension allows the client to specify 661 required cache characteristics for the response. Those 662 characteristics are defined by the following fields: 664 noCache: The client requests that the response be retrieved from the 665 CA, i.e. that any intermediary OCSP servers ignore their caches 666 when replying to this request. A server that receives a request 667 with the noCache parameter MUST NOT reply with cached data. The 668 server MUST either reply with authoritative information, or it 669 MUST forward the request, including the noCache parameter, to 670 another OCSP server. If a server is unable to do either, then it 671 MUST reply with a status value of unknown accompanied by a 672 "disconnected operation" warning. 674 maxAge: The client requests that the response can come from a cache 675 provided it is no older than maxAge seconds. See Section 7.2 for 676 a description of cache entry age calculations. If a server 677 receives a request that specifies a maxAge of 0 then it MUST 678 attempt to validate its entry (see Section 7.4), or retrieve a 679 fresh response from another OCSP server or, if appropriate, from 680 its authoritative store. Only if those attempts are unsuccessful 681 MAY a server return a cached response older than the specified 682 maxAge, and in doing so the server MUST include a staleness 683 warning with the response (see Section 8.3). 685 minFresh: The server MAY return a cached response as long as that 686 response it at least minFresh seconds away from becoming stale. 687 See Section 7.2 for a definition of stale. 689 maxStale: The server MAY return a cached response as long as no more 690 than maxStale seconds have elapsed since the response became 691 stale. See Section 7.2for a definition of stale. 693 noValidate: The client will accept a stale response from the server. 694 That is, the server MAY return a stale cache entry without first 695 validating it. Note that any stale response MUST always include 696 an appropriate warning (see Section 8.3). 698 The maxAge parameter MAY be combined with either the minFresh or the 699 maxStale parameters. When a server receives a request containing 700 either combination, it MUST reply with a cached entry only if that 701 entry satisfies both parameters, or all attempts to retrieve a 702 satisfactory response from other servers are unsuccessful (in which 703 case the server MUST include a warning in the response). 705 The noCache parameter MUST NOT be combined with any other parameter, 706 while the noValidate flag MAY accompany any other parameter (except 707 noCache). 709 This extension SHALL NOT be marked critical. 711 requestCacheParameters EXTENSION ::= { 712 SYNTAX RequestCacheParametersSyntax 713 IDENTIFIED BY id-ocsp-requestCacheParameters 714 } 716 RequestCacheParametersSyntax ::= SEQUENCE { 717 noCache BOOLEAN OPTIONAL, 718 maxAge INTEGER OPTIONAL, 719 minFresh INTEGER OPTIONAL, 720 maxStale INTEGER OPTIONAL, 721 noValidate BOOLEAN OPTIONAL 722 } 724 id-ocsp-requestCacheParameters OBJECT IDENTIFIER ::= TBA 726 8.6 The Response Cache Parameters Extension 728 This extension allows a CA to specify required caching 729 characteristics for the response. That is, the CA MAY specify how 730 the client's cache (if any) should handle the response. 732 A server that receives a response containing this extension MUST NOT 733 remove or alter the extension when sending replies based on that 734 response. That is, the server MUST preserve this extension in the 735 same way that some warnings must be preserved (see Section 8.3). 737 Response cache parameters are defined by the following fields: 739 noCache: The receiver MUST NOT cache the response at all. 741 maxAge: The receiver MAY cache the response but MUST consider it 742 stale once the cached entry's current age exceeds maxAge. 743 Responses with a maxAge of 0 MUST be revalidated every time they 744 are used. See Section 7.2.2 for a description of how this field 745 is used in cache entry freshness calculations. 747 Implementations MUST NOT generate responses that include both noCache 748 and maxAge. The ASN.1 code for this extension precludes this. 750 This extension SHALL NOT be marked critical. 752 responseCacheParameters EXTENSION ::= { 753 SYNTAX ResponseCacheParametersSyntax 754 IDENTIFIED BY id-ocsp-responseCacheParameters 755 } 757 ResponseCacheParametersSyntax ::= CHOICE { 758 noCache [0] BOOLEAN, 759 maxAge [1] INTEGER 760 } 762 id-ocsp-responseCachParameters OBJECT IDENTIFIER ::= TBA 764 9. HTTP and OCSP Caching 766 [ 767 Author's Note -- The issues surrounding an HTTP proxy caching OCSP 768 responses are largely unresolved. Here's a quick list of some 769 problems: 771 1. HTTP proxies can't sign responses. Therefore, they can't 772 provide a signed record of how old a response is. That may be 773 acceptable in some circumstances (e.g. when non-repudiation of 774 responses isn't required), but if so the response should still 775 be transmitted over a TLS (or SSL) authenticated channel. That 776 is, the client should authenticate the proxy before accepting a 777 cached response from it. The problem here is that HTTP proxies 778 are normally transparent to HTTPS requests. 780 2. Can an OCSP client really tell an HTTP proxy to refresh its 781 cache on demand (if, say, the client won't accept an entry older 782 than x, but the age of the HTTP proxy's entry is > x)? 784 3. There are many broken HTTP caching implementations. Blindly 785 relying upon them to perform OCSP caching properly can lead to 786 problems. 788 Since these and other issues still need to be resolved, this 789 section currently reflects only the author's views of HTTP caching. 790 The fact that what's here may seem somewhat muddled only reflects 791 the need for resolution. 792 ] 794 Most of OCSP's caching mechanism is borrowed from HTTP 1.1. Readers 795 familiar with [HTTP] will have recognized the similarities. The main 796 differences are: 798 o OCSP's caching is transport independent (OCSP can be implemented 799 over protocols other than HTTP); 801 o OCSP cache parameters can be signed to allow for a non-repudiable 802 record of request and response parameters; 804 o OCSP responses are always origin-authenticated, either via signed 805 responses or SSL/TLS. 807 This section describes the relationship between OCSP caching 808 parameters and HTTP Cache-control directives. 810 When OCSP is transported over HTTP 1.1 or higher, the caching 811 parameters of the OCSP messages SHALL take precedence over any Cache- 812 control directives in the HTTP messages. Where an implementation 813 wishes to use HTTP Cache-control directives when transmitting OCSP 814 messages, it SHOULD ensure that corresponding HTTP directives and 815 OCSP cache parameters, as defined below, have the same values 816 (although see below). HTTP cache-control parameters MUST NOT be used 817 as a replacement for OCSP caching parameters. The following table 818 shows the equivalences between OCSP caching parameters and HTTP 1.1 819 Cache-control directives. 821 OCSP Caching Parameter HTTP 1.1 Cache-control Directive or Header 822 ---------------------- ------------------------------------------ 823 noCache no-cache directive 824 maxAge max-age directive 825 minFresh min-fresh directive 826 maxStale max-stale directive 827 noValidate only-if-cached directive 828 producedAt Date header 829 age Age header 831 The above correlations are not an invitation to blindly use a plain 832 HTTP caching proxy as an OCSP cache. HTTP proxy caching is uneven 833 territory. Many HTTP caches do not function properly, and many also 834 do not support the HTTP 1.1 directives. What is particularly 835 troubling is that transporting OCSP requests over HTTP can lead to 836 the client receiving invalid OCSP responses if there is an 837 intermediate HTTP proxy. Consider the situation in Figure 2. 839 +--------+ +------------+ +----+ 840 | Client |----| HTTP Proxy |----| CA | 841 +--------+ +------------+ +----+ 843 Figure 2 -- An HTTP Proxy in OCSP 845 If the client uses HTTP to contact the CA, responses from the CA 846 might be transparently cached by the proxy. If a previous response 847 from the CA had an age value of, say, 10 seconds, a client making a 848 second query (for the same certificate) through the HTTP Proxy might 849 receive the cached 10-second-old response, which may by then be 850 wrong. The client has no way of knowing if the response came from 851 the CA or from the cache. The client's only recourse would be to 852 make sure it never received a cached entry (by, say, using the nonce 853 extension). 855 Because of these issues, this profile recommends that HTTP caching 856 SHOULD NOT be used for OCSP. When an OCSP message is sent via HTTP, 857 the HTTP no-cache directive SHOULD be used. Although a properly- 858 functioning HTTP 1.1 proxy MAY be employed as an OCSP cache, 859 implementations MUST NOT assume that an HTTP proxy they're dealing 860 with is functioning properly. Also, note that simply because a 861 directly-connected HTTP cache is functionally correct does not mean 862 that any other caches it contacts will be, and the OCSP client has no 863 way of determining the compliance of any HTTP cache. Note, too, that 864 some caches even ignore the no-cache directive. 866 At a minimum, if use of an HTTP proxy is unavoidable (say, to 867 transport OCSP across a firewall) then that proxy MUST at least 868 recognize and obey the no-cache directive. However, since an 869 implementation has no way of determining if this is true, it is up to 870 installation administrators to ensure that their HTTP proxies are 871 compliant. 873 Still, in general, it is better to avoid HTTP caching for OCSP. 875 10. Security Considerations 877 Many attacks, such as spoofing, are attenuated by the authentication 878 inherent in the basic OCSP protocol. The main threat that basic OCSP 879 does not address is a denial of service attack. Note that service 880 may be denied not only because of a malicious attacker but also 881 because of more benign sources, such as heavy network traffic. 883 OCSP clients may require servers to contact other servers (or CAs) to 884 respond to a request. In the event that such contact is impossible, 885 the server MAY reply with cached information even though the client 886 would consider such a response to be stale. When the server responds 887 with data it knows would not be acceptable to a client, the server 888 MUST include one or more of the warnings described in Section 8.3. 890 Such warnings allow the client to be made aware of the situation, and 891 to take appropriate steps (which will depend on the client's local 892 policies). For example, a client that receives a 893 disconnectedOperation warning in a response MAY notify its user of 894 the age of the response and ask for the user's permission to proceed. 896 Other security considerations arise when a non-OCSP entity, such as 897 an HTTP proxy, is used to cache OCSP responses. This sitution SHOULD 898 be avoided. For more, see Section 9. 900 11. Patent Considerations 902 [ Humour impaired: Please plant tongue firmly in cheek before 903 proceeding. ] 905 As of April 1998, the author is unaware of any patents in any 906 jurisdiction that might cover any aspect of the OCSP caching protocol 907 described in this document. It is possible that the publication of 908 this document under the auspices of the IETF will prevent this 909 protocol from being patented in the future. 911 However the author is neither omniscient nor prescient, and so 912 implementors SHOULD take steps to ensure that they are not infringing 913 on any patents filed in their respective jurisdictions. 915 Aspects external to this document, such as the basic OCSP protocol, 916 any application of certificates, the use of a computers or a network 917 thereof to do anything, or anything else you might think is a good 918 idea, may already or probably someday will be subject to a patent. 919 Implementors MAY take this as a sign of impending apocalypse. 921 12. References 923 [OCSP] M. Myers, A. Malpani, R. Ankney, C. Adams and S. Galperin, 924 "Online Certificate Status Protocol - OCSP" (draft). 926 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 927 Requirement Levels", BCP 14, RFC 2119, March 1997. 929 [HTTP] R. Fielding, J. Gettys, J. Mogul, H. Frystyk and T. 930 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 931 2068, January 1997. 933 13. Author's Address 935 Marc Branchaud 936 Xcert Software Inc. 937 Suite 1001 938 701 W. Georgia Street 939 Vancouver, BC, Canada 940 V7Y 1C6 942 Phone: +1 604-640-6227 943 Fax: +1 604-640-6220 944 Email: marcnarc@xcert.com 946 14. Appendix - Collected ASN.1 948 -- 949 -- New OCSPResponseStatus definition 950 -- 952 OCSPResponseStatus ::= ENUMERATED { 953 successful (0), -- Response has valid confirmations 954 malformedRequest (1), -- Illegal confirmation request 955 internalError (2), -- Internal error in issuer 956 tryLater (3), -- Try again later 957 notFound (4), -- Certificate not on record 958 certRequired (5), -- Must supply certificate 959 unchanged (6) -- Status has not changed 960 } 962 -- 963 -- Presumed Status extension 964 -- 966 presumedStatus EXTENSION ::= { 967 SYNTAX PresumedStatusSyntax 968 IDENTIFIED BY id-ocsp-presumedStatus 969 } 971 PresumedStatusSyntax ::= OCSPResponseStatus 973 -- 974 -- Cache Warnings extension 975 -- 977 cacheWarnings EXTENSION ::= { 978 SYNTAX CacheWarningsSyntax 979 IDENTIFIED BY id-ocsp-cacheWarnings 980 } 982 CacheWarningsSyntax ::= SEQUENCE SIZE (1..MAX) of SingleCacheWarning 984 SingleCacheWarning ::= SEQUENCE { 985 warning CacheWarningValue, 986 text UTF8String OPTIONAL, 987 warningData OCTET STRING OPTIONAL 988 } 990 CacheWarningValue ::= INTEGER { 991 stale (0), 992 revalidationFailed (1), 993 disconnectedOperation (2) 995 } 997 -- 998 -- Cache Status Info extension 999 -- 1001 cacheStatusInfo EXTENSION ::= { 1002 SYNTAX CacheStatusInfoSyntax 1003 IDENTIFIED BY id-ocsp-cacheStatusInfo 1004 } 1006 CacheStatusInfoSyntax ::= SEQUENCE { 1007 age INTEGER, 1008 producedAt GeneralTime OPTIONAL 1009 } 1011 -- 1012 -- Request Cache Parameters extension 1013 -- 1015 requestCacheParameters EXTENSION ::= { 1016 SYNTAX RequestCacheParametersSyntax 1017 IDENTIFIED BY id-ocsp-requestCacheParameters 1018 } 1020 RequestCacheParametersSyntax ::= SEQUENCE { 1021 noCache BOOLEAN OPTIONAL, 1022 maxAge INTEGER OPTIONAL, 1023 minFresh INTEGER OPTIONAL, 1024 maxStale INTEGER OPTIONAL, 1025 noValidate BOOLEAN OPTIONAL 1026 } 1028 -- 1029 -- Response Cache Parameters extension 1030 -- 1032 responseCacheParameters EXTENSION ::= { 1033 SYNTAX ResponseCacheParametersSyntax 1034 IDENTIFIED BY id-ocsp-responseCacheParameters 1035 } 1037 ResponseCacheParametersSyntax ::= CHOICE { 1038 noCache [0] BOOLEAN, 1039 maxAge [1] INTEGER 1040 } 1042 -- 1043 -- Collected OIDs 1044 -- 1046 id-ocsp-presumedStatus OBJECT IDENTIFIER ::= TBA 1047 id-ocsp-cacheWarnings OBJECT IDENTIFIER ::= TBA 1048 id-ocsp-cacheStatusInfo OBJECT IDENTIFIER ::= TBA 1049 id-ocsp-requestCacheParameters OBJECT IDENTIFIER ::= TBA 1050 id-ocsp-responseCachParameters OBJECT IDENTIFIER ::= TBA