draft-ietf-websec-key-pinning-12.txt   draft-ietf-websec-key-pinning-13.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: October 31, 2014 Google, Inc. Expires: November 14, 2014 Google, Inc.
April 29, 2014 May 13, 2014
Public Key Pinning Extension for HTTP Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-12 draft-ietf-websec-key-pinning-13
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 October 31, 2014. This Internet-Draft will expire on November 14, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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.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. Interaction of Public-Key-Pins and Public-Key-Pins- 2.3.2. Interaction of Public-Key-Pins and Public-Key-Pins-
Report-Only . . . . . . . . . . . . . . . . . . . . . 9 Report-Only . . . . . . . . . . . . . . . . . . . . . 9
2.3.3. Noting a Pinned Host - Storage Model . . . . . . . . 10 2.3.3. Noting a Pinned Host - Storage Model . . . . . . . . 10
2.3.4. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 11 2.3.4. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 11
2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 11 2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 11
2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 12 2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Validating Pinned Connections . . . . . . . . . . . . . . 12 2.6. Validating Pinned Connections . . . . . . . . . . . . . . 13
2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 13 2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 13
2.8. Pinning Self-Signed End Entities . . . . . . . . . . . . 14 2.8. Pinning Self-Signed End Entities . . . . . . . . . . . . 14
3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 14 3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 4. Security Considerations . . . . . . . . . . . . . . . . . . . 16
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 18 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 17
4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 18 4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 17
4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 18
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20 4.4. Interactions With Cookie Scoping . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Usability Considerations . . . . . . . . . . . . . . . . . . 21 7. Usability Considerations . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 22 9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 21
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 23 10.1. Normative References . . . . . . . . . . . . . . . . . . 22
10.2. Informative References . . . . . . . . . . . . . . . . . 24 10.2. Informative References . . . . . . . . . . . . . . . . . 23
Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 24 Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 23
Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 24 Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction 1. Introduction
We propose a new HTTP header to enable a web host to express to user We propose a new HTTP header to enable a web host to express to user
agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs agents (UAs) which Subject Public Key Info (SPKI) structure(s) UAs
SHOULD expect to be present in the host's certificate chain in future SHOULD expect to be present in the host's certificate chain in future
connections using TLS (see [RFC5246]). We call this "public key connections using TLS (see [RFC5246]). We call this "public key
pinning". At least one UA (Google Chrome) has experimented with the pinning". At least one UA (Google Chrome) has experimented with the
idea by shipping with a user-extensible embedded set of Pins. idea by shipping with a user-extensible embedded set of Pins.
Although effective, this does not scale. This proposal addresses the Although effective, this does not scale. This proposal addresses the
skipping to change at page 6, line 42 skipping to change at page 6, line 42
later). Similarly, if Known Pinned Host A sets a report-uri later). Similarly, if Known Pinned Host A sets a report-uri
referring to Known Pinned Host B, and if B sets a report-uri referring to Known Pinned Host B, and if B sets a report-uri
referring to A, and if both hosts fail Pin Validation, the UA SHOULD referring to A, and if both hosts fail Pin Validation, the UA SHOULD
detect and break the loop by failing to send reports to and about detect and break the loop by failing to send reports to and about
those hosts. those hosts.
UAs SHOULD limit the rate at which they send reports. For example, UAs SHOULD limit the rate at which they send reports. For example,
it is unnecessary to send the same report to the same report-uri more it is unnecessary to send the same report to the same report-uri more
than once. than once.
UAs MUST NOT send a report if the Host is not already a Known Pinned
Host. (I.e., the UA's first connection to a Host fails Pin
Validation.) The reason for this is so that a potential active
network attacker cannot learn about a UA's certificate validation and
Pin Validation procedures and state.
2.1.4. Examples 2.1.4. Examples
Figure 3 shows some example response header fields using the Pins Figure 3 shows some example response header fields using the Pins
extension (folded for clarity). extension (folded for clarity).
Public-Key-Pins: max-age=3000; Public-Key-Pins: max-age=3000;
pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM="; pin-sha256="d6qzRu9zOECb90Uez27xWltNsj0e1Md7GkYYkVoZWmM=";
pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g="; pin-sha256="E9CZ9INDbd+2eRQozYqqbQ2yXLVKB9+xcprMF+44U1g=";
Public-Key-Pins: max-age=2592000; Public-Key-Pins: max-age=2592000;
skipping to change at page 7, line 48 skipping to change at page 7, line 48
This section describes the processing model that Pinned Hosts This section describes the processing model that Pinned Hosts
implement. The model comprises two facets: the processing rules for implement. The model comprises two facets: the processing rules for
HTTP request messages received over a secure transport (e.g. TLS HTTP request messages received over a secure transport (e.g. TLS
[RFC5246]); and the processing rules for HTTP request messages [RFC5246]); and the processing rules for HTTP request messages
received over non-secure transports, such as TCP. received over non-secure transports, such as TCP.
2.2.1. HTTP-over-Secure-Transport Request Type 2.2.1. HTTP-over-Secure-Transport Request Type
When replying to an HTTP request that was conveyed over a secure When replying to an HTTP request that was conveyed over a secure
transport, a Pinned Host SHOULD include in its response exactly one transport, a Pinned Host SHOULD include in its response exactly one
PKP header field that MUST satisfy the grammar specified above in PKP header field, exactly one PKP-RO header field, or one of each,
Section 2.1. which MUST satisfy the grammar specified above in Section 2.1.
Establishing a given host as a Known Pinned Host, in the context of a Establishing a given host as a Known Pinned Host, in the context of a
given UA, MAY be accomplished over the HTTP protocol, which is in given UA, MAY be accomplished over the HTTP protocol, which is in
turn running over secure transport, by correctly returning (per this turn running over secure transport, by correctly returning (per this
specification) at least one valid PKP header field to the UA. Other specification) at least one valid PKP header field to the UA. Other
mechanisms, such as a client-side pre-loaded Known Pinned Host list mechanisms, such as a client-side pre-loaded Known Pinned Host list
MAY also be used. MAY also be used.
2.2.2. HTTP Request Type 2.2.2. HTTP Request Type
skipping to change at page 9, line 5 skipping to change at page 9, line 5
o The max-age value is essentially a "time to live" value relative o The max-age value is essentially a "time to live" value relative
to the time of the most recent observation of the PKP header to the time of the most recent observation of the PKP header
field. field.
o If the max-age header field value token has a value of 0, the UA o If the max-age header field value token has a value of 0, the UA
MUST remove its cached Pinning Policy information (including the MUST remove its cached Pinning Policy information (including the
includeSubDomains directive, if asserted) if the Pinned Host is includeSubDomains directive, if asserted) if the Pinned Host is
Known, or, MUST NOT note this Pinned Host if it is not yet Known. Known, or, MUST NOT note this Pinned Host if it is not yet Known.
o If a UA receives more than one PKP header field in an HTTP o If a UA receives more than one PKP header field or more than one
response message over secure transport, then the UA MUST process PKP-RO header fieled in an HTTP response message over secure
only the first such header field. transport, then the UA MUST process only the first PKP header
field (if present) and only the first PKP-RO header field (if
present).
Otherwise: Otherwise:
o If the UA receives the HTTP response over insecure transport, or o If the UA receives the HTTP response over insecure transport, or
if the PKP header is not a Valid Pinning Header (see Section 2.5), if the PKP header is not a Valid Pinning Header (see Section 2.5),
the UA MUST ignore any present PKP header field(s). the UA MUST ignore any present PKP header field(s).
o The UA MUST ignore any PKP header fields not conforming to the o The UA MUST ignore any PKP header fields not conforming to the
grammar specified in Section 2.1. grammar specified in Section 2.1.
skipping to change at page 9, line 38 skipping to change at page 9, line 40
When the Public-Key-Pins-Report-Only header is used with a report- When the Public-Key-Pins-Report-Only header is used with a report-
uri, the UA SHOULD POST reports for Pin Validation failures to the uri, the UA SHOULD POST reports for Pin Validation failures to the
indicated report-uri, although the UA MUST NOT enforce Pin indicated report-uri, although the UA MUST NOT enforce Pin
Validation. That is, in the event of Pin Validation failure when the Validation. That is, in the event of Pin Validation failure when the
host has set the Public-Key-Pins-Report-Only header, the UA performs host has set the Public-Key-Pins-Report-Only header, the UA performs
Pin Validation only to check whether or not it should POST a report, Pin Validation only to check whether or not it should POST a report,
but not for causing connection failure. but not for causing connection failure.
Note: There is no purpose to using the Public-Key-Pins-Report-Only Note: There is no purpose to using the Public-Key-Pins-Report-Only
header without the report-uri directive. User Agents MAY discard header without the report-uri directive. User Agents MAY discard
such headers without interpretting them further. such headers without interpreting them further.
If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD If a Host sets the Public-Key-Pins-Report-Only header, the UA SHOULD
note the Pins and directives given in the Public-Key-Pins-Report-Only note the Pins and directives given in the Public-Key-Pins-Report-Only
header as specified by the max-age directive. If the UA does note header as specified by the max-age directive. If the UA does note
the Pins and directives in the Public-Key-Pins-Report-Only header it the Pins and directives in the Public-Key-Pins-Report-Only header it
SHOULD evaluate the specified policy and SHOULD report any would-be SHOULD evaluate the specified policy and SHOULD report any would-be
Pin Validation failures that would occur if the report-only policy Pin Validation failures that would occur if the report-only policy
were enforced. were enforced.
If a Host sets both the Public-Key-Pins header and the Public-Key- If a Host sets both the Public-Key-Pins header and the Public-Key-
skipping to change at page 12, line 45 skipping to change at page 12, line 48
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
given in the most recently received Valid Pinning Header. given in the most recently received Valid Pinning 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, and report-uri but future max-age, Pins, includeSubDomains, and report-uri but future
specifications and implementations might use additional directives. specifications and implementations might use additional directives.
Upon receipt of a Public-Key-Pins-Report-Only response header field,
the UA SHOULD evaluate the policy expressed in the PKP-RO field, and
SHOULD generate and send a report (see Section 3). However, failure
to validate the pins in the PKP-RO MUST have no effect on the
validity or non-validity of the policy expressed in the PKP field or
in previously-noted pins for the Known Pinned Host.
The UA SHOULD NOT note any pins or other policy expressed in the PKP-
RO response header field.
2.6. Validating Pinned Connections 2.6. Validating Pinned Connections
When a UA connects to a Pinned Host, if the TLS connection has When a UA connects to a Pinned Host, if the TLS connection has
errors, the UA MUST terminate the connection without allowing the errors, the UA MUST terminate the connection without allowing the
user to proceed anyway. (This behavior is the same as that required user to proceed anyway. (This behavior is the same as that required
by [RFC6797].) by [RFC6797].)
If the connection has no errors, then the UA will determine whether If the connection has no errors, then the UA will determine whether
to apply a new, additional correctness check: Pin Validation. A UA to apply a new, additional correctness check: Pin Validation. A UA
SHOULD perform Pin Validation whenever connecting to a Known Pinned SHOULD perform Pin Validation whenever connecting to a Known Pinned
Host, but MAY allow Pin Validation to be disabled for Hosts according Host, but MAY allow Pin Validation to be disabled for Hosts according
to local policy. For example, a UA may disable Pin Validation for to local policy. For example, a UA may disable Pin Validation for
Pinned Hosts whose validated certificate chain terminates at a user- Pinned Hosts whose validated certificate chain terminates at a user-
defined trust anchor, rather than a trust anchor built-in to the UA. defined trust anchor, rather than a trust anchor built-in to the UA.
To perform Pin Validation, the UA will compute the SPKI Fingerprints To perform Pin Validation, the UA will compute the SPKI Fingerprints
for each certificate in the Pinned Host's validated certificate for each certificate in the Pinned Host's validated certificate
skipping to change at page 13, line 38 skipping to change at page 14, line 4
before beginning an HTTP conversation over the TLS channel. The TLS before beginning an HTTP conversation over the TLS channel. The TLS
layer thus evaluates TLS connections with pinning information the UA layer thus evaluates TLS connections with pinning information the UA
received previously, regardless of mechanism: statically preloaded, received previously, regardless of mechanism: statically preloaded,
via HTTP header, or some other means (possibly in the TLS layer via HTTP header, or some other means (possibly in the TLS layer
itself). itself).
2.7. Interactions With Preloaded Pin Lists 2.7. Interactions With Preloaded Pin Lists
UAs MAY choose to implement additional sources of pinning UAs MAY choose to implement additional sources of pinning
information, such as through built-in lists of pinning information. information, such as through built-in lists of pinning information.
Such UAs SHOULD allow users to override such additional sources, Such UAs SHOULD allow users to override such additional sources,
including disabling them from consideration. including disabling them from consideration.
UAs that support additional sources of pinning information MUST use The effective policy for a Known Pinned Host that has both built-in
the most recently observed pinning information when performing Pin pins and pins from previously observed PKP header response fields is
Validation for a host. The most recently observed pinning implementation-defined.
information is determined based upon the most recent Effective Pin
Date, as described in Section 2.3.3. The Effective Pin Date of
built-in pin lists is UA implementation-defined.
If the result of noting a Valid Pinning Header is to disable pinning
for the host, such as through supplying a max-age directive with a
value of 0, UAs MUST allow this new information to override any other
pinning data. That is, a host must be able to un-pin itself, even in
the presence of built-in Pins.
Example: A UA may ship with a pre-configured list of Pins that are
collected from past observations of Valid Pinning Headers supplied by
hosts. In such a solution, the pre-configured list should track when
the Valid Pinning Header was last observed, in order to permit site
operators to later update the value by supplying a new Valid Pinning
Header. Updates to such a pre-configured list should not update the
Effective Pin Dates for each host unless the list vendor has actually
observed a more recent header. This is to prevent situations where
updating the Effective Pin Date on a pre-configured list of Pins may
effectively extend the max-age beyond the site operator's stated
policy.
Example: A UA may ship with a pre-configured list of Pins that are
collected through out-of-band means, such as direct contact with the
site operator. In such a solution, the site operator accepts
responsibility for keeping the configured Valid Pinning Header in
sync with the vendor's list, allowing the UA vendor to have each
update to the list be treated as as an update of the Effective Pin
Date.
2.8. Pinning Self-Signed End Entities 2.8. Pinning Self-Signed End Entities
If UAs accept hosts that authenticate themselves with self-signed end If UAs accept hosts that authenticate themselves with self-signed end
entity certificates, they MAY also allow hosts to pin the public keys entity certificates, they MAY also allow hosts to pin the public keys
in such certificates. The usability and security implications of in such certificates. The usability and security implications of
this practice are outside the scope of this specification. this practice are outside the scope of this specification.
3. Reporting Pin Validation Failure 3. Reporting Pin Validation Failure
skipping to change at page 20, line 8 skipping to change at page 19, line 11
key of a secondary, not-yet-deployed key pair. The operator keeps key of a secondary, not-yet-deployed key pair. The operator keeps
the backup key pair offline, and sets a pin for it in the Public-Key- the backup key pair offline, and sets a pin for it in the Public-Key-
Pins header. Then, in case the operator loses control of their Pins header. Then, in case the operator loses control of their
primary private key, they can deploy the backup key pair. UAs, who primary private key, they can deploy the backup key pair. UAs, who
have had the backup key pair pinned (when it was set in previous have had the backup key pair pinned (when it was set in previous
Valid Pinning Headers), can connect to the host without error. Valid Pinning Headers), can connect to the host without error.
Because having a backup key pair is so important to recovery, UAs Because having a backup key pair is so important to recovery, UAs
MUST require that hosts set a Backup Pin. (See Section 2.5.) MUST require that hosts set a Backup Pin. (See Section 2.5.)
4.4. Interactions With Cookie Scoping
HTTP cookies [RFC6265] set by a Known Pinned Host can be stolen by a
network attacker who can forge web and DNS responses so as to cause a
client to send the cookies to a phony subdomain of the Host. To
prevent this, Hosts SHOULD set the "secure" attribute and omit the
"domain" attribute on all security-sensitive cookies, such as session
cookies. These settings tell the browser that the cookie should only
be presented back to the originating host (not its subdomains), and
should only be sent over HTTPS (not HTTP).
5. Privacy Considerations 5. Privacy Considerations
Conforming implementations (as well as implementations conforming to Conforming implementations (as well as implementations conforming to
[RFC6797]) must store state about which domains have set policies, [RFC6797]) must store state about which domains have set policies,
hence which domains the UA has contacted. A forensic attacker might hence which domains the UA has contacted. A forensic attacker might
find this information useful, even if the user has cleared other find this information useful, even if the user has cleared other
parts of the UA's state. parts of the UA's state.
More importantly, Hosts can use HSTS or HPKP as a "super-cookie", by More importantly, Hosts can use HSTS or HPKP as a "super-cookie", by
setting distinct policies for a number of subdomains. For example, setting distinct policies for a number of subdomains. For example,
skipping to change at page 21, line 46 skipping to change at page 21, line 19
that it was impossible to verify the confirmed cryptographic identity that it was impossible to verify the confirmed cryptographic identity
of the host. of the host.
UAs MUST have a way for users to clear current Pins for Pinned Hosts. UAs MUST have a way for users to clear current Pins for Pinned Hosts.
UAs SHOULD have a way for users to query the current state of Pinned UAs SHOULD have a way for users to query the current state of Pinned
Hosts. Hosts.
8. Acknowledgements 8. Acknowledgements
Thanks to Tobias Gondrom, Jeff Hodges, Paul Hoffman, Ivan Krstic, Thanks to Tobias Gondrom, Jeff Hodges, Paul Hoffman, Ivan Krstic,
Adam Langley, Nicolas Lidzborski, SM, James Manger, Yoav Nir, Eric Adam Langley, Nicolas Lidzborski, SM, James Manger, Yoav Nir, Trevor
Rescorla, and Tom Ritter for suggestions and edits that clarified the Perrin, Eric Rescorla, Tom Ritter, and Yan Zhu for suggestions and
text. Thanks to Trevor Perrin for suggesting a mechanism to edits that clarified the text.
affirmatively break Pins ([pin-break-codes]).
9. What's Changed 9. What's Changed
[RFC EDITOR: PLEASE REMOVE THIS SECTION] [RFC EDITOR: PLEASE REMOVE THIS SECTION]
Removed the strict directive. Removed the strict directive.
Removed the requirement that the server set the Valid Pinning Header Removed the requirement that the server set the Valid Pinning Header
on every response. on every response.
skipping to change at page 23, line 4 skipping to change at page 22, line 18
Explicitly requiring that UAs perform Pin Validation before the HTTP Explicitly requiring that UAs perform Pin Validation before the HTTP
conversation begins. conversation begins.
Backup Pins are now required. Backup Pins are now required.
Separated normative from non-normative material. Removed tangential Separated normative from non-normative material. Removed tangential
and out-of-scope non-normative discussion. and out-of-scope non-normative discussion.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.josefsson-pkix-textual] [I-D.josefsson-pkix-textual]
Josefsson, S. and S. Leonard, "Text Encodings of PKIX and Josefsson, S. and S. Leonard, "Text Encodings of PKIX and
CMS Structures", draft-josefsson-pkix-textual-02 (work in CMS Structures", draft-josefsson-pkix-textual-03 (work in
progress), October 2013. progress), April 2014.
[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.
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the
Internet: Timestamps", RFC 3339, July 2002. Internet: Timestamps", RFC 3339, July 2002.
skipping to change at page 23, line 49 skipping to change at page 23, line 17
May 2008. May 2008.
[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.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008. (CRL) Profile", RFC 5280, May 2008.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011.
[RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict [RFC6797] Hodges, J., Jackson, C., and A. Barth, "HTTP Strict
Transport Security (HSTS)", RFC 6797, November 2012. Transport Security (HSTS)", RFC 6797, November 2012.
[W3C.REC-html401-19991224] [W3C.REC-html401-19991224]
Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01 Raggett, D., Hors, A., and I. Jacobs, "HTML 4.01
Specification", World Wide Web Consortium Recommendation Specification", World Wide Web Consortium Recommendation
REC-html401-19991224, December 1999, REC-html401-19991224, December 1999,
<http://www.w3.org/TR/1999/REC-html401-19991224>. <http://www.w3.org/TR/1999/REC-html401-19991224>.
10.2. Informative References 10.2. Informative References
[I-D.perrin-tls-tack] [I-D.perrin-tls-tack]
Marlinspike, M., "Trust Assertions for Certificate Keys", Marlinspike, M., "Trust Assertions for Certificate Keys",
draft-perrin-tls-tack-02 (work in progress), January 2013. draft-perrin-tls-tack-02 (work in progress), January 2013.
[pin-break-codes]
Perrin, T., "Self-Asserted Key Pinning", September 2011,
<http://trevp.net/SAKP/>.
[why-pin-key] [why-pin-key]
Langley, A., "Public Key Pinning", May 2011, Langley, A., "Public Key Pinning", May 2011,
<http://www.imperialviolet.org/2011/05/04/pinning.html>. <http://www.imperialviolet.org/2011/05/04/pinning.html>.
Appendix A. Fingerprint Generation Appendix A. Fingerprint Generation
This POSIX shell program generates SPKI Fingerprints, suitable for This POSIX shell program generates SPKI Fingerprints, suitable for
use in pinning, from PEM-encoded certificates. It is non-normative. use in pinning, from PEM-encoded certificates. It is non-normative.
openssl x509 -noout -in certificate.pem -pubkey | \ openssl x509 -noout -in certificate.pem -pubkey | \
 End of changes. 22 change blocks. 
70 lines changed or deleted 60 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/