[Privsec-discuss] Review of draft-iab-web-pki-problems-03.txt

[Paul Hoffman <[e-mail]>]

Greetings. The following is a review of the recently-updated draft. The topic of the Web PKI is very important to the operation of the Internet, so it's very important for the IAB to get this right. As you can see from the first few comments below, there are substantial issues in the document that need to be addressed before this progresses. I look forward to a discussion here about how the document can be improved.

--Paul Hoffman

Internet Architecture Board                                   R. Housley
Internet-Draft                                            Vigil Security
Intended status: Informational                             K. O'Donoghue
Expires: March 26, 2017                                 Internet Society
                                                     September 22, 2016


Problems with the Public Key Infrastructure (PKI) for the World Wide Web
                  draft-iab-web-pki-problems-03.txt

[[ PEH: Paul Hoffman's comments start in the left column marked like this. The larger issues
with this document are given first. ]]

[[ PEH: "Topic A" -- My biggest concern is that this document repeatedly advocates that
browsers need to loosen their security standards in order to allow enterprises to get
their certificates into their users' browsers. This advice goes against almost everything
that has been discussed in the Web PKI community over the past decade. This document could
instead encourage that enterprises be able to be RAs for established CAs for names
constrained to their domain names. Instead of weakening the current Web PKI, this would
instead strengthen it by putting more emphasis on name constraints and local control for
enterprises. ]]

[[ PEH: "Topic B" -- The document mixes in discussions of client certificates as if they
were full-fledged participants in the Web PKI. Given that no browsers support them well,
that seems much more aspirational than real, and it confuses the topic. Worse, the
document doesn't weigh the known problems of client certificates against the other user
authentication mechanisms that have been deployed; such a comparison could easily lead
someone to not consider client certs that important. Please consider removing the
discussion of them in the body of the document. ]]

[[ PEH: "Topic C" -- Trust anchors are discussed later in the document, but not defined in
Section 2. The concept of a trust anchor is central to the Web PKI. In specific, the fact
that trust anchors in the Web PKI do not have name constraints is fundamental to
understanding the risks of adding new trust anchors (whereas subordinate CAs can have name
constraints applied). Trust anchors should be introduced in Section 2, and the rest of the
document should carefully describe their role in the Web PKI. ]]

Abstract

  The Public Key Infrastructure (PKI) used for the World Wide Web (Web
  PKI) is a vital component of trust in the Internet.  In recent years,
  there have been a number of improvements made to this infrastructure,
  including improved certificate status checking, automation, and
  transparency of governance.  However, additional improvements
  necessary.  This document identifies continuing areas of concerns and
  provides recommendations to the Internet community for additional
  improvements, moving toward a more robust and secure Web PKI.

Status of This Memo

  This Internet-Draft is submitted in full conformance with the
  provisions of BCP 78 and BCP 79.

  Internet-Drafts are working documents of the Internet Engineering
  Task Force (IETF).  Note that other groups may also distribute
  working documents as Internet-Drafts.  The list of current Internet-
  Drafts is at http://datatracker.ietf.org/drafts/current/.

  Internet-Drafts are draft documents valid for a maximum of six months
  and may be updated, replaced, or obsoleted by other documents at any
  time.  It is inappropriate to use Internet-Drafts as reference
  material or to cite them other than as "work in progress."

  This Internet-Draft will expire on March 26, 2017.

