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
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