The core of the problem is that Mozilla is working for the CAs, for free.
In your past posts, you seem to advocate the position that doing things for free is the solution, not the problem.
Microsoft, which also distributes CA root certs inside
its browser (and accepts CA-signed certs) charges each
CA for the privilege.
No, they don't.
[mozilla] simply hasn't got the easy money choice, so it has to decide what is "good" in certs, some other way.
The question is not "what is good in certs", but rather, "who can be trusted to truthfully and correctly issue certs?"
Hence Nelson's dilemma in deciding how to handle a cert that isn't laid out to standard, but is usable none the less.
A cert that isn't laid out to standard isn't useful. All computer communication is done according to protocols, rules of data formatting, interpretation, and valid combinations of transmissions and responses. Certs are no different. If the data doesn't conform to the protocol standard (including certs), the the software (and the user) cannot make use of it.
About all that Mozilla can do is try to present each
cert, in its best light.
That's pretty funny.
If a cert is non standard, then say so - on the browser, and on the website if there is sufficient information, or a test page such as proposed by Jean-Marc.
Jean-Marc proposed a diagnostic tool for CAs (if I understood him correctly) that would tell them what was wrong with their certs in terms that competent CAs would understand. That's not an end user tool.
I fully agree that if a CA gives too much trouble, then
MF should consider dropping it - but I wonder how likely
that is to be a "fair" process?
I suggest the "trouble" be measured in terms of the number of bugs filed and complaints filed in newsgroups like this. More than, say, 1 or 2 a month is way too many. Consider that we've only gotten 2-3 such complaints EVER for certs from your favorite commercial CA.
It all comes back to the little lock symbol. The one binary decision, good or bad, all compressed into that one lonely icon, is what makes it so difficult.
Make what so difficult? After all the SSL crypto computation, and the validation of the cert chain, one of two outcomes arise. Either we've proven to our own satisfaction that the party at the other end of the SSL "pipe" is who the cert says it is and we now have a "secure pipe" to that party, or we haven't and don't.
What can't be done is to hide all the available information and try and mash it all into one tiny little lock symbol.
Can't?
I think all security conscious folks who've participated here wish that browsers would display more info about a) what is the full name (as full as we have in the cert) of the party at the other end of this pipe, and b) who says so? I know that the various managers of browser crypto securty software under which I've worked in the last 7+ years all wanted that, as did most (if not all) the crypto security developers.
The fact that browsers don't do that today is not because security people are holding back, but rather is because UI people do not value security enough to be willing to devote the window real estate to it.
At some point something has to give, and there will be no easy answer. There just isn't any way to compress all those difficult choices into one binary decision, and be confident that you are delivering "trust".
The browser delivers a bit of information, saying it has (or has not) determined that the secured pipe goes to the named party.
The browser has no information upon which to determine if the party at the other end is trustworthy, and does not indicate that, as you know.
The only way forward is to engage the user in the protocol,
only way, huh?
Shall we engage them in the TCP protocol too? When a packet is received with a sequence number out of range, shall we ask the user whether or not to accept it?
That's not the only way. But, it is clear that the only way to deal with the complex security choices facing browsers is something to do with presenting the user with more information.
One thing we learned from Communicator 4.x was that if you give the user a way to override a security error, the user will always choose to do so. Any error or warning that you let the user disable, he will disable. The user views warnings that say "you're not talking to the party who you said you want to talk to" as just another annoying dialog that they have to click through on the way to what they want. IOW, the user is typically not able to aptly judge security risks, even though it is they who are most likely to lose from their choices.
That's one reason why mozilla has fewer security dialogs that the user can override, and more that simply say "no dice". And it hasn't been a great tragedy. More web sites that used to be sloppy have now done the right thing and fixed the problems. That's a GOOD THING.
I'd say the way forward is to enforce the rules no less tightly than before, maybe more so, and give the users fewer decisions to make, fewer chances to hurt themselves. With the presence of low-cost CAs, there won't be any remaining excuse for people to continue to use improperly made certs from their own homebrew CAs.
-- Nelson B
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
