idnits 2.17.1 draft-wpkops-revocation-00.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 399: '... 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 (May 12, 2014) is 3637 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 430, 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 David Chadwick 4 Expires: November 13, 2014 University of Kent 5 May 12, 2014 7 Web PKI Operations: Revocation and Status 8 draft-wpkops-revocation-00 10 Abstract 12 This document describes the certificate status mechanisms supported 13 in the Web PKI 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 Copyright Notice 32 Copyright (c) 2014 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the Simplified BSD License. 45 Table of Contents 47 1. Certificate Status . . . . . . . . . . . . . . . . . . . . . . 4 48 1.1. Operational Certificate Lifecycle Model . . . . . . . . . 4 49 1.1.1. Direct and Indirect Status Assertions . . . . . . . 4 50 1.1.2. Trust Path Processing . . . . . . . . . . . . . . . 5 51 1.1.3. Revocation Reasons . . . . . . . . . . . . . . . . . 5 52 1.1.4. Operational Certificate States . . . . . . . . . . . 7 53 1.2. Client Behavior . . . . . . . . . . . . . . . . . . . . . 8 54 2. Status Assertion Mechanisms . . . . . . . . . . . . . . . . . 8 55 2.1. CRLs . . . . . . . . . . . . . . . . . . . . . . . . . . 8 56 2.1.1. Status Model" . . . . . . . . . . . . . . . . . . . 8 57 2.1.2. Revocation Reasons . . . . . . . . . . . . . . . . . 9 58 2.2. OCSP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 59 2.2.1. CRL Responder . . . . . . . . . . . . . . . . . . . 10 60 2.2.2. Lightweight Distribution . . . . . . . . . . . . . . 11 61 2.2.3. OCSP Stapling . . . . . . . . . . . . . . . . . . . 11 62 2.3. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 11 63 2.3.1. Hardcoded/Indirect Revocation List . . . . . . . . . 11 64 2.3.2. DANE . . . . . . . . . . . . . . . . . . . . . . . . 11 65 2.3.3. Certificate Transparency . . . . . . . . . . . . . . 12 66 3. Status Acquisition Mechanisms . . . . . . . . . . . . . . . . 12 67 3.1. CRLSets . . . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.2. SCVP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.3. XKMS . . . . . . . . . . . . . . . . . . . . . . . . . . 13 70 4. Cryptography Platforms (to be completed once the survey is 71 finished) . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 4.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 13 73 4.2. cryptlib . . . . . . . . . . . . . . . . . . . . . . . . 13 74 4.3. Microsoft Windows . . . . . . . . . . . . . . . . . . . . 13 75 4.4. Network Security Services . . . . . . . . . . . . . . . . 13 76 4.5. OpenSSL . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5. Web Server Status (TBC once the survey is finished) . . . . . 13 78 5.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 13 79 5.2. Apache . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.3. IIS . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 5.4. LiteSpeed . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.5. nginx . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6. Web Client Status (TBC once the survey is finished) . . . . . 14 84 6.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 14 85 6.2. Chrome . . . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.3. Firefox . . . . . . . . . . . . . . . . . . . . . . . . . 14 87 6.4. Internet Explorer . . . . . . . . . . . . . . . . . . . . 15 88 6.5. Opera . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 6.6. Safari . . . . . . . . . . . . . . . . . . . . . . . . . 15 90 7. CA Status . . . . . . . . . . . . . . . . . . . . . . . . . . 16 91 7.1. Checklist . . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.2. CA-Browser Forum Requirements . . . . . . . . . . . . . . 16 93 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 94 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 95 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 10.1. Normative References . . . . . . . . . . . . . . . . . . 16 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 99 1. Certificate Status 101 A certificate is issued with a predetermined validity interval. It is 102 common practice to specify a validity interval that starts a few 103 hours or days before the instant of issue so as to avoid rejection by 104 machines with clocks running behind the current time or otherwise 105 mis-set. In normal operation the certificate will remain valid until 106 it expires. 108 The CA that issued a certificate has primary responsibility for 109 maintaining the certificate life cycle and reporting changes to 110 certificate status. But other parties can and in some cases do report 111 status for third party certificates. In particular client and 112 platform providers have revoked certificates known to have been mis- 113 issued or in a case of a CA breach. 115 [Introduce CRL Sets here, once I find a citation] 117 1.1. Operational Certificate Lifecycle Model 119 PKIX does not describe a certificate lifecyle model. Instead the 120 certificate lifecycle model is a consequence of the issue of PKIX 121 Certificates and CRLs. While this is sufficient for describing PKIX 122 it is not satisfactory as a reference model for describing 123 operations. Not least because modern PKIX operations are frequently 124 based on the use of OCSP rather than CRLs and differences in the 125 semantics of CRLs and OCSP are one of the features we would want to 126 measure. The distinction between an operational model and PKIX 127 semantics is illustrated by considering the difference between the 128 operational concept of direct/indirect status assertions and the PKIX 129 semantics of direct/indirect CRLs. 131 1.1.1. Direct and Indirect Status Assertions 133 PKIX CRLs may be marked as direct or indirect to indicate that they 134 are issued by the same CA that issued the original certificate (a 135 direct CRL) or by a third party (an indirect CRL). 137 In the corresponding operational model we define a direct status 138 assertion as being by the same CA that issued the original 139 certificate and an indirect status assertion as being any status 140 assertion that is not direct. 142 The difference between the operational and PKIX models has important 143 practical consequences. The CA that originally issued an assertion 144 naturally holds a privileged position when it comes to revoking it. A 145 direct CRL thus has a privileged position when considering the 146 question of certificate validity. A direct status assertion thus has 147 a privileged position when considering revocation status. A direct 148 CRL carries an implicit claim that it is a direct status assertion 149 but this is merely a claim unless the client validating the CRL takes 150 steps to verify it. For example by verifying that the CRL signature 151 has valid trust chain to the same trust anchor as the certificate. 153 CRLs introduce a further complication as a CRL contains a list of 154 explicit statements declaring that a certificate is invalid. In the 155 case of a direct CRL there is an implicit assertion that any issued, 156 unexpired certificate not listed was valid at the time the CRL was 157 issued. The processing rules specified in [RFC5280] appear to limit 158 this implicit assertion to direct CRLs but this does not appear to be 159 called out in the text. 161 One of the main use cases that might motivate the issue of an 162 indirect status assertion is the case where a third party notices 163 that a certificate is being used for malicious purposes and intends 164 to advise relying parties that they should not trust the certificate 165 subject. Since it is the behavior of the subject rather than their 166 identity that is at issue, there may not be sufficient reason for the 167 CA to revoke the certificate. There is thus a case for parties other 168 than the certificate subject and issuer having the ability to revoke 169 certificates in certain circumstances. But does granting this ability 170 also confer the ability to (implicitly) declare certificates valid? 172 [Operational question: Do clients interpret indirect CRLs as 173 substitutes for the direct CRL or as adjuncts providing additional 174 information.] 176 1.1.2. Trust Path Processing 178 One of the operational questions we would like to understand is the 179 extent to which it is possible to revoke EE certificates by revoking 180 one or more of the Certificate Signing Certificates in the 181 certification path. 183 Self Signed certificates used to transport Trust Anchors are not 184 actually PKIX certificates and are not governed by the PKIX model 185 (although they are X.509v3 certificates). One important consequence 186 of this is that relying parties do not use PKIX mechanisms to check 187 the validity of Trust Anchors. 189 CSCs signed by the trust anchor are potentially subject to 190 revocation. Do the status checking mechanisms employed in browsers 191 support this in practice? 193 [OCSP and CRLs raise separate issues here. In the case of an OCSP 194 responder should we require signed OCSP tokens for each cert in the 195 path? Is it possible to use a mix of CSCs and OCSP in stapled 196 tokens?] 198 1.1.3. Revocation Reasons 200 A status declarer may declare a certificate invalid (i.e. revoke the 201 certificate) before its scheduled expiry for a variety of reason that 202 include: 204 Subject requested revocation 205 The certificate subject requested revocation. 207 Subject requested correction 208 The certificate subject requested information in a certificate 209 be corrected either because the original information is wrong 210 or circumstances have changed. For example the subject's 211 affiliation has changed. Such corrections are typically made by 212 revoking the original certificate and issuing a replacement. 214 Payment declined 215 A CA may issue a certificate before payment has cleared. If the 216 payment is subsequently declined, the certificate is revoked. 218 Declined extension 219 The certificate was originally issued on condition that use 220 beyond an initial period would require an additional fee which 221 the subject did not pay. 223 Terms of Use 224 The subject was determined to have breached the terms of use 226 Fraudulent Request 227 The application was determined to be fraudulent after issue 229 CA compromise 230 The certificate can no longer be trusted because the operations 231 of the CA were compromised. 233 The ability to provide a reason for revocation is defined, without 234 explaining why a CA should provide this information or how relying 235 parties should behave differently according to the revocation reason 236 given. Revoked certificates are to be considered invalid regardless 237 of the reason for revocation. 239 PKIX does not define an order of severity. In cases where multiple 240 reasons apply, the CA may pick any. There is no obligation to report 241 a reason at all let alone report severity. 243 Once a certificate is revoked the certificate lifecycle is complete 244 as far as the CA is concerned and there is no obligation on the CA to 245 update the revocation reason after the fact to reflect the discovery 246 of a more serious cause. 248 In the case of a subject request the CA only has reliable knowledge 249 of the fact of the request and not the reason(s) the request was 250 made. A certificate subject might have requested the certificate be 251 revoked because they have no further use for it or because they know 252 the associated private key has been compromised. Even if the CA asks 253 for the revocation reason there is no reason to expect the subject to 254 answer. The subject may not wish to report that a private key has 255 been compromised. 257 The net effect of these limitations is that revocation reasons only 258 provide a lower bound on the severity of the cause for which a 259 certificate was revoked. 261 1.1.4. Operational Certificate States 263 From an operational point of view, once issued, a PKIX certificate 264 has five potential states, a single valid state and four invalid 265 states: 267 Nonexistent 268 The certificate does not exist. This may be because the 269 certificate has not yet been issued or it will never be issued. 271 Valid 272 The certificate was issued and is valid. 274 Invalid 275 No certificate was issued or the certificate issued is no 276 longer valid. Hold The certificate exists but has been 277 suspended with the possibility of reinstatement. Revoked The 278 certificate exists but has been declared to be invalid with 279 permanent effect. Expired The certificate existed in the past 280 but the expiry date specified at issue has passed. 282 The Hold state has been found to be of little or no practical value 283 since issuing a new certificate is simpler and more effective than 284 attempting to cancel a previous instruction to put the certificate on 285 hold. 287 CRLs and certain OCSP configurations do not permit a client to 288 distinguish between the states Valid and Invalid/Nonexistent. The CRL 289 mechanism was designed to allow a relying party to check the validity 290 of a known certificate. It was thus unnecessary to distinguish the 291 states Valid and Nonexistent as that would be verified by checking 292 the signature. Accordingly a CRL contains only a list of invalid 293 certificates. 295 In the case of a CA Breach, key compromise or cryptanalytic attack, a 296 certificate may be created that has a valid signature but was not 297 issued by the CA. Such a certificate is 'Nonexistent' as far as the 298 CA is concerned. Requiring a CA to distinguish these states in 299 reporting certificate status provides a limited degree of 300 transparency in CA operations. A CA that reports 'Nonexistent' in 301 response to a status request for an unexpired certificate that has a 302 valid signature has a defective or breached issue process. A CA that 303 reports valid in response to a status request for a non-existent 304 certificate has a defective or breached revocation mechanism. 306 1.2. Client Behavior 308 WebPKI clients are advised but not required to check certificate 309 status before relying on the assertions they contain. Waiting to 310 obtain status information from an external source before relying on a 311 certificate may cause delay or even rejection of a valid certificate. 313 Excluding the possibility that a client requests revocation status 314 then ignores the result, the options available to a Web PKI client 315 are therefore: 317 Ignore 318 The client does not process revocation status from any source 320 Local 321 The client only process revocation status that is available 322 from local sources. For example hardcoded 'do not trust' lists 323 or CRLSets. 325 Soft-Fail 326 The client attempts to obtain revocation status from external 327 sources and will reject certificates reported as revoked but 328 will accept a certificate as valid if the external source 329 cannot be contacted, does not reply or rejects the request, 330 etc. 332 Hard-Fail 333 The client attempts to obtain revocation status from external 334 sources and will reject certificates unless either an 335 affirmative assertion of validity or an affirmative assertion 336 of not revoked is obtained. 338 2. Status Assertion Mechanisms 340 2.1. CRLs 342 The PKIX CRL mechanism for asserting certificate status is described 343 in [RFC5280] 345 2.1.1. Status Model" 347 A CRL only provides a list of certificates that have been revoked. An 348 issued, unexpired certificate is presumed to be valid if it does not 349 appear in the CRL. The certificate states supported by the CRL 350 mechanism are thus: 352 UNREVOKED 353 Corresponds to operational states Valid, Nonexistent and 354 Expired. 356 UNDETERMINED 357 Occurs when no CRL with a corresponding scope is available. 359 REVOKED 360 Corresponds to operational state Revoked. 362 HOLD 363 Corresponds to operational state Hold. 365 The CRL result 'UNREVOKED' thus corresponds to three states in the 366 Operational model of which one is Valid and the other two are Invalid 367 states. A client that does not have a source of trusted time 368 available may use the issue time of the CRL as the basis for checking 369 expiry. The CRL mechanism does not provide a means of determining 370 that a certificate was legitimately issued 372 2.1.2. Revocation Reasons 374 [RFC5280] requires that a CRL entry specify a reason code but not the 375 circumstances in which a code should be raised. [[This is however 376 specified in X.509v3] The following reason codes are defined: 378 * unspecified 380 * keyCompromise 382 * cACompromise 384 * affiliationChanged 386 * superseded 388 * cessationOfOperation 390 * privilegeWithdrawn 392 * aACompromise 394 2.2. OCSP 396 OCSP is defined in [RFC6960]. [RFC5019] (lightweight) and TLS 397 Stapling [RFC6066] Section 8. 399 An OCSP service MAY return the following responses to a request: 401 Success [[+ CRL Status Code] 402 The OCSP status request succeeded and the service returned one 403 of the CRL status codes described above. 405 Refused 406 The OCSP responder refused to answer the request. 408 Unknown 409 The certificate for which status was requested was not found or 410 the status is not determined. 412 Invalid 413 The OCSP server returned an answer that was not understood. 415 Fail 416 The service failed to answer the request or the client was 417 unable to contact the OCSP service. 419 The OCSP response reflects the success or failure of the OCSP 420 transaction rather than the status of the certificate being queried. 421 Thus a client whose behavior is Soft-Fail will only reject a 422 certificate if the OCSP response Success and an Invalid certificate 423 status is returned. Thus an OCSP server that responds to a request 424 for status for a certificate that is known to have never been issued 425 with 'Invalid' will cause soft-fail clients to accept the 426 certificate. 428 Note that [RFC6960] does not differentiate the results Success/Valid 429 and Unknown. CAs are however required to differentiate these 430 responses under the CABForum Basic Requirements [TBS]. 432 The OCSP protocol permits responses to be signed in advance [static] 433 or provide a proof of freshness by returning a nonce presented by the 434 client. 436 The protocol only permits static responses to report the status of 437 individual certificates. There is no feature analagous to the NSEC3 438 feature of DNSSEC which permits the non-existence of an entry in a 439 particular range to be asserted. 441 2.2.1. CRL Responder 443 An OCSP responder may generate responses from CRLs. Such a responder 444 can generate most but not all the responses required in advance by 445 generating revoked responses for all the certificates listed in the 446 CRL and valid responses for all the certificate serial numbers 447 presented in previous requests. 449 Such a responder cannot distinguish between Valid and nonexistent 450 states unless provided with additional information not in the CRL. 452 2.2.2. Lightweight Distribution 454 In the lightweight distribution mode of operation specified in 455 [RFC5019], the CA generates OCSP responses for all unexpired 456 certificates that it has issued. The signed tokens are then passed to 457 a separate network for distribution. For example, a Content Delivery 458 Network with a large number of delivery points. 460 One of the main strengths of this model is that all the signing of 461 OCSP tokens is done offline and no signing key is ever exposed to an 462 external network. One consequence of this model is that responses for 463 nonexistent certificates cannot be signed. 465 2.2.3. OCSP Stapling 467 One of the principle limitations of the traditional OCSP model is 468 that each TLS transaction becomes a three party communication. To 469 complete the TLS connection the client must communicate with the 470 server being contacted and the OCSP service. This approach introduces 471 unnecessary delay and an additional potential point of failure and is 472 therefore unsatisfactory. 474 OCSP stapling permits a TLS server to provide a client that supports 475 the stapling extension to provide the OCSP token together with the 476 certificate it corresponds to. This permits a client to establish a 477 TLS communication without the need for a three party communication in 478 the case that the client and server both support stapling. 480 The chief drawback to stapling is that support for stapling is 481 optional. thus a client that does not receive a stapled token must 482 attempt to obtain it from the OCSP service and is therefore subject 483 to the same Softfail/hardfail dilemma described above. 485 2.3. Other 487 2.3.1. Hardcoded/Indirect Revocation List 489 Most browsers employ a 'blacklist' to block certificates known to be 490 mis-issued. The number of entries supported in such lists is 491 typically small. In some cases the list is hardcoded in the browser 492 or platform code and is only updated with the browser or platform. In 493 other cases the blacklist is updatable separately. 495 Q: Which Web browsers support update of the list without updating the 496 browser. 498 2.3.2. DANE 500 DANE assertions [RFC6698] may be used to cancel a certificate. 501 [describe] 503 2.3.3. Certificate Transparency 505 CT [RFC6962] provides a means of auditing the operation of a CA using 506 only information that is available to the public from log servers. 507 Moreover a client can determine that a certificate has been issued 508 transparently (i.e. is in the log) or not. Any certificate the client 509 receives that is not in the log should be treated as suspicious or 510 invalid by the client. 512 In order for CT to work, a CA registers a certificate in a log server 513 and is returned a signed time stamp by the log server. This signed 514 time stamp must be given to the certificate subject, and it must send 515 this to RPs along with its certificate. This requires the TLS 516 handshake to be enhanced to pass the signed time stamp, and clients 517 and servers to be enhanced to receive and send it. This will take 518 time to be rolled out to the entire Internet, so CT is not a short 519 term solution. 521 Monitor servers regularly scan the logs to look for suspicious or 522 unauthorised certificates that have been deposited there. 524 One potential problem with CT is that it is not described how the 525 monitors will operate and determine whether a certificate is 526 suspicious or unauthorised. How will they know if a certificate is 527 suspicious or not? How will clients be notified of this? What does 528 suspicious actually mean to a client? How should a client behave when 529 it is told that a certificate is dodgy by a monitor? Who arbitrates 530 on this if there is a disagreement between monitors or monitors and a 531 CA? Is it the issuing CA? If so, this will not stop a compelled 532 certificate creation attack since it is the subject that has to say 533 which certificate is false and which is not, since both were issued 534 by the same CA or its subordinate. 536 3. Status Acquisition Mechanisms 538 3.1. CRLSets 540 [Working on getting a citable description] 542 (Only supported in the Chrome Browser) 544 3.2. SCVP 546 Not supported in any Web PKI application or service. 548 3.3. XKMS 550 Not supported in any Web PKI application or service. 552 4. Cryptography Platforms (to be completed once the survey is finished) 554 [Should expand this noting that while support for a feature in the 555 platfor is often a necessary for support in applications, it is not 556 necessarily sufficient.] 558 4.1. Checklist 560 4.2. cryptlib 562 4.3. Microsoft Windows 564 4.4. Network Security Services 566 Used in Firefox and Chrome 568 4.5. OpenSSL 570 5. Web Server Status (TBC once the survey is finished) 572 Web Server support for revocation is fairly straightforward since the 573 Web Server is only involved in revocation in the case of stapled OCSP 574 tokens and this is supported in the latest versions of all the 575 servers surveyed. 577 5.1. Checklist 579 Support for OCSP Stapling? 581 5.2. Apache 583 Support for OCSP Stapling? 584 Since version 2.3. 586 5.3. IIS 588 Support for OCSP Stapling? 589 Yes 591 5.4. LiteSpeed 593 Support for OCSP Stapling? 594 Since version 4.2.4. 596 5.5. nginx 598 Support for OCSP Stapling? 599 Since version 1.3.7. 601 6. Web Client Status (TBC once the survey is finished) 603 [Need to consider further dimensions here. In particular Chrome 604 behaves differently depending on the platform it is on and several 605 browsers have different revocation checking for EV vs other 606 certificate policies.] 608 6.1. Checklist 610 Supported Revocation Checking Mechanisms 611 To Do: Some browsers do not support CRL DP. Others give 612 preference to OCSP, but fall back to CRL DP if the necessary 613 AIA is missing. Some browsers give priority to OCSP, but switch 614 to CRL DP when a particular issuer's revocation information is 615 retrieved frequently. 617 User Experience for Certificate Status Invalid 619 User Experience for Certificate Status Unknown 621 What sources are permitted to sign CRLs or OCSP responses for a 622 certificate, can any trusted CA sign or only the CA that issued 623 the certificate? 625 6.2. Chrome 627 The Chrome browser automatically updates itself to the latest version 628 unless this feature is explicitly disabled by the user. 630 Supported Revocation Checking Mechanisms 631 OCSP (at present). 633 User Experience for Certificate Status Invalid 635 User Experience for OCSP Fail 636 Soft fail 638 6.3. Firefox 640 Supported Revocation Checking Mechanisms 641 OCSP checked by default since Firefox 3. OCSP Stapling has been 642 added to nightly builds but is not yet in production releases. 644 User Experience for Certificate Status Invalid 646 User Experience for Certificate Status Unknown 647 Soft fail 649 6.4. Internet Explorer 651 Supported Revocation Checking Mechanisms 652 CRLs and OCSP. 654 User Experience for Certificate Status Invalid 655 IE5: If the certificate has a valid trust path, the user is 656 presented with a dialog box that says "The Security certificate 657 for this site has been revoked. This site should not be 658 trusted" 660 If however, a valid trust path cannot be found, the user 661 receives the error message for the invalid trust path instead: 662 "The user is presented with a dialogue box that tells them that 663 'Information you exchange with this site cannot be viewed or 664 changed by others. However there is a problem with the site's 665 security certificate." 667 IE??: Warning Page "There is a problem with this website's 668 security certificate" 670 CVE-2011-0199 : Chris Hawk and Wan-Teh Chang of Google MS ? ?the 671 revocation date is determined by comparing the current date with the 672 RevocationDate field in the CRL or the OCSP response? For Windows 673 Vista with Service Pack 1 and Windows Server 2008, the OCSP signing 674 certificate may chain up to any trusted root CA as long as the 675 certificate chain includes the OCSP Signing EKU extension. CryptoAPI 676 first determines whether a time valid version of the revocation 677 object exists in the CryptoAPI disk cache. 679 6.5. Opera 681 Supported Revocation Checking Mechanisms 682 OCSP checked by default since Opera version 8 684 User Experience for Certificate Status Invalid 686 User Experience for Certificate Status Unknown 687 Hard fail 689 6.6. Safari 691 Supported Revocation Checking Mechanisms 692 CRL: all, OCSP checking is enabled by default as of Mac OSX 693 10.7 (Lion). Prior to that it had to be enabled in the Keychain 694 preferences. 696 User Experience for Certificate Status Invalid 697 Dialog Box: Offers Continue/Cancel/Show Certificate 699 User Experience for Certificate Status Unknown 701 User Experience for OCSP-FAIL 703 For Apple?s OS X, OCSP and CRL checking can be configured via 704 Keychain Access -> Preferences ?> Certificates. A dialog box opens 705 with three rows: OCSP, CRL, and Priority. Under OCSP and CRL, the 706 three allowed options (a grayed-out one said something like ?always?) 707 were: ?Off?, ?Best Attempt?, and ?Required if certificate indicates?. 708 ?Best Attempt? was the default. Under Priority, the options were 709 ?OCSP? ?CRL? and ?Require both?. ?OCSP? was the default. 711 IE5: Popup dialog box: "Revocation information for the security 712 certificate for this site is not available. Do you want to proceed?" 714 7. CA Status 716 Historical behavior is only of interest to the extent that it affects 717 current operations. 719 Every PKIX certificate has a built in expiry date. Thus we are only 720 interested in CA operations from the date at which their oldest 721 unexpired certificate is still valid. 723 7.1. Checklist 725 Are CRLs or OCSP supported 727 Is the CDP extension filled? 729 Is the AIA extension filled? 731 7.2. CA-Browser Forum Requirements 733 8. Security Considerations 735 Put something here? 737 9. IANA Considerations 739 None 741 10. References 743 10.1. Normative References 745 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 746 Extension Definitions", RFC 6066, January 2011. 748 [RFC6698] Hoffman, P.,Schlyter, J., "The DNS-Based Authentication of 749 Named Entities (DANE) Transport Layer Security (TLS) 750 Protocol: TLSA", RFC 6698, August 2012. 752 [RFC6962] Laurie, B.,Langley, A.,Kasper, E., "Certificate 753 Transparency", RFC 6962, June 2013. 755 [RFC5280] Cooper, D.,Santesson, S.,Farrell, S.,Boeyen, S.,Housley, 756 R.,Polk, W., "Internet X.509 Public Key Infrastructure 757 Certificate and Certificate Revocation List (CRL) 758 Profile", RFC 5280, May 2008. 760 [RFC6960] Santesson, S.,Myers, M.,Ankney, R.,Malpani, A.,Galperin, 761 S.,Adams, C., "X.509 Internet Public Key Infrastructure 762 Online Certificate Status Protocol - OCSP", RFC 6960, June 763 2013. 765 [RFC5019] Deacon, A.,Hurst, R., "The Lightweight Online Certificate 766 Status Protocol (OCSP) Profile for High-Volume 767 Environments", RFC 5019, September 2007. 769 Authors' Addresses 771 Phillip Hallam-Baker 772 Comodo Group Inc. 774 philliph@comodo.com 776 David Chadwick 777 University of Kent 779 d.w.chadwick@kent.ac.uk