I would suggest that there are 3 things for Mozilla to impress upon the participants in the trusted store program: 1) Compliance with relevant specs and policies. This is important not only to ensure proper, secure interoperability but also to create a level playing field. As Tim Moses points out the CA's that are "less diligent" do not deserve the same treatment as those who are. As a collective I think we do a decent job on this. 2) Establish and maintain trust. This means going beyond strict compliance and behaving in ways that demonstrate a commitment to security and privacy and respect for individual liberties. (Yes, I ask for a lot.). Obviously this one is very difficult in light of NSA, GCHQ, etc. bully tactics but it's important nonetheless. I imagine this is an area we'll be spending more time on. 3) Financial impact to "the Internet". I don't know if anyone talks about this or has performed any studies? Basically, this mistake by ANSSI just cost untold millions of dollars of Mozilla, the other browser vendors, cert users, and the individual users and IT departments who must upgrade their browsers (to say nothing of all non-browser applications that are affected, too). I think Mozilla rightfully has a responsibility to itself and the broader Internet to protect and limit the financial costs of mistakes like this, and can place tighter controls on participating CA's accordingly. Plus, I would argue that "upgrade your browser because someone made a mistake" hardly counts as a "best practice".
Am 2013-12-10 09:52, schrieb Erwann Abalea: > I think ANSSI knows the duties associated to running a public CA, I'm > pretty sure the different ministries don't. I agree with the assumption that the ministries don't know the duties associated with running a public CA. Thus, ANSSI should never have issued them Sub-CA certs, since they are unable to run one correctly. What else does a CA need to do in order to be removed? This CA: 1. Has stated that it does not intend to comply with current policies for another two years, making it a total of three years for compliance. This is by far the longest of all CAs in the program. 2. Is not just having trouble with some minor details of the policy, but is violating several important requirements (e.g. 1024 bit certs, randomness for SHA-1 as per Erwann's mail) including ones critical to prevent issues like the one that happened now (audit/disclosure of Sub-CAs). 3. Has had a Sub-CA misissue for MitM purposes. This had to be detected and reported by a third party, not the CA itself. 4. Is organizationally unable to implement requirements in a timely manner. This is not an excuse, it is a reason not to be a CA. If they cannot operate a CA properly, then they cannot operate a CA. 5. Appears unable to operate a CA properly as per Erwann's mail (e.g. no valid CRLs). I'd say that once a second person has verified the issues reported by Erwann, we should remove the trust bits. Kind regards, Jan -- Please avoid sending mails, use the group instead. If you really need to send me an e-mail, mention "FROM NG" in the subject line, otherwise my spam filter will delete your mail. Sorry for the inconvenience, thank the spammers... _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy | ||
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
