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