wdiff draft-iab-web-pki-problems-02.txt draft-iab-web-pki-problems-03.txt

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

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

Abstract

This document describes some of the challenges facing the current

The Public Key Infrastructure (PKI) used for the World Wide Web (Web
PKI)
and considers promising improvements to address these challenges.
Technical, process, and policy improvements to is a vital component of trust in the WebPKI are
considered. Internet. In addition, some technical considerations beyond WebPKI
itself are considered. Hopefully the content 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 will
help drive identifies continuing areas of concerns and
provides recommendations to the Internet community for additional
improvements, moving toward wide spread adoption of some
of the highlighted recommendations. 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 November 13, 2016. March 26, 2017.

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
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 . . . . . . . . . . . . 3 2
3. Technical Improvements to the Web PKI . . . . . . . . . . . . 4 . . . . . 3
3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 4 3
3.2. Certificate Status Checking . . . . . . . . . . . . . . . 5
3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 6
3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 6
3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 6
3.2.4. OCSP Stapling . . . . . Support for Enterprise PKIs . . . . . . . . . . . . . . . 7 4
3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 8
3.3.1. Certificate Authority Authorization (CAA) . . . . . . 9
3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 9
3.3.3. HTTP Strict Transport Security (HSTS) . . . . . . . . 10
3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 10
3.3.5. Certificate Transparency . . . . . . . . . . . . . . 11
3.4. Automation for Server Administrators . . . . . . . . . . 12
4. Policy and Process Improvements to the Web PKI . . . . . . . 13
4.1. Determination of the Trusted Certificate Authorities . . 13
4.2. Price for Certificates . . . . . . . . . . . . . . . . . 14
4.3. Governance Structures for in the Web PKI . Home . . . . . . . . . 15
5. Additional Technical Considerations . . . . . . . . . . . . . 15
5.1. 6
3.4. Browser Error Messages . . . . . . . . . . . . . . . . . 15
5.2. Time Synchronization . . . . . . . . . . . . . . . . . . 16
6. Recommendations for Improving 8
3.5. Governance Improvements to the Web PKI . . . . . . . . . . 16
7. 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
8. 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9. 10
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.1. 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 18
9.2. 11
6.2. Informative References . . . . . . . . . . . . . . . . . 18 11
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22 13
Appendix B. IAB Members at the Time of Approval . . . . . . . . 22 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 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]. 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.

Over the years, many technical improvements have been made to the Web
PKI, but several challenges remain. This document describes technical, usability, process, and policy
problems, considers some emerging technical improvements, discusses
some evoling process and policy improvements, and provides some basic offers a general
set of recommendations for to the Internet community. community that might be
helpful in addressing these remaining challenges.

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
private key associated with the certified public key is owned by the
named subject.

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.

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) RFC 6960 [RFC6960], certificate
revocation lists (CRLs) RFC 5280 [RFC5280], or some other mechanism. 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. Technical 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 problems unresolved problems, and the technical
improvements that have been made to address them. This history sets
the stage for suggestions it suggests general
directions for additional improvements in other
sections of this document. tackling them.

3.1. Weak Cryptographic Algorithms or Short Public Keys

Over the years, the

Several digital signature algorithms, one-way hash functions, and
public key sizes that are were once considered strong have
changed. are no longer
considered adequate. This is not a surprise. Cryptographic
algorithms age; they become weaker with over time. As new cryptanalysis
techniques are developed and computing capabilities improve, increase, the work factor
amount of time needed to break a particular cryptographic algorithm
will reduce. decrease. For this reason, the algorithms and key sizes used in
the Web PKI need to migrate over time. A reasonable choice of algorithm or key size
needs to be reevaluated periodically, and a transition may be needed
before the expected lifetime expires.

The browser

Browser vendors have been trying to manage algorithm and key size
transitions, but
transitions. It is a long-lived trust anchor or intermediate CA
certificate can have significant challenge to maintain a huge number very high
degree of certificates under it. So,
removing one certificate because it uses a weak interoperability across the world wide web while phasing
out aged cryptographic algorithm or a short public too small key can have size. When these
appear in a significant long-lived trust anchor or intermediate CA certificate,
refusal to accept them can impact on a very large certificate subtree.
In addition, if a certificate for a web site with a huge amount of
traffic is in that subtree, it will increase the
difficulty in removing the rejecting that certificate with a weak cryptographic
algorithm or a short public key.

As a result, some valid trust anchors and certificates contain
cryptographic algorithms long after weaknesses have been discovered
and widely known. Similarly, valid trust anchors and certificates
contain public keys after computational resources available to
attackers have rendered them may impact too weak. We have seen a very
successful migration away from certificates that use
many users.

