< draft-iab-web-pki-problems-00.txt   draft-iab-web-pki-problems-01.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: June 11, 2016 Internet Society Expires: August 24, 2016 Internet Society
December 9, 2015 February 21, 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-00.txt draft-iab-web-pki-problems-01.txt
Abstract Abstract
This document describes the technical and non-technical problems with This document describes some of the challenges facing the current
the current Public Key Infrastructure (PKI) used for the World Wide Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI)
Web. Some potential technical improvements are considered, and some and considers promising improvements to address these challenges.
non-technical approaches to improvements are discussed. Technical, process, and policy improvements to the WebPKI are
considered. In addition, some technical considerations beyond WebPKI
itself are considered. Hopefully the content of this document will
help drive the Internet community toward wide spread adoption of some
of the highlighted recommendations.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 June 11, 2016. This Internet-Draft will expire on August 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . 4 3.2. Certificate Status Checking . . . . . . . . . . . . . . . 5
3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 5 3.2.1. Short-lived Certificates . . . . . . . . . . . . . . 5
3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 5 3.2.2. CRL Distribution Points . . . . . . . . . . . . . . . 6
3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 5 3.2.3. Proprietary Revocation Checks . . . . . . . . . . . . 6
3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 6 3.2.4. OCSP Stapling . . . . . . . . . . . . . . . . . . . . 6
3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 7 3.3. Surprising Certificates . . . . . . . . . . . . . . . . . 7
3.3.1. Certificate Authority Authorization (CAA) . . . . . . 8 3.3.1. Certificate Authority Authorization (CAA) . . . . . . 8
3.3.2. HTTP Public Key Pinning (HPKP) . . . . . . . . . . . 8 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) . . . . . . . . 9
3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 9 3.3.4. DNS-Based Authentication of Named Entities (DANE) . . 10
3.3.5. Certificate Transparency . . . . . . . . . . . . . . 10 3.3.5. Certificate Transparency . . . . . . . . . . . . . . 10
3.4. Automation for Server Administrators . . . . . . . . . . 11 3.4. Automation for Server Administrators . . . . . . . . . . 11
4. Policy and Process Improvements to the Web PKI . . . . . . . 11 4. Policy and Process Improvements to the Web PKI . . . . . . . 12
4.1. Determination of the Trusted Certificate Authorities . . 11 4.1. Determination of the Trusted Certificate Authorities . . 12
4.2. Governance Structures for the Web PKI . . . . . . . . . . 13 4.2. Governance Structures for the Web PKI . . . . . . . . . . 13
5. Challenges for Improving the Web PKI . . . . . . . . . . . . 13 5. Additional Technical Considerations . . . . . . . . . . . . . 14
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5.1. Browser Error Messages . . . . . . . . . . . . . . . . . 14
6.1. Browser Error Messages . . . . . . . . . . . . . . . . . 14 5.2. Time Synchronization . . . . . . . . . . . . . . . . . . 14
6.2. Time Synchronization . . . . . . . . . . . . . . . . . . 14 6. Recommendations for Improving the Web PKI . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 15 9.1. Normative References . . . . . . . . . . . . . . . . . . 15
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 17 9.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix B. IAB Members at the Time of Approval . . . . . . . . 18 Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 Appendix B. IAB Members at the Time of Approval . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
There are many technical and non-technical problems with the current There are many technical, process, and policy problems with the
Public Key Infrastructure (PKI) used for the World Wide Web. This current Public Key Infrastructure (PKI) used for the World Wide Web
document describes these problems, considers some potential technical (Web PKI). This document describes these problems, considers some
improvements, and discusses some non-technical approaches to emerging technical improvements, discusses some evoling process and
improvements. policy improvements, and provides some basic recommendations for the
Internet community.
The Web PKI makes use of certificates as described in RFC 5280 The Web PKI makes use of certificates as described in RFC 5280
[RFC5280]. These certificates are primarily used with Transport [RFC5280]. These certificates are primarily used with Transport
Layer Security (TLS) RFC 5246 [RFC5246]. Layer Security (TLS) RFC 5246 [RFC5246].
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 and a public key, and contain, among other things, a subject name, a public key, a limited
they are digitally signed by the Certification Authority (CA). valid lifetime, and the digital signature of the Certification
Certificate users require confidence that the private key associated Authority (CA). Certificate users require confidence that the
with the certified public key is owned by the named subject. A private key associated with the certified public key is owned by the
certificate has a limited valid lifetime. named subject.
The architectural model used in the Web PKI includes: The architectural model used in the Web PKI includes:
EE: End Entity -- the subject of a certificate -- certificates are EE: End Entity -- the subject of a certificate -- certificates are
issued to Web Servers, and certificates are also issued to issued to end entities including Web servers and clients that
clients that need mutual authentication. need mutual authentication.
CA: Certification Authority -- the issuer of a certificate -- CA: Certification Authority -- the issuer of a certificate --
issues certificates for Web Servers and clients. issues certificates for end entities including Web servers and
clients.
RA: Registration Authority -- an optional system to which a CA RA: Registration Authority -- an optional system to which a CA
delegates some management functions such as identity validation delegates some management functions such as identity validation
or physical credential distribution. or physical credential distribution.
CAs are responsible for indicating the revocation status of the 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 certificates that they issue throughout the lifetime of the
certificate. Revocation status information may be provided using the certificate. Revocation status information may be provided using the
Online Certificate Status Protocol (OCSP) [RFC2560], certificate Online Certificate Status Protocol (OCSP) RFC 6960 [RFC6960],
revocation lists (CRLs) [RFC5280], or some other mechanism. In certificate revocation lists (CRLs) RFC 5280 [RFC5280], or some other
general, when revocation status information is provided using CRLs, mechanism. In general, when revocation status information is
the CA is also the CRL issuer. However, a CA may delegate the provided using CRLs, the CA is also the CRL issuer. However, a CA
responsibility for issuing CRLs to a different entity. may delegate the responsibility for issuing CRLs to a different
entity.
The enrollment process used by a CA makes sure that the subject name The enrollment process used by a CA makes sure that the subject name
in the certificate is appropriate and that the subject actually holds in the certificate is appropriate and that the subject actually holds
the private key. Proof of possession of the private key is often the private key. Proof of possession of the private key is often
accomplished through a challenge-response protocol. accomplished through a challenge-response protocol.
3. Technical Improvements to the Web PKI 3. Technical Improvements to the Web PKI
Over the years, many technical improvements have been made to the Web Over the years, many technical improvements have been made to the Web
PKI. This section discusses several problems and the technical PKI. This section discusses several problems and the technical
problems that have been made to address them. This history sets the improvements that have been made to address them. This history sets
stage for suggestions for additional improvements in other sections the stage for suggestions for additional improvements in other
of this document. sections of this document.
3.1. Weak Cryptographic Algorithms or Short Public Keys 3.1. Weak Cryptographic Algorithms or Short Public Keys
Over the years, the digital signature algorithms, one-way hash Over the years, the digital signature algorithms, one-way hash
functions, and public key sizes that are considered strong have functions, and public key sizes that are considered strong have
changed. This is not a surprise. Cryptographic algorithms age; they changed. This is not a surprise. Cryptographic algorithms age; they
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 evaluated 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 subordinate certificates. So,
removing a one because it uses a weak cryptographic algorithm or a removing one because it uses a weak cryptographic algorithm or a
short public key can have a significant impact. short public key can have a significant impact.
As a result, some valid trust anchors and certificates contain As a result, some valid trust anchors and certificates contain
cryptographic algorithms after weakness has been discovered and cryptographic algorithms long after weaknesses have been discovered
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 great 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, and these
should be replaced. 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 certificates
with a traditional lifespan should offer 112 to 128 bits of security. with a traditional lifespan should offer 112 to 128 bits of security.
SHA-256 is a widely studied one-way hash function that meets this 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 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 with a public key of at least 256 bits are widely studied digital
signature algorithms that meet this requirement. signature algorithms that meet this requirement.
Obviously, additional algorithm transitions will be needed in the
future as these algorithms age. These algorithms, like the ones that
were used earlier, will become weaker with time. RFC 7696 [RFC7696]
offers some guidelines regarding cryptographic algorithm agility.
3.2. Certificate Status Checking 3.2. Certificate Status Checking
Several years ago, many browsers do 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
issuing CA has revoked the certificate unless the user explicitly issuing CA had revoked the certificate unless the user explicitly
adjusted a setting to enable this feature. This check can be made by adjusted a setting to enable this feature. This check can be made by
fetching the most recent certificate revocation list (CRL) RFC 5280 fetching the most recent certificate revocation list (CRL) RFC 5280
[RFC5280], or this check can use the Online Certificate Status [RFC5280], or this check can use the Online Certificate Status
Protocol (OCSP) RFC 6960 [RFC6960]. The location of the CRL or the Protocol (OCSP) RFC 6960 [RFC6960]. The location of the CRL or the
OCSP responder is usually found in the certificate itself. Either OCSP responder is usually found in the certificate itself. However,
one of these approaches add latency. The desire to provide a snappy both of these approaches add latency. The desire to provide a
user experience is a significant reason that this feature has not responsive user experience is a significant reason that this feature
turned on by default. Mobile browsers simply do not bother to check has not been turned on by default. Mobile browsers simply do not
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 of Content status checking more efficient. Many CAs are using Content Delivery
Delivery Networks (CDNs) to deliver CRLs and OCSP responses, Networks (CDNs) to deliver CRLs and OCSP responses, resulting in very
resulting in very high availability and low latency. Yet, browser high availability and low latency. Yet, browser vendors are still
vendors are still reluctant to perform standard-based status checking reluctant to perform standard-based status checking by default for
by default for every session. every session.
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, and browsers are fraction of Web PKI certicates have been revoked. These same
not obtaining current certificate revocation information because it measurements show that browsers are not obtaining current certificate
is too expensive in terms of latency and bandwidth. revocation information because it is too expensive in terms of
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
[ABLOG] this is expected 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 3.2.1. Short-lived Certificates
Short-lived certificates are an excellent way to reduce the need for Short-lived certificates are an excellent way to reduce the need for
certificate status checking. The shorter the life of the certificate status checking. The shorter the life of the
certificate, the less time there is for anything to go wrong. If the certificate, the less time there is for anything to go wrong. If the
lifetime is short enough, policy might allow certificate status lifetime is short enough, policy might allow certificate status
checking can be skipped altogether. In practice, implementation of checking can be skipped altogether. In practice, implementation of
short-lived certificates requires automation to assist web server short-lived certificates requires automation to assist web server
administrators, which is a topic that is discussed elsewhere in this administrators, which is a topic that is discussed elsewhere in this
skipping to change at page 7, line 21 skipping to change at page 7, line 41
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
unaware that a CA has issued a certificate that contains their domain unaware that a CA has issued a certificate that contains their domain
name, and once the surprising certificate is discovered, it can be name, and once the surprising certificate is discovered, it can be
very difficult for the legitimate domain name owner to get it very difficult for the legitimate domain name owner to get it
revoked. Further, browsers and other relying parties cannot revoked. Further, browsers and other relying parties cannot
distinguish a certificate that the legitimate domain name owner distinguish a certificate that the legitimate domain name owner
requested from an surprising one. requested from a surprising one.
Since all of the CAs in the trust store are equally trusted, any CA Since all of the CAs in the trust store are equally trusted, any CA
can issue a certificate for any domain name. There are known cases can issue a certificate for any domain name. There are known cases
where attackers have thwarted the CA protections and issued where attackers have thwarted the CA protections and issued
certificates that were then used to mount attacks against the users certificates that were then used to mount attacks against the users
of that web site [FOXIT]. For this reason, all of the CAs listed in of that web site [FOXIT]. For this reason, all of the CAs listed in
the trust store must be very well protected. the trust store must be very well protected.
The Baseline Requirements produced by the CA/Browser Forum [CAB2014] The Baseline Requirements produced by the CA/Browser Forum [CAB2014]
tell CAs the checks that need to be performed before a certificate is tell CAs the checks that need to be performed before a certificate is
issued. In addition, WebTrust [WEBTRUST] provides the audit issued. In addition, WebTrust [WEBTRUST] provides the audit
requirements for CAs, and browser vendors will remove a CA from the requirements for CAs, and browser vendors will remove a CA from the
trust anchor store if successful audit reports are not made trust anchor store if successful audit reports are not made
available. available.
When a CA issues a certificate to a subordinate CA, the inclusion of When a CA issues a certificate to a subordinate CA, the inclusion of
widely supported certificate extensions can reduce set of privileges widely supported certificate extensions can reduce the set of
given to the sub-CA. This aligns with the traditional security privileges given to the sub-CA. This aligns with the traditional
practice of least privilege, where only the privileges needed to security practice of least privilege, where only the privileges
perform the envisioned tasks are provided. However, many sub-CAs needed to perform the envisioned tasks are provided. However, many
have certificates that pass along the full powers of the CA, creating sub-CAs have certificates that pass along the full powers of the CA,
additional high-pay-off targets for attackers, and these sub-CAs may creating additional high-pay-off targets for attackers, and these
not be held to the same certificate issuance requirements and audit sub-CAs may not be held to the same certificate issuance requirements
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 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. Further, global CAs
are prepared to issue certificates within every top-level domain, 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)
The Certificate Authority Authorization (CAA) [RFC6844] DNS resource The Certificate Authority Authorization (CAA) [RFC6844] DNS resource
record allows a domain administrator to specify one or more CA that record allows a domain administrator to specify one or more CAs
is authorized to issue certificates that include the domain name. authorized to issue certificates that include that domain name.
Then, a trustworthy CA will refuse to issue a certificate for a Then, a trustworthy CA will refuse to issue a certificate for a
domain name that has a CAA resource record that does not explicitly domain name that has a CAA resource record that does not explicitly
name the CA. name the CA.
To date, only one major CA performs this check, and there is no To date, only one major CA performs this check, and there is no
indication that other CAs are planning to add this check in the near indication that other CAs are planning to add this check in the near
future. future.
3.3.2. HTTP Public Key Pinning (HPKP) 3.3.2. HTTP Public Key Pinning (HPKP)
HTTP Public Key Pinning (HPKP) [RFC7469] allows a web server to HTTP Public Key Pinning (HPKP) [RFC7469] allows a web server to
instruct browsers to remember the server's public key fingerprints instruct browsers to remember the server's public key fingerprints
for a period of time. The fingerprint is a one-way hash of the for a period of time. The fingerprint is a one-way hash of the
subject public key information in the certificate. The Public-Key- subject public key information in the certificate. The Public-Key-
Pins header provides a maximum retention period, fingerprints of the Pins header provides a maximum retention period, fingerprints of the
web server certificate, and optionally fingerprints for backup web server certificate, and optionally fingerprints for backup
certificates. The act of saving of the fingerprints is referred to certificates. The act of saving the fingerprints is referred to as
as "pinning". During pin lifetime, browsers require that the same "pinning". During the pin lifetime, browsers require that the same
web server present a certificate chain that includes a public key web server present a certificate chain that includes a public key
that matches one of the retained fingerprints. This prevents that matches one of the retained fingerprints. This prevents
impersonation of the website with a surprising certificate. impersonation of the website with a surprising certificate.
A website can choose to pin the CA certificate so that the browser A website can choose to pin the CA certificate so that the browser
will accept only valid certificates for the website domain that are will accept only valid certificates for the website domain that are
issued by that CA. Alternatively, the website can choose to pin issued by that CA. Alternatively, the website can choose to pin
their own certificate and at least one backup certificate in case the their own certificate and at least one backup certificate in case the
current certificate needs to be replaced due to a compromised server. current certificate needs to be replaced due to a compromised server.
skipping to change at page 9, line 33 skipping to change at page 10, line 7
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 eavesdropping and active network
attacks. attacks.
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 the then an error message is displayed and the user is denied access to
web application. the web application.
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 18 skipping to change at page 10, line 40
to the zone and then signing the zone. In this way, the same to the zone and then signing the zone. In this way, the same
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 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 to confirm that the received
certificate matches the one posted in the DNS. For this reason, work certificate matches the one posted in the DNS. For this reason, work
has begun on a TLS extension that will allow the DNSSEC-protected has begun on a TLS extension that will allow the DNSSEC-protected
information to be provided in the handshake, which will eliminate the information to be provided in the handshake, which will eliminate the
latency [TLSCHAIN]. 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
mis-issued certificates, and once detected, administrators and CAs surprising certificates, and once detected, administrators and CAs
can take the necessary actions to revoke the mis-issued 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
with one or more CT log. with one or more CT logs.
An administrator, or another party acting on behalf of the An administrator, or another party acting on behalf of the
administrator, is able to monitor one or more CT log to which a pre- administrator, is able to monitor one or more CT logs to which a pre-
certificate or certificate is submitted, and detect the logging of a certificate or certificate is submitted, and detect the logging of a
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 mis-issued 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.
3.4. Automation for Server Administrators 3.4. Automation for Server Administrators
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 automate obtaining and renewing certificates [PHBOB]. Without server to automate obtaining and renewing certificates [PHBOB].
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 not 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,
many web sites do not have a certificate at all. The cost, time, and many web sites do not have a certificate at all. The cost, time, and
effort are too great for the system administrator to go through the effort are too great for the system administrator. This is
effort, especially if the web site does not offer anything for especially true if the web site is not involved in financial
purchase. Second, once a certificate is obtained, a replacement is transactions or some other critical activity. Second, once a
not obtained until the current one expires. Automation can reduce certificate is obtained, a replacement is not obtained until the
the amount of time that an administrator needs to dedicate to current one expires. Automation can reduce the amount of time that
certificate management, and it can make certificate renewal timely an administrator needs to dedicate to certificate management, and it
and automatic. can make certificate renewal timely and automatic. Both of these
should lead to more widespread deployment and improved web security.
The IETF ACME working group [ACMEWG] is working on protocols that The IETF ACME working group [ACMEWG] is working on protocols that
will provide system administrators an automated way to enroll and will provide system administrators with an automated way to enroll
renew their certificates. The expectation is that these and renew their certificates. The expectation is that these
specifications will lead to widely available and interoperable tools specifications will lead to widely available and interoperable tools
for system administrators. The expectation is that these protocols for system administrators. The expectation is that these protocols
and tools will be supported by all web server environments and CAs, and tools will be supported by all web server environments and CAs,
which will greatly reduce complexity and cost. which will greatly reduce complexity and cost. In addition, the
easier renewal process provided by automation can be used to reduce
certificate lifetimes, which in turn will reduce the time required to
flush old algorithms out of the system when it is decided to
transition to newer more secure algorithms.
4. Policy and Process Improvements to the Web PKI 4. Policy and Process Improvements to the Web PKI
As with many technologies, the issues and complexities associated As with many technologies, the issues and complexities associated
with Web PKI use and deployment are just as much policy and process with Web PKI use and deployment are just as much policy and process
as technical. These have evolved over time as well. This section as technical. These have evolved over time as well. This section
discusses the ways that business models and operational policies and discusses the ways that business models and operational policies and
processes impact the Web PKI. processes impact the Web PKI.
4.1. Determination of the Trusted Certificate Authorities 4.1. Determination of the Trusted Certificate Authorities
skipping to change at page 12, line 11 skipping to change at page 12, line 34
individual CA gets added to the trust store for each of the major individual CA gets added to the trust store for each of the major
browsers is not straightforward. The individual browser vendors browsers is not straightforward. The individual browser vendors
determine what should and should not be trusted by including those determine what should and should not be trusted by including those
trusted CAs in their trust store. They do this by leveraging the trusted CAs in their trust store. They do this by leveraging the
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 may be
considered a fairly high barrier for the average user. There are considered a fairly high barrier for the average user. There are
also options to make local modifications by educated users, but there also options to make local modifications by educated users, but there
is little understanding about the implications of these choices. How is little understanding about the implications of these choices. How
does an individual, organization, or enterprise really determine if a does an 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?
skipping to change at page 12, line 45 skipping to change at page 13, line 20
Another complication with CAs and the trust store maintained by the Another complication with CAs and the trust store maintained by the
browser vendor is an enterprise managed PKI. For example, the US browser vendor is an enterprise managed PKI. For example, the US
Department of Defense operates its own PKI. In this case, the Department of Defense operates its own PKI. In this case, the
enterprise maintains its own PKI for the exclusive use of the enterprise maintains its own PKI for the exclusive use of the
enterprise itself. A bridge CA may be used to connect related enterprise itself. A bridge CA may be used to connect related
enterprises. The complication in this approach is that the enterprises. The complication in this approach is that the
revocation mechanisms don't work with any additions that have been revocation mechanisms don't work with any additions that have been
made by the enterprise. See Section 3.2.3 on proprietary revocation made by the enterprise. See Section 3.2.3 on proprietary revocation
checks. checks.
What constitutes sufficiently bad behavior by a CA to cause removal The guidelines provided by the WebTrust program [WEBTRUST] provide a
from the trust store? The guidelines provided by the WebTrust framework for removing a CA from the trust store. However, the
program [WEBTRUST] provide a framework, but the implications of implications of removing a CA can be significant. There may be a few
removing a CA can be significant. There may be a few very large CAs very large CAs that are critical to significant portions of Internet
that are critical to significant portions of Internet infrastructure. infrastructure. Removing one of these trusted CAs can have a
Removing one of these trusted CAs can have a significant impact on a significant impact on a large cross section of Internet users
large cross section of Internet users. resulting in potentially large numbers of websites no longer being
trusted. Users are already struggling to understand the implications
of untrusted websites and often ignore the current warnings as
discussed below.
4.2. Governance Structures for the Web PKI 4.2. 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,
inclusive, and transparent manner? Currently, as the name implies, inclusive, and transparent manner? Currently, as the name implies,
the CAB Forum members represent CAs and browser vendors. How do we the CAB Forum members represent CAs and browser vendors. How do we
ensure that relying parties a voice in this forum? ensure that relying parties have a voice in this forum?
Since the Web PKI is widespread, applications beyond the World Wide 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 Web are making use of the Web PKI. For example, the Web PKI is used
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. Challenges for Improving the Web PKI 5. Additional Technical Considerations
To make the Web PKI more secure and more robust, solutions to these Beyond the technical mechanisms that constitute the Web PKI itself,
technical challenges are needed: there are additional technologies that impact the success of the Web
PKI infrastructure. Examples of these are discussed in this section.
Improved certificate status checking. 5.1. Browser Error Messages
Neither CRLs nor OCSP Responders are meeting the latency and
bandwidth needs of browsers. As a result, some browser vendors Many people find browser error messages related to certificates
have started to deploy proprietary alternatives, but they are confusing. Good man-machine interfaces are always difficult, but in
not providing coverage for the whole Web PKI. In addition, this situation users are unable to understand the risks that they are
these proprietary solutions do not support non-browser relying accepting by clicking "okay". Users have been basically trained to
parties. A standard solution for all relying parties is ignore the warnings provided by the infrastructure rendering this
needed. warning ineffective. This aspect of browser usability needs to be
improved for users to make better security choices. (Editor note:
Additional detail with references is needed for this section.)
5.2. Time Synchronization
Time synchronization is another factor that impacts the security and
reliability of the Web PKI. Reasonably accurate time is needed to
check certificate expiration and to determine whether cached
revocation status information is fresh. There is ongoing work to
improve the security 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 a significant part of
this solution.
Automation for certificate enrollment and renewal. Automation for certificate enrollment and renewal.
Standard protocols are needed that provide system Develop and deploy standard protocols that provide system
administrators with an automated way to enroll and renew their administrators with an automated way to enroll and renew their
certificates. certificates. This work is currently underway in the IETF.
In addition, solutions to these procedural and policy challenges are In addition, solutions to these procedural and policy challenges are
needed: needed:
Smooth transition between cryptographic algorithms. Smooth transition between cryptographic algorithms.
Develop best practices for smooth and timely transition between
All CAs need to sign certificates with well-studied algorithms cryptographic algorithms.
and use key sizes that offer 112 to 128 bits of security. The
algorithms and key sizes will necessarily change over time.
Best practices are needed for smooth transition between
cryptographic algorithms in a timely fashion.
Eliminate surprising certificates. Eliminate surprising certificates.
Several mechanisms have been defined that can be used to Develop best practices that use one or more of the several
indicate which CAs ought to be issuing certificates for a mechanisms that have been defined throughout the Web PKI to
particular domain name or to detect them if the are issued. eliminate surprising certificates.
Best practices are needed that use one or more of these
mechanisms throughout the Web PKI to eliminate surprising
certificates.
Confidence in CA actions. Confidence in CA actions.
Currently, all CAs in the trust store are equally trusted, and Develop best practices for identifying and dealing with bad
it is unclear what forms of bad behavior by a CA will result in behavior by a CA that can be followed by all browser vendors.
removal from the trust store. Best practices are needed that
can be followed by all browser vendors.
Open and transparent Web PKI governance. Open and transparent Web PKI governance.
Many organizations act on behalf of the entire Internet Develop a governance structure that allows relying parties to
community to provide the Web PKI; however, open and transparent have a voice resulting in open and transparent governance.
governance is vital for basic trust in the Web PKI. A
governance structure that allows relying parties to have a
voice is needed.
6. Security Considerations
6.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 are
accepting by clicking "okay". This aspect of browser usability needs
to be improved for users to make better security choices.
6.2. Time Synchronization 7. Security Considerations
Time synchronization is another factor that impacts the security and This document considers the weaknesses of the current Web PKI system
reliability of the Web PKI. Reasonably accurate time is needed to and provides recommendations for improvements. Some of the risks
check certificate expiration and to determine whether cached associated with doing nothing or continuing down the current path are
revocation status information is fresh. There is ongoing work to articulated. The Web PKI is a vital component of a trusted Internet
improve the security of the time synchronization infrastructure, and and as such needs to be improved to sustain continued growth of the
it will use certificates to authenticate time servers. Since the Internet.
certificate infrastructure relies on quality time synchronization,
this dependency creates a boot strapping issue.
7. IANA Considerations 8. IANA Considerations
None. None.
{{{ RFC Editor: Please remove this section prior to publication. }}} {{{ RFC Editor: Please remove this section prior to publication. }}}
8. References 9. References
8.1. Normative References 9.1. Normative References
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <http://www.rfc-editor.org/info/rfc5280>.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Galperin, S., and C. Adams, "X.509 Internet Public Key Galperin, S., and C. Adams, "X.509 Internet Public Key
Infrastructure Online Certificate Status Protocol - OCSP", Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013, RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>. <http://www.rfc-editor.org/info/rfc6960>.
8.2. Informative References 9.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 [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/>.
[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>.
[IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D., [IMC2015] Liu, Y., Tome, W., Zhang, L., Choffnes, D., Levin, D.,
skipping to change at page 17, line 23 skipping to change at page 18, line 18
<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>.
[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
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 [SSLM] Opsmate, Inc., "SSLMate: Secure your website the easy
way", August 2015, <https://sslmate.com/>. way", August 2015, <https://sslmate.com/>.
[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-
skipping to change at page 17, line 46 skipping to change at page 18, line 46
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, Christian Huitema, Eliot Lear, Xing Li, Lucy Lynch, Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy
Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy Rowley, Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy
Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian Trammell, Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian
and Juan Carlos Zuniga. 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. 65 change blocks. 
175 lines changed or deleted 214 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/