draft-ietf-websec-key-pinning-18.txt   draft-ietf-websec-key-pinning-19.txt 
Web Security C. Evans Web Security C. Evans
Internet-Draft C. Palmer Internet-Draft C. Palmer
Intended status: Standards Track R. Sleevi Intended status: Standards Track R. Sleevi
Expires: January 4, 2015 Google, Inc. Expires: January 5, 2015 Google, Inc.
July 3, 2014 July 4, 2014
Public Key Pinning Extension for HTTP Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-18 draft-ietf-websec-key-pinning-19
Abstract Abstract
This document describes an extension to the HTTP protocol allowing This document describes an extension to the HTTP protocol allowing
web host operators to instruct user agents to remember ("pin") the web host operators to instruct user agents to remember ("pin") the
hosts' cryptographic identities for a given period of time. During hosts' cryptographic identities for a given period of time. During
that time, UAs will require that the host present a certificate chain that time, UAs will require that the host present a certificate chain
including at least one Subject Public Key Info structure whose including at least one Subject Public Key Info structure whose
fingerprint matches one of the pinned fingerprints for that host. By fingerprint matches one of the pinned fingerprints for that host. By
effectively reducing the number of authorities who can authenticate effectively reducing the number of authorities who can authenticate
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2015. This Internet-Draft will expire on January 5, 2015.
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 5, line 15 skipping to change at page 5, line 15
string is a sequence of base 64 digits: the base 64-encoded SPKI string is a sequence of base 64 digits: the base 64-encoded SPKI
Fingerprint [RFC4648] (see Section 2.4). Fingerprint [RFC4648] (see Section 2.4).
When a connection passes Pin Validation using the UA's noted Pins for When a connection passes Pin Validation using the UA's noted Pins for
the host at the time, the host becomes a Known Pinned Host. the host at the time, the host becomes a Known Pinned Host.
According to rule 5, above, the UA MUST ignore pin-directives with According to rule 5, above, the UA MUST ignore pin-directives with
tokens naming hahs algorithms it does not recognize. If the set of tokens naming hahs algorithms it does not recognize. If the set of
remaining effective pin-directives is empty, and if the host is a remaining effective pin-directives is empty, and if the host is a
Known Pinned Host, the UA MUST cease to consider the host as a Known Known Pinned Host, the UA MUST cease to consider the host as a Known
Pinned Host (the UA should fail open). The UA SHOULD indicate to Pinned Host (the UA should fail open). The UA should indicate to
users that the host is no longer a Known Pinned Host. 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 "max-age" directive specifies the number of seconds after the The "max-age" directive specifies the number of seconds after the
reception of the PKP header field during which the UA SHOULD regard reception of the PKP header field during which the UA SHOULD regard
the host (from whom the message was received) as a Known Pinned Host. the host (from whom the message was received) as a Known Pinned Host.
The "max-age" directive is REQUIRED to be present within a "Public- The "max-age" directive is REQUIRED to be present within a "Public-
Key-Pins" header field, and is OPTIONAL within a "Public-Key-Pins- Key-Pins" header field, and is OPTIONAL within a "Public-Key-Pins-
skipping to change at page 6, line 11 skipping to change at page 6, line 11
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 PKP or PKP-RO headers, the presence of a report-uri When used in the PKP or PKP-RO headers, the presence of a report-uri
directive indicates to the UA that in the event of Pin Validation directive indicates to the UA that in the event of Pin Validation
failure it SHOULD POST a report to the report-uri. If the header is failure it SHOULD POST a report to the report-uri. If the header is
Public-Key-Pins, the UA should do this in addition to terminating the Public-Key-Pins, the UA should do this in addition to terminating the
connection (as described in Section 2.6). connection (as described in Section 2.6).
Hosts may set report-uris that use HTTP, HTTPS, or other schemes. If Hosts may set report-uris that use HTTP or HTTPS. If the scheme in
the scheme in the report-uri is one that uses TLS (e.g. HTTPS or the report-uri is one that uses TLS (e.g. HTTPS), UAs MUST perform
WSS), UAs MUST perform Pinning Validation when the host in the Pinning Validation when the host in the report-uri is a Known Pinned
report-uri is a Known Pinned Host; similarly, UAs MUST apply HSTS if Host; similarly, UAs MUST apply HSTS if the host in the report-uri is
the host in the report-uri is a Known HSTS Host. a Known HSTS Host.
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 host being reported about. domain or web origin as the host being reported about.
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. Similarly, if Known Pinned Host A sets a MUST cancel the connection. Similarly, if Known Pinned Host A sets a
report-uri referring to Known Pinned Host B, and if B sets a report- report-uri referring to Known Pinned Host B, and if B sets a report-
skipping to change at page 14, line 22 skipping to change at page 14, line 22
UAs send validation failure reports only when Pin Validation is UAs send validation failure reports only when Pin Validation is
actually in effect. Pin Validation might not be in effect e.g. actually in effect. Pin Validation might not be in effect e.g.
because the user has elected to disable it, or because a presented because the user has elected to disable it, or because a presented
certificate chain chains up to a locally-installed anchor. In such certificate chain chains up to a locally-installed anchor. In such
cases, UAs SHOULD NOT send reports. cases, UAs SHOULD NOT send reports.
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.
The effective policy for a Known Pinned Host that has both built-in The effective policy for a Known Pinned Host that has both built-in
Pins and Pins from previously observed PKP header response fields is Pins and Pins from previously observed PKP header response fields is
implementation-defined. implementation-defined.
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
skipping to change at page 23, line 30 skipping to change at page 23, line 30
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-04 (work in CMS Structures", draft-josefsson-pkix-textual-05 (work in
progress), July 2014. progress), July 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.
[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
 End of changes. 7 change blocks. 
12 lines changed or deleted 12 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/