On Sep 13, 2011, at 9:15 PM, Peter Saint-Andre wrote: > On 9/12/11 5:53 PM, =JeffH wrote: >> >> 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.
As a customer, I have very little insight into the policies of the CA I'm using. For all I know, the actual signing may be done on a server, accessible from the Internet through SSH with the user "root" and the password "password", and then it's just an OpenSSL script conveniently located along with the private key in root's home directory. Alternatively, it's possible that the private key is stored on the web server and accessible as http://www.exampleca.com/../ca.key Locking yourself into a CA like that seems like a bad idea. Unlike the Dutch government and Mozilla, most customers do not have the pull to force CAs to submit to audits. Six months ago we would not have thought that Comodo or DigiNotar were easy to hack. In the latter case, the customers of DigiNotar were left out in the cold. Without certificate pinning, they just need to spend money on a new certificate and their site is working again. With it, they are in trouble. _______________________________________________ websec mailing list websec@ietf.org https://www.ietf.org/mailman/listinfo/websec
