On Mon, March 23, 2015 3:47 pm, Richard Barnes wrote: > Dear dev.security.policy, > > It has been discovered that an intermediate CA under the CNNIC root has > mis-issued certificates for some Google domains. Full details can be > found > in blog posts by Google [0] and Mozilla [1]. We would like to discuss > what > further action might be necessary in order to maintain the integrity of > the > Mozilla root program, and the safety of its users. > > There have been incidents of this character before. When ANSSI issued an > intermediate that was used for MitM, name constraints were added to limit > its scope to French government domains. When TurkTrust mis-issued > intermediate certificates, they changed their procedures and then they > were > required to be re-audited in order to confirm their adherence to those > procedures. > > We propose to add name constraints to the CNNIC root in NSS to minimize > the > impact of any future mis-issuance incidents. The âupdate procedures and > re-auditâ approach taken with TurkTrust is not suitable for this > scenario. > Because the mis-issuance was done by a customer of CNNIC, itâs not clear > that updates to CNNICâs procedures would address the risks that led to > this > mis-issuance. We will follow up this post soon with a specific list of > proposed constraints. > > Please send comments to this mailing list. We would like to have a final > plan by around 1 April. > > Thanks, > --Richard > > [0] > > http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html > [1] > > https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate/
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
