< draft-ietf-websec-origin-05.txt		draft-ietf-websec-origin-06.txt >
	websec A. Barth		websec A. Barth
	Internet-Draft Google, Inc.		Internet-Draft Google, Inc.
	Intended status: Standards Track September 23, 2011		Intended status: Standards Track October 3, 2011
	Expires: March 26, 2012		Expires: April 5, 2012
	The Web Origin Concept		The Web Origin Concept
	draft-ietf-websec-origin-05		draft-ietf-websec-origin-06
	Abstract		Abstract
	This document defines the concept of an "origin", which is often used		This document defines the concept of an "origin", which is often used
	as the scope of authority or privilege by user agents. Typically,		as the scope of authority or privilege by user agents. Typically,
	user agents isolate content retrieved from different origins to		user agents isolate content retrieved from different origins to
	prevent malicious web site operators from interfering with the		prevent malicious web site operators from interfering with the
	operation of benign web sites. In addition to outlining the		operation of benign web sites. In addition to outlining the
	principles that underlie the concept of origin, this document defines		principles that underlie the concept of origin, this document defines
	how to determine the origin of a URI, how to serialize an origin into		how to determine the origin of a URI, how to serialize an origin into
	skipping to change at page 1, line 38 ¶		skipping to change at page 1, line 38 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on March 26, 2012.		This Internet-Draft will expire on April 5, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 15 ¶		skipping to change at page 2, line 15 ¶
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4		2.1. Conformance Criteria . . . . . . . . . . . . . . . . . . . 4
	2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		2.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4		2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 6		3. Principles of the Same-Origin Policy . . . . . . . . . . . . . 6
	3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Trust . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 7		3.1.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.2. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8		3.2.1. Examples . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8		3.3. Authority . . . . . . . . . . . . . . . . . . . . . . . . 8
	3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9		3.3.1. Pitfalls . . . . . . . . . . . . . . . . . . . . . . . 9
	3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.4. Policy . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9		3.4.1. Object Access . . . . . . . . . . . . . . . . . . . . 9
	3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10		3.4.2. Network Access . . . . . . . . . . . . . . . . . . . . 10
	skipping to change at page 2, line 41 ¶		skipping to change at page 2, line 41 ¶
	6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15		6.1. Unicode Serialization of an Origin . . . . . . . . . . . . 15
	6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15		6.2. ASCII Serialization of an Origin . . . . . . . . . . . . . 15
	7. The HTTP Origin header field . . . . . . . . . . . . . . . . . 17		7. The HTTP Origin header field . . . . . . . . . . . . . . . . . 17
	7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17		7.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17		7.2. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 17
	7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17		7.3. User Agent Requirements . . . . . . . . . . . . . . . . . 17
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 19		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19		8.1. Reliance on DNS . . . . . . . . . . . . . . . . . . . . . 19
	8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19		8.2. Divergent Units of Isolation . . . . . . . . . . . . . . . 19
	8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20		8.3. Ambient Authority . . . . . . . . . . . . . . . . . . . . 20
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		8.4. IDNA dependency and migration . . . . . . . . . . . . . . 20
	9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 21		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
	10. IDNA dependency and migration . . . . . . . . . . . . . . . . 22		9.1. Origin . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	11.1. Normative References . . . . . . . . . . . . . . . . . . . 23		10.1. Normative References . . . . . . . . . . . . . . . . . . . 23
	11.2. Informative References . . . . . . . . . . . . . . . . . . 24		10.2. Informative References . . . . . . . . . . . . . . . . . . 23
	Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 26		Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 25
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	User agents interact with content created by a large number of		User agents interact with content created by a large number of
	authors. Although many of those authors are well-meaning, some		authors. Although many of those authors are well-meaning, some
	authors might be malicious. To the extent that user agents undertake		authors might be malicious. To the extent that user agents undertake
	actions based on content they process, user agent implementors might		actions based on content they process, user agent implementors might
	wish to restrict the ability of malicious authors to disrupt the		wish to restrict the ability of malicious authors to disrupt the
	confidentiality or integrity of other content or servers.		confidentiality or integrity of other content or servers.
	skipping to change at page 4, line 37 ¶		skipping to change at page 4, line 37 ¶
	notation of [RFC5234].		notation of [RFC5234].
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-		sequence of data), SP (space), HTAB (horizontal tab), CHAR (any US-
	ASCII character), VCHAR (any visible US-ASCII character), and WSP		ASCII character), VCHAR (any visible US-ASCII character), and WSP
	(whitespace).		(whitespace).
	The OWS (optional whitespace) rule is used where zero or more linear		The OWS rule is used where zero or more linear whitespace octets
	whitespace characters MAY appear:		might appear. OWS SHOULD either not be produced or be produced as a
			single SP. Multiple OWS octets that occur within field-content
	OWS = *( [ obs-fold ] WSP )		SHOULD either be replaced with a single SP or transformed to all SP
	; "optional" whitespace		octets (each octet other than SP replaced with SP) before
	obs-fold = CRLF		interpreting the field value or forwarding the message downstream.
	OWS SHOULD either not be produced or be produced as a single SP		OWS = *( SP / HTAB / obs-fold )
	character.		; "optional" whitespace
			obs-fold = CRLF ( SP / HTAB )
			; obsolete line folding
	2.3. Terminology		2.3. Terminology
	The terms user agent, client, server, proxy, and origin server have		The terms user agent, client, server, proxy, and origin server have
	the same meaning as in the HTTP/1.1 specification ([RFC2616], Section		the same meaning as in the HTTP/1.1 specification ([RFC2616], Section
	1.3).		1.3).
	A globally unique identifier is a value which is different from all		A globally unique identifier is a value which is different from all
	other previously existing values. For example, a sufficiently long		other previously existing values. For example, a sufficiently long
	random string is likely to be a globally unique identifier. If the		random string is likely to be a globally unique identifier. If the
	origin value never leaves the user agent, a monotonically increasing		origin value never leaves the user agent, a monotonically increasing
	counter local to the user agent can also serve as a globally unique		counter local to the user agent can also serve as a globally unique
	identifier		identifier
	For the purposes of this document, we define "idna-canonicalized host
	name" as the string generated by the following algorithm:
	1. Convert the host name to a sequence of NR-LDH labels (see Section
	2.3.2.2 of [RFC5890]) and/or A-labels according to the
	appropriate IDNA specification [RFC5891] or [RFC3490] (see
	Section 10 of this specification)
	2. Convert the labels to lower case (using the i;ascii-casemap
	collation defined in [RFC4790]).
	3. Concatenate the labels, separating each label from the next with
	a %x2E (".") character.
	3. Principles of the Same-Origin Policy		3. Principles of the Same-Origin Policy
	Many user agents undertake actions on behalf of remote parties. For		Many user agents undertake actions on behalf of remote parties. For
	example, HTTP user agents follow redirects, which are instructions		example, HTTP user agents follow redirects, which are instructions
	from remote servers and HTML user agents expose rich DOM interfaces		from remote servers and HTML user agents expose rich DOM interfaces
	to scripts retrieved from remote servers.		to scripts retrieved from remote servers.
	Without any security model, user agents might undertake actions		Without any security model, user agents might undertake actions
	detrimental to the user or to other parties. Over time, many web-		detrimental to the user or to other parties. Over time, many web-
	related technologies have converged towards a common security model,		related technologies have converged towards a common security model,
	skipping to change at page 12, line 14 ¶		skipping to change at page 12, line 14 ¶
	4. Origin of a URI		4. Origin of a URI
	The origin of a URI is the value computed by the following algorithm:		The origin of a URI is the value computed by the following algorithm:
	1. If the URI does not use a hierarchical element as a naming		1. If the URI does not use a hierarchical element as a naming
	authority (see [RFC3986], Section 3.2), or if the URI is not an		authority (see [RFC3986], Section 3.2), or if the URI is not an
	absolute URI, then generate a fresh globally unique identifier		absolute URI, then generate a fresh globally unique identifier
	and return that value.		and return that value.
	1. NOTE: Running this algorithm multiple times for the same URI		NOTE: Running this algorithm multiple times for the same URI
	can produce different values each time. Typically, user		can produce different values each time. Typically, user
	agents compute the origin of, for example, an HTML document		agents compute the origin of, for example, an HTML document
	once and use that origin for subsequent security checks		once and use that origin for subsequent security checks rather
	rather than recomputing the origin for each security check.		than recomputing the origin for each security check.
	2. Let uri-scheme be the scheme component of the URI, converted to		2. Let uri-scheme be the scheme component of the URI, converted to
	lowercase.		lowercase.
	3. If the implementation doesn't support the protocol given by uri-		3. If the implementation doesn't support the protocol given by uri-
	scheme, then return generate a fresh globally unique identifier		scheme, then return generate a fresh globally unique identifier
	and return that value.		and return that value.
	4. If uri-scheme is "file", the implementation MAY return an		4. If uri-scheme is "file", the implementation MAY return an
	implementation-defined value.		implementation-defined value.
	1. NOTE: Historically, user agents have granted content from the		1. NOTE: Historically, user agents have granted content from the
	file scheme a tremendous amount of privilege. However,		file scheme a tremendous amount of privilege. However,
	granting all local files such wide privileges can lead to		granting all local files such wide privileges can lead to
	privilege escalation attacks. Some user agents have had		privilege escalation attacks. Some user agents have had
	success granting local files directory-based privileges, but		success granting local files directory-based privileges, but
	this approach has not been widely adopted. Other user agents		this approach has not been widely adopted. Other user agents
	use globally unique identifiers for each file URI, which is		use globally unique identifiers for each file URI, which is
	the most secure option.		the most secure option.
	5. Let uri-host be the idna-canonicalized form of the host component		5. Let uri-host be the host component of the URI, converted to lower
	of the URI.		case (using the i;ascii-casemap collation defined in [RFC4790]).
			1. NOTE: This document assumes that the user agent performs IDNA
			processing and validation when constructing the URI. In
			particular, this document assumes the uri-host will contain
			only LDH-labels because the user agent will have already
			converted any non-ASCII labels to their corresponding
			A-labels (see [RFC5890]). For this reason, origin-based
			security policies are sensitive to the IDNA algorithm
			employed by the user agent. See Section 8.4 for further
			discussion.
	6. If there is no port component of the URI:		6. If there is no port component of the URI:
	1. Let uri-port be the default port for the protocol given by		1. Let uri-port be the default port for the protocol given by
	uri-scheme.		uri-scheme.
	Otherwise:		Otherwise:
	2. Let uri-port be the port component of the URI.		2. Let uri-port be the port component of the URI.
	skipping to change at page 15, line 27 ¶		skipping to change at page 15, line 27 ¶
	null		null
	(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)		(i.e., the code point sequence U+006E, U+0075, U+006C, U+006C)
	and abort these steps.		and abort these steps.
	2. Otherwise, let result be the scheme part of the origin triple.		2. Otherwise, let result be the scheme part of the origin triple.
	3. Append the string "://" to result.		3. Append the string "://" to result.
	4. Apply the IDNA ToUnicode algorithm (from the appropriate IDNA		4. Append each component of the host part of the origin triple
	specification [RFC5891] or [RFC3490], see Section 10 of this		(converted as follows) to the result, separated by U+002E FULL
	specification) to each component of the host part of the origin		STOP code points ("."):
	triple, and append the results of each component, in the same
	order, separated by U+002E FULL STOP code points (".") to result.		* If the component is an A-label, use the corresponding U-label
			instead (see [RFC5890] and [RFC5891]).
			* Otherwise, use the component verbatim.
	5. If the port part of the origin triple is different than the		5. If the port part of the origin triple is different than the
	default port for the protocol given by the scheme part of the		default port for the protocol given by the scheme part of the
	origin triple:		origin triple:
	1. Append a U+003A COLON code point (":") and the given port, in		1. Append a U+003A COLON code point (":") and the given port, in
	base ten, to result.		base ten, to result.
	6. Return result.		6. Return result.
	skipping to change at page 17, line 13 ¶		skipping to change at page 17, line 13 ¶
	6. Return result.		6. Return result.
	7. The HTTP Origin header field		7. The HTTP Origin header field
	This section defines the HTTP Origin header field.		This section defines the HTTP Origin header field.
	7.1. Syntax		7.1. Syntax
	The Origin header field has the following syntax:		The Origin header field has the following syntax:
	origin = "Origin:" OWS origin-list-or-null OWS		origin = "Origin:" OWS origin-list-or-null OWS
	origin-list-or-null = "null" / origin-list		origin-list-or-null = %x6E %x75 %x6C %x6C / origin-list
	origin-list = serialized-origin *( SP serialized-origin )		origin-list = serialized-origin *( SP serialized-origin )
	serialized-origin = scheme "://" host [ ":" port ]		serialized-origin = scheme "://" host [ ":" port ]
	; <scheme>, <host>, <port> productions from RFC3986		; <scheme>, <host>, <port> from RFC3986
	7.2. Semantics		7.2. Semantics
	When included in an HTTP request, the Origin header field indicates		When included in an HTTP request, the Origin header field indicates
	the origin(s) that "caused" the user agent to issue the request, as		the origin(s) that "caused" the user agent to issue the request, as
	defined by the API that triggered the user agent to issue the		defined by the API that triggered the user agent to issue the
	request.		request.
	For example, consider a user agent that executes scripts on behalf of		For example, consider a user agent that executes scripts on behalf of
	origins. If one of those scripts causes the user agent to issue an		origins. If one of those scripts causes the user agent to issue an
	skipping to change at page 21, line 5 ¶		skipping to change at page 20, line 38 ¶
	Consider, for example, cross-site scripting in HTML documents. If an		Consider, for example, cross-site scripting in HTML documents. If an
	attacker can inject script content into an HTML document, those		attacker can inject script content into an HTML document, those
	scripts will run with the authority of the document's origin, perhaps		scripts will run with the authority of the document's origin, perhaps
	allowing the script access to sensitive information, such as the		allowing the script access to sensitive information, such as the
	user's medical records. If, however, the script's authority were		user's medical records. If, however, the script's authority were
	limited to those objects that the script could designate, the		limited to those objects that the script could designate, the
	attacker would not gain any advantage by injecting the script into an		attacker would not gain any advantage by injecting the script into an
	HTML document hosted by a third party.		HTML document hosted by a third party.
			8.4. IDNA dependency and migration
			The security properties of the same-origin policy can depend
			crucially on details of the IDNA algorithm employed by the user
			agent. In particular, a user agent might map some international
			domain names (for example, those involving the U+00DF character) to
			different ASCII representations depending on whether the user agent
			uses IDNA2003 [RFC3490] or IDNA2008 [RFC5890].
			Migrating from one IDNA algorithm to another might redraw a number of
			security boundaries, potentially erecting new security boundaries or,
			worse, tearing down security boundaries between two mutually
			distrusting entities. Changing security boundaries is risky because
			combining two mutually distrusting entities into the same origin
			might allow one to attack the other.
	9. IANA Considerations		9. IANA Considerations
	The permanent message header field registry (see [RFC3864]) should be		The permanent message header field registry (see [RFC3864]) should be
	updated with the following registrations:		updated with the following registrations:
	9.1. Origin		9.1. Origin
	Header field name: Origin		Header field name: Origin
	Applicable protocol: http		Applicable protocol: http
	Status: standard		Status: standard
	Author/Change controller: IETF		Author/Change controller: IETF
	Specification document: this specification (Section 7)		Specification document: this specification (Section 7)
	10. IDNA dependency and migration		10. References
	IDNA2008 [RFC5890] supersedes IDNA2003 [RFC3490] but is not
	backwards-compatible. For this reason, there will be a transition
	period (possibly of a number of years). User agents SHOULD implement
	IDNA2008 [RFC5890] and MAY implement [UnicodeTR46] in order to
	facilitate a smoother IDNA transition. If a user agent does not
	implement IDNA2008, the user agent MUST implement IDNA2003 [RFC3490].
	11. References
	11.1. Normative References		10.1. Normative References
	[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,		[RFC20] Cerf, V., "ASCII format for network interchange", RFC 20,
	October 1969.		October 1969.
	[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.
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext		Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
	Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.		Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
	[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
	"Internationalizing Domain Names in Applications (IDNA)",
	RFC 3490, March 2003.
	See Section 10 for an explanation why the normative
	reference to an obsoleted specification is needed.
	[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration		[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration
	Procedures for Message Header Fields", BCP 90, RFC 3864,		Procedures for Message Header Fields", BCP 90, RFC 3864,
	September 2004.		September 2004.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet		[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet
	Application Protocol Collation Registry", RFC 4790,		Application Protocol Collation Registry", RFC 4790,
	March 2007.		March 2007.
	[UnicodeTR46]
	The Unicode Consortium, "Unicode IDNA Compatibility
	Processing", 2010, <http://unicode.org/reports/tr46/>.
	[Unicode52]		[Unicode52]
	The Unicode Consortium, "The Unicode Standard, Version		The Unicode Consortium, "The Unicode Standard, Version
	5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN		5.1.0", Unicode 5.0.0, Boston, MA, Addison-Wesley ISBN
	0-321-48091-0, as amended by Unicode 5.1.0		0-321-48091-0, as amended by Unicode 5.1.0
	http://www.unicode.org/versions/Unicode5.1.0/, 2008,		http://www.unicode.org/versions/Unicode5.1.0/, 2008,
	<http://www.unicode.org/versions/Unicode5.2.0/>.		<http://www.unicode.org/versions/Unicode5.2.0/>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	[RFC5890] Klensin, J., "Internationalized Domain Names for		[RFC5890] Klensin, J., "Internationalized Domain Names for
	Applications (IDNA): Definitions and Document Framework",		Applications (IDNA): Definitions and Document Framework",
	RFC 5890, August 2010.		RFC 5890, August 2010.
	[RFC5891] Klensin, J., "Internationalized Domain Names in		[RFC5891] Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol", RFC 5891, August 2010.		Applications (IDNA): Protocol", RFC 5891, August 2010.
	11.2. Informative References		10.2. Informative References
	[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, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, August 2008.
	[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,		[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
	August 1998.		August 1998.
	[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within		[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
	HTTP/1.1", RFC 2817, May 2000.		HTTP/1.1", RFC 2817, May 2000.
			[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
			"Internationalizing Domain Names in Applications (IDNA)",
			RFC 3490, March 2003.
			See Section 8.4 for an explanation why the normative
			reference to an obsoleted specification is needed.
	[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,		[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
	April 2011.		April 2011.
	[WEBSOCKETS]		[WEBSOCKETS]
	Fette, I., "The WebSocket protocol",		Fette, I. and A. Melnikov, "The WebSocket protocol",
	draft-ietf-hybi-thewebsocketprotocol-09 (work in		draft-ietf-hybi-thewebsocketprotocol-17 (work in
	progress), June 2011.		progress), September 2011.
	[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing",		[SNIFF] Barth, A. and I. Hickson, "Media Type Sniffing",
	draft-ietf-websec-mime-sniff-03 (work in progress),		draft-ietf-websec-mime-sniff-03 (work in progress),
	May 2011.		May 2011.
	[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525,		[HTML] Hickson, I., "HTML5", W3C Working Draft WD-html5-20110525,
	May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>.		May 2011, <http://www.w3.org/TR/2011/WD-html5-20110525/>.
	Latest version available at <http://www.w3.org/TR/html5/>.		Latest version available at <http://www.w3.org/TR/html5/>.
	skipping to change at page 26, line 8 ¶		skipping to change at page 25, line 8 ¶
	<http://w2spconf.com/2008/papers/s2p1.pdf>.		<http://w2spconf.com/2008/papers/s2p1.pdf>.
	[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman,		[CRX] Barth, A., Felt, A., Saxena, P., and A. Boodman,
	"Protecting Browsers from Extension Vulnerabilities",		"Protecting Browsers from Extension Vulnerabilities",
	2010,		2010,
	<http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.		<http://www.isoc.org/isoc/conferences/ndss/10/pdf/04.pdf>.
	Appendix A. Acknowledgements		Appendix A. Acknowledgements
	We would like to thank Lucas Adamski, Stephen Farrell, Miguel A.		We would like to thank Lucas Adamski, Stephen Farrell, Miguel A.
	Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Collin		Garcia, Tobias Gondrom, Ian Hickson, Anne van Kesteren, Jeff Hodges,
	Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham, Julian		Collin Jackson, Larry Masinter, Alexey Melnikov, Mark Nottingham,
	Reschke, Jonas Sicking, Sid Stamm, Daniel Veditz, and Chris Weber for		Julian Reschke, Peter Saint-Andre, Jonas Sicking, Sid Stamm, Daniel
	their valuable feedback on this document.		Veditz, and Chris Weber for their valuable feedback on this document.
	Author's Address		Author's Address
	Adam Barth		Adam Barth
	Google, Inc.		Google, Inc.
	Email: ietf@adambarth.com		Email: ietf@adambarth.com
	URI: http://www.adambarth.com/		URI: http://www.adambarth.com/
End of changes. 21 change blocks.
	82 lines changed or deleted		86 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/