Best and most substantial summary I have read so far, Ryan. I do remember the CA communications Kathleen initiated after TrustWave.
Also, CNNIC is saying "it was only a test and we got it wrong and it had consequences". Not exactly trust-inspiring. On 03/25/2015 08:17 AM, Ryan Sleevi wrote: > Based on the information provided so far, I think we can establish > multiple failures upon CNNIC's part to comply with both the Baseline > Requirements and Mozilla's Certificate Inclusion Policy. > > Some of these have also been raised by others (thanks Peter!), but below > is a summary of the information available to date. > > * Section 17 of the BRs requires that all certificates "_capable_ of being > used to issue new certificates" MUST either be Technically Constrained or > audited in line with all of the requirements of Section 17. > * Prior to the issuance of a certificate, CNNIC should have ensured a > Point in Time Readiness Assessment with an appropriate audit scheme, per > Section 17.4. > * Prior to the issuance of a certificate, CNNIC should have ensured the > development of a Key Generation Script and that the Key Generation > Script was witnessed by a qualified auditor or a video recording opined > upon by a qualified auditor, per Section 17.7. > * Prior to the issuance of a certificate, CNNIC should have ensured that > the keys were generated in a physically secured environment and > generated securely, per Section 17.7. > * CNNIC's current CPS (v3.03) does not provide for or describe the > issuance procedures for test or subordinate CA certificates. The closest > approximation is Section 2.2.10, which describes CNNIC pursuing > cross-certification for their own root, not the use of CNNIC to > cross-certify. > * CNNIC's current CPS (v3.03) states in Section 6.2.3 that "The private > keys of the root certificates and intermediate root certificates of CNNIC > Trusted Network Service Center are not entrusted to another agency, nor > does CNNIC Trusted Network Service Center accept the entrustment from any > certificate applicant to keep signature private keys.". Two > interpretations of this exist - this is either a reaffirmation that > subordinate CA keys are not issued (consistent with the rest of the CPS, > and based upon "entrusted to another agency" referring to MCS), or that > they only control the private keys detailed within the CPS itself. > * CNNIC's current CPS (v3.03) states in Section 7.1.2 that the profile for > issued certificates will have a CA=FALSE, through the mistranslation of > "basicConstraints" as "Basic Restriction" and "Subject Type = End Entity". > * Mozilla's Certificate Inclusion Policy (v2.1 and 2.2) both require that > all certificates capable of issuance be _publicly disclosed and audited_ > or _technically constrained_ (Section 8). Disclosure is required _before_ > the subordinate CA is allowed to issue certificates (Section 10). > > In the responses provided to this list, CNNIC has affirmed that MCS did > not have a CPS developed, ergo did not have an approved Key Generation > Script, did not have a Point-in-Time Readiness Assessment, and lacked any > form of controls beyond that of contractual agreement. CNNIC knowingly and > willingly issued certificates despite this - this was not a failure of > technical controls (as was Turktrust), but an intentional action. > > This represents multiple Baseline Requirements and Mozilla Policy > violations. Further, given the nature of these violations, there are zero > guarantees that these would have been detected by an audit. Though CNNIC > limited the certificate validity to 23 days (a value of time greater than > the two weeks represented here and in the Mozilla blog post), such > certificates could have only been detected by a sampling audit. Given that > Section 17.8 only dictates a quarterly audit of 1 cert or 3% of issued > certs, there is a significant probability that this certificate would not > have shown. Had it shown, the fact that it has expired may, for many > auditors, prevent a qualified finding from being issued, thus from Mozilla > being notified. > > This is different than ANSSI, in which an administrator violated stated > policy when handling the issued certificate, but which was part of the > same organization recognized. > > The closest similarity to past misissuance is Trustwave, in which a CA > knowingly violated the program requirements. At the time of Trustwave, > there existed some confusion regarding this, which although many people > disagreed with Trustwave's interpretation, Root Stores recognized this as > a possible reading. > > Mozilla had previously affirmed in the February 17, 2012 communication the > expectations regarding such certificates [1]. This was further affirmed in > the January 10, 2013 [2] and May 13, 2014 [3] CA communications. > > As one last data point worth mentioning, during the request for inclusion > of their EV root [4], it's noted that CNNIC is failing to comply with > Mozilla and CA/B Forum Guidelines by not ensuring there are at least 20 > bits of entropy within end-entity certificates [5]. This is noted on > 2012-09-27. However, this is not resolved until 2014-01-16 [6], or 476 > days after moving towards inclusion. > > > [1] https://wiki.mozilla.org/CA:Communications#February_17.2C_2012 > [2] https://wiki.mozilla.org/CA:Communications#January_10.2C_2013 > [3] https://wiki.mozilla.org/CA:Communications#May_13.2C_2014 > [4] https://bugzilla.mozilla.org/show_bug.cgi?id=607208 > [5] https://bugzilla.mozilla.org/show_bug.cgi?id=607208#c22 > [6] https://bugzilla.mozilla.org/show_bug.cgi?id=607208#c25 > _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
