Consequences of mis-issuance under CNNIC

[Richard Barnes]

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]

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]

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]

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]

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]

On Mon, Mar 23, 2015 at 5:50 PM, Kathleen Wilson <kwi...@mozilla.com> wrote:
> 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

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

* 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]

* 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]

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]

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]

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]

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]

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]

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]

* 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]

* 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]

* 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]

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]

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]

You mean we should make a change to Firefox to do this?

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

Gerv

[Amr Farouk]

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]

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]

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]

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]

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]

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]

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.

[Daniel Micay]

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

[Ryan Sleevi]

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]

[dia...@gmail.com]

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]

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]

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]

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]

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]

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]

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]

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

[Peter Bowen]

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]

‎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]

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]

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]

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]

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.

[Anyin]

Regarding this Incident,



1, We prompt to response to Microsoft and Apple, and actively send incident
report and CRL to Mozilla ASAP. We request MCS to take steps do more
investigate. Quoting MCS report as following,

“ MCS had received the Sub-ordinate certificate from CNNIC on mentioned
date and started the test on same day inside MCS lab which is a protected

environment, MCS had assured to store the private key in a FIPS compliant
device (Firewall), to run the test which had started with no incidents on

Thursday, and for the sack of unintentional action the Firewall had an
active policy to act as SSL forward proxy with an automatic generation for a

certificates for browsed domains on the internet, which had been taken place
on a weekend time (Friday, and Saturday) during unintentional use from one

of the IT Engineers for a browsing the internet using Google Chrome which
had reported a miss-use at Google’s End.”

MCS confirms that the reported issue is a human mistake that took place
unintentionally through a single PC inside MCS Lab which had been

dedicated for testing purposes. Quoting google spokesman, confirms: "We have
no indication of abuse, and we are not suggesting that people

change passwords or take other action". Claims by some public reports are
inconsistent with statement by Google spokesman for abuse or spying activity
for any traffic:

“Google does not, however, believe the certificates were used for that
purpose”. As stated by Google spokesman.

2, CNNIC request MCS to provide the screenshots and logs of detailed
information of certificate issue, including SSL firewall logs, internet
browsing logs of Google websites browsing records from personal browsers. We
will update to Mozilla forum while we get and analyze the logs.

3, CNNIC are planning to update CA system to add name constrains function.

4, CNNIC will evaluate business security of the external subCA authorized
and management

5, The device MCS used to mis-issuance cert is PaloAlto Firewall, we may
consult more technical details about how it works as a SSL proxy and issue
the cert automatically.



We apply Mozilla do not remove CNNIC root from trust store as this is
absolutely not a intension mis-issuance. CNNIC signed intermediate root for
2 weeks test, MCS signed cert for testing propose in Lab. While they made
mistake, we prompt revoke the intermediate root not led to more harmful
result.



Regards,

An Yin

-----邮件原件-----
发件人: dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnni...@lists.mozilla.org] 代表

Kathleen Wilson
发送时间: 2015年3月26日 1:10
收件人: mozilla-dev-s...@lists.mozilla.org
主题: Re: 答复: Consequences of mis-issuance under CNNIC

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

_______________________________________________

dev-security-policy mailing list

<mailto:dev-secur...@lists.mozilla.org>
dev-secur...@lists.mozilla.org

<https://lists.mozilla.org/listinfo/dev-security-policy>
https://lists.mozilla.org/listinfo/dev-security-policy

[Daniel Micay]

Signing their certificate in the first place was against the policies,
even if they hadn't screwed up. It seems like CNNIC isn't aware of the
policies that they agreed to follow.

What is the excuse for violating all of these policies? All I see
explained in this email is how MCS got caught doing this, and an
expression of regret that it happened. If that story is true at all...
logs are not hard to fake after a few days of delay. It doesn't really
matter though.

Ryan Sleevi spent the time figuring out the precise rules that were
violated, which is reposted from his email here:

[dia...@gmail.com]

I'm very much in favor of Option A.

If a CAs doesn't follow the Baseline Requirements, they don't get included. Simple as that. If we continue to waver on these requirements, we should really rename them to Baseline Guidelines.

The websites that currently chain to CNNIC's roots will have to switch to another CA that actually follows the Requirements. Perhaps a bit stressful for a short period of time, but definitely worth setting the precedent that all root CAs must follow the Requirements if they are to remain in the trust store.

-Daniel

[Charles Reiss]

Although it's rather irrelevant to whether CNNIC has complied with Mozilla's
policies: This device designed to issue certs without verifying domain control.
Does CNNIC not regard this as strong evidence that MCS's agreement was made in
bad faith?

[Matt Palmer]

On Thu, Mar 26, 2015 at 05:02:16PM +0800, Anyin wrote:
> We apply Mozilla do not remove CNNIC root from trust store as this is
> absolutely not a intension mis-issuance.

That it was accidental is, in some ways, *worse*. Intentional mis-issuance
would mean that someone worked to subvert the controls that were in place.
An accidental mis-issuance means that the controls that were asserted to be
in place (and were audited as such) were ineffective.

I'm firmly in the camp of removing CNNIC from the Mozilla trust store. Ryan
did an excellent job of summarising the ways in which CNNIC has breached the
public trust, and there appears to be no indication that CNNIC understands
what a huge deal this is and is taking useful steps to address the core
problems at issue.

Another issue that I haven't seen mentioned is the failure of the auditor to
detect the insufficient controls in place. What degree of ineffectiveness
is required by an auditor before Mozilla considers the firm ineligible for
providing an assurance of BR compliance?

- Matt

[Man Ho (Certizen)]

On 3/27/2015 1:29 AM, Charles Reiss wrote:
> Although it's rather irrelevant to whether CNNIC has complied with Mozilla's
> policies: This device designed to issue certs without verifying domain control.
> Does CNNIC not regard this as strong evidence that MCS's agreement was made in
> bad faith?

Yeah, if this device is designed to issue certificates automatically.
Why does it have this feature? The answer is obviously for traffic
monitoring. But then why Paloalto would develop such problematic feature
which violate security principle? If it is a common feature in Paloalto
firewall (or even other brands of firewalls), I'd believe that many
organizations are doing the same thing. Should firewall vendors or
developers take some responsibilities too?

[Matt Palmer]

I don't see why -- there are legitimate(ish) reasons for wanting to do this,
and within a closed ecosystem, where everyone is OK with it (or, if they're
not OK with it, they'd be fired) there's no reason not to use the device.

The *correct* way to deploy these devices is to generate a local root CA
certificate and install that in the trust store of all devices which use the
network. That is perfectly legitimate, once again, because the owner of the
device gives permission to do so (typically, all devices are owned by the
organisation deploying the appliance).

What *is* a shady practice is what's gone on here -- MCS got a
globally-trusted intermediate CA private key and cert and used that to MitM.
The problem with this is that it allows MCS to intercept and inspect traffic
from devices which have *not* consented to have their traffic so
manipulated.

A root CA which allows such an activity to take place is not, IMO, worthy of
the trust placed in it by the greater public, and therefore I'm in favour of
CNNIC's removal from the Mozilla trust store (preferably with one of the
user-harm-minimisation strategies that others have described).

- Matt

--
English is about as pure as a cribhouse whore. We don't just borrow
words; on occasion, English has pursued other languages down alleyways
to beat them unconscious and rifle their pockets for new vocabulary."
-- James D. Nicoll, resident of rec.arts.sf.written

[Gervase Markham]

On 27/03/15 06:41, Man Ho (Certizen) wrote:
> Yeah, if this device is designed to issue certificates automatically.
> Why does it have this feature? The answer is obviously for traffic
> monitoring. But then why Paloalto would develop such problematic feature
> which violate security principle? If it is a common feature in Paloalto
> firewall (or even other brands of firewalls), I'd believe that many
> organizations are doing the same thing. Should firewall vendors or
> developers take some responsibilities too?

Such a feature can be used without endangering the global PKI by using a
corporation-specific root which is installed on all browsers inside the
enterprise. So there is nothing wrong, by itself, with this feature
existing in firewalls.

