The Mozilla CA Certificates team has been considering what the appropriate next steps are for the inclusion request from the CA "StartCom".[0] As readers will know, this CA has previously been removed from trust[1], and so a re-application obviously involves particular scrutiny. In addition, several questions have been raised about the way in which the new StartCom PKI has been operated technically[2]. This is a proposal for the way forward, on which comments are invited.
Mozilla's considered view is as follows: * It should have been obvious to StartCom that testing of their new systems needed to be done using a parallel testing hierarchy. That it was not obvious, is deeply concerning. It is also concerning that someone can sit at a terminal and issue random certificates with variable values in lots of fields, in what is to become a publicly-trusted hierarchy. It's not about numbers (e.g. "40 out of 50000"), it's about the process. As JC Jones wrote: "This is a professional PKI operation, being overseen by industry veterans. If something as concrete as the issuance process had such a glaring quality assurance methodology failure, why should anyone believe that something much harder -- subscriber validation -- is going to be done correctly?" * The key for their new root certificate was also used in a couple of intermediates (one revoked as it was done incorrectly - again, lack of testing!). While this is probably not a policy violation, it's not good practice. * StartCom's infrastructure audit, performed by Cure53, was frankly a security disaster. (They are using EJBCA for CA operations; this was an audit of their front end and customer management systems, which were rewritten by a team from their new owner, Qihoo 360.) The (PHP) codebase was full of holes, poorly commented, had few or no tests, and showed every evidence of being hacked together in an enormous rush. This does not inspire confidence. Cure53 say they retested a couple of months later and most of the holes they found were fixed - although they found quite a few more. All this does not bode well - Cure53 are not infallible, an audit is not a substitute for secure coding practices, and the initial results show that the software was clearly not built by people who understand software security. The summary of their results is attached to their Action Items bug[3], but it does leave out some of the more critical passages of commentary from the original, and of course does not show the particular holes found and their scope and severity. * The WT/BR/EV audits on StartCom's website are significantly qualified, and they include lack of controls on issuance. They should have clean ones done before we permit any inclusion request to proceed. The qualifications include: - Risk analysis process defined but not implemented - Business continuity plan defined but not implemented - Audit logs not guaranteed to have integrity - Monitoring system cannot detect security-related changes to Certificate Systems * Certnomis chose to cross-sign StartCom while StartCom had audits with significant qualifications, and allowed them to recommence publicly-trusted issuance before they had demonstrated to Mozilla that they had met the remediation conditions required. While this may not have been against the letter of our requirements for StartCom to restart trusted operations, we feel it was not in the spirit of them. All in all, this attempt to start a new CA compares poorly with other recent executions of this process, such as those by Google and Amazon. While those companies do have significantly more resources than StartCom, many of the issues raised are questions of good practice, not of money. Conclusion: StartCom's attempt to restart the CA was rushed. One could speculate why that was; perhaps due to a requirement to start generating income again. But a process of building a production PKI by trial and error, revoking your mistakes, is entirely inappropriate. The qualified audits include missing or unimplemented processes, and audit/monitoring failures which lead to uncertainty as to how well the new roots were protected. This all shows that StartCom were not ready to start up the production PKI when they did. And yet Firefox today trusts tens of thousands of certificates issued by this PKI. Considering all this, our proposal is to require that StartCom begin again with new-new roots. These roots should be generated inside an already-security-validated infrastructure, as part of a new WT/BR audit process, the end results of which are clean because they already have all the policies and processes in place before the roots are generated. They should also build and use a parallel testing hierarchy, so that major operations done on the production PKI are done right, first time. Once they have generated new-new roots and intermediates, and got clean audits, they can re-re-apply for inclusion. No-one should be allowed to cross-sign this new hierarchy until, at minimum, Mozilla has pronounced itself satisfied that the 5 (or 6) remediation conditions which were imposed have been met. To permit otherwise is to allow the bypassing of Mozilla's requirements. We should add the existing Certnomis cross-signs to OneCRL to revoke all the existing certificates. As of 10th August (now a month ago) StartCom said they have 50000 outstanding SSL certs which are valid due to the Certnomis cross-sign. Revoking them all by adding intermediates to OneCRL would therefore lead to non-negligible disruption. But these were issued by an org whose most recent audits are qualified, which is under sanction, and about whose issuance practices and process safety there is a reasonable amount of doubt. We may allow a grace period for customers to replace them with certs from a trusted provider. We are not sure what to do about StartCom's poor quality PHP code. While continued use of it would cause us concern, we are not really in a position to request particular changes to it, or a complete rewrite, in a verifiable way. On the other hand, a security audit is a remediation condition, and the current codebase can hardly be said to have passed with flying colours. We feel some sympathy for StartCom CEO Inigo Barreira, who has been placed in a difficult position since he took on the role, but we need to treat all CAs equally and fairly, according to our professional judgement. We would not accept this set of circumstances from other CAs, and so we feel we cannot accept it here. Comments on this proposal are welcomed. Gerv [0] https://bugzilla.mozilla.org/show_bug.cgi?id=1381406 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1311832 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1369359 https://bugzilla.mozilla.org/show_bug.cgi?id=1386894 https://bugzilla.mozilla.org/show_bug.cgi?id=1386891 https://bugzilla.mozilla.org/show_bug.cgi?id=1381406#c5 and other comments in m.d.s.p. [3] https://bugzilla.mozilla.org/attachment.cgi?id=8886970 _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