Despite this situation, the MD2 or MD5 and SHA-1 one-way hash functions. However, there are still a number of
certificates that use SHA-1 functions have
been almost completely eliminated from the Web PKI, and 1024-bit RSA
public keys are essentially gone [MB2015]
[MB2016], and these certificates should be replaced.

Today, the algorithms and key sizes used by a CA to sign end-entity
certificates with a traditional lifespan of [MB2016]. It took a year should offer 112 very
long time to 128 bits of security. SHA-256 is a widely studied one-way hash
function that meets this requirement. RSA with a public key of at
least 2048 bits or ECDSA with a public key of at least 256 bits are
widely studied digital signature algorithms that meet make this
requirement.

The algorithms happen, and trust anchors and key sizes used by a CA to sign long-lived
intermediate CA certificates
that often have a lifespan of several
decades should offer even greater security. SHA-384 is a widely
studied one-way hash function that meets this requirement. RSA with
a public key of at least 3072 bits or ECDSA with a public key of at
least 384 bits are widely studied digital signature used these cryptographic algorithms that
meet this requirement. were considered valid long
after they were widely known to be too weak.

Obviously, additional algorithm transitions will be needed in the
future as these
future. The algorithms age. These algorithms, like the ones and key sizes that
were used earlier, are acceptable today will
become weaker with time. RFC 7696 [RFC7696] offers some guidelines regarding
cryptographic algorithm agility.

3.2. Certificate Status Checking

Several years ago, many browsers did not perform certificate status
checks by default. That is, browsers did not check whether the
issuing CA had revoked the certificate unless the user explicitly
adjusted a setting to enable this feature. This check can be made by
fetching the most recent certificate revocation list (CRL) RFC 5280
[RFC5280], or this check can use the Online Certificate Status
Protocol (OCSP) RFC 6960 [RFC6960].

The location of the CRL or Web PKI can prepare for the
OCSP responder is usually found in next transition by:

1. Having experts periodically evaluate the certificate itself. However,
both current choices of these approaches add latency. The desire to provide a
responsive user experience is a significant reason that this feature
has not been turned on by default. Mobile browsers simply do not
bother to check revocation status [IMC2015].

Certificate status checking needs to be used at all times. Several
techniques have been tried by CAs and browsers to make certificate
status checking more efficient. Many CAs are using Content Delivery
Networks (CDNs) to deliver CRLs and OCSP responses, resulting in very
high availability
algorithm and low latency. Yet, browser vendors are still
reluctant to perform standard-based status checking by default for
every session.

Certificate status checking by the browser can reveal the web sites
that the browser user key size. While it is visiting not possible to the OCSP Responder or the server
providing the CRL. This privacy concern can predict when
a new cryptanalysis technique will be eliminated by having
the Web Server include the OCSP Response in discovered, the TLS handshake. This
is called OCSP Stapling, and it is discussed further in
Section 3.2.4.

Measurements in 2015 [IMC2015] show that a surprisingly large
fraction end of Web PKI certicates have been revoked. Note that these
measurements were taken around the time
useful lifetime of the Heartbleed incident
[HEARTBLEED], most algorithms and the revocation activity may have been unusually
high due to this incident. In addition, this incident exacerbates
the problem of incomplete Web PKI revocation checking. These
measurements show that browsers are not obtaining current certificate
revocation information because it key sizes is too expensive known many
years in terms of
latency and bandwidth. Finally, only advance.

2. Planning for a small number of CRL smooth and OCSP
servers orderly transition from a weak
algorithm or key size. Experience has shown that many years are available over IPv6,
needed produce to specifications, develop implementations, and as more of
then deploy replacements.

3. Reducing the Web moves lifetime of certificates, especially intermediate CA
certificates, to IPv6
[ABLOG] this is expected create frequent opportunities to become an increasingly significant issue.

The following subsections identify some approaches for reducing the
perceived and actual cost of revocation status checks.

3.2.1. Short-lived Certificates

Short-lived certificates are change an excellent way to reduce the need for
certificate status checking. The shorter the life of the
certificate, the less time there is
algorithm or key size.

3.2. Support for anything Enterprise PKIs

Many enterprises operate their own PKI. These enterprises do not
want to go wrong. If the
lifetime is short enough, policy might allow certificate status
checking can be skipped altogether. In practice, implementation of
short-lived certificates requires automation to assist web server
administrators, which is a topic that is discussed elsewhere in this
document.

3.2.2. CRL Distribution Points

The certificate revocation list distribution point (CRLDP)
certificate extension RFC 5280 [RFC5280] allows a CA to control the
maximum size part of the CRLs that traditional Web PKI, but they issue. This helps face many
challenges in two ways.
First, the amount of storage needed by the browser order to cache CRLs is
reduced. Second, achieve a similar user experience and more importantly, the amount level of time it takes
to download a CRL can be scoped, so that
security.

