idnits 2.17.00 (12 Aug 2021) /tmp/idnits39258/draft-iab-web-pki-problems-02.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 (May 12, 2016) is 2200 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 == Outdated reference: draft-hallambaker-tlsfeature has been published as RFC 7633 Summary: 0 errors (**), 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: November 13, 2016 Internet Society 6 May 12, 2016 8 Problems with the Public Key Infrastructure (PKI) for the World Wide Web 9 draft-iab-web-pki-problems-02.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 November 13, 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 . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . 6 62 3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 6 63 3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 6 64 3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 7 65 3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 8 66 3.3.1. Certificate Authority Authorization (CAA) . . . . . . 9 67 3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 9 68 3.3.3. HTTP Strict Transport Security (HSTS) . . . . . . . . 10 69 3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 10 70 3.3.5. Certificate Transparency . . . . . . . . . . . . . . 11 71 3.4. Automation for Server Administrators . . . . . . . . . . 12 72 4. Policy and Process Improvements to the Web PKI . . . . . . . 13 73 4.1. Determination of the Trusted Certificate Authorities . . 13 74 4.2. Price for Certificates . . . . . . . . . . . . . . . . . 14 75 4.3. Governance Structures for the Web PKI . . . . . . . . . . 15 76 5. Additional Technical Considerations . . . . . . . . . . . . . 15 77 5.1. Browser Error Messages . . . . . . . . . . . . . . . . . 15 78 5.2. Time Synchronization . . . . . . . . . . . . . . . . . . 16 79 6. Recommendations for Improving the Web PKI . . . . . . . . . . 16 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 81 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 84 9.2. Informative References . . . . . . . . . . . . . . . . . 18 85 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 86 Appendix B. IAB Members at the Time of Approval . . . . . . . . 22 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 89 1. Introduction 91 There are many interrelated problems with the current Public Key 92 Infrastructure (PKI) used for the World Wide Web (Web PKI). The Web 93 PKI makes use of certificates as described in RFC 5280 [RFC5280]. 94 These certificates are primarily used with Transport Layer Security 95 (TLS) RFC 5246 [RFC5246]. 97 The economics of the Web PKI value chain are discussed in [VFBH], 98 [AV], and [AVAV]. This document does not discuss the economic issues 99 further, but these economic issues provide motivation for correcting 100 the other problems that are discussed in this document. 102 This document describes technical, usability, process, and policy 103 problems, considers some emerging technical improvements, discusses 104 some evoling process and policy improvements, and provides some basic 105 recommendations for the Internet community. 107 2. Very Brief Description of the Web PKI 109 Certificates are specified in RFC 5280 [RFC5280]. Certificates 110 contain, among other things, a subject name, a public key, a limited 111 valid lifetime, and the digital signature of the Certification 112 Authority (CA). Certificate users require confidence that the 113 private key associated with the certified public key is owned by the 114 named subject. 116 The architectural model used in the Web PKI includes: 118 EE: End Entity -- the subject of a certificate -- certificates are 119 issued to end entities including Web servers and clients that 120 need mutual authentication. 122 CA: Certification Authority -- the issuer of a certificate -- 123 issues certificates for end entities including Web servers and 124 clients. 126 RA: Registration Authority -- an optional system to which a CA 127 delegates some management functions such as identity validation 128 or physical credential distribution. 130 A valid certificate may be revoked for any number of reasons. CAs 131 are responsible for indicating the revocation status of the 132 certificates that they issue throughout the lifetime of the 133 certificate. Revocation status information may be provided using the 134 Online Certificate Status Protocol (OCSP) RFC 6960 [RFC6960], 135 certificate revocation lists (CRLs) RFC 5280 [RFC5280], or some other 136 mechanism. In general, when revocation status information is 137 provided using CRLs, the CA is also the CRL issuer. However, a CA 138 may delegate the responsibility for issuing CRLs to a different 139 entity. 141 The enrollment process used by a CA makes sure that the subject name 142 in the certificate is appropriate and that the subject actually holds 143 the private key. Proof of possession of the private key is often 144 accomplished through a challenge-response protocol. 146 3. Technical Improvements to the Web PKI 148 Over the years, many technical improvements have been made to the Web 149 PKI. This section discusses several problems and the technical 150 improvements that have been made to address them. This history sets 151 the stage for suggestions for additional improvements in other 152 sections of this document. 154 3.1. Weak Cryptographic Algorithms or Short Public Keys 156 Over the years, the digital signature algorithms, one-way hash 157 functions, and public key sizes that are considered strong have 158 changed. This is not a surprise. Cryptographic algorithms age; they 159 become weaker with time. As new cryptanalysis techniques are 160 developed and computing capabilities improve, the work factor to 161 break a particular cryptographic algorithm will reduce. For this 162 reason, the algorithms and key sizes used in the Web PKI need to 163 migrate over time. A reasonable choice of algorithm or key size 164 needs to be reevaluated periodically, and a transition may be needed 165 before the expected lifetime expires. 167 The browser vendors have been trying to manage algorithm and key size 168 transitions, but a long-lived trust anchor or intermediate CA 169 certificate can have a huge number of certificates under it. So, 170 removing one certificate because it uses a weak cryptographic 171 algorithm or a short public key can have a significant impact on a 172 large subtree. In addition, if a certificate for a web site with a 173 huge amount of traffic is in that subtree, it will increase the 174 difficulty in removing the certificate with a weak cryptographic 175 algorithm or a short public key. 177 As a result, some valid trust anchors and certificates contain 178 cryptographic algorithms long after weaknesses have been discovered 179 and widely known. Similarly, valid trust anchors and certificates 180 contain public keys after computational resources available to 181 attackers have rendered them too weak. We have seen a very 182 successful migration away from certificates that use the MD2 or MD5 183 one-way hash functions. However, there are still a number of 184 certificates that use SHA-1 and 1024-bit RSA public keys [MB2015] 185 [MB2016], and these certificates should be replaced. 187 Today, the algorithms and key sizes used by a CA to sign end-entity 188 certificates with a traditional lifespan of a year should offer 112 189 to 128 bits of security. SHA-256 is a widely studied one-way hash 190 function that meets this requirement. RSA with a public key of at 191 least 2048 bits or ECDSA with a public key of at least 256 bits are 192 widely studied digital signature algorithms that meet this 193 requirement. 195 The algorithms and key sizes used by a CA to sign long-lived 196 intermediate CA certificates that often have a lifespan of several 197 decades should offer even greater security. SHA-384 is a widely 198 studied one-way hash function that meets this requirement. RSA with 199 a public key of at least 3072 bits or ECDSA with a public key of at 200 least 384 bits are widely studied digital signature algorithms that 201 meet this requirement. 203 Obviously, additional algorithm transitions will be needed in the 204 future as these algorithms age. These algorithms, like the ones that 205 were used earlier, will become weaker with time. RFC 7696 [RFC7696] 206 offers some guidelines regarding cryptographic algorithm agility. 208 3.2. Certificate Status Checking 210 Several years ago, many browsers did not perform certificate status 211 checks by default. That is, browsers did not check whether the 212 issuing CA had revoked the certificate unless the user explicitly 213 adjusted a setting to enable this feature. This check can be made by 214 fetching the most recent certificate revocation list (CRL) RFC 5280 215 [RFC5280], or this check can use the Online Certificate Status 216 Protocol (OCSP) RFC 6960 [RFC6960]. The location of the CRL or the 217 OCSP responder is usually found in the certificate itself. However, 218 both of these approaches add latency. The desire to provide a 219 responsive user experience is a significant reason that this feature 220 has not been turned on by default. Mobile browsers simply do not 221 bother to check revocation status [IMC2015]. 223 Certificate status checking needs to be used at all times. Several 224 techniques have been tried by CAs and browsers to make certificate 225 status checking more efficient. Many CAs are using Content Delivery 226 Networks (CDNs) to deliver CRLs and OCSP responses, resulting in very 227 high availability and low latency. Yet, browser vendors are still 228 reluctant to perform standard-based status checking by default for 229 every session. 231 Certificate status checking by the browser can reveal the web sites 232 that the browser user is visiting to the OCSP Responder or the server 233 providing the CRL. This privacy concern can be eliminated by having 234 the Web Server include the OCSP Response in the TLS handshake. This 235 is called OCSP Stapling, and it is discussed further in 236 Section 3.2.4. 238 Measurements in 2015 [IMC2015] show that a surprisingly large 239 fraction of Web PKI certicates have been revoked. Note that these 240 measurements were taken around the time of the Heartbleed incident 241 [HEARTBLEED], and the revocation activity may have been unusually 242 high due to this incident. In addition, this incident exacerbates 243 the problem of incomplete Web PKI revocation checking. These 244 measurements show that browsers are not obtaining current certificate 245 revocation information because it is too expensive in terms of 246 latency and bandwidth. Finally, only a small number of CRL and OCSP 247 servers are available over IPv6, and as more of the Web moves to IPv6 248 [ABLOG] this is expected to become an increasingly significant issue. 250 The following subsections identify some approaches for reducing the 251 perceived and actual cost of revocation status checks. 253 3.2.1. Short-lived Certificates 255 Short-lived certificates are an excellent way to reduce the need for 256 certificate status checking. The shorter the life of the 257 certificate, the less time there is for anything to go wrong. If the 258 lifetime is short enough, policy might allow certificate status 259 checking can be skipped altogether. In practice, implementation of 260 short-lived certificates requires automation to assist web server 261 administrators, which is a topic that is discussed elsewhere in this 262 document. 264 3.2.2. CRL Distribution Points 266 The certificate revocation list distribution point (CRLDP) 267 certificate extension RFC 5280 [RFC5280] allows a CA to control the 268 maximum size of the CRLs that they issue. This helps in two ways. 269 First, the amount of storage needed by the browser to cache CRLs is 270 reduced. Second, and more importantly, the amount of time it takes 271 to download a CRL can be scoped, so that the amount of time needed to 272 fetch any single CRL is reasonable. 274 Few CAs take advantage of the CRLDP certificate extension to limit 275 the size of CRLs. In fact, there are several CAs that publish 276 extremely large CRLs. Browsers never want to suffer the latency 277 associated with large CRLs, and some ignore the CRLDP extension when 278 it is present. Browsers tend to avoid the use of CRLs altogether. 280 3.2.3. Proprietary Revocation Checks 282 Some browser vendors provide a proprietary mechanism for revocation 283 checking. These mechanisms obtain revocation status information once 284 per day for the entire Web PKI in a very compact form. No network 285 traffic is generated at the time that a certificate is being 286 validated, so there is no latency associated with revocation status 287 checking. The browser vendor infrastructure performs daily checks of 288 the Web PKI, and then the results are assembled in a proprietary 289 format and made available to the browser. These checks only cover 290 the trust anchor store for that browser vendor, so any trust anchors 291 added by the user cannot be checked in this manner. 293 Measurements in 2015 [IMC2015] show that proprietary status checking 294 is not currently providing adequate coverage of the Web PKI. 296 3.2.4. OCSP Stapling 298 Browsers can avoid transmission of CRLs altogether by using the 299 Online Certificate Status Protocol (OCSP) RFC 6960 [RFC6960] to check 300 the validity of web server certificates. The TLS Certificate Status 301 Request extension is defined in Section 8 of RFC 6066 [RFC6066]. In 302 addition, RFC 6961 [RFC6961] defines the TLS Multiple Certificate 303 Status Request extension, which allows the web server to provide 304 status information about its own certificate and also the status of 305 intermediate certificates in the certification path. By including 306 this extension in the TLS handshake, the browser asks the web server 307 to provide an OCSP response in addition to its certificate. This 308 approach greatly reduces the number of round trips by the browser to 309 check the status of each certificate in the path. In addition, the 310 web server can cache the OCSP response for a period of time, avoiding 311 additional latency. Even in the cases where the web server needs to 312 contact the OCSP responder, the web server usually has a higher 313 bandwidth connection than the browser to do so. 315 The provision of the time-stamped OCSP response in the TLS handshake 316 is referred to as "stapling" the OCSP response to the TLS handshake. 317 If the browser does not receive a stapled OCSP response, it can 318 contact the OCSP responder directly. In addition, the MUST_STAPLE 319 feature [TLSFEATURE] can be used to insist that OCSP stapling be 320 used. 322 When every browser that connects to a high volume website performs 323 its own OCSP lookup, the OCSP responder must handle a real-time 324 response to every browser. OCSP stapling can avoid enormous volumes 325 of OCSP requests for certificates of popular websites, so stapling 326 can significantly reduce the cost of providing an OCSP service. 328 OCSP stapling can also improve user privacy, since the web server, 329 not the browser, contacts the OCSP responder. In this way, the OCSP 330 responder is not able to determine which browsers are checking the 331 validity of certificate for websites. 333 Many web site are taking advantage of OCSP stapling. At the time of 334 this writing, browser venders report that about 12% the the 335 transactions use OCSP stapling, and the number is on the rise. 337 3.3. Surprising Certificates 339 All of the CAs in the trust store are equally trusted for the entire 340 domain name space, so any CA can issue for any domain name. In fact, 341 there have been certificates issued by CAs that are surprising to the 342 legitimate owner of a domain. The domain name owner is surprised 343 because they did not request the certificates. They are initially 344 unaware that a CA has issued a certificate that contains their domain 345 name, and once the surprising certificate is discovered, it can be 346 very difficult for the legitimate domain name owner to get it 347 revoked. Further, browsers and other relying parties cannot 348 distinguish a certificate that the legitimate domain name owner 349 requested from a surprising one. 351 Since all of the CAs in the trust store are equally trusted, any CA 352 can issue a certificate for any domain name. There are known cases 353 where attackers have thwarted the CA protections and issued 354 certificates that were then used to mount attacks against the users 355 of that web site [FOXIT]. For this reason, all of the CAs listed in 356 the trust store must be very well protected. 358 The Baseline Requirements produced by the CA/Browser Forum [CAB2014] 359 tell CAs the checks that need to be performed before a certificate is 360 issued. In addition, WebTrust [WEBTRUST] provides the audit 361 requirements for CAs, and browser vendors will remove a CA from the 362 trust anchor store if successful audit reports are not made 363 available. 365 When a CA issues a certificate to a subordinate CA, the inclusion of 366 widely supported certificate extensions can reduce the set of 367 privileges given to the sub-CA. This aligns with the traditional 368 security practice of least privilege, where only the privileges 369 needed to perform the envisioned tasks are provided. However, many 370 sub-CAs have certificates that pass along the full powers of the CA, 371 creating additional high-pay-off targets for attackers, and these 372 sub-CAs may not be held to the same certificate issuance requirements 373 and audit requirement as the parent CA. 375 Some major implementations have not fully implemented the mechanisms 376 necessary to reduce sub-CA privileges. For example, RFC 5280 377 [RFC5280] includes the specification of name constraints, and the CA/ 378 Browser Forum guidelines [CAB2014] encourage the use of dNSNames in 379 permittedSubtrees within the name constraints extension. Despite 380 this situation, one major browser does not support name constraints, 381 and as a result, CAs are reluctant to use them. When they are used, 382 the name constraints extension in not marked critical so that the 383 browser that does not support this extension is free to ignore the 384 extension. This situation leads to enforcement of the name 385 constraint by some browsers and not others. Further, global CAs are 386 prepared to issue certificates within every top-level domain, 387 including ones that are newly-approved. It is not practical for 388 these global CAs to use name constraints in their sub-CA 389 certificates. 391 As a result of procedural failures or attacks, surprising 392 certificates are being issued. Several mechanisms have been defined 393 to avoid the issuance of surprising certificates or prevent browsers 394 from accepting them. 396 3.3.1. Certificate Authority Authorization (CAA) 398 The Certificate Authority Authorization (CAA) [RFC6844] DNS resource 399 record allows a domain administrator to specify one or more CAs 400 authorized to issue certificates that include that domain name. 401 Then, a trustworthy CA will refuse to issue a certificate for a 402 domain name that has a CAA resource record that does not explicitly 403 name the CA. 405 To date, only one major CA performs this check, and there is no 406 indication that other CAs are planning to add this check in the near 407 future. 409 3.3.2. HTTP Public Key Pinning (HPKP) 411 HTTP Public Key Pinning (HPKP) [RFC7469] allows a web server to 412 instruct browsers to remember the server's public key fingerprints 413 for a period of time. The fingerprint is a one-way hash of the 414 subject public key information in the certificate. The Public-Key- 415 Pins header provides a maximum retention period, fingerprints of the 416 web server certificate, and optionally fingerprints for backup 417 certificates. The act of saving the fingerprints is referred to as 418 "pinning". During the pin lifetime, browsers require that the same 419 web server present a certificate chain that includes a public key 420 that matches one of the retained fingerprints. This prevents 421 impersonation of the website with a surprising certificate. 423 A website can choose to pin the CA certificate so that the browser 424 will accept only valid certificates for the website domain that are 425 issued by that CA. Alternatively, the website can choose to pin 426 their own certificate and at least one backup certificate in case the 427 current certificate needs to be replaced due to a compromised server. 429 Some browser vendors also pin certificates by hardcoding fingerprints 430 of very well known websites. 432 When HPKP is used, browsers may be able to detect a man-in-the- 433 middle. Sometimes the man-in-the-middle is an attacker, and other 434 times a service provider purposefully terminates the TLS at a 435 location other than the web server. One example became very public 436 in February 2012 when Trustwave admitted that it had issued a 437 subordinate CA certificate for use by a company to inspect corporate 438 network traffic [LC2012]. When HPKP is used, the browser user will 439 be notified if the key-pining is violated, unless the violating 440 certificate can be validated to a locally installed trust anchor. In 441 this situation, the browser is assuming that the user intended to 442 explicitly trust the certificate. 444 3.3.3. HTTP Strict Transport Security (HSTS) 446 HTTP Strict Transport Security (HSTS) [RFC6797] is a security policy 447 mechanism that protects secure websites against downgrade attacks, 448 and it greatly simplifies protection against cookie hijacking. The 449 presence of the Strict-Transport-Security header tells browsers that 450 all interactions with this web server should never use HTTP without 451 TLS, providing protection against both eavesdropping and active 452 network attacks. The protections can be tied to a domain or a domain 453 and all of its sub-domains. 455 When a web server includes the Strict-Transport-Security header, the 456 browser is expected to do two things. First, the browser 457 automatically turns any insecure links into secure ones. For 458 instance, "http://mysite.example.com/mypage/" will be changed to 459 "https://mysite.example.com/mypage/". Second, if the TLS Handshake 460 results in some failure, such as the certificate cannot be validated, 461 then an error message is displayed and the user is denied access to 462 the web application. Any web server misconfiguration, such as a 463 certificate expiration, will result no one being able to access the 464 web site until the configuration is corrected. 466 To date, HSTS ha seen very little deployment, and there is no 467 indication that the browser vendors intend to add support for it. 469 3.3.4. DNS-Based Authentication of Named Entities (DANE) 471 The DNS-Based Authentication of Named Entities (DANE) [RFC6698] 472 allows domain administrators to specify the raw public keys or 473 certificates that are used by web servers in their domain. DANE 474 leverages the DNS Security Extensions (DNSSEC) [RFC4034][RFC4035], 475 which provides digital signatures over DNS zones that are validated 476 with keys that are bound to the domain name of the signed zone. The 477 keys associated with a domain name can only be signed by a key 478 associated with the parent of that domain name. For example, the 479 DNSSEC keys for "www.example.com" can only be signed by the DNSSEC 480 keys for "example.com". Therefore, a malicious actor can only 481 compromise the keys of their own subdomains. Like the Web PKI, 482 DNSSEC relies on public keys used to validate chains of signatures, 483 but DNSSEC has a single root domain as opposed to a multiplicity of 484 trusted CAs. 486 DANE binds raw public keys or certificates to DNS names. The domain 487 administrator is the one that vouches for the binding of the public 488 key or the certificate to the domain name by adding the TSLA records 489 to the zone and then signing the zone. In this way, the same 490 administrator is responsible for managing the DNS names themselves 491 and associated public keys or certificates with those names. DANE 492 restricts the scope of assertions that can be made, forcing them to 493 be consistent with the DNS naming hierarchy. 495 In addition, DNSSEC reduces opportunities for redirection attacks by 496 binding the domain name to the public key or certificate. 498 Some Web PKI certificates are being posted in TLSA records, but 499 browsers expect to receive the server certificate in the TLS 500 handshake, and there is little incentive for browsers to confirm that 501 the received certificate matches the one posted in the DNS. For this 502 reason, work has begun on a TLS extension that will allow the DNSSEC- 503 protected information to be provided in the handshake, which will 504 eliminate the added latency [TLSCHAIN]. 506 3.3.5. Certificate Transparency 508 Certificate Transparency (CT) [RFC6962] offers a mechanism to detect 509 surprising certificates, and once detected, administrators and CAs 510 can take the necessary actions to revoke the surprising certificates. 512 When requesting a certificate, the administrator can request the CA 513 to include an embedded Signed Certificate Timestamp (SCT) in the 514 certificate to ensure that their legitimate certificate is logged 515 with one or more CT logs. 517 An administrator, or another party acting on behalf of the 518 administrator, is able to monitor one or more CT logs to which a pre- 519 certificate or certificate is submitted, and detect the logging of a 520 pre-certificate or certificate that contains their domain name. When 521 such a pre-certificate or certificate is detected, the CA can be 522 contacted to to get the surprising certificate revoked. 524 In the future, a browser may choose to reject certificates that do 525 not contain an SCT, and potentially notify the website administrator 526 or CA when they encounter such a certificate. Such reporting will 527 help detect mis-issuance of certificates and lead to their 528 revocation. 530 The IETF Certificate Transparency Working Group is in the process of 531 updating RFC 6962. Many data structures are changing, and CT logs 532 will have to pick a format, choosing version 1 (v1) that conforms to 533 RFC 6962 or version 2 (v2) that conforms to the new specification. 534 Since the data structures are incompatible, a v2 log will not be able 535 to issue a valid v1 SCT. A CT client can support both v1 and v2 SCTs 536 for the same certificate, simultaneously, since a v1 SCT will be 537 carried in different extension than a v2 SCT. 539 3.4. Automation for Server Administrators 541 The IETF has developed several protocols for certificate management, 542 including the Certificate Management Protocol (CMP) [RFC4210], 543 Certificate Management over CMS (CMC) [RFC5272], and Enrollment over 544 Secure Transport (EST) [RFC7030]. There are also some proprietary 545 certificate management protocols. None of these protocols enjoys a 546 dominate position in the market. 548 There have been several attempts to provide automation for routine 549 tasks that are performed by web server administrators, such as 550 certificate renewal. For example, some commercial tools offer 551 automated certificate renewal and installation [DCEI][SSLM]. Also, 552 at least one proposal was brought to the IETF that allows a web 553 server to automate obtaining and renewing certificates [PHBOB]. 554 Without automation, there are many manual steps involved in getting a 555 certificate from a CA, and to date none of these attempts at 556 automation have enjoyed widespread interoperability and adoption. 557 There are at least two ways that this impacts web security. First, 558 many web sites do not have a certificate at all. The cost, time, and 559 effort are too great for the system administrator. This is 560 especially true if the web site is not involved in financial 561 transactions or some other critical activity. Second, once a 562 certificate is obtained, a replacement is not obtained until the 563 current one expires. Automation can reduce the amount of time that 564 an administrator needs to dedicate to certificate management, and it 565 can make certificate renewal timely and automatic. Both of these 566 should lead to more widespread deployment and improved web security. 568 The IETF ACME working group [ACMEWG] is working on protocols that 569 will provide system administrators with an automated way to enroll 570 and renew their certificates. The expectation is that these 571 specifications will lead to widely available and interoperable tools 572 for system administrators. The expectation is that these protocols 573 and tools will be supported by all web server environments and CAs, 574 which will greatly reduce complexity and cost. In addition, the 575 easier renewal process provided by automation can be used to reduce 576 certificate lifetimes, which in turn will reduce the time required to 577 flush old algorithms out of the system when it is decided to 578 transition to newer more secure algorithms. 580 4. Policy and Process Improvements to the Web PKI 582 As with many technologies, the issues and complexities associated 583 with Web PKI use and deployment are just as much policy and process 584 as technical. These have evolved over time as well. This section 585 discusses the ways that business models and operational policies and 586 processes impact the Web PKI. 588 4.1. Determination of the Trusted Certificate Authorities 590 A very basic question for users of the Web PKI is "Who do you trust?" 591 The system for determining which CAs are added to or removed from the 592 trust store in browsers has been perceived by some as opaque and 593 confusing. As mentioned earlier, the CA/Browser Forum has developed 594 baseline requirements for the management and issuance of certificates 595 [CAB2014] for individual CAs. However, the process by which an 596 individual CA gets added to the trust store for each of the major 597 browsers is not straightforward. The individual browser vendors 598 determine what should and should not be trusted by including those 599 trusted CAs in their trust store. They do this by leveraging the 600 AICPA/CICA WebTrust Program for Certification Authorities [WEBTRUST]. 601 This program provides auditing requirements and a trust mark for CAs. 602 Failure to pass an audit can result in the CA being removed from the 603 trust store. 605 Once the browser has shipped, how does a user know which CAs are 606 trusted or what has changed recently? For an informed user, 607 information about which CAs have been added to or deleted from the 608 browser trust store can be found in the release notes. Users can 609 also examine the policies of the various CAs which would have been 610 developed and posted for the WebTrust Program. However, this is a 611 very high barrier for the average user. There are options to make 612 local modifications by educated users, but there is little 613 understanding about the implications of these choices. How does an 614 individual, organization, or enterprise really determine if a 615 particular CA is trustworthy? Do the default choices inherited from 616 the browser vendors truly represent the organization's trust model? 617 What constitutes sufficiently bad behavior by a CA to cause removal 618 from the trust store? 620 In addition, it can be hazardous for users to remove CAs from the 621 browser trust store. If a user removes a CA from the browser trust 622 store, some web sites may become completely inaccessible or require 623 the user to take explicit action to accept warnings or bypass browser 624 protections related to untrusted certificates. 626 One form of bad behavior by CAs is the mis-issuance of certificates. 627 This mis-issuance can be either an honest mistake by the CA, 628 malicious behavior by the CA, or a case where an external party has 629 duped the CA into the mis-issuance. When a CA has delegated 630 authority to a sub-CA, and then the sub-CA issued bad certificates 631 either unintentionally or maliciously, the CA is able to deny 632 responsibility for the actions of the sub-CA. However, the CA may be 633 the only party that can revoke the sub-CA certificate to protect the 634 overall Web PKI. 636 Another complication with CAs and the trust store maintained by the 637 browser vendor is an enterprise managed PKI. For example, the US 638 Department of Defense operates its own PKI. In this case, the 639 enterprise maintains its own PKI for the exclusive use of the 640 enterprise itself. A bridge CA may be used to connect related 641 enterprises. The complication in this approach is that the 642 revocation mechanisms don't work with any additions that have been 643 made by the enterprise. See Section 3.2.3 on proprietary revocation 644 checks. 646 The guidelines provided by the WebTrust program [WEBTRUST] provide a 647 framework for removing a CA from the trust store. However, the 648 implications of removing a CA can be significant. There may be a few 649 very large CAs that are critical to significant portions of Internet 650 infrastructure. Removing one of these trusted CAs can have a 651 significant impact on a large cross section of Internet users 652 resulting in potentially large numbers of websites no longer being 653 trusted. Users are already struggling to understand the implications 654 of untrusted websites and often ignore the current warnings as 655 discussed below. 657 4.2. Price for Certificates 659 Many CAs charge for each of the certificates that they issue. This 660 business model creates a hurdle for proper deployment. In some 661 cases, the cost causes people to deploy self-signed certificates that 662 cannot be validated against the browser trust store. In other cases, 663 the cost is an incentive to use the same certificate and the 664 associate private key on many different servers within a domain. 665 This leads to greater exposure of the private key, and coordination 666 is needed among the server administrators when it is time to renew 667 the certificate. 669 At least one CA is moving away from the charging-per-certificate 670 business model. The Let's Encrypt CA [LE] is offering free web 671 server certificates. This zero-cost business model will 672 significantly change the Web PKI, removing the cost concerns that 673 leaded to insecure deployment. 675 4.3. Governance Structures for the Web PKI 677 There are a number of organizations that play significant roles in 678 the operation of the Web PKI, including the CAB Forum, the WebTrust 679 Program, and the browser vendors. These organizations act on behalf 680 of the entire Internet community. Transparency in these operations 681 is vital to basic trust in the Web PKI. As one example, in the past 682 the CAB Forum was perceived as being a closed forum; however, some 683 changes were made to the operational procedures to allow more 684 visibility if not actual participation in the process [CAB1.2]. How 685 do we ensure that these processes continue to evolve in an open, 686 inclusive, and transparent manner? Currently, as the name implies, 687 the CAB Forum members represent CAs and browser vendors. How do we 688 ensure that relying parties have a voice in this forum? 690 Since the Web PKI is widespread, applications beyond the World Wide 691 Web are making use of the Web PKI. For example, the Web PKI is used 692 to secure the connections between SMTP servers. In these 693 environments, the browser-centric capabilities are unavailable. For 694 example, see Section 3.2.3 on proprietary revocation checks. The 695 current governance structure does not provide a way for these other 696 applications to participate. How do we ensure that these other 697 applications get a voice in this forum? 699 5. Additional Technical Considerations 701 Beyond the technical mechanisms that constitute the Web PKI itself, 702 there are additional technical considerations that impact the success 703 of the Web PKI. 705 5.1. Browser Error Messages 707 Many people find browser error messages related to certificates 708 confusing. Good man-machine interfaces are always difficult, but in 709 this situation users are unable to understand the risks that they 710 being asked to accept. Even experts do not have the time or 711 inclination to make an assessment of the situation that caused the 712 error message. As a result, browser users have learned to largely 713 ignore the warning messages. 715 Many different situations can cause an error message, where blocking 716 the communication would not be in the interest of the browser user. 717 There are many examples, including web sites that use self-signed 718 certificates, captive portals that redirect intercepted HTTPS 719 connections, and certificates that appear expired because the local 720 computer clock is wrong. 722 Too often the warnings are due to web server misconfiguration. 723 Further, solving the error message situation in isolation is probably 724 not possible; instead, it needs to be considered along side the other 725 issues raised in this document. 727 If the risk to the user is high, then the session should be closed 728 with a clear description of the problem that was encountered. Doing 729 so will lead to improved management of the overall infrastructure 730 over time, especially as the tools that are being developed for web 731 server administrators are rolled out. 733 In some enterprises, avoiding these errors requires the addition of 734 enterprise-specific trust anchors to the browser. Additional tools 735 are needed to allow administrations to easily add appropriate trust 736 anchors, especially browsers on consumer-grade devices as more and 737 more enterprises are embracing bring-your-own-device policies. 739 5.2. Time Synchronization 741 Time synchronization is another factor that impacts the security and 742 reliability of the Web PKI. Reasonably accurate time is needed to 743 check certificate expiration and to determine whether cached 744 revocation status information is fresh. There is ongoing work to 745 improve the security of the time synchronization infrastructure, and 746 it will use certificates to authenticate time servers. Since the 747 certificate infrastructure relies on quality time synchronization, 748 this dependency creates a boot strapping issue. 750 6. Recommendations for Improving the Web PKI 752 To make the Web PKI more secure and more robust, the following 753 priorities have been identified and are recommended for further 754 development and deployment: 756 Improve certificate status checking. 757 Develop and deploy a standard solution for all relying parties 758 is needed. OCSP stapling seems to be a significant part of 759 this solution. 761 Automation for certificate enrollment and renewal. 762 Develop and deploy standard protocols that provide system 763 administrators with an automated way to enroll and renew their 764 certificates. This work is currently underway in the IETF. 766 In addition, solutions to these procedural and policy challenges are 767 needed: 769 Smooth transition between cryptographic algorithms. 770 Develop best practices for smooth and timely transition between 771 cryptographic algorithms. 773 Eliminate surprising certificates. 774 Develop best practices that use one or more of the several 775 mechanisms that have been defined throughout the Web PKI to 776 eliminate surprising certificates. 778 Confidence in CA actions. 779 Develop best practices for identifying and dealing with bad 780 behavior by a CA that can be followed by all browser vendors. 782 Open and transparent Web PKI governance. 783 Develop a governance structure that allows relying parties to 784 have a voice resulting in open and transparent governance. 786 7. Security Considerations 788 Not just the Web depends on the Web PKI. For example, mail servers 789 often use certificates that are validated using the trust store from 790 a browser. In addition, applications written in scripting languages 791 that run in the browser environment do not have access to any 792 alternative infrastructures. The Web PKI is being leveraged to avoid 793 the time and expense to establish an independent PKI. 795 More and more Internet applications depend on the Web PKI. For the 796 most part, leveraging the Web PKI is improving the security of the 797 Internet. However, the Web PKI is being used in ways that were not 798 envisaged in its design. Care is needed to ensure that applications 799 are not expecting security properties that cannot be delivered by the 800 Web PKI. 802 This document considers the weaknesses of the current Web PKI system 803 and provides recommendations for improvements. Some of the risks 804 associated with doing nothing or continuing down the current path are 805 articulated. The Web PKI is a vital component of a trusted Internet 806 and as such needs to be improved to sustain continued growth of the 807 Internet. 809 8. IANA Considerations 811 None. 813 {{{ RFC Editor: Please remove this section prior to publication. }}} 815 9. References 817 9.1. Normative References 819 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 820 Housley, R., and W. Polk, "Internet X.509 Public Key 821 Infrastructure Certificate and Certificate Revocation List 822 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 823 . 825 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 826 Galperin, S., and C. Adams, "X.509 Internet Public Key 827 Infrastructure Online Certificate Status Protocol - OCSP", 828 RFC 6960, DOI 10.17487/RFC6960, June 2013, 829 . 831 9.2. Informative References 833 [ABLOG] Nygren, E., "Three years since World IPv6 Launch: strong 834 IPv6 growth continues", June 2015, 835 . 838 [ACMEWG] IETF, "Charter for Automated Certificate Management 839 Environment (acme) Working Group", June 2015, 840 . 842 [AV] Arnbak, A. and N. van Eijk, "Certificate Authority 843 Collapse: Regulating Systemic Vulnerabilities in the HTTPS 844 Value Chain", 2012 TRPC , August 2012, 845 . 847 [AVAV] Asghari, H., van Eeten, M., Arnbak, A., and N. van Eijk, 848 "Security Economics in the HTTPS Value Chain", Workshop on 849 Economics of Information Security (WEIS) 2013 , 2013, 850 . 853 [CAB1.2] CA/Browser Forum, "Bylaws of the CA/Browser Forum", 854 October 2014, . 857 [CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements 858 for the Issuance and Management of Publicly-Trusted 859 Certificates, v.1.2.2", October 2014, 860 . 862 [DCEI] DigiCert Inc, "Express Install(TM): Automate SSL 863 Certificate Installation and HTTPS Configuration", August 864 2015, . 866 [FOXIT] Prins, J., "DigiNotar Certificate Authority breach: 867 "Operation Black Tulip"", September 2011, 868 . 873 [HEARTBLEED] 874 Wikipedia, "Heartbleed", 2016, 875 . 877 [IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D., 878 Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An 879 End-to-End Measurement of Certificate Revocation in the 880 Web's PKI", October 2015, 881 . 884 [LC2012] Constantin, L., "Trustwave admits issuing man-in-the- 885 middle digital certificate; Mozilla debates punishment", 886 February 2012, 887 . 891 [LE] Internet Security Research Group, "Let's Encrypt", July 892 2015, . 894 [MB2015] Wilson, K., "Phase 2: Phasing out Certificates with 895 1024-bit RSA Keys", January 2015, 896 . 899 [MB2016] Barnes, R., "Payment Processors Still Using Weak Crypto", 900 February 2016, 901 . 904 [PHBOB] Hallam-Baker, P., "OmniBroker Publication Protocol", 905 draft-hallambaker-omnipublish-00 (work in progress), May 906 2014. 908 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 909 Rose, "Resource Records for the DNS Security Extensions", 910 RFC 4034, DOI 10.17487/RFC4034, March 2005, 911 . 913 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 914 Rose, "Protocol Modifications for the DNS Security 915 Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, 916 . 918 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 919 "Internet X.509 Public Key Infrastructure Certificate 920 Management Protocol (CMP)", RFC 4210, 921 DOI 10.17487/RFC4210, September 2005, 922 . 924 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 925 (TLS) Protocol Version 1.2", RFC 5246, 926 DOI 10.17487/RFC5246, August 2008, 927 . 929 [RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS 930 (CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008, 931 . 933 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 934 Extensions: Extension Definitions", RFC 6066, 935 DOI 10.17487/RFC6066, January 2011, 936 . 938 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 939 of Named Entities (DANE) Transport Layer Security (TLS) 940 Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 941 2012, . 943 [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict 944 Transport Security (HSTS)", RFC 6797, 945 DOI 10.17487/RFC6797, November 2012, 946 . 948 [RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification 949 Authority Authorization (CAA) Resource Record", RFC 6844, 950 DOI 10.17487/RFC6844, January 2013, 951 . 953 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 954 Multiple Certificate Status Request Extension", RFC 6961, 955 DOI 10.17487/RFC6961, June 2013, 956 . 958 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 959 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 960 . 962 [RFC7030] Pritikin, M., Ed., Yee, P., Ed., and D. Harkins, Ed., 963 "Enrollment over Secure Transport", RFC 7030, 964 DOI 10.17487/RFC7030, October 2013, 965 . 967 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning 968 Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April 969 2015, . 971 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm 972 Agility and Selecting Mandatory-to-Implement Algorithms", 973 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, 974 . 976 [SSLM] Opsmate, Inc., "SSLMate: Secure your website the easy 977 way", August 2015, . 979 [TLSCHAIN] 980 Shore, M., Barnes, R., Huque, S., and W. Toorop, "X.509v3 981 TLS Feature Extension", draft-shore-tls-dnssec-chain- 982 extension-01 (work in progress), July 2015. 984 [TLSFEATURE] 985 Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft- 986 hallambaker-tlsfeature-10 (work in progress), July 2015. 988 [VFBH] Vratonjic, N., Freudiger, J., Bindschaedler, V., and J. 989 Hubaux, "The Inconvenient Truth About Web Certificates", 990 Workshop on Economics of Information Security (WEIS) 991 2011 , 2011, 992 . 995 [WEBTRUST] 996 CPA Canada, "WebTrust Program for Certification 997 Authorities", August 2015, . 1000 Appendix A. Acknowledgements 1002 This document has been developed within the IAB Privacy and Security 1003 Program. The authors greatly appreciate the review and suggestions 1004 provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet, 1005 Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie, 1006 Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy 1007 Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy 1008 Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Martin 1009 Thomson, Brian Trammell, and Juan Carlos Zuniga. 1011 Appendix B. IAB Members at the Time of Approval 1013 {{{ RFC Editor: Please add the names to the IAB members at the time 1014 that this document is put into the RFC Editor queue. }}} 1016 Authors' Addresses 1018 Russ Housley 1019 Vigil Security 1020 918 Spring Knoll Drive 1021 Herndon, VA 20170 1022 USA 1024 Email: housley@vigilsec.com 1026 Karen O'Donoghue 1027 Internet Society 1028 1775 Wiehle Ave #201 1029 Reston, VA 20190 1030 USA 1032 Email: odonoghue@isoc.org