Consequences of mis-issuance under CNNIC

4292 views
Skip to first unread message

Richard Barnes

unread,
Mar 23, 2015, 6:48:10 PM3/23/15
to mozilla-dev-s...@lists.mozilla.org
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/

Jeremy Rowley

unread,
Mar 23, 2015, 6:51:07 PM3/23/15
to Richard Barnes, mozilla-dev-s...@lists.mozilla.org
Although CT would not have prevented issuance, requiring CT for all certificates would have detected the misissuance much sooner. Maybe Mozilla should be the first to require CT for all certificates?

Jeremy
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Peter Bowen

unread,
Mar 23, 2015, 8:00:36 PM3/23/15
to Richard Barnes, mozilla-dev-s...@lists.mozilla.org
On Mon, Mar 23, 2015 at 3:47 PM, Richard Barnes <rba...@mozilla.com> wrote:
> 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.

Is there any data on this intermediate?

- Was it publicly disclosed as per Mozilla's unconstrained subordinate policy?

- Was it issued since their latest complete audit period ended and, if
not, did their auditor flag it?

- What response has their been from CNNIC on this issue? How do they
explain issuing a subordinate CA certificate with a private key not
being on a HSM meeting the Baseline Requirements?

- How many other CA certs has CNNIC issued which are not stored on HSMs?

Kathleen Wilson

unread,
Mar 23, 2015, 8:51:51 PM3/23/15
to mozilla-dev-s...@lists.mozilla.org
Peter, Did you read the blog posts?
1)
https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate/
2)
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html

>
> Is there any data on this intermediate?

Does the Google blog post answer your question?
Note that they provided the cert chain:
https://drive.google.com/file/d/0B_OzbbAp1CG5NXVrYmFPbFhUV2s/view?usp=sharing

>
> - Was it publicly disclosed as per Mozilla's unconstrained subordinate policy?

In the next version of Mozilla's policy I plan to add information about
when CAs are required to disclose their unconstrained subordinates,
which I expect will be in line with the Baseline Requirements.

According to the Baseline Requirements section 17 and 17.4, pre-issuance
Readiness Audit is to be done before the SubCA begins issuing
publicly-trusted certs. Then a complete audit is due within 90 days of
issuing the first publicly-trusted cert.


>
> - Was it issued since their latest complete audit period ended and, if
> not, did their auditor flag it?

From Mozilla's blog post:
"CNNIC issued an unconstrained intermediate certificate that was labeled
as a test certificate and had a two week validity, expiring April 3, 2015."

CNNIC's most recent audit statement is 8/1/2014.

>
> - What response has their been from CNNIC on this issue?

The CNNIC representative notified me of the certificate revocation on
Sunday, without prompting from me. (I had not sent them email asking
about it.)


> How do they
> explain issuing a subordinate CA certificate with a private key not
> being on a HSM meeting the Baseline Requirements?

That is a very good question. Their customer apparently used a Palo Alto
Network Firewall Built in CA server to create their CSR request, and
planned to export it and import it into their CA server. Apparently
CNNIC was not aware that the customer had done this (until the incident
occurred).

It is a good question about how CAs can better inform their customers
and make sure their customers don't do things like this.

>
> - How many other CA certs has CNNIC issued which are not stored on HSMs?
>

Remember that it is CNNIC's customer who made this mistake. CNNIC, as
the CA, is still responsible for it. But I would be surprised if CNNIC
themselves have this problem, nonetheless I will ask them.

Kathleen







Peter Kurrasch

unread,
Mar 23, 2015, 9:00:14 PM3/23/15
to Richard Barnes, mozilla-dev-s...@lists.mozilla.org
Hi Richard, 

Is the proposal to limit CNNIC roots to only .cn domains or would others be allowed?

I'm curious to know what CNNIC's perspective is on this proposal, so will a representative be replying in this forum?

Thanks.

  Original Message  
From: Richard Barnes
Sent: Monday, March 23, 2015 5:48 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Consequences of mis-issuance under CNNIC

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.

Peter Bowen

unread,
Mar 23, 2015, 9:14:55 PM3/23/15
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
I did read them both, but missed a couple of details on the Mozilla one.

>> - Was it issued since their latest complete audit period ended and, if
>> not, did their auditor flag it?
>
>
> From Mozilla's blog post:
> "CNNIC issued an unconstrained intermediate certificate that was labeled as
> a test certificate and had a two week validity, expiring April 3, 2015."
>
> CNNIC's most recent audit statement is 8/1/2014.

Ok, so the auditor did not miss it.

>> How do they
>> explain issuing a subordinate CA certificate with a private key not
>> being on a HSM meeting the Baseline Requirements?
>
>
> That is a very good question. Their customer apparently used a Palo Alto
> Network Firewall Built in CA server to create their CSR request, and planned
> to export it and import it into their CA server. Apparently CNNIC was not
> aware that the customer had done this (until the incident occurred).

The Baseline Requirements state "The CA SHALL protect its Private Key
in a system or device that has been validated as meeting at least FIPS
140 level 3 or an appropriate Common Criteria Protection Profile or
Security Target, EAL 4 (or higher), which includes requirements to
protect the Private Key and other assets against known threats."

According to https://www.paloaltonetworks.com/company/certifications.html
and http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2323,
this device has been certified at Level 3 for several parts, but has
an overall Level 2 certification. I was under the impression, from
the Google blog post, that the CA key was not in a FIPS certified
device at all.


>> - How many other CA certs has CNNIC issued which are not stored on HSMs?
>>
>
> Remember that it is CNNIC's customer who made this mistake. CNNIC, as the
> CA, is still responsible for it. But I would be surprised if CNNIC
> themselves have this problem, nonetheless I will ask them.

I was under the impression that CNNIC failed to verify that the key
was properly stored. Based on the note that it was generated and
stored on a Palo Alto Networks firewall, it appears that they
requirement was met, as technically it met FIPS Level 3. The BRs
probably need to clarify that the _Overall_ level needs to be level 3,
not just module levels.

That being said, maybe the better question to ask is "How does CNNIC
confirm that subordinate CA keys are generated and secured
appropriately?"

Thanks,
Peter

David E. Ross

unread,
Mar 23, 2015, 10:24:18 PM3/23/15
to mozilla-dev-s...@lists.mozilla.org
What assurance is there that the mis-issued certificates were not
intentional. The approval of the CNNIC was quite controversial.
Assertions were made that CNNIC is actually an agent of the Chinese
military.

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.

Charles Reiss

unread,
Mar 24, 2015, 3:17:42 AM3/24/15
to mozilla-dev-s...@lists.mozilla.org
On 03/23/15 22:47, 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.

Does any part of CNNIC's CPS cover issuing external subCAs at all? When did
CNNIC start issuing external subCAs?

Did CNNIC take steps suggesting they planned to comply with Mozilla's subCA
policy for this CA:
- Did they have a CPS for this subCA?
- Is there evidence that any auditing of this subCA took place/was planned?



Anyin

unread,
Mar 24, 2015, 3:41:18 AM3/24/15
to Charles Reiss, mozilla-dev-s...@lists.mozilla.org
Does any part of CNNIC's CPS cover issuing external subCAs at all? When did CNNIC start issuing external subCAs?
I am afraid we don't have issuing external subCAs in CPS. This is the first time we try to issueing an external subCAs just for testing propose.
We decided to discuss external SUBCAs authorization with our audit team in this year WebTrust audit in April.