Users must install the amount of time needed to
fetch any single CRL is reasonable.

Few CAs take advantage of trust anchor or trust anchors for the CRLDP certificate extension
enterprise PKI in their browser. There is not a standard way to limit
the size of CRLs. In fact, there
accomplish trust anchor installation, and users are several CAs that publish
extremely large CRLs. Browsers never want to suffer the latency
associated often faced with large CRLs, and some ignore the CRLDP extension when
it is present. Browsers tend to avoid
scary warnings in the use process of CRLs altogether.

3.2.3. Proprietary Revocation Checks the installation.

Enterprise PKI users often experience greater latency than tradition
Web PKI users. Some browser vendors provide a proprietary mechanism for revocation
checking. These mechanisms obtain
checking mechanism that obtains revocation status information once
per day for the entire Web
PKI in a very compact form. No This mechanism eliminates latency since
no network traffic is generated at the time that a certificate is
being
validated, so there is no latency associated with revocation status
checking. The browser vendor infrastructure performs daily checks of
the Web PKI, and then the results are assembled in a proprietary
format and made available to the browser. These checks only validated. However, these mechanisms cover only the trust
anchor store for that browser vendor, so any trust anchors
added by the user cannot be checked in this manner.

Measurements excluding all enterprise PKIs.
In addition, measurements in 2015 [IMC2015] show that proprietary status checking
is these
mechanisms do not currently providing provide adequate coverage of the Web PKI.

3.2.4. OCSP Stapling

Browsers can avoid transmission of CRLs altogether by using the
Online Certificate Status Protocol (OCSP) RFC 6960 [RFC6960] to check
the validity of web server certificates. The TLS Certificate Status
Request extension is defined in Section 8 of RFC 6066 [RFC6066]. In
addition,

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 an OCSP response responses in addition to its the server certificate.
This approach greatly reduces the number of round trips by latency since the browser does not
need to
check the status of each certificate in the path. In addition, the
web server can cache the generate any OCSP response requests or wait for a period of time, avoiding
additional latency. Even in the cases where the web server needs to
contact the any OCSP responder, the web server usually has a higher
bandwidth connection than the browser to do so. 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.

When every browser that connects to a high volume website performs
its own OCSP lookup, the OCSP responder must handle a real-time
response to every browser. 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.

Many web site are taking advantage of OCSP stapling. At the time of
this writing, browser venders report that about 12% the the
transactions use OCSP stapling, and the number is on the rise.

3.3. Surprising Certificates

All of the CAs in the trust store are equally trusted for the entire
domain name space, so any CA can

Several enterprises issue for any domain name. In fact,
there have been certificates issued by CAs that are surprising to the
legitimate owner all of a domain. The domain name owner their employees, and
among other uses, these certificates are used in TLS client
authentication. There is surprised
because they did not request the certificates. They are initially
unaware that a CA has issued a certificate that contains their domain
name, common way to import the private key
and once the surprising client certificate is discovered, it into browsers. In fact, the private key
can be
very difficult for the legitimate domain name owner to get it
revoked. Further, browsers and other relying parties cannot
distinguish a certificate that the legitimate domain name owner
requested from a surprising one.

Since all of the CAs stored in many different formats depending on the trust store are equally trusted, any CA
can issue a certificate for any domain name. There are known cases
where attackers have thwarted the CA protections and issued
certificates that were then software
used to mount attacks against generate the users
of that web site [FOXIT]. For this reason, all of the CAs listed in
the trust store must public/private key pair. PKCS#12 [RFC7292]
seems to be very well protected.

The Baseline Requirements produced by the CA/Browser Forum [CAB2014]
tell CAs most popular format at the checks that need moment. A standard way to be performed before a certificate is
issued. In addition, WebTrust [WEBTRUST] provides
import the audit
requirements for CAs, needed keying material and browser vendors will remove a CA from the
trust anchor store if successful audit reports are not made
available.

When a CA issues a certificate to a subordinate CA, standard format will make
this task much easier, and the inclusion of
widely supported certificate extensions World Wide Web might enjoy an increase
in mutual authentication.

Enterprise PKIs can reduce the set of
privileges given to the sub-CA. This aligns be better supported if:

1. Each enterprise PKI offers an OCSP Responder, and web sites with the traditional
security practice of least privilege, where only the privileges
needed to perform the envisioned tasks are provided. However, many
sub-CAs have
certificates that pass along from the full powers enterprise PKI make use of OCSP Stapling.

2. Browser vendors support a standard way for the CA,
creating additional high-pay-off targets trust anchors for attackers, and these
sub-CAs may not
the enterprise PKI to be held installed.

