Following the Turktrust incident last December-January, there was some talk within the CA/Browser Forum about addressing change control/quality assurance by adding “Certificate System Operational Security Requirements” to the already existing “Network and Certificate System Security Requirements”. Here is another iteration of that preliminary work. Even though much of the following is already in place for most of us in this industry, I figured it doesn’t hurt to put it out here for further discussion.
Definitions – Certificate System Code: Computer instructions, including certificate profiles, used by Certificate Systems in the processing and storage of data related to identity verification, registration and enrollment, certificate approval, issuance, validity status, support, and other PKI-related services. Operating Procedures: Operating Procedures are the business processes and procedural safeguards used by the CA to access, manage, maintain, and operate its CA operations. Written Operating Procedures minimize the risk of unauthorized access to or modification of Certificate System Code and system failure. They also enhance incident detection, reporting, and response to mitigate potential damages caused by system failures. Therefore, each CA SHALL: · Segregate operational responsibilities between those employees, contractors, or consultants authorized to work on Certificate System Code and those who are authorized to place Certificate System Code into its production environment; · Document its Certificate System Code (including the operation of any external interfaces), data flows, database designs, and hardware components; · Implement formal procedural controls over all changes to its Certificate System Code, including documented practices for quality assurance and testing of all new or modified Certificate System Code for its operational performance and security vulnerabilities before placing it into the production environment; and · Document its adherence to its change control process and its review and testing of its Certificate System Code in a pre-production environment before placing it into the production environment. Ben From: dev-security-policy [mailto:[email protected]] On Behalf Of [email protected] Sent: Tuesday, December 10, 2013 7:10 AM To: [email protected] Subject: Re: Revoking Trust in one ANSSI Certificate 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". From: Jan Schejbal Sent: Tuesday, December 10, 2013 5:10 AM To: [email protected] Reply To: [email protected] Subject: Re: Revoking Trust in one ANSSI Certificate 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
