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 -- Peter Saint-Andre https://stpeter.im/ _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