3. Browser vendors support a standard way to the same certificate issuance requirements install private keys
and audit requirement as the parent CA.

Some major implementations have not fully implemented certificates for use in client authentication.

4. In the event that browser vendors continue to offer latency-free
proprietary revocation status checking mechanisms, then these
mechanisms
necessary need to reduce sub-CA privileges. For example, RFC 5280
[RFC5280] includes expand the specification coverage to all of name constraints, and the CA/
Browser Forum guidelines [CAB2014] encourage Web PKI and
offer a means to include enterprise PKIs in the use of dNSNames coverage.

3.3. Web PKI in
permittedSubtrees within the name constraints extension. Despite
this situation, one major browser does not support name constraints, Home

More and as a result, CAs more, web protocols are reluctant being used to use them. When they are used,
the name constraints extension manage devices in not marked critical so that the
home. For example, homeowners can use a web browser that does not support this extension is free to ignore the
extension. This situation leads to enforcement of the name
constraint by some browsers and not others. Further, global CAs are
prepared connect to issue certificates within every top-level domain,
including ones a
web site that are newly-approved. It is not practical for
these global CAs to use name constraints embedded in their sub-CA
certificates.

As a result of procedural failures or attacks, surprising
certificates are being issued. Several mechanisms have been defined home router to avoid the issuance of surprising certificates or prevent browsers
from accepting them.

3.3.1. Certificate Authority Authorization (CAA) adjust various
settings. The Certificate Authority Authorization (CAA) [RFC6844] DNS resource
record router allows a domain administrator to specify one or more CAs
authorized the browser to issue certificates that include that domain name.
Then, a trustworthy CA will refuse access web pages to issue a certificate for a
domain name that has a CAA resource record that does not explicitly
name
adjust these setting as long as the CA.

To date, only one major CA performs this check, connection originates from the
home network and the proper password is provided. However, there is
no
indication that other CAs are planning to add this check in way for the near
future.

3.3.2. HTTP Public Key Pinning (HPKP)

HTTP Public Key Pinning (HPKP) [RFC7469] allows a web server browser to
instruct browsers authenticate to remember the server's public key fingerprints
for a period of time. The fingerprint is a one-way hash of the
subject public key information in the certificate. The Public-Key-
Pins header provides a maximum retention period, fingerprints embedded web site.
Authentication of the web server certificate, and optionally fingerprints for backup
certificates. The act of saving site is normally performed during the fingerprints TLS
handshake, but the Web PKI is referred not equipped to as
"pinning". During issue certificates to
home routers or the pin lifetime, browsers require many other home devices that the same employ embedded web server present a certificate chain
sites for homeowner management.

A solution in this environment must not depend on the homeowner to
perform duties that includes are normally associated with a public key
that matches one of web site
administrator. However, some straightforward tasks could be done at
the retained fingerprints. This prevents
impersonation of time the website with a surprising certificate.

A website can choose to pin device is installed in the CA certificate so home. These task cannot be
more complex that the browser initial setup of a new printer in the home,
otherwise they will accept only valid be skipped or done incorrectly.

There are two very different approaches to certificates for the website domain that are
issued by home
devices that CA. Alternatively, have been discussed over the website can choose to pin
their own certificate years. In the first
approach, a private key and at least one backup certificate are installed in case the
current device
at the factory. The certificate needs to be replaced due to a compromised server.

Some browser vendors also pin certificates by hardcoding fingerprints
of very well known websites.

When HPKP has an unlimited lifetime. Since it
never expires, no homeowner action is used, browsers may be able needed to detect a man-in-the-
middle. Sometimes renew it. Also,
since the man-in-the-middle is an attacker, and other
times a service provider purposefully terminates certificate never changes, the TLS at a
location other than algorithms are selected by
the web server. One example became very public
in February 2012 when Trustwave admitted that it had issued a
subordinate CA certificate factory for use by a company to inspect corporate
network traffic [LC2012]. When HPKP is used, the browser user will
be notified if lifetime of the key-pining is violated, unless device. The subject name in the violating
certificate can be validated to a locally installed trust anchor. In
this situation, the browser is assuming quite generic, as it must be comprised of information
that the user intended to
explicitly trust the certificate.

3.3.3. HTTP Strict Transport Security (HSTS)

HTTP Strict Transport Security (HSTS) [RFC6797] is a security policy
mechanism that protects secure websites against downgrade attacks,
and it greatly simplifies protection against cookie hijacking. known in the factory. The
presence subject name is often based on
some combination of the Strict-Transport-Security header tells browsers that
all interactions with this web server should never use HTTP without
TLS, providing protection against both eavesdropping manufacturer, model, serial number, and active
network attacks. The protections can be tied 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 domain or a domain private key and all of its sub-domains.

