I see this question (new root cert/private key or continue with the existing one) as being less about security and more about what got us here in the first place.
From Ryan's reply: 1) Certificates that violate policy (such as the one that lead to CNNIC's quasi-removal) may have been issued that, if CNNIC were accepted, would become recognized as valid. I think this is the crux of the problem: how do we want to treat all the existing certs which chain to this root? If we let the existing root stand it seems like we're saying to CNNIC, "Go ahead and do these audits and then once you've been accepted back in the program we'll just pretend that this whole thing never happened." There are probably good reasons to do just that (convenience to cert holders, expediency in reinstating CNNIC's root) but then I have to rethink what started this whole mess: the loss of trust/confidence in the management of this CA. Since losing that trust, why would (should?) we allow any of those certs to be valid once more? How do we know which ones are safe to trust? To my mind, if the question being asked is how do we reestablish trust in CNNIC then I think the answer is new private key, new root cert, new audits, and new certs issued to existing cert holders. If it's a different question being asked, we'll probably have a different answer. Original Message From: Gervase Markham Sent: Wednesday, May 27, 2015 4:41 AM On 26/05/15 22:26, Kathleen Wilson wrote: > But this raises the question of whether their re-application can be for > the same (currently-included) root certificates, or if it has to be for > a new root certificate. In other words, should we consider taking the > stance that we will require a new root certificate for their > re-application? (i.e. the restrictions would remain in place for the > currently-included roots.) I see no security advantage in requiring new roots. Doing so would be an inconvenience (one might say "punishment") to CNNIC, and someone might want to argue for it on those grounds, but I can't see how requiring new roots changes any security evaluation, because there has been no suggestion that their roots are either a) technically unsound, or b) compromised. Gerv _______________________________________________ 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
