On Tuesday, 18 October 2016 15:38:07 UTC+1, Inigo Barreira wrote: > Let´s focus on the 3 issues for which StartCom has been proposed to a > sanction (hopefully we can change that), and these are: > > 1.- Bad coding of a new solution called startencrypt, which basically > was barely used and not affected StartCom > > 2.- Issues with serial numbers, not able to generate serial numbers > starting with zero and the reuse of some. Those were bugs fixed on time > and were because of a software and hardware upgrading as explained > before, due to the acquisiton of Wosign because the PKI was cloned. This > is also indicated in the plan > > 3.- Backdating 2 certs for Tyro. I think this is the issue that has made > Mozilla to include Startcom in the equation and fine it. But as also > explained this is not a security issue (same as other SHA1 certs > legitimacy issued on time) but a bad practice > > In any case, this mailing list is called mozilla.dev._security_.policy, > and for these 3 issues, imho there´s no security problem.
Without any doubt in my mind, all three issues were in fact security problems. Most broadly this is because StartCom deviated from its stated policy and obeying that policy is itself a security requirement. It is not for StartCom to declare that it has decided after the fact some aspects of the policy are not "security" and it chose to ignore those, the Relying Parties are entitled to expect that StartCom will obey the entire policy and to rely on however much or little of the policy as they like. Likewise for the Baseline Requirements. StartCom was of course welcome to write a policy saying "We might issue backdated certificates, we might re-use serial numbers, we might not bother actually doing domain verification properly" and I believe a hypothetical alternative CA which documented such policies, let's call it "Garbage StartCom" would not be trusted by Mozilla, nor by any major trust store. Why should the actual StartCom be permitted to document good policies, then act like Garbage StartCom anyway with the thin excuse that you think it was not a "security" problem? For the backdated SHA-1 certificates in particular, signing these certificates involved taking a huge risk each time because of the known vulnerability of the Merkle–Damgård construction and relatively short hashes in SHA-1. When this is done for the Exception process the _entire_ community gets to examine the tbsCertificates first, with both statistical analysis tools and simple visual inspection of the contents to see if there's anything dubious. But StartCom / WoSign instead issued certificates without so much as telling anybody, forcing the risk upon the entire Web PKI relying community without notice, for their financial benefit. StartCom's Issuer for the back-dated SHA-1 certificates has a CA:TRUE certificate without a path length constraint allowing a hypothetical bad guy to create themselves a full CA:TRUE certificate of their own using a chosen-prefix attack or some as-yet unknown improvement on the same idea. That's basically game over for the PKI if it had happened, but StartCom/ WoSign risked it to get some cash in direct defiance of the Baseline Requirements, and the rules of the trust store programmes they'd agreed to. How is that _not_ a security problem ? _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
