draft-ietf-websec-key-pinning-06.txt   draft-ietf-websec-key-pinning-07.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: December 21, 2013 Google, Inc. Expires: January 10, 2014 Google, Inc.
June 19, 2013 July 09, 2013
Public Key Pinning Extension for HTTP Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-06 draft-ietf-websec-key-pinning-07
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 December 21, 2013. This Internet-Draft will expire on January 10, 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Server and Client Behavior . . . . . . . . . . . . . . . . . 3 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 3
2.1. Response Header Field Syntax . . . . . . . . . . . . . . 3 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 3
2.1.1. The max-age Directive . . . . . . . . . . . . . . . . 5 2.1.1. The max-age Directive . . . . . . . . . . . . . . . . 5
2.1.2. The includeSubDomains Directive . . . . . . . . . . . 5 2.1.2. The includeSubDomains Directive . . . . . . . . . . . 5
2.1.3. The report-uri Directive . . . . . . . . . . . . . . 5 2.1.3. The report-uri Directive . . . . . . . . . . . . . . 5
2.1.4. The strict Directive . . . . . . . . . . . . . . . . 6 2.1.4. The strict Directive . . . . . . . . . . . . . . . . 6
2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 6 2.1.5. Examples . . . . . . . . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . 9 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 . . . . . . . . . . . . . . . . . . . . . . . 10 2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 11
2.6. Validating Pinned Connections . . . . . . . . . . . . . . 11 2.6. Validating Pinned Connections . . . . . . . . . . . . . . 12
2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 12 2.7. Interactions With Preloaded Pin Lists . . . . . . . . . . 13
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 . . . . . . . . . . . . . . . . . . . 14 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 15
4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 15 4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 16
4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 17 4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 17
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17
6. Usability Considerations . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 7. Usability Considerations . . . . . . . . . . . . . . . . . . 19
8. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 21
Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 19 Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
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
scale problem. scale problem.
Deploying public key pinning safely will require operational and Deploying public key pinning safely will require operational and
skipping to change at page 3, line 37 skipping to change at page 3, line 40
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Server and Client Behavior 2. Server and Client Behavior
2.1. Response Header Field Syntax 2.1. Response Header Field Syntax
The Public-Key-Pins HTTP response header field (PKP header field) The Public-Key-Pins HTTP response header field (PKP header field)
indicates to a UA that it SHOULD perform Pin Validation (Section 2.6) indicates to a UA that it should perform Pin Validation (Section 2.6)
in regards to the host emitting the response message containing this in regards to the host emitting the response message containing this
header field, and provides the necessary information for the UA to do header field, and provides the necessary information for the UA to do
so. so.
Figure 1 describes the ABNF (Augmented Backus-Naur Form) syntax of Figure 1 describes the ABNF (Augmented Backus-Naur Form) syntax of
the header field. It is based on the Generic Grammar defined in the header field. It is based on the Generic Grammar defined in
Section 2 of [RFC2616] (which includes a notion of "implied linear Section 2 of [RFC2616] (which includes a notion of "implied linear
whitespace", also known as "implied *LWS"). whitespace", also known as "implied *LWS").
Public-Key-Pins = Public-Key-Pins =
skipping to change at page 4, line 51 skipping to change at page 5, line 4
Additional directives extending the semantic functionality of the PKP Additional directives extending the semantic functionality of the PKP
header field can be defined in other specifications, with a registry header field can be defined in other specifications, with a registry
(having an IANA policy definition of IETF Review [RFC2616]) defined (having an IANA policy definition of IETF Review [RFC2616]) defined
for them at such time. Such future directives will be ignored by UAs for them at such time. Such future directives will be ignored by UAs
implementing only this specification, as well as by generally non- implementing only this specification, as well as by generally non-
conforming UAs. conforming UAs.
In the pin-directive, the token is the name of a cryptographic hash In the pin-directive, the token is the name of a cryptographic hash
algorithm, and MUST be either "sha1" or "sha256". The quoted-string algorithm, and MUST be either "sha1" or "sha256". The quoted-string
is a sequence of base 64 digits: the base 64-encoded SPKI is a sequence of base 64 digits: the base 64-encoded SPKI Fingerprint
Fingerprint. See Section 2.4. ([RFC4648]). See Section 2.4.
2.1.1. The max-age Directive 2.1.1. The max-age Directive
The REQUIRED "max-age" directive specifies the number of seconds, The REQUIRED "max-age" directive specifies the number of seconds,
after the reception of the PKP header field, during which the UA after the reception of the PKP header field, during which the UA
SHOULD regard the host (from whom the message was received) as a SHOULD regard the host (from whom the message was received) as a
Known Pinned Host. The delta-seconds production is specified in Known Pinned Host. The delta-seconds production is specified in
[RFC2616]. [RFC2616].
The syntax of the max-age directive's REQUIRED value (after quoted- The syntax of the max-age directive's REQUIRED value (after quoted-
skipping to change at page 6, line 20 skipping to change at page 6, line 25
Note that the report-uri need not necessarily be in the same Internet Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the Known Pinned Host. domain or web origin as the Known Pinned Host.
Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If
the scheme in the report-uri is HTTPS, UAs MUST perform Pinning the scheme in the report-uri is HTTPS, UAs MUST perform Pinning
Validation when the host in the report-uri is a Known Pinned Host; Validation when the host in the report-uri is a Known Pinned Host;
similarly, UAs MUST apply HSTS if the host in the report-uri is a similarly, UAs MUST apply HSTS if the host in the report-uri is a
Known HSTS Host. Known HSTS Host.
UAs SHOULD make their best effort to report Pin Validation failures UAs SHOULD make their best effort to report Pin Validation failures
to the report-uri, but MAY fail to report in exceptional conditions. to the report-uri, but may fail to report in exceptional conditions.
For example, if connecting the report-uri itself incurs a Pinning For example, if connecting the report-uri itself incurs a Pinning
Validation failure or other certificate validation failure, the UA Validation failure or other certificate validation failure, the UA
MUST cancel the connection (and MAY attempt to re-send the report MUST cancel the connection (and MAY attempt to re-send the report
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,
skipping to change at page 10, line 20 skipping to change at page 10, line 28
hash algorithm whose input is the DER-encoded ASN.1 representation of hash algorithm whose input is the DER-encoded ASN.1 representation of
the SubjectPublicKeyInfo (SPKI) field of an X.509 certificate. A Pin the SubjectPublicKeyInfo (SPKI) field of an X.509 certificate. A Pin
is defined as the combination of the known algorithm identifier and is defined as the combination of the known algorithm identifier and
the SPKI Fingerprint computed using that algorithm. the SPKI Fingerprint computed using that algorithm.
The SPKI Fingerprint is encoded in base 64 for use in an HTTP header. The SPKI Fingerprint is encoded in base 64 for use in an HTTP header.
(See [RFC4648].) (See [RFC4648].)
In this version of the specification, the known cryptographic hash In this version of the specification, the known cryptographic hash
algorithms are SHA-1, identified as "sha1", and SHA-256, identified algorithms are SHA-1, identified as "sha1", and SHA-256, identified
as "sha256". (Future versions of this specification may add new as "sha256" ([RFC4634]). (Future versions of this specification may
algorithms and deprecate old ones.) UAs MUST ignore Pins for which add new algorithms and deprecate old ones.) UAs MUST ignore Pins for
they do not recognize the algorithm identifier. UAs MUST continue to which they do not recognize the algorithm identifier. UAs MUST
process the rest of a PKP response header field and note Pins for continue to process the rest of a PKP response header field and note
algorithms they do recognize; UAs MUST recognize "sha1" and "sha256". Pins for algorithms they do recognize; UAs MUST recognize "sha1" and
"sha256".
Figure 4 reproduces the definition of the SubjectPublicKeyInfo Figure 4 reproduces the definition of the SubjectPublicKeyInfo
structure in [RFC5280]. structure in [RFC5280].
SubjectPublicKeyInfo ::= SEQUENCE { SubjectPublicKeyInfo ::= SEQUENCE {
algorithm AlgorithmIdentifier, algorithm AlgorithmIdentifier,
subjectPublicKey BIT STRING } subjectPublicKey BIT STRING }
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
skipping to change at page 11, line 43 skipping to change at page 12, line 4
connections that do not meet the first criterion. 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.
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.
However, if the Pinned Host Metadata indicates that the Pinned Host However, if the Pinned Host Metadata indicates that the Pinned Host
is operating in "strict mode" (see Section 2.1.4), then the UA MUST is operating in "strict mode" (see Section 2.1.4), then the UA MUST
perform Pin Validation. perform Pin Validation.
skipping to change at page 13, line 36 skipping to change at page 14, line 4
Date. 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
When a Known Pinned Host has set the report-uri directive, the UA When a Known Pinned Host has set the report-uri directive, the UA
SHOULD report Pin Validation failures to the indicated URI. The UA SHOULD report Pin Validation failures to the indicated URI. The UA
does this by POSTing a JSON message to the URI; the JSON message does this by POSTing a JSON ([RFC4627]) message to the URI; the JSON
takes this form: message takes this form:
{ {
"date-time": date-time, "date-time": date-time,
"hostname": hostname, "hostname": hostname,
"port": port, "port": port,
"certificate-chain": [ "certificate-chain": [
pem1, ... pemN pem1, ... pemN
], ],
"known-pins": [ "known-pins": [
known-pin1, ... known-pinN known-pin1, ... known-pinN
skipping to change at page 17, line 19 skipping to change at page 17, line 29
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.)
5. IANA Considerations 5. Privacy Considerations
This document has no actions for IANA. Conforming implementations (as well as implementations conforming to
[RFC6797]) must store state about which domains have set policies,
hence which domains the UA has contacted. A forensic attacker might
find this information useful, even if the user has cleared other
parts of the UA's state.
6. Usability Considerations More importantly, Hosts can use HSTS or HPKP as a "super-cookie", by
setting distinct policies for a number of subdomains. For example,
assume example.com wishes to track distinct UAs without explicitly
setting a cookie, or if a previously-set cookie is deleted from the
UA's cookie store. Here are two attack scenarios.
1. example.com can use report-uri and the ability to pin arbitrary
identifiers to distinguish UAs.
2.
1. example.com sets a Valid Pinning Header in its response to
requests. The header asserts the includeSubDomains
directive, and specifies a report-uri directive as well.
Pages served by the host also include references to
subresource https://bad.example.com/foo.png.
2. The Valid Pinning Header includes a "pin" that is not really
the hash of an SPKI, but is instead an arbitrary
distinguishing string sent only in response to a particular
request. For each request, the Host creates a new, distinct
distinguishing string and sets it as if it were a pin.
3. The certificate chain served by bad.example.com does not pass
Pin Validation given the pin set the Host asserted in (1).
The HPKP-conforming UA attempts to report the Pin Validation
failure to the specified report-uri, including the
certificate chain it observed and the SPKI hashes it expected
to see. Among the SPKI hashes is the distinguishing string
in step (2).
3. example.com can use SNI and subdomains to distinguish UAs.
4.
1. example.com sets a Valid Pinning Header in its response to
requests. The header asserts the includeSubDomains
directive.
2. On a subsequent page view, the Host responds with a page
including the subresource https://0.fingerprint.example.com/
foo.png, and the server responds using a certificate chain
that does not pass Pin Validation for the pin-set defined in
the Valid Pinning Header in step (1). The HPKP-conforming UA
will close the connection, never completing the request to
0.fingerprint.example.com. The Host may thus note that this
particular UA had noted the (good) pins for that subdomain.
3. example.com can distinguish 2^N UAs by serving Valid Pinning
Headers from an arbitrary number N distinct subdomains,
giving some UAs Valid Pinning Headers for some, but not all
subdomains (causing subsequent requests for
n.fingerprint.example.com to fail), and giving some UAs no
Valid Pinning Header for other subdomains (causing subsequent
requests for m.fingerprint.example.com to succeed).
6. IANA Considerations
This document has no actions for IANA. However, in the future there
may arise a need for a registry of extension directives (see
Section 2.1).
7. Usability Considerations
When pinning works to detect impostor Pinned Hosts, users will When pinning works to detect impostor Pinned Hosts, users will
experience denial of service. UAs MUST explain the reason why, i.e. experience denial of service. UAs MUST explain the reason why, i.e.
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.
7. 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]).
8. What's Changed 9. What's Changed
Added normative references for SHA, JSON, and base-64.
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.
Removed the section "Pin Validity Times", which was intended to be in Removed the section "Pin Validity Times", which was intended to be in
harmony with [I-D.perrin-tls-tack]. Now using max-age purely as harmony with [I-D.perrin-tls-tack]. Now using max-age purely as
specified in [RFC6797]. specified in [RFC6797].
skipping to change at page 18, line 24 skipping to change at page 20, line 17
Security. Security.
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.
9. References 10. References
9.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-01 (work in CMS Structures", draft-josefsson-pkix-textual-01 (work in
progress), July 2012. progress), July 2012.
[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.
[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, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006.
[RFC4634] Eastlake, D. and T. Hansen, "US Secure Hash Algorithms
(SHA and HMAC-SHA)", RFC 4634, July 2006.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006.
[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.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
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.
[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]
Hors, A., Jacobs, I., and D. Raggett, "HTML 4.01 Hors, A., Raggett, D., 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>.
9.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] [pin-break-codes]
Perrin, T., "Self-Asserted Key Pinning", September 2011, Perrin, T., "Self-Asserted Key Pinning", September 2011,
<http://trevp.net/SAKP/>. <http://trevp.net/SAKP/>.
[why-pin-key] [why-pin-key]
 End of changes. 29 change blocks. 
44 lines changed or deleted 125 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/