Did CNNIC take steps suggesting they planned to comply with Mozilla's subCA policy for this CA:
- Did they have a CPS for this subCA? Not yet.
- Is there evidence that any auditing of this subCA took place/was planned?
As we discussed with MCS Holding, we will issue a 2 weeks period intermediate cert for testing propose, as we only define the EKU, no name constrains in the intermediate cert, we made items in agreement that MCS must issue cert to domains only MCS registered. We decided to discuss the audit request on the formal cooperation regarding intermediate root authorized.

Regards,

An Yin
CA Product Manager
---------------------------------------------------
= =Profession • Responsibility • Service= =

China Internet Network Information Center (CNNIC)
Tel: (8610)-58812432
mobile:13683527697
Fax: (8610)-58812666-168
Web: http://www.cnnic.cn
Add: 4 South 4th Street, Zhongguancun, Haidian district, 100190 Beijing, China
POB: Beijing 349, Branch 6
---------------------------------------------------
-----邮件原件-----
发件人: dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org [mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org] 代表 Charles Reiss
发送时间: 2015年3月24日 15:16
收件人: mozilla-dev-s...@lists.mozilla.org
主题: Re: Consequences of mis-issuance under CNNIC

On 03/23/15 22:47, 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.

Does any part of CNNIC's CPS cover issuing external subCAs at all? When did CNNIC start issuing external subCAs?

Did CNNIC take steps suggesting they planned to comply with Mozilla's subCA policy for this CA:
- Did they have a CPS for this subCA?
- Is there evidence that any auditing of this subCA took place/was planned?



Gervase Markham

unread,
Mar 24, 2015, 4:54:32 AM3/24/15
to Jeremy Rowley
On 23/03/15 22:49, Jeremy Rowley wrote:
> Although CT would not have prevented issuance, requiring CT for all
> certificates would have detected the misissuance much sooner.

I'm not sure that's true. The intermediate itself would not count as a
misissuance. The Google cert the firewall created would, but Google
found out about that and notified us very quickly.

Mozilla's position on CT remains the same: "watching with interest" :-)

Gerv

Gervase Markham

unread,
Mar 24, 2015, 4:59:47 AM3/24/15
to Peter Bowen
On 24/03/15 00:00, Peter Bowen wrote:
> Is there any data on this intermediate?
>
> - Was it publicly disclosed as per Mozilla's unconstrained subordinate policy?

Kathleen would need to say to be certain, but my understanding is no.

> - Was it issued since their latest complete audit period ended and, if
> not, did their auditor flag it?

It was issued:

Validity
Not Before: Mar 19 06:20:09 2015 GMT
Not After : Apr 3 06:20:09 2015 GMT

I presume that is since their last audit.

> - What response has their been from CNNIC on this issue? How do they
> explain issuing a subordinate CA certificate with a private key not
> being on a HSM meeting the Baseline Requirements?

Good question. For those following along, this is Baseline Requirements
16.6:

16.6 Private Key Protection

The CA SHALL protect its Private Key in a system or device that has been
validated as meeting at least FIPS 140 level 3 or an appropriate Common
Criteria Protection Profile or Security Target, EAL 4 (or higher), which
includes requirements to protect the Private Key and other assets
against known threats. The CA SHALL implement physical and logical
safeguards to prevent unauthorized certificate issuance. Protection of
the Private Key outside the validated system or device specified above
MUST consist of physical security, encryption, or a combination of both,
implemented in a manner that prevents disclosure of the Private Key.

(And, just to be clear, from the definitions: "Certification Authority:
An organization that is responsible for the creation, issuance,
revocation, and management of Certificates. The term applies equally
to both Roots CAs and Subordinate CAs.")

> - How many other CA certs has CNNIC issued which are not stored on HSMs?

Unknown.

Gerv

Gervase Markham

unread,
Mar 24, 2015, 5:04:44 AM3/24/15
to Peter Kurrasch
On 24/03/15 00:59, Peter Kurrasch wrote:
> Is the proposal to limit CNNIC roots to only .cn domains or would
> others be allowed?

That's a matter for discussion. We do have some data (thanks, Richard)
from CT and other places on the prevalence of CNNIC certificates in
those scans, broken down by TLD:

cn: 481
com: 203
net: 10
xn--fiqs8s: 8 (This is 中国, .china in Simplified characters)
xn--55qx5d: 4 (This is 公司, basically .com)
xn--io0a7i: 2 (This is 网络, basically .net)
wang: 2 (This is the Pinyin (romanization) for 网, which you can see
in the .net equivalent above. Chinese internet cafes have
this character on their signs. http://icannwiki.com/.wang)
xn--fiqz9s: 1 (This is 中國, .china in Traditional characters)

This is useful in assessing the impact of any particular proposed set of
changes.

> I'm curious to know what CNNIC's perspective is on this proposal, so
> will a representative be replying in this forum?

Like anyone else, they are welcome to contribute here.

Gerv

Kurt Roeckx

unread,
Mar 24, 2015, 5:05:44 AM3/24/15
to mozilla-dev-s...@lists.mozilla.org
So it's my understanding that they were only supposed to issue
certificates for their own domain(s). Why wasn't this enforced by using
a name constraint?


Kurt

Gervase Markham

unread,
Mar 24, 2015, 5:09:39 AM3/24/15
to mozilla-dev-s...@lists.mozilla.org
On 24/03/15 02:23, David E. Ross wrote:
> What assurance is there that the mis-issued certificates were not
> intentional.

All of the evidence we have seen does fit with the scenario as outlined
in the two blog posts. Of course, most of that evidence comes from CNNIC
(and MCS via CNNIC). But then, this is often the case in events
regarding misissuance - the details we have come from the CA.

> The approval of the CNNIC was quite controversial.
> Assertions were made that CNNIC is actually an agent of the Chinese
> military.

Anyone can make assertions. As we noted at the time, we do not take
action against any CA based solely on assertions.

Gerv

Gervase Markham

unread,
Mar 24, 2015, 5:10:29 AM3/24/15
to Kurt Roeckx
The implied answer to this question from statements by the CNNIC
representative is that their system was not set up to issue certificates
with name constraints, and this is something they are now urgently
looking at fixing.

Gerv

Anyin

unread,
Mar 24, 2015, 5:16:27 AM3/24/15
to David E. Ross, mozilla-dev-s...@lists.mozilla.org
Hi David E.Ross,

I am not so sure the if you could receive the mail from MCS, so I attached
their response as following,

Hello Anyin,

It's really unfortunate to get such absolute incorrect and prejudiced
feedback
I sent the truth inside the requested report and i am ready to submit any
required proofs from our Firewall Logs as we reported
I don’t think being a company established 8 years ago with a very
successful projects references across the middle east with a direct
partnership with a leading world wide companies like Intel, PaloAlto,
Juniper and riverbed with a fully compliance history to the import
regulations for the security products might submit a report with incorrect
information!!!!
i appreciate your revisiting to the report carefully then inquiring for the
uncleared issues, studying our feedback and proofs
Then finally to judge either the submitted information is delivering the
truth or not !!!
That’s the logic !!
again, i am open for discussion and to respond to any objective inquiries !!


Regards,

Amr Farouk
Managing Director

Mideast Communication Systems
5 Al Sherka Al Portsaidya St, off Asmaa Fahmy St.
Behind Rekaba Idareya Building, 11341
Heliopolis. Cairo, Egypt
Mobile: +2 (0122) 3929889
Office (Tel): +2 (02) 2290 9326
Office (Fax):+2 (02) 2415 3565
Email: a...@mcsholding.com
Website: www.mcsholding.com
Mideast Communication Systems – Tomorrow’s Solutions Today TM

Regards,
An Yin

-----邮件原件-----
发件人: dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org] 代表
David E. Ross
发送时间: 2015年3月24日 10:23
收件人: mozilla-dev-s...@lists.mozilla.org
主题: Re: Consequences of mis-issuance under CNNIC

On 3/23/2015 5:59 PM, Peter Kurrasch wrote:
What assurance is there that the mis-issued certificates were not
intentional. The approval of the CNNIC was quite controversial.
Assertions were made that CNNIC is actually an agent of the Chinese
military.

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can be used when
autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.

Anyin

unread,
Mar 24, 2015, 5:18:09 AM3/24/15
to Gervase Markham, Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
Yes, we are working on fixing this issue with our CA system.

Regards,

An Yin
CA Product Manager
-----邮件原件-----
发件人: dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org] 代表
Gervase Markham
发送时间: 2015年3月24日 17:09
收件人: Kurt Roeckx; mozilla-dev-s...@lists.mozilla.org
主题: Re: Consequences of mis-issuance under CNNIC

