On Mar 5, 2013, at 12:26 PM, Daniel Kahn Gillmor <[email protected]>
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)
_______________________________________________
websec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/websec
