draft-ietf-websec-key-pinning-19.txt   draft-ietf-websec-key-pinning-20.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 5, 2015 Google, Inc. Expires: February 8, 2015 Google, Inc.
July 4, 2014 August 7, 2014
Public Key Pinning Extension for HTTP Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-19 draft-ietf-websec-key-pinning-20
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 5, 2015. This Internet-Draft will expire on February 8, 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
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
2. Server and Client Behavior . . . . . . . . . . . . . . . . . 3 2. Server and Client Behavior . . . . . . . . . . . . . . . . . 4
2.1. Response Header Field Syntax . . . . . . . . . . . . . . 3 2.1. Response Header Field Syntax . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . 6
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 . . . . . . . . . . . . . . . . . . . . . . 7
2.2. Server Processing Model . . . . . . . . . . . . . . . . . 7 2.2. Server Processing Model . . . . . . . . . . . . . . . . . 8
2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 7 2.2.1. HTTP-over-Secure-Transport Request Type . . . . . . . 8
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 . . . . . . . . . . . . . . 13 2.6. Validating Pinned Connections . . . . . . . . . . . . . . 13
skipping to change at page 3, line 11 skipping to change at page 3, line 11
Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 25 Appendix A. Fingerprint Generation . . . . . . . . . . . . . . . 25
Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 25 Appendix B. Deployment Guidance . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
This document defines a new HTTP header that enables a web host to This document defines a new HTTP header that enables a web host to
express to user agents (UAs) which Subject Public Key Info (SPKI) express to user agents (UAs) which Subject Public Key Info (SPKI)
structure(s) UAs SHOULD expect to be present in the host's structure(s) UAs SHOULD expect to be present in the host's
certificate chain in future connections using TLS [RFC5246]. We call certificate chain in future connections using TLS [RFC5246]. We call
this "public key pinning" (PKP). At least one UA (Google Chrome) has this "public key pinning" (PKP); in particular, this document
experimented with the idea by shipping with a user-extensible describes HTTP-based public key pinning (HPKP). At least one UA
embedded set of Pins. Although effective, this does not scale. This (Google Chrome) has experimented with the idea by shipping with a
proposal addresses the scale problem. user-extensible embedded set of Pins. Although effective, this does
not scale. This proposal addresses the scale problem.
Deploying PKP safely will require operational and organizational Deploying PKP safely will require operational and organizational
maturity due to the risk that hosts may make themselves unavailable maturity due to the risk that hosts may make themselves unavailable
by pinning to a (set of) SPKI(s) that becomes invalid (see by pinning to a (set of) SPKI(s) that becomes invalid (see
Section 4). With care, host operators can greatly reduce the risk of Section 4). With care, host operators can greatly reduce the risk of
main-in-the-middle (MITM) attacks and other false-authentication main-in-the-middle (MITM) attacks and other false-authentication
problems for their users without incurring undue risk. problems for their users without incurring undue risk.
PKP is meant to be used toegether with HTTP Strict Transport Security PKP is meant to be used together with HTTP Strict Transport Security
(HSTS) [RFC6797], but is possible to pin keys without requiring HSTS. (HSTS) [RFC6797], but it is possible to pin keys without requiring
HSTS.
A Pin is a relationship between a hostname and a cryptographic
identity (in this document, 1 or more of the public keys in a chain
of X.509 certificates). Pin Validation is the process a UA performs
to ensure that a host is in fact authenticated with its previously-
established Pin.
Key pinning is a trust-on-first-use (TOFU) mechanism. The first time
a UA connects to a host, it lacks the information necessary to
perform Pin Validation; UAs can only apply their normal cryptographic
identity validation. (In this document, it is assumed that UAs apply
X.509 certificate chain validation in accord with [RFC5280].)
The UA will not be able to detect and thwart a MITM attacking the
UA's first connection to the host. (However, the requirement that
the MITM provide an X.509 certificate chain that can pass the UA's
validation requirements, without error, mitigates this risk
somewhat.) Worse, such a MITM can inject its own PKP header into the
HTTP stream, and pin the UA to its own keys. To avoid post facto
detection, the attacker would have to be in a position to intercept
all future requests to the host from that UA.
Thus, key pinning as described in this document is not a perfect
defense against MITM attackers capable of passing certificate chain
validation procedures -- nothing short of pre-shared keys can be.
However, it provides significant value by allowing host operators to
limit the number of certification authorities than can vouch for the
host's identity, and allows UAs to detect in-process MITM attacks
after the initial communication.
1.1. Requirements Language 1.1. Requirements Language
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
skipping to change at page 4, line 19 skipping to change at page 4, line 45
simple-directive = directive-name [ "=" directive-value ] simple-directive = directive-name [ "=" directive-value ]
directive-name = token directive-name = token
directive-value = token directive-value = token
/ quoted-string / quoted-string
pin-directive = "pin-" token "=" quoted-string pin-directive = "pin-" token "=" quoted-string
Figure 1: HPKP Header Syntax Figure 1: HPKP Header Syntax
OWS is used as defined in Section 3.2.3 of [RFC7230]. token and Optional white space (OWS) is used as defined in Section 3.2.3 of
quoted-string are used as defined in Section 3.2.6 of [RFC7230]. [RFC7230]. token and quoted-string are used as defined in
Section 3.2.6 of [RFC7230].
The directives defined in this specification are described below. The directives defined in this specification are described below.
The overall requirements for directives are: The overall requirements for directives are:
1. The order of appearance of directives is not significant. 1. The order of appearance of directives is not significant.
2. A given simple-directive MUST NOT appear more than once in a 2. A given simple-directive MUST NOT appear more than once in a
given header field. Directives are either optional or required, given header field. Directives are either optional or required,
as stipulated in their definitions. as stipulated in their definitions.
skipping to change at page 4, line 52 skipping to change at page 5, line 32
requirements (1 through 5), the UA MUST process the directives it requirements (1 through 5), the UA MUST process the directives it
recognizes. recognizes.
Additional directives extending the semantic functionality of the Additional directives extending the semantic functionality of the
header fields can be defined in other specifications. The first such header fields can be defined in other specifications. The first such
specification will need to define a reistry for such directives. specification will need to define a reistry for such directives.
Such future directives will be ignored by UAs implementing only this Such future directives will be ignored by UAs implementing only this
specification, as well as by generally non-conforming UAs. specification, as well as by generally non-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. The only algorithm allowed at this time is "sha256"; algorithm. The only algorithm allowed at this time is "sha256", i.e.
additional algorithms may be defined in the future. The quoted- the hash algorithm SHA256 ([RFC4634]); additional algorithms may be
string is a sequence of base 64 digits: the base 64-encoded SPKI allowed for use in this context in the future. The quoted-string is
Fingerprint [RFC4648] (see Section 2.4). a sequence of base 64 digits: the base 64-encoded SPKI 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 hash 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.
skipping to change at page 14, line 9 skipping to change at page 14, line 19
isolation cannot be pinned.) The UA MUST ignore superfluous isolation cannot be pinned.) The UA MUST ignore superfluous
certificates in the chain that do not form part of the validating certificates in the chain that do not form part of the validating
chain. The UA will then check that the set of these SPKI chain. The UA will then check that the set of these SPKI
Fingerprints intersects the set of SPKI Fingerprints in that Pinned Fingerprints intersects the set of SPKI Fingerprints in that Pinned
Host's Pinning Metadata. If there is set intersection, the UA Host's Pinning Metadata. If there is set intersection, the UA
continues with the connection as normal. Otherwise, the UA MUST continues with the connection as normal. Otherwise, the UA MUST
treat this Pin Validation Failure as a non-recoverable error. Any treat this Pin Validation Failure as a non-recoverable error. Any
procedure that matches the results of this Pin Validation procedure procedure that matches the results of this Pin Validation procedure
is considered equivalent. is considered equivalent.
Note that the UA MUST perform Pin Validation when setting up the TLS A UA that has previous noted a host as a Known Pinned Host MUST
session, before beginning an HTTP conversation over the TLS channel. perform Pin Validation when setting up the TLS session, before
beginning an HTTP conversation over the TLS channel.
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
skipping to change at page 19, line 5 skipping to change at page 19, line 5
4.2. Using includeSubDomains Safely 4.2. Using includeSubDomains Safely
It may happen that Pinned Hosts whose hostnames share a parent domain It may happen that Pinned Hosts whose hostnames share a parent domain
use different Valid Pinning Headers. If a host whose hostname is a use different Valid Pinning Headers. If a host whose hostname is a
parent domain for another host sets the includeSubDomains directive, parent domain for another host sets the includeSubDomains directive,
the two hosts' Pins may conflict with each other. For example, the two hosts' Pins may conflict with each other. For example,
consider two Known Pinned Hosts, example.com and consider two Known Pinned Hosts, example.com and
subdomain.example.com. Assume example.com sets a Valid Pinning subdomain.example.com. Assume example.com sets a Valid Pinning
Header such as this: Header such as this:
Public-Key-Pins: max-age=12000; pin-sha256="ABC..."; pin-sha256="DEF..."; Public-Key-Pins: max-age=12000; pin-sha256="ABC...";
includeSubDomains pin-sha256="DEF..."; includeSubDomains
Figure 8: example.com Valid Pinning Header Figure 8: example.com Valid Pinning Header
Assume subdomain.example.com sets a Valid Pinning Header such as Assume subdomain.example.com sets a Valid Pinning Header such as
this: this:
Public-Key-Pins: pin-sha256="GHI..."; pin-sha256="JKL..." Public-Key-Pins: pin-sha256="GHI..."; pin-sha256="JKL..."
Figure 9: subdomain.example.com Valid Pinning Header Figure 9: subdomain.example.com Valid Pinning Header
skipping to change at page 21, line 11 skipping to change at page 21, line 11
chain it observed and the SPKI hashes it expected to see. chain it observed and the SPKI hashes it expected to see.
Among the SPKI hashes is the distinguishing string in step Among the SPKI hashes is the distinguishing string in step
(2). (2).
4. Different site operators/origins can optionally collaborate by 4. Different site operators/origins can optionally collaborate by
setting the report-uri to be in an origin they share setting the report-uri to be in an origin they share
administrative control of. UAs MAY, therefore, refuse to send administrative control of. UAs MAY, therefore, refuse to send
reports outside of the origin that set the PKP or PKP-RO reports outside of the origin that set the PKP or PKP-RO
header. header.
o example.com can use SNI and subdomains to distinguish UAs. o example.com can use server name indication (SNI; [RFC3546]) and
subdomains to distinguish UAs.
1. example.com sets a Valid Pinning Header in its response to 1. example.com sets a Valid Pinning Header in its response to
requests. The header asserts the includeSubDomains directive. requests. The header asserts the includeSubDomains directive.
2. On a subsequent page view, the host responds with a page 2. On a subsequent page view, the host responds with a page
including the subresource https://0.fingerprint.example.com/ including the subresource https://0.fingerprint.example.com/
foo.png, and the server responds using a certificate chain foo.png, and the server responds using a certificate chain
that does not pass Pin Validation for the pin-set defined in that does not pass Pin Validation for the pin-set defined in
the Valid Pinning Header in step (1). The HPKP-conforming UA the Valid Pinning Header in step (1). The HPKP-conforming UA
will close the connection, never completing the request to will close the connection, never completing the request to
skipping to change at page 21, line 41 skipping to change at page 21, line 42
requests for m.fingerprint.example.com to succeed). requests for m.fingerprint.example.com to succeed).
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.
6. IANA Considerations 6. IANA Considerations
IANA is requested to register the header described in this document IANA is requested to register the response headers described in this
in the "Message Headers" registry, with the following parameters: document in the "Message Headers" registry ([permanent-headers] with
the following parameters:
o Header Field Names should be "Public-Key-Pins" and "Public-Key- o Header Field Names should be "Public-Key-Pins" and "Public-Key-
Pins-Report-Only". Pins-Report-Only".
o Protocol should be "http" o Protocol should be "http"
o Status should be "standard" o Status should be "standard"
o Reference should be this document o Reference should be this document
7. Usability Considerations 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. It is advisable for UAs to explain the experience denial of service. It is advisable for UAs to explain the
reason why, i.e. that it was impossible to verify the confirmed reason why, i.e. that it was impossible to verify the confirmed
cryptographic identity of the host. cryptographic identity of the host.
It is advisable that UAs have a way for users to clear current Pins It is advisable that UAs have a way for users to clear current Pins
skipping to change at page 23, line 46 skipping to change at page 23, line 50
[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 [RFC4627] Crockford, D., "The application/json Media Type for
JavaScript Object Notation (JSON)", RFC 4627, July 2006. 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 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 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.,
skipping to change at page 24, line 36 skipping to change at page 24, line 42
[RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext [RFC7234] Fielding, R., Nottingham, M., and J. Reschke, "Hypertext
Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June Transfer Protocol (HTTP/1.1): Caching", RFC 7234, June
2014. 2014.
[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>.
[permanent-headers]
Klyne, G., "Permanent Message Header Field Names", July
2014, <http://www.iana.org/assignments/message-headers/
message-headers.xml#perm-headers/>.
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.
[RFC3546] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 3546, June 2003.
[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.
[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
 End of changes. 18 change blocks. 
33 lines changed or deleted 80 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/