On 24/03/15 09:03, Kurt Roeckx wrote:
The implied answer to this question from statements by the CNNIC
representative is that their system was not set up to issue certificates
with name constraints, and this is something they are now urgently looking
at fixing.

Gerv

Gervase Markham

unread,
Mar 24, 2015, 5:19:48 AM3/24/15
to Richard Barnes
On 23/03/15 22:47, Richard Barnes wrote:
> We propose to add name constraints to the CNNIC root in NSS to minimize the
> impact of any future mis-issuance incidents.

I think it's worth noting that alternative options (both more and less
severe) would be considered, if people want to make a case for them.

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

If this is true, it has some rather alarming consequences. You are
basically saying that today's certificate system does not have a
suitable way to prevent a CA's customers (or, at least, their customers
for intermediate certificates) from using such certificates in evil
ways. (You say this when you say there's nothing CNNIC could have done
differently to prevent this.)

If that's true, why would any CA take the risk of ever issuing an
intermediate to anyone else?

If that's our view, then shouldn't we be banning the practice of CAs
issuing intermediates to anyone other than themselves?

Alternatively, if that's true, if CNNIC could not have done anything to
prevent this, and if we are not going to ban the issuance of
intermediates to third parties, then surely no blame attaches to CNNIC?

That is not what I think, but it does seem like a logical consequence of
your statement.

Gerv

Florian Weimer

unread,
Mar 24, 2015, 5:36:41 AM3/24/15
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
* Kurt Roeckx:

> So it's my understanding that they were only supposed to issue
> certificates for their own domain(s). Why wasn't this enforced by
> using a name constraint?

Sadly, name constraints do not work because they do not constrain the
Common Name field. The IETF PKIX WG explicitly rejected an erratum
which corrected this oversight.

NSS used to be different (before the mozilla::pkix rewrite), but it's
not PKIX-compliant.

Florian Weimer

unread,
Mar 24, 2015, 5:40:09 AM3/24/15
to Gervase Markham, Peter Kurrasch, mozilla-dev-s...@lists.mozilla.org
* Gervase Markham:

