As Gerv suggested this was the official call for incidents with respect to
StartCom, it seems appropriate to start a new thread.
It would seem that, in evaluating the relationship with WoSign and Qihoo, we
naturally reach three possible conclusions:
1) StartCom is treated as an independent entity
2) StartCom is treated as a subsidiary of Qihoo
3) StartCom is treated as a subsidiary of WoSign
We know there are serious incidents with WoSign that, collectively, encourage
the community to distrust future certificates. However, there hasn't been a
similar investigation into the trustworthiness of StartCom as an independent
entity or as an entity operated by Qihoo. It would seem that germane to the
discussion is how trustworthy the claims are - from either StartCom or Qihoo -
and how that affects trust.
Incidents with StartCom:
A) Duplicate Serials. https://bugzilla.mozilla.org/show_bug.cgi?id=1029884
We know that StartCom had issues issuing duplicate serials, in violation of RFC
5280. We know that they did not prioritize resolution, and when attempting
resolution, did so incompletely, as the issue still resurfaced.
C) Improper OCSP responder.
We know that StartCom continues to have issue with their OCSP responder after
they issue certificates. Presumably, this is a CDN distribution delay, but we
can't be sure, especially considering Incident A was with the underlying
systems. As a consequence of this, users with StartCom certificates are
disproportionately disadvantaged from enabling OCSP stapling, which many
browser programs support (and is perhaps the only viable path towards a
complete revocation solution).
E) Heartbleed. https://bugzilla.mozilla.org/show_bug.cgi?id=994033 /
We know StartCom had a notoriously poor response to HeartBleed. Eddy first
dismissed the significance, and then when proven wrong, still continued to
charge $25 USD for revocation. Ostensibly, this is a violation of the Baseline
Requirements, in that CAs are required to revoke certificates suspected of Key
Compromise. However, despite the BRs effective date of 2012, Mozilla was not
aggressively imposing compliance then (... or now, to be fair).
G) StartCom BR violations - IV
StartCom was materially violating its CP/CPS and the Baseline Requirements with
respect to certain types of validation. No explanation for the root cause
I) StartCom BR violations (2) - Key Sizes
StartCom was issuing certificates less than 2048 bits.
K) StartCom impersonating mozilla.com.
StartCom's (former) CEO Eddy Nigg obtained a key and certificate for
www.mozilla.com and placed it on an Internet-facing server.
M) StartCom BR violations (3) - Key exponents
StartCom was not enforcing the BRs with respect to RSA public exponents.
O) StartCom BR violations (4) - Curve violations
StartCom was not enforcing the BRs with respect to EC curve algorithms.
In addition to discussion of StartCom issues, it seems relevant to future trust
to evaluate issues with Qihoo. Many in the Mozilla community may not have
direct interactions with Qihoo, but they have obtained some notoriety in
Q.A) Qihoo masking their browser as a critical Windows security update to IE
Qihoo displayed a misleading security update for Windows users that instead
installed their browser.
Q.C) Qihoo browser actively enables insecure cryptography.
Qihoo's browser is notably insecure with respect to SSL/TLS, with some of the
insecure changes requiring active modification to the low-level source
libraries that Chromium (of which they're based on) uses.
Q.E) Qihoo apps removed from app stores due to malware
Qihoo Apps have repeatedly been banned from Apple's App Store due to issues
Q.G) Qihoo "security" apps repeatedly found as unfair competition
I hope the above show that the odds are if the original StartCom systems are
restored, we're likely to continue to have significant BR violations - a
pattern StartCom has repeatedly demonstrated over several years. Similarly, if
we were to accept trust in Qihoo, then we would be ignoring the precedent Qihoo
has set of choosing insecure and anti-user behaviours masked as "security".
dev-security-policy mailing list