When a web server includes
certificate that are installed in the Strict-Transport-Security header, device at the
browser factory, but the
homeowner is unaware of them. This factory-installed certificate is expected
used only to do two things. First, the browser
automatically turns any insecure links into secure ones. For
instance, "http://mysite.example.com/mypage/" will be changed authenticate to
"https://mysite.example.com/mypage/". Second, if a CA operated by the TLS Handshake
results in some failure, such as manufacturer. At
the certificate cannot be validated,
then an error message is displayed and time the user device is denied access to installed, the web application. Any web server misconfiguration, such as homeowner can provide a
certificate expiration, will result no one being able to access the
web site until the configuration is corrected.

To date, HSTS ha seen very little deployment, and there is no
indication that portion
of the browser vendors intend to add support subject name for it.

3.3.4. DNS-Based Authentication of Named Entities (DANE)

The DNS-Based Authentication of Named Entities (DANE) [RFC6698]
allows domain administrators to specify the raw public keys or
certificates that are used by web servers in their domain. DANE
leverages device, and the DNS Security Extensions (DNSSEC) [RFC4034][RFC4035],
which provides digital signatures over DNS zones that are validated
with keys manufacturer CA can issue
a certificate that are bound to the domain includes a subject name of that the signed zone. homeowner will
recognize. The
keys associated with a domain name certificate can only be signed renewed without any action by the
homeowner at appropriate intervals. Also, following a key
associated with software
update, the parent of that domain name. For example, algorithms used in the
DNSSEC keys for "www.example.com" can only be signed by TLS handshake and the DNSSEC
keys for "example.com". Therefore, a malicious actor certificate
can only
compromise the keys be updated.

Section 3.1 of their own subdomains. Like this document calls for the Web PKI,
DNSSEC relies on public keys used ability to validate chains of signatures,
but DNSSEC has a single root domain as opposed transition from
weak cryptographic algorithms over time. For this reason, and the
ability to use a multiplicity of
trusted CAs.

DANE binds raw public keys or certificates to DNS names. The domain
administrator is the one subject name that vouches for the binding of homeowner will recognize, the public
key or
second approach is preferred.

One potential problem with the certificate to second approach is continuity of
operations of the domain name by adding manufacturer CA. After the TSLA records
to device is deployed, the zone
manufacturer might go out of business, and then signing the zone. In this way, the same
administrator is responsible come time for managing the DNS names themselves
and associated public keys or certificates with those names. DANE
restricts the scope renewal
of assertions that can the certificate, there will not be made, forcing them a CA to
be consistent with issue the DNS naming hierarchy.

In addition, DNSSEC reduces opportunities for redirection attacks by
binding new
certificate. One possible solution might be modeled on the domain
name business, where other parties will continue to provide needed
services if the public key or certificate.

Some original provider goes out of business.

The Web PKI can prepare for the vast number of home devices that need
certificates are being posted in TLSA records, but
browsers expect to receive by:

1. Building upon the server certificate work being done in the TLS
handshake, and there is little incentive for browsers IETF ACME Working Group
[ACMEWG] to confirm that facilitate the received certificate matches automatic renewal of certificates for
home devices without any actions by the one posted in homeowner beyond the DNS. For this
reason, work has begun on a TLS extension
initial device setup.

2. Working with device manufacturers to establish scalable CAs that
will allow the DNSSEC-
protected information continue to be provided in the handshake, which will
eliminate issue certificates for the added latency [TLSCHAIN].

3.3.5. Certificate Transparency

Certificate Transparency (CT) [RFC6962] offers a mechanism to detect
surprising certificates, and once detected, administrators and CAs
can take deployed devices even
if the necessary actions manufacture goes out of business.

3. Working with device manufacturers to revoke the surprising certificates.

When requesting a certificate, the administrator can request establish OCSP Responders so
that the CA
to include an web sites that are embedded Signed Certificate Timestamp (SCT) in the
certificate to ensure that their legitimate certificate is logged
with one or more CT logs.

An administrator, or another party acting on behalf of the
administrator, is able to monitor one or more CT logs to which a pre-
certificate or certificate is submitted, devices can provide
robust authentication and detect the logging of OCSP stapling in a
pre-certificate or certificate manner that contains their domain name. When
such a pre-certificate or certificate is detected, the CA can be
contacted to to get the surprising certificate revoked.

In the future, a
compatible with traditional web sites.

3.4. Browser Error Messages

Many users find browser may choose error messages related to reject certificates that do
not contain an SCT, and potentially notify the website administrator
or CA when they encounter such a certificate. Such reporting will
help detect mis-issuance of certificates and lead to their
revocation.