Copyright Notice

  Copyright (c) 2016 IETF Trust and the persons identified as the
  document authors.  All rights reserved.

  This document is subject to BCP 78 and the IETF Trust's Legal
  Provisions Relating to IETF Documents
  (http://trustee.ietf.org/license-info) in effect on the date of
  publication of this document.  Please review these documents
  carefully, as they describe your rights and restrictions with respect



Housley & O'Donoghue     Expires March 26, 2017                 [Page 1]
Internet-Draft              Web PKI Problems              September 2016


  to this document.  Code Components extracted from this document must
  include Simplified BSD License text as described in Section 4.e of
  the Trust Legal Provisions and are provided without warranty as
  described in the Simplified BSD License.

Table of Contents

  1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
  2.  Very Brief Description of the Web PKI . . . . . . . . . . . .   2
  3.  Improvements to the Web PKI . . . . . . . . . . . . . . . . .   3
    3.1.  Weak Cryptographic Algorithms or Short Public Keys  . . .   3
    3.2.  Support for Enterprise PKIs . . . . . . . . . . . . . . .   4
    3.3.  Web PKI in the Home . . . . . . . . . . . . . . . . . . .   6
    3.4.  Browser Error Messages  . . . . . . . . . . . . . . . . .   8
    3.5.  Governance Improvements to the Web PKI  . . . . . . . . .   8
  4.  Security Considerations . . . . . . . . . . . . . . . . . . .  10
  5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
  6.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
    6.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
    6.2.  Informative References  . . . . . . . . . . . . . . . . .  11
  Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .  13
  Appendix B.  IAB Members at the Time of Approval  . . . . . . . .  13
  Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

  There are many interrelated problems with the current Public Key
  Infrastructure (PKI) used for the World Wide Web (Web PKI).  The Web
  PKI makes use of certificates as described in RFC 5280 [RFC5280].
  These certificates are primarily used with Transport Layer Security
  (TLS) as described in RFC 5246 [RFC5246].

  The economics of the Web PKI value chain are discussed in [VFBH],
  [AV], and [AVAV].

[[ Those articles are all pretty old, and they all seem to assume that getting a
certificate will have a financial cost to the EE. That is certainly no longer true, and
hasn't been for a few years. Either you should include more modern economic papers or at
least say that the assumption that web certificates costs money is a limitation of those
references. ]]

  This document does not discuss the economic issues
  further, but these economic issues provide motivation for correcting
  the other problems that are discussed in this document.

[[ PEH: Section 3.5 is very definitely about economic issues. Improved governance is
directly tied to the economics of (first) setting up a new CA and (second) maintaining the
CA at the expected level of security. ]]

  Over the years, many technical improvements have been made to the Web
  PKI, but several challenges remain.  This document offers a general
  set of recommendations to the Internet community that might be
  helpful in addressing these remaining challenges.

[[ PEH: See Topic B. Putting a short paragraph here saying why client certificates are not
discussed would be useful. ]]

2.  Very Brief Description of the Web PKI

  Certificates are specified in RFC 5280 [RFC5280].  Certificates
  contain, among other things, a subject name, a public key, a limited
  valid lifetime, and the digital signature of the Certification
  Authority (CA).  Certificate users require confidence that the



Housley & O'Donoghue     Expires March 26, 2017                 [Page 2]
Internet-Draft              Web PKI Problems              September 2016


  private key associated with the certified public key is owned by the
  named subject.

[[ PEH: This does not clearly state that for servers, the "name" is the domain name(s)
that the server can be accessed at. Without this information, a reader might not
understand that the Web PKI is tightly associated with the domain name system. ]]

  The architectural model used in the Web PKI includes:

  EE:   End Entity -- the subject of a certificate -- certificates are
        issued to end entities including Web servers and clients that
        need mutual authentication.

  CA:   Certification Authority -- the issuer of a certificate --
        issues certificates for end entities including Web servers and
        clients.

  RA:   Registration Authority -- an optional system to which a CA
        delegates some management functions such as identity validation
        or physical credential distribution.

[[ PEH: RAs are widely misunderstood: even RFC 5280 barely describes them. They are often
thought of as intermediate CAs, but they are not. Please strongly consider removing them
from this document and instead. ]]

[[ PEH: This discussion, and the rest of the document, ignores name constraints. However,
name constraints have a huge impact on the solutions proposed for enterprises. A short
description should go here. ]]

  A valid certificate may be revoked for any number of reasons.  CAs
  are responsible for indicating the revocation status of the
  certificates that they issue throughout the lifetime of the
  certificate.  Revocation status information may be provided using the
  Online Certificate Status Protocol (OCSP) [RFC6960], certificate
  revocation lists (CRLs) [RFC5280], or some other mechanism.  

[[ PEH: This sentence should definite talk about OCSP stapling. ]]

  In
  general, when revocation status information is provided using CRLs,
  the CA is also the CRL issuer.  However, a CA may delegate the
  responsibility for issuing CRLs to a different entity.

  The enrollment process used by a CA makes sure that the subject name
  in the certificate is appropriate and that the subject actually holds
  the private key.  Proof of possession of the private key is often
  accomplished through a challenge-response protocol.

3.  Improvements to the Web PKI

  Over the years, many technical improvements have been made to the Web
  PKI.  Despite this progress, several challenges remain.  This section
  discusses several unresolved problems, and it suggests general
  directions for tackling them.

3.1.  Weak Cryptographic Algorithms or Short Public Keys

  Several digital signature algorithms, one-way hash functions, and
  public key sizes that were once considered strong are no longer
  considered adequate.  This is not a surprise.  Cryptographic
  algorithms age; they become weaker over time.  As new cryptanalysis
  techniques are developed and computing capabilities increase, the
  amount of time needed to break a particular cryptographic algorithm




Housley & O'Donoghue     Expires March 26, 2017                 [Page 3]
Internet-Draft              Web PKI Problems              September 2016


  will decrease.  For this reason, the algorithms and key sizes used in
  the Web PKI need to migrate over time.

  Browser vendors have been trying to manage algorithm and key size
  transitions.  It is a significant challenge to maintain a very high
  degree of interoperability across the world wide web while phasing

[[ PEH: Nit: World Wide Web ]]

  out aged cryptographic algorithm or too small key size.  When these
  appear in a long-lived trust anchor or intermediate CA certificate,
  refusal to accept them can impact a very large certificate subtree.
  In addition, if a certificate for a web site with a huge amount of
  traffic is in that subtree, rejecting that certificate may impact too
  many users.

[[ PEH: This discussion glosses over the difference between algorithm changes in trust
anchors, CA, and EE certs. Some browsers have different requirements at different times
for those, so describing how they differ here is important. A discussion that a "stronger"
CA can sign "weaker" certs is also important. ]]

  Despite this situation, the MD5 and SHA-1 one-way hash functions have
  been almost completely eliminated from the Web PKI, and 1024-bit RSA
  public keys are essentially gone [MB2015] [MB2016].  It took a very
  long time to make this happen, and trust anchors and certificates
  that used these cryptographic algorithms were considered valid long
  after they were widely known to be too weak.

  Obviously, additional algorithm transitions will be needed in the
  future.  The algorithms and key sizes that are acceptable today will
  become weaker with time.  [RFC7696] offers some guidelines regarding
  cryptographic algorithm agility.

  The Web PKI can prepare for the next transition by:

  1.  Having experts periodically evaluate the current choices of
      algorithm and key size.  While it is not possible to predict when
      a new cryptanalysis technique will be discovered, the end of the
      useful lifetime of most algorithms and key sizes is known many
      years in advance.

  2.  Planning for a smooth and orderly transition from a weak
      algorithm or key size.  Experience has shown that many years are
      needed produce to specifications, develop implementations, and
      then deploy replacements.

[[ PEH: This should call out that the transition might need to be made for both the trust
anchors as well as CA, and EE certs. ]]

  3.  Reducing the lifetime of certificates, especially intermediate CA
      certificates, to create frequent opportunities to change an
      algorithm or key size.

3.2.  Support for Enterprise PKIs

  Many enterprises operate their own PKI.  These enterprises do not
  want to be part of the traditional Web PKI, but they face many
  challenges in order to achieve a similar user experience and level of
  security.



Housley & O'Donoghue     Expires March 26, 2017                 [Page 4]
Internet-Draft              Web PKI Problems              September 2016


  Users must install the trust anchor or trust anchors for the
  enterprise PKI in their browser.  There is not a standard way to
  accomplish trust anchor installation, and users are often faced with
  scary warnings in the process of the installation.

[[ PEH: The "scary" warnings have proven to be important to prevent unsuspecting users
from installing new trust anchors from untrusted parties. Similarly, the sentence makes it
sound like there should be a standard way to install trust anchors, and yet there is well
over a decade of agreement that doing so would hurt users. This section really needs to be
reworded to acknowledge the problems of installing random trust anchors and why it would
be better to instead use RAs with name constraints. See Topic A. ]]

  Enterprise PKI users often experience greater latency than tradition

[[ PEH: Nit: traditional ]]

  Web PKI users.  Some browser vendors provide a proprietary revocation
  checking mechanism that obtains revocation status for the entire Web
  PKI in a very compact form.  This mechanism eliminates latency since
  no network traffic is generated at the time that a certificate is
  being validated.  However, these mechanisms cover only the trust
  anchor store for that browser vendor, excluding all enterprise PKIs.
  In addition, measurements in 2015 [IMC2015] show that these
  mechanisms do not currently provide adequate coverage of the Web PKI.

  RFC 6961 [RFC6961] defines the TLS Multiple Certificate Status
  Request extension, which allows the web server to provide status
  information about its own certificate and also the status of
  intermediate certificates in the certification path.  By including
  this extension in the TLS handshake, the browser asks the web server
  to provide OCSP responses in addition to the server certificate.
  This approach greatly reduces the latency since the browser does not
  need to generate any OCSP requests or wait for any OCSP responses.

  The provision of the time-stamped OCSP response in the TLS handshake
  is referred to as "stapling" the OCSP response to the TLS handshake.
  If the browser does not receive a stapled OCSP response, it can
  contact the OCSP responder directly.  In addition, the MUST_STAPLE
  feature [TLSFEATURE] can be used to insist that OCSP stapling be
  used.

[[ PEH: That document became RFC 7633. ]]

  When every browser that connects to a high volume website performs
  its own OCSP lookup, the OCSP responder must handle a large volume of
  OCSP requests in real-time.  OCSP stapling can avoid enormous volumes
  of OCSP requests for certificates of popular websites, so stapling
  can significantly reduce the cost of providing an OCSP service.

  OCSP stapling can also improve user privacy, since the web server,
  not the browser, contacts the OCSP responder.  In this way, the OCSP
  responder is not able to determine which browsers are checking the
  validity of certificate for particular websites.

  Several enterprises issue certificates to all of their employees, and

[[ PEH: This paragraph is about client certificates, so should be clearer about that. 
It should preferably be removed; see Topic B. ]]

  among other uses, these certificates are used in TLS client
  authentication.  There is not a common way to import the private key
  and the client certificate into browsers.  In fact, the private key
  can be stored in many different formats depending on the software
  used to generate the public/private key pair.  PKCS#12 [RFC7292]



Housley & O'Donoghue     Expires March 26, 2017                 [Page 5]
Internet-Draft              Web PKI Problems              September 2016


  seems to be the most popular format at the moment.  A standard way to
  import the needed keying material and a standard format will make
  this task much easier, and the World Wide Web might enjoy an increase
  in mutual authentication.

  Enterprise PKIs can be better supported if:

  1.  Each enterprise PKI offers an OCSP Responder, and web sites with
      certificates from the enterprise PKI make use of OCSP Stapling.

  2.  Browser vendors support a standard way for the trust anchors for
      the enterprise PKI to be installed.

[[ PEH: There are no name constraints on trust anchors, and giving enterprises an easy way
to become fully-trusted partners in the Web PKI will lead to lower security. See Topic A. ]]

  3.  Browser vendors support a standard way to install private keys
      and certificates for use in client authentication.

[[ PEH: This conclusion isn't supported in the arguments above. Given the UI problems with
client certificates, you need to either show how they are better than current forms of
authentication or remove this bullet; I suggest the latter. See Topic B. ]]

  4.  In the event that browser vendors continue to offer latency-free
      proprietary revocation status checking mechanisms, then these
      mechanisms need to expand the coverage to all of the Web PKI and
      offer a means to include enterprise PKIs in the coverage.

[[ PEH: This bullet should be removed. See Topic A. ]]

3.3.  Web PKI in the Home

[[ PEH: This section would be a lot more understandable if you explained why a home router
could not get a normal Web PKI cert. A short explanation of private address space and NATs
will go a long way here. ]]

  More and more, web protocols are being used to manage devices in the
  home.  For example, homeowners can use a web browser to connect to a
  web site that is embedded in their home router to adjust various
  settings.  The router allows the browser to access web pages to
  adjust these setting as long as the connection originates from the
  home network and the proper password is provided.  However, there is
  no way for the browser to authenticate to the embedded web site.
  Authentication of the web site is normally performed during the TLS
  handshake, but the Web PKI is not equipped to issue certificates to
  home routers or the many other home devices that employ embedded web
  sites for homeowner management.

  A solution in this environment must not depend on the homeowner to
  perform duties that are normally associated with a web site
  administrator.  However, some straightforward tasks could be done at
  the time the device is installed in the home.  These task cannot be

[[ PEH: Nit: These tasks ]]

  more complex that the initial setup of a new printer in the home,
  otherwise they will be skipped or done incorrectly.

  There are two very different approaches to certificates for home
  devices that have been discussed over the years.  In the first
  approach, a private key and certificate are installed in the device
  at the factory.  The certificate has an unlimited lifetime.  Since it
  never expires, no homeowner action is needed to renew it.  Also,
  since the certificate never changes, the algorithms are selected by



Housley & O'Donoghue     Expires March 26, 2017                 [Page 6]
Internet-Draft              Web PKI Problems              September 2016


  the factory for the lifetime of the device.  The subject name in the
  certificate is quite generic, as it must be comprised of information
  that is known in the factory.  The subject name is often based on
  some combination of the manufacturer, model, serial number, and MAC
  address.  While these do uniquely identify the device, they have
  little meaning to the homeowner.

  In the second approach, like the first one, a private key and a
  certificate that are installed in the device at the factory, but the
  homeowner is unaware of them.  This factory-installed certificate is
  used only to authenticate to a CA operated by the manufacturer.  At
  the time the device is installed, the homeowner can provide a portion
  of the subject name for the device, and the manufacturer CA can issue
  a certificate that includes a subject name that the homeowner will
  recognize.  The certificate can be renewed without any action by the
  homeowner at appropriate intervals.  Also, following a software
  update, the algorithms used in the TLS handshake and the certificate
  can be updated.

  Section 3.1 of this document calls for the ability to transition from
  weak cryptographic algorithms over time.  For this reason, and the
  ability to use a subject name that the homeowner will recognize, the
  second approach is preferred.

  One potential problem with the second approach is continuity of
  operations of the manufacturer CA.  After the device is deployed, the
  manufacturer might go out of business,

[[ PEH: or simply decide that being a CA for their devices is too expensive, ]]

  and then come time for renewal
  of the certificate, there will not be a CA to issue the new
  certificate.  One possible solution might be modeled on the domain
  name business, where other parties will continue to provide needed
  services if the original provider goes out of business.

  The Web PKI can prepare for the vast number of home devices that need
  certificates by:

  1.  Building upon the work being done in the IETF ACME Working Group
      [ACMEWG] to facilitate the automatic renewal of certificates for
      home devices without any actions by the homeowner beyond the
      initial device setup.

  2.  Working with device manufacturers to establish scalable CAs that
      will continue to issue certificates for the deployed devices even
      if the manufacture goes out of business.

[[ PEH: Maybe replace "goes out of business" with "stops being a CA" ]]

  3.  Working with device manufacturers to establish OCSP Responders so
      that the web sites that are embedded in the devices can provide
      robust authentication and OCSP stapling in a manner that is
      compatible with traditional web sites.



Housley & O'Donoghue     Expires March 26, 2017                 [Page 7]
Internet-Draft              Web PKI Problems              September 2016


3.4.  Browser Error Messages

  Many users find browser error messages related to certificates
  confusing.  Good man-machine interfaces are always difficult, but in
  this situation users are unable to fully understand the risks that
  they are accepting, and as a result they do not make informed
  decisions about when to proceed and when to stop.  This aspect of
  browser usability needs to be improved for users to make better
  security choices.

  Browser users have been trained to ignore warnings, making them
  ineffective.  Further, solving the error message situation in
  isolation is probably not possible; instead, it needs to be
  considered along side the other issues raised in this document.
  Browser users have been trained to find a way around any error, and
  very often, the error is the result of web server misconfiguration,
  and it does not actually present a risk to the browser user.

  If the risk to the user is high, then the session should be closed
  with a clear description of the problem that was encountered.  Doing
  so will lead to improved management of the overall Web infrastructure
  over time, especially as the tools that are being developed for web
  server administrators are rolled out.

  In some enterprises, avoiding these errors requires the addition of
  enterprise-specific trust anchors to the browser.  Additional tools
  are needed to allow administrations to easily add appropriate trust
  anchors, especially browsers on consumer devices as more and more
  enterprises are embracing bring-your-own-device policies.

[[ PEH: Solving this problem by weakening the security model is inappropriate. It can be
instead solved by allowing constrained RAs. See Topic A.  ]]

  The Web PKI can simplify user choice and improve user actions by:

  1.  Browser vendors providing additional intelligence to eliminate
      the majority of certificate warnings, only prompting the user
      when there is likely to be a risk.

[[ PEH: Browser vendors have worked on this for wall over a decade and where we are now is
the best they can do. Unless you give examples of what they have missed in all that time,
this bullet point is out of place. ]]

  2.  Browser vendors improving error messages to clearly indicate the
      risk that the user is accepting if they proceed.

[[ PEH: The IETF and W3C have tried to clearly describe the risks in a way that typical
users can understand, and both have failed. The IETF's most recent attempt, the WPKOPS
Working Group, completely fizzled. This bullet point makes it sound like the browser
vendors haven't tried hard enough. If we can't do it, it is inappropriate to put the onus
on browser vendors. ]]

3.5.  Governance Improvements to the Web PKI

  As with many other technologies, Web PKI technical issues are tangled
  up with policy and process issues.  Policy and process issues have
  evolved over time, sometimes eroding confidence and trust in the Web
  PKI.  Governance structures are needed that increase transparency and
  trust.





Housley & O'Donoghue     Expires March 26, 2017                 [Page 8]
Internet-Draft              Web PKI Problems              September 2016


  Web PKI users are by definition asked to trust CAs.  This includes
  what CAs are trusted to do properly, and what they are trusted not to
  do.  The system for determining which CAs are added to or removed
  from the trust anchor store in browsers is opaque and confusing to
  most Web PKI users.  The CA/Browser Forum 

[[ PEH: A URL reference should go here. ]]

  has developed baseline
  requirements for the management and issuance of certificates
  [CAB2014] for individual CAs.  However, the process by which an
  individual CA gets added to 

[[ PEH: and removed from ]]

  the trust anchor store by each of the
  browsers vendors is not straightforward.  The individual browser
  vendors determine what should and should not be trusted by including
  the CA certificate in their trust anchor store.  They do this 

[[ PEH: This makes it sound like the only thing they do is use WebTrust. Maybe reword
this to "One of the many considerations they use to do this is " ]]

  by
  leveraging the AICPA/CICA WebTrust Program for Certification
  Authorities [WEBTRUST].  This program provides auditing requirements
  and a trust mark for CAs that meet them.  Failure to pass an audit
  can result in the CA being removed from the trust store.

  Once the browser has shipped, how does a user know which CAs are
  trusted or what has changed recently?  For an informed user,
  information about which CAs have been added to or deleted from the
  browser trust anchor store can be found in the browser release notes.
  Users can also examine the policies of the various CAs that have been
  developed and posted for the WebTrust Program.  However, this is a
  very high barrier for the average user.  There are options to make
  local modifications by educated users, but there is little
  understanding about the implications of these choices.  How does an
  individual, organization, or enterprise really determine if a
  particular CA is trustworthy?  Do the default choices inherited from
  the browser vendors truly represent the organization's trust model?
  What constitutes sufficiently bad behavior by a CA to cause removal
  from the trust anchor store?

  In addition, it can be hazardous for users to remove CAs from the
  browser trust anchor store.  If a user removes a CA from the browser
  trust anchor store, some web sites may become completely inaccessible
  or require the user to take explicit action to accept warnings or
  bypass browser protections related to untrusted certificates.

  The guidelines provided by the WebTrust program [WEBTRUST] provide a
  framework for removing a CA from the trust anchor store.  There may
  be a few very large CAs that are critical to significant portions of
  World Wide Web infrastructure.  Removing one of these CAs can have a
  significant impact on a huge number of websites.  As discussed in
  Section 3.4, users are already struggling to understand the
  implications of untrusted certificates, so they often ignore warnings
  presented by the browser.

  There are a number of organizations that play significant roles in
  the operation of the Web PKI, including the CA/Browser Forum, the



Housley & O'Donoghue     Expires March 26, 2017                 [Page 9]
Internet-Draft              Web PKI Problems              September 2016


  WebTrust Program, and the browser vendors.  These organizations act
  on behalf of the entire Internet community; therefore, transparency
  in these operations is fundamental to confidence and trust in the Web
  PKI.  Recently the CA/Browser Forum made some changes to their
  operational procedures to make it easier for people to participate
  and to improve visibility into their process [CAB1.2].  

[[ PEH: This deeply overstates the situation. If you go to the CABForum web site, there is
absolutely no indication of how "people" can do this. It is only mentioned in their
by-laws, nowhere else. Better wording would be "...procedures to allow people..." ]]

  This is a
  significant improvement, but these processes need to continue to
  evolve in an open, inclusive, and transparent manner.  Currently, as
  the name implies, the CA/Browser Forum members primarily represent
  CAs and browser vendors.  It would be better if relying parties also
  have a voice in this forum.

  Since the Web PKI is widespread, applications beyond the World Wide
  Web are making use of the Web PKI.  For example, the Web PKI is used
  to secure connections between SMTP servers.  In these environments,
  the browser-centric capabilities are unavailable.  The current
  governance structure does not provide a way for the relying parties
  in these applications to participate.

  The Web PKI governance structures can be made more open and
  transparent by:

  1.  Browser vendors providing additional visibility and tools to
      support the management of the trust anchor store.

  2.  Governance organizations providing a way for all relying parties,
      including ones associated with non-browser applications, to
      participate.

4.  Security Considerations

  This document considers the weaknesses of the current Web PKI system
  and provides recommendations for improvements.  Some of the risks
  associated with doing nothing or continuing down the current path are
  articulated.  The Web PKI is a vital component of a trusted Internet,
  and as such needs to be improved to sustain continued growth of the
  Internet.

5.  IANA Considerations

  None.

  {{{ RFC Editor: Please remove this section prior to publication. }}}








Housley & O'Donoghue     Expires March 26, 2017                [Page 10]
Internet-Draft              Web PKI Problems              September 2016


6.  References

6.1.  Normative References

  [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
             Housley, R., and W. Polk, "Internet X.509 Public Key
             Infrastructure Certificate and Certificate Revocation List
             (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
             <http://www.rfc-editor.org/info/rfc5280>.

  [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
             Galperin, S., and C. Adams, "X.509 Internet Public Key
             Infrastructure Online Certificate Status Protocol - OCSP",
             RFC 6960, DOI 10.17487/RFC6960, June 2013,
             <http://www.rfc-editor.org/info/rfc6960>.

6.2.  Informative References

  [ACMEWG]   IETF, "Charter for Automated Certificate Management
             Environment (acme) Working Group", June 2015,
             <https://datatracker.ietf.org/doc/charter-ietf-acme/>.

  [AV]       Arnbak, A. and N. van Eijk, "Certificate Authority
             Collapse: Regulating Systemic Vulnerabilities in the HTTPS
             Value Chain", 2012 TRPC , August 2012,
             <http://dx.doi.org/10.2139/ssrn.2031409>.

  [AVAV]     Asghari, H., van Eeten, M., Arnbak, A., and N. van Eijk,
             "Security Economics in the HTTPS Value Chain", Workshop on
             Economics of Information Security (WEIS) 2013 , 2013,
             <http://www.econinfosec.org/archive/weis2013/papers/
             AsghariWEIS2013.pdf>.

  [CAB1.2]   CA/Browser Forum, "Bylaws of the CA/Browser Forum",
             October 2014, <https://cabforum.org/wp-content/uploads/CA-
             Browser-Forum-Bylaws-v.1.2.pdf>.

  [CAB2014]  CA/Browser Forum, "CA/Browser Forum Baseline Requirements
             for the Issuance and Management of Publicly-Trusted
             Certificates, v.1.2.2", October 2014,
             <https://cabforum.org/wp-content/uploads/BRv1.2.2.pdf>.

  [IMC2015]  Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D.,
             Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An
             End-to-End Measurement of Certificate Revocation in the
             Web's PKI", October 2015,
             <http://conferences2.sigcomm.org/imc/2015/papers/
             p183.pdf>.



Housley & O'Donoghue     Expires March 26, 2017                [Page 11]
Internet-Draft              Web PKI Problems              September 2016


  [MB2015]   Wilson, K., "Phase 2: Phasing out Certificates with
             1024-bit RSA Keys", January 2015,
             <https://blog.mozilla.org/security/2015/01/28/phase-2-
             phasing-out-certificates-with-1024-bit-rsa-keys/>.

  [MB2016]   Barnes, R., "Payment Processors Still Using Weak Crypto",
             February 2016,
             <https://blog.mozilla.org/security/2016/02/24/payment-
             processors-still-using-weak-crypto/>.

  [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
             (TLS) Protocol Version 1.2", RFC 5246,
             DOI 10.17487/RFC5246, August 2008,
             <http://www.rfc-editor.org/info/rfc5246>.

  [RFC6961]  Pettersen, Y., "The Transport Layer Security (TLS)
             Multiple Certificate Status Request Extension", RFC 6961,
             DOI 10.17487/RFC6961, June 2013,
             <http://www.rfc-editor.org/info/rfc6961>.

  [RFC7292]  Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
             and M. Scott, "PKCS #12: Personal Information Exchange
             Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
             <http://www.rfc-editor.org/info/rfc7292>.

  [RFC7696]  Housley, R., "Guidelines for Cryptographic Algorithm
             Agility and Selecting Mandatory-to-Implement Algorithms",
             BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
             <http://www.rfc-editor.org/info/rfc7696>.

  [TLSFEATURE]
             Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft-
             hallambaker-tlsfeature-10 (work in progress), July 2015.

[[ PEH: That document became RFC 7633. ]]

  [VFBH]     Vratonjic, N., Freudiger, J., Bindschaedler, V., and J.
             Hubaux, "The Inconvenient Truth About Web Certificates",
             Workshop on Economics of Information Security (WEIS)
             2011 , 2011,
             <http://www.econinfosec.org/archive/weis2011/papers/The%20
             Inconvenient%20Truth%20about%20Web%20Certificates.pdf>.

  [WEBTRUST]
             CPA Canada, "WebTrust Program for Certification
             Authorities", August 2015, <http://www.webtrust.org/
             homepage-documents/item27839.aspx>.






Housley & O'Donoghue     Expires March 26, 2017                [Page 12]
Internet-Draft              Web PKI Problems              September 2016


Appendix A.  Acknowledgements

  This document has been developed within the IAB Privacy and Security
  Program.  The authors greatly appreciate the review and suggestions
  provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet,
  Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie,
  Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy
  Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy
  Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian
  Trammell, and Juan Carlos Zuniga.

Appendix B.  IAB Members at the Time of Approval

  {{{ RFC Editor: Please add the names to the IAB members at the time
  that this document is put into the RFC Editor queue. }}}

Authors' Addresses

  Russ Housley
  Vigil Security
  918 Spring Knoll Drive
  Herndon, VA  20170
  USA

  Email: [e-mail]


  Karen O'Donoghue
  Internet Society
  1775 Wiehle Ave #201
  Reston, VA  20190
  USA

  Email: [e-mail]

















Housley & O'Donoghue     Expires March 26, 2017                [Page 13]