draft-ietf-websec-key-pinning-11.txt   draft-ietf-websec-key-pinning-12.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: August 12, 2014 Google, Inc. Expires: October 31, 2014 Google, Inc.
February 8, 2014 April 29, 2014
Public Key Pinning Extension for HTTP Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-11 draft-ietf-websec-key-pinning-12
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 August 12, 2014. This Internet-Draft will expire on October 31, 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 19 skipping to change at page 2, line 19
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . 6
2.1.4. Examples . . . . . . . . . . . . . . . . . . . . . . 6 2.1.4. 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 . . . . . . . . . . . . . . . . . . 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. Interaction of Public-Key-Pins and Public-Key-Pins-
2.3.3. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 10 Report-Only . . . . . . . . . . . . . . . . . . . . . 9
2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 10 2.3.3. Noting a Pinned Host - Storage Model . . . . . . . . 10
2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 11 2.3.4. HTTP-Equiv <Meta> Element Attribute . . . . . . . . . 11
2.4. Semantics of Pins . . . . . . . . . . . . . . . . . . . . 11
2.5. Noting Pins . . . . . . . . . . . . . . . . . . . . . . . 12
2.6. Validating Pinned Connections . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . 14
3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 13 3. Reporting Pin Validation Failure . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17
4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 17 4.1. Maximum max-age . . . . . . . . . . . . . . . . . . . . . 18
4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 17 4.2. Using includeSubDomains Safely . . . . . . . . . . . . . 18
4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 18 4.3. Backup Pins . . . . . . . . . . . . . . . . . . . . . . . 19
5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 19 5. Privacy Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Usability Considerations . . . . . . . . . . . . . . . . . . 20 7. Usability Considerations . . . . . . . . . . . . . . . . . . 21
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 21 9. What's Changed . . . . . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
10.1. Normative References . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 23 10.2. Informative References . . . . . . . . . . . . . . . . . 24
Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 23 Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 24
Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 23 Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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 5, line 11 skipping to change at page 5, line 11
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 "sha256". (In the future, additional hash algorithm, and MUST be "sha256". (In the future, additional hash
algorithms MAY be registered and used.) The quoted-string is a algorithms MAY be registered and used.) The quoted-string is a
sequence of base 64 digits: the base 64-encoded SPKI Fingerprint sequence of base 64 digits: the base 64-encoded SPKI Fingerprint
([RFC4648]). See Section 2.4. ([RFC4648]). See Section 2.4.
The UA MUST ignore pin-directives with tokens naming hash algorithms
it does not recognize. If the set of remaining effective pin-
directives is empty, and if the connection passed Pin Validation with
the UA's existing noted pins for the Host (i.e. the Host is a Known
Pinned Host), the UA MUST cease to consider the Host as a Known
Pinned Host. (I.e. the UA should fail open.) The UA SHOULD indicate
to users that the Host is no longer a Known Pinned Host.
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-
string unescaping, if necessary) is defined as: string unescaping, if necessary) is defined as:
skipping to change at page 5, line 47 skipping to change at page 6, line 11
which, if present (i.e., it is "asserted"), signals to the UA that which, if present (i.e., it is "asserted"), signals to the UA that
the Pinning Policy applies to this Pinned Host as well as any the Pinning Policy applies to this Pinned Host as well as any
subdomains of the host's domain name. subdomains of the host's domain name.
2.1.3. The report-uri Directive 2.1.3. The report-uri Directive
The OPTIONAL "report-uri" directive indicates the URI to which the UA The OPTIONAL "report-uri" directive indicates the URI to which the UA
SHOULD report Pin Validation failures (Section 2.6). The UA POSTs SHOULD report Pin Validation failures (Section 2.6). The UA POSTs
the reports to the given URI as described in Section 3. the reports to the given URI as described in Section 3.
When used in the Public-Key-Pins-Report-Only header, the UA SHOULD When used in the Public-Key-Pins or Public-Key-Pins-Report-Only
POST reports for Pin Validation failures to the indicated report-uri, header, the presence of a report-uri directive indicates to the UA
although the UA MUST NOT enforce Pin Validation. That is, in the that in the event of Pin Validation failure it SHOULD POST a report
event of Pin Validation failure when the host has set the Public-Key- to the report-uri. If the header is Public-Key-Pins, the UA should
Pins-Report-Only header, the UA performs Pin Validation only to check do this in addition to terminating the connection (as described in
whether or not it should POST a report, but not for causing Section 2.6).
connection failure.
If a Host sets both the Public-Key-Pins header and the Public-Key-
Pins-Report-Only header, the UA MUST NOT enforce Pin Validation, and
MUST note only the Pins and directives given in the Public-Key-Pins-
Report-Only header.
When used in the Public-Key-Pins header, the presence of a report-uri
directive indicates to the UA that the UA MUST enforce Pin
Validation, and the UA SHOULD also, in the event of Pin Validation
failure, POST a report to the report-uri.
Note that the report-uri need not necessarily be in the same Internet
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.
Note that the report-uri need not necessarily be in the same Internet
domain or web origin as the Known Pinned 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,
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 8, line 33 skipping to change at page 8, line 33
the scheme in Section 10 of [RFC6797]. the scheme in Section 10 of [RFC6797].
2.3.1. Public-Key-Pins Response Header Field Processing 2.3.1. Public-Key-Pins Response Header Field Processing
If the UA receives, over a secure transport, an HTTP response that If the UA receives, over a secure transport, an HTTP response that
includes a PKP header field conforming to the grammar specified in includes a PKP header field conforming to the grammar specified in
Section 2.1, and there are no underlying secure transport errors or Section 2.1, and there are no underlying secure transport errors or
warnings (see Section 2.5), the UA MUST either: warnings (see Section 2.5), the UA MUST either:
o Note the host as a Known Pinned Host if it is not already so noted o Note the host as a Known Pinned Host if it is not already so noted
(see Section 2.3.2), (see Section 2.3.3),
or, or,
o Update the UA's cached information for the Known Pinned Host if o Update the UA's cached information for the Known Pinned Host if
any of of the max-age, includeSubDomains, or report-uri header any of of the max-age, includeSubDomains, or report-uri header
field value directives convey information different than that field value directives convey information different than that
already maintained by the UA. already maintained by the UA.
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
skipping to change at page 9, line 18 skipping to change at page 9, line 18
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.
2.3.2. Noting a Pinned Host - Storage Model 2.3.2. Interaction of Public-Key-Pins and Public-Key-Pins-Report-Only
A server MAY set both the Public-Key-Pins and Public-Key-Pins-Report-
Only headers simultaneously. The headers do not interact with one
another but the UA MUST process the Public-Key-Pins header and SHOULD
process both.
The Public-Key-Pins header is processed as according to
Section 2.3.1.
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
indicated report-uri, although the UA MUST NOT enforce Pin
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
Pin Validation only to check whether or not it should POST a report,
but not for causing connection failure.
Note: There is no purpose to using the Public-Key-Pins-Report-Only
header without the report-uri directive. User Agents MAY discard
such headers without interpretting them further.
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
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
SHOULD evaluate the specified policy and SHOULD report any would-be
Pin Validation failures that would occur if the report-only policy
were enforced.
If a Host sets both the Public-Key-Pins header and the Public-Key-
Pins-Report-Only header, the UA MUST note and enforce Pin Validation
as specified by the Public-Key-Pins header, and SHOULD note the Pins
and directives given in the Public-Key-Pins-Report-Only header. If
the UA does note the Pins and directives in the Public-Key-Pins-
Report-Only header it SHOULD evaluate the specified policy and SHOULD
report any would-be Pin Validation failures that would occur if the
report-only policy were enforced.
2.3.3. Noting a Pinned Host - Storage Model
The Effective Pin Date of a Known Pinned Host is the time that the UA The Effective Pin Date of a Known Pinned Host is the time that the UA
observed a Valid Pinning Header for the host. The Effective observed a Valid Pinning Header for the host. The Effective
Expiration Date of a Known Pinned Host is the Effective Pin Date plus Expiration Date of a Known Pinned Host is the Effective Pin Date plus
the max-age. A Known Pinned Host is "expired" if the Effective the max-age. A Known Pinned Host is "expired" if the Effective
Expiration Date refers to a date in the past. The UA MUST ignore all Expiration Date refers to a date in the past. The UA MUST ignore all
expired Known Pinned Hosts from its cache if, at any time, an expired expired Known Pinned Hosts from its cache if, at any time, an expired
Known Pinned Host exists in the cache. Known Pinned Host exists in the cache.
If the substring matching the host production from the Request-URI If the substring matching the host production from the Request-URI
skipping to change at page 10, line 14 skipping to change at page 11, line 5
age directive of 90 days in its Valid Pinning Header, the UA MAY age directive of 90 days in its Valid Pinning Header, the UA MAY
behave as if the max-age were effectively 60 days. (One way to behave as if the max-age were effectively 60 days. (One way to
achieve this behavior is for the UA to simply store a value of 60 achieve this behavior is for the UA to simply store a value of 60
days instead of the 90 day value provided by the Pinned Host.) For days instead of the 90 day value provided by the Pinned Host.) For
UA implementation guidance on how to select a maximum max-age, see UA implementation guidance on how to select a maximum max-age, see
Section 4.1. Section 4.1.
The UA MUST NOT modify any pinning metadata of any superdomain The UA MUST NOT modify any pinning metadata of any superdomain
matched Known Pinned Host. matched Known Pinned Host.
2.3.3. HTTP-Equiv <Meta> Element Attribute 2.3.4. HTTP-Equiv <Meta> Element Attribute
UAs MUST NOT heed http-equiv="Public-Key-Pins" or http-equiv="Public- UAs MUST NOT heed http-equiv="Public-Key-Pins" or http-equiv="Public-
Key-Pins-Report-Only" attribute settings on <meta> elements Key-Pins-Report-Only" attribute settings on <meta> elements
[W3C.REC-html401-19991224] in received content. [W3C.REC-html401-19991224] in received content.
2.4. Semantics of Pins 2.4. Semantics of Pins
An SPKI Fingerprint is defined as the output of a known cryptographic An SPKI Fingerprint is defined as the output of a known cryptographic
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
skipping to change at page 13, line 9 skipping to change at page 13, line 45
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 UAs that support additional sources of pinning information MUST use
the most recently observed pinning information when performing Pin the most recently observed pinning information when performing Pin
Validation for a host. The most recently observed pinning Validation for a host. The most recently observed pinning
information is determined based upon the most recent Effective Pin information is determined based upon the most recent Effective Pin
Date, as described in Section 2.3.2. 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 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 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 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 pinning data. That is, a host must be able to un-pin itself, even in
the presence of built-in Pins. the presence of built-in Pins.
Example: A UA may ship with a pre-configured list of Pins that are Example: A UA may ship with a pre-configured list of Pins that are
collected from past observations of Valid Pinning Headers supplied by collected from past observations of Valid Pinning Headers supplied by
hosts. In such a solution, the pre-configured list should track when hosts. In such a solution, the pre-configured list should track when
skipping to change at page 15, line 10 skipping to change at page 16, line 10
the Known Pinned Host during TLS session setup. It is provided as an the Known Pinned Host during TLS session setup. It is provided as an
array of strings; each string pem1, ... pemN is the PEM array of strings; each string pem1, ... pemN is the PEM
representation of each X.509 certificate as described in representation of each X.509 certificate as described in
[I-D.josefsson-pkix-textual]. [I-D.josefsson-pkix-textual].
The validated-certificate-chain is the certificate chain, as The validated-certificate-chain is the certificate chain, as
constructed by the UA during certificate chain verification. (This constructed by the UA during certificate chain verification. (This
may differ from the served-certificate-chain.) It is provided as an may differ from the served-certificate-chain.) It is provided as an
array of strings; each string pem1, ... pemN is the PEM array of strings; each string pem1, ... pemN is the PEM
representation of each X.509 certificate as described in representation of each X.509 certificate as described in
[I-D.josefsson-pkix-textual]. [I-D.josefsson-pkix-textual]. For UAs that build certificate chains
in more than one way during the validation process, they SHOULD send
the last chain built. In this way they can avoid keeping too much
state during the validation process.
The known-pins are the Pins that the UA has noted for the Known The known-pins are the Pins that the UA has noted for the Known
Pinned Host. They are provided as an array of strings with the Pinned Host. They are provided as an array of strings with the
syntax: syntax:
known-pin = token "=" quoted-string known-pin = token "=" quoted-string
Figure 6: Known Pin Syntax Figure 6: Known Pin Syntax
As in Section 2.4, the token refers to the algorithm name, and the As in Section 2.4, the token refers to the algorithm name, and the
skipping to change at page 17, line 20 skipping to change at page 18, line 20
Operators can pin any one or more of the public keys in this chain, Operators can pin any one or more of the public keys in this chain,
and indeed could pin to issuers not in the chain (as, for example, a and indeed could pin to issuers not in the chain (as, for example, a
Backup Pin). Pinning to an intermediate issuer, or even to a trust Backup Pin). Pinning to an intermediate issuer, or even to a trust
anchor or root, still significantly reduces the number of issuers who anchor or root, still significantly reduces the number of issuers who
can issue end entity certificates for the Known Pinned Host, while can issue end entity certificates for the Known Pinned Host, while
still giving that host flexibility to change keys without a still giving that host flexibility to change keys without a
disruption of service. disruption of service.
4.1. Maximum max-age 4.1. Maximum max-age
As mentioned in Section 2.3.2, UAs MAY cap the max-age value at some As mentioned in Section 2.3.3, UAs MAY cap the max-age value at some
upper limit. There is a security trade-off in that low maximum upper limit. There is a security trade-off in that low maximum
values provide a narrow window of protection for users who visit the values provide a narrow window of protection for users who visit the
Known Pinned Host only infrequently, while high maximum values might Known Pinned Host only infrequently, while high maximum values might
potentially result in a UA's inability to successfully perform Pin potentially result in a UA's inability to successfully perform Pin
Validation for a Known Pinned Host if the UA's noted Pins and the Validation for a Known Pinned Host if the UA's noted Pins and the
Host's true Pins diverge. Host's true Pins diverge.
Such divergence could occur for several reasons, including: UA error; Such divergence could occur for several reasons, including: UA error;
Host operator error; network attack; or a Known Pinned Host that Host operator error; network attack; or a Known Pinned Host that
intentionally migrates all pinned keys, combined with a UA that has intentionally migrates all pinned keys, combined with a UA that has
 End of changes. 16 change blocks. 
53 lines changed or deleted 101 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/