Re: [websec] Certificate Pinning via HSTS (.txt version)

Peter Saint-Andre <> Tue, 13 September 2011 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DFF5C21F8BAD for <>; Tue, 13 Sep 2011 11:13:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.571
X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JasvN6WfAwmr for <>; Tue, 13 Sep 2011 11:13:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8594521F8B81 for <>; Tue, 13 Sep 2011 11:13:29 -0700 (PDT)
Received: from (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id B892F41964; Tue, 13 Sep 2011 12:18:49 -0600 (MDT)
Message-ID: <>
Date: Tue, 13 Sep 2011 12:15:34 -0600
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:6.0.2) Gecko/20110902 Thunderbird/6.0.2
MIME-Version: 1.0
To: =JeffH <>
References: <>
In-Reply-To: <>
X-Enigmail-Version: 1.3.1
OpenPGP: url=
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: IETF WebSec WG <>
Subject: Re: [websec] Certificate Pinning via HSTS (.txt version)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 13 Sep 2011 18:13:36 -0000

On 9/12/11 5:53 PM, =JeffH wrote:
>> Chris Evans and I work at Google on the Chrome security team. We have
>> devised this specification for a new extension to Strict Transport
>> Security to allow site operators to "pin" certificates: UAs will
>> require that TLS connections be validated with at least one of the
>> public keys identified in the new "pins" directive in the HSTS header.
>> (Sites can pin to one or more public keys in end entity, subordinate
>> CA, and/or root CA certificates, for flexibility and disaster
>> recovery.)
>> We hope that this mechanism opens up the benefits of certificate
>> pinning to more sites. Currently, Chrome can "pre-load" HSTS behavior
>> and certificate pins for sites, but the mechanism for doing this
>> (email us!) does not scale.
>> We eagerly anticipate your comments, questions, concerns, et c. As you
>> can see from the Ideas section, there are some unanswered questions
>> about the behavior of UAs and hosts, and possible extensions to the
>> policy.
> This is great, thanks for posting this here.
> I have various comments on it I'll try to get to in the next day or so.
> During HSTS's gestation, various parties have discussed potential
> "LockCA" and "LockEV" directives ostensibly having similar semantics to
> what you've proposed here (see talk slides from last few websec sessions
> at IETF meetings). (though I think recent events pretty much obviate
> those nominal ideas because they'd relied on the resilience of one's CA
> and the CA infrastructure (oops))

<hat type='individual'/>

Jeff, why do you say that? It seems to me that if you think various CAs
are dodgy or vulnerable, but you know and like the policies of the CA
you're using, you might well want to lock into that CA.


Peter Saint-Andre