Gerv

[Peter Kurrasch]

Perhaps there is a middle ground of remedies. For consideration:

1) Mozilla could refuse to validate any intermediate cert which CNNIC has issued to a subordinate CA. (Note: I'm not sure that's the technically precise term here.) Basically, CNNIC may issue intermediates for itself but those paths going outside their organization would no longer be trusted. The root itself would remain in the trust store.

2) I don't think MCS should be trusted to issue certs no matter who provides them with intermediate auth‎ority. CNNIC should not be permitted to provide that authority but neither should anyone else. MCS fell flat on their faces here by failing to understand the PKI system and by failing to understand the proper configuration of their equipment. Mistakes in configurations are what lead to security breaches so this failure is really quite significant. 


  Original Message  
From: Matt Palmer
Sent: Friday, March 27, 2015 3:51 AM
To: dev-secur...@lists.mozilla.org
Subject: Re:答复: 答复:Consequences of mis-issuance under CNNIC

On Fri, Mar 27, 2015 at 02:41:03PM +0800, Man Ho (Certizen) wrote:
>
> On 3/27/2015 1:29 AM, Charles Reiss wrote:
> > Although it's rather irrelevant to whether CNNIC has complied with Mozilla's
> > policies: This device designed to issue certs without verifying domain control.
> > Does CNNIC not regard this as strong evidence that MCS's agreement was made in
> > bad faith?
>

> Yeah, if this device is designed to issue certificates automatically.
> Why does it have this feature? The answer is obviously for traffic
> monitoring. But then why Paloalto would develop such problematic feature
> which violate security principle? If it is a common feature in Paloalto
> firewall (or even other brands of firewalls), I'd believe that many
> organizations are doing the same thing. Should firewall vendors or
> developers take some responsibilities too?

I don't see why -- there are legitimate(ish) reasons for wanting to do this,
and within a closed ecosystem, where everyone is OK with it (or, if they're
not OK with it, they'd be fired) there's no reason not to use the device.

The *correct* way to deploy these devices is to generate a local root CA
certificate and install that in the trust store of all devices which use the
network. That is perfectly legitimate, once again, because the owner of the
device gives permission to do so (typically, all devices are owned by the
organisation deploying the appliance).

What *is* a shady practice is what's gone on here -- MCS got a
globally-trusted intermediate CA private key and cert and used that to MitM.
The problem with this is that it allows MCS to intercept and inspect traffic
from devices which have *not* consented to have their traffic so
manipulated.

A root CA which allows such an activity to take place is not, IMO, worthy of
the trust placed in it by the greater public, and therefore I'm in favour of
CNNIC's removal from the Mozilla trust store (preferably with one of the
user-harm-minimisation strategies that others have described).

- Matt

--
English is about as pure as a cribhouse whore. We don't just borrow
words; on occasion, English has pursued other languages down alleyways
to beat them unconscious and rifle their pockets for new vocabulary."
-- James D. Nicoll, resident of rec.arts.sf.written

[Matt Palmer]

On Fri, Mar 27, 2015 at 02:09:41PM -0500, Peter Kurrasch wrote:
> Perhaps there is a middle ground of remedies. For consideration:
>
> 1) Mozilla could refuse to validate any intermediate cert which CNNIC has
> issued to a subordinate CA. (Note: I'm not sure that's the technically
> precise term here.) Basically, CNNIC may issue intermediates for itself
> but those paths going outside their organization would no longer be
> trusted. The root itself would remain in the trust store.

That's not something that can be enforced technically; in theory, the
certificate validation code could "whitelist" specified (and pre-arranged)
intermediate CA certificates, but there's nothing that definitively says
"this is an internal intermediate CA certificate" as opposed to "this is an
external intermediate CA certificate", that isn't under the control of the
root CA (which has already demonstrated that it can't be trusted to act in
the public interest).

> 2) I don't think MCS should be trusted to issue certs no matter who
> provides them with intermediate auth‎ority. CNNIC should not be
> permitted to provide that authority but neither should anyone else. MCS
> fell flat on their faces here by failing to understand the PKI system and
> by failing to understand the proper configuration of their equipment.
> Mistakes in configurations are what lead to security breaches so this
> failure is really quite significant. 

MCS Holdings is (to my knowledge) a corporate entity. However, the
corporate entity wasn't the one who screwed up, so to ban the corporate
entity from ever being a CA is pointless. I doubt that it would be possible
to identify everyone at MCS who was in some way responsible and state that
any organisation they are a part of in the future could not be a CA.

Focusing on MCS is the wrong approach. CNNIC are the ones who failed to
uphold the trust placed in them, and quite blatantly disregarded their own
audited policies in issuing the intermediate CA certificate. They must be
held to account for their actions.

- Matt

--
<Igloo> I remember going to my first tutorial in room 404. I was most upset
when I found it.

[Gervase Markham]

On 27/03/15 19:09, Peter Kurrasch wrote:
> 1) Mozilla could refuse to validate any intermediate cert which CNNIC
> has issued to a subordinate CA. (Note: I'm not sure that's the
> technically precise term here.) Basically, CNNIC may issue
> intermediates for itself but those paths going outside their
> organization would no longer be trusted. The root itself would remain
> in the trust store.

How do you suggest that this is determined in software?

> 2) I don't think MCS should be trusted to issue certs no matter who
> provides them with intermediate auth‎ority.

Leaving aside my opinion on that question, again, how can you determine
in software that a certificate has been issued by this particular
company called MCS?

Gerv

[Richard Barnes]

After some further thought on this issue, I would like to propose the
following course of action:

1. Remove the CNNIC root certificates
2. (possibly) Temporarily add the CNNIC intermediate certificates

Removing the CNNIC root certificates reflects the seriousness of the breach
of trust that CNNIC has incurred by deliberately issuing an intermediate
certificate in violation of its CPS, the BRs, and Mozilla policies. CNNIC
is of course free to re-apply to the root program, so this removal is not
necessarily permanent

Adding the intermediates would allow CNNIC to continue to issue end-entity
certificates, and not penalize site owners immediately (as Peter notes).
However, it would prevent the acceptance of other intermediates, since the
improper issuance of intermediates is the immediate issue here.

Further reasoning for this course of action follows.


# Recap of the options

Summarizing the options expressed by Kathleen and Peter earlier:

A) Remove both CNNIC root certificates

B) Remove EV treatment for the CNNIC EV root

C) Name-constrain the CNNIC roots

D) Remove both CNNIC roots temporarily, with conditions for re-acceptance

E) Only accept certificates already issued by CNNIC (not future ones)

To these, I would like to add:

F) Remove both CNNIC roots, but temporarily add the CNNIC intermediates

This latter option would continue to allow CNNIC to issue end-entity
certicates, but not to issue further intermediates.


# My Analysis

The underlying issue here is that CNNIC, apparently deliberately, violated
the BRs, Mozilla policy, and its own CPS by issuing an intermediate without
proper vetting. For me, the most troubling aspect of this is that CNNIC
violated their own CPS -- the covenant they make with the community for how
they will behave, and the basis for all the decisions that we make about
whether to trust them.

The basic need here is thus to re-establish the community's confidence that
CNNIC will adhere to their obligations under their CPS, the BRs, and
Mozilla policy. As long as there is uncertainty on this point, it is
inappropriate for us to grant the unbounded trust implied by inclusion in
the root program, so there is at least a need place bounds on how CNNIC is
trusted. Ultimately, if CNNIC cannot assure the community that they will
adhere to their obligations, then they should not be in the root program.


## Not (B), (C), or (E)

Options (B) and (C) are only loosely related to the concerns about CNNIC's
behavior. While in general I'm enthusiastic about constraining CAs (see
the "Name Constraints" thread), in the context of this discussion, it would
be better to focus on the issues raised by CNNIC's incorrect decision to
issue an intermediate certificate to MCS Holdings.

Option (E) is technically infeasible, for the reasons that Ryan noted.


## Between (A), (D), and (F)