The IETF Certificate Transparency Working Group is
confusing. Good man-machine interfaces are always difficult, but in the process of
updating RFC 6962. Many data structures
this situation users are changing, and CT logs
will have to pick a format, choosing version 1 (v1) that conforms to
RFC 6962 or version 2 (v2) that conforms unable to fully understand the new specification.
Since the data structures risks that
they are incompatible, accepting, and as a v2 log will result they do not be able make informed
decisions about when to issue a valid v1 SCT. A CT client can support both v1 proceed and v2 SCTs
for the same certificate, simultaneously, since a v1 SCT will when to stop. This aspect of
browser usability needs to be
carried in different extension than a v2 SCT.

3.4. Automation for Server Administrators

The IETF has developed several protocols improved for certificate management,
including the Certificate Management Protocol (CMP) [RFC4210],
Certificate Management over CMS (CMC) [RFC5272], and Enrollment over
Secure Transport (EST) [RFC7030]. There are also some proprietary
certificate management protocols. None of these protocols enjoys a
dominate position in the market.

There users to make better
security choices.

Browser users have been several attempts to provide automation for routine
tasks that are performed by web server administrators, such as
certificate renewal. For example, some commercial tools offer
automated certificate renewal and installation [DCEI][SSLM]. Also,
at least one proposal was brought trained to ignore warnings, making them
ineffective. Further, solving the IETF that allows a web
server to automate obtaining and renewing certificates [PHBOB].
Without automation, there are many manual steps involved error message situation in getting a
certificate from a CA, and
isolation is probably not possible; instead, it needs to date none of these attempts at
automation have enjoyed widespread interoperability and adoption.
There are at least two ways that be
considered along side the other issues raised in this impacts web security. First,
many web sites do not document.
Browser users have been trained to find a certificate at all. The cost, time, way around any error, and
effort are too great for
very often, the system administrator. This error is
especially true if the result of web site is server misconfiguration,
and it does not involved in financial
transactions or some other critical activity. Second, once a
certificate is obtained, actually present a replacement is not obtained until risk to the
current one expires. Automation can reduce browser user.

If the amount of time that
an administrator needs to dedicate to certificate management, and it
can make certificate renewal timely and automatic. Both of these
should lead risk to more widespread deployment and improved web security.

The IETF ACME working group [ACMEWG] the user is working on protocols that
will provide system administrators high, then the session should be closed
with an automated way to enroll
and renew their certificates. The expectation is a clear description of the problem that these
specifications was encountered. Doing
so will lead to widely available and interoperable improved management of the overall Web infrastructure
over time, especially as the tools
for system administrators. The expectation is that these protocols
and tools will be supported by all are being developed for web
server environments and CAs,
which will greatly reduce complexity and cost. administrators are rolled out.

In addition, some enterprises, avoiding these errors requires the
easier renewal process provided by automation can be used addition of
enterprise-specific trust anchors to reduce
certificate lifetimes, which in turn will reduce the time required browser. Additional tools
are needed to
flush old algorithms out 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.

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 system user
when it there is decided likely to
transition be a risk.

2. Browser vendors improving error messages to newer more secure algorithms.

4. Policy and Process clearly indicate the
risk that the user is accepting if they proceed.

3.5. Governance Improvements to the Web PKI

As with many other technologies, the issues and complexities associated
with Web PKI use and deployment technical issues are just as much tangled
up with policy and process
as technical. These issues. Policy and process issues have
evolved over time as well. This section
discusses the ways that business models and operational policies time, sometimes eroding confidence and
processes impact trust in the Web
PKI.

4.1. Determination of the Trusted Certificate Authorities

A very basic question for users of the Governance structures are needed that increase transparency and
trust.

Web PKI is "Who users are by definition asked to trust CAs. This includes
what CAs are trusted to do you trust?" 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 has been perceived by some as is opaque and
confusing. As mentioned earlier, the confusing to
most Web PKI users. The CA/Browser Forum 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 the trust anchor store for by each of the major
browsers vendors is not straightforward. The individual browser
vendors determine what should and should not be trusted by including those
trusted CAs
the CA certificate in their trust anchor store. They do this by
leveraging the AICPA/CICA WebTrust Program for Certification
Authorities [WEBTRUST]. This program provides auditing requirements
and a trust mark for CAs. 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 which would 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.

One form of bad behavior by CAs is the mis-issuance of certificates.
This mis-issuance can be either an honest mistake by the CA,
malicious behavior by the CA, or a case where an external party has
duped the CA into the mis-issuance. When a CA has delegated
authority to a sub-CA, and then the sub-CA issued bad certificates
either unintentionally or maliciously, the CA is able to deny
responsibility for the actions of the sub-CA. However, the CA may be
the only party that can revoke the sub-CA certificate to protect the
overall Web PKI.

