Re: [websec] Issue 53 - Key pinning should clarify status of pin validation with private trust anchors

[Yoav Nir <[e-mail]>]

On Mar 5, 2013, at 12:26 PM, Daniel Kahn Gillmor <[e-mail]>
 wrote:

> On 03/04/2013 07:57 PM, Ryan Sleevi wrote:
>> As discussed during Atlanta, the way that pinning is currently implemented
>> within Google Chrome, pinning is only enforced as it relates to so-called
>> "public trust anchors" (eg: those shipped by default as part of a browser
>> or OS installation, not those installed by a user).
> 
> Sorry -- i wasn't in Atlanta, so i don't know the context or background
> for this.  Can you explain more?
> 
> Consider the case where pre-loaded trust anchor ("trusted root
> certificate authority") X certified my web server's EE certificate with
> pubkey Y, and i published a pin on Y and my backup pubkey Z (but no pin
> on X).
> 
> Are you saying that if i switch my server to use Z, and it is certified
> by some non-(pre)loaded trust anchor (or it is self-signed), then Google
> Chrome will not respect the pinning and the connection will fail?

Hi Daniel

Not respecting the pinning means that the connection will not fail.

Suppose the trust anchor store that comes with the OS on which Chrome is installed comes with two CAs: Verisign and StartCom. 

My computer also has another CA called BigCorpCA.

Suppose some website, such as tools.ietf.org has published a pin for Verisign.

Chrome will accept a certificate from Verisign, because it fits the pin
Chrome will accept a certificate from BigCorpCA, because it was added by the user (or by someone who has enough power over the user to install CAs on their computer)
Chrome will not accept a certificate from StartCom, because it goes against the PIN.

I can guess that the reason they do this is so that Chrome doesn't block on certificates from TLS proxies, that are becoming increasingly common.

Yoav (with no hats)