In brief, my preference order is (A) > (F) > (D)

Given how fundamental a violation it is for a CA to deliberately violate
its obligations, I think Mozilla would be within its rights to remove the
CNNIC roots (A). The Mozilla Certificate Policy says that roots may be
removed as a result of "ongoing or egregious" violations. Given the
multiple violations noted in Ryan's earlier message, I feel comfortable
labeling this incident "egregious", in the sense of "unusually serious".

The only difference between (A) and (D) is that (D) establishes conditions
up front for CNNIC's readmission. Even in case (A), CNNIC may re-apply,
and they will have to go through the normal process for community approval.
I am hesitant to commit to conditions for re-admission up front, in case
any new issues arise in the interim. Any conditions that might be stated
in case (D) could also be stated in case (A) as part of the re-application
process.

As a compromise, however, I would be willing to add the CNNIC intermediates
to the Mozilla root list (F). (Ideally, with an additional path length
constraint, set to zero.) This would enable CNNIC to continue issuing
end-entity certificates, without the possibility of adding intermediates.
Since CNNIC's policy regarding intermediates is the immediate issue here,
this seems like a reasonable compromise. However, these intermediate
certificates should not be admitted indefinitely. Rather, we should plan
to remove them after a fixed time (say 6 months) or after CNNIC's
re-application is resolved, whichever comes first.

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

[Gervase Markham]

On 30/03/15 16:34, Richard Barnes wrote:
> Adding the intermediates would allow CNNIC to continue to issue end-entity
> certificates, and not penalize site owners immediately (as Peter notes).
> However, it would prevent the acceptance of other intermediates, since the
> improper issuance of intermediates is the immediate issue here.

This is only true if we are aware of all existing in-use CNNIC
intermediates, and that they all have an explit pathLength constraint of
0. A higher constraint, or none at all, would allow CNNIC to issue
further intermediates off the whitelisted intermediates.

> As a compromise, however, I would be willing to add the CNNIC intermediates
> to the Mozilla root list (F). (Ideally, with an additional path length
> constraint, set to zero.)

Ah, I see you have covered this. If the CNNIC intermediates do not have
such a constraint, we could add one artificially, but AIUI that would
require custom code.

> Since CNNIC's policy regarding intermediates is the immediate issue here,
> this seems like a reasonable compromise. However, these intermediate
> certificates should not be admitted indefinitely. Rather, we should plan
> to remove them after a fixed time (say 6 months) or after CNNIC's
> re-application is resolved, whichever comes first.

If CNNIC are required to re-apply from scratch, I believe the current
length of the application queue is longer than six months. That would
mean that it's likely the time limit you set would expire before the
determination of their re-inclusion.

Gerv

[David Keeler]

On 03/30/2015 09:23 AM, Gervase Markham wrote:
> On 30/03/15 16:34, Richard Barnes wrote:

>> Adding the intermediates would allow CNNIC to continue to issue end-entity
>> certificates, and not penalize site owners immediately (as Peter notes).
>> However, it would prevent the acceptance of other intermediates, since the
>> improper issuance of intermediates is the immediate issue here.
>

> This is only true if we are aware of all existing in-use CNNIC
> intermediates, and that they all have an explit pathLength constraint of
> 0. A higher constraint, or none at all, would allow CNNIC to issue
> further intermediates off the whitelisted intermediates.
>

>> As a compromise, however, I would be willing to add the CNNIC intermediates
>> to the Mozilla root list (F). (Ideally, with an additional path length
>> constraint, set to zero.)
>

> Ah, I see you have covered this. If the CNNIC intermediates do not have
> such a constraint, we could add one artificially, but AIUI that would
> require custom code.

Since we never have to verify signatures on trust anchors, we can make
modifications to the information they contain without causing
verification failures. In this case, if we add those intermediates as
trust anchors, we can modify the basicConstraints extensions to each
have a pathLenConstraint of 0. This shouldn't require custom user-agent
code.

>> Since CNNIC's policy regarding intermediates is the immediate issue here,
>> this seems like a reasonable compromise. However, these intermediate
>> certificates should not be admitted indefinitely. Rather, we should plan
>> to remove them after a fixed time (say 6 months) or after CNNIC's
>> re-application is resolved, whichever comes first.
>

> If CNNIC are required to re-apply from scratch, I believe the current
> length of the application queue is longer than six months. That would
> mean that it's likely the time limit you set would expire before the
> determination of their re-inclusion.

I imagine the actual length of time to keep the intermediates around is
up for debate. In any case, it would still give sites time to move to a
different CA. If we remove the CNNIC root (which I think we should),
this sounds like a good trade-off between protecting our users and the
compatibility concerns of root-removal.

Cheers,
David

[jjo...@mozilla.com]

On Monday, March 30, 2015 at 8:34:47 AM UTC-7, Richard Barnes wrote:

> As a compromise, however, I would be willing to add the CNNIC intermediates

> to the Mozilla root list (F). [...] Rather, we should plan

> to remove them after a fixed time (say 6 months) or after CNNIC's
> re-application is resolved, whichever comes first.

I believe Richard's compromise approach is well-founded. If 6 months is too short, as Gerv pointed out, perhaps we plan for that fixed period to be something like ( $average_reapplication_time * 125% ) to account for minor snags.

It's likely to be in the applicant's best interests to commit to a timeframe up front, even if it has a fudge factor, rather than leave it indefinite.

[Peter Bowen]

On Mon, Mar 30, 2015 at 2:22 PM, <jjo...@mozilla.com> wrote:
> On Monday, March 30, 2015 at 8:34:47 AM UTC-7, Richard Barnes wrote:
>

>> As a compromise, however, I would be willing to add the CNNIC intermediates

>> to the Mozilla root list (F). [...] Rather, we should plan

>> to remove them after a fixed time (say 6 months) or after CNNIC's
>> re-application is resolved, whichever comes first.
>

> I believe Richard's compromise approach is well-founded. If 6 months is too short, as Gerv pointed out, perhaps we plan for that fixed period to be something like ( $average_reapplication_time * 125% ) to account for minor snags.
>
> It's likely to be in the applicant's best interests to commit to a timeframe up front, even if it has a fudge factor, rather than leave it indefinite.

Can they reapply with the same intermediate CAs? If not, then could
it be that they agree to move to new intermediates and cease issuing
from the current ones, to lock the list of issued certs?

[Matt Palmer]

On Mon, Mar 30, 2015 at 11:34:40AM -0400, Richard Barnes wrote:
> The underlying issue here is that CNNIC, apparently deliberately, violated
> the BRs, Mozilla policy, and its own CPS by issuing an intermediate without
> proper vetting. For me, the most troubling aspect of this is that CNNIC
> violated their own CPS -- the covenant they make with the community for how
> they will behave, and the basis for all the decisions that we make about
> whether to trust them.

I agree with you wholeheartedly on this point. However, given that CNNIC
felt it appropriate to violate their CPS with regards to an intermediate CA
certificate, I don't see that there's any greater reason to trust their
adherence to their CPS in any other aspect. Thus, I'm not not keen on
allowing them to issue *any* further trusted certificates.

> Option (E) is technically infeasible, for the reasons that Ryan noted.

There were two sub-parts to option (E) -- (1) keep the root, but disallow
further issuance, or (2) obtain a list of issued end-entity certs from CNNIC
and whitelist those. Ryan described how E1 is infeasible, but did state
that E2 was possible (assuming CNNIC cooperation). I assume it would be
some amount of work to implement E2, however. Absent considerations of the cost
of implementation, E2 is the best option I've seen (or thought of) so far.

> As a compromise, however, I would be willing to add the CNNIC intermediates

> to the Mozilla root list (F). (Ideally, with an additional path length

> constraint, set to zero.) This would enable CNNIC to continue issuing
> end-entity certificates, without the possibility of adding intermediates.

> Since CNNIC's policy regarding intermediates is the immediate issue here,
> this seems like a reasonable compromise. However, these intermediate

> certificates should not be admitted indefinitely. Rather, we should plan

