< draft-iab-web-pki-problems-01.txt   draft-iab-web-pki-problems-02.txt >
Internet Architecture Board R. Housley Internet Architecture Board R. Housley
Internet-Draft Vigil Security Internet-Draft Vigil Security
Intended status: Informational K. O'Donoghue Intended status: Informational K. O'Donoghue
Expires: August 24, 2016 Internet Society Expires: November 13, 2016 Internet Society
February 21, 2016 May 12, 2016
Problems with the Public Key Infrastructure (PKI) for the World Wide Web Problems with the Public Key Infrastructure (PKI) for the World Wide Web
draft-iab-web-pki-problems-01.txt draft-iab-web-pki-problems-02.txt
Abstract Abstract
This document describes some of the challenges facing the current This document describes some of the challenges facing the current
Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI) Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI)
and considers promising improvements to address these challenges. and considers promising improvements to address these challenges.
Technical, process, and policy improvements to the WebPKI are Technical, process, and policy improvements to the WebPKI are
considered. In addition, some technical considerations beyond WebPKI considered. In addition, some technical considerations beyond WebPKI
itself are considered. Hopefully the content of this document will itself are considered. Hopefully the content of this document will
help drive the Internet community toward wide spread adoption of some help drive the Internet community toward wide spread adoption of some
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 24, 2016. This Internet-Draft will expire on November 13, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Very Brief Description of the Web PKI . . . . . . . . . . . . 3 2. Very Brief Description of the Web PKI . . . . . . . . . . . . 3
3. Technical Improvements to the Web PKI . . . . . . . . . . . . 3 3. Technical Improvements to the Web PKI . . . . . . . . . . . . 4
3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 4 3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 4
3.2. Certificate Status Checking . . . . . . . . . . . . . . . 5 3.2. Certificate Status Checking . . . . . . . . . . . . . . . 5
3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 5 3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 6
3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 6 3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 6
3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 6 3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 6
3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 6 3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 7
3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 7 3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 8
3.3.1. Certificate Authority Authorization (CAA) . . . . . . 8 3.3.1. Certificate Authority Authorization (CAA) . . . . . . 9
3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 9 3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 9
3.3.3. HTTP Strict Transport Security (HSTS) . . . . . . . . 9 3.3.3. HTTP Strict Transport Security (HSTS) . . . . . . . . 10
3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 10 3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 10
3.3.5. Certificate Transparency . . . . . . . . . . . . . . 10 3.3.5. Certificate Transparency . . . . . . . . . . . . . . 11
3.4. Automation for Server Administrators . . . . . . . . . . 11 3.4. Automation for Server Administrators . . . . . . . . . . 12
4. Policy and Process Improvements to the Web PKI . . . . . . . 12 4. Policy and Process Improvements to the Web PKI . . . . . . . 13
4.1. Determination of the Trusted Certificate Authorities . . 12 4.1. Determination of the Trusted Certificate Authorities . . 13
4.2. Governance Structures for the Web PKI . . . . . . . . . . 13 4.2. Price for Certificates . . . . . . . . . . . . . . . . . 14
5. Additional Technical Considerations . . . . . . . . . . . . . 14 4.3. Governance Structures for the Web PKI . . . . . . . . . . 15
5.1. Browser Error Messages . . . . . . . . . . . . . . . . . 14 5. Additional Technical Considerations . . . . . . . . . . . . . 15
5.2. Time Synchronization . . . . . . . . . . . . . . . . . . 14 5.1. Browser Error Messages . . . . . . . . . . . . . . . . . 15
6. Recommendations for Improving the Web PKI . . . . . . . . . . 14 5.2. Time Synchronization . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. Recommendations for Improving the Web PKI . . . . . . . . . . 16
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2. Informative References . . . . . . . . . . . . . . . . . 16 9.1. Normative References . . . . . . . . . . . . . . . . . . 18
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix B. IAB Members at the Time of Approval . . . . . . . . 19 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 Appendix B. IAB Members at the Time of Approval . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
There are many technical, process, and policy problems with the There are many interrelated problems with the current Public Key
current Public Key Infrastructure (PKI) used for the World Wide Web Infrastructure (PKI) used for the World Wide Web (Web PKI). The Web
(Web PKI). This document describes these problems, considers some PKI makes use of certificates as described in RFC 5280 [RFC5280].
emerging technical improvements, discusses some evoling process and These certificates are primarily used with Transport Layer Security
policy improvements, and provides some basic recommendations for the (TLS) RFC 5246 [RFC5246].
Internet community.
The Web PKI makes use of certificates as described in RFC 5280 The economics of the Web PKI value chain are discussed in [VFBH],
[RFC5280]. These certificates are primarily used with Transport [AV], and [AVAV]. This document does not discuss the economic issues
Layer Security (TLS) RFC 5246 [RFC5246]. further, but these economic issues provide motivation for correcting
the other problems that are discussed in this document.
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
recommendations for the Internet community.
2. Very Brief Description of the Web PKI 2. Very Brief Description of the Web PKI
Certificates are specified in RFC 5280 [RFC5280]. Certificates Certificates are specified in RFC 5280 [RFC5280]. Certificates
contain, among other things, a subject name, a public key, a limited contain, among other things, a subject name, a public key, a limited
valid lifetime, and the digital signature of the Certification valid lifetime, and the digital signature of the Certification
Authority (CA). Certificate users require confidence that the Authority (CA). Certificate users require confidence that the
private key associated with the certified public key is owned by the private key associated with the certified public key is owned by the
named subject. named subject.
skipping to change at page 4, line 22 skipping to change at page 4, line 28
become weaker with time. As new cryptanalysis techniques are become weaker with time. As new cryptanalysis techniques are
developed and computing capabilities improve, the work factor to developed and computing capabilities improve, the work factor to
break a particular cryptographic algorithm will reduce. For this break a particular cryptographic algorithm will reduce. For this
reason, the algorithms and key sizes used in the Web PKI need to reason, the algorithms and key sizes used in the Web PKI need to
migrate over time. A reasonable choice of algorithm or key size migrate over time. A reasonable choice of algorithm or key size
needs to be reevaluated periodically, and a transition may be needed needs to be reevaluated periodically, and a transition may be needed
before the expected lifetime expires. before the expected lifetime expires.
The browser vendors have been trying to manage algorithm and key size The browser vendors have been trying to manage algorithm and key size
transitions, but a long-lived trust anchor or intermediate CA transitions, but a long-lived trust anchor or intermediate CA
certificate can have a huge number of subordinate certificates. So, certificate can have a huge number of certificates under it. So,
removing one because it uses a weak cryptographic algorithm or a removing one certificate because it uses a weak cryptographic
short public key can have a significant impact. algorithm or a short public key can have a significant impact on a
large 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 certificate with a weak cryptographic
algorithm or a short public key.
As a result, some valid trust anchors and certificates contain As a result, some valid trust anchors and certificates contain
cryptographic algorithms long after weaknesses have been discovered cryptographic algorithms long after weaknesses have been discovered
and widely known. Similarly, valid trust anchors and certificates and widely known. Similarly, valid trust anchors and certificates
contain public keys after computational resources available to contain public keys after computational resources available to
attackers have rendered them too weak. We have seen a very attackers have rendered them too weak. We have seen a very
successful migration away from certificates that use the MD2 or MD5 successful migration away from certificates that use the MD2 or MD5
one-way hash functions. However, there are still a great number of one-way hash functions. However, there are still a number of
certificates that use SHA-1 and 1024-bit RSA public keys, and these certificates that use SHA-1 and 1024-bit RSA public keys [MB2015]
should be replaced. [MB2016], and these certificates should be replaced.
Today, the algorithms and key sizes used by a CA to sign certificates Today, the algorithms and key sizes used by a CA to sign end-entity
with a traditional lifespan should offer 112 to 128 bits of security. certificates with a traditional lifespan of a year should offer 112
SHA-256 is a widely studied one-way hash function that meets this to 128 bits of security. SHA-256 is a widely studied one-way hash
requirement. RSA with a public key of at least 2048 bits or ECDSA function that meets this requirement. RSA with a public key of at
with a public key of at least 256 bits are widely studied digital least 2048 bits or ECDSA with a public key of at least 256 bits are
signature algorithms that meet this requirement. widely studied digital signature algorithms that meet this
requirement.
The algorithms 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 algorithms that
meet this requirement.
Obviously, additional algorithm transitions will be needed in the Obviously, additional algorithm transitions will be needed in the
future as these algorithms age. These algorithms, like the ones that future as these algorithms age. These algorithms, like the ones that
were used earlier, will become weaker with time. RFC 7696 [RFC7696] were used earlier, will become weaker with time. RFC 7696 [RFC7696]
offers some guidelines regarding cryptographic algorithm agility. offers some guidelines regarding cryptographic algorithm agility.
3.2. Certificate Status Checking 3.2. Certificate Status Checking
Several years ago, many browsers did not perform certificate status Several years ago, many browsers did not perform certificate status
checks by default. That is, browsers did not check whether the checks by default. That is, browsers did not check whether the
skipping to change at page 5, line 28 skipping to change at page 5, line 41
bother to check revocation status [IMC2015]. bother to check revocation status [IMC2015].
Certificate status checking needs to be used at all times. Several Certificate status checking needs to be used at all times. Several
techniques have been tried by CAs and browsers to make certificate techniques have been tried by CAs and browsers to make certificate
status checking more efficient. Many CAs are using Content Delivery status checking more efficient. Many CAs are using Content Delivery
Networks (CDNs) to deliver CRLs and OCSP responses, resulting in very Networks (CDNs) to deliver CRLs and OCSP responses, resulting in very
high availability and low latency. Yet, browser vendors are still high availability and low latency. Yet, browser vendors are still
reluctant to perform standard-based status checking by default for reluctant to perform standard-based status checking by default for
every session. every session.
Certificate status checking by the browser can reveal the web sites
that the browser user is visiting to the OCSP Responder or the server
providing the CRL. This privacy concern can be eliminated by having
the Web Server include the OCSP Response in 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 Measurements in 2015 [IMC2015] show that a surprisingly large
fraction of Web PKI certicates have been revoked. These same fraction of Web PKI certicates have been revoked. Note that these
measurements were taken around the time of the Heartbleed incident
[HEARTBLEED], 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 measurements show that browsers are not obtaining current certificate
revocation information because it is too expensive in terms of revocation information because it is too expensive in terms of
latency and bandwidth. Finally, only a small number of CRL and OCSP latency and bandwidth. Finally, only a small number of CRL and OCSP
servers are available over IPv6, and as more of the Web moves to IPv6 servers are available over IPv6, and as more of the Web moves to IPv6
[ABLOG] this is expected to become an increasingly significant issue. [ABLOG] this is expected to become an increasingly significant issue.
The following subsections identify some approaches for reducing the The following subsections identify some approaches for reducing the
perceived and actual cost of revocation status checks. perceived and actual cost of revocation status checks.
3.2.1. Short-lived Certificates 3.2.1. Short-lived Certificates
skipping to change at page 7, line 25 skipping to change at page 7, line 47
its own OCSP lookup, the OCSP responder must handle a real-time its own OCSP lookup, the OCSP responder must handle a real-time
response to every browser. OCSP stapling can avoid enormous volumes response to every browser. OCSP stapling can avoid enormous volumes
of OCSP requests for certificates of popular websites, so stapling of OCSP requests for certificates of popular websites, so stapling
can significantly reduce the cost of providing an OCSP service. can significantly reduce the cost of providing an OCSP service.
OCSP stapling can also improve user privacy, since the web server, OCSP stapling can also improve user privacy, since the web server,
not the browser, contacts the OCSP responder. In this way, the OCSP not the browser, contacts the OCSP responder. In this way, the OCSP
responder is not able to determine which browsers are checking the responder is not able to determine which browsers are checking the
validity of certificate for websites. validity of certificate for websites.
Many web site are taking advantage of OCSP sampling. At the time of Many web site are taking advantage of OCSP stapling. At the time of
this writing, browser venders report that about 12% the the this writing, browser venders report that about 12% the the
transactions use OCSP stapling, and the number is on the rise. transactions use OCSP stapling, and the number is on the rise.
3.3. Surprising Certificates 3.3. Surprising Certificates
All of the CAs in the trust store are equally trusted for the entire All of the CAs in the trust store are equally trusted for the entire
domain name space, so any CA can issue for any domain name. In fact, domain name space, so any CA can issue for any domain name. In fact,
there have been certificates issued by CAs that are surprising to the there have been certificates issued by CAs that are surprising to the
legitimate owner of a domain. The domain name owner is surprised legitimate owner of a domain. The domain name owner is surprised
because they did not request the certificates. They are initially because they did not request the certificates. They are initially
skipping to change at page 8, line 23 skipping to change at page 8, line 47
needed to perform the envisioned tasks are provided. However, many needed to perform the envisioned tasks are provided. However, many
sub-CAs have certificates that pass along the full powers of the CA, sub-CAs have certificates that pass along the full powers of the CA,
creating additional high-pay-off targets for attackers, and these creating additional high-pay-off targets for attackers, and these
sub-CAs may not be held to the same certificate issuance requirements sub-CAs may not be held to the same certificate issuance requirements
and audit requirement as the parent CA. and audit requirement as the parent CA.
Some major implementations have not fully implemented the mechanisms Some major implementations have not fully implemented the mechanisms
necessary to reduce sub-CA privileges. For example, RFC 5280 necessary to reduce sub-CA privileges. For example, RFC 5280
[RFC5280] includes the specification of name constraints, and the CA/ [RFC5280] includes the specification of name constraints, and the CA/
Browser Forum guidelines [CAB2014] encourage the use of dNSNames in Browser Forum guidelines [CAB2014] encourage the use of dNSNames in
permittedSubtrees within the name Constraints extension. Despite permittedSubtrees within the name constraints extension. Despite
this situation, one major browser does not support name constraints, this situation, one major browser does not support name constraints,
and as a result, CAs are reluctant to use them. Further, global CAs and as a result, CAs are reluctant to use them. When they are used,
are prepared to issue certificates within every top-level domain, the name constraints extension in not marked critical so that the
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 to issue certificates within every top-level domain,
including ones that are newly-approved. It is not practical for including ones that are newly-approved. It is not practical for
these global CAs to use name constraints in their sub-CA these global CAs to use name constraints in their sub-CA
certificates. certificates.
As a result of procedural failures or attacks, surprising As a result of procedural failures or attacks, surprising
certificates are being issued. Several mechanisms have been defined certificates are being issued. Several mechanisms have been defined
to avoid the issuance of surprising certificates or prevent browsers to avoid the issuance of surprising certificates or prevent browsers
from accepting them. from accepting them.
3.3.1. Certificate Authority Authorization (CAA) 3.3.1. Certificate Authority Authorization (CAA)
skipping to change at page 9, line 47 skipping to change at page 10, line 24
this situation, the browser is assuming that the user intended to this situation, the browser is assuming that the user intended to
explicitly trust the certificate. explicitly trust the certificate.
3.3.3. HTTP Strict Transport Security (HSTS) 3.3.3. HTTP Strict Transport Security (HSTS)
HTTP Strict Transport Security (HSTS) [RFC6797] is a security policy HTTP Strict Transport Security (HSTS) [RFC6797] is a security policy
mechanism that protects secure websites against downgrade attacks, mechanism that protects secure websites against downgrade attacks,
and it greatly simplifies protection against cookie hijacking. The and it greatly simplifies protection against cookie hijacking. The
presence of the Strict-Transport-Security header tells browsers that presence of the Strict-Transport-Security header tells browsers that
all interactions with this web server should never use HTTP without all interactions with this web server should never use HTTP without
TLS, providing protection against eavesdropping and active network TLS, providing protection against both eavesdropping and active
attacks. network attacks. The protections can be tied to a domain or a domain
and all of its sub-domains.
When a web server includes the Strict-Transport-Security header, the When a web server includes the Strict-Transport-Security header, the
browser is expected to do two things. First, the browser browser is expected to do two things. First, the browser
automatically turns any insecure links into secure ones. For automatically turns any insecure links into secure ones. For
instance, "http://mysite.example.com/mypage/" will be changed to instance, "http://mysite.example.com/mypage/" will be changed to
"https://mysite.example.com/mypage/". Second, if the TLS Handshake "https://mysite.example.com/mypage/". Second, if the TLS Handshake
results in some failure, such as the certificate cannot be validated, results in some failure, such as the certificate cannot be validated,
then an error message is displayed and the user is denied access to then an error message is displayed and the user is denied access to
the web application. the web application. Any web server misconfiguration, such as 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 the browser vendors intend to add support for it.
3.3.4. DNS-Based Authentication of Named Entities (DANE) 3.3.4. DNS-Based Authentication of Named Entities (DANE)
The DNS-Based Authentication of Named Entities (DANE) [RFC6698] The DNS-Based Authentication of Named Entities (DANE) [RFC6698]
allows domain administrators to specify the raw public keys or allows domain administrators to specify the raw public keys or
certificates that are used by web servers in their domain. DANE certificates that are used by web servers in their domain. DANE
leverages the DNS Security Extensions (DNSSEC) [RFC4034][RFC4035], leverages the DNS Security Extensions (DNSSEC) [RFC4034][RFC4035],
which provides digital signatures over DNS zones that are validated which provides digital signatures over DNS zones that are validated
with keys that are bound to the domain name of the signed zone. The with keys that are bound to the domain name of the signed zone. The
keys associated with a domain name can only be signed by a key keys associated with a domain name can only be signed by a key
skipping to change at page 10, line 41 skipping to change at page 11, line 24
administrator is responsible for managing the DNS names themselves administrator is responsible for managing the DNS names themselves
and associated public keys or certificates with those names. DANE and associated public keys or certificates with those names. DANE
restricts the scope of assertions that can be made, forcing them to restricts the scope of assertions that can be made, forcing them to
be consistent with the DNS naming hierarchy. be consistent with the DNS naming hierarchy.
In addition, DNSSEC reduces opportunities for redirection attacks by In addition, DNSSEC reduces opportunities for redirection attacks by
binding the domain name to the public key or certificate. binding the domain name to the public key or certificate.
Some Web PKI certificates are being posted in TLSA records, but Some Web PKI certificates are being posted in TLSA records, but
browsers expect to receive the server certificate in the TLS browsers expect to receive the server certificate in the TLS
handshake, and there is little incentive to confirm that the received handshake, and there is little incentive for browsers to confirm that
certificate matches the one posted in the DNS. For this reason, work the received certificate matches the one posted in the DNS. For this
has begun on a TLS extension that will allow the DNSSEC-protected reason, work has begun on a TLS extension that will allow the DNSSEC-
information to be provided in the handshake, which will eliminate the protected information to be provided in the handshake, which will
added latency [TLSCHAIN]. eliminate the added latency [TLSCHAIN].
3.3.5. Certificate Transparency 3.3.5. Certificate Transparency
Certificate Transparency (CT) [RFC6962] offers a mechanism to detect Certificate Transparency (CT) [RFC6962] offers a mechanism to detect
surprising certificates, and once detected, administrators and CAs surprising certificates, and once detected, administrators and CAs
can take the necessary actions to revoke the surprising certificates. can take the necessary actions to revoke the surprising certificates.
When requesting a certificate, the administrator can request the CA When requesting a certificate, the administrator can request the CA
to include an embedded Signed Certificate Timestamp (SCT) in the to include an embedded Signed Certificate Timestamp (SCT) in the
certificate to ensure that their legitimate certificate is logged certificate to ensure that their legitimate certificate is logged
skipping to change at page 11, line 23 skipping to change at page 12, line 7
pre-certificate or certificate that contains their domain name. When pre-certificate or certificate that contains their domain name. When
such a pre-certificate or certificate is detected, the CA can be such a pre-certificate or certificate is detected, the CA can be
contacted to to get the surprising certificate revoked. contacted to to get the surprising certificate revoked.
In the future, a browser may choose to reject certificates that do In the future, a browser may choose to reject certificates that do
not contain an SCT, and potentially notify the website administrator not contain an SCT, and potentially notify the website administrator
or CA when they encounter such a certificate. Such reporting will or CA when they encounter such a certificate. Such reporting will
help detect mis-issuance of certificates and lead to their help detect mis-issuance of certificates and lead to their
revocation. revocation.
The IETF Certificate Transparency Working Group is in the process of
updating RFC 6962. Many data structures 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 to the new specification.
Since the data structures are incompatible, a v2 log will not be able
to issue a valid v1 SCT. A CT client can support both v1 and v2 SCTs
for the same certificate, simultaneously, since a v1 SCT will be
carried in different extension than a v2 SCT.
3.4. Automation for Server Administrators 3.4. Automation for Server Administrators
The IETF has developed several protocols 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 have been several attempts to provide automation for routine There have been several attempts to provide automation for routine
tasks that are performed by web server administrators, such as tasks that are performed by web server administrators, such as
certificate renewal. For example, some commercial tools offer certificate renewal. For example, some commercial tools offer
automated certificate renewal and installation [DCEI][SSLM]. Also, automated certificate renewal and installation [DCEI][SSLM]. Also,
at least one proposal was brought to the IETF that allows a web at least one proposal was brought to the IETF that allows a web
server to automate obtaining and renewing certificates [PHBOB]. server to automate obtaining and renewing certificates [PHBOB].
Without automation, there are many manual steps involved in getting a Without automation, there are many manual steps involved in getting a
certificate from a CA, and to date none of these attempts at certificate from a CA, and to date none of these attempts at
automation have enjoyed widespread interoperability and adoption. automation have enjoyed widespread interoperability and adoption.
There are at least two ways that this impacts web security. First, There are at least two ways that this impacts web security. First,
skipping to change at page 12, line 38 skipping to change at page 13, line 39
AICPA/CICA WebTrust Program for Certification Authorities [WEBTRUST]. AICPA/CICA WebTrust Program for Certification Authorities [WEBTRUST].
This program provides auditing requirements and a trust mark for CAs. This program provides auditing requirements and a trust mark for CAs.
Failure to pass an audit can result in the CA being removed from the Failure to pass an audit can result in the CA being removed from the
trust store. trust store.
Once the browser has shipped, how does a user know which CAs are Once the browser has shipped, how does a user know which CAs are
trusted or what has changed recently? For an informed user, trusted or what has changed recently? For an informed user,
information about which CAs have been added to or deleted from the information about which CAs have been added to or deleted from the
browser trust store can be found in the release notes. Users can browser trust store can be found in the release notes. Users can
also examine the policies of the various CAs which would have been also examine the policies of the various CAs which would have been
developed and posted for the WebTrust Program. However, this may be developed and posted for the WebTrust Program. However, this is a
considered a fairly high barrier for the average user. There are very high barrier for the average user. There are options to make
also options to make local modifications by educated users, but there local modifications by educated users, but there is little
is little understanding about the implications of these choices. How understanding about the implications of these choices. How does an
does an individual, organization, or enterprise really determine if a individual, organization, or enterprise really determine if a
particular CA is trustworthy? Do the default choices inherited from particular CA is trustworthy? Do the default choices inherited from
the browser vendors truly represent the organization's trust model? the browser vendors truly represent the organization's trust model?
What constitutes sufficiently bad behavior by a CA to cause removal What constitutes sufficiently bad behavior by a CA to cause removal
from the trust store? from the trust store?
In addition, it can be hazardous for users to remove CAs from the
browser trust store. If a user removes a CA from the browser trust
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. 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, 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 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 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 authority to a sub-CA, and then the sub-CA issued bad certificates
either unintentionally or maliciously, the CA is able to deny either unintentionally or maliciously, the CA is able to deny
responsibility for the actions of the sub-CA. However, the CA may be 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 the only party that can revoke the sub-CA certificate to protect the
overall Web PKI. overall Web PKI.
skipping to change at page 13, line 31 skipping to change at page 14, line 38
framework for removing a CA from the trust store. However, the framework for removing a CA from the trust store. However, the
implications of removing a CA can be significant. There may be a few implications of removing a CA can be significant. There may be a few
very large CAs that are critical to significant portions of Internet very large CAs that are critical to significant portions of Internet
infrastructure. Removing one of these trusted CAs can have a infrastructure. Removing one of these trusted CAs can have a
significant impact on a large cross section of Internet users significant impact on a large cross section of Internet users
resulting in potentially large numbers of websites no longer being resulting in potentially large numbers of websites no longer being
trusted. Users are already struggling to understand the implications trusted. Users are already struggling to understand the implications
of untrusted websites and often ignore the current warnings as of untrusted websites and often ignore the current warnings as
discussed below. discussed below.
4.2. Governance Structures for the Web PKI 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 the Web PKI
There are a number of organizations that play significant roles in There are a number of organizations that play significant roles in
the operation of the Web PKI, including the CAB Forum, the WebTrust the operation of the Web PKI, including the CAB Forum, the WebTrust
Program, and the browser vendors. These organizations act on behalf Program, and the browser vendors. These organizations act on behalf
of the entire Internet community. Transparency in these operations of the entire Internet community. Transparency in these operations
is vital to basic trust in the Web PKI. As one example, in the past is vital to basic trust in the Web PKI. As one example, in the past
the CAB Forum was perceived as being a closed forum; however, some the CAB Forum was perceived as being a closed forum; however, some
changes were made to the operational procedures to allow more changes were made to the operational procedures to allow more
visibility if not actual participation in the process [CAB1.2]. How visibility if not actual participation in the process [CAB1.2]. How
do we ensure that these processes continue to evolve in an open, do we ensure that these processes continue to evolve in an open,
skipping to change at page 14, line 10 skipping to change at page 15, line 35
to secure the connections between SMTP servers. In these to secure the connections between SMTP servers. In these
environments, the browser-centric capabilities are unavailable. For environments, the browser-centric capabilities are unavailable. For
example, see Section 3.2.3 on proprietary revocation checks. The example, see Section 3.2.3 on proprietary revocation checks. The
current governance structure does not provide a way for these other current governance structure does not provide a way for these other
applications to participate. How do we ensure that these other applications to participate. How do we ensure that these other
applications get a voice in this forum? applications get a voice in this forum?
5. Additional Technical Considerations 5. Additional Technical Considerations
Beyond the technical mechanisms that constitute the Web PKI itself, Beyond the technical mechanisms that constitute the Web PKI itself,
there are additional technologies that impact the success of the Web there are additional technical considerations that impact the success
PKI infrastructure. Examples of these are discussed in this section. of the Web PKI.
5.1. Browser Error Messages 5.1. Browser Error Messages
Many people find browser error messages related to certificates Many people find browser error messages related to certificates
confusing. Good man-machine interfaces are always difficult, but in confusing. Good man-machine interfaces are always difficult, but in
this situation users are unable to understand the risks that they are this situation users are unable to understand the risks that they
accepting by clicking "okay". Users have been basically trained to being asked to accept. Even experts do not have the time or
ignore the warnings provided by the infrastructure rendering this inclination to make an assessment of the situation that caused the
warning ineffective. This aspect of browser usability needs to be error message. As a result, browser users have learned to largely
improved for users to make better security choices. (Editor note: ignore the warning messages.
Additional detail with references is needed for this section.)
Many different situations 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
more enterprises are embracing bring-your-own-device policies.
5.2. Time Synchronization 5.2. Time Synchronization
Time synchronization is another factor that impacts the security and Time synchronization is another factor that impacts the security and
reliability of the Web PKI. Reasonably accurate time is needed to reliability of the Web PKI. Reasonably accurate time is needed to
check certificate expiration and to determine whether cached check certificate expiration and to determine whether cached
revocation status information is fresh. There is ongoing work to revocation status information is fresh. There is ongoing work to
improve the security of the time synchronization infrastructure, and improve the security of the time synchronization infrastructure, and
it will use certificates to authenticate time servers. Since the it will use certificates to authenticate time servers. Since the
certificate infrastructure relies on quality time synchronization, certificate infrastructure relies on quality time synchronization,
skipping to change at page 15, line 27 skipping to change at page 17, line 27
Confidence in CA actions. Confidence in CA actions.
Develop best practices for identifying and dealing with bad Develop best practices for identifying and dealing with bad
behavior by a CA that can be followed by all browser vendors. behavior by a CA that can be followed by all browser vendors.
Open and transparent Web PKI governance. Open and transparent Web PKI governance.
Develop a governance structure that allows relying parties to Develop a governance structure that allows relying parties to
have a voice resulting in open and transparent governance. have a voice resulting in open and transparent governance.
7. Security Considerations 7. 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 This document considers the weaknesses of the current Web PKI system
and provides recommendations for improvements. Some of the risks and provides recommendations for improvements. Some of the risks
associated with doing nothing or continuing down the current path are associated with doing nothing or continuing down the current path are
articulated. The Web PKI is a vital component of a trusted Internet 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 and as such needs to be improved to sustain continued growth of the
Internet. Internet.
8. IANA Considerations 8. IANA Considerations
None. None.
skipping to change at page 16, line 22 skipping to change at page 18, line 32
[ABLOG] Nygren, E., "Three years since World IPv6 Launch: strong [ABLOG] Nygren, E., "Three years since World IPv6 Launch: strong
IPv6 growth continues", June 2015, IPv6 growth continues", June 2015,
<https://blogs.akamai.com/2015/06/three-years-since-world- <https://blogs.akamai.com/2015/06/three-years-since-world-
ipv6-launch-strong-ipv6-growth-continues.html>. ipv6-launch-strong-ipv6-growth-continues.html>.
[ACMEWG] IETF, "Charter for Automated Certificate Management [ACMEWG] IETF, "Charter for Automated Certificate Management
Environment (acme) Working Group", June 2015, Environment (acme) Working Group", June 2015,
<https://datatracker.ietf.org/doc/charter-ietf-acme/>. <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", [CAB1.2] CA/Browser Forum, "Bylaws of the CA/Browser Forum",
October 2014, <https://cabforum.org/wp-content/uploads/CA- October 2014, <https://cabforum.org/wp-content/uploads/CA-
Browser-Forum-Bylaws-v.1.2.pdf>. Browser-Forum-Bylaws-v.1.2.pdf>.
[CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements [CAB2014] CA/Browser Forum, "CA/Browser Forum Baseline Requirements
for the Issuance and Management of Publicly-Trusted for the Issuance and Management of Publicly-Trusted
Certificates, v.1.2.2", October 2014, Certificates, v.1.2.2", October 2014,
<https://cabforum.org/wp-content/uploads/BRv1.2.2.pdf>. <https://cabforum.org/wp-content/uploads/BRv1.2.2.pdf>.
[DCEI] DigiCert Inc, "Express Install(TM): Automate SSL [DCEI] DigiCert Inc, "Express Install(TM): Automate SSL
Certificate Installation and HTTPS Configuration", August Certificate Installation and HTTPS Configuration", August
2015, <https://www.digicert.com/express-install/>. 2015, <https://www.digicert.com/express-install/>.
[FOXIT] Prins, J., "DigiNotar Certificate Authority breach: [FOXIT] Prins, J., "DigiNotar Certificate Authority breach:
"Operation Black Tulip"", September 2011, "Operation Black Tulip"", September 2011,
<http://www.rijksoverheid.nl/bestanden/documenten-en- <http://www.rijksoverheid.nl/bestanden/documenten-en-
publicaties/rapporten/2011/09/05/ publicaties/rapporten/2011/09/05/
diginotar-public-report-version-1/ diginotar-public-report-version-1/
rapport-fox-it-operation-black-tulip-v1-0.pdf>. 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., [IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D.,
Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An Maggs, B., Mislove, A., Schulman, A., and C. Wilson, "An
End-to-End Measurement of Certificate Revocation in the End-to-End Measurement of Certificate Revocation in the
Web's PKI", October 2015, Web's PKI", October 2015,
<http://conferences2.sigcomm.org/imc/2015/papers/ <http://conferences2.sigcomm.org/imc/2015/papers/
p183.pdf>. p183.pdf>.
[LC2012] Constantin, L., "Trustwave admits issuing man-in-the- [LC2012] Constantin, L., "Trustwave admits issuing man-in-the-
middle digital certificate; Mozilla debates punishment", middle digital certificate; Mozilla debates punishment",
February 2012, February 2012,
<http://www.computerworld.com/article/2501291/internet/ <http://www.computerworld.com/article/2501291/internet/
trustwave-admits-issuing-man-in-the-middle-digital- trustwave-admits-issuing-man-in-the-middle-digital-
certificate--mozilla-debates-punishment.html>. 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", [PHBOB] Hallam-Baker, P., "OmniBroker Publication Protocol",
draft-hallambaker-omnipublish-00 (work in progress), May draft-hallambaker-omnipublish-00 (work in progress), May
2014. 2014.
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Resource Records for the DNS Security Extensions", Rose, "Resource Records for the DNS Security Extensions",
RFC 4034, DOI 10.17487/RFC4034, March 2005, RFC 4034, DOI 10.17487/RFC4034, March 2005,
<http://www.rfc-editor.org/info/rfc4034>. <http://www.rfc-editor.org/info/rfc4034>.
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "Protocol Modifications for the DNS Security Rose, "Protocol Modifications for the DNS Security
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
<http://www.rfc-editor.org/info/rfc4035>. <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 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, August 2008,
<http://www.rfc-editor.org/info/rfc5246>. <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) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>. <http://www.rfc-editor.org/info/rfc6066>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
of Named Entities (DANE) Transport Layer Security (TLS) of Named Entities (DANE) Transport Layer Security (TLS)
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
2012, <http://www.rfc-editor.org/info/rfc6698>. 2012, <http://www.rfc-editor.org/info/rfc6698>.
skipping to change at page 18, line 14 skipping to change at page 21, line 14
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>. <http://www.rfc-editor.org/info/rfc6961>.
[RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate
Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013,
<http://www.rfc-editor.org/info/rfc6962>. <http://www.rfc-editor.org/info/rfc6962>.
[RFC7030] Pritikin, M., Ed., Yee, P., Ed., 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 [RFC7469] Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April Extension for HTTP", RFC 7469, DOI 10.17487/RFC7469, April
2015, <http://www.rfc-editor.org/info/rfc7469>. 2015, <http://www.rfc-editor.org/info/rfc7469>.
[RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm [RFC7696] Housley, R., "Guidelines for Cryptographic Algorithm
Agility and Selecting Mandatory-to-Implement Algorithms", Agility and Selecting Mandatory-to-Implement Algorithms",
BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015, BCP 201, RFC 7696, DOI 10.17487/RFC7696, November 2015,
<http://www.rfc-editor.org/info/rfc7696>. <http://www.rfc-editor.org/info/rfc7696>.
[SSLM] Opsmate, Inc., "SSLMate: Secure your website the easy [SSLM] Opsmate, Inc., "SSLMate: Secure your website the easy
skipping to change at page 18, line 35 skipping to change at page 21, line 40
[TLSCHAIN] [TLSCHAIN]
Shore, M., Barnes, R., Huque, S., and W. Toorop, "X.509v3 Shore, M., Barnes, R., Huque, S., and W. Toorop, "X.509v3
TLS Feature Extension", draft-shore-tls-dnssec-chain- TLS Feature Extension", draft-shore-tls-dnssec-chain-
extension-01 (work in progress), July 2015. extension-01 (work in progress), July 2015.
[TLSFEATURE] [TLSFEATURE]
Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft- Hallam-Baker, P., "X.509v3 TLS Feature Extension", draft-
hallambaker-tlsfeature-10 (work in progress), July 2015. 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] [WEBTRUST]
CPA Canada, "WebTrust Program for Certification CPA Canada, "WebTrust Program for Certification
Authorities", August 2015, <http://www.webtrust.org/ Authorities", August 2015, <http://www.webtrust.org/
homepage-documents/item27839.aspx>. homepage-documents/item27839.aspx>.
Appendix A. Acknowledgements Appendix A. Acknowledgements
This document has been developed within the IAB Privacy and Security This document has been developed within the IAB Privacy and Security
Program. The authors greatly appreciate the review and suggestions Program. The authors greatly appreciate the review and suggestions
provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet, provided by Rick Andrews, Mary Barnes, Richard Barnes, Marc Blanchet,
Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie, Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted Hardie,
Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy
Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy
Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Martin
Trammell, and Juan Carlos Zuniga. Thomson, Brian Trammell, and Juan Carlos Zuniga.
Appendix B. IAB Members at the Time of Approval Appendix B. IAB Members at the Time of Approval
{{{ RFC Editor: Please add the names to the IAB members at the time {{{ RFC Editor: Please add the names to the IAB members at the time
that this document is put into the RFC Editor queue. }}} that this document is put into the RFC Editor queue. }}}
Authors' Addresses Authors' Addresses
Russ Housley Russ Housley
Vigil Security Vigil Security
 End of changes. 37 change blocks. 
77 lines changed or deleted 244 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/