Nelson brings up some key points on conflicts inherent in the Mozilla situation. I think he's right, but also, I don't see how to necessarily solve or deal with these issues easily, unless some treasured assumptions are challenged. Some thoughts follow...
The core of the problem is that Mozilla is working for the CAs, for free.
Microsoft, which also distributes CA root certs inside its browser (and accepts CA-signed certs) charges each CA for the privilege. Thus Microsoft can cover itself for any support issues it has to deal with. It can also choose to set its fees at different rates, depending on how broken each CA is. Even better, Microsoft can bend its own offering to the CA that pays the most money, so if some CA wants broken certs, they can have them. For a fee, why ever not?
Mozilla does not have that advantage. Neither has it the incentive to promote one CA over another, nor all CAs over the OpenSSL self-issuers. It simply hasn't got the easy money choice, so it has to decide what is "good" in certs, some other way.
Hence Nelson's dilemma in deciding how to handle a cert that isn't laid out to standard, but is usable none the less.
About all that Mozilla can do is try to present each cert, in its best light. 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.
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? We can easily craft a set of rules when it comes to CACert, but what happens when Verisign starts being hard to deal with?
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.
What can't be done is to hide all the available information and try and mash it all into one tiny little lock symbol. 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 only way forward is to engage the user in the protocol, as only the user has the interests best in mind. This has been tried, with good results, in Mozilla, even: the paper by Ye and Smith presents their experiments and results with modifying the browser to deal with security attacks.
Ye and Smith, Trusted Path for Browsers,
11th Usenix security symp, 2002.
http://www.cs.dartmouth.edu/~pkilab/demos/countermeasures/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.
iang
Nelson Bolyard wrote:
In the past, the largest single support burden for NSS and PSM developers and QA folks has been the relentless stream of "bugs" filed by OpenSSL users who made certs that don't work, and who just assume that the problem must be a mozilla bug. This has primarily been a problem with certs from CAs not in mozilla's trusted CA list.
There have been rather few problems with certs from trusted CAs, which is just as it should be, and is how it must remain.
It simply MUST NOT become the case that everyone who has a problem with a cert from a trusted CA receives their customer support from mozilla. CAs cannot rely on bugzilla.mozilla.org as their bug tracking system.
So, I think mozilla foundation's trusted CA meta-policy needs to say something to the effect that a trusted CA cannot create a support burden for mozilla and its developers.
Further, I believe the policy needs to state that trusted CAs MUST provide all technical support for (a) their "customers" (the parties who obtain certs from them), and (b) their "relying parties" (people who rely on their certs, e.g. while web surfing).
Finally, I think that the policy should state that a CA whose certs cause too many problems maybe removed from the trusted CA list. We need to spell out what the threshold is, and it needs to be quite low.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
