< draft-iab-web-pki-problems-03.txt		draft-iab-web-pki-problems-04.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: March 26, 2017 Internet Society		Expires: May 1, 2017 Internet Society
	September 22, 2016		October 28, 2016
	Problems with the Public Key Infrastructure (PKI) for the World Wide Web		Improving the Public Key Infrastructure (PKI) for the World Wide Web
	draft-iab-web-pki-problems-03.txt		draft-iab-web-pki-problems-04.txt
	Abstract		Abstract
	The Public Key Infrastructure (PKI) used for the World Wide Web (Web		The Public Key Infrastructure (PKI) used for the World Wide Web (Web
	PKI) is a vital component of trust in the Internet. In recent years,		PKI) is a vital component of trust in the Internet. In recent years,
	there have been a number of improvements made to this infrastructure,		there have been a number of improvements made to this infrastructure,
	including improved certificate status checking, automation, and		including improved certificate status checking, automation, and
	transparency of governance. However, additional improvements		transparency of governance. However, additional improvements are
	necessary. This document identifies continuing areas of concerns and		necessary. This document identifies continuing areas of concern and
	provides recommendations to the Internet community for additional		provides recommendations to the Internet community for additional
	improvements, moving toward a more robust and secure Web PKI.		improvements, moving toward a more robust and secure Web PKI.
	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 March 26, 2017.		This Internet-Draft will expire on May 1, 2017.
	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 . . . . . . . . . . . . 2		2. A Brief Description of the Web PKI . . . . . . . . . . . . . 3
	3. Improvements to the Web PKI . . . . . . . . . . . . . . . . . 3		3. Improvements to the Web PKI . . . . . . . . . . . . . . . . . 4
	3.1. Weak Cryptographic Algorithms or Short Public Keys . . . 3		3.1. Strong Cryptography . . . . . . . . . . . . . . . . . . . 4
	3.2. Support for Enterprise PKIs . . . . . . . . . . . . . . . 4		3.1.1. Preparing for Quantum Computers . . . . . . . . . . . 4
	3.3. Web PKI in the Home . . . . . . . . . . . . . . . . . . . 6		3.1.2. Avoiding Weak Cryptography . . . . . . . . . . . . . 5
	3.4. Browser Error Messages . . . . . . . . . . . . . . . . . 8		3.2. Support for Enterprise PKIs . . . . . . . . . . . . . . . 6
	3.5. Governance Improvements to the Web PKI . . . . . . . . . 8		3.3. Web PKI in the Home . . . . . . . . . . . . . . . . . . . 8
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 10		3.4. Governance Improvements to the Web PKI . . . . . . . . . 10
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		4. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12
	6.1. Normative References . . . . . . . . . . . . . . . . . . 11		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6.2. Informative References . . . . . . . . . . . . . . . . . 11		7. Informative References . . . . . . . . . . . . . . . . . . . 13
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 13		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 15
	Appendix B. IAB Members at the Time of Approval . . . . . . . . 13		Appendix B. IAB Members at the Time of Approval . . . . . . . . 16
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
	1. Introduction		1. Introduction
	There are many interrelated problems with the current Public Key		The Public Key Infrastructure (PKI) for the World Wide Web (Web PKI)
	Infrastructure (PKI) used for the World Wide Web (Web PKI). The Web		has evolved into a key component of the global Internet; it enables
	PKI makes use of certificates as described in RFC 5280 [RFC5280].		trusted business and individual transactions. This global
	These certificates are primarily used with Transport Layer Security		infrastructure has been growing and evolving for many years. The
	(TLS) as described in RFC 5246 [RFC5246].		success of Web PKI has contributed to significant Internet growth.
			The Web PKI impacts all aspects of our lives, and no one can imagine
			the web without the protections that the Web PKI enables.
			As with any maturing technology, there are several problems with the
			current Web PKI. The Web PKI makes use of certificates as described
			in RFC 5280 [RFC5280]. These certificates are primarily used with
			Transport Layer Security (TLS) as described in RFC 5246 [RFC5246].
	The economics of the Web PKI value chain are discussed in [VFBH],		The economics of the Web PKI value chain are discussed in [VFBH],
	[AV], and [AVAV]. This document does not discuss the economic issues		[AV], and [AVAV]. This document does not investigate the economic
	further, but these economic issues provide motivation for correcting		issues further, but these economic issues provide motivation for
	the other problems that are discussed in this document.		correcting the other problems that are discussed in this document.
			One note of caution is that the references above assume the cost of
			acquiring a certificate is high. These costs have been decreasing in
			recent years due to a number of factors including the Let's Encrypt
			initiative discussed later in this document.
	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, but several challenges remain. This document offers a general		PKI, but several challenges remain. This document offers a general
	set of recommendations to the Internet community that might be		set of recommendations to the Internet community designed to be
	helpful in addressing these remaining challenges.		helpful in addressing these remaining challenges.
	2. Very Brief Description of the Web PKI		2. A Brief Description of the Web PKI
	Certificates are specified in RFC 5280 [RFC5280]. Certificates		This section provides a very brief introduction to some of the key
	contain, among other things, a subject name, a public key, a limited		concepts of the Web PKI. It is not intended to be a full description
	valid lifetime, and the digital signature of the Certification		of Web PKI but rather to provide some basic concepts to help frame
	Authority (CA). Certificate users require confidence that the		the remaining discussion.
	private key associated with the certified public key is owned by the
	named subject.		Web PKI is an infrastructure comprised of a number of PKIs that
			enables the establishment of trust relationships between
			communicating web entities. This trust may be chained through
			multiple intermediate parties. The root of that trust is referred to
			as a trust anchor. A relying party is an entity that depends upon
			the trust provided by the infrastructure to make informed decisions.
			A complex set of technical, policy, and legal requirements can make
			up the qualificiations for a trust anchor in a specific situation.
			Certificates are digitally signed structures that contain the
			information required to communicate the trust. Certificates are
			specified in RFC 5280 [RFC5280]. Certificates contain, among other
			things, a subject name, a public key, a limited validity lifetime,
			and the digital signature of the Certification Authority (CA).
			Certificate users require confidence that the private key associated
			with the certified public key is owned by the named subject.
	The architectural model used in the Web PKI includes:		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 end entities including Web servers and clients that		issued to end entities including Web servers and 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 end entities including Web servers and		issues certificates for end entities including Web servers and
	clients.		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.
	A valid certificate may be revoked for any number of reasons. CAs		While in its simplest form, the Web PKI is fairly straightforward,
	are responsible for indicating the revocation status of the		there are a number of concepts that can complicate the relationships
	certificates that they issue throughout the lifetime of the		and the behavior. As mentioned already, there can be intermediate
	certificate. Revocation status information may be provided using the		certificates that represent delegation within the certification path.
	Online Certificate Status Protocol (OCSP) [RFC6960], certificate		There can be cross-signing of certificates that creates
	revocation lists (CRLs) [RFC5280], or some other mechanism. In		multidimensional relationships. Browsers install numerous trust
	general, when revocation status information is provided using CRLs,		anchors associated with many different CAs in the Web PKI. All of
	the CA is also the CRL issuer. However, a CA may delegate the		this results in a complex ecosystem of trust relationships that
	responsibility for issuing CRLs to a different entity.		reflect different operational practices and underlying certificate
			policies.
			Certificates naturally expire since they contain a validity lifetime.
			In some situations, a certificate needs to be revoked before it
			expires. Revocation usually happens because the private key is lost
			or compromised, but an intermediate CA certificate can be revoked for
			bad behavior. All CAs are responsible for providing revocation
			status of the certificates that they issue throughout their lifetime
			of the certificate. Revocation status information may be provided by
			certificate revocation lists (CRLs) [RFC5280], the Online Certificate
			Status Protocol (OCSP) [RFC6960], or some other mechanism.
	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. The enrollment process should require the subject
	accomplished through a challenge-response protocol.		to use the private key; this can be accomplished with PKCS#10
			[RFC2986] or some other proof-of-possession mechanism such as
			[RFC6955].
	3. Improvements to the Web PKI		3. 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. Despite this progress, several challenges remain. This section		PKI. Despite this progress, several challenges remain. This section
	discusses several unresolved problems, and it suggests general		discusses several unresolved problems, and it suggests general
	directions for tackling them.		directions for tackling them.
	3.1. Weak Cryptographic Algorithms or Short Public Keys		3.1. Strong Cryptography
			Quantum computers [WIKI-QC] exist today, but they are not yet able to
			solve real world problems faster that digital computers. No one
			knows whether a large-scale quantum computer will be invented in the
			next decade or two that is able to break all of the public key
			algorithms that are used in the Web PKI, but it seems prudent to
			prepare for such a catastrophic event.
			In the mean time, the Web PKI needs to employ cryptographic
			algorithms that are secure against known cryptanalytic techniques and
			advanced digital computers.
			3.1.1. Preparing for Quantum Computers
			Hash-based signature algorithms [HASH-S1][HASH-S2] are quantum
			resistant, meaning that they are secure even if an attacker is able
			to build a large-scale quantum computer. Hash-based signature
			algorithms have small public and private keys, provide fast signing
			and verification operation, but they have very large signature values
			and one private key can produce a fixed number of signatures. The
			number of signatures is set at the time the key pair is generated.
			As a result of these properties, hash-based signature algorithms are
			not ideal for signing certificates. However, they are well suited
			for other uses, including signatures for software updates. The use a
			quantum resistant signature algorithm for software updates ensures
			that new software can be securely deployed even if a large-scale
			quantum computer is invented during the lifetime of the system.
			Several signature and key establishment algorithms [WIKI-PQC] are
			being investigated that might prove to be quantum resistant and offer
			properties that are suitable for use in the Web PKI. So far, none of
			these algorithms has achieved wide acceptance. Further research is
			needed.
			While this research is underway, some security protocols allow a pre-
			shared key (PSK) to be mixed with a symmetric key that is established
			with a public key algorithms. If the PSK is distributed without the
			use of a public key mechanism, the overall key establishment
			mechanism will be quantum resistant. Consider the use of a PSK for
			information that requires decades of confidentiality protection, such
			as health care information.
			The Web PKI can prepare for the for quantum computing by:
			1. Deploy hash-based signatures for software updates.
			2. For information that requires decades of confidentiality
			protection, mix a pre-shared key (PSK) as part of the key
			establishment.
			3. Continue research on quantum resistant public key cryptography.
			3.1.2. Avoiding Weak Cryptography
	Several digital signature algorithms, one-way hash functions, and		Several digital signature algorithms, one-way hash functions, and
	public key sizes that were once considered strong are no longer		public key sizes that were once considered strong are no longer
	considered adequate. This is not a surprise. Cryptographic		considered adequate. This is not a surprise. Cryptographic
	algorithms age; they become weaker over time. As new cryptanalysis		algorithms age; they become weaker over time. As new cryptanalysis
	techniques are developed and computing capabilities increase, the		techniques are developed and computing capabilities increase, the
	amount of time needed to break a particular cryptographic algorithm		amount of time needed to break a particular cryptographic algorithm
	will decrease. For this reason, the algorithms and key sizes used in		will decrease. For this reason, the algorithms and key sizes used in
	the Web PKI need to migrate over time.		the Web PKI need to migrate over time.
	Browser vendors have been trying to manage algorithm and key size		CAs and Browser vendors have been managing algorithm and key size
	transitions. It is a significant challenge to maintain a very high		transitions, but it is a significant challenge to maintain a very
	degree of interoperability across the world wide web while phasing		high degree of interoperability across the world wide web while
	out aged cryptographic algorithm or too small key size. When these		phasing out aged cryptographic algorithms or too small key sizes.
	appear in a long-lived trust anchor or intermediate CA certificate,		When these appear in a long-lived trust anchor or intermediate CA
	refusal to accept them can impact a very large certificate subtree.		certificate, refusal to accept them can impact a very large tree of
	In addition, if a certificate for a web site with a huge amount of		certificates. In addition, if a certificate for a web site with a
	traffic is in that subtree, rejecting that certificate may impact too		huge amount of traffic is in that tree, rejecting that certificate
	many users.		may impact too many users.
	Despite this situation, the MD5 and SHA-1 one-way hash functions have		Despite this situation, the MD5 and SHA-1 one-way hash functions have
	been almost completely eliminated from the Web PKI, and 1024-bit RSA		been almost completely eliminated from the Web PKI, and 1024-bit RSA
	public keys are essentially gone [MB2015] [MB2016]. It took a very		public keys are essentially gone [MB2015] [MB2016]. It took a very
	long time to make this happen, and trust anchors and certificates		long time to make this happen, and trust anchors and certificates
	that used these cryptographic algorithms were considered valid long		that used these cryptographic algorithms were considered valid long
	after they were widely known to be too weak.		after they were widely known to be too weak.
	Obviously, additional algorithm transitions will be needed in the		Obviously, additional algorithm transitions will be needed in the
	future. The algorithms and key sizes that are acceptable today will		future. The algorithms and key sizes that are acceptable today will
	become weaker with time. [RFC7696] offers some guidelines regarding		become weaker with time. RFC 7696 [RFC7696] offers some guidelines
	cryptographic algorithm agility.		regarding cryptographic algorithm agility.
	The Web PKI can prepare for the next transition by:		The Web PKI can prepare for the next transition by:
	1. Having experts periodically evaluate the current choices of		1. Having experts periodically evaluate the current choices of
	algorithm and key size. While it is not possible to predict when		algorithm and key size. While it is not possible to predict when
	a new cryptanalysis technique will be discovered, the end of the		a new cryptanalysis technique will be discovered, the end of the
	useful lifetime of most algorithms and key sizes is known many		useful lifetime of most algorithms and key sizes is known many
	years in advance.		years in advance.
	2. Planning for a smooth and orderly transition from a weak		2. Planning for a smooth and orderly transition from a weak
	algorithm or key size. Experience has shown that many years are		algorithm or key size. Experience has shown that many years are
	needed produce to specifications, develop implementations, and		needed produce to specifications, develop implementations, and
	then deploy replacements.		then deploy replacements.
	3. Reducing the lifetime of certificates, especially intermediate CA		3. Reducing the lifetime of end-entity certificates to create
	certificates, to create frequent opportunities to change an		frequent opportunities to change an algorithm or key size.
	algorithm or key size.
	3.2. Support for Enterprise PKIs		3.2. Support for Enterprise PKIs
	Many enterprises operate their own PKI. These enterprises do not		Many enterprises operate their own PKI. These enterprises do not
	want to be part of the traditional Web PKI, but they face many		want to be part of the traditional Web PKI, but they face many
	challenges in order to achieve a similar user experience and level of		challenges in order to achieve a similar user experience and level of
	security.		security.
	Users must install the trust anchor or trust anchors for the		Enterprise PKI users must install one or more enterprise trust
	enterprise PKI in their browser. There is not a standard way to		anchors in their operating system or browser. There is readily-
	accomplish trust anchor installation, and users are often faced with		available software that can install trust anchors for use by the
	scary warnings in the process of the installation.		operating system and browser, but the enterprise PKI will not be
			trusted until the system administrator or end user does this step.
	Enterprise PKI users often experience greater latency than tradition		Enterprise PKI users often experience greater latency than tradition
	Web PKI users. Some browser vendors provide a proprietary revocation		Web PKI users. Standards-based and proprietary revocation status
	checking mechanism that obtains revocation status for the entire Web		checking approches might offer relief.
	PKI in a very compact form. This mechanism eliminates latency since
	no network traffic is generated at the time that a certificate is
	being validated. However, these mechanisms cover only the trust
	anchor store for that browser vendor, excluding all enterprise PKIs.
	In addition, measurements in 2015 [IMC2015] show that these
	mechanisms do not currently provide adequate coverage of the Web PKI.
	RFC 6961 [RFC6961] defines the TLS Multiple Certificate Status		The Status Request extension to TLS [RFC6066] allows the web server
	Request extension, which allows the web server to provide status		to provide status information about its certificate. By including
	information about its own certificate and also the status of
	intermediate certificates in the certification path. By including
	this extension in the TLS handshake, the browser asks the web server		this extension in the TLS handshake, the browser asks the web server
	to provide OCSP responses in addition to the server certificate.		to provide OCSP responses in addition to the server certificate.
	This approach greatly reduces the latency since the browser does not		This approach greatly reduces the latency since the browser does not
	need to generate any OCSP requests or wait for any OCSP responses.		need to generate an OCSP request or wait for an OCSP response to
			check the validity of the server certificate. The inclusion of a
			time-stamped OCSP response in the TLS handshake is referred to as
			"OCSP stapling". In addition, the MUST_STAPLE feature [TLSFEATURE]
			can be used to insist that OCSP stapling be used.
	The provision of the time-stamped OCSP response in the TLS handshake		While not widely implemented, the Multiple Certificate Status Request
	is referred to as "stapling" the OCSP response to the TLS handshake.		extension [RFC6961] allows the web server to provide status
	If the browser does not receive a stapled OCSP response, it can		information about its own certificate and also the status of
	contact the OCSP responder directly. In addition, the MUST_STAPLE		intermediate certificates in the certification path, further reducing
	feature [TLSFEATURE] can be used to insist that OCSP stapling be		latency.
	used.
	When every browser that connects to a high volume website performs		When OCSP stapling is used by an enterprise, the OCSP responder will
	its own OCSP lookup, the OCSP responder must handle a large volume of		not receive an enormous volume of OCSP requests because the web
	OCSP requests in real-time. OCSP stapling can avoid enormous volumes		servers make a few requests and the responses are passed to the
	of OCSP requests for certificates of popular websites, so stapling		browsers in the TLS handshake. In addition, OCSP stapling can
	can significantly reduce the cost of providing an OCSP service.		improve user privacy, since the web server, not the browser, contacts
			the OCSP responder. In this way, the OCSP responder is not able to
			determine which browsers are checking the validity of certificate for
			particular websites.
	OCSP stapling can also improve user privacy, since the web server,		Some browser vendors provide a proprietary revocation checking
	not the browser, contacts the OCSP responder. In this way, the OCSP		mechanism that obtains revocation status for the entire Web PKI in a
	responder is not able to determine which browsers are checking the		very compact form. This mechanism eliminates latency since no
	validity of certificate for particular websites.		network traffic is generated at the time that a certificate is being
			validated. However, these mechanisms cover only the trust anchor
			store for that browser vendor, excluding all enterprise PKIs. In
			addition, measurements in 2015 [IMC2015] show that these mechanisms
			do not currently provide adequate coverage of the Web PKI.
	Several enterprises issue certificates to all of their employees, and		Several enterprises issue certificates to all of their employees, and
	among other uses, these certificates are used in TLS client		among other uses, these certificates are used in TLS client
	authentication. There is not a common way to import the private key		authentication. There is not a common way to import the private key
	and the client certificate into browsers. In fact, the private key		and the client certificate into browsers. In fact, the private key
	can be stored in many different formats depending on the software		can be stored in many different formats depending on the software
	used to generate the public/private key pair. PKCS#12 [RFC7292]		used to generate the public/private key pair. PKCS#12 [RFC7292]
	seems to be the most popular format at the moment. A standard way to		seems to be the most popular format at the moment. A standard way to
	import the needed keying material and a standard format will make		import the needed keying material and a standard format will make
	this task much easier, and the World Wide Web might enjoy an increase		this task much easier, and the web might enjoy an increase in mutual
	in mutual authentication.		authentication. However, please note the privacy considerations in
			Section 5.
	Enterprise PKIs can be better supported if:		Enterprise PKIs can be better supported if:
	1. Each enterprise PKI offers an OCSP Responder, and web sites with		1. Each enterprise PKI offers an OCSP Responder, and enterprise
	certificates from the enterprise PKI make use of OCSP Stapling.		websites make use of OCSP Stapling.
	2. Browser vendors support a standard way for the trust anchors for
	the enterprise PKI to be installed.
	3. Browser vendors support a standard way to install private keys		2. Operating system and browser vendors support a standard way to
	and certificates for use in client authentication.		install private keys and certificates for use in client
			authentication.
	4. In the event that browser vendors continue to offer latency-free		3. In the event that browser vendors continue to offer latency-free
	proprietary revocation status checking mechanisms, then these		proprietary revocation status checking mechanisms, then these
	mechanisms need to expand the coverage to all of the Web PKI and		mechanisms need to expand the coverage to all of the Web PKI and
	offer a means to include enterprise PKIs in the coverage.		offer a means to include enterprise PKIs in the coverage.
	3.3. Web PKI in the Home		3.3. Web PKI in the Home
	More and more, web protocols are being used to manage devices in the		More and more, web protocols are being used to manage devices in the
	home. For example, homeowners can use a web browser to connect to a		home. For example, homeowners can use a web browser to connect to a
	web site that is embedded in their home router to adjust various		web site that is embedded in their home router to adjust various
	settings. The router allows the browser to access web pages to		settings. The router allows the browser to access web pages to
	adjust these setting as long as the connection originates from the		adjust these setting as long as the connection originates from the
	home network and the proper password is provided. However, there is		home network and the proper password is provided. However, there is
	no way for the browser to authenticate to the embedded web site.		no way for the browser to authenticate to the embedded web site.
	Authentication of the web site is normally performed during the TLS		Authentication of the web site is normally performed during the TLS
	handshake, but the Web PKI is not equipped to issue certificates to		handshake, but the Web PKI is not equipped to issue certificates to
	home routers or the many other home devices that employ embedded web		home routers or the many other home devices that employ embedded web
	sites for homeowner management.		sites for homeowner management.
	A solution in this environment must not depend on the homeowner to		A solution in this environment cannot depend on the homeowner to
	perform duties that are normally associated with a web site		perform duties that are normally associated with a web site
	administrator. However, some straightforward tasks could be done at		administrator. However, some straightforward tasks could be done at
	the time the device is installed in the home. These task cannot be		the time the device is installed in the home. These tasks cannot be
	more complex that the initial setup of a new printer in the home,		more complex than the initial setup of a new printer in the home,
	otherwise they will be skipped or done incorrectly.		otherwise they will be skipped or done incorrectly.
	There are two very different approaches to certificates for home		There are three very different approaches to certificates for home
	devices that have been discussed over the years. In the first		devices that have been discussed over the years. In the first
	approach, a private key and certificate are installed in the device		approach, a private key and certificate are installed in the device
	at the factory. The certificate has an unlimited lifetime. Since it		at the factory. The certificate has an unlimited lifetime. Since it
	never expires, no homeowner action is needed to renew it. Also,		never expires, no homeowner action is needed to renew it. Also,
	since the certificate never changes, the algorithms are selected by		since the certificate never changes, the algorithms are selected by
	the factory for the lifetime of the device. The subject name in the		the factory for the lifetime of the device. The subject name in the
	certificate is quite generic, as it must be comprised of information		certificate is quite generic, as it must be comprised of information
	that is known in the factory. The subject name is often based on		that is known in the factory. The subject name is often based on
	some combination of the manufacturer, model, serial number, and MAC		some combination of the manufacturer, model, serial number, and MAC
	address. While these do uniquely identify the device, they have		address. While these do uniquely identify the device, they have
	little meaning to the homeowner.		little meaning to the homeowner. A secure device identifier, as
			defined in [IEEE802.1AR], is one example of a specification where
			locally significant identities can be securely associated with a
			manufacturer-provisioned device identifier.
	In the second approach, like the first one, a private key and a		In the second approach, like the first one, a private key and a
	certificate that are installed in the device at the factory, but the		certificate that are installed in the device at the factory, but the
	homeowner is unaware of them. This factory-installed certificate is		homeowner is unaware of them. This factory-installed certificate is
	used only to authenticate to a CA operated by the manufacturer. At		used only to authenticate to a CA operated by the manufacturer. At
	the time the device is installed, the homeowner can provide a portion		the time the device is installed, the homeowner can provide a portion
	of the subject name for the device, and the manufacturer CA can issue		of the subject name for the device, and the manufacturer CA can issue
	a certificate that includes a subject name that the homeowner will		a certificate that includes a subject name that the homeowner will
	recognize. The certificate can be renewed without any action by the		recognize. The certificate can be renewed without any action by the
	homeowner at appropriate intervals. Also, following a software		homeowner at appropriate intervals. Also, following a software
	update, the algorithms used in the TLS handshake and the certificate		update, the algorithms used in the TLS handshake and the certificate
	can be updated.		can be updated.
	Section 3.1 of this document calls for the ability to transition from		In the third approach, which is sometimes used today in Internet of
	weak cryptographic algorithms over time. For this reason, and the		Things devices, the device generates a key pair at the time the
	ability to use a subject name that the homeowner will recognize, the		device is configured for the home network, and then a controller on
	second approach is preferred.		the local network issues a certificate for the device that contains
			the freshly generated public key and a name selected by the user. If
			the device is passed on to another user, then a new key pair will be
			generated and a new name can be assigned when the device is
			configured for that user's network.
			Section 3.1.2 of this document calls for the ability to transition
			from weak cryptographic algorithms over time. For this reason, and
			the ability to use a subject name that the homeowner will recognize,
			the second or third approaches are preferred.
	One potential problem with the second approach is continuity of		One potential problem with the second approach is continuity of
	operations of the manufacturer CA. After the device is deployed, the		operations of the manufacturer CA. After the device is deployed, the
	manufacturer might go out of business, and then come time for renewal		manufacturer might go out of business or stop offering CA services,
	of the certificate, there will not be a CA to issue the new		and then come time for renewal of the certificate, there will not be
	certificate. One possible solution might be modeled on the domain		a CA to issue the new certificate. Some people see this as a way to
	name business, where other parties will continue to provide needed		end-of-life old equipment, but the users want to choose the end date,
	services if the original provider goes out of business.		not have one imposed upon them. One possible solution might be
			modeled on the domain name business, where other parties will
			continue to provide needed services if the original provider stops
			doing so.
	The Web PKI can prepare for the vast number of home devices that need		The Web PKI can prepare for the vast number of home devices that need
	certificates by:		certificates by:
	1. Building upon the work being done in the IETF ACME Working Group		1. Building upon the work being done in the IETF ACME Working Group
	[ACMEWG] to facilitate the automatic renewal of certificates for		[ACMEWG] to facilitate the automatic renewal of certificates for
	home devices without any actions by the homeowner beyond the		home devices without any actions by the homeowner beyond the
	initial device setup.		initial device setup.
	2. Working with device manufacturers to establish scalable CAs that		2. Establish conventions for the names that appear in certificates
			that accomodate the approaches discussed above and also ensure
			uniqueness without putting a burden on the homeowner.
			3. Working with device manufacturers to establish scalable CAs that
	will continue to issue certificates for the deployed devices even		will continue to issue certificates for the deployed devices even
	if the manufacture goes out of business.		if the manufacturer goes out of business.
	3. Working with device manufacturers to establish OCSP Responders so		4. Working with device manufacturers to establish OCSP Responders so
	that the web sites that are embedded in the devices can provide		that the web sites that are embedded in the devices can provide
	robust authentication and OCSP stapling in a manner that is		robust authentication and OCSP stapling in a manner that is
	compatible with traditional web sites.		compatible with traditional web sites.
	3.4. Browser Error Messages		3.4. Governance Improvements to the Web PKI
	Many users find browser error messages related to certificates
	confusing. Good man-machine interfaces are always difficult, but in
	this situation users are unable to fully understand the risks that
	they are accepting, and as a result they do not make informed
	decisions about when to proceed and when to stop. This aspect of
	browser usability needs to be improved for users to make better
	security choices.
	Browser users have been trained to ignore warnings, making them
	ineffective. Further, solving the error message situation in
	isolation is probably not possible; instead, it needs to be
	considered along side the other issues raised in this document.
	Browser users have been trained to find a way around any error, and
	very often, the error is the result of web server misconfiguration,
	and it does not actually present a risk to the browser user.
	If the risk to the user is high, then the session should be closed
	with a clear description of the problem that was encountered. Doing
	so will lead to improved management of the overall Web infrastructure
	over time, especially as the tools that are being developed for web
	server administrators are rolled out.
	In some enterprises, avoiding these errors requires the addition of
	enterprise-specific trust anchors to the browser. Additional tools
	are needed to allow administrations to easily add appropriate trust
	anchors, especially browsers on consumer devices as more and more
	enterprises are embracing bring-your-own-device policies.
	The Web PKI can simplify user choice and improve user actions by:
	1. Browser vendors providing additional intelligence to eliminate
	the majority of certificate warnings, only prompting the user
	when there is likely to be a risk.
	2. Browser vendors improving error messages to clearly indicate the
	risk that the user is accepting if they proceed.
	3.5. Governance Improvements to the Web PKI
	As with many other technologies, Web PKI technical issues are tangled		As with many other technologies, Web PKI technical issues are tangled
	up with policy and process issues. Policy and process issues have		up with policy and process issues. Policy and process issues have
	evolved over time, sometimes eroding confidence and trust in the Web		evolved over time, sometimes eroding confidence and trust in the Web
	PKI. Governance structures are needed that increase transparency and		PKI. Governance structures are needed that increase transparency and
	trust.		trust.
	Web PKI users are by definition asked to trust CAs. This includes		Web PKI users are by definition asked to trust CAs. This includes
	what CAs are trusted to do properly, and what they are trusted not to		what CAs are trusted to do properly, and what they are trusted not to
	do. The system for determining which CAs are added to or removed		do. The system for determining which CAs are added to or removed
	from the trust anchor store in browsers is opaque and confusing to		from the trust anchor store in browsers is opaque and confusing to
	most Web PKI users. The CA/Browser Forum has developed baseline		most Web PKI users. The CA/Browser Forum has developed baseline
	requirements for the management and issuance of certificates		requirements for the management and issuance of certificates
	[CAB2014] for individual CAs. However, the process by which an		[CAB2014] for individual CAs. However, the process by which an
	individual CA gets added to the trust anchor store by each of the		individual CA gets added to the trust anchor store by each of the
	browsers vendors is not straightforward. The individual browser		browser vendors is somewhat mysterious. The individual browser
	vendors determine what should and should not be trusted by including		vendors determine what should and should not be trusted by including
	the CA certificate in their trust anchor store. They do this by		the CA certificate in their trust anchor store. They do this by
	leveraging the AICPA/CICA WebTrust Program for Certification		leveraging the (###need to update or add ETSI reference) AICPA/CICA
	Authorities [WEBTRUST]. This program provides auditing requirements		WebTrust Program for Certification Authorities [WEBTRUST]. This
	and a trust mark for CAs that meet them. Failure to pass an audit		program provides auditing requirements and a trust mark for CAs that
	can result in the CA being removed from the trust store.		meet them. Failure to pass an audit can result in the CA being
			removed from the trust store.
	Once the browser has shipped, how does a user know which CAs are		Once the browser has shipped, regular updates may add or delete CAs.
	trusted or what has changed recently? For an informed user,		This is generally not something that a user would monitor. For an
	information about which CAs have been added to or deleted from the		informed user, information about which CAs have been added to or
	browser trust anchor store can be found in the browser release notes.		deleted from the browser trust anchor store can be found in the
	Users can also examine the policies of the various CAs that have been		browser release notes. Users can also examine the policies of the
	developed and posted for the WebTrust Program. However, this is a		various CAs that have been developed and posted for the WebTrust
	very high barrier for the average user. There are options to make		Program. How does an individual, organization, or enterprise really
	local modifications by educated users, but there is little		determine if a particular CA is trustworthy? Do the default choices
	understanding about the implications of these choices. How does an		inherited from the browser vendors truly represent the organization's
	individual, organization, or enterprise really determine if a		trust model? What constitutes sufficiently bad behavior by a CA to
	particular CA is trustworthy? Do the default choices inherited from		cause removal from the trust anchor store?
	the browser vendors truly represent the organization's trust model?
	What constitutes sufficiently bad behavior by a CA to cause removal
	from the trust anchor store?
	In addition, it can be hazardous for users to remove CAs from the		In addition, it can be hazardous for users to remove CAs from the
	browser trust anchor store. If a user removes a CA from the browser		browser trust anchor store. If a user removes a CA from the browser
	trust anchor store, some web sites may become completely inaccessible		trust anchor store, some web sites may become completely inaccessible
	or require the user to take explicit action to accept warnings or		or require the user to take explicit action to accept warnings or
	bypass browser protections related to untrusted certificates.		bypass browser protections related to untrusted certificates.
	The guidelines provided by the WebTrust program [WEBTRUST] provide a		The guidelines provided by the WebTrust (###ETSI?) program [WEBTRUST]
	framework for removing a CA from the trust anchor store. There may		provide a framework for removing a CA from the trust anchor store.
	be a few very large CAs that are critical to significant portions of		There may be a few very large CAs that are critical to significant
	World Wide Web infrastructure. Removing one of these CAs can have a		portions of the Web PKI. Removing one of these CAs can have a
	significant impact on a huge number of websites. As discussed in		significant impact on a huge number of websites. As discussed in
	Section 3.4, users are already struggling to understand the		briefly in Section 4, users are already struggling to understand the
	implications of untrusted certificates, so they often ignore warnings		implications of untrusted certificates, so they often ignore warnings
	presented by the browser.		presented by the browser.
	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 CA/Browser Forum, the		the operation of the Web PKI, including the CA/Browser Forum, the
	WebTrust Program, and the browser vendors. These organizations act		WebTrust Program, and the browser vendors. These organizations act
	on behalf of the entire Internet community; therefore, transparency		on behalf of the entire Internet community; therefore, transparency
	in these operations is fundamental to confidence and trust in the Web		in these operations is fundamental to confidence and trust in the Web
	PKI. Recently the CA/Browser Forum made some changes to their		PKI. In particular, transparency in both the CA/Browser Forum and
	operational procedures to make it easier for people to participate		the browser vendor processes would be helpful. Recently the CA/
	and to improve visibility into their process [CAB1.2]. This is a		Browser Forum made some changes to their operational procedures to
	significant improvement, but these processes need to continue to		make it easier for people to participate and to improve visibility
	evolve in an open, inclusive, and transparent manner. Currently, as		into their process [CAB1.2]. This is a significant improvement, but
	the name implies, the CA/Browser Forum members primarily represent		these processes need to continue to evolve in an open, inclusive, and
	CAs and browser vendors. It would be better if relying parties also		transparent manner. Currently, as the name implies, the CA/Browser
	have a voice in this forum.		Forum members primarily represent CAs and browser vendors. It would
			be better if relying parties also have a voice in this forum.
			Additionally, some browser vendors are more transparent in their
			decision processes than others, and it is felt that all should be
			more transparent.
	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 connections between SMTP servers. In these environments,		to secure connections between SMTP servers. In these environments,
	the browser-centric capabilities are unavailable. The current		the browser-centric capabilities are unavailable. The current
	governance structure does not provide a way for the relying parties		governance structure does not provide a way for the relying parties
	in these applications to participate.		in these applications to participate.
	The Web PKI governance structures can be made more open and		The Web PKI governance structures can be made more open and
	transparent by:		transparent by:
	1. Browser vendors providing additional visibility and tools to		1. Browser vendors providing additional visibility and tools to
	support the management of the trust anchor store.		support the management of the trust anchor store.
	2. Governance organizations providing a way for all relying parties,		2. Governance organizations providing a way for all relying parties,
	including ones associated with non-browser applications, to		including ones associated with non-browser applications, to
	participate.		participate.
	4. Security Considerations		4. Security Considerations
	This document considers the weaknesses of the current Web PKI system		This document considers some areas for improvement of the Web PKI.
	and provides recommendations for improvements. Some of the risks		Some of the risks associated with doing nothing or continuing down
	associated with doing nothing or continuing down the current path are		the current path are articulated. The Web PKI is a vital component
	articulated. The Web PKI is a vital component of a trusted Internet,		of a trusted Internet, and as such needs to be improved to sustain
	and as such needs to be improved to sustain continued growth of the		continued growth of the Internet.
	Internet.
	5. IANA Considerations
	None.		Many users find browser error messages related to certificates
			confusing. Good man-machine interfaces are always difficult, but in
			this situation users are unable to fully understand the risks that
			they are accepting, and as a result they do not make informed
			decisions about when to proceed and when to stop. This aspect of
			browser usability has improved over the years, and there is an
			enormous amount of ongoing work on this complex topic. It is hoped
			that further improvements will allow users to make better security
			choices.
	{{{ RFC Editor: Please remove this section prior to publication. }}}		5. Privacy Considerations
	6. References		Client certificates can be used for mutual authentication. While
			mutual authentication is usually consider better than unilateral
			authentication, there is a privacy concern in this situation. When
			mutual authentication is used, the browser sends the client
			certificate in plaintext to the webserver in the TLS handshake. This
			allows the browser user's identity to be tracked across many
			different sites by anyone that can observe the traffic.
	6.1. Normative References		6. IANA Considerations
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		None.
	Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<http://www.rfc-editor.org/info/rfc5280>.
	[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,		{{{ RFC Editor: Please remove this section prior to publication. }}}
	Galperin, S., and C. Adams, "X.509 Internet Public Key
	Infrastructure Online Certificate Status Protocol - OCSP",
	RFC 6960, DOI 10.17487/RFC6960, June 2013,
	<http://www.rfc-editor.org/info/rfc6960>.
	6.2. Informative References		7. Informative References
	[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		[AV] Arnbak, A. and N. van Eijk, "Certificate Authority
	Collapse: Regulating Systemic Vulnerabilities in the HTTPS		Collapse: Regulating Systemic Vulnerabilities in the HTTPS
	Value Chain", 2012 TRPC , August 2012,		Value Chain", 2012 TRPC , August 2012,
	<http://dx.doi.org/10.2139/ssrn.2031409>.		<http://dx.doi.org/10.2139/ssrn.2031409>.
	skipping to change at page 11, line 47 ¶		skipping to change at page 13, line 31 ¶
	[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>.
			[IEEE802.1AR]
			IEEE Standards Association, "IEEE Standard for Local and
			Metropolitan Area Networks -- Secure Device Identity",
			2009.
			[HASH-S1] McGrew, D. and M. Curcio, "Hash-Based Signatures", draft-
			mcgrew-hash-sigs-04 (work in progress), March 2016.
			[HASH-S2] Huelsing, A., Butin, D., Gazdag, S., and A. Mohaisen,
			"Hash-Based Signatures", draft-irtf-cfrg-xmss-hash-based-
			signatures-06 (work in progress), July 2016.
	[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>.
	[MB2015] Wilson, K., "Phase 2: Phasing out Certificates with		[MB2015] Wilson, K., "Phase 2: Phasing out Certificates with
	1024-bit RSA Keys", January 2015,		1024-bit RSA Keys", January 2015,
	<https://blog.mozilla.org/security/2015/01/28/phase-2-		<https://blog.mozilla.org/security/2015/01/28/phase-2-
	phasing-out-certificates-with-1024-bit-rsa-keys/>.		phasing-out-certificates-with-1024-bit-rsa-keys/>.
	[MB2016] Barnes, R., "Payment Processors Still Using Weak Crypto",		[MB2016] Barnes, R., "Payment Processors Still Using Weak Crypto",
	February 2016,		February 2016,
	<https://blog.mozilla.org/security/2016/02/24/payment-		<https://blog.mozilla.org/security/2016/02/24/payment-
	processors-still-using-weak-crypto/>.		processors-still-using-weak-crypto/>.
			[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification
			Request Syntax Specification Version 1.7", RFC 2986,
			DOI 10.17487/RFC2986, November 2000,
			<http://www.rfc-editor.org/info/rfc2986>.
	[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>.
			[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
			Housley, R., and W. Polk, "Internet X.509 Public Key
			Infrastructure Certificate and Certificate Revocation List
			(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
			<http://www.rfc-editor.org/info/rfc5280>.
			[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
			Galperin, S., and C. Adams, "X.509 Internet Public Key
			Infrastructure Online Certificate Status Protocol - OCSP",
			RFC 6960, DOI 10.17487/RFC6960, June 2013,
			<http://www.rfc-editor.org/info/rfc6960>.
	[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>.
			[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
			Extensions: Extension Definitions", RFC 6066,
			DOI 10.17487/RFC6066, January 2011,
			<http://www.rfc-editor.org/info/rfc6066>.
			[RFC6955] Schaad, J. and H. Prafullchandra, "Diffie-Hellman Proof-
			of-Possession Algorithms", RFC 6955, DOI 10.17487/RFC6955,
			May 2013, <http://www.rfc-editor.org/info/rfc6955>.
	[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,		[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A.,
	and M. Scott, "PKCS #12: Personal Information Exchange		and M. Scott, "PKCS #12: Personal Information Exchange
	Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,		Syntax v1.1", RFC 7292, DOI 10.17487/RFC7292, July 2014,
	<http://www.rfc-editor.org/info/rfc7292>.		<http://www.rfc-editor.org/info/rfc7292>.
	[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>.
	skipping to change at page 13, line 5 ¶		skipping to change at page 15, line 31 ¶
	Workshop on Economics of Information Security (WEIS)		Workshop on Economics of Information Security (WEIS)
	2011 , 2011,		2011 , 2011,
	<http://www.econinfosec.org/archive/weis2011/papers/The%20		<http://www.econinfosec.org/archive/weis2011/papers/The%20
	Inconvenient%20Truth%20about%20Web%20Certificates.pdf>.		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>.
			[WIKI-PQC]
			Wikipedia, "Post-quantum cryptography", October 2016,
			<https://en.wikipedia.org/wiki/Post-quantum_cryptography>.
			[WIKI-QC] Wikipedia, "Quantum computing", October 2016,
			<https://en.wikipedia.org/wiki/Quantum_computing>.
	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,		Peter Bowen, Alissa Cooper, Nick Doty, Stephen Farrell, Joe Hall, Ted
	Ralph Holz, Lee Howard, Christian Huitema, Eliot Lear, Xing Li, Lucy		Hardie, Paul Hoffman, Ralph Holz, Lee Howard, Christian Huitema,
	Lynch, Gervase Markham, Andrei Robachevsky, Thomas Roessler, Jeremy		Eliot Lear, Xing Li, Lucy Lynch, Gervase Markham, Eric Rescorla,
	Rowley, Christine Runnegar, Jakob Schlyter, Wendy Seltzer, Brian		Andrei Robachevsky, Thomas Roessler, Jeremy Rowley, Christine
	Trammell, and Juan Carlos Zuniga.		Runnegar, Jakob Schlyter, Wendy Seltzer, Dave Thaler, 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. 57 change blocks.
	223 lines changed or deleted		348 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/