< draft-ietf-websec-key-pinning-07.txt		draft-ietf-websec-key-pinning-08.txt >
	Web Security C. Evans		Web Security C. Evans
	Internet-Draft C. Palmer		Internet-Draft C. Palmer
	Intended status: Standards Track R. Sleevi		Intended status: Standards Track R. Sleevi
	Expires: January 10, 2014 Google, Inc.		Expires: January 13, 2014 Google, Inc.
	July 09, 2013		July 12, 2013
	Public Key Pinning Extension for HTTP		Public Key Pinning Extension for HTTP
	draft-ietf-websec-key-pinning-07		draft-ietf-websec-key-pinning-08
	Abstract		Abstract
	This memo describes an extension to the HTTP protocol allowing web		This memo describes an extension to the HTTP protocol allowing web
	host operators to instruct user agents (UAs) to remember ("pin") the		host operators to instruct user agents (UAs) to remember ("pin") the
	hosts' cryptographic identities for a given period of time. During		hosts' cryptographic identities for a given period of time. During
	that time, UAs will require that the host present a certificate chain		that time, UAs will require that the host present a certificate chain
	including at least one Subject Public Key Info structure whose		including at least one Subject Public Key Info structure whose
	fingerprint matches one of the pinned fingerprints for that host. By		fingerprint matches one of the pinned fingerprints for that host. By
	effectively reducing the number of authorities who can authenticate		effectively reducing the number of authorities who can authenticate
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	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 January 10, 2014.		This Internet-Draft will expire on January 13, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 32 ¶		skipping to change at page 2, line 32 ¶
	2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7		2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7
	2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7		2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7
	2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8		2.2.2. HTTP Request Type . . . . . . . . . . . . . . . . . . 8
	2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8		2.3. User Agent Processing Model . . . . . . . . . . . . . . . 8
	2.3.1. Public-Key-Pins Response Header Field Processing . . 8		2.3.1. Public-Key-Pins Response Header Field Processing . . 8
	2.3.2. Noting a Pinned Host - Storage Model . . . . . . . . 9		2.3.2. Noting a Pinned Host - Storage Model . . . . . . . . 9
	2.3.3. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 10		2.3.3. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 10
	2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 10		2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 10
	2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 11		2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 11
	2.6. Validating Pinned Connections . . . . . . . . . . . . . . 12		2.6. Validating Pinned Connections . . . . . . . . . . . . . . 12
	2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 13		2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 12
	2.8. Pinning Self-Signed End Entities . . . . . . . . . . . . 13		2.8. Pinning Self-Signed End Entities . . . . . . . . . . . . 13
	3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 13		3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 13
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 15		4. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15		4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15
	4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 16		4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 16
	4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 17		4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 17
	5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17		5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	7. Usability Considerations . . . . . . . . . . . . . . . . . . 19		7. Usability Considerations . . . . . . . . . . . . . . . . . . 19
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 19		9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 19
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.1. Normative References . . . . . . . . . . . . . . . . . . 20		10.1. Normative References . . . . . . . . . . . . . . . . . . 20
	skipping to change at page 11, line 42 ¶		skipping to change at page 11, line 42 ¶
	o The UA MUST note the Pins if and only if the given set of Pins		o The UA MUST note the Pins if and only if the given set of Pins
	contains at least one Pin that does NOT refer to an SPKI in the		contains at least one Pin that does NOT refer to an SPKI in the
	certificate chain. (That is, the host must set a Backup Pin; see		certificate chain. (That is, the host must set a Backup Pin; see
	Section 4.3.)		Section 4.3.)
	If the Public-Key-Pins response header field does not meet all three		If the Public-Key-Pins response header field does not meet all three
	of these criteria, the UA MUST NOT note the host as a Pinned Host. A		of these criteria, the UA MUST NOT note the host as a Pinned Host. A
	Public-Key-Pins response header field that meets all these critera is		Public-Key-Pins response header field that meets all these critera is
	known as a Valid Pinning Header.		known as a Valid Pinning Header.
	The UA MUST ignore Public-Key-Pins response header fields received on
	connections that do not meet the first criterion.
	Whenever a UA receives a Valid Pinning Header, it MUST set its		Whenever a UA receives a Valid Pinning Header, it MUST set its
	Pinning Metadata to the exact Pins, max-age, and (if any) report-uri		Pinning Metadata to the exact Pins, max-age, and (if any) report-uri
	and strict mode given in the most recently received Valid Pinning		and strict mode given in the most recently received Valid Pinning
	Header.		Header.
	For forward compatibility, the UA MUST ignore any unrecognized		For forward compatibility, the UA MUST ignore any unrecognized
	Public-Key-Pins header directives, while still processing those		Public-Key-Pins header directives, while still processing those
	directives it does recognize. Section 2.1 specifies the directives		directives it does recognize. Section 2.1 specifies the directives
	max-age, pins, includeSubDomains, report-uri, and strict, but future		max-age, pins, includeSubDomains, report-uri, and strict, but future
	specifications and implementations might use additional directives.		specifications and implementations might use additional directives.
	skipping to change at page 19, line 29 ¶		skipping to change at page 19, line 26 ¶
	8. Acknowledgements		8. Acknowledgements
	Thanks to Tobias Gondrom, Jeff Hodges, Ivan Krstic, Adam Langley,		Thanks to Tobias Gondrom, Jeff Hodges, Ivan Krstic, Adam Langley,
	Nicolas Lidzborski, SM, James Manger, Eric Rescorla, Paul Hoffman,		Nicolas Lidzborski, SM, James Manger, Eric Rescorla, Paul Hoffman,
	and Yoav Nir for suggestions and edits that clarified the text.		and Yoav Nir for suggestions and edits that clarified the text.
	Thanks to Trevor Perrin for suggesting a mechanism to affirmatively		Thanks to Trevor Perrin for suggesting a mechanism to affirmatively
	break pins ([pin-break-codes]).		break pins ([pin-break-codes]).
	9. What's Changed		9. What's Changed
			[RFC EDITOR: PLEASE REMOVE THIS SECTION]
	Added normative references for SHA, JSON, and base-64.		Added normative references for SHA, JSON, and base-64.
	Added the Privacy Considerations section.		Added the Privacy Considerations section.
	Changed non-normative pin generation code from Go to POSIX shell		Changed non-normative pin generation code from Go to POSIX shell
	script using openssl.		script using openssl.
	Changed max-max-age from SHOULD to MAY, and used the example of 60		Changed max-max-age from SHOULD to MAY, and used the example of 60
	days instead of 30.		days instead of 30.
End of changes. 7 change blocks.
	9 lines changed or deleted		8 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/