Ian Grigg wrote:
marcel wrote:
Another point here will be self-signed certs...
Not sure what you meant by this?
Well, the SSC aren't covered by the proposed "meta-CA", but its not a real problem.
I really
like your suggestion about branding (altough I dont know all the details),
I am in the background writing up the proposal more completely, but the essence of it is this, just quickly:
I really like this idea.
1. browsers should 'brand' the certificate and the CA by displaying a branding box on the chrome. This box should include a certain amount of fluff in it, such as images from the CA, as distributed by the product or as signed by the CA.
Nice idea (if that part of the chrome can't be overlapped by an image/popup-window...). I hope these "images from the CA" are tamper-resistant. Who decides about what images are showed, so that a rogue CA can be noticed by the users?
2. Cert usage should be cached and analysed. specifically, when I log into my Bank of America for the hundredth time, I want to see a nice pretty 100 in the branding box. If I get phished to the Funk of Amerika, I want to see a big bad bold 0 up there instead.
Fine. Some further considerations: what is done to protect the counter(-file)?
3. Self-signed certs should be branded as some bland thing in the branding box, and no warnings should popup. Self-signed certs should not be warned against because the represent an improvement over the alternate, which is unprotected HTTP. I.e., we warn when something is wrong, not when something is better.
Good.
4. Webservers should install automatically in HTTPS mode and bootstrap a self-signed certificate. This should be designed to encourage people to do more SSL. If they can do this, and browsers like it (see 3.) then later on, successful sites can upgrade to a CA-signed cert. (this is more an Apache / IIE issue, not a Mozilla issue.)
Those are the 4 key steps.
> 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).
That's correct, branding will make TTP listing of CAs as valid. Until Verisign gets a capability to brand itself to users as being "better" then it is invisible, and thus Verisign cannot be better than any other, no matter how many boxes and checks you put in, as far as the user perception goes.
The creation of branding to the user is essential to get the CAs to compete on quality, and thus raise the bar against CA-substitute attacks.
> 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?)
Branding simply tells the user. If the CA isn't trustworthy any more, it will become a bad brand. The user may be more careful with brands that aren't recognised or thought to be dodgy. At the moment, there is no incentive for the CA to keep clean, as even if found out, the user never sees their name.
There we are at a kind of "meta-CA" again, no? Someone/something has to decide which image is showed inside the branding box... IMHO this can only be done via a TTP.
(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)
I haven't seen the latter article, but it seems that one has to buy it. I don't understand those publishers.
Oh yes, hm, well, I just did a search in google for the file and got a free copy in the internet:)
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?
All of the above :) Have a browse through this: http://iang.org/maps/browser_attack_tree.html (you need applets enabled).
Thanks for the link!
/marcel _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
