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" 

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

Reply via email to