> On 24/03/15 00:59, Peter Kurrasch wrote:
>> Is the proposal to limit CNNIC roots to only .cn domains or would
>> others be allowed?
>
> That's a matter for discussion. We do have some data (thanks, Richard)
> from CT and other places on the prevalence of CNNIC certificates in
> those scans, broken down by TLD:
>
> cn: 481
> com: 203
> net: 10
> xn--fiqs8s: 8 (This is 中国, .china in Simplified characters)
> xn--55qx5d: 4 (This is 公司, basically .com)
> xn--io0a7i: 2 (This is 网络, basically .net)
> wang: 2 (This is the Pinyin (romanization) for 网, which you can see
> in the .net equivalent above. Chinese internet cafes have
> this character on their signs. http://icannwiki.com/.wang)
> xn--fiqz9s: 1 (This is 中國, .china in Traditional characters)
>
> This is useful in assessing the impact of any particular proposed set of
> changes.

The intermediate certificate which prompted this discussion had C=EG,
which does not align well with a limitation to the Chinese market.
How reliable are the data quoted above?

Gervase Markham

unread,
Mar 24, 2015, 5:55:28 AM3/24/15
to Florian Weimer, Peter Kurrasch
On 24/03/15 09:38, Florian Weimer wrote:
> The intermediate certificate which prompted this discussion had C=EG,
> which does not align well with a limitation to the Chinese market.

I'm not entirely sure what you are saying here. Are you saying you are
suprised not to see ".eg" in that list?

> How reliable are the data quoted above?

It comes from either internet-wide cert scans or CT, or both - Richard
can tell you.

Remember, the TLD of the domain names in the CN or SAN fields is not the
same thing as the C= field in the DN of the owner of the cert.

CNNIC could issue a cert to an Egyptian Company called Cairo Corporation
for cairocorp.com, and the issuer would be C=EG, O=Cairo Corporation,
but the CN would be www.cairocorp.com. In this type of case, .eg would
not show up in the list.

Gerv

Gervase Markham

unread,
Mar 24, 2015, 6:03:01 AM3/24/15
to Florian Weimer, Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
On 24/03/15 09:35, Florian Weimer wrote:
> Sadly, name constraints do not work because they do not constrain the
> Common Name field. The IETF PKIX WG explicitly rejected an erratum
> which corrected this oversight.
>
> NSS used to be different (before the mozilla::pkix rewrite), but it's
> not PKIX-compliant.

My understanding is that we continue to constrain the CN field using
name constraints, even after adopting mozilla::pkix; do you know
differently?

Anyway, the BRs require that the value in the CN field be repeated in
the SAN field. So, at some point in the future, for publicly-trusted
certs anyway, we can start ignoring the CN field.

>From BRs draft 30b:

"If present, this field MUST contain a single Fully-Qualified
Domain Name that is one of the values contained in the
Certificate's subjectAltName extension (see Section 9.2.1)."

The BRs were adopted in 2011 and had an effective date of 1st July 2012.
At the time, they permitted 5 year issuance. So on 1st July 2017, we
should be able to start ignoring CN if we want.

(The fact that this is such a long time away is a good argument for
reducing cert lifetimes!)

Gerv

Gervase Markham

unread,
Mar 24, 2015, 6:03:24 AM3/24/15
to Florian Weimer, Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
On 24/03/15 09:35, Florian Weimer wrote:
> Sadly, name constraints do not work because they do not constrain the
> Common Name field. The IETF PKIX WG explicitly rejected an erratum
> which corrected this oversight.
>
> NSS used to be different (before the mozilla::pkix rewrite), but it's
> not PKIX-compliant.

Kurt Roeckx

unread,
Mar 24, 2015, 6:04:17 AM3/24/15
to mozilla-dev-s...@lists.mozilla.org
I understand that the name constraint applies to the SubjectAltName.
Under the Baseline Requirements the SAN must be present. If there is a
CommonName it should match one of the SANs.

We know that not everybody does add the SANs. But I think that if there
is a name constraint and there is no SAN we should just either reject
the certificate for being invalid or for not matching.

If a SAN is present you should probably either not look at the
CommonName or check that it matches a SAN.

If you know of software that doesn't do this, I suggest you file bug
reports. I have no idea what any implementation currently does.


Kurt

quanx...@gmail.com

unread,
Mar 24, 2015, 9:19:10 AM3/24/15
to mozilla-dev-s...@lists.mozilla.org
As it is shown that, CNNIC doesn't have any proper audit policy for issuing external subCA, and it is the first time they do so, can we at least untrust any external subCA issued by CNNIC before their updating policy gets reviewed?

- Xidorn

Erwann Abalea

unread,
Mar 24, 2015, 9:55:30 AM3/24/15
to mozilla-dev-s...@lists.mozilla.org
Le mardi 24 mars 2015 09:59:47 UTC+1, Gervase Markham a écrit :
> On 24/03/15 00:00, Peter Bowen wrote:
[...]
> > - What response has their been from CNNIC on this issue? How do they
> > explain issuing a subordinate CA certificate with a private key not
> > being on a HSM meeting the Baseline Requirements?
>
> Good question. For those following along, this is Baseline Requirements
> 16.6:
>
> 16.6 Private Key Protection
>
> The CA SHALL protect its Private Key in a system or device that has been
> validated as meeting at least FIPS 140 level 3 or an appropriate Common
> Criteria Protection Profile or Security Target, EAL 4 (or higher), which
> includes requirements to protect the Private Key and other assets
> against known threats. The CA SHALL implement physical and logical
> safeguards to prevent unauthorized certificate issuance. Protection of
> the Private Key outside the validated system or device specified above
> MUST consist of physical security, encryption, or a combination of both,
> implemented in a manner that prevents disclosure of the Private Key.
>
> (And, just to be clear, from the definitions: "Certification Authority:
> An organization that is responsible for the creation, issuance,
> revocation, and management of Certificates. The term applies equally
> to both Roots CAs and Subordinate CAs.")

See also Mozilla CA Policy, https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/, point 10.
This unconstrained sub-CA MUST have been audited and disclosed to Mozilla *before* it was able to issue certificates.

Florian Weimer

unread,
Mar 24, 2015, 10:26:56 AM3/24/15
to Gervase Markham, Peter Kurrasch, mozilla-dev-s...@lists.mozilla.org
* Gervase Markham:

> On 24/03/15 09:38, Florian Weimer wrote:
>> The intermediate certificate which prompted this discussion had C=EG,
>> which does not align well with a limitation to the Chinese market.
>
> I'm not entirely sure what you are saying here. Are you saying you are
> suprised not to see ".eg" in that list?

Or a more diverse choice of (cc)TLDs, yes.

> CNNIC could issue a cert to an Egyptian Company called Cairo Corporation
> for cairocorp.com, and the issuer would be C=EG, O=Cairo Corporation,
> but the CN would be www.cairocorp.com. In this type of case, .eg would
> not show up in the list.

Technically, this is true. I just find it odd that the offending
certificate suggests a relationship with a non-Chinese market, while
at the same time, Richard's data only shows the top gTLDs and various
China-related TLDs.

Florian Weimer

unread,
Mar 24, 2015, 10:28:30 AM3/24/15
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Kurt Roeckx
* Gervase Markham:

> On 24/03/15 09:35, Florian Weimer wrote:
>> Sadly, name constraints do not work because they do not constrain the
>> Common Name field. The IETF PKIX WG explicitly rejected an erratum
>> which corrected this oversight.
>>
>> NSS used to be different (before the mozilla::pkix rewrite), but it's
>> not PKIX-compliant.
>
> My understanding is that we continue to constrain the CN field using
> name constraints, even after adopting mozilla::pkix; do you know
> differently?

I simply have not investigated, my comment was poorly phrased in this
regard.

> Anyway, the BRs require that the value in the CN field be repeated in
> the SAN field. So, at some point in the future, for publicly-trusted
> certs anyway, we can start ignoring the CN field.
>
>>From BRs draft 30b:
>
> "If present, this field MUST contain a single Fully-Qualified
> Domain Name that is one of the values contained in the
> Certificate's subjectAltName extension (see Section 9.2.1)."
>
> The BRs were adopted in 2011 and had an effective date of 1st July 2012.
> At the time, they permitted 5 year issuance. So on 1st July 2017, we
> should be able to start ignoring CN if we want.

This is an interesting idea. It would be a nice simplification.

Florian Weimer

unread,
Mar 24, 2015, 10:32:10 AM3/24/15
to Kurt Roeckx, mozilla-dev-s...@lists.mozilla.org
* Kurt Roeckx:

> I understand that the name constraint applies to the
> SubjectAltName. Under the Baseline Requirements the SAN must be
> present. If there is a CommonName it should match one of the SANs.

If the CAs abided by the baseline requirements, we wouldn't have to
consider name constraints. :-(

> We know that not everybody does add the SANs. But I think that if
> there is a name constraint and there is no SAN we should just either
> reject the certificate for being invalid or for not matching.

This has to be integrated with certificate path processing somehow.
Maybe it is feasible to ignore the Subject DN if there is a name
constraint anywhere on the path?

That would be fairly straightforward to implement with other PKIX
validators (which generally lack the NSS hack for Common Name
verification).

Erwann Abalea

unread,
Mar 24, 2015, 11:16:55 AM3/24/15
to mozilla-dev-s...@lists.mozilla.org
Le mardi 24 mars 2015 15:32:10 UTC+1, Florian Weimer a écrit :
> * Kurt Roeckx:

> > We know that not everybody does add the SANs. But I think that if
> > there is a name constraint and there is no SAN we should just either
> > reject the certificate for being invalid or for not matching.
>
> This has to be integrated with certificate path processing somehow.
> Maybe it is feasible to ignore the Subject DN if there is a name
> constraint anywhere on the path?

Ignore the CN when validating a certificate for TLS use.
NameConstraints can have a directoryName form, and it applies to the SubjectDN.

> That would be fairly straightforward to implement with other PKIX
> validators (which generally lack the NSS hack for Common Name
> verification).

Providing support for legacy use of CN as FQDN while being strict on what-should-be-done isn't straightforward. Some bugs were raised when Firefox decided to disallow self-signed CA certs used as TLS server certs also.

Gervase Markham

unread,
Mar 24, 2015, 12:21:13 PM3/24/15
to Florian Weimer, Peter Kurrasch
On 24/03/15 14:25, Florian Weimer wrote:
> Technically, this is true. I just find it odd that the offending
> certificate suggests a relationship with a non-Chinese market, while
> at the same time, Richard's data only shows the top gTLDs and various
> China-related TLDs.

This may be a limitation in the data, or it may be that CNNIC are
expanding their business. You would need to ask them :-).

Gerv

Gervase Markham

unread,
Mar 24, 2015, 12:21:44 PM3/24/15
to quanx...@gmail.com
You mean we should make a change to Firefox to do this?

How would you define "external", when writing the code?

Gerv

Amr Farouk

unread,
Mar 24, 2015, 12:27:19 PM3/24/15
to Anyin, mozilla-dev-s...@lists.mozilla.org, Ahmed Tharwat MCS, David E. Ross
Hello Anyin,

It's really unfortunate to get such absolute incorrect and prejudiced feedback
I sent the truth inside the requested report and i am ready to submit any required proofs from our Firewall Logs as we reported
I don’t think being a company established 8 years ago with a very successful projects references across the middle east with a direct partnership with a leading world wide companies like Intel, PaloAlto, Juniper and riverbed with a fully compliance history to the import regulations for the security products might submit a report with incorrect information!!!!
i appreciate your revisiting to the report carefully then inquiring for the uncleared issues, studying our feedback and proofs
Then finally to judge either the submitted information is delivering the truth or not !!!
That’s the logic !!
again, i am open for discussion and to respond to any objective inquiries !!


Regards,

Amr Farouk
Managing Director

Mideast Communication Systems
5 Al Sherka Al Portsaidya St, off Asmaa Fahmy St.
Behind Rekaba Idareya Building, 11341
Heliopolis. Cairo, Egypt
Mobile: +2 (0122) 3929889
Office (Tel): +2 (02) 2290 9326
Office (Fax):+2 (02) 2415 3565
Email: a...@mcsholding.com <mailto:a...@mcsholding.com>
Website: www.mcsholding.com <http://www.mcsholding.com/>
Mideast Communication Systems – Tomorrow’s Solutions Today TM


> On Mar 24, 2015, at 4:35 AM, Anyin <an...@cnnic.cn> wrote:
>
> It's so not ture. I am sure this misuse is not intentional. Actually the
> MCSHolding is contact CNNIC first early in the 2015. After dicussion, we
> signed agreement to issue a 2 weeks intermediate root for testing propose.
>
> And we take action to revoke the intermediate root as soon as we received
> report from Microsoft and Apple, and strongly request MCS to provide sealed
> and signed offcially report(attached).
>
> And I sent the incident report include whole timeline of this case to
> Kathleen intiatively to avoid more harmful result of the misused cert.
>
> So this is absolutely not a intentional issue.
>
> Our Webtrust Audit will start soon in April, we surely will take action to
> improve security management and dicussed with audit team(Ernst & Young) if
> we decide to have external intermediate Root authorization in the future.
>
> CC to Amr from MCS HOLDING.
>
>
> Regards,
> An Yin
>
>
> -----邮件原件-----
> 发件人: dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org
> [mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org] 代表
> David E. Ross
> 发送时间: 2015年3月24日 10:23
> 收件人: mozilla-dev-s...@lists.mozilla.org
> 主题: Re: Consequences of mis-issuance under CNNIC
>
> On 3/23/2015 5:59 PM, Peter Kurrasch wrote:
>> Hi Richard,
>>
>> Is the proposal to limit CNNIC roots to only .cn domains or would others
> be allowed?
>>
>> I'm curious to know what CNNIC's perspective is on this proposal, so will
> a representative be replying in this forum?
>>
>> Thanks.
>>
>> Original Message
>> From: Richard Barnes
>> Sent: Monday, March 23, 2015 5:48 PM
>> To: mozilla-dev-s...@lists.mozilla.org
>> Subject: Consequences of mis-issuance under CNNIC
>>
>> 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-c
>> ertificate-security.html
>> [1]
>> https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnn
>> ic-intermediate-certificate/
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
> What assurance is there that the mis-issued certificates were not
> intentional. The approval of the CNNIC was quite controversial.
> Assertions were made that CNNIC is actually an agent of the Chinese
> military.
>
> --
> David E. Ross
>
> I am sticking with SeaMonkey 2.26.1 until saved passwords can be used when
> autocomplete=off. See
> <https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
> <CCI20150319_00000.jpg><CCF20150319_00000.jpg><B1.pdf><B2.pdf>

Amr Farouk

unread,
Mar 24, 2015, 12:27:39 PM3/24/15
to Anyin, mozilla-dev-s...@lists.mozilla.org, Ahmed Tharwat MCS, David E. Ross
Hello Anyin,
i would like to inform you that i will hold our testing lab for a 2 days to respond to your inquiries
and this will be the only chance for you to audit and to get a more clear picture for our feedback
after two days, the logs and information might be unavailable due to our application testing
I’d rather to get your inquiries within 2 days
Regards,

Amr Farouk
Managing Director

Mideast Communication Systems
5 Al Sherka Al Portsaidya St, off Asmaa Fahmy St.
Behind Rekaba Idareya Building, 11341
Heliopolis. Cairo, Egypt
Mobile: +2 (0122) 3929889
Office (Tel): +2 (02) 2290 9326
Office (Fax):+2 (02) 2415 3565
Email: a...@mcsholding.com <mailto:a...@mcsholding.com>
Website: www.mcsholding.com <http://www.mcsholding.com/>
Mideast Communication Systems – Tomorrow’s Solutions Today TM


>> [mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org <mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org>] 代表
>> David E. Ross
>> 发送时间: 2015年3月24日 10:23
>> 收件人: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
>> 主题: Re: Consequences of mis-issuance under CNNIC
>>
>> On 3/23/2015 5:59 PM, Peter Kurrasch wrote:
>>> Hi Richard,
>>>
>>> Is the proposal to limit CNNIC roots to only .cn domains or would others
>> be allowed?
>>>
>>> I'm curious to know what CNNIC's perspective is on this proposal, so will
>> a representative be replying in this forum?
>>>
>>> Thanks.
>>>
>>> Original Message
>>> From: Richard Barnes
>>> Sent: Monday, March 23, 2015 5:48 PM
>>> To: mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org>
>>> http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-c <http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-c>
>>> ertificate-security.html
>>> [1]
>>> https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnn
>>> ic-intermediate-certificate/
>>> _______________________________________________
>>> dev-security-policy mailing list
>>> dev-secur...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-security-policy
>>>
>>
>> What assurance is there that the mis-issued certificates were not
>> intentional. The approval of the CNNIC was quite controversial.
>> Assertions were made that CNNIC is actually an agent of the Chinese
>> military.
>>
>> --
>> David E. Ross
>>
>> I am sticking with SeaMonkey 2.26.1 until saved passwords can be used when
>> autocomplete=off. See
>> <https://bugzilla.mozilla.org/show_bug.cgi?id=433238 <https://bugzilla.mozilla.org/show_bug.cgi?id=433238>>.
>> _______________________________________________
>> dev-security-policy mailing list
>> dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>

Anyin

unread,
Mar 24, 2015, 12:28:57 PM3/24/15
to David E. Ross, mozilla-dev-s...@lists.mozilla.org, Amr Farouk
It's so not ture. I am sure this misuse is not intentional. Actually the
MCSHolding is contact CNNIC first early in the 2015. After dicussion, we
signed agreement to issue a 2 weeks intermediate root for testing propose.

And we take action to revoke the intermediate root as soon as we received
report from Microsoft and Apple, and strongly request MCS to provide sealed
and signed offcially report(attached).

And I sent the incident report include whole timeline of this case to
Kathleen intiatively to avoid more harmful result of the misused cert.

So this is absolutely not a intentional issue.

Our Webtrust Audit will start soon in April, we surely will take action to
improve security management and dicussed with audit team(Ernst & Young) if
we decide to have external intermediate Root authorization in the future.

CC to Amr from MCS HOLDING.


Regards,
An Yin


-----邮件原件-----
发件人: dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org] 代表
David E. Ross
发送时间: 2015年3月24日 10:23
收件人: mozilla-dev-s...@lists.mozilla.org
主题: Re: Consequences of mis-issuance under CNNIC

On 3/23/2015 5:59 PM, Peter Kurrasch wrote:
> Hi Richard,
>
> Is the proposal to limit CNNIC roots to only .cn domains or would others
be allowed?
>
> I'm curious to know what CNNIC's perspective is on this proposal, so will
a representative be replying in this forum?
>
> Thanks.
>
> Original Message
> From: Richard Barnes
> Sent: Monday, March 23, 2015 5:48 PM
> To: mozilla-dev-s...@lists.mozilla.org
> ertificate-security.html
> [1]
> https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnn
> ic-intermediate-certificate/
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

What assurance is there that the mis-issued certificates were not
intentional. The approval of the CNNIC was quite controversial.
Assertions were made that CNNIC is actually an agent of the Chinese
military.

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can be used when
autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Anyin

unread,
Mar 24, 2015, 12:28:58 PM3/24/15
to Peter Bowen, Richard Barnes, mozilla-dev-s...@lists.mozilla.org
Regarding Peter's questions,

- What response has their been from CNNIC on this issue? How do they explain issuing a subordinate CA certificate with a private key not being on a HSM meeting the Baseline Requirements?
We informed MCS Holding provide an official report(attached) for this issue and revoked the intermediate root ASAP. I already send timeline and report of this incident to Kathleen.
We issued this intermediate root for 2 weeks with testing proposal, we should constrain name constrain to the Sub CA as we already did constrain in EKU. At this question ,we need find a way to confirm how the private generated from HSMs or not.

- How many other CA certs has CNNIC issued which are not stored on HSMs?
This is the first time we signed an external intermediate root. The current sub-CA(CNNIC SSL) is operated by CNNIC own and the private key is generate and stored in the HSMs.

Regards,

An Yin
CA Product Manager
---------------------------------------------------
= =Profession • Responsibility • Service= =

China Internet Network Information Center (CNNIC)
Tel: (8610)-58812432
mobile:13683527697
Fax: (8610)-58812666-168
Web: http://www.cnnic.cn
Add: 4 South 4th Street, Zhongguancun, Haidian district, 100190 Beijing, China
POB: Beijing 349, Branch 6
---------------------------------------------------
-----邮件原件-----
发件人: dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org [mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org] 代表 Peter Bowen
发送时间: 2015年3月24日 8:00
收件人: Richard Barnes
抄送: mozilla-dev-s...@lists.mozilla.org
主题: Re: Consequences of mis-issuance under CNNIC

On Mon, Mar 23, 2015 at 3:47 PM, Richard Barnes <rba...@mozilla.com> wrote:
> 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.

Is there any data on this intermediate?

- Was it publicly disclosed as per Mozilla's unconstrained subordinate policy?

- Was it issued since their latest complete audit period ended and, if not, did their auditor flag it?

- What response has their been from CNNIC on this issue? How do they explain issuing a subordinate CA certificate with a private key not being on a HSM meeting the Baseline Requirements?

- How many other CA certs has CNNIC issued which are not stored on HSMs?

Kai Engert

unread,
Mar 24, 2015, 1:45:11 PM3/24/15
to Richard Barnes, mozilla-dev-s...@lists.mozilla.org
On Mon, 2015-03-23 at 17:47 -0500, Richard Barnes wrote:
> 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.

The blog posts say that the intermediate was used in a MITM device.

In February 2012, a CA communication was posted to this list, which
contained the following statements:

> Subordinate CAs chaining to CAs in Mozilla’s root program cannot be used for
> MITM or “traffic management” of domain names or IPs that the certificate holder
> does not legitimately own or control, regardless of whether it is in a closed
> and controlled environment or not.
> ...
> As a CA in Mozilla’s root program you are ultimately responsible for
> certificates issued by you and any intermediate CAs that chain up to your
> roots. After April 27, 2012, if it is found that a subordinate CA is being
> used for MITM, we will take action to mitigate, including and up to removing
> the corresponding root certificate. Based on Mozilla’s assessment, we may
> also remove any of your other root certificates, and root certificates from
> other organizations that cross-sign your certificates.

(cited from https://groups.google.com/forum/#!
topic/mozilla.dev.security.policy/6CX23NVaUvY )

When the above communication was sent in the past, I had hoped that any
future incident, where an intermediate gets loaded into a MITM device,
would have more serious consequences for the CA than simply being
constrained to a TLD.

Kai






Charles Reiss

unread,
Mar 24, 2015, 2:13:05 PM3/24/15
to mozilla-dev-s...@lists.mozilla.org
On 03/23/15 22:47, 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

Can Mozilla consider more serious measures like also distrusting all CNNIC
certificates after a given date?

In light of CNNIC's apparent lack of monitoring or auditing of this subCA, CNNIC
should have anticipated that certs issued by this subCA would be substantially
noncompliant with the BRs and Mozilla's policy -- especially since they require
much more than domain validation. In addition, the subCA itself seems an
unambiguous violation of Mozilla's inclusion policy ("MUST disclose this
information before any such subordinate CA is allowed to issue certificates").
Mozilla should make clear that such recklessness will ultimately result in CAs
being removed from Mozilla's root program.


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

Daniel Micay

unread,
Mar 24, 2015, 2:39:25 PM3/24/15
to dev-secur...@lists.mozilla.org
This is a great idea. CAs are not taking the policies seriously because
it has been shown that there are no consequences to breaking them. The
potential breakage has been the excuse in the past, but that is only a
reason to continue trusting *existing* certificates.

They should no longer be trusted for any new certificates and should
have to re-apply once they've made *provable* changes to prevent this
from happening again. Implementing Certificate Transparency would be a
step towards regaining trust down the road. They need to prove that this
isn't happening anymore if they expect to be trusted again.

signature.asc

Daniel Micay

unread,
Mar 24, 2015, 3:39:01 PM3/24/15
to dev-secur...@lists.mozilla.org
> Technically, this is true. I just find it odd that the offending
> certificate suggests a relationship with a non-Chinese market, while
> at the same time, Richard's data only shows the top gTLDs and various
> China-related TLDs.

Why would the Chinese military directly implicate China for a
certificate issued to perform MITM attacks?

It wouldn't make sense. They're obviously going to make it look like it
was some company a long way away with no ties to them. Perhaps they even
sold some real products to make the business look legitimate. This is
how the world works in 2015.

If CNNIC expects to be trusted again, they have to prove that they're
not doing this on a regular basis. They should have to re-apply to the
trust store once they've implemented CT so the claim that they're not
simply being used as a tool for the Chinese military can be disproved.

signature.asc

Ryan Sleevi

unread,
Mar 24, 2015, 5:16:43 PM3/24/15
to Richard Barnes, mozilla-dev-s...@lists.mozilla.org
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

Ryan Sleevi

unread,
Mar 24, 2015, 5:18:12 PM3/24/15
to Richard Barnes, mozilla-dev-s...@lists.mozilla.org

dia...@gmail.com

unread,
Mar 24, 2015, 5:55:12 PM3/24/15
to mozilla-dev-s...@lists.mozilla.org
Absolutely agreed. There is ample evidence that CNNIC has not upheld their responsibilities in Mozilla's Certificate Inclusion Policy. Can someone please file a bug to remove CNNIC as a trusted root CA?

-Daniel

Peter Bowen

unread,
Mar 24, 2015, 6:27:25 PM3/24/15
to Anyin, mozilla-dev-s...@lists.mozilla.org, Richard Barnes
Anyin,

It seems that the mailing list strips attachments. I copied the ones
you attached to this message a shared location. They are at:

https://pzb-public-files.s3-us-west-2.amazonaws.com/B1.pdf
https://pzb-public-files.s3-us-west-2.amazonaws.com/B2.pdf

Thanks,
Peter

Kathleen Wilson

unread,
Mar 25, 2015, 1:13:25 PM3/25/15
to mozilla-dev-s...@lists.mozilla.org
All,

I appreciate your thoughtful and constructive feedback on this situation.

The suggestions regarding the CNNIC root certificates that I've
interpreted from this discussion are as follows. These are listed in no
particular order, and are not necessarily mutually exclusive.

A) Remove both of the CNNIC root certificates from NSS. This would
result in users seeing an over-rideable Untrusted Connection error.
(Error code: sec_error_unknown_issuer)