Another complication with CAs and the trust store maintained by the
browser vendor is an enterprise managed PKI. For example, the US
Department of Defense operates its own PKI. In this case, the
enterprise maintains its own PKI for the exclusive use of the
enterprise itself. A bridge CA may be used to connect related
enterprises. The complication in this approach is that the
revocation mechanisms don't work with any additions that have been
made by the enterprise. See Section 3.2.3 on proprietary revocation
checks.

The guidelines provided by the WebTrust program [WEBTRUST] provide a
framework for removing a CA from the trust anchor store. However, the
implications of removing a CA can be significant. There may
be a few very large CAs that are critical to significant portions of Internet
World Wide Web infrastructure. Removing one of these trusted CAs can have a
significant impact on a large cross section huge number of Internet users
resulting websites. As discussed in potentially large numbers of websites no longer being
trusted. Users
Section 3.4, users are already struggling to understand the
implications of untrusted websites and certificates, so they often ignore the current warnings as
discussed below.

4.2. Price for Certificates

Many CAs charge for each of the certificates that they issue. This
business model creates a hurdle for proper deployment. In some
cases, the cost causes people to deploy self-signed certificates that
cannot be validated against the browser trust store. In other cases,
the cost is an incentive to use the same certificate and the
associate private key on many different servers within a domain.
This leads to greater exposure of the private key, and coordination
is needed among the server administrators when it is time to renew
the certificate.

At least one CA is moving away from the charging-per-certificate
business model. The Let's Encrypt CA [LE] is offering free web
server certificates. This zero-cost business model will
significantly change the Web PKI, removing the cost concerns that
leaded to insecure deployment.

4.3. Governance Structures for
presented by the Web PKI browser.

There are a number of organizations that play significant roles in
the operation of the Web PKI, including the CAB CA/Browser Forum, the
WebTrust Program, and the browser vendors. These organizations act
on behalf of the entire Internet community. Transparency community; therefore, transparency
in these operations is vital fundamental to basic confidence and trust in the Web
PKI. As one example, in the past Recently the CAB CA/Browser Forum was perceived as being a closed forum; however, made some changes were made to the their
operational procedures to allow more make it easier for people to participate
and to improve visibility if not actual participation in the into their process [CAB1.2]. How
do we ensure that This is a
significant improvement, but these processes need to continue to
evolve in an open, inclusive, and transparent manner? manner. Currently, as
the name implies, the CAB CA/Browser Forum members primarily represent
CAs and browser vendors. How do we
ensure that It would be better if relying parties also
have a voice in this forum? 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 the connections between SMTP servers. In these environments,
the browser-centric capabilities are unavailable. For
example, see Section 3.2.3 on proprietary revocation checks. The current
governance structure does not provide a way for the relying parties
in these other applications to participate. How do we ensure that these other
applications get a voice in this forum?

5. Additional Technical Considerations

Beyond the technical mechanisms that constitute the

The Web PKI itself,
there are additional technical considerations that impact the success
of the Web PKI.

5.1. Browser Error Messages

Many people find browser error messages related to certificates
confusing. Good man-machine interfaces are always difficult, but in
this situation users are unable to understand the risks that they
being asked to accept. Even experts do not have the time or
inclination to make an assessment of the situation that caused the
error message. As a result, browser users have learned to largely
ignore the warning messages.

Many different situations governance structures can cause an error message, where blocking
the communication would not be in the interest of the browser user.
There are many examples, including web sites that use self-signed
certificates, captive portals that redirect intercepted HTTPS
connections, and certificates that appear expired because the local
computer clock is wrong.

Too often the warnings are due to web server misconfiguration.
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.

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 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-grade devices as more and made more enterprises are embracing bring-your-own-device policies.

5.2. Time Synchronization

Time synchronization is another factor that impacts the security open and
reliability of the Web PKI. Reasonably accurate time is needed to
check certificate expiration
transparent by:

1. Browser vendors providing additional visibility and tools to determine whether cached
revocation status information is fresh. There is ongoing work to
improve
support the security management of the time synchronization infrastructure, and
it will use certificates to authenticate time servers. Since the
certificate infrastructure relies on quality time synchronization,
this dependency creates a boot strapping issue.

6. Recommendations for Improving the Web PKI

To make the Web PKI more secure and more robust, the following
priorities have been identified and are recommended for further
development and deployment:

Improve certificate status checking.
Develop and deploy a standard solution for all relying parties
is needed. OCSP stapling seems to be trust anchor store.

2. Governance organizations providing a significant part of
this solution.

Automation for certificate enrollment and renewal.
Develop and deploy standard protocols that provide system
administrators with an automated way to enroll and renew their
certificates. This work is currently underway in the IETF.

