idnits 2.17.1 draft-ietf-pkix-lightweight-ocsp-profile-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 947. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 958. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 965. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 971. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 2007) is 6122 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 789 -- Looks like a reference, but probably isn't: '1' on line 720 -- Looks like a reference, but probably isn't: '3' on line 874 ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2560 (ref. 'OCSP') (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3280 (ref. 'PKIX') (Obsoleted by RFC 5280) ** Obsolete normative reference: RFC 4346 (ref. 'TLS') (Obsoleted by RFC 5246) ** Obsolete normative reference: RFC 4366 (ref. 'TLSEXT') (Obsoleted by RFC 5246, RFC 6066) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group A. Deacon 3 Internet-Draft VeriSign 4 Intended status: Standards Track R. Hurst 5 Microsoft 6 Expires: December 2007 June 2007 8 Lightweight OCSP Profile 9 for High Volume Environments 11 draft-ietf-pkix-lightweight-ocsp-profile-11.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/1id-abstracts.html 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html 36 Abstract 38 This specification defines a profile of the Online Certificate 39 Status Protocol (OCSP) that addresses the scalability issues 40 inherent when using OCSP in large scale (high volume) Public Key 41 Infrastructure (PKI) environments and/or in PKI environments that 42 require a lightweight solution to minimize communication bandwidth 43 and client side processing. 45 Table of Contents 47 1. OCSP Message Profile...........................................4 48 1.1 OCSP Request Profile......................................4 49 1.1.1 OCSPRequest Structure...................................4 50 1.1.2 Signed OCSPRequests.....................................4 51 1.2 OCSP Response Profile.....................................4 52 1.2.1 OCSPResponse Structure..................................4 53 1.2.2 Signed OCSPResponses....................................5 54 1.2.3 OCSPResponseStatus Values...............................6 55 1.2.4 thisUpdate, nextUpdate and producedAt...................6 56 2. Client Behavior................................................7 57 2.1 OCSP Responder Discovery..................................7 58 2.2 Sending an OCSP Request...................................7 59 3. Ensuring an OCSPResponse is Fresh..............................7 60 4. Transport Profile..............................................8 61 5. Caching Recommendations........................................9 62 5.1 Caching at the Client.....................................9 63 5.2 HTTP Proxies.............................................10 64 5.3 Caching at Servers.......................................11 65 6. Security Considerations.......................................12 66 6.1 Replay attacks...........................................12 67 6.2 Man-in-the-middle attacks................................12 68 6.3 Impersonation attacks....................................13 69 6.4 Denial of service attacks................................13 70 6.5 Modification of HTTP Headers.............................13 71 6.6 Request Authentication and Authorization.................13 72 7. IANA Considerations...........................................13 73 8. Acknowledgements..............................................14 74 9. References....................................................14 75 9.1 Normative................................................14 76 9.2 Informative..............................................14 77 10. Author's Addresses...........................................14 78 Appendix A. Example OCSP Messages...............................15 79 Appendix A.1: OCSP Request...................................15 80 Appendix A.2: OCSP Response..................................15 82 Introduction 84 The Online Certificate Status Protocol [OCSP] specifies a mechanism 85 used to determine the status of digital certificates, in lieu of 86 using Certificate Revocation Lists (CRLs). Since its definition in 87 1999, it has been deployed in a variety of environments and has 88 proven to be a useful certificate status checking mechanism. (For 89 brevity we refer to OCSP as being used to verify certificate status, 90 but only the revocation status of a certificate is checked via this 91 protocol.) 93 To date, many OCSP deployments have been used to ensure timely and 94 secure certificate status information for high-value electronic 95 transactions or highly sensitive information, such as in the banking 96 and financial environments. As such, the requirement for an OCSP 97 responder to respond in "real time" (i.e. generating a new OCSP 98 response for each OCSP request) has been important. In addition, 99 these deployments have operated in environments where bandwidth 100 usage is not an issue, and have run on client and server systems 101 where processing power is not constrained. 103 As the use of PKI continues to grow and move into diverse 104 environments, so does the need for a scalable and cost effective 105 certificate status mechanism. Although OCSP as currently defined 106 and deployed meets the need of small to medium sized PKI's which 107 operate on powerful systems on wired networks, there is a limit as 108 to how these OCSP deployments scale from both an efficiency and cost 109 perspective. Mobile environments, where network bandwidth may be at 110 a premium and client side devices are constrained from a processing 111 point of view, require the careful use of OCSP to minimize bandwidth 112 usage and client side processing complexity. [OCSPMP] 114 PKI continues to be deployed into environments where millions if not 115 hundreds of millions of certificates have been issued. In many of 116 these environments an even larger number of users (also known as 117 relying parties) have the need to ensure that the certificate they 118 are relying upon has not been revoked. As such it is important that 119 OCSP is used in such a way that ensures the load on OCSP responders 120 and the network infrastructure required to host those responders is 121 kept to a minimum. 123 This document addresses the scalability issues inherent when using 124 OCSP in PKI environments described above by defining a message 125 profile and clarifying OCSP client and responder behavior that will 126 permit: 128 1) OCSP response pre-production and distribution 129 2) Reduced OCSP message size to lower bandwidth usage 130 3) Response message caching both in the network and on the client 132 It is intended that the normative requirements defined in this 133 profile will be adopted by OCSP clients and OCSP responders 134 operating in very large scale (high volume) PKI environments or PKI 135 environments that require a lightweight solution to minimize 136 bandwidth and client side processing power (or both), as described 137 above. As OCSP does not have the means to signal responder 138 capabilities within the protocol, clients needing to differentiate 139 between OCSP responses produced by responders conformant with this 140 profile and those that are not need to rely on out of band 141 mechanisms to determine when a responder operates according to this 142 profile and, as such, when the requirements of this profile apply. 143 In the case where an out of band mechanisms may not be available, 144 this profile ensures that interoperability will still occur between 145 a fully conformant OCSP 2560 client and a responder that is 146 operating in a mode as described in this specification. 148 1. OCSP Message Profile 150 This section defines a subset of OCSPRequest and OCSPResponse 151 functionality as defined in [OCSP]. 153 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 154 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 155 document are to be interpreted as described in [RFC2119]. 157 1.1 OCSP Request Profile 159 1.1.1 OCSPRequest Structure 161 OCSPRequests conformant to this profile MUST include only one 162 Request in the OCSPRequest.RequestList structure. 164 Clients MUST use SHA1 as the hashing algorithm for the 165 CertID.issuerNameHash and the CertID.issuerKeyHash values. 167 Clients MUST NOT include the singleRequestExtensions structure. 169 Clients SHOULD NOT include the requestExtensions structure. If a 170 requestExtensions structure is included, this profile RECOMMENDS 171 that it contain only the nonce extension (id-pkix-ocsp-nonce). See 172 Section 3 for issues concerning the use of a nonce in high volume 173 OCSP environments. 175 1.1.2 Signed OCSPRequests 177 Clients SHOULD NOT send signed OCSPRequests. Responders MAY ignore 178 the signature on OCSPRequests. 180 If the OCSPRequest is signed, the client SHALL specify its name in 181 the OCSPRequest.requestorName field, otherwise clients SHOULD NOT 182 include the requestorName field in the OCSPRequest. OCSP servers 183 MUST be prepared to receive unsigned OCSP requests that contain the 184 requestorName field, but must realize that the provided value is not 185 authenticated. 187 1.2 OCSP Response Profile 189 1.2.1 OCSPResponse Structure 191 Responders MUST generate a BasicOCSPResponse as identified by the 192 id-pkix-ocsp-basic OID. Clients MUST be able to parse and accept a 193 BasicOCSPResponse. OCSPResponses conformant to this profile SHOULD 194 include only one SingleResponse in the ResponseData.responses 195 structure, but MAY include additional SingleResponse elements if 196 necessary to improve response pre-generation performance or cache 197 efficiency. 199 The responder SHOULD NOT include responseExtensions. As specified in 200 [OCSP], clients MUST ignore unrecognized non-critical 201 responseExtensions in the response. 203 In the case where a responder does not have the ability to respond 204 to an OCSP request containing a option not supported by the server, 205 it SHOULD return the most complete response it can. For example in 206 the case where a responder only supports pre-produced responses and 207 does not have the ability to respond to an OCSP request containing a 208 nonce, it SHOULD return a response that does not include a nonce. 210 Clients SHOULD attempt to process a response even if the response 211 does not include a nonce. See Section 3 for details on validating 212 responses that do not contain a nonce. See also Section 6 for 213 relevant security considerations. 215 Responders that do not have the ability to respond to OCSP requests 216 that contain a unsupported option such as a nonce MAY forward the 217 request to an OCSP responder capable of doing so. 219 The responder MAY include the singleResponse.singleResponse 220 extensions structure. 222 1.2.2 Signed OCSPResponses 224 Clients MUST validate the signature on the returned OCSPResponse. 226 If the response is signed by a delegate of the issuing CA a valid 227 responder certificate MUST be referenced in the 228 BasicOCSPResponse.certs structure. 230 It is RECOMMENDED that the OCSP responder's certificate contain the 231 id-pkix-ocsp-nocheck extension, as defined in [OCSP], to indicate to 232 the client that it need not check its status. In addition, it is 233 RECOMMENDED that neither an OCSP authorityInfoAccess (AIA) extension 234 nor cRLDistributionPoints (CRLDP) extension be included in the OCSP 235 responder's certificate. Accordingly, the responder's signing 236 certificate SHOULD be relatively short-lived and renewed regularly. 238 Clients MUST be able to identify OCSP responder certificates using 239 both the byName and byKey ResponseData.ResponderID choices. 240 Responders SHOULD use byKey to further reduce the size of the 241 response in scenarios where reducing bandwidth is an issue. 243 1.2.3 OCSPResponseStatus Values 245 As long as the OCSP infrastructure has authoritative records for a 246 particular certificate, an OCSPResponseStatus of "successful" will 247 be returned. When access to authoritative records for a particular 248 certificate is not available the responder MUST return an 249 OCSPResponseStatus of "unauthorized". As such, this profile extends 250 the RFC 2560 [OCSP] definition of "unauthorized" as follows - 252 The response "unauthorized" is returned in cases where the client 253 is not authorized to make this query to this server or the server 254 is not capable of responding authoritatively. 256 For example, OCSP responders that do not have access to 257 authoritative records for a requested certificate, such as those 258 that generate and distribute OCSP responses in advance and thus do 259 not have the ability to properly respond with a signed "successful" 260 yet "unknown" response, will respond with an OCSPResponseStatus of 261 "unauthorized". Also, in order to ensure the database of revocation 262 information does not grow unbounded over time, the responder MAY 263 remove the status records of expired certificates. Requests from 264 clients for certificates whose record has been removed, will result 265 in an OCSPResponseStatus of "unauthorized". 267 Security considerations regarding the use of unsigned responses are 268 discussed in [OCSP]. 270 1.2.4 thisUpdate, nextUpdate and producedAt 272 When pre-producing OCSPResponse messages, the responder MUST set the 273 thisUpdate, nextUpdate and producedAt times as follows: 275 thisUpdate The time at which the status being indicated is 276 known to be correct. 278 nextUpdate The time at or before which newer information 279 will be available about the status of the 280 certificate. Responders MUST always include 281 this value to aid in response caching. See 282 Section 5 for additional information on 283 caching. 285 producedAt The time at which the OCSP response was signed. 287 Note: In many cases the value of thisUpdate and producedAt will be 288 the same. 290 For the purposes of this profile, ASN.1 encoded GeneralizedTime 291 values such as thisUpdate, nextUpdate and producedAt MUST be 292 expressed Greenwich Mean Time (Zulu) and MUST include seconds (i.e., 293 times are YYYYMMDDHHMMSSZ), even where the number of seconds is 294 zero. GeneralizedTime values MUST NOT include fractional seconds. 296 2. Client Behavior 298 2.1 OCSP Responder Discovery 300 Clients MUST support the authorityInfoAccess extension as defined in 301 [PKIX] and MUST recognize the id-ad-ocsp access method. This 302 enables CAs to inform clients how they can contact the OCSP service. 304 In the case where a client is checking the status of a certificate 305 that contains both an authorityInformationAccess (AIA) extension 306 pointing to an OCSP responder and a cRLDistributionPoints extension 307 pointing to a CRL, the client SHOULD attempt to contact the OCSP 308 responder first. Clients MAY attempt to retrieve the CRL if no 309 OCSPResponse is received from the responder after a locally 310 configured timeout and number of retries. 312 2.2 Sending an OCSP Request 314 To avoid needless network traffic, applications MUST verify the 315 signature of signed data before asking an OCSP client to check the 316 status of certificates used to verify the data. If the signature is 317 invalid or the application is not able to verify it, an OCSP check 318 MUST NOT be requested. 320 Similarly, an application MUST validate the signature on 321 certificates in a chain, before asking an OCSP client to check the 322 status of the certificate. If the certificate signature is invalid 323 or the application is not able to verify it, an OCSP check MUST NOT 324 be requested. Clients SHOULD NOT make a request to check the status 325 of expired certificates. 327 3. Ensuring an OCSPResponse is Fresh 329 In order to ensure a client does not accept an out of date response 330 that indicates a 'good' status when in fact there is a more up to 331 date response that specifies the status of 'revoked', a client must 332 ensure the responses they receive are fresh. 334 In general, two mechanisms are available to clients to ensure a 335 response is fresh. The first uses nonces, and the second is based 336 on time. In order for time based mechanisms to work, both clients 337 and responders MUST have access to an accurate source of time. 339 Because this profile specifies that clients SHOULD NOT include a 340 requestExtensions structure in OCSPRequests (See Section 1.1) 341 clients MUST be able to determine OCSPResponse freshness based on an 342 accurate source of time. Clients that opt to include a nonce in the 343 request SHOULD NOT reject a corresponding OCSPResponse solely on the 344 basis of the non-existent expected nonce, but MUST fall back to 345 validating the OCSPResponse based on time. 347 Clients that do not include a nonce in the request MUST ignore any 348 nonce that may be present in the response. 350 Clients MUST check for the existence of the nextUpdate field and 351 MUST ensure the current time, expressed in GMT time as described in 352 Section 1.2.4, falls between the thisUpdate and nextUpdate times. 353 If the nextUpdate field is absent the client MUST reject the 354 response. 356 If the nextUpdate field is present the client MUST ensure that it is 357 not earlier than current time. If the current time on the client is 358 later than the time specified in the nextUpdate field, the client 359 MUST reject the response as stale. Clients MAY allow configuration 360 of a small tolerance period for acceptance of responses after 361 nextUpdate to handle minor clock differences relative to responders 362 and caches. This tolerance period should be chosen based on the 363 accuracy and precision of time synchronization technology available 364 to the calling application environment. For example, Internet peers 365 with low latency connections typically expect NTP time 366 synchronization to keep them accurate within parts of a second; 367 higher latency environments or where an NTP analogue is not 368 available may have to be more liberal in their tolerance. 370 See the security considerations in Section 6 for additional details 371 on replay and man-in-the-middle attacks. 373 4. Transport Profile 375 The OCSP responder MUST support requests and responses over HTTP. 376 When sending requests that are less than or equal to 255 bytes in 377 total (after encoding) including the scheme and delimiters 378 (http://), server name and base64 encoded OCSPRequest structure, 379 clients MUST use the GET method (to enable OCSP response caching). 380 OCSP requests larger than 255 bytes SHOULD be submitted using the 381 POST method. In all cases, clients MUST follow the descriptions in 382 A.1.1 of [OCSP] when constructing these messages. 384 When constructing a GET message, OCSP clients MUST base64 encode the 385 OCSPRequest structure and append it to the URI specified in the AIA 386 extension [PKIX]. Clients MUST NOT include CR or LF characters in 387 the base64-encoded string. Clients MUST properly url-encode the 388 base64 encoded OCSPRequest. For example: 390 http://ocsp.example.com/MEowSDBGMEQwQjAKBggqhkiG9w0CBQQQ7sp6GTKpL 391 2dAdeGaW267owQQqInESWQD0mGeBArSgv%2FBWQIQLJx%2Fg9xF8oySYzol80Mbpg 392 %3D%3D 394 In response to properly formatted OCSPRequests that are cachable 395 (i.e. responses that contain a nextUpdate value), the responder will 396 include the binary value of the DER encoding of the OCSPResponse 397 preceded by the following HTTP [HTTP] headers. 399 content-type: application/ocsp-response 400 content-length: 401 last-modified: 402 ETag: "" 403 expires: 404 cache-control: max-age=, public, no-transform, must-revalidate 405 date: 407 See Section 5.2 for details on the use of these headers. 409 5. Caching Recommendations 411 The ability to cache OCSP Responses throughout the network is an 412 important factor in high volume OCSP deployments. This section 413 discusses the recommended caching behavior of OCSP clients and HTTP 414 proxies and the steps that should be taken to minimize the number of 415 times that OCSP clients "hit the wire". In addition the concept of 416 including OCSP responses in protocol exchanges (aka stapling or 417 piggybacking), such as has been defined in TLS, is also discussed. 419 5.1 Caching at the Client 421 To minimize bandwidth usage, clients MUST locally cache 422 authoritative OCSP responses. (i.e., a response with a signature 423 that has been successfully validated and that indicate an 424 OCSPResponseStatus of 'successful') 426 Most OCSP clients will send OCSPrequests at or near the nextUpdate 427 time (when a cached response expires). To avoid large spikes in 428 responder load that might occur when many clients refresh cached 429 responses for a popular certificate, responders MAY indicate when 430 the client should fetch an updated OCSP response by using the cache- 431 control:max-age directive. Clients SHOULD fetch the updated OCSP 432 Response on or after the max-age time. To ensure that clients 433 receive an updated OCSP response, OCSP Responders MUST refresh the 434 OCSP response before the max-age time. 436 5.2 HTTP Proxies 438 The responder SHOULD set the HTTP headers of the OCSP response in 439 such a way to allow for the intelligent use of intermediate HTTP 440 proxy servers. See [HTTP] for the full definition of these headers 441 and the proper format of any date and time values. 443 HTTP Header Description 444 =========== ==================================================== 445 date The date and time at which the OCSP server generated 446 the HTTP response. 448 last-modified This value specifies the date and time at which the 449 OCSP responder last modified the response. This 450 date and time will be the same as the thisUpdate 451 timestamp in the request itself. 453 expires Specifies how long the response is considered fresh. 454 This date and time will be the same as the 455 nextUpdate timestamp in the OCSP response itself. 457 ETag A string that identifies a particular version of 458 the associated data. This profile RECOMMENDS that 459 the ETag value be the ASCII HEX representation of 460 the SHA1 hash of the OCSPResponse structure. 462 cache-control Contains a number of caching directives. 464 * max-age=- where n is a time value later than 465 thisUpdate but earlier than nextUpdate. 466 * public- makes normally uncachable response 467 cachable by both shared and 468 nonshared caches. 469 * no-transform-specifies that a proxy cache cannot 470 change the type, length , or 471 encoding of the object content. 472 * must-revalidate- prevents caches from 473 intentionally returning stale 474 responses. 476 OCSP responders MUST NOT include a "Pragma: no-cache", "Cache- 477 Control: no-cache" or "Cache-Control: no-store" header in 478 authoritative OCSP responses. 480 OCSP responders SHOULD include one or more of these headers in non- 481 authoritative OCSP responses. 483 For example, assume that an OCSP response has the following time 484 stamp values: 486 thisUpdate = May 1, 2005 01:00:00 GMT 487 nextUpdate = May 3, 2005 01:00:00 GMT 488 productedAt = May 1, 2005 01:00:00 GMT 490 and that an OCSP client requests the response on May 2, 2005 491 01:00:00 GMT. In this scenario the HTTP response may look like 492 this: 494 content-type: application/ocsp-response 495 content-length: 1000 496 date: Fri, 02 May 2005 01:00:00 GMT 497 last-modified: Thu, 01 May 2005 01:00:00 GMT 498 ETag: "c66c0341abd7b9346321d5470fd0ec7cc4dae713" 499 expires: Sat, 03 May 2005 01:00:00 GMT 500 cache-control: max-age=86000,public,no-transform,must-revalidate 501 <...> 503 OCSP clients MUST NOT included a no-cache header in OCSP request 504 messages, unless the client encounters an expired response which may 505 be a result of an intermediate proxy caching stale data. In this 506 situation clients SHOULD resend the request specifying that proxies 507 should be bypassed by including an appropriate HTTP header in the 508 request (i.e. Pragma: no-cache or Cache-Control: no-cache). 510 5.3 Caching at Servers 512 In some scenarios it is advantageous to include OCSP response 513 information within the protocol being utilized between the client 514 and server. Including OCSP responses in this manner has a few 515 attractive effects. 517 First, it allows for the caching of OCSP responses on the server, 518 thus lowering the number of hits to the OCSP responder. 520 Second, it enables certificate validation in the event the client is 521 not connected to a network and thus eliminates the need for clients 522 to establish a new HTTP session with the responder. 524 Third, it reduces the number of round trips the client needs to make 525 in order to complete a handshake. 527 Fourth, it simplifies the client side OCSP implementation by 528 enabling a situation where the client need only the ability to parse 529 and recognize OCSP responses. 531 This functionality has been specified as an extension to the TLS 532 [TLS] protocol in Section 3.6 [TLSEXT], but can be applied to any 533 client-server protocol. 535 This profile RECOMMENDS that both TLS clients and servers implement 536 the certificate status request extension mechanism for TLS. 538 Further information regarding caching issues can be obtained from 539 RFC 3143 [RFC3143]. 541 6. Security Considerations 543 The following considerations apply in addition to the security 544 consideration addressed in Section 5 of [OCSP]. 546 6.1 Replay attacks 548 Because the use of nonces in this profile is optional, there is a 549 possibility that an out of date OCSP response could be replayed, 550 thus causing a client to accept good response when in fact there is 551 a more up to date response that specifies the status of revoked. In 552 order to mitigate this attack, clients MUST have access to an 553 accurate source of time and ensure that the OCSP responses they 554 receive are sufficiently fresh. 556 Clients that do not have an accurate source of date and time are 557 vulnerable to service disruption. For example, a client with a 558 sufficiently fast clock may reject a fresh OCSP response. Similarly 559 a client with a sufficiently slow clock may incorrectly accept 560 expired valid responses for certificates that may in fact be 561 revoked. 563 Future versions of the OCSP protocol may provide a way for the 564 client to know whether the server supports nonces or does not 565 support nonces. If a client can determine that the server supports 566 nonces, it MUST reject a reply that does not contain an expected 567 nonce. Otherwise, clients that opt to include a nonce in the 568 request SHOULD NOT reject a corresponding OCSPResponse solely on the 569 basis of the non-existent expected nonce, but MUST fall back to 570 validating the OCSPResponse based on time. 572 6.2 Man-in-the-middle attacks 574 To mitigate risk associated with this class of attack, the client 575 must properly validate the signature on the response. 577 The use of signed responses in OCSP serves the purpose to 578 authenticate the identity of the OCSP responder and to verify that 579 it is authorized to sign responses on the CA's behalf. 581 Clients MUST ensure that they are communicating with an authorized 582 responder by the rules described in [OCSP] Section 4.2.2.2. 584 6.3 Impersonation attacks 586 The use of signed responses in OCSP serves to authenticate the 587 identity of OCSP Responder. 589 As detailed in [OCSP], clients must properly validate the signature 590 of the OCSP response and the signature on the OCSP response signer 591 certificate to ensure an authorized responder created it. 593 6.4 Denial of service attacks 595 OCSP responders should take measures to prevent or mitigate denial 596 of service attacks. As this profile specifies the use of unsigned 597 OCSPRequests, access to the responder may be implicitly given to 598 everyone who can send a request to a responder, and thus the ability 599 to mount a denial of service attack via a flood of requests may be 600 greater. For example a responder could limit the rate of incoming 601 requests from a particular IP address if questionable behavior is 602 detected. 604 6.5 Modification of HTTP Headers 606 Values included in HTTP headers as described in Section 4 and 5, are 607 not cryptographically protected, they may be manipulated by an 608 attacker. Clients SHOULD use these values for caching guidance only 609 and ultimately SHOULD rely only on the values present in the signed 610 OCSPResponse. Clients SHOULD NOT rely on cached responses beyond 611 the nextUpdate time. 613 6.6 Request Authentication and Authorization 615 The suggested use of unsigned requests in this environment removes 616 an option that allows the responder to determine the authenticity of 617 incoming request. Thus, access to the responder may be implicitly 618 given to everyone who can send a request to a responder. 619 Environments where explicit authorization to access the OCSP 620 responder is necessary can utilize other mechanisms to authenticate 621 requestors or restrict or meter service. 623 7. IANA Considerations 625 This document has no actions for IANA. 627 8. Acknowledgements 629 The authors wish to thank Magnus Nystrom Of RSA Security, Inc., 630 Jagjeet Sondh of Vodafone Group R&D and David Engberg of CoreStreet, 631 Ltd. for their contributions to this specification. 633 9. References 635 9.1 Normative 637 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 638 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 639 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S. and 645 C. Adams, "Internet X.509 Public Key Infrastructure: 646 Online Certificate Status Protocol - OCSP", RFC 2560, 647 June 1999. 649 [PKIX] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 650 Public Key Infrastructure - Certificate and 651 Certificate Revocation List (CRL) Profile", RFC 3280, 652 April 2002. 654 [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security 655 Protocol Version 1.1", RFC 4346, April 2006. 657 [TLSEXT] Blake-Wilson, et. al., "Transport Layer Security (TLS) 658 Extensions", RFC 4366, April 2006. 660 9.2 Informative 662 [OCSPMP] "OCSP Mobile Profile V1.0", Open Mobile Alliance, 663 www.openmobilalliance.org. 665 [RFC3143] Cooper, I., Dilley, J., "Known HTTP Proxy/Caching 666 Problems", RFC 3143, June 2001 668 10. Author's Addresses 670 Alex Deacon 671 VeriSign, Inc. 672 487 E. Middlefield Road Phone: 1-650-426-3478 673 Mountain View, CA. USA Email: alex@verisign.com 675 Ryan Hurst 676 Microsoft 677 One Microsoft Way Phone: 1-425-707-8979 678 Redmond, WA. USA Email: rmh@microsoft.com 680 Appendix A. Example OCSP Messages 682 Appendix A.1: OCSP Request 684 SEQUENCE { 685 SEQUENCE { 686 SEQUENCE { 687 SEQUENCE { 688 SEQUENCE { 689 SEQUENCE { 690 OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 691 NULL 692 } 693 OCTET STRING 694 C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2 695 1A B7 BF C0 696 OCTET STRING 697 0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D 698 15 7C D4 F6 699 INTEGER 700 09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA 701 } 702 } 703 } 704 } 705 } 707 Appendix A.2: OCSP Response 709 SEQUENCE { 710 ENUMERATED 0 711 [0] { 712 SEQUENCE { 713 OBJECT IDENTIFIER ocspBasic (1 3 6 1 5 5 7 48 1 1) 714 OCTET STRING, encapsulates { 715 SEQUENCE { 716 SEQUENCE { 717 [0] { 718 INTEGER 0 719 } 720 [1] { 721 SEQUENCE { 722 SET { 723 SEQUENCE { 724 OBJECT IDENTIFIER organizationName (2 5 4 10) 725 PrintableString 'Example Trust Network' 726 } 727 } 728 SET { 729 SEQUENCE { 730 OBJECT IDENTIFIER 731 organizationalUnitName (2 5 4 11) 732 PrintableString 'Example, Inc.' 733 } 734 } 735 SET { 736 SEQUENCE { 737 OBJECT IDENTIFIER 738 organizationalUnitName (2 5 4 11) 739 PrintableString 740 'Example OCSP Responder' 741 } 742 } 743 } 744 } 745 GeneralizedTime 07/11/2005 23:52:44 GMT 746 SEQUENCE { 747 SEQUENCE { 748 SEQUENCE { 749 SEQUENCE { 750 OBJECT IDENTIFIER sha1 (1 3 14 3 2 26) 751 NULL 752 } 753 OCTET STRING 754 C0 FE 02 78 FC 99 18 88 91 B3 F2 12 E9 C7 E1 B2 755 1A B7 BF C0 756 OCTET STRING 757 0D FC 1D F0 A9 E0 F0 1C E7 F2 B2 13 17 7E 6F 8D 758 15 7C D4 F6 759 INTEGER 760 09 34 23 72 E2 3A EF 46 7C 83 2D 07 F8 DC 22 BA 761 } 762 [0] 763 Error: Object has zero length. 764 GeneralizedTime 07/11/2005 23:52:44 GMT 765 [0] { 766 GeneralizedTime 14/11/2005 23:52:44 GMT 767 } 768 } 769 } 770 } 771 SEQUENCE { 772 OBJECT IDENTIFIER 773 sha1withRSAEncryption (1 2 840 113549 1 1 5) 774 NULL 775 } 776 BIT STRING 777 0E 9F F0 52 B1 A7 42 B8 6E C1 35 E1 0E D5 A9 E2 778 F5 C5 3C 16 B1 A3 A7 A2 03 8A 2B 4D 2C F1 B4 98 779 8E 19 DB BA 1E 1E 72 FF 32 F4 44 E0 B2 77 1C D7 780 3C 9E 78 F3 D1 82 68 86 63 12 7F A4 6F F0 4D 84 781 EA F8 E2 F7 5D E3 48 44 57 28 80 C7 57 3C FE E1 782 42 0E 5E 17 FC 60 D8 05 D9 EF E2 53 E7 AB 7F 3A 783 A8 84 AA 5E 46 5B E7 B8 1F C6 B1 35 AD FF D1 CC 784 BA 58 7D E8 29 60 79 F7 41 02 EA E0 82 0E A6 30 785 [0] { 786 SEQUENCE { 787 SEQUENCE { 788 SEQUENCE { 789 [0] { 790 INTEGER 2 791 } 792 INTEGER 793 49 4A 02 37 1B 1E 70 67 41 6C 9F 06 2F D8 FE DA 794 SEQUENCE { 795 OBJECT IDENTIFIER 796 sha1withRSAEncryption (1 2 840 113549 1 1 5) 797 NULL 798 } 799 SEQUENCE { 800 SET { 801 SEQUENCE { 802 OBJECT IDENTIFIER 803 organizationName (2 5 4 10) 804 PrintableString 'Example Trust Network' 805 } 806 } 807 SET { 808 SEQUENCE { 809 OBJECT IDENTIFIER 810 organizationalUnitName (2 5 4 11) 811 PrintableString 'Example, Inc.' 812 } 813 } 814 SET { 815 SEQUENCE { 816 OBJECT IDENTIFIER 817 organizationalUnitName (2 5 4 11) 818 PrintableString 819 'Example CA' 820 } 821 } 822 } 823 SEQUENCE { 824 UTCTime 08/10/2005 00:00:00 GMT 825 UTCTime 06/01/2006 23:59:59 GMT 826 } 827 SEQUENCE { 828 SET { 829 SEQUENCE { 830 OBJECT IDENTIFIER 831 organizationName (2 5 4 10) 832 PrintableString 'Example Trust Network' 833 } 834 } 835 SET { 836 SEQUENCE { 837 OBJECT IDENTIFIER 838 organizationalUnitName (2 5 4 11) 839 PrintableString 'Example, Inc.' 840 } 841 } 842 SET { 843 SEQUENCE { 844 OBJECT IDENTIFIER 845 organizationalUnitName (2 5 4 11) 846 PrintableString 847 'Example OCSP Responder' 848 } 849 } 850 } 851 SEQUENCE { 852 SEQUENCE { 853 OBJECT IDENTIFIER 854 rsaEncryption (1 2 840 113549 1 1 1) 855 NULL 856 } 857 BIT STRING, encapsulates { 858 SEQUENCE { 859 INTEGER 860 00 AF C9 7A F5 09 CA D1 08 8C 82 6D AC D9 63 4D 861 D2 64 17 79 CB 1E 1C 1C 0C 6E 28 56 B5 16 4A 4A 862 00 1A C1 B0 74 D7 B4 55 9D 2A 99 1F 0E 4A E3 5F 863 81 AF 8D 07 23 C3 30 28 61 3F B0 C8 1D 4E A8 9C 864 A6 32 B4 D2 63 EC F7 C1 55 7A 73 2A 51 99 00 D5 865 0F B2 4E 11 5B 83 55 83 4C 0E DD 12 0C BD 7E 41 866 04 3F 5F D9 2A 65 88 3C 2A BA 20 76 1D 1F 59 3E 867 D1 85 F7 4B E2 81 50 9C 78 96 1B 37 73 12 1A D2 869 [ Another 1 bytes skipped ] 870 INTEGER 65537 871 } 872 } 873 } 874 [3] { 875 SEQUENCE { 876 SEQUENCE { 877 OBJECT IDENTIFIER 878 basicConstraints (2 5 29 19) 879 OCTET STRING, encapsulates { 880 SEQUENCE {} 881 } 882 } 883 SEQUENCE { 884 OBJECT IDENTIFIER extKeyUsage (2 5 29 37) 885 OCTET STRING, encapsulates { 886 SEQUENCE { 887 OBJECT IDENTIFIER 888 ocspSigning (1 3 6 1 5 5 7 3 9) 889 } 890 } 891 } 892 SEQUENCE { 893 OBJECT IDENTIFIER keyUsage (2 5 29 15) 894 OCTET STRING, encapsulates { 895 BIT STRING 7 unused bits 896 '1'B (bit 0) 897 } 898 } 899 SEQUENCE { 900 OBJECT IDENTIFIER 901 ocspNoCheck (1 3 6 1 5 5 7 48 1 5) 902 OCTET STRING, encapsulates { 903 NULL 904 } 905 } 906 } 907 } 908 } 909 SEQUENCE { 910 OBJECT IDENTIFIER 911 sha1withRSAEncryption (1 2 840 113549 1 1 5) 912 NULL 913 } 914 BIT STRING 915 3A 68 5F 6A F8 87 36 4A E2 22 46 5C C8 F5 0E CE 916 1A FA F2 25 E1 51 AB 37 BE D4 10 C8 15 93 39 73 917 C8 59 0F F0 39 67 29 C2 60 20 F7 3F FE A0 37 AB 918 80 0B F9 3D 38 D4 48 67 E4 FA FD 4E 12 BF 55 29 919 14 E9 CC CB DD 13 82 E9 C4 4D D3 85 33 C1 35 E5 920 8F 38 01 A7 F7 FD EB CD DE F2 F7 85 86 AE E3 1B 921 9C FD 1D 07 E5 28 F2 A0 5E AC BF 9E 0B 34 A1 B4 922 3A A9 0E C5 8A 34 3F 65 D3 10 63 A4 5E 21 71 5A 923 } 924 } 925 } 926 } 927 } 928 } 929 } 930 } 932 Full Copyright Statement 934 Copyright (C) The IETF Trust (2007). 936 This document is subject to the rights, licenses and restrictions 937 contained in BCP 78, and except as set forth therein, the authors 938 retain all their rights. 940 This document and the information contained herein are provided on an 941 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 942 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 943 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 944 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 945 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 946 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 947 FOR A PARTICULAR PURPOSE. 949 Intellectual Property 951 The IETF takes no position regarding the validity or scope of any 952 Intellectual Property Rights or other rights that might be claimed 953 to pertain to the implementation or use of the technology described 954 in this document or the extent to which any license under such 955 rights might or might not be available; nor does it represent that 956 it has made any independent effort to identify any such rights. 957 Information on the procedures with respect to rights in RFC 958 documents can be found in BCP 78 and BCP 79. 960 Copies of IPR disclosures made to the IETF Secretariat and any 961 assurances of licenses to be made available, or the result of an 962 attempt made to obtain a general license or permission for the use 963 of such proprietary rights by implementers or users of this 964 specification can be obtained from the IETF on-line IPR repository 965 at http://www.ietf.org/ipr. 967 The IETF invites any interested party to bring to its attention any 968 copyrights, patents or patent applications, or other proprietary 969 rights that may cover technology that may be required to implement 970 this standard. Please address the information to the IETF at 971 ietf-ipr@ietf.org.