< draft-ietf-xmpp-posh-03.txt		draft-ietf-xmpp-posh-04.txt >
	XMPP Working Group M. Miller		XMPP Working Group M. Miller
	Internet-Draft Cisco Systems, Inc.		Internet-Draft Cisco Systems, Inc.
	Intended status: Standards Track P. Saint-Andre		Intended status: Standards Track P. Saint-Andre
	Expires: July 30, 2015 &yet		Expires: August 27, 2015 &yet
	January 26, 2015		February 23, 2015
	PKIX over Secure HTTP (POSH)		PKIX over Secure HTTP (POSH)
	draft-ietf-xmpp-posh-03		draft-ietf-xmpp-posh-04
	Abstract		Abstract
	Experience has shown that it is extremely difficult to deploy proper		Experience has shown that it is extremely difficult to deploy proper
	PKIX certificates for TLS in multi-tenanted environments. As a		PKIX certificates for TLS in multi-tenanted environments. As a
	result, domains hosted in such environments often deploy applications		result, domains hosted in such environments often deploy applications
	using certificates that identify the hosting service, not the hosted		using certificates that identify the hosting service, not the hosted
	domain. Such deployments force end users and peer services to accept		domain. Such deployments force end users and peer services to accept
	a certificate with an improper identifier, resulting in obvious		a certificate with an improper identifier, resulting in obvious
	security implications. This document defines two methods that make		security implications. This document defines two methods that make
	skipping to change at page 1, line 42 ¶		skipping to change at page 1, line 42 ¶
	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 July 30, 2015.		This Internet-Draft will expire on August 27, 2015.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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
	skipping to change at page 2, line 21 ¶		skipping to change at page 2, line 21 ¶
	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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Obtaining Verification Materials . . . . . . . . . . . . . . 4		3. Obtaining Verification Materials . . . . . . . . . . . . . . 4
	3.1. Source Domain Possesses PKIX Certificate Information . . 5		3.1. Source Domain Possesses PKIX Certificate Information . . 5
	3.2. Source Domain References PKIX Certificate . . . . . . . . 6		3.2. Source Domain References PKIX Certificate . . . . . . . . 7
	3.3. Performing Verification . . . . . . . . . . . . . . . . . 7		3.3. Performing Verification . . . . . . . . . . . . . . . . . 8
	4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8		4. Secure Delegation . . . . . . . . . . . . . . . . . . . . . . 8
	5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8		5. Order of Operations . . . . . . . . . . . . . . . . . . . . . 8
	6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 9		6. Caching Results . . . . . . . . . . . . . . . . . . . . . . . 10
	7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10		7. Alternates and Roll-over . . . . . . . . . . . . . . . . . . 10
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. Guidelines for Protocols that Use POSH . . . . . . . . . . . 11
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 11		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		11.1. Normative References . . . . . . . . . . . . . . . . . . 12
			11.2. Informative References . . . . . . . . . . . . . . . . . 13
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 14
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
	1. Introduction		1. Introduction
	We begin with a thought experiment.		We begin with a thought experiment.
	Imagine that you work on the operations team of a hosting company		Imagine that you work on the operations team of a hosting company
	that provides the "foo" service (or email or instant messaging or		that provides the "SPICE" service (or email or instant messaging or
	social networking service) for ten thousand different customer		social networking service) for ten thousand different customer
	organizations. Each customer wants their service to be identified by		organizations. Each customer wants their service to be identified by
	the customer's domain name (e.g., bar.example.com), not the hosting		the customer's domain name (e.g., bar.example.com), not the hosting
	company's domain name (e.g., hosting.example.net).		company's domain name (e.g., hosting.example.net).
	In order to properly secure each customer's "foo" service via		In order to properly secure each customer's "SPICE" service via
	Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX		Transport Layer Security (TLS) [RFC5246], you need to obtain PKIX
	certificates [RFC5280] containing identifiers such as		certificates [RFC5280] containing identifiers such as
	bar.example.com, as explained in the "CertID" specification		bar.example.com, as explained in the "CertID" specification
	[RFC6125]. Unfortunately, you can't obtain such certificates		[RFC6125]. Unfortunately, you can't obtain such certificates
	because:		because:
	o Certification authorities won't issue such certificates to you		o Certification authorities won't issue such certificates to you
	because you work for the hosting company, not the customer		because you work for the hosting company, not the customer
	organization.		organization.
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	Based Authentication of Named Entities (DANE) [RFC6698] to solve the		Based Authentication of Named Entities (DANE) [RFC6698] to solve the
	problem. However, your customers and your operations team have told		problem. However, your customers and your operations team have told
	you that it will be several years before they will be able to deploy		you that it will be several years before they will be able to deploy
	DNSSEC and DANE for all of your customers (because of tooling		DNSSEC and DANE for all of your customers (because of tooling
	updates, slow deployment of DNSSEC at some top-level domains, etc.).		updates, slow deployment of DNSSEC at some top-level domains, etc.).
	The product managers in your company are pushing you to find a method		The product managers in your company are pushing you to find a method
	that can be deployed more quickly to overcome the lack of proper		that can be deployed more quickly to overcome the lack of proper
	server identity checking for your hosted customers.		server identity checking for your hosted customers.
	One possible approach that your team has investigated is to ask each		One possible approach that your team has investigated is to ask each
	customer to provide the public key / certificate for the "foo"		customer to provide the public key / certificate for the "SPICE"
	service at a special HTTPS URL on their website		service at a special HTTPS URL on their website
	("https://bar.example.com/.well-known/posh.foo.json" is one		("https://bar.example.com/.well-known/posh.spice.json" is one
	possibility). This could be a public key that you generate for the		possibility). This could be a public key that you generate for the
	customer, but because the customer hosts it via HTTPS, any user agent		customer, but because the customer hosts it via HTTPS, any user agent
	can find that public key and check it against the public key you		can find that public key and check it against the public key you
	provide during TLS negotiation for the "foo" service (as one added		provide during TLS negotiation for the "SPICE" service (as one added
	benefit, the customer never needs to hand you a private key).		benefit, the customer never needs to hand you a private key).
	Alternatively, the customer can redirect requests for that special		Alternatively, the customer can redirect requests for that special
	HTTPS URL to an HTTPS URL at your own website, thus making it		HTTPS URL to an HTTPS URL at your own website, thus making it
	explicit that they have delegated the "foo" service to you.		explicit that they have delegated the "SPICE" service to you.
	The approach sketched out above, called POSH ("PKIX Over Secure		The approach sketched out above, called POSH ("PKIX Over Secure
	HTTP"), is explained in the remainder of this document. While this		HTTP"), is explained in the remainder of this document. While this
	approach was developed for use in the Extensible Messaging and		approach was developed for use in the Extensible Messaging and
	Presence Protocol (XMPP) as a prooftype for Domain Name Associations		Presence Protocol (XMPP) as a prooftype for Domain Name Associations
	(DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP		(DNA) [I-D.ietf-xmpp-dna], it can be applied to any non-HTTP
	application protocol.		application protocol.
	2. Terminology		2. Terminology
	This document inherits security terminology from [RFC5280]. The		This document inherits security terminology from [RFC5280]. The
	terms "Source Domain", "Delegated Domain", "Derived Domain", and		terms "Source Domain", "Delegated Domain", "Derived Domain", and
	"Reference Identifier" are used as defined in the "CertID"		"Reference Identifier" are used as defined in the "CertID"
	specification [RFC6125].		specification [RFC6125].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
			Additionally, this document uses the following terms:
			POSH client: The client utilizing the application service (e.g., an
			XMPP client). It relies on the protocol defined herein to verify
			the POSH server's identity.
			POSH server: The server hosting the application service (e.g., an
			XMPP server). It expects clients to rely on the protocol defined
			herein to verify its identity.
	3. Obtaining Verification Materials		3. Obtaining Verification Materials
	Server identity checking (see [RFC6125]) involves three different		Server identity checking (see [RFC6125]) involves three different
	aspects:		aspects:
	1. A proof of the POSH server's identity (in PKIX, this takes the		1. A proof of the POSH server's identity (in PKIX, this takes the
	form of a PKIX end-entity certificate [RFC5280]).		form of a PKIX end-entity certificate [RFC5280]).
	2. Rules for checking the certificate (which vary by application		2. Rules for checking the certificate (which vary by application
	protocol, although [RFC6125] attempts to harmonize those rules).		protocol, although [RFC6125] attempts to harmonize those rules).
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 16 ¶
	server proves it identity by presenting a PKIX certificate [RFC5280]		server proves it identity by presenting a PKIX certificate [RFC5280]
	and the certificate is checked according to the rules defined in the		and the certificate is checked according to the rules defined in the
	appropriate application protocol specification (such as [RFC6120] for		appropriate application protocol specification (such as [RFC6120] for
	XMPP). However, the POSH client obtains the materials it will use to		XMPP). However, the POSH client obtains the materials it will use to
	verify the server's proof by retrieving a JSON document [RFC7159]		verify the server's proof by retrieving a JSON document [RFC7159]
	containing hashes of the PKIX certificate over HTTPS ([RFC7230] and		containing hashes of the PKIX certificate over HTTPS ([RFC7230] and
	[RFC2818]) from a well-known URI [RFC5785] at the Source Domain.		[RFC2818]) from a well-known URI [RFC5785] at the Source Domain.
	(This means that the POSH client needs to verify the certificate of		(This means that the POSH client needs to verify the certificate of
	the HTTPS service at the Source Domain in order to securely		the HTTPS service at the Source Domain in order to securely
	"bootstrap" into the use of POSH; specifically, the rules of		"bootstrap" into the use of POSH; specifically, the rules of
	[RFC2818] apply to this "bootstrapping" step to provide a secure		[RFC2818] apply to this "bootstrapping" step to provide a secure
	basis for all subsequent POSH processing.)		basis for all subsequent POSH processing.)
	The process for retrieving a PKIX certificate over secure HTTP is as		The process for retrieving a PKIX certificate over secure HTTP is as
	follows.		follows.
	1. The POSH client performs an HTTPS GET request at the Source		1. The POSH client performs an HTTPS GET request at the Source
	Domain to the path "/.well-known/posh.{servicedesc}.json". The		Domain to the path "/.well-known/posh.{servicedesc}.json". The
	value of "{servicedesc}" is application-specific; see Section 8		value of "{servicedesc}" is application-specific; see Section 9
	of this document for more details. For example, if the		of this document for more details. For example, if the
	application protocol is some hypothetical "foo" service, then		application protocol is some hypothetical "SPICE" service, then
	"{servicedesc}" could be "foo"; thus if an application client		"{servicedesc}" could be "spice"; thus if an application client
	were to use POSH to verify an application server for the Source		were to use POSH to verify an application server for the Source
	Domain "bar.example.com", the HTTPS GET request would be as		Domain "bar.example.com", the HTTPS GET request would be as
	follows:		follows:
	GET /.well-known/posh.foo.json HTTP/1.1		GET /.well-known/posh.spice.json HTTP/1.1
	Host: bar.example.com		Host: bar.example.com
	2. The Source Domain HTTPS server responds in one of three ways:		2. The Source Domain HTTPS server responds in one of three ways:
	* If it possesses PKIX certificate information for the requested		* If it possesses PKIX certificate information for the requested
	path, it responds as detailed in Section 3.1.		path, it responds as detailed in Section 3.1.
	* If it has a reference to where the PKIX certificate		* If it has a reference to where the PKIX certificate
	information can be obtained, it responds as detailed in		information can be obtained, it responds as detailed in
	Section 3.2.		Section 3.2.
	skipping to change at page 6, line 5 ¶		skipping to change at page 6, line 15 ¶
	the document is a JSON object which MUST have the following:		the document is a JSON object which MUST have the following:
	o A "fingerprints" field whose value is a JSON array of fingerprint		o A "fingerprints" field whose value is a JSON array of fingerprint
	descriptors.		descriptors.
	o An "expires" field whose value is a JSON number specifying the		o An "expires" field whose value is a JSON number specifying the
	number of seconds after which the POSH client ought to consider		number of seconds after which the POSH client ought to consider
	the key information to be stale (further explained under		the key information to be stale (further explained under
	Section 6).		Section 6).
			The JSON document returned MUST NOT contain a "url" field as
			described in Section 3.2.
	Each included fingerprint descriptor is a JSON object, where each		Each included fingerprint descriptor is a JSON object, where each
	member name is the textual name of a hash function (as listed in		member name is the textual name of a hash function (as listed in
	[HASH-NAMES]) and its associated value is the base 64 encoded		[HASH-NAMES]) and its associated value is the base 64 encoded
	fingerprint hash generated using the named hash function (where the		fingerprint hash generated using the named hash function (where the
	encoding adheres to the definition in Section 4 of [RFC4648] and		encoding adheres to the definition in Section 4 of [RFC4648] and
	where the padding bits are set to zero). Each fingerprint descriptor		where the padding bits are set to zero). Each fingerprint descriptor
	MUST possess at least one named hash function.		MUST possess at least one named hash function.
	The fingerprint hash for a given hash algorithm is generated by		The fingerprint hash for a given hash algorithm is generated by
	performing the named hash function over the DER encoding of the PKIX		performing the named hash function over the DER encoding of the PKIX
	skipping to change at page 7, line 20 ¶		skipping to change at page 7, line 32 ¶
	number of seconds after which the POSH client ought to consider		number of seconds after which the POSH client ought to consider
	the delegation to be stale (further explained under Section 6).		the delegation to be stale (further explained under Section 6).
	Example Reference Response		Example Reference Response
	HTTP/1.1 200 Ok		HTTP/1.1 200 Ok
	Content-Type: application/json		Content-Type: application/json
	Content-Length: 79		Content-Length: 79
	{		{
	"url":"https://hosting.example.net/.well-known/posh.foo.json",		"url":"https://hosting.example.net/.well-known/posh.spice.json",
	"expires":86400		"expires":86400
	}		}
	The client performs an HTTPS GET request for the URL specified in the		The client performs an HTTPS GET request for the URL specified in the
	"url" field value. The HTTPS server for the URL to which the client		"url" field value. The HTTPS server for the URL to which the client
	has been redirected responds to the request with a JSON document		has been redirected responds to the request with a JSON document
	containing fingerprints as described in Section 3.1. The content		containing fingerprints as described in Section 3.1. The content
	retrieved from the "url" location MUST NOT itself be a reference		retrieved from the "url" location MUST NOT itself be a reference
	(i.e., containing a "url" field instead of a "fingerprints" field),		(i.e., containing a "url" field instead of a "fingerprints" field),
	in order to prevent circular delegations.		in order to prevent circular delegations.
	Note: The JSON document returned by the Source Domain HTTPS server		Note: See Section 10 for discussion about HTTPS redirects.
	MUST contain either a reference or a fingerprints document, but
	MUST NOT contain both.
	Note: See Section 9 for discussion about HTTPS redirects.
	The "expires" value is a hint regarding the expiration of the Source		The "expires" value is a hint regarding the expiration of the Source
	Domain's delegation of service to the Delegated Domain. It MUST be a		Domain's delegation of service to the Delegated Domain. It MUST be a
	non-negative integer. If no "expires" field is included or its value		non-negative integer. If no "expires" field is included or its value
	is equal to 0, a POSH client SHOULD consider the delegation invalid.		is equal to 0, a POSH client SHOULD consider the delegation invalid.
	See Section 6 for guidelines about reconciling this "expires" field		See Section 6 for guidelines about reconciling this "expires" field
	with the "expires" field of the fingerprints document.		with the "expires" field of the fingerprints document.
	3.3. Performing Verification		3.3. Performing Verification
	skipping to change at page 10, line 33 ¶		skipping to change at page 11, line 5 ¶
	"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="		"sha-256":"otyLADSKjRDjVpj8X7/hmCAD5C7Qe+PedcmYV7cUncE="
	}		}
	],		],
	"expires": 806400		"expires": 806400
	}		}
	Rolling over from one hosting provider to another is best handled by		Rolling over from one hosting provider to another is best handled by
	updating the relevant SRV records, not primarily by updating the POSH		updating the relevant SRV records, not primarily by updating the POSH
	files themselves.		files themselves.
	8. IANA Considerations		8. Guidelines for Protocols that Use POSH
	This document registers a well-known URI [RFC5785] for protocols that
	use POSH. The completed template follows.
	URI suffix: posh.
	Change controller: IETF
	Specification document: [[ this document ]]
	Related information: Because the "posh." string is merely a		Protocols that use POSH will need to register well-known URIs wth the
	prefix, protocols that use POSH need to register particular		IANA in accordance with [RFC5785] (the IANA registration policy
	URIs that are prefixed with the "posh." string.		[RFC5226] for well-known URIs is Specification Required).
	Note that the registered URI is "posh." (with a trailing dot). This		For the sake of consistency, it would be best if the URIs registered
	is merely a prefix to be placed at the front of well-known URIs		by such protocols match the URI template [RFC6570] path "/.well-
	[RFC5785] registered by protocols that use POSH, which themselves are		known/posh.{servicedesc}.json"; that is, begin with "posh." and end
	responsible for the relevant registrations with the IANA. The URIs		with ".json" (indicating a media type of application/json [RFC7159]).
	registered by such protocols SHOULD match the URI template [RFC6570]
	path "/.well-known/posh.{servicedesc}.json"; that is, begin with
	"posh." and end with ".json" (indicating a media type of application/
	json [RFC7159]).
	For POSH-using protocols that rely on DNS SRV records [RFC2782], the		For POSH-using protocols that rely on DNS SRV records [RFC2782], it
	"{servicedesc}" part of the well-known URI SHOULD be		would be best if the "{servicedesc}" part of the well-known URI is
	"{service}.{proto}", where the "{service}" is the DNS SRV "Service"		"{service}.{proto}", where the "{service}" is the DNS SRV "Service"
	prepended by the underscore character "_" and the "{proto}" is the		prepended by the underscore character "_" and the "{proto}" is the
	DNS SRV "Proto" also prepended by the underscore character "_". As		DNS SRV "Proto" also prepended by the underscore character "_". As
	an example, the well-known URI for XMPP server-to-server connections		an example, the well-known URI for XMPP server-to-server connections
	would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers		would be "posh._xmpp-server._tcp.json" since XMPP [RFC6120] registers
	a service name of "xmpp-server" and uses TCP as the underlying		a service name of "xmpp-server" and uses TCP as the underlying
	transport protocol.		transport protocol.
	For other POSH-using protocols, the "{servicedesc}" part of the well-		For other POSH-using protocols, the "{servicedesc}" part of the well-
	known URI can be any unique string or identifier for the protocol,		known URI can be any unique string or identifier for the protocol,
	which might be a service name registered with the IANA in accordance		which might be a service name registered with the IANA in accordance
	with [RFC6335] or which might be an unregistered name. As an		with [RFC6335] or which might be an unregistered name. As an
	example, the well-known URI for the mythical "foo" service could be		example, the well-known URI for a hypothetical "SPICE" application
	"posh.foo.json".		could be "posh.spice.json".
	Note: As explained in [RFC5785], the IANA registration policy		9. IANA Considerations
	[RFC5226] for well-known URIs is Specification Required.
	9. Security Considerations		This document requests no actions of IANA. [Note to RFC Editor:
			please remove this section before publication.]
			10. Security Considerations
	This document supplements but does not supersede the security		This document supplements but does not supersede the security
	considerations provided in specifications for application protocols		considerations provided in specifications for application protocols
	that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP).		that decide to use POSH (e.g., [RFC6120] and [RFC6125] for XMPP).
	Specifically, the security of requests and responses sent via HTTPS		Specifically, the security of requests and responses sent via HTTPS
	depends on checking the identity of the HTTP server in accordance		depends on checking the identity of the HTTP server in accordance
	with [RFC2818]. Additionally, the security of POSH can benefit from		with [RFC2818]. Additionally, the security of POSH can benefit from
	other HTTP hardening protocols, such as HSTS [RFC6797] and key		other HTTP hardening protocols, such as HSTS [RFC6797] and key
	pinning [I-D.ietf-websec-key-pinning], especially if the POSH client		pinning [I-D.ietf-websec-key-pinning], especially if the POSH client
	shares some information with a common HTTPS implementation (e.g.,		shares some information with a common HTTPS implementation (e.g.,
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 17 ¶
	certificate enrollment with a certification authority via HTTPS, as		certificate enrollment with a certification authority via HTTPS, as
	is done in Enrollment over Secure Transport [RFC7030].		is done in Enrollment over Secure Transport [RFC7030].
	A web server at the Source Domain might redirect an HTTPS request to		A web server at the Source Domain might redirect an HTTPS request to
	another URL. The location provided in the redirect response MUST		another URL. The location provided in the redirect response MUST
	specify an HTTPS URL. Source domains SHOULD use only temporary		specify an HTTPS URL. Source domains SHOULD use only temporary
	redirect mechanisms, such as HTTP status codes 302 (Found) and 307		redirect mechanisms, such as HTTP status codes 302 (Found) and 307
	(Temporary Redirect). Clients MAY treat any redirect as temporary,		(Temporary Redirect). Clients MAY treat any redirect as temporary,
	ignoring the specific semantics for 301 (Moved Permanently) and 308		ignoring the specific semantics for 301 (Moved Permanently) and 308
	(Permanent Redirect) [RFC7238]. To protect against circular		(Permanent Redirect) [RFC7238]. To protect against circular
	references, clients MUST NOT follow an infinite number of redirects.		references, it is RECOMMENDED that POSH clients follow no more than
	It is RECOMMENDED that clients follow no more than 10 redirects,		10 redirects, although applications or implementations can require
	although applications or implementations can require that fewer		that fewer redirects be followed.
	redirects be followed.
	Hash function agility is an important quality to ensure secure		Hash function agility is an important quality to ensure secure
	operations in the face of attacks against the fingerprints obtained		operations in the face of attacks against the fingerprints obtained
	within verification materials. Because POSH verification materials		within verification materials. Because POSH verification materials
	are relatively short-lived compared to long-lived credentials such as		are relatively short-lived compared to long-lived credentials such as
	PKIX end-entity certificates (at least as typically deployed),		PKIX end-entity certificates (at least as typically deployed),
	entities that deploy POSH are advised to swap out POSH files if the		entities that deploy POSH are advised to swap out POSH files if the
	hash functions in use are found to be subject to realistic attacks.		hash functions in use are found to be subject to realistic attacks.
	10. References		11. References
	10.1. Normative References		11.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.		[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
	[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data		[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
	Encodings", RFC 4648, October 2006.		Encodings", RFC 4648, October 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	skipping to change at page 13, line 18 ¶		skipping to change at page 13, line 18 ¶
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, March 2011.		Security (TLS)", RFC 6125, March 2011.
	[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, March 2014.		Interchange Format", RFC 7159, March 2014.
	[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol		[RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
	(HTTP/1.1): Message Syntax and Routing", RFC 7230, June		(HTTP/1.1): Message Syntax and Routing", RFC 7230, June
	2014.		2014.
	10.2. Informative References		11.2. Informative References
	[I-D.ietf-dane-srv]		[I-D.ietf-dane-srv]
	Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-		Finch, T., Miller, M., and P. Saint-Andre, "Using DNS-
	Based Authentication of Named Entities (DANE) TLSA Records		Based Authentication of Named Entities (DANE) TLSA Records
	with SRV Records", draft-ietf-dane-srv-06 (work in		with SRV Records", draft-ietf-dane-srv-11 (work in
	progress), June 2014.		progress), February 2015.
	[I-D.ietf-websec-key-pinning]		[I-D.ietf-websec-key-pinning]
	Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning		Evans, C., Palmer, C., and R. Sleevi, "Public Key Pinning
	Extension for HTTP", draft-ietf-websec-key-pinning-14		Extension for HTTP", draft-ietf-websec-key-pinning-21
	(work in progress), June 2014.		(work in progress), October 2014.
	[I-D.ietf-xmpp-dna]		[I-D.ietf-xmpp-dna]
	Saint-Andre, P. and M. Miller, "Domain Name Associations		Saint-Andre, P., Miller, M., and P. Hancke, "Domain Name
	(DNA) in the Extensible Messaging and Presence Protocol		Associations (DNA) in the Extensible Messaging and
	(XMPP)", draft-ietf-xmpp-dna-05 (work in progress),		Presence Protocol (XMPP)", draft-ietf-xmpp-dna-09 (work in
	February 2014.		progress), February 2015.
	[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for		[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
	specifying the location of services (DNS SRV)", RFC 2782,		specifying the location of services (DNS SRV)", RFC 2782,
	February 2000.		February 2000.
	[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "DNS Security Introduction and Requirements", RFC		Rose, "DNS Security Introduction and Requirements", RFC
	4033, March 2005.		4033, March 2005.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
End of changes. 34 change blocks.
	72 lines changed or deleted		69 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/