I think this discussion has made it clear that the request for inclusion of the TunRootCA2 root should be denied.
CAs inherently must be trusted, and trust must be earned. A CA can't simply fix one problem after another as we find them during the inclusion process and expect to be rewarded for their reactive efforts, nor can they ignore program requirements until the time comes to get their inclusion request approved. Recurrences of the same issue that the CA claimed to have fixed are especially damaging. As Ryan mentioned, section 7.1 of the Root Store Policy states that "We will determine which CA certificates are included in Mozilla's root program based on the benefits and risks of such inclusion to typical users of our products." While I believe the decision to deny this request is fully supported by that policy statement, I would be interested to know if anyone thinks there are ways we could make our expectations clearer in this regard. Regarding next steps, the Tunisian Government is welcome to submit a new root (using a newly generated key pair) for inclusion. The current bug may be reopened and used for the new request, but it will still need to go through the entire process. The only real "shortcut" in the inclusion process - as has been demonstrated by a few CAs recently who completed the process in 9-18 months) - is to have all the requirements fully met before the request is reviewed. Tests that are performed during the information verification process are documented [1], and every previous inclusion request is publicly accessible in Bugzilla and archives of this list, so this really shouldn't be as difficult as it seems to be. I agree with the comments Hans made on the desire to rapidly move through the process with the new request. Establishing confidence in a CA takes time, and attempts to move too quickly to regain trust can be extremely counterproductive (e.g. StartCom). Regarding the choice of auditor, Mozilla has not disqualified LSTI and so will not require a different auditor to be selected if/when a new root is submitted. However, given the concerns that have been raised with the current audits, choosing a different auditor may help to gain the confidence of the community in the new root and in the Tunisian Government CA. - Wayne [1] https://wiki.mozilla.org/CA:TestErrors On Thu, Mar 15, 2018 at 5:44 AM, okaphone.elektronika--- via dev-security-policy <dev-security-policy@lists.mozilla.org> wrote: > On Thursday, 15 March 2018 04:30:22 UTC+1, syri...@gmail.com wrote: > > Dear Wayne, > > Based on the long discussion regarding our request, I would appreciate > having your opinion on the following: > > Move to a new root based on EJBCA (Enterprise License) and conduct a new > audit with a new auditor as required by Mozilla and the BR. > > We are ready and we do commit to do these steps in 6 months. As we hope > that you would accept to resume the inclusion process from this point. > > We are looking forward to hearing from you. > > > > Syrine. > > Do consider that it only makes sense to start with a new root (and do the > required audits etc.) when you are sure that all problems have been fixed, > in such a way that they (and others like them) will not happen again. > > Because if that isn't the case, the new root will soon be as useless as > trust-anchor as the old one. The fastest way forward is probably to not try > to do it quickly. > > CU Hans > _______________________________________________ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
