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
> in blog posts by Google  and Mozilla . We would like to discuss
> further action might be necessary in order to maintain the integrity of
> 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
> required to be re-audited in order to confirm their adherence to those
> We propose to add name constraints to the CNNIC root in NSS to minimize
> impact of any future mis-issuance incidents. The â€œupdate procedures and
> re-auditâ€ approach taken with TurkTrust is not suitable for this
> 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
> mis-issuance. We will follow up this post soon with a specific list of
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
* 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
* 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
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 . This was further affirmed in
the January 10, 2013  and May 13, 2014  CA communications.
As one last data point worth mentioning, during the request for inclusion
of their EV root , 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 . This is noted on
2012-09-27. However, this is not resolved until 2014-01-16 , or 476
days after moving towards inclusion.