In addition, solutions to these procedural and policy challenges are
needed:

Smooth transition between cryptographic algorithms.
Develop best practices for smooth and timely transition between
cryptographic algorithms.

Eliminate surprising certificates.
Develop best practices that use one or more of the several
mechanisms that have been defined throughout the Web PKI to
eliminate surprising certificates.

Confidence in CA actions.
Develop best practices for identifying and dealing with bad
behavior by a CA that can be followed by all browser vendors.

Open and transparent Web PKI governance.
Develop a governance structure that allows relying parties parties,
including ones associated with non-browser applications, to
have a voice resulting in open and transparent governance.

7.
participate.

4. Security Considerations

Not just the Web depends on the Web PKI. For example, mail servers
often use certificates that are validated using the trust store from
a browser. In addition, applications written in scripting languages
that run in the browser environment do not have access to any
alternative infrastructures. The Web PKI is being leveraged to avoid
the time and expense to establish an independent PKI.

More and more Internet applications depend on the Web PKI. For the
most part, leveraging the Web PKI is improving the security of the
Internet. However, the Web PKI is being used in ways that were not
envisaged in its design. Care is needed to ensure that applications
are not expecting security properties that cannot be delivered by the
Web PKI.

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 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. }}}

6. References

9.1.

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>.

9.2.

6.2. Informative References

[ABLOG] Nygren, E., "Three years since World IPv6 Launch: strong
IPv6 growth continues", June 2015,
<https://blogs.akamai.com/2015/06/three-years-since-world-
ipv6-launch-strong-ipv6-growth-continues.html>.

[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>.

[DCEI] DigiCert Inc, "Express Install(TM): Automate SSL
Certificate Installation and HTTPS Configuration", August
2015, <https://www.digicert.com/express-install/>.

[FOXIT] Prins, J., "DigiNotar Certificate Authority breach:
"Operation Black Tulip"", September 2011,
<http://www.rijksoverheid.nl/bestanden/documenten-en-
publicaties/rapporten/2011/09/05/
diginotar-public-report-version-1/
rapport-fox-it-operation-black-tulip-v1-0.pdf>.

[HEARTBLEED]
Wikipedia, "Heartbleed", 2016,
<https://en.wikipedia.org/wiki/Heartbleed>.

[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>.

[LC2012] Constantin, L., "Trustwave admits issuing man-in-the-
middle digital certificate; Mozilla debates punishment",
February 2012,
<http://www.computerworld.com/article/2501291/internet/
trustwave-admits-issuing-man-in-the-middle-digital-
certificate--mozilla-debates-punishment.html>.

[LE] Internet Security Research Group, "Let's Encrypt", July
2015, <https://letsencrypt.org/>.

[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/>.

[PHBOB] Hallam-Baker, P., "OmniBroker Publication Protocol",
draft-hallambaker-omnipublish-00 (work in progress), May
2014.

[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>.

[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>.

[RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen,
"Internet X.509 Public Key Infrastructure Certificate
Management Protocol (CMP)", RFC 4210,
DOI 10.17487/RFC4210, September 2005,
<http://www.rfc-editor.org/info/rfc4210>.

[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>.

[RFC5272] Schaad, J. and M. Myers, "Certificate Management over CMS
(CMC)", RFC 5272, DOI 10.17487/RFC5272, June 2008,
<http://www.rfc-editor.org/info/rfc5272>.

[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.

[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>.

[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797,
DOI 10.17487/RFC6797, November 2012,
<http://www.rfc-editor.org/info/rfc6797>.

[RFC6844] Hallam-Baker, P. and R. Stradling, "DNS Certification
Authority Authorization (CAA) Resource Record", RFC 6844,
DOI 10.17487/RFC6844, January 2013,
<http://www.rfc-editor.org/info/rfc6844>.

[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>.

[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>.

[RFC7030] Pritikin, M., Ed., Yee, P.,

[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
and D. Harkins, Ed.,
"Enrollment over Secure Transport", RFC 7030,
DOI 10.17487/RFC7030, October 2013,
<http://www.rfc-editor.org/info/rfc7030>.

[RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", M. Scott, "PKCS #12: Personal Information Exchange
Syntax v1.1", RFC 7469, 7292, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>. 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>.

[SSLM] Opsmate, Inc., "SSLMate: Secure your website the easy
way", August 2015, <https://sslmate.com/>.

[TLSCHAIN]
Shore, M., Barnes, R., Huque, S., and W. Toorop, "X.509v3
TLS Feature Extension", draft-shore-tls-dnssec-chain-
extension-01 (work in progress), July 2015.

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

[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>.

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, Martin
Thomson, 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: housley@vigilsec.com

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

Email: odonoghue@isoc.org