> to remove them after a fixed time (say 6 months) or after CNNIC's
> re-application is resolved, whichever comes first.

Time-limited intermediate inclusion could be a workable compromise. It
would give CNNIC an opportunity to communicate with all of the customers who
have been issued certificates derived from their root to advise them that
they will need to seek a new certificate provider in order to maintain a
trusted status after date (X). Whether CNNIC cares enough about its
customers to do that is another matter. Third parties, using CT and/or
SSL census data, could also attempt to raise the issue with those who would
be impacted, however I'm dubious whether that would have any meaningful
effect.

(As a side-note, and taking a leaf from CT's book: TLS should, if it doesn't
already, support the presentation of multiple certificates, and browsers
could start requiring the presentation of multiple certificates to get, to
start with, EV treatment. That would allow browsers to untrust a
misbehaving CA without the massive impact that happens now. Just a
thought.)

- Matt

--
"[Perl] combines all the worst aspects of C and Lisp: a billion different
sublanguages in one monolithic executable. It combines the power of C with
the readability of PostScript."
-- Jamie Zawinski

[Peter Gutmann]

Matt Palmer <mpa...@hezmatt.org> writes:

>However, given that CNNIC felt it appropriate to violate their CPS with
>regards to an intermediate CA certificate, I don't see that there's any
>greater reason to trust their adherence to their CPS in any other aspect.
>Thus, I'm not not keen on allowing them to issue *any* further trusted
>certificates.

So this is now a convenient excuse to kick out CNNIC, after the initial
attempts to not let them in in the first place failed. I've always wondered,
what do people have against CNNIC and Turktrust in particular? Why the
hostility focused on just these two CAs, when there are plenty of others who
have behaved in a far more dubious manner?

Given that other certificate vending machines trusted by Mozilla have done all
manner of bad things (selling certs to phishers and other criminals, selling
certs for things like apple.com to multiple people who asked for them, selling
thousands upon thousands of certs for internal, unqualified, and RFC 1918
domains/addresses, etc), all in violation of the BR, why the hostility
directed at these two?

It seems like every other CA that's been examined in any detail after problems
have cropped up has shown BR compliance failures, and yet it's being used as a
convenient cudgel to beat CNNIC with. They're certificate vending machines
like any others, and from all the information that's been made available, what
CNNIC did seems to be a genuine slip-up that affected one whole person, inside
the organisation that messed up their firewall config/usage, rather than, for
example, supplying certs to Russian organised crime as other vendors have
done.

If you're going to kick out CNNIC because of this BR-compliance issue then an
awful lot of other CAs will need to go as well. If you're going to apply this
"standard" then you need to apply it uniformly, not just to bash a particular
CA you want to get rid of.

