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

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