B) Take away EV treatment (green bar) from the "China Internet Network
Information Center EV Certificates Root" certificate. Note that the
"CNNIC ROOT" certificate is not enabled for EV treatment.

C) Constrain the CNNIC root certificates to certain domains (e.g. .cn
and .china)

D) Suspend inclusion of (i.e. temporarily remove) the CNNIC root
certificates until they have implemented CT, updated their CP/CPS to
resolve the noted issues, updated their systems to enable issuing certs
with name constraints, and have been re-audited.

Did I miss any?

Thanks,
Kathleen












Peter Bowen

unread,
Mar 25, 2015, 1:18:19 PM3/25/15
to Kathleen Wilson, mozilla-dev-s...@lists.mozilla.org
E) Enable existing CNNIC-issued certificates to continue to work but
block new ones. Two possible ways this could be done:

1) Code a cutoff date, and treat any certificate with a not_before
date after the cutoff date as untrusted.

2) Require CNNIC to provide a list of all unexpired issued
certificates, white list those certificates, and treat any others as
untrusted.

This would not penalize those site owners who chose CNNIC but would
indicate that the lack of trust in CNNIC's processes mean that future
certificates are not trusted.

Thanks,
Peter

Ryan Sleevi

unread,
Mar 25, 2015, 1:46:27 PM3/25/15
to Peter Bowen, mozilla-dev-s...@lists.mozilla.org, Kathleen Wilson
On Wed, March 25, 2015 10:18 am, Peter Bowen wrote:
> E) Enable existing CNNIC-issued certificates to continue to work but
> block new ones. Two possible ways this could be done:
>
> 1) Code a cutoff date, and treat any certificate with a not_before
> date after the cutoff date as untrusted.
>
> 2) Require CNNIC to provide a list of all unexpired issued
> certificates, white list those certificates, and treat any others as
> untrusted.
>
> This would not penalize those site owners who chose CNNIC but would
> indicate that the lack of trust in CNNIC's processes mean that future
> certificates are not trusted.