More generally, a second informal requirement for being in a browser,
alongside "Don't sell only a small number of certs" (to meet the TB2F criteria
required by browsers if something goes wrong) seems to be "Don't be Chinese or
Arab/Persian/Turkic". I don't know if any
Russian/Byelorussian/Ukrainian/*stani CAs are present in browsers, but I'm
guessing being one of those won't help your case either.

Peter.

[Matt Palmer]

On Tue, Mar 31, 2015 at 02:34:45PM +1300, Peter Gutmann wrote:
> Matt Palmer <mpa...@hezmatt.org> writes:
>
> >However, given that CNNIC felt it appropriate to violate their CPS with
> >regards to an intermediate CA certificate, I don't see that there's any
> >greater reason to trust their adherence to their CPS in any other aspect.
> >Thus, I'm not not keen on allowing them to issue *any* further trusted
> >certificates.
>
> So this is now a convenient excuse to kick out CNNIC, after the initial
> attempts to not let them in in the first place failed. I've always wondered,
> what do people have against CNNIC and Turktrust in particular? Why the
> hostility focused on just these two CAs, when there are plenty of others who
> have behaved in a far more dubious manner?

I wasn't involved in d-s-p when those previous cases were considered,
otherwise I'd have said exactly the same thing about the CAs involved in
those cases, too.

> More generally, a second informal requirement for being in a browser,
> alongside "Don't sell only a small number of certs" (to meet the TB2F criteria
> required by browsers if something goes wrong) seems to be "Don't be Chinese or
> Arab/Persian/Turkic". I don't know if any
> Russian/Byelorussian/Ukrainian/*stani CAs are present in browsers, but I'm
> guessing being one of those won't help your case either.

Or, presumably, Dutch.

- Matt
(Oooh, *good* sigmonster, have a biscuit)

--
"If a politician fixes a problem then he loses it as a campaign issue. But
if he makes the problem worse while heroically fighting against it, then
he's golden."
-- Rex Tincher

[Daniel Micay]

On 30/03/15 09:34 PM, Peter Gutmann wrote:
> Matt Palmer <mpa...@hezmatt.org> writes:
>
>> However, given that CNNIC felt it appropriate to violate their CPS with
>> regards to an intermediate CA certificate, I don't see that there's any
>> greater reason to trust their adherence to their CPS in any other aspect.
>> Thus, I'm not not keen on allowing them to issue *any* further trusted
>> certificates.
>
> So this is now a convenient excuse to kick out CNNIC, after the initial
> attempts to not let them in in the first place failed. I've always wondered,
> what do people have against CNNIC and Turktrust in particular? Why the
> hostility focused on just these two CAs, when there are plenty of others who
> have behaved in a far more dubious manner?

CNNIC is known to have produced and distributed malware for the purpose
of mass surveillance and censorship. Here's just one example:

http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?name=BrowserModifier%3aWin32%2fCNNIC

What are you trying to imply? Empowering an authoritarian government
with the ability to oppress dissent doesn't seem very compatible with
Mozilla's purported values.

> Given that other certificate vending machines trusted by Mozilla have done all
> manner of bad things (selling certs to phishers and other criminals, selling
> certs for things like apple.com to multiple people who asked for them, selling
> thousands upon thousands of certs for internal, unqualified, and RFC 1918
> domains/addresses, etc), all in violation of the BR, why the hostility
> directed at these two?

I'm not aware of other certificate authorities that are black hat
malware vendors, just CNNIC. There are other CAs that are also just an
appendage of governments that do these things, but they don't do within
their organizations as far as we know.

If you have solid evidence that other CAs do this, feel free to present
and I'll be a loud supporter of ripping out their certificates too.

> It seems like every other CA that's been examined in any detail after problems
> have cropped up has shown BR compliance failures, and yet it's being used as a
> convenient cudgel to beat CNNIC with. They're certificate vending machines
> like any others, and from all the information that's been made available, what
> CNNIC did seems to be a genuine slip-up that affected one whole person, inside
> the organisation that messed up their firewall config/usage, rather than, for
> example, supplying certs to Russian organised crime as other vendors have
> done.

If you believe the story they put together after they were caught. It's
hard to believe that they issued this certificate for an inexplicable
"test" in a lab. There's very little in the way of a real explanation in
that email, zero acknowledgement that rules were broken and zero regret
for what they did.

The much simpler, more likely explanantion is that a known black hat
organization is up to their usual tricks. It's likely the usual state
sponsored hacking, made possible by Mozilla.

> If you're going to kick out CNNIC because of this BR-compliance issue then an
> awful lot of other CAs will need to go as well. If you're going to apply this
> "standard" then you need to apply it uniformly, not just to bash a particular
> CA you want to get rid of.

The policies should be enforced across the board. Past negligence in
enforcing the rules isn't an excuse to continue on that path today.

> More generally, a second informal requirement for being in a browser,
> alongside "Don't sell only a small number of certs" (to meet the TB2F criteria
> required by browsers if something goes wrong) seems to be "Don't be Chinese or
> Arab/Persian/Turkic". I don't know if any
> Russian/Byelorussian/Ukrainian/*stani CAs are present in browsers, but I'm
> guessing being one of those won't help your case either.

It was obvious that you were pulling the race/nationality card from the
first paragraph, but I decided to give you the benefit of the doubt.

The people who were most outspoken against the original inclusion of
this certificate were Chinese citizens terrified of this helping their
authoritarian government to crack down on them. It has what CNNIC has
done in the past and continues to do today.

Sorry, but I don't buy into spineless moral relativism. It's not okay to
empower an authoritarian regime with the ability to harm their citizens.
It is what they have done historically, and there's little doubt that
they will continue to do it.

Accusing people who disagree with you on this topic of being racists is
ridiculous. I'm not a racist for applying the same moral standards to
someone regardless of their race, nationality or religion.

For people in China, FOSS is an escape from a world of backdoored,
highly controlled proprietary software. Hard-wiring support for their
government to spy on them into the browser is a betrayal.

[Peter Gutmann]

Daniel Micay <danie...@gmail.com> writes:

>CNNIC is known to have produced and distributed malware for the purpose of
>mass surveillance and censorship.

TeliaSonera aided totalitarian governments, Comodo provided the PrivDog MITM
software, and that's just the first two off the top of my head.

>If you have solid evidence that other CAs do this, feel free to present and
>I'll be a loud supporter of ripping out their certificates too.

We'll start with Comodo then, shall we? [0].

Peter.

[0] Nothing against Comodo, just using them to make a point :-).

[Daniel Micay]

On 30/03/15 10:08 PM, Peter Gutmann wrote:
> Daniel Micay <danie...@gmail.com> writes:
>
>> CNNIC is known to have produced and distributed malware for the purpose of
>> mass surveillance and censorship.
>
> TeliaSonera aided totalitarian governments, Comodo provided the PrivDog MITM
> software, and that's just the first two off the top of my head.

Any CA demonstrating a high level of incompetent or malicious behaviour
should be removed. If you really wanted this, then I doubt you'd be
using whataboutism as a defense against it. In a thread about removing
Comodo, someone else would just point out that CNNIC was not removed for
doing the same thing... it's a nonsensical fallacy.

>> If you have solid evidence that other CAs do this, feel free to present and
>> I'll be a loud supporter of ripping out their certificates too.
>
> We'll start with Comodo then, shall we? [0].

The topic at hand here is CNNIC. You're free to start another thread
about Comodo. If they're shown to have egregiously violated policies as
is the case here, then clearly they should be removed.

The decision about which CAs to include is ultimately a political one,
except when it comes to policy violations. The fact that some of them
are malware outfits is a strong reason to exclude them, but that all
depends on the political views of the people making the call. On the
other hand, choosing not to enforce the industry standard policies is
just cut and dry negligence. If there are known violations and no
response to it, then Mozilla is liable for anything that goes wrong.

[Peter Kurrasch]

Your's is certainly one viewpoint, Daniel. Just the same, there is nothing wrong with more nuanced perspectives.

________________________________________________________________________

From: Daniel Micay <danie...@gmail.com>
Date: Mon Mar 30 2015 21:29:04 GMT-0500 (Central Daylight Time)

[Daniel Micay]

On 30/03/15 10:32 PM, Peter Kurrasch wrote:
> Your's is certainly one viewpoint, Daniel. Just the same, there is
> nothing wrong with more nuanced perspectives.

I'm not sure how allegations of racial bias and hypocrisy with little
basis are a perspective. It's a weak attempt to discredit people making
sound arguments, not another side of the story.

[Daniel Micay]

Anyway, whataboutism isn't very effective even as a fallacious argument
when you're debating with a third party who thinks *everyone* should be
accountable to the same standards.

[Robin Alden]

Peter Gutmann said..

> Daniel Micay <danie...@gmail.com> writes:
>
> >CNNIC is known to have produced and distributed malware
> > for the purpose of mass surveillance and censorship.
>
> TeliaSonera aided totalitarian governments, Comodo provided
> the PrivDog MITM software, and that's just the first two off
> the top of my head.
>

> > If you have solid evidence that other CAs do this, feel
> > free to present and I'll be a loud supporter of ripping
> > out their certificates too.
>
> We'll start with Comodo then, shall we?

Hi Peter,
Your assertion about Comodo is wrong and that blunts your point
instead of helping you make it.

I refer you to my previous statement on Privdog.
https://cabforum.org/pipermail/public/2015-February/005095.html
and Hanno's post to this list
https://www.mail-archive.com/dev-secur...@lists.mozilla.org/msg01
544.html

Robin

[Gervase Markham]

On 31/03/15 02:34, Peter Gutmann wrote:
> So this is now a convenient excuse to kick out CNNIC, after the initial
> attempts to not let them in in the first place failed. I've always wondered,
> what do people have against CNNIC and Turktrust in particular?

I haven't seen anyone in this thread mention TurkTrust in any context
other than as one of the list of CAs which have misissued intermediates,
which includes Trustwave and ANSSI (American and French respectively, if
it matters).

> Given that other certificate vending machines trusted by Mozilla have done all
> manner of bad things (selling certs to phishers and other criminals,

A certificate is proof of identity (or domain ownership), not of
honesty. I'm not aware of any 100% accurate test for honesty that CAs
could deploy even if we asked them to.

> selling
> certs for things like apple.com to multiple people who asked for them,

[citation needed]

> selling
> thousands upon thousands of certs for internal, unqualified, and RFC 1918
> domains/addresses, etc), all in violation of the BR,

Internal names are not currently a BR violation (they will be soon).

> More generally, a second informal requirement for being in a browser,
> alongside "Don't sell only a small number of certs" (to meet the TB2F criteria
> required by browsers if something goes wrong) seems to be "Don't be Chinese or
> Arab/Persian/Turkic".

I have great respect for you as a technologist, but I'm disappointed
that you would make such a serious (implied) accusation without
extremely careful analysis of the facts.

Gerv

[Ralph Holz]

On 03/25/2015 12:54 AM, Erwann Abalea wrote:

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

Thank you - I was waiting for someone to finally say this. This is a bit
like Trustwave - "what, it's an industry practice?"

Ralph

[Ralph Holz]

Best and most substantial summary I have read so far, Ryan. I do
remember the CA communications Kathleen initiated after TrustWave.

Also, CNNIC is saying "it was only a test and we got it wrong and it had
consequences". Not exactly trust-inspiring.

On 03/25/2015 08:17 AM, Ryan Sleevi wrote:

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

[Kurt Roeckx]

On 2015-03-31 03:34, Peter Gutmann wrote:
> More generally, a second informal requirement for being in a browser,
> alongside "Don't sell only a small number of certs" (to meet the TB2F criteria
> required by browsers if something goes wrong)

You seem to be under the impression that the number of issued
certificate is a deciding factor for being too big 2 fail, and then
think it's larger than 10K. That might well be the case, but I think
what you're basing it on is just wrong. The 10K you talk about is 10K
validations (or connections) that saw such a certificate, out of 10G, or
about 1 per million (1 ppm, 0.0001%). It's not about different
certificates. I would also not say that you need more than 1 ppm of
connections to be too big to fail, but rather that 1 ppm is clearly
lower then the threshold.

But like with lots of things, like enforcing 2048 RSA keys, you have to
have a point where you're willing to break things, and I really hope
that that threshold is a few factors higher than the 1 ppm.

> seems to be "Don't be Chinese or
> Arab/Persian/Turkic". I don't know if any
> Russian/Byelorussian/Ukrainian/*stani CAs are present in browsers, but I'm
> guessing being one of those won't help your case either.

I know there are people who don't trust some governments. And there are
some very vocal people on this list and other places that don't trust
the Chinese government. But I haven't seen Mozilla take decisions based
on that.

I think the best thing we can do is make technical changes so that we
don't need to trust those governments. And I think CT is a big step in
that direction.


Kurt

[Daniel Micay]

CT will be worthless if removals don't happen when the policy violations
are detected.

[Richard Barnes]

On Tue, Mar 31, 2015 at 10:26 AM, Kurt Roeckx <ku...@roeckx.be> wrote:

> On 2015-03-31 03:34, Peter Gutmann wrote:
>

>> More generally, a second informal requirement for being in a browser,
>> alongside "Don't sell only a small number of certs" (to meet the TB2F
>> criteria
>> required by browsers if something goes wrong)
>>
>

> You seem to be under the impression that the number of issued certificate
> is a deciding factor for being too big 2 fail, and then think it's larger
> than 10K. That might well be the case, but I think what you're basing it
> on is just wrong. The 10K you talk about is 10K validations (or
> connections) that saw such a certificate, out of 10G, or about 1 per
> million (1 ppm, 0.0001%). It's not about different certificates. I would
> also not say that you need more than 1 ppm of connections to be too big to
> fail, but rather that 1 ppm is clearly lower then the threshold.
>
> But like with lots of things, like enforcing 2048 RSA keys, you have to
> have a point where you're willing to break things, and I really hope that
> that threshold is a few factors higher than the 1 ppm.
>

One piece of data here: The base cert validation failure rate is around 2% (
http://mzl.la/1Dlmty7 bin 3). So 1ppm is pretty far down in the noise.

>
> > seems to be "Don't be Chinese or
>
>> Arab/Persian/Turkic". I don't know if any
>> Russian/Byelorussian/Ukrainian/*stani CAs are present in browsers, but
>> I'm
>> guessing being one of those won't help your case either.
>>
>

> I know there are people who don't trust some governments. And there are
> some very vocal people on this list and other places that don't trust the
> Chinese government. But I haven't seen Mozilla take decisions based on that.
>
> I think the best thing we can do is make technical changes so that we
> don't need to trust those governments. And I think CT is a big step in
> that direction.
>
>
> Kurt
>
>

[Gervase Markham]

On 30/03/15 16:34, Richard Barnes wrote:

> After some further thought on this issue, I would like to propose the
> following course of action:
>
> 1. Remove the CNNIC root certificates
> 2. (possibly) Temporarily add the CNNIC intermediate certificates

After consideration, I want to record two potential problems with this
proposal.

1) It encourages bad practice, and arguably requires CNNIC to violate
the BRs. Both Mozilla (as a Potentially Problematic Practice) and the
BRs tell CAs not to issue certs directly from their embedded
certificates. The BRs has a whole section on this (section 12), which says:

"Root CA Private Keys MUST NOT be used to sign Certificates"

and then goes on to give a limited set of exceptions, none of which
apply to CNNIC issuing EE certs. What is a "Root CA"? According to the
BRs, it is "the top level Certification Authority whose Root Certificate
is distributed by Application Software Suppliers and that issues
Subordinate CA Certificates".

CNNIC's embedded intermediates, in this plan would meet the first half
of that definition, but not the second (due to the artificial pathLength
constraint). So you could argue this both ways in terms of the letter of
the law, but the fact remains that issuing directly from your embedded
certs is bad practice.

2) It subverts end-user choices. If the level of concern at their
inclusion is any guide, some end-users may well have configured their
trust store not to trust CNNIC's roots. If we remove those roots and add
the intermediates, AIUI those decisions will no longer be respected, and
those browsers will trust CNNIC certs again. Without meaning to, we will
have accidentally subverted user trust choices in a way which almost
perfectly restores trust in certs they have chosen not to trust, with no
notification and no side-effects.

This second issue concerns me particularly, given Mozilla's stance on
user sovereignty.

Gerv

[Richard Barnes]

Alright, one more pass at this. After more feedback from this list
(thanks, all!) and some more conversation, I would like to propose
something stronger than my last proposal:

* Do not remove the CNNIC root, but
* Reject certificates chaining to CNNIC with a notBefore date after a
threshold date*.*
* Request that CNNIC provide a list of currently valid certificates, and
publish that list so that the community can recognize any back-dated certs
* Allow CNNIC to re-apply for full inclusion, with some additional
requirements (to be discussed on this list)
* If CNNIC's re-application is unsuccessful, then their root certificates w
ill be removed

This corresponds roughly to option (E) that Peter Bowen raised, and
combines the E1 and E2 options noted by Ryan. I do not anticipate that we
would make software changes to enforce a whitelist, but instead would rely
on CNNIC not back-dating certificates, with the published list usable as
a check for any certificates that the community finds (in the spirit of
CT).

The fact that CNNIC violated its CPS in issuing the MCS Holdings
intermediate certificate calls into question whether they are adhering to
their obligations more generally. The idea of this proposal is
effectively to impose a moratorium on CNNIC issuing more certificates
until they have assured the community that this is the case.

Please consider this a last call for comments on this plan, and send any
objections now. We hope to make a final decision in the next day or two.

Thanks,
--Richard



On Sun, Mar 29, 2015 at 10:24 PM, Richard Barnes <rba...@mozilla.com>

wrote:

> After some further thought on this issue, I would like to propose the
> following course of action:
>
> 1. Remove the CNNIC root certificates
> 2. (possibly) Temporarily add the CNNIC intermediate certificates
>

> Removing the CNNIC root certificates reflects the seriousness of the
> breach of trust that CNNIC has incurred by deliberately issuing an
> intermediate certificate in violation of its CPS, the BRs, and Mozilla
> policies. CNNIC is of course free to re-apply to the root program, so this
> removal is not necessarily permanent
>

> Adding the intermediates would allow CNNIC to continue to issue end-entity
> certificates, and not penalize site owners immediately (as Peter notes).
> However, it would prevent the acceptance of other intermediates, since the

> improper issuance of intermediates is the immediate issue here.
>
> Further reasoning for this course of action follows.
>
>
> # Recap of the options
>
> Summarizing the options expressed by Kathleen and Peter earlier:
>
> A) Remove both CNNIC root certificates
>
> B) Remove EV treatment for the CNNIC EV root
>
> C) Name-constrain the CNNIC roots
>
> D) Remove both CNNIC roots temporarily, with conditions for re-acceptance
>
> E) Only accept certificates already issued by CNNIC (not future ones)
>
> To these, I would like to add:
>
> F) Remove both CNNIC roots, but temporarily add the CNNIC intermediates
>
> This latter option would continue to allow CNNIC to issue end-entity
> certicates, but not to issue further intermediates.
>
>
> # My Analysis
>

> The underlying issue here is that CNNIC, apparently deliberately, violated
> the BRs, Mozilla policy, and its own CPS by issuing an intermediate without
> proper vetting. For me, the most troubling aspect of this is that CNNIC
> violated their own CPS -- the covenant they make with the community for how
> they will behave, and the basis for all the decisions that we make about
> whether to trust them.
>

> The basic need here is thus to re-establish the community's confidence
> that CNNIC will adhere to their obligations under their CPS, the BRs, and
> Mozilla policy. As long as there is uncertainty on this point, it is
> inappropriate for us to grant the unbounded trust implied by inclusion in
> the root program, so there is at least a need place bounds on how CNNIC is
> trusted. Ultimately, if CNNIC cannot assure the community that they will
> adhere to their obligations, then they should not be in the root program.
>
>
> ## Not (B), (C), or (E)
>
> Options (B) and (C) are only loosely related to the concerns about CNNIC's
> behavior. While in general I'm enthusiastic about constraining CAs (see
> the "Name Constraints" thread), in the context of this discussion, it would
> be better to focus on the issues raised by CNNIC's incorrect decision to
> issue an intermediate certificate to MCS Holdings.
>

> Option (E) is technically infeasible, for the reasons that Ryan noted.
>
>

> ## Between (A), (D), and (F)
>
> In brief, my preference order is (A) > (F) > (D)
>
> Given how fundamental a violation it is for a CA to deliberately violate
> its obligations, I think Mozilla would be within its rights to remove the
> CNNIC roots (A). The Mozilla Certificate Policy says that roots may be
> removed as a result of "ongoing or egregious" violations. Given the
> multiple violations noted in Ryan's earlier message, I feel comfortable
> labeling this incident "egregious", in the sense of "unusually serious".
>
> The only difference between (A) and (D) is that (D) establishes conditions
> up front for CNNIC's readmission. Even in case (A), CNNIC may re-apply,
> and they will have to go through the normal process for community approval.
> I am hesitant to commit to conditions for re-admission up front, in case
> any new issues arise in the interim. Any conditions that might be stated
> in case (D) could also be stated in case (A) as part of the re-application
> process.
>

> As a compromise, however, I would be willing to add the CNNIC
> intermediates to the Mozilla root list (F). (Ideally, with an additional
> path length constraint, set to zero.) This would enable CNNIC to continue
> issuing end-entity certificates, without the possibility of adding
> intermediates. Since CNNIC's policy regarding intermediates is the
> immediate issue here, this seems like a reasonable compromise. However,
> these intermediate certificates should not be admitted indefinitely.
> Rather, we should plan to remove them after a fixed time (say 6 months) or
> after CNNIC's re-application is resolved, whichever comes first.
>

[kwi...@mozilla.com]

Thank you to all of you who have thoughtfully and constructively contributed to this discussion so far. This discussion is still open, and we will continue to appreciate your input.

I believe that the latest proposal from Richard (to reject new certificates chaining to CNNIC roots) is in line with Mozilla's policies, and I will explain my reasoning below.

As a reminder, in 2012 and 2013 we set up a wiki page spelling out how Mozilla should respond to incidents of certificate mis-issuance.
https://wiki.mozilla.org/CA:MaintenanceAndEnforcement#Potential_Problems.2C_Prevention.2C_Response

The current incident falls into this category:
"Problem: CA mis-issued a small number of intermediate certificates that they can enumerate
- Immediate Minimum Response: Actively distrust the intermediate certificates...
- Depending on the situation, also consider distrusting the root certificate or all of the root certificates owned by that CA."

Mozilla has taken an immediate minimum response by adding the intermediate certificate to OneCRL in Firefox 37, even though the cert expires soon.

This continued discussion is about the second part: "Depending on the situation, also consider distrusting the root certificate or all of the root certificates owned by that CA."

Additionally Mozilla's CA Certificate Enforcement Policy says:
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/enforcement/
"2. Mozilla may, at its sole discretion, disable (partially or fully) or remove a certificate at any time and for any reason. Mozilla will disable or remove a certificate if the CA demonstrates ongoing or *egregious* practices that do not maintain the level of service that was established in the Inclusion Section of the Mozilla CA Certificate Policy or that do not comply with the requirements of the Maintenance Section of the Mozilla CA Certificate Policy.

I believe this incident may be considered egregious, and is different from previous incidents for the following two reasons:

1) Mozilla's expectations regarding externally-operated subordinate CAs chaining up to roots in Mozilla's program have been increasingly clarified since 2012, and CNNIC has acknowledged each of Mozilla's communications regarding externally-operated subordinate CAs, starting in 2012.
https://wiki.mozilla.org/CA:Communications

2) As Richard previously stated: "... the most troubling aspect of this is that CNNIC violated their own CPS -- the covenant they make with the community for how they will behave, and the basis for all the decisions that we make about whether to trust them."
Also, as per
https://bugzilla.mozilla.org/show_bug.cgi?id=476766#c14
and
https://bugzilla.mozilla.org/show_bug.cgi?id=607208#c22
the decision to include the CNNIC root certificates was partly based on evaluation of the CA hierarchy.
There was no indication in their CP/CPS or during the inclusion process that CNNIC would issue externally-operated intermediate certificates.

Therefore, I believe we should move forward with filling in the details for the plan that Richard described.

I will greatly appreciate your continued thoughtful and constructive feedback on this.

Thanks,
Kathleen

[Rob Stradling]

On 01/04/15 18:35, Richard Barnes wrote:
<snip>

> * Request that CNNIC provide a list of currently valid certificates, and
> publish that list so that the community can recognize any back-dated certs

<snip>

> This corresponds roughly to option (E) that Peter Bowen raised, and
> combines the E1 and E2 options noted by Ryan. I do not anticipate that we
> would make software changes to enforce a whitelist, but instead would rely
> on CNNIC not back-dating certificates, with the published list usable as
> a check for any certificates that the community finds (in the spirit of
> CT).

Why don't you specifically require CT to be the mechanism by which this
list is published?

> The fact that CNNIC violated its CPS in issuing the MCS Holdings
> intermediate certificate calls into question whether they are adhering to
> their obligations more generally. The idea of this proposal is
> effectively to impose a moratorium on CNNIC issuing more certificates
> until they have assured the community that this is the case.

Would it be reasonable to require CNNIC to publish all certs they issue
in the future too (at least until "they have assured the community that
this is the case") ?

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Richard Barnes]

On Wed, Apr 1, 2015 at 5:32 PM, Rob Stradling <rob.st...@comodo.com>
wrote:

> On 01/04/15 18:35, Richard Barnes wrote:
> <snip>
>
>> * Request that CNNIC provide a list of currently valid certificates, and
>> publish that list so that the community can recognize any back-dated certs
>>
> <snip>
>
>> This corresponds roughly to option (E) that Peter Bowen raised, and
>> combines the E1 and E2 options noted by Ryan. I do not anticipate that
>> we
>> would make software changes to enforce a whitelist, but instead would
>> rely
>> on CNNIC not back-dating certificates, with the published list usable as
>> a check for any certificates that the community finds (in the spirit of
>> CT).
>>
>
> Why don't you specifically require CT to be the mechanism by which this
> list is published?
>

That's certainly an option. I didn't want to prescribe a specific
mechanism in my initial proposal, since this seemed like an implementation
detail. In principle, just a list of issuer/serial pairs would be
sufficient to recognize bad certs, if CNNIC were uncomfortable releasing
the full details. I do agree that publishing the details would be
preferable.

> The fact that CNNIC violated its CPS in issuing the MCS Holdings
>> intermediate certificate calls into question whether they are adhering to
>> their obligations more generally. The idea of this proposal is
>> effectively to impose a moratorium on CNNIC issuing more certificates
>> until they have assured the community that this is the case.
>>
>
> Would it be reasonable to require CNNIC to publish all certs they issue in
> the future too (at least until "they have assured the community that this
> is the case") ?
>

That would fall under the rubric of what we as the community want to
require of CNNIC before they can be re-admitted. I think that's a second
discussion, after this one.

--Richard

[Daniel Roesler]

Howdy Kathleen,

I'm a bit confused. Part of Richard's proposal (Option F) is to
temporarily add CNNIC intermediates to the root store. However, you
didn't seem to offer feedback on that part of his proposal. What
precedent or procedure does this procedure draw from? Has this been
done before?

Also, I am strongly against this part of the proposal for two reasons:

First, it allows CNNIC to continue to issue TLS certificates that
browsers will trust, which effectively nullifies any consequence for
violating Mozilla's policies and their own CPS. We cannot trust CNNIC
to follow the policies for intermediate certificates if they cannot
follow them for root certificates. There needs to be real and
effective consequences for CNNIC. Including the intermediate
certificates while CNNIC re-applies makes removal of the root simply
theater.

Second, this compromise is a slap in the face for other root
certificate authorities to have CNNIC's intermediate certificates
elevated (even temporarily) to the same level as their root
certificates. Other root certificate authorities have worked very hard
to follow Mozilla's requirements, and CNNIC should not be propped up
by Mozilla while they re-apply. They are welcome to re-apply in the
future with new root certificates, but it's offensive to the other
root certificate authorities for Mozilla to "compromise" and include
CNNIC's intermediates.

Finally, I'm not super clear on the reason for this intermediate
compromise. Are we worried that many websites will suffer from
removing CNNIC's root? This is not a security breach or private key
leak, so nothing needs to happen in secret or immediately. Mozilla can
announce that CNNIC's root is removed from the next release of
Firefox, which will give website owners plenty of time to move to
other certificate authorities.

Thanks very much for such a productive discussion!

-Daniel

On Wed, Apr 1, 2015 at 2:41 PM,
<dev-security-...@lists.mozilla.org> wrote:
> ------------------------------
>
> Message: 3
> Date: Wed, 1 Apr 2015 10:54:15 -0700 (PDT)
> From: kwi...@mozilla.com
> To: mozilla-dev-s...@lists.mozilla.org
> Subject: Re: Consequences of mis-issuance under CNNIC
> Message-ID: <68666ea2-a135-4424...@googlegroups.com>
> Content-Type: text/plain; charset=ISO-8859-1

[Kathleen Wilson]

On 4/1/15 3:18 PM, Daniel Roesler wrote:
> Howdy Kathleen,
>

> I'm a bit confused. Part of Richard's proposal ...

Hi Daniel,

I think you missed Richard's latest proposal...

>
>
> -------- Forwarded Message --------
> Subject: Re: Consequences of mis-issuance under CNNIC

> Date: Wed, 1 Apr 2015 13:35:25 -0400
> From: Richard Barnes <rba...@mozilla.com>
> To: mozilla-dev-s...@lists.mozilla.org <mozilla-dev-s...@lists.mozilla.org>
> Newsgroups: mozilla.dev.security.policy
> References: <CAOAcki-uuBcZ+iwcPrE+jzTj...@mail.gmail.com> <CAOAcki_=dBcrjXE0htKCLL-iQnY3u...@mail.gmail.com>
>
> Alright, one more pass at this. After more feedback from this list
> (thanks, all!) and some more conversation, I would like to propose
> something stronger than my last proposal:
>
> * Do not remove the CNNIC root, but
> * Reject certificates chaining to CNNIC with a notBefore date after a
> threshold date*.*

> * Request that CNNIC provide a list of currently valid certificates, and
> publish that list so that the community can recognize any back-dated certs

> * Allow CNNIC to re-apply for full inclusion, with some additional
> requirements (to be discussed on this list)
> * If CNNIC's re-application is unsuccessful, then their root certificates w
> ill be removed
>

> This corresponds roughly to option (E) that Peter Bowen raised, and
> combines the E1 and E2 options noted by Ryan. I do not anticipate that we
> would make software changes to enforce a whitelist, but instead would rely
> on CNNIC not back-dating certificates, with the published list usable as
> a check for any certificates that the community finds (in the spirit of
> CT).
>

> The fact that CNNIC violated its CPS in issuing the MCS Holdings
> intermediate certificate calls into question whether they are adhering to
> their obligations more generally. The idea of this proposal is
> effectively to impose a moratorium on CNNIC issuing more certificates
> until they have assured the community that this is the case.
>

[Matt Palmer]

On Wed, Apr 01, 2015 at 01:35:25PM -0400, Richard Barnes wrote:
> Alright, one more pass at this. After more feedback from this list
> (thanks, all!) and some more conversation, I would like to propose
> something stronger than my last proposal:
>
> * Do not remove the CNNIC root, but
> * Reject certificates chaining to CNNIC with a notBefore date after a
> threshold date*.*
> * Request that CNNIC provide a list of currently valid certificates, and
> publish that list so that the community can recognize any back-dated certs
> * Allow CNNIC to re-apply for full inclusion, with some additional
> requirements (to be discussed on this list)
> * If CNNIC's re-application is unsuccessful, then their root certificates w
> ill be removed
>
> This corresponds roughly to option (E) that Peter Bowen raised, and
> combines the E1 and E2 options noted by Ryan. I do not anticipate that we
> would make software changes to enforce a whitelist, but instead would rely
> on CNNIC not back-dating certificates, with the published list usable as
> a check for any certificates that the community finds (in the spirit of
> CT).

I have no objections to this plan as such, and if all goes according to
plan, I believe it will remove CNNIC from the trust store without
inconveniencing those end entities who relied on CNNIC.

I'd like to see discussion of what happens if things *don't* go according to
plan, though. The plan relies quite a bit on CNNIC's cooperation, both to
provide the list of existing certificates, as well as making (and abiding
by) the undertaking not to issue further certificates chaining to their
existing trusted roots. I think it would be beneficial to have a solid idea
of what should be done if CNNIC doesn't cooperate:

1) If they refuse to provide a list of currently issued certificates;

2) If they refuse to cease issuing certificates chained to the existing
trusted roots;

3) If they contravene the undertaking to cease issuing certificates chained
to the existing trusted roots.

My "off the top of my head" reaction to any or all of these events would be
immediate removal of the roots from the trust store, but if that is a
suitable response to CNNIC's inability to abide by Mozilla's additional
rules, I have to wonder why it isn't a suitable response to CNNIC's
inability to abide by Mozilla's *original* set of rules.

A slightly adjusted plan, that doesn't require any actual cooperation from
CNNIC, could be as follows:

* Do not remove the CNNIC root, but
* Reject certificates chaining to CNNIC with a notBefore date after a
threshold date

* Publish a list of all known CNNIC end-entity and intermediate certificates
(based on CT log and TLS census data)
* Invite CNNIC to enumerate any other certificates which they would like to
add to the list
* Advise CNNIC that if any *other* certificates are discovered, the CNNIC
root certificates will be *immediately* removed from NSS, without any
further discussion or appeal
* Allow CNNIC to re-apply for inclusion, etc etc

The advantage of this plan is that it doesn't require CNNIC's cooperation at
any point, and it leaves no room for doubt about what the consequences are
for deviation from the plan. On the other hand, others may disagree with
the consequences I've enumerated, or feel that it is too heavy handed --
which I can appreciate, and would be happy to discuss.

- Matt

--
"You could wire up a dead rat to a DIMM socket and the PC BIOS memory test
would pass it just fine."
-- Ethan Benson

[Reed Loden]

From
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html

"Update - April 1: As a result of a joint investigation of the events
surrounding this incident by Google and CNNIC, we have decided that the
CNNIC Root and EV CAs will no longer be recognized in Google products. This
will take effect in a future Chrome update. To assist customers affected by
this decision, for a limited time we will allow CNNIC’s existing
certificates to continue to be marked as trusted in Chrome, through the use
of a publicly disclosed whitelist. While neither we nor CNNIC believe any
further unauthorized digital certificates have been issued, nor do we
believe the misissued certificates were used outside the limited scope of
MCS Holdings’ test network, CNNIC will be working to prevent any future
incidents. CNNIC will implement Certificate Transparency for all of their
certificates prior to any request for reinclusion. We applaud CNNIC on
their proactive steps, and welcome them to reapply once suitable technical
and procedural controls are in place."

[Richard Barnes]

Given what's in Google's blog post (thanks, Reed), there will apparently be
a public whitelist of certificates whether CNNIC cooperates with Mozilla or
not. So (1) is not an issue.

(2) and (3) are only an issue if they issue certificates that are
back-dated to before the threshold date. That seems like an active
misrepresentation, which would likely be considered sufficient grounds for
removal anyway.

I would suggest that we focus on agreeing on the principle that existing
certificates will continue to be accepted. We can look at a couple of
alternatives for implementing this policy. It may be that a whitelist
approach will be feasible to implement, which has none of the issues you
note.

--Richard

[Reed Loden]

CNNIC just released a "declaration" concerning Google's recent update:

http://www1.cnnic.cn/AU/MediaC/Announcement/201504/t20150402_52049.htm

"1. The decision that Google has made is unacceptable and unintelligible to
CNNIC, and meanwhile CNNIC sincerely urge that Google would take users’
rights and interests into full consideration.

2. For the users that CNNIC has already issued the certificates to, we
guarantee that your lawful rights and interests will not be affected.

China Internet Network Information Center（CNNIC）
April 2nd, 2015"

[Daniel Roesler]

Doh! Apologies for the mix up. One of the downsides of subscribing to
the mailing list in digest mode...

-Daniel

On Wed, Apr 1, 2015 at 6:42 PM,
<dev-security-...@lists.mozilla.org> wrote:
> Message: 2
> Date: Wed, 01 Apr 2015 15:27:18 -0700
> From: Kathleen Wilson <kwi...@mozilla.com>
> To: mozilla-dev-s...@lists.mozilla.org

> Subject: Re: Consequences of mis-issuance under CNNIC

> Message-ID: <AsudnVhgy7Nb7YHI...@mozilla.org>
> Content-Type: text/plain; charset=utf-8; format=flowed