Thats why I propose some trusted third party web site including just the informations about the different CA's, listing also the known rogue ones, and the ones that are newer then the users browser version.
But, unless it is automated, it is hard for the user to do much about it. The user is likely to just click through.
I think this too... You nearly cant protect a user knowing absolutely nothing :(
Presumably, one wants a meta-CA, but that just creates yet another point of trauma. It's already a bit of a challenge to get the user to keep some sort of eye on the false cert attack. How do you propose getting this working for the meta-CA?
Well, I dont think there is a real solution. At the Microsoft side its WebTrust, here its the mozilla foundation deciding whether a root cert is built-in or not and therefore acting like a meta-CA (altough only at the release time, not afterwards).
Another point here will be self-signed certs...
Right. One of the "signs" that a web site is spoofed _could be_ its SSL certificate, altough today almost no users look at the SSL icon.
But if a rogue CA manages to get its root cert into the trusted cert store, this SSL lock wouldn't be trustworthy any more.
Yup. Although the other defences that have been proposed (branding, etc) will still work. What they effectively do is take us back to when info on the SSL connection was important, and drag the user (perhaps kicking and screaming) back into the security protocol. In this case, the browser can give the user some sense of how well the browser knows the cert - never before? many times?
IMHO browsing security doesnt work without the user involved. I really like your suggestion about branding (altough I dont know all the details), the suggestion about a TTP listing trustworthiness of the CAs is just some addition. Branding leads to a situation where newly started CAs have some "market entry barrier" (in german "markteintrittsbarriere", dont know the exact english word). I'd call this model "static" (Bruce Schneier), a TTP web site would be more dynamical and under the control of the mozilla foundation (e.g. if a CA isnt trustworthy any more, how does branding handle this? Revocation or OCSP?)
(The literature I found doesnt really state much about this, mostly its said "do not trust any CA unless you're really sure...";
What literature have you found that seriously addresses the security model? I'm surprised you've found anything addressing the CA, as this is something that is out of the hands of the user.
I wasn't able to find anything serious, and relied on Eric Rescorla's SSL book and a bunch of papers. For the most part, I've collected my information at http://iang.org/ssl/ and http://iang.org/ssl/pki_considered_harmful.html#links
Yes thats what I rely on too. Some other interesting sources are the books and articles from Bruce Schneier, e.g. his "10 risks about PKI" (Http://www.counterpane.com/pki-risks-ft.txt) or cyberworthiness (http://csdl.computer.org/comp/mags/sp/2004/02/j2073abs.htm)
> thats what I'm
trying to enhance with the TTP web site; and thats what Microsoft wants to solve with their "root cert update").
CA-signed certs aren't under attack, secure browsing is. So it seems likely that a root cert attack is more of a theoretical issue or a design issue - which might suit your purposes admirable.
Well I also hope this doesnt change... but I'm pretty sure once the importance of SSL (or email certs, e.g. against spam as someone proposed) increases, there will be attacks against it. (The same for software signing.)
Btw, it would just be a nice thing to do for the next worm: install a new root cert, even if you dont know yet what this could be used for in the future... (well its not a good idea, if the police finds the corresponding private key in your pc... :) ).
Regardless of that, I'd suggest that you would have to address how the CA-signed cert attacks work alongside with your investigations into how the root cert gets attacked. As in, the two should be treated hand in hand, as addressing one risk without covering the other will leave one exposed, academically.
Thanks for the suggestion! You mean CA-signed certs from an already trusted CA, e.g. with a wrong identity? (like the verisign giving out a cert for a wrong Microsoft employee). Or do you mean hacking the CA? Or what could be done once I've managed to get a faked root installed?
/marcel _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