It's worth noting the technical issue with E1 is that you cannot use the
not_before (which is set and signed by the CA) if you do not trust the CA.

E2 differs, in that it acts as an external counter-party (much like, say,
Certificate Transparency does), and thus does not rely on the CA.

That is, in a hypothetical world where E1 is pursued (for any CA), the CA
can simply backdate the certificate. They'd be non-compliant with the
Baseline Requirements, presumably, but that is somewhat how we got here in
the first place.

So purely on a technical level, E2 seems to be the only viable option of
the E options.

Gervase Markham

unread,
Mar 25, 2015, 3:21:31 PM3/25/15
to ryan-mozde...@sleevi.com, Peter Bowen, Kathleen Wilson
On 25/03/15 17:45, Ryan Sleevi wrote:
> That is, in a hypothetical world where E1 is pursued (for any CA), the CA
> can simply backdate the certificate. They'd be non-compliant with the
> Baseline Requirements, presumably, but that is somewhat how we got here in
> the first place.
>
> So purely on a technical level, E2 seems to be the only viable option of
> the E options.

Not necessarily. In this hypothetical case, Mozilla could state that any
evidence of cert backdating (verified out of band by IP scans) would
lead to immediate root removal; the CAs customers (who would then have
to replace all certs on an accelerated schedule) might then have cause
for action against them for deliberately triggering such an event. This
might prevent the CA from taking that action.

