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.