idnits 2.17.1 draft-iab-web-pki-problems-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 9, 2015) is 3054 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2560' is mentioned on line 120, but not defined ** Obsolete undefined reference: RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6844 (Obsoleted by RFC 8659) -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) == Outdated reference: A later version (-02) exists of draft-shore-tls-dnssec-chain-extension-01 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Architecture Board R. Housley 3 Internet-Draft Vigil Security 4 Intended status: Informational K. O'Donoghue 5 Expires: June 11, 2016 Internet Society 6 December 9, 2015 8 Problems with the Public Key Infrastructure (PKI) for the World Wide Web 9 draft-iab-web-pki-problems-00.txt 11 Abstract 13 This document describes the technical and non-technical problems with 14 the current Public Key Infrastructure (PKI) used for the World Wide 15 Web. Some potential technical improvements are considered, and some 16 non-technical approaches to improvements are discussed. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on June 11, 2016. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Very Brief Description of the Web PKI . . . . . . . . . . . . 3 54 3. Technical Improvements to the Web PKI . . . . . . . . . . . . 3 55 3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 4 56 3.2. Certificate Status Checking . . . . . . . . . . . . . . . 4 57 3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 5 58 3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 5 59 3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 5 60 3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 6 61 3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 7 62 3.3.1. Certificate Authority Authorization (CAA) . . . . . . 8 63 3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 8 64 3.3.3. HTTP Strict Transport Security (HSTS) . . . . . . . . 9 65 3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 9 66 3.3.5. Certificate Transparency . . . . . . . . . . . . . . 10 67 3.4. Automation for Server Administrators . . . . . . . . . . 11 68 4. Policy and Process Improvements to the Web PKI . . . . . . . 11 69 4.1. Determination of the Trusted Certificate Authorities . . 11 70 4.2. Governance Structures for the Web PKI . . . . . . . . . . 13 71 5. Challenges for Improving the Web PKI . . . . . . . . . . . . 13 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 73 6.1. Browser Error Messages . . . . . . . . . . . . . . . . . 14 74 6.2. Time Synchronization . . . . . . . . . . . . . . . . . . 14 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 77 8.1. Normative References . . . . . . . . . . . . . . . . . . 15 78 8.2. Informative References . . . . . . . . . . . . . . . . . 15 79 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 80 Appendix B. IAB Members at the Time of Approval . . . . . . . . 18 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 There are many technical and non-technical problems with the current 86 Public Key Infrastructure (PKI) used for the World Wide Web. This 87 document describes these problems, considers some potential technical 88 improvements, and discusses some non-technical approaches to 89 improvements. 91 The Web PKI makes use of certificates as described in RFC 5280 92 [RFC5280]. These certificates are primarily used with Transport 93 Layer Security (TLS) RFC 5246 [RFC5246]. 95 2. Very Brief Description of the Web PKI 97 Certificates are specified in RFC 5280 [RFC5280]. Certificates 98 contain, among other things, a subject name and a public key, and 99 they are digitally signed by the Certification Authority (CA). 100 Certificate users require confidence that the private key associated 101 with the certified public key is owned by the named subject. A 102 certificate has a limited valid lifetime. 104 The architectural model used in the Web PKI includes: 106 EE: End Entity -- the subject of a certificate -- certificates are 107 issued to Web Servers, and certificates are also issued to 108 clients that need mutual authentication. 110 CA: Certification Authority -- the issuer of a certificate -- 111 issues certificates for Web Servers and clients. 113 RA: Registration Authority -- an optional system to which a CA 114 delegates some management functions such as identity validation 115 or physical credential distribution. 117 CAs are responsible for indicating the revocation status of the 118 certificates that they issue throughout the lifetime of the 119 certificate. Revocation status information may be provided using the 120 Online Certificate Status Protocol (OCSP) [RFC2560], certificate 121 revocation lists (CRLs) [RFC5280], or some other mechanism. In 122 general, when revocation status information is provided using CRLs, 123 the CA is also the CRL issuer. However, a CA may delegate the 124 responsibility for issuing CRLs to a different entity. 126 The enrollment process used by a CA makes sure that the subject name 127 in the certificate is appropriate and that the subject actually holds 128 the private key. Proof of possession of the private key is often 129 accomplished through a challenge-response protocol. 131 3. Technical Improvements to the Web PKI 133 Over the years, many technical improvements have been made to the Web 134 PKI. This section discusses several problems and the technical 135 problems that have been made to address them. This history sets the 136 stage for suggestions for additional improvements in other sections 137 of this document. 139 3.1. Weak Cryptographic Algorithms or Short Public Keys 141 Over the years, the digital signature algorithms, one-way hash 142 functions, and public key sizes that are considered strong have 143 changed. This is not a surprise. Cryptographic algorithms age; they 144 become weaker with time. As new cryptanalysis techniques are 145 developed and computing capabilities improve, the work factor to 146 break a particular cryptographic algorithm will reduce. For this 147 reason, the algorithms and key sizes used in the Web PKI need to 148 migrate over time. A reasonable choice of algorithm or key size 149 needs to be evaluated periodically, and a transition may be needed 150 before the expected lifetime expires. 152 The browser vendors have been trying to manage algorithm and key size 153 transitions, but a long-lived trust anchor or intermediate CA 154 certificate can have a huge number of subordinate certificates. So, 155 removing a one because it uses a weak cryptographic algorithm or a 156 short public key can have a significant impact. 158 As a result, some valid trust anchors and certificates contain 159 cryptographic algorithms after weakness has been discovered and 160 widely known. Similarly, valid trust anchors and certificates 161 contain public keys after computational resources available to 162 attackers have rendered them too weak. We have seen a very 163 successful migration away from certificates that use the MD2 or MD5 164 one-way hash functions. However, there are still a great number of 165 certificates that use SHA-1 and 1024-bit RSA public keys, and these 166 should be replaced. 168 Today, the algorithms and key sizes used by a CA to sign certificates 169 with a traditional lifespan should offer 112 to 128 bits of security. 170 SHA-256 is a widely studied one-way hash function that meets this 171 requirement. RSA with a public key of at least 2048 bits or ECDSA 172 with a public key of at least 256 bits are widely studied digital 173 signature algorithms that meet this requirement. 175 3.2. Certificate Status Checking 177 Several years ago, many browsers do not perform certificate status 178 checks by default. That is, browsers did not check whether the 179 issuing CA has revoked the certificate unless the user explicitly 180 adjusted a setting to enable this feature. This check can be made by 181 fetching the most recent certificate revocation list (CRL) RFC 5280 182 [RFC5280], or this check can use the Online Certificate Status 183 Protocol (OCSP) RFC 6960 [RFC6960]. The location of the CRL or the 184 OCSP responder is usually found in the certificate itself. Either 185 one of these approaches add latency. The desire to provide a snappy 186 user experience is a significant reason that this feature has not 187 turned on by default. Mobile browsers simply do not bother to check 188 revocation status [IMC2015]. 190 Certificate status checking needs to be used at all times. Several 191 techniques have been tried by CAs and browsers to make certificate 192 status checking more efficient. Many CAs are using of Content 193 Delivery Networks (CDNs) to deliver CRLs and OCSP responses, 194 resulting in very high availability and low latency. Yet, browser 195 vendors are still reluctant to perform standard-based status checking 196 by default for every session. 198 Measurements in 2015 [IMC2015] show that a surprisingly large 199 fraction of Web PKI certicates have been revoked, and browsers are 200 not obtaining current certificate revocation information because it 201 is too expensive in terms of latency and bandwidth. 203 3.2.1. Short-lived Certificates 205 Short-lived certificates are an excellent way to reduce the need for 206 certificate status checking. The shorter the life of the 207 certificate, the less time there is for anything to go wrong. If the 208 lifetime is short enough, policy might allow certificate status 209 checking can be skipped altogether. In practice, implementation of 210 short-lived certificates requires automation to assist web server 211 administrators, which is a topic that is discussed elsewhere in this 212 document. 214 3.2.2. CRL Distribution Points 216 The certificate revocation list distribution point (CRLDP) 217 certificate extension RFC 5280 [RFC5280] allows a CA to control the 218 maximum size of the CRLs that they issue. This helps in two ways. 219 First, the amount of storage needed by the browser to cache CRLs is 220 reduced. Second, and more importantly, the amount of time it takes 221 to download a CRL can be scoped, so that the amount of time needed to 222 fetch any single CRL is reasonable. 224 Few CAs take advantage of the CRLDP certificate extension to limit 225 the size of CRLs. In fact, there are several CAs that publish 226 extremely large CRLs. Browsers never want to suffer the latency 227 associated with large CRLs, and some ignore the CRLDP extension when 228 it is present. Browsers tend to avoid the use of CRLs altogether. 230 3.2.3. Proprietary Revocation Checks 232 Some browser vendors provide a proprietary mechanism for revocation 233 checking. These mechanisms obtain revocation status information once 234 per day for the entire Web PKI in a very compact form. No network 235 traffic is generated at the time that a certificate is being 236 validated, so there is no latency associated with revocation status 237 checking. The browser vendor infrastructure performs daily checks of 238 the Web PKI, and then the results are assembled in a proprietary 239 format and made available to the browser. These checks only cover 240 the trust anchor store for that browser vendor, so any trust anchors 241 added by the user cannot be checked in this manner. 243 Measurements in 2015 [IMC2015] show that proprietary status checking 244 is not currently providing adequate coverage of the Web PKI. 246 3.2.4. OCSP Stapling 248 Browsers can avoid transmission of CRLs altogether by using the 249 Online Certificate Status Protocol (OCSP) RFC 6960 [RFC6960] to check 250 the validity of web server certificates. The TLS Certificate Status 251 Request extension is defined in Section 8 of RFC 6066 [RFC6066]. In 252 addition, RFC 6961 [RFC6961] defines the TLS Multiple Certificate 253 Status Request extension, which allows the web server to provide 254 status information about its own certificate and also the status of 255 intermediate certificates in the certification path. By including 256 this extension in the TLS handshake, the browser asks the web server 257 to provide an OCSP response in addition to its certificate. This 258 approach greatly reduces the number of round trips by the browser to 259 check the status of each certificate in the path. In addition, the 260 web server can cache the OCSP response for a period of time, avoiding 261 additional latency. Even in the cases where the web server needs to 262 contact the OCSP responder, the web server usually has a higher 263 bandwidth connection than the browser to do so. 265 The provision of the time-stamped OCSP response in the TLS handshake 266 is referred to as "stapling" the OCSP response to the TLS handshake. 267 If the browser does not receive a stapled OCSP response, it can 268 contact the OCSP responder directly. In addition, the MUST_STAPLE 269 feature [TLSFEATURE] can be used to insist that OCSP stapling be 270 used. 272 When every browser that connects to a high volume website performs 273 its own OCSP lookup, the OCSP responder must handle a real-time 274 response to every browser. OCSP stapling can avoid enormous volumes 275 of OCSP requests for certificates of popular websites, so stapling 276 can significantly reduce the cost of providing an OCSP service. 278 OCSP stapling can also improve user privacy, since the web server, 279 not the browser, contacts the OCSP responder. In this way, the OCSP 280 responder is not able to determine which browsers are checking the 281 validity of certificate for websites. 283 Many web site are taking advantage of OCSP sampling. At the time of 284 this writing, browser venders report that about 12% the the 285 transactions use OCSP stapling, and the number is on the rise. 287 3.3. Surprising Certificates 289 All of the CAs in the trust store are equally trusted for the entire 290 domain name space, so any CA can issue for any domain name. In fact, 291 there have been certificates issued by CAs that are surprising to the 292 legitimate owner of a domain. The domain name owner is surprised 293 because they did not request the certificates. They are initially 294 unaware that a CA has issued a certificate that contains their domain 295 name, and once the surprising certificate is discovered, it can be 296 very difficult for the legitimate domain name owner to get it 297 revoked. Further, browsers and other relying parties cannot 298 distinguish a certificate that the legitimate domain name owner 299 requested from an surprising one. 301 Since all of the CAs in the trust store are equally trusted, any CA 302 can issue a certificate for any domain name. There are known cases 303 where attackers have thwarted the CA protections and issued 304 certificates that were then used to mount attacks against the users 305 of that web site [FOXIT]. For this reason, all of the CAs listed in 306 the trust store must be very well protected. 308 The Baseline Requirements produced by the CA/Browser Forum [CAB2014] 309 tell CAs the checks that need to be performed before a certificate is 310 issued. In addition, WebTrust [WEBTRUST] provides the audit 311 requirements for CAs, and browser vendors will remove a CA from the 312 trust anchor store if successful audit reports are not made 313 available. 315 When a CA issues a certificate to a subordinate CA, the inclusion of 316 widely supported certificate extensions can reduce set of privileges 317 given to the sub-CA. This aligns with the traditional security 318 practice of least privilege, where only the privileges needed to 319 perform the envisioned tasks are provided. However, many sub-CAs 320 have certificates that pass along the full powers of the CA, creating 321 additional high-pay-off targets for attackers, and these sub-CAs may 322 not be held to the same certificate issuance requirements and audit 323 requirement as the parent CA. 325 Some major implementations have not fully implemented the mechanisms 326 necessary to reduce sub-CA privileges. For example, RFC 5280 327 [RFC5280] includes the specification of name constraints, and the CA/ 328 Browser Forum guidelines [CAB2014] encourage the use dNSNames in 329 permittedSubtrees within the name Constraints extension. Despite 330 this situation, one major browser does not support name constraints, 331 and as a result, CAs are reluctant to use them. Further, global CAs 332 are prepared to issue certificates within every top-level domain, 333 including ones that are newly-approved. It is not practical for 334 these global CAs to use name constraints in their sub-CA 335 certificates. 337 As a result of procedural failures or attacks, surprising 338 certificates are being issued. Several mechanisms have been defined 339 to avoid the issuance of surprising certificates or prevent browsers 340 from accepting them. 342 3.3.1. Certificate Authority Authorization (CAA) 344 The Certificate Authority Authorization (CAA) [RFC6844] DNS resource 345 record allows a domain administrator to specify one or more CA that 346 is authorized to issue certificates that include the domain name. 347 Then, a trustworthy CA will refuse to issue a certificate for a 348 domain name that has a CAA resource record that does not explicitly 349 name the CA. 351 To date, only one major CA performs this check, and there is no 352 indication that other CAs are planning to add this check in the near 353 future. 355 3.3.2. HTTP Public Key Pinning (HPKP) 357 HTTP Public Key Pinning (HPKP) [RFC7469] allows a web server to 358 instruct browsers to remember the server's public key fingerprints 359 for a period of time. The fingerprint is a one-way hash of the 360 subject public key information in the certificate. The Public-Key- 361 Pins header provides a maximum retention period, fingerprints of the 362 web server certificate, and optionally fingerprints for backup 363 certificates. The act of saving of the fingerprints is referred to 364 as "pinning". During pin lifetime, browsers require that the same 365 web server present a certificate chain that includes a public key 366 that matches one of the retained fingerprints. This prevents 367 impersonation of the website with a surprising certificate. 369 A website can choose to pin the CA certificate so that the browser 370 will accept only valid certificates for the website domain that are 371 issued by that CA. Alternatively, the website can choose to pin 372 their own certificate and at least one backup certificate in case the 373 current certificate needs to be replaced due to a compromised server. 375 Some browser vendors also pin certificates by hardcoding fingerprints 376 of very well known websites. 378 When HPKP is used, browsers may be able to detect a man-in-the- 379 middle. Sometimes the man-in-the-middle is an attacker, and other 380 times a service provider purposefully terminates the TLS at a 381 location other than the web server. One example became very public 382 in February 2012 when Trustwave admitted that it had issued a 383 subordinate CA certificate for use by a company to inspect corporate 384 network traffic [LC2012]. When HPKP is used, the browser user will 385 be notified if the key-pining is violated, unless the violating 386 certificate can be validated to a locally installed trust anchor. In 387 this situation, the browser is assuming that the user intended to 388 explicitly trust the certificate. 390 3.3.3. HTTP Strict Transport Security (HSTS) 392 HTTP Strict Transport Security (HSTS) [RFC6797] is a security policy 393 mechanism that protects secure websites against downgrade attacks, 394 and it greatly simplifies protection against cookie hijacking. The 395 presence of the Strict-Transport-Security header tells browsers that 396 all interactions with this web server should never use HTTP without 397 TLS, providing protection against eavesdropping and active network 398 attacks. 400 When a web server includes the Strict-Transport-Security header, the 401 browser is expected to do two things. First, the browser 402 automatically turns any insecure links into secure ones. For 403 instance, "http://mysite.example.com/mypage/" will be changed to 404 "https://mysite.example.com/mypage/". Second, if the TLS Handshake 405 results in some failure, such as the certificate cannot be validated, 406 then an error message is displayed and the user is denied access the 407 web application. 409 3.3.4. DNS-Based Authentication of Named Entities (DANE) 411 The DNS-Based Authentication of Named Entities (DANE) [RFC6698] 412 allows domain administrators to specify the raw public keys or 413 certificates that are used by web servers in their domain. DANE 414 leverages the DNS Security Extensions (DNSSEC) [RFC4034][RFC4035], 415 which provides digital signatures over DNS zones that are validated 416 with keys that are bound to the domain name of the signed zone. The 417 keys associated with a domain name can only be signed by a key 418 associated with the parent of that domain name. For example, the 419 DNSSEC keys for "www.example.com" can only be signed by the DNSSEC 420 keys for "example.com". Therefore, a malicious actor can only 421 compromise the keys of their own subdomains. Like the Web PKI, 422 DNSSEC relies on public keys used to validate chains of signatures, 423 but DNSSEC has a single root domain as opposed to a multiplicity of 424 trusted CAs. 426 DANE binds raw public keys or certificates to DNS names. The domain 427 administrator is the one that vouches for the binding of the public 428 key or the certificate to the domain name by adding the TSLA records 429 to the zone and then signing the zone. In this way, the same 430 administrator is responsible for managing the DNS names themselves 431 and associated public keys or certificates with those names. DANE 432 restricts the scope of assertions that can be made, forcing them to 433 be consistent with the DNS naming hierarchy. 435 In addition, DNSSEC reduces opportunities for redirection attacks by 436 binding the domain name to the public key or certificate. 438 Some Web PKI certificates are being posted in TLSA records, but 439 browsers expect to receive the the server certificate in the TLS 440 handshake, and there is little incentive to confirm that the received 441 certificate matches the one posted in the DNS. For this reason, work 442 has begun on a TLS extension that will allow the DNSSEC-protected 443 information to be provided in the handshake, which will eliminate the 444 latency [TLSCHAIN]. 446 3.3.5. Certificate Transparency 448 Certificate Transparency (CT) [RFC6962] offers a mechanism to detect 449 mis-issued certificates, and once detected, administrators and CAs 450 can take the necessary actions to revoke the mis-issued certificates. 452 When requesting a certificate, the administrator can request the CA 453 to include an embedded Signed Certificate Timestamp (SCT) in the 454 certificate to ensure that their legitimate certificate is logged 455 with one or more CT log. 457 An administrator, or another party acting on behalf of the 458 administrator, is able to monitor one or more CT log to which a pre- 459 certificate or certificate is submitted, and detect the logging of a 460 pre-certificate or certificate that contains their domain name. When 461 such a pre-certificate or certificate is detected, the CA can be 462 contacted to to get the mis-issued certificate revoked. 464 In the future, a browser may choose to reject certificates that do 465 not contain an SCT, and potentially notify the website administrator 466 or CA when they encounter such a certificate. Such reporting will 467 help detect mis-issuance of certificates and lead to their 468 revocation. 470 3.4. Automation for Server Administrators 472 There have been several attempts to provide automation for routine 473 tasks that are performed by web server administrators, such as 474 certificate renewal. For example, some commercial tools offer 475 automated certificate renewal and installation [DCEI][SSLM]. Also, 476 at least one proposal was brought to the IETF that allows a web 477 server automate obtaining and renewing certificates [PHBOB]. Without 478 automation, there are many manual steps involved in getting a 479 certificate from a CA, and to date none of these attempts at 480 automation have not enjoyed widespread interoperability and adoption. 481 There are at least two ways that this impacts web security. First, 482 many web sites do not have a certificate at all. The cost, time, and 483 effort are too great for the system administrator to go through the 484 effort, especially if the web site does not offer anything for 485 purchase. Second, once a certificate is obtained, a replacement is 486 not obtained until the current one expires. Automation can reduce 487 the amount of time that an administrator needs to dedicate to 488 certificate management, and it can make certificate renewal timely 489 and automatic. 491 The IETF ACME working group [ACMEWG] is working on protocols that 492 will provide system administrators an automated way to enroll and 493 renew their certificates. The expectation is that these 494 specifications will lead to widely available and interoperable tools 495 for system administrators. The expectation is that these protocols 496 and tools will be supported by all web server environments and CAs, 497 which will greatly reduce complexity and cost. 499 4. Policy and Process Improvements to the Web PKI 501 As with many technologies, the issues and complexities associated 502 with Web PKI use and deployment are just as much policy and process 503 as technical. These have evolved over time as well. This section 504 discusses the ways that business models and operational policies and 505 processes impact the Web PKI. 507 4.1. Determination of the Trusted Certificate Authorities 509 A very basic question for users of the Web PKI is "Who do you trust?" 510 The system for determining which CAs are added to or removed from the 511 trust store in browsers has been perceived by some as opaque and 512 confusing. As mentioned earlier, the CA/Browser Forum has developed 513 baseline requirements for the management and issuance of certificates 514 [CAB2014] for individual CAs. However, the process by which an 515 individual CA gets added to the trust store for each of the major 516 browsers is not straightforward. The individual browser vendors 517 determine what should and should not be trusted by including those 518 trusted CAs in their trust store. They do this by leveraging the 519 AICPA/CICA WebTrust Program for Certification Authorities [WEBTRUST]. 520 This program provides auditing requirements and a trust mark for CAs. 521 Failure to pass an audit can result in the CA being removed from the 522 trust store. 524 Once the browser has shipped, how does a user know which CAs are 525 trusted or what has changed recently. For an informed user, 526 information about which CAs have been added to or deleted from the 527 browser trust store can be found in the release notes. Users can 528 also examine the policies of the various CAs which would have been 529 developed and posted for the WebTrust Program. However, this may be 530 considered a fairly high barrier for the average user. There are 531 also options to make local modifications by educated users, but there 532 is little understanding about the implications of these choices. How 533 does an individual, organization, or enterprise really determine if a 534 particular CA is trustworthy? Do the default choices inherited from 535 the browser vendors truly represent the organization's trust model? 536 What constitutes sufficiently bad behavior by a CA to cause removal 537 from the trust store? 539 One form of bad behavior by CAs is the mis-issuance of certificates. 540 This mis-issuance can be either an honest mistake by the CA, 541 malicious behavior by the CA, or a case where an external party has 542 duped the CA into the mis-issuance. When a CA has delegated 543 authority to a sub-CA, and then the sub-CA issued bad certificates 544 either unintentionally or maliciously, the CA is able to deny 545 responsibility for the actions of the sub-CA. However, the CA may be 546 the only party that can revoke the sub-CA certificate to protect the 547 overall Web PKI. 549 Another complication with CAs and the trust store maintained by the 550 browser vendor is an enterprise managed PKI. For example, the US 551 Department of Defense operates its own PKI. In this case, the 552 enterprise maintains its own PKI for the exclusive use of the 553 enterprise itself. A bridge CA may be used to connect related 554 enterprises. The complication in this approach is that the 555 revocation mechanisms don't work with any additions that have been 556 made by the enterprise. See Section 3.2.3 on proprietary revocation 557 checks. 559 What constitutes sufficiently bad behavior by a CA to cause removal 560 from the trust store? The guidelines provided by the WebTrust 561 program [WEBTRUST] provide a framework, but the implications of 562 removing a CA can be significant. There may be a few very large CAs 563 that are critical to significant portions of Internet infrastructure. 564 Removing one of these trusted CAs can have a significant impact on a 565 large cross section of Internet users. 567 4.2. Governance Structures for the Web PKI 569 There are a number of organizations that play significant roles in 570 the operation of the Web PKI, including the CAB Forum, the WebTrust 571 Program, and the browser vendors. These organizations act on behalf 572 of the entire Internet community. Transparency in these operations 573 is vital to basic trust in the Web PKI. As one example, in the past 574 the CAB Forum was perceived as being a closed forum; however, some 575 changes were made to the operational procedures to allow more 576 visibility if not actual participation in the process [CAB1.2]. How 577 do we ensure that these processes continue to evolve in an open, 578 inclusive, and transparent manner? Currently, as the name implies, 579 the CAB Forum members represent CAs and browser vendors. How do we 580 ensure that relying parties a voice in this forum? 582 Since the Web PKI is widespread, applications beyond the World Wide 583 Web are making use of the Web PKI. For example, the Web PKI is used 584 to secure the connections between SMTP servers. In these 585 environments, the browser-centric capabilities are unavailable. For 586 example, see Section 3.2.3 on proprietary revocation checks. The 587 current governance structure does not provide a way for these other 588 applications to participate. How do we ensure that these other 589 applications get a voice in this forum? 591 5. Challenges for Improving the Web PKI 593 To make the Web PKI more secure and more robust, solutions to these 594 technical challenges are needed: 596 Improved certificate status checking. 597 Neither CRLs nor OCSP Responders are meeting the latency and 598 bandwidth needs of browsers. As a result, some browser vendors 599 have started to deploy proprietary alternatives, but they are 600 not providing coverage for the whole Web PKI. In addition, 601 these proprietary solutions do not support non-browser relying 602 parties. A standard solution for all relying parties is 603 needed. 605 Automation for certificate enrollment and renewal. 606 Standard protocols are needed that provide system 607 administrators with an automated way to enroll and renew their 608 certificates. 610 In addition, solutions to these procedural and policy challenges are 611 needed: 613 Smooth transition between cryptographic algorithms. 615 All CAs need to sign certificates with well-studied algorithms 616 and use key sizes that offer 112 to 128 bits of security. The 617 algorithms and key sizes will necessarily change over time. 618 Best practices are needed for smooth transition between 619 cryptographic algorithms in a timely fashion. 621 Eliminate surprising certificates. 622 Several mechanisms have been defined that can be used to 623 indicate which CAs ought to be issuing certificates for a 624 particular domain name or to detect them if the are issued. 625 Best practices are needed that use one or more of these 626 mechanisms throughout the Web PKI to eliminate surprising 627 certificates. 629 Confidence in CA actions. 630 Currently, all CAs in the trust store are equally trusted, and 631 it is unclear what forms of bad behavior by a CA will result in 632 removal from the trust store. Best practices are needed that 633 can be followed by all browser vendors. 635 Open and transparent Web PKI governance. 636 Many organizations act on behalf of the entire Internet 637 community to provide the Web PKI; however, open and transparent 638 governance is vital for basic trust in the Web PKI. A 639 governance structure that allows relying parties to have a 640 voice is needed. 642 6. Security Considerations 644 6.1. Browser Error Messages 646 Many people find browser error messages related to certificates 647 confusing. Good man-machine interfaces are always difficult, but in 648 this situation users are unable to understand the risks that they are 649 accepting by clicking "okay". This aspect of browser usability needs 650 to be improved for users to make better security choices. 652 6.2. Time Synchronization 654 Time synchronization is another factor that impacts the security and 655 reliability of the Web PKI. Reasonably accurate time is needed to 656 check certificate expiration and to determine whether cached 657 revocation status information is fresh. There is ongoing work to 658 improve the security of the time synchronization infrastructure, and 659 it will use certificates to authenticate time servers. Since the 660 certificate infrastructure relies on quality time synchronization, 661 this dependency creates a boot strapping issue. 663 7. IANA Considerations 665 None. 667 {{{ RFC Editor: Please remove this section prior to publication. }}} 669 8. References 671 8.1. Normative References 673 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 674 Housley, R., and W. Polk, "Internet X.509 Public Key 675 Infrastructure Certificate and Certificate Revocation List 676 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 677 . 679 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 680 Galperin, S., and C. Adams, "X.509 Internet Public Key 681 Infrastructure Online Certificate Status Protocol - OCSP", 682 RFC 6960, DOI 10.17487/RFC6960, June 2013, 683 . 685 8.2. Informative References 687 [ACMEWG] IETF, "Charter for Automated Certificate Management 688 Environment (acme) Working Group", June 2015, 689 . 691 [CAB1.2] CA/Browser Forum, "Bylaws of the CA/Browser Forum", 692 October 2014, . 695 [CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements 696 for the Issuance and Management of Publicly-Trusted 697 Certificates, v.1.2.2", October 2014, 698 . 700 [DCEI] DigiCert Inc, "Express Install(TM): Automate SSL 701 Certificate Installation and HTTPS Configuration", AUGUST 702 2015, . 704 [FOXIT] Prins, J., "DigiNotar Certificate Authority breach: 705 "Operation Black Tulip"", September 2011, 706 . 711 [IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D., 712 Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An 713 End-to-End Measurement of Certificate Revocation in the 714 Web's PKI", October 2015, 715 . 718 [LC2012] Constantin, L., "Trustwave admits issuing man-in-the- 719 middle digital certificate; Mozilla debates punishment", 720 February 2012, 721 . 725 [PHBOB] Hallam-Baker, P., "OmniBroker Publication Protocol", 726 draft-hallambaker-omnipublish-00 (work in progress), May 727 2014. 729 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 730 Rose, "Resource Records for the DNS Security Extensions", 731 RFC 4034, DOI 10.17487/RFC4034, March 2005, 732 . 734 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 735 Rose, "Protocol Modifications for the DNS Security 736 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 737 . 739 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 740 (TLS) Protocol Version 1.2", RFC 5246, 741 DOI 10.17487/RFC5246, August 2008, 742 . 744 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 745 Extensions: Extension Definitions", RFC 6066, 746 DOI 10.17487/RFC6066, January 2011, 747 . 749 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 750 of Named Entities (DANE) Transport Layer Security (TLS) 751 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 752 2012, . 754 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 755 Transport Security (HSTS)", RFC 6797, 756 DOI 10.17487/RFC6797, November 2012, 757 . 759 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 760 Authority Authorization (CAA) Resource Record", RFC 6844, 761 DOI 10.17487/RFC6844, January 2013, 762 . 764 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 765 Multiple Certificate Status Request Extension", RFC 6961, 766 DOI 10.17487/RFC6961, June 2013, 767 . 769 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 770 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 771 . 773 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 774 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 775 2015, . 777 [SSLM] Opsmate, Inc., "SSLMate: Secure your website the easy 778 way", August 2015, . 780 [TLSCHAIN] 781 Shore, M., Barnes, R., Huque, S., and W. Toorop, "X.509v3 782 TLS Feature Extension", draft-shore-tls-dnssec-chain- 783 extension-01 (work in progress), July 2015. 785 [TLSFEATURE] 786 Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft- 787 hallambaker-tlsfeature-10 (work in progress), July 2015. 789 [WEBTRUST] 790 CPA Canada, "WebTrust Program for Certification 791 Authorities", August 2015, . 794 Appendix A. Acknowledgements 796 This document has been developed within the IAB Privacy and Security 797 Program. The authors greatly appreciate the review and suggestions 798 provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet, 799 Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie, 800 Ralph Holz, Christian Huitema, Eliot Lear, Xing Li, Lucy Lynch, 801 Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy Rowley, 802 Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian Trammell, 803 and Juan Carlos Zuniga. 805 Appendix B. IAB Members at the Time of Approval 807 {{{ RFC Editor: Please add the names to the IAB members at the time 808 that this document is put into the RFC Editor queue. }}} 810 Authors' Addresses 812 Russ Housley 813 Vigil Security 814 918 Spring Knoll Drive 815 Herndon, VA 20170 816 USA 818 Email: housley@vigilsec.com 820 Karen O'Donoghue 821 Internet Society 822 1775 Wiehle Ave #201 823 Reston, VA 20190 824 USA 826 Email: odonoghue@isoc.org