Just throwing thoughts around...

Gerv

Peter Bowen

unread,
Mar 25, 2015, 3:40:51 PM3/25/15
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, ryan-mozde...@sleevi.com, Kathleen Wilson
On Wed, Mar 25, 2015 at 12:20 PM, Gervase Markham <ge...@mozilla.org> wrote:
> On 25/03/15 17:45, Ryan Sleevi wrote:
>> That is, in a hypothetical world where E1 is pursued (for any CA), the CA
>> can simply backdate the certificate. They'd be non-compliant with the
>> Baseline Requirements, presumably, but that is somewhat how we got here in
>> the first place.
>>
>> So purely on a technical level, E2 seems to be the only viable option of
>> the E options.
>
> Not necessarily. In this hypothetical case, Mozilla could state that any
> evidence of cert backdating (verified out of band by IP scans) would
> lead to immediate root removal; the CAs customers (who would then have
> to replace all certs on an accelerated schedule) might then have cause
> for action against them for deliberately triggering such an event. This
> might prevent the CA from taking that action.

Based on the certificates Google has run across in the crawls (and
therefore put in the CT logs), there are 219 current unexpired CNNIC
certificates, each with a 128-bit serial number. Some of them look
random, some are highly sequential. Uncompressed this is about 4k of
data, which is fairly sizable when multiplied millions of times.

Maybe a compromise could be to disclose all existing certs (possibly
allowing the browsers to withhold certain details, such as specific
subjects). Then any certs that show up with dates before the
disclosure date would be considered backdated and trigger the
immediate removal.

I would hate to cause customers who made a good faith decision to use
a CA be penalized for actions they had no control over.

Thanks,
Peter

Daniel Micay

unread,
Mar 25, 2015, 4:32:53 PM3/25/15
to dev-secur...@lists.mozilla.org
> B) Take away EV treatment (green bar) from the "China Internet Network
> Information Center EV Certificates Root" certificate. Note that the
> "CNNIC ROOT" certificate is not enabled for EV treatment.

