idnits 2.17.1 draft-hallambaker-pkixstatus-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 383: '... An OCSP service MAY return the follow...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 20, 2013) is 3841 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) == Missing Reference: 'TBS' is mentioned on line 405, but not defined ** Obsolete normative reference: RFC 6962 (Obsoleted by RFC 9162) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force (IETF) Phillip Hallam-Baker 2 Internet-Draft Comodo Group Inc. 3 Intended Status: Standards Track October 20, 2013 4 Expires: April 23, 2014 6 Web PKI Operations: Revocation and Status 7 draft-hallambaker-pkixstatus-01 9 Abstract 11 This document describes the certificate status mechanisms supported 12 in the Web PKI 14 Status of This Memo 16 This Internet-Draft is submitted in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF). Note that other groups may also distribute 21 working documents as Internet-Drafts. The list of current Internet- 22 Drafts is at http://datatracker.ietf.org/drafts/current/. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 Copyright Notice 31 Copyright (c) 2013 IETF Trust and the persons identified as the 32 document authors. All rights reserved. 34 This document is subject to BCP 78 and the IETF Trust's Legal 35 Provisions Relating to IETF Documents 36 (http://trustee.ietf.org/license-info) in effect on the date of 37 publication of this document. Please review these documents 38 carefully, as they describe your rights and restrictions with respect 39 to this document. Code Components extracted from this document must 40 include Simplified BSD License text as described in Section 4.e of 41 the Trust Legal Provisions and are provided without warranty as 42 described in the Simplified BSD License. 44 Table of Contents 46 1. Certificate Status . . . . . . . . . . . . . . . . . . . . . . 4 47 1.1. Operational Certificate Lifecycle Model . . . . . . . . . 4 48 1.1.1. Direct and Indirect Status Assertions . . . . . . . 4 49 1.1.2. Trust Path Processing . . . . . . . . . . . . . . . 5 50 1.1.3. Revocation Reasons . . . . . . . . . . . . . . . . . 5 51 1.1.4. Operational Certificate States . . . . . . . . . . . 7 52 1.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 7 53 2. Status Assertion Mechanisms . . . . . . . . . . . . . . . . . 8 54 2.1. CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 55 2.1.1. Status Model" . . . . . . . . . . . . . . . . . . . 8 56 2.1.2. Revocation Reasons . . . . . . . . . . . . . . . . . 9 57 2.2. OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 58 2.2.1. CRL Responder . . . . . . . . . . . . . . . . . . . 10 59 2.2.2. Lightweight Distribution . . . . . . . . . . . . . . 10 60 2.2.3. OCSP Stapling . . . . . . . . . . . . . . . . . . . 10 61 2.3. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 11 62 2.3.1. Hardcoded/Indirect Revocation List . . . . . . . . . 11 63 2.3.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . 11 64 2.3.3. Certificate Transparency . . . . . . . . . . . . . . 11 65 3. Status Acquisition Mechanisms . . . . . . . . . . . . . . . . 11 66 3.1. Google's Status Mechanism . . . . . . . . . . . . . . . . 11 67 3.2. SCVP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.3. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 4. Cryptography Platforms . . . . . . . . . . . . . . . . . . . . 12 70 4.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 12 71 4.2. cryptlib . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.3. Microsoft Windows . . . . . . . . . . . . . . . . . . . . 12 73 4.4. Network Security Services . . . . . . . . . . . . . . . . 12 74 4.5. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 5. Web Server Status . . . . . . . . . . . . . . . . . . . . . . 12 76 5.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.2. Apache . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.3. IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.4. LiteSpeed . . . . . . . . . . . . . . . . . . . . . . . 12 80 5.5. nginx . . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 6. Web Client Status . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6.2. Chrome . . . . . . . . . . . . . . . . . . . . . . . . . 13 84 6.3. Firefox . . . . . . . . . . . . . . . . . . . . . . . . . 13 85 6.4. Internet Explorer . . . . . . . . . . . . . . . . . . . . 14 86 6.5. Opera . . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 6.6. Safari . . . . . . . . . . . . . . . . . . . . . . . . . 14 88 7. CA Status . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 7.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 15 90 7.2. CA-Browser Forum Requirements . . . . . . . . . . . . . . 15 91 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 92 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 94 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 96 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 1. Certificate Status 100 A certificate is issued with a predetermined validity interval. It is 101 common practice to specify a validity interval that starts a few 102 hours or days before the instant of issue so as to avoid rejection by 103 machines with clocks running behind the current time or otherwise 104 mis-set. In normal operation the certificate will remain valid until 105 it expires. 107 The CA that issued a certificate has primary responsibility for 108 maintaining the certificate life cycle and reporting changes to 109 certificate status. But other parties can and in some cases do report 110 status for third party certificates. In particular client and 111 platform providers have revoked certificates known to have been mis- 112 issued or in a case of a CA breach. 114 1.1. Operational Certificate Lifecycle Model 116 PKIX does not describe a certificate lifecyle model. Instead the 117 certificate lifecycle model is a consequence of the issue of PKIX 118 Certificates and CRLs. While this is sufficient for describing PKIX 119 it is not satisfactory as a reference model for describing 120 operations. Not least because modern PKIX operations are frequently 121 based on the use of OCSP rather than CRLs and differences in the 122 semantics of CRLs and OCSP are one of the features we would want to 123 measure. The distinction between an operational model and PKIX 124 semantics is illustrated by considering the difference between the 125 operational concept of direct/indirect status assertions and the PKIX 126 semantics of direct/indirect CRLs. 128 1.1.1. Direct and Indirect Status Assertions 130 PKIX CRLs may be marked as direct or indirect to indicate that they 131 are issued by the same CA that issued the original certificate (a 132 direct CRL) or by a third party (an indirect CRL). 134 In the corresponding operational model we define a direct status 135 assertion as being by the same CA that issued the original 136 certificate and an indirect status assertion as being any status 137 assertion that is not direct. 139 The difference between the operational and PKIX models has imporant 140 practical consequences. The CA that originally issued an assertion 141 naturally holds a privileged position when it comes to revoking it. A 142 direct CRL thus has a privileged position when considering the 143 question of certificate validity. A direct status assertion thus has 144 a privileged position when considering revocation status. A direct 145 CRL carries an implicit claim that it is a direct status assertion 146 but this is merely a claim unless the client validating the CRL takes 147 steps to verify it. For example by verifying that the CRL signature 148 has valid trust chain to the same trust anchor as the certificate. 150 CRLs introduce a further complication as a CRL contains a list of 151 explicit statements declaring that a certificate is invalid. In the 152 case of a direct CRL there is an implicit assertion that any issued, 153 unexpired certificate not listed was valid at the time the CRL was 154 issued. The processing rules specified in [RFC5280] appear to limit 155 this implicit assertion to direct CRLs but this is does not appear to 156 be called out in the text. 158 One of the main use cases that might motivate the issue of an 159 indirect status assertion is the case where a third party notices 160 that a certificate is being used for malicious purposes and intends 161 to advise relying parties that they should not rely on that 162 certificate. There is thus a case for granting third parties the 163 ability to revoke certificates but does granting this ability also 164 confer the ability to (implicitly) declare certificates valid? 166 [Operational question: Do clients interpret indirect CRLs as 167 substitutes for the direct CRL or as adjuncts providing additional 168 information.] 170 1.1.2. Trust Path Processing 172 One of the operational questions we would like to understand is the 173 extent to which it is possible to revoke EE certificates by revoking 174 one or more of the CSCs in the certification path. 176 Self Signed certificates used to transport Trust Anchors are not 177 actually PKIX certificates and are not governed by the PKIX model. 178 One important consequence of this is that relying parties do not use 179 PKIX mechanisms to check the validity of Trust Anchors. 181 CSCs signed by the trust anchor are potentially subject to 182 revocation. Do the status checking mechanisms employed in browsers 183 support this in practice? 185 [OCSP and CRLs raise separate issues here. In the case of an OCSP 186 responder should we require signed OCSP tokens for each cert in the 187 path? Is it possible to use a mix of CSCs and OCSP in stapled 188 tokens?] 190 1.1.3. Revocation Reasons 192 A status declarer may declare a certificate invalid (i.e. revoke the 193 certificate) before its scheduled expiry for a variety of reason that 194 include: 196 Subject requested revocation 197 The certificate subject requested revocation. 199 Subject requested correction 200 The certificate subject requested information in a certificate 201 be corrected. Such corrections are typically made by revoking 202 the original certificate and issuing a replacement. 204 Payment declined 205 A CA may issue a certificate before payment has cleared. If the 206 payment is subsequently declined, the certificate is revoked. 208 Declined extension 209 The certificate was originally issued on condition that use 210 beyond an initial period would require an additional fee which 211 the subject did not pay. 213 Terms of Use 214 The subject was determined to have breached the terms of use 216 Fraudulent Request 217 The application was determined to be fraudulent after issue 219 CA compromise 220 The certificate can no longer be trusted because the operations 221 of the CA were compromised. 223 The ability to provide a reason for revocation is defined without 224 explaining the reason a CA should provide this information or how 225 relying parties should behave differently according to the revocation 226 reason given. Revoked certificates are to be considered invalid 227 regardless of the reason for revocation. 229 PKIX does not define an order of severity. In cases where multiple 230 reasons apply, the CA may pick any. There is no obligation to report 231 a reason at all let alone report severity. 233 Once a certificate is revoked the certificate lifecycle is complete 234 as far as the CA is concerned and there is no obligation on the CA to 235 update the revocation reason after the fact to reflect the discovery 236 of a more serious cause. 238 In the case of a subject request the CA only has reliable knowledge 239 of the fact of the request and not the reason(s) the request was 240 made. A certificate subject might have requested the certificate be 241 revoked because they no further use for it or because they know the 242 associated private key has been compromised. Even if the CA asks for 243 the revocation reason there is no reason to expect the subject to 244 answer. The subject may not wish to report that a private key has 245 been compromised. 247 The net effect of these limitations is that revocation reasons only 248 provide a lower bound on the severity of the cause for which a 249 certificate was revoked. 251 1.1.4. Operational Certificate States 253 From an operational point of view, the lifecycle of a PKIX 254 certificate has five potential states: 256 Valid 257 The certificate was issued and is valid. 259 Invalid 260 No certificate was issued or the certificate issued is no 261 longer valid. Nonexistent"> The certificate does not exist. 262 This may be because the certificate has not yet been issued or 263 it will never be issued. Hold The certificate exists but has 264 been suspended with the possibility of reinstatement. Revoked 265 The certificate exists but has been declared to be invalid with 266 permanent effect. Expired The certificate existed in the past 267 but the expiry date specified at issue has passed. 269 The Hold state has been found to be of little or no practical value 270 since issuing a new certificate is simpler and more effective than 271 attempting to cancel a previous instruction to put the certificate on 272 hold. 274 CRLs and certain OCSP configurations do not permit a client to 275 distinguish between the states Valid and Invalid/Nonexistent. The CRL 276 mechanism was designed to allow a relying party to check the validity 277 of a known certificate. It was thus unnecessary to distinguish the 278 states Valid and Nonexistent as that would be verified by checking 279 the signature. Accordingly a CRL contains only a list of invalid 280 certificates. 282 In the case of a CA Breach, key compromise or cryptanalytic attack, a 283 certificate may be created that has a valid signature but was not 284 issued by the CA. Such a certificate is 'Nonexistent' as far as the 285 CA is concerned. Requiring a CA to distinguish these states in 286 reporting certificate status provides a limited degree of 287 transparency in CA operations. A CA that reports 'Nonexistent' in 288 response to a status request for an unexpired certificate that has a 289 valid signature has a defective or breached issue process. A CA that 290 reports valid in response to a status request for a non-existent 291 certificate has a defective or breached revocation mechanism. 293 1.2. Client Behavior 295 WebPKI clients are advised but not required to check certificate 296 status before relying on the assertions they contain. Waiting to 297 obtain status information from an external source before relying on a 298 certificate may cause delay or even rejection of a valid certificate. 300 Excluding the possibility that a client requests revocation status 301 then ignores the result, the options available to a Web PKI client 302 are therefore: 304 Ignore 305 The client does not process revocation status from any source 307 Local 308 The client only process revocation status that is available 309 from local sources. For example hardcoded 'do not trust' lists. 311 Soft-Fail 312 The client attempts to obtain revocation status from external 313 sources and will reject certificates reported as revoked but 314 will accept a certificate as valid if the external source does 315 not reply. 317 Hard-Fail 318 The client attempts to obtain revocation status from external 319 sources and will reject certificates unless an affirmative 320 assertion of validity is obtained. 322 2. Status Assertion Mechanisms 324 2.1. CRLs 326 The PKIX CRL mechanism for asserting certificate status is described 327 in [RFC5280] 329 2.1.1. Status Model" 331 A CRL only provides a list of certificates that have been revoked. An 332 issued, unexpired certificate is presumed to be valid if it does not 333 appear in the CRL. The certificate states supported by the CRL 334 mechanism are thus: 336 UNREVOKED 337 Corresponds to operational states Valid, Nonexistent and 338 Expired. 340 UNDETERMINED 341 Occurs when no CRL with a corresponding scope is available. 343 REVOKED" 344 Corresponds to operational state Revoked. 346 HOLD 347 Corresponds to operational state Hold. 349 The CRL result 'UNREVOKED' thus corresponds to three states in the 350 Operational model of which one is Valid and the other two are Invalid 351 states. A client that does not have a source of trusted time 352 available may use the issue time of the CRL as the basis for checking 353 expiry. The CRL mechanism does not provide a means of determining 354 that a certificate was legitimately issued 356 2.1.2. Revocation Reasons 358 [RFC5280] requires that a CRL entry specify a reason code but not the 359 circumstances in which a code should be raised. [[This is however 360 specified in X.509v3] The following reason codes are defined: 362 * unspecified 364 * keyCompromise 366 * cACompromise 368 * affiliationChanged 370 * superseded 372 * cessationOfOperation 374 * privilegeWithdrawn 376 * aACompromise 378 2.2. OCSP 380 OCSP is defined in [RFC6960]. [RFC5019] (lightweight) and TLS 381 Stapling [RFC6066] Section 8. 383 An OCSP service MAY return the following results. 385 Success [[+ CRL Status Code] 386 The OCSP status request succeeded and the service returned one 387 of the CRL status codes described above. 389 Refused 390 The OCSP responder refused to answer the request. 392 Unknown 393 The certificate for which status was requested was not found or 394 the status is not determined. 396 Invalid 397 The OCSP server returned an answer that was not understood. 399 Fail 400 The service failed to answer the request or the client was 401 unable to contact the OCSP service. 403 Note that [RFC6960] does not differentiate the results Success/Valid 404 and Unknown. CAs are however required to differentiate these 405 responses under the CABForum Basic Requirements [TBS]. 407 The OCSP protocol permits responses to be signed in advance [static] 408 or provide a proof of freshness by returning a nonce presented by the 409 client. 411 The protocol only permits static responses to report the status of 412 individual certificates. There is no feature analagous to the NSEC3 413 feature of DNSSEC which permits the non-existence of an entry in a 414 particular range to be asserted. 416 2.2.1. CRL Responder 418 An OCSP responder may generate responses from CRLs. Such a responder 419 can generate most but not all the responses required in advance by 420 generating revoked responses for all the certificates listed in the 421 CRL and valid responses for all the certificate serial numbers 422 presented in previous requests. 424 Such a responder cannot distinguish between Valid and nonexistent 425 states unless provided with additional information not in the CRL. 427 2.2.2. Lightweight Distribution 429 In the lightweight distribution mode of operation specified in 430 [RFC5019], the CA generates OCSP responses for all unexpired 431 certificates that it has issued. The signed tokens are then passed to 432 a separate network for distribution. For example, a Content Delivery 433 Network with a large number of delivery points. 435 One of the main strengths of this model is that all the signing of 436 OCSP tokens is done offline and no signing key is ever exposed to an 437 external network. One consequence of this model is that responses for 438 nonexistent certificates cannot be signed. 440 2.2.3. OCSP Stapling 442 One of the principle limitations of the traditional OCSP model is 443 that each TLS transaction becomes a three party communication. To 444 complete the TLS connection the client must communicate with the 445 server being contacted and the OCSP service. This approach introduces 446 unnecessary delay and an additional potential point of failure and is 447 therefore unsatisfactory. 449 OCSP stapling permits a TLS server to provide a client that supports 450 the stapling extension to provide the OCSP token together with the 451 certificate it corresponds to. This permits a client to establish a 452 TLS communication without the need for a three party communication in 453 the case that the client and server both support stapling. 455 The chief drawback to stapling is that support for stapling is 456 optional. thus a client that does not receive a stapled token must 457 attempt to obtain it from the OCSP service and is therefore subject 458 to the same Softfail/hardfail dilemma described above. 460 2.3. Other 462 2.3.1. Hardcoded/Indirect Revocation List 464 Most browsers employ a 'blacklist' to block certificates known to be 465 mis-issued. The number of entries supported in such lists is 466 typically small. In some cases the list is hardcoded in the browser 467 or platform code and is only updated with the browser or platform. In 468 other cases the blacklist is updatable separately. 470 Q: Which Web browsers support update of the list without updating the 471 browser. 473 2.3.2. DANE 475 DANE assertions [RFC6698] may be used to cancel a certificate. 476 [describe] 478 2.3.3. Certificate Transparency 480 CT [RFC6962] provides a means of auditing the operation of a CA using 481 only information that is available to the public. Moreover a client 482 can determine that a certificate has been issued transparently or 483 not. [describe] 485 [Allows another way to distinguish Valid and nonexistent and thus CA 486 breach.] 488 3. Status Acquisition Mechanisms 490 3.1. Google's Status Mechanism 492 (Only supported in the Chrome Browser) 494 3.2. SCVP 496 Not supported in any Web PKI application or service. 498 3.3. XKMS 500 Not supported in any Web PKI application or service. 502 4. Cryptography Platforms 504 [Should expand this noting that while support for a feature in the 505 platfor is often a necessary for support in applications, it is not 506 necessarily sufficient.] 508 4.1. Checklist 510 4.2. cryptlib 512 4.3. Microsoft Windows 514 4.4. Network Security Services 516 Used in Firefox and Chrome 518 4.5. OpenSSL 520 5. Web Server Status 522 Web Server support for revocation is fairly straightforward since the 523 Web Server is only involved in revocation in the case of stapled OCSP 524 tokens and this is supported in the latest versions of all the 525 servers surveyed. 527 5.1. Checklist 529 Support for OCSP Stapling? 531 5.2. Apache 533 Support for OCSP Stapling? 534 Since version 2.3. 536 5.3. IIS 538 Support for OCSP Stapling? 539 Yes 541 5.4. LiteSpeed 543 Support for OCSP Stapling? 544 Since version 4.2.4. 546 5.5. nginx 548 Support for OCSP Stapling? 549 Since version 1.3.7. 551 6. Web Client Status 553 [Need to consider further dimensions here. In particular Chrome 554 behaves differently depending on the platform it is on and several 555 browsers have different revocation checking for EV vs other 556 certificate policies.] 558 6.1. Checklist 560 Supported Revocation Checking Mechanisms 561 To Do: Some browsers do not support CRL DP. Others give 562 preference to OCSP, but fall back to CRL DP if the necessary 563 AIA is missing. Some browsers give priority to OCSP, but switch 564 to CRL DP when a particular issuer's revocation information is 565 retrieved frequently. 567 User Experience for Certificate Status Invalid 569 User Experience for Certificate Status Unknown 571 What sources are permitted to sign CRLs or OCSP responses for a 572 certificate, can any trusted CA sign or only the CA that issued 573 the certificate? 575 6.2. Chrome 577 The Chrome browser automatically updates itself to the latest version 578 unless this feature is explicitly disabled by the user. 580 Supported Revocation Checking Mechanisms 581 OCSP (at present). 583 User Experience for Certificate Status Invalid 585 User Experience for OCSP Fail 586 Soft fail 588 6.3. Firefox 590 Supported Revocation Checking Mechanisms 591 OCSP checked by default since Firefox 3. OCSP Stapling has been 592 added to nightly builds but is not yet in production releases. 594 User Experience for Certificate Status Invalid 596 User Experience for Certificate Status Unknown 597 Soft fail 599 6.4. Internet Explorer 601 Supported Revocation Checking Mechanisms 602 CRLs and OCSP. 604 User Experience for Certificate Status Invalid 605 IE5: If the certificate has a valid trust path, the user is 606 presented with a dialog box that says "The Security certificate 607 for this site has been revoked. This site should not be 608 trusted" 610 If however, a valid trust path cannot be found, the user 611 receives the error message for the invalid trust path instead: 612 "The user is presented with a dialogue box that tells them that 613 'Information you exchange with this site cannot be viewed or 614 changed by others. However there is a problem with the site's 615 security certificate." 617 IE??: Warning Page "There is a problem with this website's 618 security certificate" 620 CVE-2011-0199 : Chris Hawk and Wan-Teh Chang of Google MS ? ?the 621 revocation date is determined by comparing the current date with the 622 RevocationDate field in the CRL or the OCSP response? For Windows 623 Vista with Service Pack 1 and Windows Server 2008, the OCSP signing 624 certificate may chain up to any trusted root CA as long as the 625 certificate chain includes the OCSP Signing EKU extension. CryptoAPI 626 first determines whether a time valid version of the revocation 627 object exists in the CryptoAPI disk cache. 629 6.5. Opera 631 Supported Revocation Checking Mechanisms 632 OCSP checked by default since Opera version 8 634 User Experience for Certificate Status Invalid 636 User Experience for Certificate Status Unknown 637 Hard fail 639 6.6. Safari 641 Supported Revocation Checking Mechanisms 642 CRL: all, OCSP checking is enabled by default as of Mac OSX 643 10.7 (Lion). Prior to that it had to be enabled in the Keychain 644 preferences. 646 User Experience for Certificate Status Invalid 647 Dialog Box: Offers Continue/Cancel/Show Certificate 649 User Experience for Certificate Status Unknown 651 User Experience for OCSP-FAIL 653 For Apple?s OS X, OCSP and CRL checking can be configured via 654 Keychain Access -> Preferences ?> Certificates. A dialog box opens 655 with three rows: OCSP, CRL, and Priority. Under OCSP and CRL, the 656 three allowed options (a grayed-out one said something like ?always?) 657 were: ?Off?, ?Best Attempt?, and ?Required if certificate indicates?. 658 ?Best Attempt? was the default. Under Priority, the options were 659 ?OCSP? ?CRL? and ?Require both?. ?OCSP? was the default. 661 IE5: Popup dialog box: "Revocation information for the security 662 certificate for this site is not available. Do you want to proceed?" 664 7. CA Status 666 Historical behavior is only of interest to the extent that it affects 667 current operations. 669 Every PKIX certificate has a built in expiry date. Thus we are only 670 interested in CA operations from the date at which their oldest 671 unexpired certificate is still valid. 673 7.1. Checklist 675 Are CRLs or OCSP supported 677 Is the CDP extension filled? 679 Is the AIA extension filled? 681 7.2. CA-Browser Forum Requirements 683 8. Security Considerations 685 Put something here? 687 9. IANA Considerations 689 None 691 10. References 693 10.1. Normative References 695 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 696 Extension Definitions", RFC 6066, January 2011. 698 [RFC6698] Hoffman, P.,Schlyter, J., "The DNS_Based Authentication of 699 Named Entities (DANE) Transport Layer Security (TLS) 700 Protocol: TLSA", RFC 6698, August 2012. 702 [RFC6962] Laurie, B.,Langley, A.,Kasper, E., "Certificate 703 Transparency", RFC 6962, June 2013. 705 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 706 R.,Polk, W., "Internet X.509 Public Key Infrastructure 707 Certificate and Certificate Revocation List (CRL) 708 Profile", RFC 5280, May 2008. 710 [RFC6960] Santesson, S.,Myers, M.,Ankney, R.,Malpani, A.,Galperin, 711 S.,Adams, C., "X.509 Internet Public Key Infrastructure 712 Online Certificate Status Protocol - OCSP", RFC 6960, June 713 2013. 715 [RFC5019] Deacon, A.,Hurst, R., "The Lightweight Online Certificate 716 Status Protocol (OCSP) Profile for High-Volume 717 Environments", RFC 5019, September 2007. 719 Author's Address 721 Phillip Hallam-Baker 722 Comodo Group Inc. 724 philliph@comodo.com