> Of the above CAs... Good stuff. Thanks, Frank.
> First, at the moment, and for the foreseeable future, I will be acting > under my previously-announced policy of approving only CAs that have > passed a WebTrust for CAs audit or a "WebTrust-equivalent" audit. I have > not given up on crafting a policy that would go beyond that, but it will > have to wait for 2005 until I have time to work on it. This is obviously disappointing to those who are not going the audit route. But given the volunteer nature of the project, and the unfinanced nature of CA addition, I guess they will have to live with their disappointment :) >From a security point of view, and casting an eye to the Mozilla target 'ordinary users' who are being mauled by phishing out there, I think this is 'acceptable' in the short term. Adding more CAs either webtrusted or not makes no odds to phishing, as the existing ones are not defending against phishing, nor can they. The main game is getting the user back in control of the certificate-protected SSL connection. This means adding the CA's brand, petname capabilities, visit counts, and the site's logo preferably signed off by the user (c.f., Amir&Ahmad) , all onto the chrome. (It occurred to me the other day a place to do this all would be where the google box is right now; that is, on switching to SSL, drop the google box and stick in the branding box, a.k.a. the T Only when some semblance of user visibility of the 'who' of the SSL connection is put in place is the browser going to develop some defence against phishing; until then, most other security questions like less or more CAs can take a back seat. IMHO. > Second, CAs often ask when their certificates can get into the various > products: Firefox, Thunderbird, the Mozilla Application Suite, Camino, > etc. The process works as follows: [snip] > There are things we could potentially do to get more timely turnaround > on getting root CA certificates into Mozilla, etc., including building > the NSS certificate library as a standalone operation (i.e., not > requiring a complete NSS rebuild) and implementing an automatic updating > scheme to push out new versions of the library. Another possibility is for you to create a meta-key for Mozilla approval of the CA certificates, and to sign the certs as approval occurs. Then, the build tools could simply scan and filter on MF approval. (As I recall, x.509 lacks an ability to carry more than one sig, so this might be complicated, but there might be a hack around this that I don't know about.) Such a signed approval would also make it a lot easier for an update process to work, and also help defend against the root list attacks that we are just starting to see. Just some thoughts. iang http://www.cs.biu.ac.il/~herzbea/Papers/ecommerce/spoofing.htm http://trustbar.mozdev.org/ _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