The lock indicating a secure connection can be taken away completely,
while still leaving authenticated encryption in-place. I mentioned the
EV bar because Chromium took it away for lack of CT.

I think removal would be better, but if removal isn't a viable option
due to breakage then indicating that the connections aren't secure is a
solid step forward. It won't break anything but is still a meaningful
consequence for breaking the policies and informs users - not as well as
a scary warning page saying the cert isn't trusted, but much better than
doing nothing.

signature.asc

Peter Bowen

unread,
Mar 25, 2015, 7:53:03 PM3/25/15
to Daniel Micay, dev-secur...@lists.mozilla.org
So, combining parts from this thread and the forked thread, the
following could be done in combination, with minimal impact to
existing customers:

1) Remove EV treatment for sites with CNNIC certs - only optics,
probably fairly easy for browsers

2) Remove "Secure" UI for sites with CNNIC certs - still only optics,
but probably harder for browsers
- Still treat as secure in networking code, allowing HSTS and secure
cookies to work for the sites

3) Name constrain to existing known issued TLDs - if browser has
support for external name constraints, probably not that hard, and it
provides some protection against unknown certs being out there.

4) Treat certificates issued by CNNIC that have a not_before date
after a certain point in time as untrusted - unknown complexity
- The error for certificates after date X could be the same as unknown
CA or could be the same as revoked cert

5) Ensure that CNNIC is not back dating by requiring disclosure of all
unexpired certs and publishing cert details (at least issuer, serial
number, certificate hash). - not a technical change

6) Fully revoke trust if backdating or undisclosed certs are discovered

7) Allow CNNIC to reapply for admission to the trust store once they
meet the requirements (Ryan clearly documented that they don't today).
If the call is made to remove trust, implementation of removal should
not be blocked on determining specific additional requirements for
re-admission, if any.


I think it is very important to not penalize customers for a bad
decision by their vendor, so option A from Kathleen's list is right
out in my opinion.

Thanks,
Peter

Peter Kurrasch

unread,
Mar 25, 2015, 9:25:14 PM3/25/15
to Peter Bowen, Daniel Micay, dev-secur...@lists.mozilla.org
‎Someone correct me if I'm wrong, but my understanding of the Superfish debacle is that sites that have EV certs would get the green bar treatment on other devices but not on the Lenovo devices where Superfish was installed. The implication, then, is that the green bar provides no improvement in security since apparently nobody noticed it wasn't there.

That being the case, if there is little security benefit to having the green bar to begin with then taking it away seems...feckless?

Besides, while CNNIC clearly made mistakes they aren't the ones who generated a google.com cert. Seems to me some responsibility should be borne by the folks at MCS Holdings, too.


  Original Message  
From: Peter Bowen
Sent: Wednesday, March 25, 2015 6:53 PM‎

Peter Bowen

unread,
Mar 25, 2015, 9:26:31 PM3/25/15
to Peter Kurrasch, Daniel Micay, dev-secur...@lists.mozilla.org
On Wed, Mar 25, 2015 at 6:24 PM, Peter Kurrasch <fhw...@gmail.com> wrote:
> ‎Someone correct me if I'm wrong, but my understanding of the Superfish debacle is that sites that have EV certs would get the green bar treatment on other devices but not on the Lenovo devices where Superfish was installed. The implication, then, is that the green bar provides no improvement in security since apparently nobody noticed it wasn't there.
>
> That being the case, if there is little security benefit to having the green bar to begin with then taking it away seems...feckless?
>
> Besides, while CNNIC clearly made mistakes they aren't the ones who generated a google.com cert. Seems to me some responsibility should be borne by the folks at MCS Holdings, too.

The MCS holding certificate was already revoked. What more do you
want from them?

Peter Kurrasch

unread,
Mar 25, 2015, 10:52:31 PM3/25/15
to Peter Bowen, Daniel Micay, dev-secur...@lists.mozilla.org
MCS wants to issue their own certs eventually but they are clearly not up to that task--not right now at least.‎ The question I think the security community should consider is how MCS might be able to demonstrate they have the right level of knowledge, experience, and maturity that warrants trust in the certs they issue. Has trust been irretrievably damaged?

I'm not suggesting I have a firm answer in mind, but I am saying that while we're focusing on CNNIC it doesn't seem right that the actual perpetrator suffers no consequence. 


  Original Message  
From: Peter Bowen
Sent: Wednesday, March 25, 2015 8:26 PM
To: Peter Kurrasch
Cc: Daniel Micay; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Consequences of mis-issuance under CNNIC

Ryan Sleevi

unread,
Mar 25, 2015, 11:22:55 PM3/25/15
to Peter Kurrasch, Daniel Micay, dev-secur...@lists.mozilla.org, Peter Bowen
On Wed, March 25, 2015 7:52 pm, Peter Kurrasch wrote:
> I'm not suggesting I have a firm answer in mind, but I am saying that
> while we're focusing on CNNIC it doesn't seem right that the actual
> perpetrator suffers no consequence. 

Peter,

Hopefully my first reply to Kathleen's message has demonstrated sufficient
evidence that CNNIC has, independent of any actions MCS took, violated the
BRs in several real, meaningful, and significant ways.

That is, even if MCS Holdings had never placed such a certificate on a
MITM device, the very act of giving MCS Holdings a certificate, and the
manner in which it was done, was itself an action that failed to uphold
and abide by the Baseline Requirements and CNNIC's CPS.

That MCS Holdings used their certificate in a way that was non-compliant
with the BRs is certainly unfortunate, but in doing so, it brought to
light the even more serious seeming non-compliance of CNNIC.

I think it's reasonable to first question what steps should be taken to
preserve or restore trust, before discussion of how to avoid and/or
mitigate such situations in the future.

But let's be clear: while MCS Holdings violated their agreements
(according to CNNIC), which, per Mozilla policy, reflects upon and is
ultimately the responsibility of CNNIC, CNNIC independently appears to
have violated even more of the Baseline Requirements, and has done so
wholly independently of MCS's actions.

Daniel Micay

unread,
Mar 25, 2015, 11:59:05 PM3/25/15
to Peter Kurrasch, Peter Bowen, dev-secur...@lists.mozilla.org
On 25/03/15 10:52 PM, Peter Kurrasch wrote:
> MCS wants to issue their own certs eventually but they are clearly not up to that task--not right now at least.‎ The question I think the security community should consider is how MCS might be able to demonstrate they have the right level of knowledge, experience, and maturity that warrants trust in the certs they issue. Has trust been irretrievably damaged?
>
> I'm not suggesting I have a firm answer in mind, but I am saying that while we're focusing on CNNIC it doesn't seem right that the actual perpetrator suffers no consequence.

CNNIC is an "actual perpetrator" too. They directly violated a dozen
rules in the CA policy. I'd expect that they knew the certificate was
being used for MITM attacks anyway... the alternative of them handing it
out without knowing the purpose isn't any less frightening.

MCS is free to implement Certificate Transparent, start releasing all of
their audit reports in full, including ones they fail and they could
open-source their infrastructure's code to prove that it's high quality
and enforces the correct constraints. I'm not sure why they'd be a good
candidate even after all of that when there are plenty of others with no
history of black hat behavior.

signature.asc

Anyin

unread,
Mar 26, 2015, 5:03:34 AM3/26/15