draft-ietf-websec-key-pinning-02.txt   draft-ietf-websec-key-pinning-03.txt 
Web Security C. Evans Web Security C. Evans
Internet-Draft C. Palmer Internet-Draft C. Palmer
Intended status: Standards Track Google, Inc. Intended status: Standards Track Google, Inc.
Expires: December 6, 2012 June 4, 2012 Expires: April 19, 2013 October 16, 2012
Public Key Pinning Extension for HTTP Public Key Pinning Extension for HTTP
draft-ietf-websec-key-pinning-02 draft-ietf-websec-key-pinning-03
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 or more of the pinned fingerprints for that fingerprint matches one or more of the pinned fingerprints for that
host. By effectively reducing the scope of authorities who can host. By effectively reducing the scope of authorities who can
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 6, 2012. This Internet-Draft will expire on April 19, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 25 skipping to change at page 5, line 25
AlgorithmIdentifier ::= SEQUENCE { AlgorithmIdentifier ::= SEQUENCE {
algorithm OBJECT IDENTIFIER, algorithm OBJECT IDENTIFIER,
parameters ANY DEFINED BY algorithm OPTIONAL } parameters ANY DEFINED BY algorithm OPTIONAL }
Figure 3 Figure 3
The SPKI hash is then encoded in base-64 for use in an HTTP header. The SPKI hash is then encoded in base-64 for use in an HTTP header.
(See [rfc-4648].) (See [rfc-4648].)
If the SubjectPublicKeyInfo of a certificate is incomplete when taken
in isolation, such as when holding a DSA key without domain
parameters, a public key pin cannot be formed.
We pin public keys, rather than entire certificates, to enable We pin public keys, rather than entire certificates, to enable
operators to generate new certificates containing old public keys operators to generate new certificates containing old public keys
(see [why-pin-key]). (see [why-pin-key]).
See Appendix A for an example non-normative program that generates See Appendix A for an example non-normative program that generates
public key fingerprints from SubjectPublicKeyInfo fields in public key fingerprints from SubjectPublicKeyInfo fields in
certificates. certificates.
2.3. Noting Pins 2.3. Noting Pins
skipping to change at page 6, line 42 skipping to change at page 6, line 47
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 [hsts-draft].) by [hsts-draft].)
If the connection has no errors, the UA will then apply a new, If the connection has no errors, the UA will then apply a new,
additional correctness check: Pin Validation. To perform Pin additional correctness check: Pin Validation. To perform Pin
Validation, the UA will compute the fingerprints of the SPKI Validation, the UA will compute the fingerprints of the SPKI
structures in each certificate in the host's validated certificate structures in each certificate in the host's validated certificate
chain. (For the purposes of Pin Validation, the UA MUST ignore chain. (For the purposes of Pin Validation, the UA MUST ignore
superfluous certificates in the chain that do not form part of the certificates who SPKI cannot be taken in isolation and superfluous
validating chain.) The UA will then check that the set of these certificates in the chain that do not form part of the validating
fingerprints intersects the set of fingerprints in that host's chain.) The UA will then check that the set of these fingerprints
Pinning Metadata. If there is set intersection, the UA continues intersects the set of fingerprints in that host's Pinning Metadata.
with the connection as normal. Otherwise, the UA MUST treat this Pin If there is set intersection, the UA continues with the connection as
Failure as a non-recoverable error. normal. Otherwise, the UA MUST treat this Pin Failure as a non-
recoverable error.
Note that, although the UA has previously received public key pins at Note that, although the UA has previously received public key pins at
the HTTP layer, it can and MUST perform Pin Validation at the TLS the HTTP layer, it can and MUST perform Pin Validation at the TLS
layer, before beginning an HTTP conversation over the TLS channel. layer, before beginning an HTTP conversation over the TLS channel.
The TLS layer thus evaluates TLS connections with pinning information The TLS layer thus evaluates TLS connections with pinning information
the UA received previously, regardless of mechanism: statically the UA received previously, regardless of mechanism: statically
preloaded, via HTTP header, or some other means (possibly in the TLS preloaded, via HTTP header, or some other means (possibly in the TLS
layer itself, such as specified in [tack-draft]). layer itself, such as specified in [tack-draft]).
2.5. Pin Validity Times 2.5. Pin Validity Times
 End of changes. 5 change blocks. 
9 lines changed or deleted 14 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/