idnits 2.17.1
draft-iab-web-pki-problems-04.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 (October 28, 2016) is 2729 days in the past. Is this
intentional?
Checking references for intended status: Informational
----------------------------------------------------------------------------
== Outdated reference: A later version (-15) exists of
draft-mcgrew-hash-sigs-04
== Outdated reference: A later version (-12) exists of
draft-irtf-cfrg-xmss-hash-based-signatures-06
-- Obsolete informational reference (is this intentional?): RFC 5246
(Obsoleted by RFC 8446)
-- Obsolete informational reference (is this intentional?): RFC 6961
(Obsoleted by RFC 8446)
Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: May 1, 2017 Internet Society
6 October 28, 2016
8 Improving the Public Key Infrastructure (PKI) for the World Wide Web
9 draft-iab-web-pki-problems-04.txt
11 Abstract
13 The Public Key Infrastructure (PKI) used for the World Wide Web (Web
14 PKI) is a vital component of trust in the Internet. In recent years,
15 there have been a number of improvements made to this infrastructure,
16 including improved certificate status checking, automation, and
17 transparency of governance. However, additional improvements are
18 necessary. This document identifies continuing areas of concern and
19 provides recommendations to the Internet community for additional
20 improvements, moving toward a more robust and secure Web PKI.
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 May 1, 2017.
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. A Brief Description of the Web PKI . . . . . . . . . . . . . 3
58 3. Improvements to the Web PKI . . . . . . . . . . . . . . . . . 4
59 3.1. Strong Cryptography . . . . . . . . . . . . . . . . . . . 4
60 3.1.1. Preparing for Quantum Computers . . . . . . . . . . . 4
61 3.1.2. Avoiding Weak Cryptography . . . . . . . . . . . . . 5
62 3.2. Support for Enterprise PKIs . . . . . . . . . . . . . . . 6
63 3.3. Web PKI in the Home . . . . . . . . . . . . . . . . . . . 8
64 3.4. Governance Improvements to the Web PKI . . . . . . . . . 10
65 4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
66 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
68 7. Informative References . . . . . . . . . . . . . . . . . . . 13
69 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
70 Appendix B. IAB Members at the Time of Approval . . . . . . . . 16
71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
73 1. Introduction
75 The Public Key Infrastructure (PKI) for the World Wide Web (Web PKI)
76 has evolved into a key component of the global Internet; it enables
77 trusted business and individual transactions. This global
78 infrastructure has been growing and evolving for many years. The
79 success of Web PKI has contributed to significant Internet growth.
80 The Web PKI impacts all aspects of our lives, and no one can imagine
81 the web without the protections that the Web PKI enables.
83 As with any maturing technology, there are several problems with the
84 current Web PKI. The Web PKI makes use of certificates as described
85 in RFC 5280 [RFC5280]. These certificates are primarily used with
86 Transport Layer Security (TLS) as described in RFC 5246 [RFC5246].
88 The economics of the Web PKI value chain are discussed in [VFBH],
89 [AV], and [AVAV]. This document does not investigate the economic
90 issues further, but these economic issues provide motivation for
91 correcting the other problems that are discussed in this document.
92 One note of caution is that the references above assume the cost of
93 acquiring a certificate is high. These costs have been decreasing in
94 recent years due to a number of factors including the Let's Encrypt
95 initiative discussed later in this document.
97 Over the years, many technical improvements have been made to the Web
98 PKI, but several challenges remain. This document offers a general
99 set of recommendations to the Internet community designed to be
100 helpful in addressing these remaining challenges.
102 2. A Brief Description of the Web PKI
104 This section provides a very brief introduction to some of the key
105 concepts of the Web PKI. It is not intended to be a full description
106 of Web PKI but rather to provide some basic concepts to help frame
107 the remaining discussion.
109 Web PKI is an infrastructure comprised of a number of PKIs that
110 enables the establishment of trust relationships between
111 communicating web entities. This trust may be chained through
112 multiple intermediate parties. The root of that trust is referred to
113 as a trust anchor. A relying party is an entity that depends upon
114 the trust provided by the infrastructure to make informed decisions.
115 A complex set of technical, policy, and legal requirements can make
116 up the qualificiations for a trust anchor in a specific situation.
118 Certificates are digitally signed structures that contain the
119 information required to communicate the trust. Certificates are
120 specified in RFC 5280 [RFC5280]. Certificates contain, among other
121 things, a subject name, a public key, a limited validity lifetime,
122 and the digital signature of the Certification Authority (CA).
123 Certificate users require confidence that the private key associated
124 with the certified public key is owned by the named subject.
126 The architectural model used in the Web PKI includes:
128 EE: End Entity -- the subject of a certificate -- certificates are
129 issued to end entities including Web servers and clients that
130 need mutual authentication.
132 CA: Certification Authority -- the issuer of a certificate --
133 issues certificates for end entities including Web servers and
134 clients.
136 RA: Registration Authority -- an optional system to which a CA
137 delegates some management functions such as identity validation
138 or physical credential distribution.
140 While in its simplest form, the Web PKI is fairly straightforward,
141 there are a number of concepts that can complicate the relationships
142 and the behavior. As mentioned already, there can be intermediate
143 certificates that represent delegation within the certification path.
144 There can be cross-signing of certificates that creates
145 multidimensional relationships. Browsers install numerous trust
146 anchors associated with many different CAs in the Web PKI. All of
147 this results in a complex ecosystem of trust relationships that
148 reflect different operational practices and underlying certificate
149 policies.
151 Certificates naturally expire since they contain a validity lifetime.
152 In some situations, a certificate needs to be revoked before it
153 expires. Revocation usually happens because the private key is lost
154 or compromised, but an intermediate CA certificate can be revoked for
155 bad behavior. All CAs are responsible for providing revocation
156 status of the certificates that they issue throughout their lifetime
157 of the certificate. Revocation status information may be provided by
158 certificate revocation lists (CRLs) [RFC5280], the Online Certificate
159 Status Protocol (OCSP) [RFC6960], or some other mechanism.
161 The enrollment process used by a CA makes sure that the subject name
162 in the certificate is appropriate and that the subject actually holds
163 the private key. The enrollment process should require the subject
164 to use the private key; this can be accomplished with PKCS#10
165 [RFC2986] or some other proof-of-possession mechanism such as
166 [RFC6955].
168 3. Improvements to the Web PKI
170 Over the years, many technical improvements have been made to the Web
171 PKI. Despite this progress, several challenges remain. This section
172 discusses several unresolved problems, and it suggests general
173 directions for tackling them.
175 3.1. Strong Cryptography
177 Quantum computers [WIKI-QC] exist today, but they are not yet able to
178 solve real world problems faster that digital computers. No one
179 knows whether a large-scale quantum computer will be invented in the
180 next decade or two that is able to break all of the public key
181 algorithms that are used in the Web PKI, but it seems prudent to
182 prepare for such a catastrophic event.
184 In the mean time, the Web PKI needs to employ cryptographic
185 algorithms that are secure against known cryptanalytic techniques and
186 advanced digital computers.
188 3.1.1. Preparing for Quantum Computers
190 Hash-based signature algorithms [HASH-S1][HASH-S2] are quantum
191 resistant, meaning that they are secure even if an attacker is able
192 to build a large-scale quantum computer. Hash-based signature
193 algorithms have small public and private keys, provide fast signing
194 and verification operation, but they have very large signature values
195 and one private key can produce a fixed number of signatures. The
196 number of signatures is set at the time the key pair is generated.
198 As a result of these properties, hash-based signature algorithms are
199 not ideal for signing certificates. However, they are well suited
200 for other uses, including signatures for software updates. The use a
201 quantum resistant signature algorithm for software updates ensures
202 that new software can be securely deployed even if a large-scale
203 quantum computer is invented during the lifetime of the system.
205 Several signature and key establishment algorithms [WIKI-PQC] are
206 being investigated that might prove to be quantum resistant and offer
207 properties that are suitable for use in the Web PKI. So far, none of
208 these algorithms has achieved wide acceptance. Further research is
209 needed.
211 While this research is underway, some security protocols allow a pre-
212 shared key (PSK) to be mixed with a symmetric key that is established
213 with a public key algorithms. If the PSK is distributed without the
214 use of a public key mechanism, the overall key establishment
215 mechanism will be quantum resistant. Consider the use of a PSK for
216 information that requires decades of confidentiality protection, such
217 as health care information.
219 The Web PKI can prepare for the for quantum computing by:
221 1. Deploy hash-based signatures for software updates.
223 2. For information that requires decades of confidentiality
224 protection, mix a pre-shared key (PSK) as part of the key
225 establishment.
227 3. Continue research on quantum resistant public key cryptography.
229 3.1.2. Avoiding Weak Cryptography
231 Several digital signature algorithms, one-way hash functions, and
232 public key sizes that were once considered strong are no longer
233 considered adequate. This is not a surprise. Cryptographic
234 algorithms age; they become weaker over time. As new cryptanalysis
235 techniques are developed and computing capabilities increase, the
236 amount of time needed to break a particular cryptographic algorithm
237 will decrease. For this reason, the algorithms and key sizes used in
238 the Web PKI need to migrate over time.
240 CAs and Browser vendors have been managing algorithm and key size
241 transitions, but it is a significant challenge to maintain a very
242 high degree of interoperability across the world wide web while
243 phasing out aged cryptographic algorithms or too small key sizes.
244 When these appear in a long-lived trust anchor or intermediate CA
245 certificate, refusal to accept them can impact a very large tree of
246 certificates. In addition, if a certificate for a web site with a
247 huge amount of traffic is in that tree, rejecting that certificate
248 may impact too many users.
250 Despite this situation, the MD5 and SHA-1 one-way hash functions have
251 been almost completely eliminated from the Web PKI, and 1024-bit RSA
252 public keys are essentially gone [MB2015] [MB2016]. It took a very
253 long time to make this happen, and trust anchors and certificates
254 that used these cryptographic algorithms were considered valid long
255 after they were widely known to be too weak.
257 Obviously, additional algorithm transitions will be needed in the
258 future. The algorithms and key sizes that are acceptable today will
259 become weaker with time. RFC 7696 [RFC7696] offers some guidelines
260 regarding cryptographic algorithm agility.
262 The Web PKI can prepare for the next transition by:
264 1. Having experts periodically evaluate the current choices of
265 algorithm and key size. While it is not possible to predict when
266 a new cryptanalysis technique will be discovered, the end of the
267 useful lifetime of most algorithms and key sizes is known many
268 years in advance.
270 2. Planning for a smooth and orderly transition from a weak
271 algorithm or key size. Experience has shown that many years are
272 needed produce to specifications, develop implementations, and
273 then deploy replacements.
275 3. Reducing the lifetime of end-entity certificates to create
276 frequent opportunities to change an algorithm or key size.
278 3.2. Support for Enterprise PKIs
280 Many enterprises operate their own PKI. These enterprises do not
281 want to be part of the traditional Web PKI, but they face many
282 challenges in order to achieve a similar user experience and level of
283 security.
285 Enterprise PKI users must install one or more enterprise trust
286 anchors in their operating system or browser. There is readily-
287 available software that can install trust anchors for use by the
288 operating system and browser, but the enterprise PKI will not be
289 trusted until the system administrator or end user does this step.
291 Enterprise PKI users often experience greater latency than tradition
292 Web PKI users. Standards-based and proprietary revocation status
293 checking approches might offer relief.
295 The Status Request extension to TLS [RFC6066] allows the web server
296 to provide status information about its certificate. By including
297 this extension in the TLS handshake, the browser asks the web server
298 to provide OCSP responses in addition to the server certificate.
299 This approach greatly reduces the latency since the browser does not
300 need to generate an OCSP request or wait for an OCSP response to
301 check the validity of the server certificate. The inclusion of a
302 time-stamped OCSP response in the TLS handshake is referred to as
303 "OCSP stapling". In addition, the MUST_STAPLE feature [TLSFEATURE]
304 can be used to insist that OCSP stapling be used.
306 While not widely implemented, the Multiple Certificate Status Request
307 extension [RFC6961] allows the web server to provide status
308 information about its own certificate and also the status of
309 intermediate certificates in the certification path, further reducing
310 latency.
312 When OCSP stapling is used by an enterprise, the OCSP responder will
313 not receive an enormous volume of OCSP requests because the web
314 servers make a few requests and the responses are passed to the
315 browsers in the TLS handshake. In addition, OCSP stapling can
316 improve user privacy, since the web server, not the browser, contacts
317 the OCSP responder. In this way, the OCSP responder is not able to
318 determine which browsers are checking the validity of certificate for
319 particular websites.
321 Some browser vendors provide a proprietary revocation checking
322 mechanism that obtains revocation status for the entire Web PKI in a
323 very compact form. This mechanism eliminates latency since no
324 network traffic is generated at the time that a certificate is being
325 validated. However, these mechanisms cover only the trust anchor
326 store for that browser vendor, excluding all enterprise PKIs. In
327 addition, measurements in 2015 [IMC2015] show that these mechanisms
328 do not currently provide adequate coverage of the Web PKI.
330 Several enterprises issue certificates to all of their employees, and
331 among other uses, these certificates are used in TLS client
332 authentication. There is not a common way to import the private key
333 and the client certificate into browsers. In fact, the private key
334 can be stored in many different formats depending on the software
335 used to generate the public/private key pair. PKCS#12 [RFC7292]
336 seems to be the most popular format at the moment. A standard way to
337 import the needed keying material and a standard format will make
338 this task much easier, and the web might enjoy an increase in mutual
339 authentication. However, please note the privacy considerations in
340 Section 5.
342 Enterprise PKIs can be better supported if:
344 1. Each enterprise PKI offers an OCSP Responder, and enterprise
345 websites make use of OCSP Stapling.
347 2. Operating system and browser vendors support a standard way to
348 install private keys and certificates for use in client
349 authentication.
351 3. In the event that browser vendors continue to offer latency-free
352 proprietary revocation status checking mechanisms, then these
353 mechanisms need to expand the coverage to all of the Web PKI and
354 offer a means to include enterprise PKIs in the coverage.
356 3.3. Web PKI in the Home
358 More and more, web protocols are being used to manage devices in the
359 home. For example, homeowners can use a web browser to connect to a
360 web site that is embedded in their home router to adjust various
361 settings. The router allows the browser to access web pages to
362 adjust these setting as long as the connection originates from the
363 home network and the proper password is provided. However, there is
364 no way for the browser to authenticate to the embedded web site.
365 Authentication of the web site is normally performed during the TLS
366 handshake, but the Web PKI is not equipped to issue certificates to
367 home routers or the many other home devices that employ embedded web
368 sites for homeowner management.
370 A solution in this environment cannot depend on the homeowner to
371 perform duties that are normally associated with a web site
372 administrator. However, some straightforward tasks could be done at
373 the time the device is installed in the home. These tasks cannot be
374 more complex than the initial setup of a new printer in the home,
375 otherwise they will be skipped or done incorrectly.
377 There are three very different approaches to certificates for home
378 devices that have been discussed over the years. In the first
379 approach, a private key and certificate are installed in the device
380 at the factory. The certificate has an unlimited lifetime. Since it
381 never expires, no homeowner action is needed to renew it. Also,
382 since the certificate never changes, the algorithms are selected by
383 the factory for the lifetime of the device. The subject name in the
384 certificate is quite generic, as it must be comprised of information
385 that is known in the factory. The subject name is often based on
386 some combination of the manufacturer, model, serial number, and MAC
387 address. While these do uniquely identify the device, they have
388 little meaning to the homeowner. A secure device identifier, as
389 defined in [IEEE802.1AR], is one example of a specification where
390 locally significant identities can be securely associated with a
391 manufacturer-provisioned device identifier.
393 In the second approach, like the first one, a private key and a
394 certificate that are installed in the device at the factory, but the
395 homeowner is unaware of them. This factory-installed certificate is
396 used only to authenticate to a CA operated by the manufacturer. At
397 the time the device is installed, the homeowner can provide a portion
398 of the subject name for the device, and the manufacturer CA can issue
399 a certificate that includes a subject name that the homeowner will
400 recognize. The certificate can be renewed without any action by the
401 homeowner at appropriate intervals. Also, following a software
402 update, the algorithms used in the TLS handshake and the certificate
403 can be updated.
405 In the third approach, which is sometimes used today in Internet of
406 Things devices, the device generates a key pair at the time the
407 device is configured for the home network, and then a controller on
408 the local network issues a certificate for the device that contains
409 the freshly generated public key and a name selected by the user. If
410 the device is passed on to another user, then a new key pair will be
411 generated and a new name can be assigned when the device is
412 configured for that user's network.
414 Section 3.1.2 of this document calls for the ability to transition
415 from weak cryptographic algorithms over time. For this reason, and
416 the ability to use a subject name that the homeowner will recognize,
417 the second or third approaches are preferred.
419 One potential problem with the second approach is continuity of
420 operations of the manufacturer CA. After the device is deployed, the
421 manufacturer might go out of business or stop offering CA services,
422 and then come time for renewal of the certificate, there will not be
423 a CA to issue the new certificate. Some people see this as a way to
424 end-of-life old equipment, but the users want to choose the end date,
425 not have one imposed upon them. One possible solution might be
426 modeled on the domain name business, where other parties will
427 continue to provide needed services if the original provider stops
428 doing so.
430 The Web PKI can prepare for the vast number of home devices that need
431 certificates by:
433 1. Building upon the work being done in the IETF ACME Working Group
434 [ACMEWG] to facilitate the automatic renewal of certificates for
435 home devices without any actions by the homeowner beyond the
436 initial device setup.
438 2. Establish conventions for the names that appear in certificates
439 that accomodate the approaches discussed above and also ensure
440 uniqueness without putting a burden on the homeowner.
442 3. Working with device manufacturers to establish scalable CAs that
443 will continue to issue certificates for the deployed devices even
444 if the manufacturer goes out of business.
446 4. Working with device manufacturers to establish OCSP Responders so
447 that the web sites that are embedded in the devices can provide
448 robust authentication and OCSP stapling in a manner that is
449 compatible with traditional web sites.
451 3.4. Governance Improvements to the Web PKI
453 As with many other technologies, Web PKI technical issues are tangled
454 up with policy and process issues. Policy and process issues have
455 evolved over time, sometimes eroding confidence and trust in the Web
456 PKI. Governance structures are needed that increase transparency and
457 trust.
459 Web PKI users are by definition asked to trust CAs. This includes
460 what CAs are trusted to do properly, and what they are trusted not to
461 do. The system for determining which CAs are added to or removed
462 from the trust anchor store in browsers is opaque and confusing to
463 most Web PKI users. The CA/Browser Forum has developed baseline
464 requirements for the management and issuance of certificates
465 [CAB2014] for individual CAs. However, the process by which an
466 individual CA gets added to the trust anchor store by each of the
467 browser vendors is somewhat mysterious. The individual browser
468 vendors determine what should and should not be trusted by including
469 the CA certificate in their trust anchor store. They do this by
470 leveraging the (###need to update or add ETSI reference) AICPA/CICA
471 WebTrust Program for Certification Authorities [WEBTRUST]. This
472 program provides auditing requirements and a trust mark for CAs that
473 meet them. Failure to pass an audit can result in the CA being
474 removed from the trust store.
476 Once the browser has shipped, regular updates may add or delete CAs.
477 This is generally not something that a user would monitor. For an
478 informed user, information about which CAs have been added to or
479 deleted from the browser trust anchor store can be found in the
480 browser release notes. Users can also examine the policies of the
481 various CAs that have been developed and posted for the WebTrust
482 Program. How does an individual, organization, or enterprise really
483 determine if a particular CA is trustworthy? Do the default choices
484 inherited from the browser vendors truly represent the organization's
485 trust model? What constitutes sufficiently bad behavior by a CA to
486 cause removal from the trust anchor store?
488 In addition, it can be hazardous for users to remove CAs from the
489 browser trust anchor store. If a user removes a CA from the browser
490 trust anchor store, some web sites may become completely inaccessible
491 or require the user to take explicit action to accept warnings or
492 bypass browser protections related to untrusted certificates.
494 The guidelines provided by the WebTrust (###ETSI?) program [WEBTRUST]
495 provide a framework for removing a CA from the trust anchor store.
496 There may be a few very large CAs that are critical to significant
497 portions of the Web PKI. Removing one of these CAs can have a
498 significant impact on a huge number of websites. As discussed in
499 briefly in Section 4, users are already struggling to understand the
500 implications of untrusted certificates, so they often ignore warnings
501 presented by the browser.
503 There are a number of organizations that play significant roles in
504 the operation of the Web PKI, including the CA/Browser Forum, the
505 WebTrust Program, and the browser vendors. These organizations act
506 on behalf of the entire Internet community; therefore, transparency
507 in these operations is fundamental to confidence and trust in the Web
508 PKI. In particular, transparency in both the CA/Browser Forum and
509 the browser vendor processes would be helpful. Recently the CA/
510 Browser Forum made some changes to their operational procedures to
511 make it easier for people to participate and to improve visibility
512 into their process [CAB1.2]. This is a significant improvement, but
513 these processes need to continue to evolve in an open, inclusive, and
514 transparent manner. Currently, as the name implies, the CA/Browser
515 Forum members primarily represent CAs and browser vendors. It would
516 be better if relying parties also have a voice in this forum.
517 Additionally, some browser vendors are more transparent in their
518 decision processes than others, and it is felt that all should be
519 more transparent.
521 Since the Web PKI is widespread, applications beyond the World Wide
522 Web are making use of the Web PKI. For example, the Web PKI is used
523 to secure connections between SMTP servers. In these environments,
524 the browser-centric capabilities are unavailable. The current
525 governance structure does not provide a way for the relying parties
526 in these applications to participate.
528 The Web PKI governance structures can be made more open and
529 transparent by:
531 1. Browser vendors providing additional visibility and tools to
532 support the management of the trust anchor store.
534 2. Governance organizations providing a way for all relying parties,
535 including ones associated with non-browser applications, to
536 participate.
538 4. Security Considerations
540 This document considers some areas for improvement of the Web PKI.
541 Some of the risks associated with doing nothing or continuing down
542 the current path are articulated. The Web PKI is a vital component
543 of a trusted Internet, and as such needs to be improved to sustain
544 continued growth of the Internet.
546 Many users find browser error messages related to certificates
547 confusing. Good man-machine interfaces are always difficult, but in
548 this situation users are unable to fully understand the risks that
549 they are accepting, and as a result they do not make informed
550 decisions about when to proceed and when to stop. This aspect of
551 browser usability has improved over the years, and there is an
552 enormous amount of ongoing work on this complex topic. It is hoped
553 that further improvements will allow users to make better security
554 choices.
556 5. Privacy Considerations
558 Client certificates can be used for mutual authentication. While
559 mutual authentication is usually consider better than unilateral
560 authentication, there is a privacy concern in this situation. When
561 mutual authentication is used, the browser sends the client
562 certificate in plaintext to the webserver in the TLS handshake. This
563 allows the browser user's identity to be tracked across many
564 different sites by anyone that can observe the traffic.
566 6. IANA Considerations
568 None.
570 {{{ RFC Editor: Please remove this section prior to publication. }}}
572 7. Informative References
574 [ACMEWG] IETF, "Charter for Automated Certificate Management
575 Environment (acme) Working Group", June 2015,
576 .
578 [AV] Arnbak, A. and N. van Eijk, "Certificate Authority
579 Collapse: Regulating Systemic Vulnerabilities in the HTTPS
580 Value Chain", 2012 TRPC , August 2012,
581 .
583 [AVAV] Asghari, H., van Eeten, M., Arnbak, A., and N. van Eijk,
584 "Security Economics in the HTTPS Value Chain", Workshop on
585 Economics of Information Security (WEIS) 2013 , 2013,
586 .
589 [CAB1.2] CA/Browser Forum, "Bylaws of the CA/Browser Forum",
590 October 2014, .
593 [CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements
594 for the Issuance and Management of Publicly-Trusted
595 Certificates, v.1.2.2", October 2014,
596 .
598 [IEEE802.1AR]
599 IEEE Standards Association, "IEEE Standard for Local and
600 Metropolitan Area Networks -- Secure Device Identity",
601 2009.
603 [HASH-S1] McGrew, D. and M. Curcio, "Hash-Based Signatures", draft-
604 mcgrew-hash-sigs-04 (work in progress), March 2016.
606 [HASH-S2] Huelsing, A., Butin, D., Gazdag, S., and A. Mohaisen,
607 "Hash-Based Signatures", draft-irtf-cfrg-xmss-hash-based-
608 signatures-06 (work in progress), July 2016.
610 [IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D.,
611 Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An
612 End-to-End Measurement of Certificate Revocation in the
613 Web's PKI", October 2015,
614 .
617 [MB2015] Wilson, K., "Phase 2: Phasing out Certificates with
618 1024-bit RSA Keys", January 2015,
619 .
622 [MB2016] Barnes, R., "Payment Processors Still Using Weak Crypto",
623 February 2016,
624 .
627 [RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
628 Request Syntax Specification Version 1.7", RFC 2986,
629 DOI 10.17487/RFC2986, November 2000,
630 .
632 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
633 (TLS) Protocol Version 1.2", RFC 5246,
634 DOI 10.17487/RFC5246, August 2008,
635 .
637 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
638 Housley, R., and W. Polk, "Internet X.509 Public Key
639 Infrastructure Certificate and Certificate Revocation List
640 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
641 .
643 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
644 Galperin, S., and C. Adams, "X.509 Internet Public Key
645 Infrastructure Online Certificate Status Protocol - OCSP",
646 RFC 6960, DOI 10.17487/RFC6960, June 2013,
647 .
649 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
650 Multiple Certificate Status Request Extension", RFC 6961,
651 DOI 10.17487/RFC6961, June 2013,
652 .
654 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
655 Extensions: Extension Definitions", RFC 6066,
656 DOI 10.17487/RFC6066, January 2011,
657 .
659 [RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
660 of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
661 May 2013, .
663 [RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
664 and M. Scott, "PKCS #12: Personal Information Exchange
665 Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
666 .
668 [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
669 Agility and Selecting Mandatory-to-Implement Algorithms",
670 BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
671 .
673 [TLSFEATURE]
674 Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft-
675 hallambaker-tlsfeature-10 (work in progress), July 2015.
677 [VFBH] Vratonjic, N., Freudiger, J., Bindschaedler, V., and J.
678 Hubaux, "The Inconvenient Truth About Web Certificates",
679 Workshop on Economics of Information Security (WEIS)
680 2011 , 2011,
681 .
684 [WEBTRUST]
685 CPA Canada, "WebTrust Program for Certification
686 Authorities", August 2015, .
689 [WIKI-PQC]
690 Wikipedia, "Post-quantum cryptography", October 2016,
691 .
693 [WIKI-QC] Wikipedia, "Quantum computing", October 2016,
694 .
696 Appendix A. Acknowledgements
698 This document has been developed within the IAB Privacy and Security
699 Program. The authors greatly appreciate the review and suggestions
700 provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet,
701 Peter Bowen, Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted
702 Hardie, Paul Hoffman, Ralph Holz, Lee Howard, Christian Huitema,
703 Eliot Lear, Xing Li, Lucy Lynch, Gervase Markham, Eric Rescorla,
704 Andrei Robachevsky, Thomas Roessler, Jeremy Rowley, Christine
705 Runnegar, Jakob Schlyter, Wendy Seltzer, Dave Thaler, Brian Trammell,
706 and Juan Carlos Zuniga.
708 Appendix B. IAB Members at the Time of Approval
710 {{{ RFC Editor: Please add the names to the IAB members at the time
711 that this document is put into the RFC Editor queue. }}}
713 Authors' Addresses
715 Russ Housley
716 Vigil Security
717 918 Spring Knoll Drive
718 Herndon, VA 20170
719 USA
721 Email: housley@vigilsec.com
723 Karen O'Donoghue
724 Internet Society
725 1775 Wiehle Ave #201
726 Reston, VA 20190
727 USA
729 Email: odonoghue@isoc.org