subject:"Consequences of mis\-issuance under CNNIC"

Hi Matt,

On 01/04/15 23:44, Matt Palmer wrote:
 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.

No, this plan does not include them making or abiding by such an
undertaking. Such certificates would not be trusted by Firefox, but they
are welcome to issue them.

It does require them not to _backdate_ certificates, and we will be
asking for a list of currently-outstanding certificates to help ensure
that this does not happen.

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

I think this is unlikely, particularly as Google have decided to require
CNNIC to agree to CT for all certificates in the future, and Google's
blog post suggests that they have agreed to this.

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 02:42, Reed Loden wrote:
 From
 http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html

Indeed. It seems that Google have independently come to very similar
conclusions to us.

Gerv


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 01/04/15 22:41, Richard Barnes wrote:
 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'm not sure that's true; it's easy to issue a new cert with the same
issuer and serial but different dates or CN/SAN.

I suggest issuer, serial, notBefore, notAfter, CN and all SAN at minimum.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 19:33, Daniel Micay wrote:
 Is there really a way we could notice this? Other than a leak from an
 employee at CNNIC...

To be used, certs generally have to be public. Which means people can
find them. And compare them to lists.

We may end up coding the whitelist into Firefox, we may not. But AIUI,
Google are going to.

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

 I've not seen any announcements from Microsoft. Do you have links?

They've only revoked the intermediate certificate right now, but I
wouldn't be surprised if they also ended up removing the root cert.

https://technet.microsoft.com/en-us/library/security/3050995/



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 09:49, c.le...@gmail.com wrote:
 China has a enormous internet population and enormous number of
 websites. Yes CNNIC acted like a dangerous kid. But you really think
 making all Chinese unable to do any online transaction is the
 solution we want to push?

Our plan will not have that effect. What makes you think it will?

 My suggestion: follow IE, Microsoft said they will do something, 

I've not seen any announcements from Microsoft. Do you have links?

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Brian Smith

Florian Weimer f...@deneb.enyo.de wrote:
 Gervase Markham wrote:
 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.

mozilla::pkix does enforce name constraints on domain names in the CN
attribute of the subject field.

https://mxr.mozilla.org/mozilla-central/source/security/pkix/test/gtest/pkixnames_tests.cpp#2186

Cheers,
Brian
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Matt Palmer

On Thu, Apr 02, 2015 at 09:18:05AM +0100, Gervase Markham wrote:
 On 01/04/15 23:44, Matt Palmer wrote:
  1) If they refuse to provide a list of currently issued certificates;
 
 I think this is unlikely, particularly as Google have decided to require
 CNNIC to agree to CT for all certificates in the future, and Google's
 blog post suggests that they have agreed to this.

On the other hand, CNNIC's blog post suggests that they haven't.  There's
some serious cognitive dissonance going on here.

- Matt

-- 
I tend to think of solution as just a pretentious term for thingy. 
Doing that word substitution in my head makes IT marketing literature
somewhat more tolerable.
-- lutchann, in http://lwn.net/Articles/124703/

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Robin Alden

Peter Gutmann said..
 I was using IT news stories as the source, e.g. IDG's 'Secure'
advertising
 tool PrivDog compromises HTTPS security:
 
   Instead, the problem was tracked down to another advertising-related
   application called PrivDog, which was built with the involvement of
 Comodo's
   CEO, Melih Abdulhayoglu. New PrivDog releases are announced on the
 Comodo
   community forum by people tagged as Comodo staff.
 
 That does sound like there's Comodo involvement.
 

It does sound that way, and we have shipped some versions of 
PrivDog with some of our products.
You may even find an IT news story that says it in your exact 
words, but that doesn't make 
'Comodo provided the PrivDog MITM software' 
a correct statement.

Regards
Robin


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Wisilence Seol

I come from the discuss of the bugzilla 
https://bugzilla.mozilla.org/show_bug.cgi?id=542689

this is my opinion about your latest plan:

The CNNIC's root CA on how to issue an intermediate certificate process 
obviously lack of transparency and responsibility, while you still ask the 
community members to provide you the so called professional evidence: We ask 
your continued patience and request that further input remain professional and 
focused on providing concrete evidence that can be acted on according to the 
Mozilla CA Certificate Policy  
Is this sound like a joke?  is this unauthorized digital certificates for 
several Google domains are professional enough evidence?
And still you give CNNIC a chance to re-apply, without any detailed requirement 
on the transparency (yes, you said you will discuss this later, but you allowed 
CNNIC to re-apply already),  meanwhile you chose to only revoke one CNNIC 
Intermediate Certificate not the root CA, it is fully not acceptable by me and 
it still hurt the security of the Mozilla products user.
and for your  Request for CNNIC to provide a list of balabala,  I will be very 
very happy to see you will get a buggy English response/Statement from CNNIC 
like this later:
http://www1.cnnic.cn/AU/MediaC/Announcement/201504/t20150402_52049.htm

At that time, I hope it is not another 5 or 6 years later, I will personally 
ask you(who decided to include CNNIC root CA into Mozilla before and refuse to 
revoke CNNIC CA now) a question: is it hurt to be slapped on the face again and 
again?

On Thursday, April 2, 2015 at 1:35:34 AM UTC+8, 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).
 
 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 rbar...@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,

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Tom Ritter

On 2 April 2015 at 03:49,  c.le...@gmail.com wrote:
 It would be a golden opportunity for Chinese gov to push for a home-grown 
 browser that is not under the control of western imperialism governments for 
 sure.

You mean 360 Browser? Hard to get good statistics it seems, but there
are reports of it being pretty darn popular:
http://www.chinainternetwatch.com/8757/top-web-browsers-china/
(It also does not validate certificates:
https://cabforum.org/pipermail/public/2015-April/005441.html ,
although that is a discussion for another list)


I guess I missed the cutoff for the decision, but I am supportive of
removing CNNIC entirely and whitelisting existing certificiates
issued. As others have said, I am nervous the plans of simply
enforcing a cutoff date and asking the community to detect misissuance
will not be a sufficient detection mechanism for misissuance. Unless
I'm mistaken, despite all the efforts in detecting misissuance
(Perspectives, Decentralized Observatory, HPKP reporting, etc) - all
recent misissued certificates were found via Chrome's PKP in Chrome.
The community does not have a good track record on this.

-tom
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread George Yang

Hi All,

FYI in case that you all guys still think CNNIC is a non-government entity. All
news, regarding Google dropping CNNIC ROOT CA, has been blocked or removed in
almost all Chinese media and web sites. This is not a sporadic action, but
obviously by a ordinance from top level media-controlling agency of China. So
Chinese government is blocking all this info and prevent Chinese people from
knowing Google's decision.

For example, here is a recent google search result on a popular web site (in
Chinese):

Solidot | Google产品全面撤销CNNIC根证书
www.solidot.org/story?sid=43556
Translate this page
4 hours ago - Google在4月1日更新了安全博客，宣布旗下产品删除CNNIC
根证书。Chrome将释出更新移除对CNNIC证书的信任。为了帮助受影响的客户，Google将使用白名单 ...

You will find that such article does not longer exist.

Best Regards,
George

BTW. I'm Chinese and using an alias.

On Monday, March 23, 2015 at 6:48:10 PM UTC-4, 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/

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread George Yang

Hi All,

In addition to the this declaration, they are actually flexing their muscle by 
actively blocking the news of Google dropping CNNIC root in China at all.

As a Chinese, I know that CNNIC is closely related to Chinese Golden Shield 
(a.k.a Great Fire Wall) that monitor and control all internet traffic in/out 
China. Basically CNNIC is just a minion of Chinese internet-controlling agency, 
which would do anything to censor Chinese web sites and attack those it doesn't 
like, people such as Shi Tao and sites such as GitHub.

Many Chinese web sites indeed reported the news of Google's action a short time 
ago. However, most of those articles, if not all, have been taken down. I hope 
that this info will help all you developers to understand why I (and most 
Chinese netizens) consider CNNIS as evil.

Best regards,
George (alias)


On Thursday, April 2, 2015 at 1:07:24 AM UTC-4, Reed Loden wrote:
 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
 
 On Wed, Apr 1, 2015 at 7:19 PM, Richard Barnes rbar...@mozilla.com wrote:
 
  On Wed, Apr 1, 2015 at 6:44 PM, Matt Palmer mpal...@hezmatt.org wrote:
 
   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.
  
 
  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
 
 
 
   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:

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Richard Barnes

On Thu, Apr 2, 2015 at 10:34 AM, Phillip Hallam-Baker ph...@hallambaker.com
 wrote:

 On Thu, Apr 2, 2015 at 9:41 AM, Gervase Markham g...@mozilla.org wrote:
  On 02/04/15 12:42, Sebastian Wiesinger wrote:
  the plan would be to continue allowing current certificats (perhaps
  with some sort of whitelist) while not accepting new certificates.
 
  Could you ask Google to share their whitelist?
 
  Until they announced, we were not aware that Google would be requesting
  a whitelist. It is quite possible CNNIC will supply us both with the
  same data.
 
  As far as I understand it, without an explicit whitelist nothing would
  prevent CNNIC to backdate new certificates so that they would be
  accepted. Is this right or am I missing something?
 
  Well, if anyone detects them doing this, by e.g. scanning the internet,
  the consequences will be serious. I have no reason to believe that they
  would backdate certs but if they did, they would need to be very
  confident that no-one would notice. If I owned CNNIC, I would not be at
  all confident of this.

 Organizations are funny things.

 Facing a choice of coming clean, admitting a mistake and moving on
 versus a cover up, pretty much every rational CEO will choose the
 first.

 Faced with a choice between getting fired for making a mistake and
 making a pathetic attempt to cover up with a small chance of success,
 a rational junior manager will choose the second.


 I think we need to rethink how the principle of least privilege
 applies here and make sure we are doing everything we can to minimize
 risk.

 As a matter of policy, no cert should ever issue for a private key
 that is not under the direct control of a CA unless one of the
 following apply to the corresponding cert:

 1) The other party has CP, CPS and full audit for operating a CA.
 2) There is a name constraint.
 3) It is an end entity certificate.


That's what the Mozilla policy already says!


10. ... All certificates that are capable of being used to issue new
certificates, that are not technically constrained, and that directly or
transitively chain to a certificate included in Mozilla’s CA Certificate
Program MUST be audited in accordance with Mozilla’s CA Certificate Policy
and MUST be publicly disclosed by the CA that has their certificate
included in Mozilla’s CA Certificate Program. The CA with a certificate
included in Mozilla’s CA Certificate Program MUST disclose this information
before any such subordinate CA is allowed to issue certificates.


https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/inclusion/

Indeed, the lack of disclosure and audit is the core of the concern in this
case.

--Richard



 Further no private key should ever be in a network accessible device
 unless the following apply:

 1) There is a path length constraint that limits issue to EE certs.
 2) It is an end entity certificate.

 Perhaps we should take this to the IETF right key list.
 ___
 dev-security-policy mailing list
 dev-security-policy@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 12:42, Sebastian Wiesinger wrote:
 the plan would be to continue allowing current certificats (perhaps
 with some sort of whitelist) while not accepting new certificates.
 
 Could you ask Google to share their whitelist?

Until they announced, we were not aware that Google would be requesting
a whitelist. It is quite possible CNNIC will supply us both with the
same data.

 As far as I understand it, without an explicit whitelist nothing would
 prevent CNNIC to backdate new certificates so that they would be
 accepted. Is this right or am I missing something?

Well, if anyone detects them doing this, by e.g. scanning the internet,
the consequences will be serious. I have no reason to believe that they
would backdate certs but if they did, they would need to be very
confident that no-one would notice. If I owned CNNIC, I would not be at
all confident of this.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Phillip Hallam-Baker

On Thu, Apr 2, 2015 at 11:05 AM, Kurt Roeckx k...@roeckx.be wrote:
 On 2015-04-02 16:34, Phillip Hallam-Baker wrote:

 Further no private key should ever be in a network accessible device
 unless the following apply:

 1) There is a path length constraint that limits issue to EE certs.
 2) It is an end entity certificate.

 Why 1)?

Can you state a use case that requires online issue of Key Signing Certs?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Richard Barnes

Thanks for the feedback on this plan, everyone.  Gerv, Kathleen, and I have
discussed it, and our judgement is that there's consensus here to move
forward with the plan as proposed:

* 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

We may also enforce a whitelist, as suggested on the list, if it turns out
to be feasible.

We will need to have a follow-on discussion to work out some additional
details, e.g., what conditions should be placed on CNNIC's re-inclusion.  I
will send a message starting that thread later today.

There will shortly be a post on the Mozilla Security Blog outlining this
decision, along with more background.
https://blog.mozilla.org/security/

Thanks again to everyone for the robust discussion here.

--Richard


On Wed, Apr 1, 2015 at 1:35 PM, Richard Barnes rbar...@mozilla.com 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
 will 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 rbar...@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,

Re: Consequences of mis-issuance under CNNIC

 As far as I understand it, without an explicit whitelist nothing would
 prevent CNNIC to backdate new certificates so that they would be
 accepted. Is this right or am I missing something?
 
 Well, if anyone detects them doing this, by e.g. scanning the internet,
 the consequences will be serious. I have no reason to believe that they
 would backdate certs but if they did, they would need to be very
 confident that no-one would notice. If I owned CNNIC, I would not be at
 all confident of this.

Is there really a way we could notice this? Other than a leak from an
employee at CNNIC...



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

 China has a enormous internet population and enormous number of websites. Yes 
 CNNIC acted like a dangerous kid. But you really think making all Chinese 
 unable to do any online transaction is the solution we want to push?

I think there'a a much stronger argument that this is protecting Chinese
users. It's certainly an improvement for everyone else.

AFAIK, there are still plenty of CAs that are usable by Chinese
businesses. It will cause some temporary pain but that can be alleviated
with the proposed certificate whitelisting. Legitimate use cases with a
broad impact can continue working.

 It would be a golden opportunity for Chinese gov to push for a home-grown 
 browser that is not under the control of western imperialism governments for 
 sure.

They already have this in various forms. In fact, CNNIC has produced
lots of malware infested browser software. There are signatures for some
of it in most AV products. The inclusion of this root CA is a relatively
recent event anyway, and things weren't much different before then. It
doesn't seem to matter what they want though...

 We can advocate the problem through Mozilla community in China, understand 
 that the impact is minimal. But then again, with Mozilla's market in china, 
 not much we can do that will be significant.
 
 My suggestion: follow IE, Microsoft said they will do something, and they 
 have the largest market share in China.

Microsoft has very little market share in terms of systems that they can
push out updates to. Is it even the case that up-to-date instances of IE
outnumber Firefox + Chrome?



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-02 Thread Kathleen Wilson


On 4/2/15 10:24 AM, Richard Barnes wrote:

Thanks for the feedback on this plan, everyone.  Gerv, Kathleen, and I have
discussed it, and our judgement is that there's consensus here to move
forward with the plan as proposed:

* 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

We may also enforce a whitelist, as suggested on the list, if it turns out
to be feasible.

We will need to have a follow-on discussion to work out some additional
details, e.g., what conditions should be placed on CNNIC's re-inclusion.  I
will send a message starting that thread later today.

There will shortly be a post on the Mozilla Security Blog outlining this
decision, along with more background.
https://blog.mozilla.org/security/

Thanks again to everyone for the robust discussion here.

--Richard




We published a security blog about this:
https://blog.mozilla.org/security/2015/04/02/distrusting-new-cnnic-certificates/

As Richard said, we'll start separate thread to discuss the details of 
implementing this plan.


Thanks,
Kathleen


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 02/04/15 08:54 AM, Kurt Roeckx wrote:
 On 2015-04-02 07:06, Reed Loden wrote:
 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.
 
 I would argue that the decisions that CNNIC made are unacceptable.

The response to the issue has been unacceptable too. They've refused to
acknowledge that many rules were broken and have just downplayed this.

The use of censorship by the to cover this up blows the claim that CNNIC
is independent out of the water.

 2. For the users that CNNIC has already issued the certificates to, we
 guarantee that your lawful rights and interests will not be affected.
 
 I don't think CNNIC can make any such claims, and it's Google (and
 Mozilla) that try to guarantee that instead.

Well, lawful rights and interests means something completely different
to the Chinese government. ;)



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread 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-policy-requ...@lists.mozilla.org wrote:
 Message: 2
 Date: Wed, 01 Apr 2015 15:27:18 -0700
 From: Kathleen Wilson kwil...@mozilla.com
 To: mozilla-dev-security-pol...@lists.mozilla.org
 Subject: Re: Consequences of mis-issuance under CNNIC
 Message-ID: asudnvhgy7nb7yhinz2dnuu7-q-dn...@mozilla.org
 Content-Type: text/plain; charset=utf-8; format=flowed

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread 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

On Wed, Apr 1, 2015 at 7:19 PM, Richard Barnes rbar...@mozilla.com wrote:

 On Wed, Apr 1, 2015 at 6:44 PM, Matt Palmer mpal...@hezmatt.org wrote:

  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.
 

 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



  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

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread Richard Barnes

On Wed, Apr 1, 2015 at 6:44 PM, Matt Palmer mpal...@hezmatt.org wrote:

 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.


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



 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

 ___
 dev-security-policy mailing list
 dev-security-policy@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-security-policy

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread Matt Palmer

On Wed, Apr 01, 2015 at 10:06:53PM -0700, Reed Loden wrote:
 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.

/me gets popcorn

Anyone else want some while I'm up?

- Matt

-- 
If only more employers realized that people join companies, but leave
bosses. A boss should be an insulator, not a conductor or an amplifier.
-- Geoff Kinnel, in the Monastery

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread 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-policy-requ...@lists.mozilla.org wrote:
--

Message: 3
Date: Wed, 1 Apr 2015 10:54:15 -0700 (PDT)
From: kwil...@mozilla.com
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Consequences of mis-issuance under CNNIC
Message-ID: 68666ea2-a135-4424-98d5-91cb5c4f0...@googlegroups.com
Content-Type: text/plain; charset=ISO-8859-1

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

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread 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 rbar...@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.

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread kwilson

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:

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-04-01 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Consequences of mis-issuance under CNNIC

2015-03-31 Thread Robin Alden

Peter Gutmann said..
 Daniel Micay danielmi...@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-security-policy@lists.mozilla.org/msg01
544.html

Robin

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-31 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-31 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-31 Thread 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

Re: Consequences of mis-issuance under CNNIC

2015-03-31 Thread Daniel Micay

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



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread 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 rbar...@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

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread 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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread 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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread jjones

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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread Peter Gutmann

Daniel Micay danielmi...@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 :-).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-30 Thread Peter Gutmann

Matt Palmer mpal...@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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 30/03/15 10:41 PM, Daniel Micay wrote:
 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.

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.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 30/03/15 09:34 PM, Peter Gutmann wrote:
Matt Palmer mpal...@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.

signature.asc
Description: OpenPGP digital signature
___

Re: Consequences of mis-issuance under CNNIC

On 30/03/15 10:08 PM, Peter Gutmann wrote:
 Daniel Micay danielmi...@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.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

2015-03-27 Thread 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?



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

2015-03-27 Thread 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


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

2015-03-27 Thread Matt Palmer

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-27 Thread 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-security-policy@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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-27 Thread 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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

2015-03-26 Thread 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:

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



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

答复: 答复: Consequences of mis-issuance under CNNIC

2015-03-26 Thread 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=cnnic...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表
Kathleen Wilson
发送时间: 2015年3月26日 1:10
收件人: mozilla-dev-security-pol...@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-security-policy@lists.mozilla.org
dev-security-policy@lists.mozilla.org

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: 答复: Consequences of mis-issuance under CNNIC

2015-03-26 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: Consequences of mis-issuance under CNNIC

2015-03-25 Thread Peter Bowen

On Wed, Mar 25, 2015 at 10:10 AM, Kathleen Wilson kwil...@mozilla.com wrote:
 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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: Consequences of mis-issuance under CNNIC

2015-03-25 Thread 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












___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: çå¤: Consequences of mis-issuance under CNNIC

2015-03-25 Thread 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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ç”å¤ : Consequences of mis-issuance under CNNIC

2015-03-25 Thread Peter Bowen

On Wed, Mar 25, 2015 at 12:20 PM, Gervase Markham g...@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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: ç”å¤: Consequences of mis-issuance under CNNIC

2015-03-25 Thread 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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: 答复: Consequences of mis-issuance under CNNIC

2015-03-25 Thread 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.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-25 Thread 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‎

On Wed, Mar 25, 2015 at 1:32 PM, Daniel Micay danielmi...@gmail.com wrote:
 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.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-25 Thread 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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-25 Thread 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.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Kurt Roeckx


On 2015-03-24 10:35, Florian Weimer wrote:

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


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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread diafygi

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

On Tuesday, March 24, 2015 at 2:18:12 PM UTC-7, 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

Re: 答复: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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

On Mon, Mar 23, 2015 at 6:26 PM, Anyin an...@cnnic.cn wrote:
 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 mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 24/03/15 09:03, Kurt Roeckx wrote:
 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?

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

答复: Consequences of mis-issuance under CNNIC

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 �C Tomorrow’s Solutions Today TM

Regards,
An Yin

-邮件原件-
发件人: dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表
David E. Ross
发送时间: 2015年3月24日 10:23
收件人: mozilla-dev-security-pol...@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-security-pol...@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-security-policy@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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

答复: Consequences of mis-issuance under CNNIC

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=cnnic...@lists.mozilla.org
[mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表
David E. Ross
发送时间: 2015年3月24日 10:23
收件人: mozilla-dev-security-pol...@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-security-pol...@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-security-policy@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-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

答复: Consequences of mis-issuance under CNNIC

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=cnnic...@lists.mozilla.org 
[mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表 Peter 
Bowen
发送时间: 2015年3月24日 8:00
收件人: Richard Barnes
抄送: mozilla-dev-security-pol...@lists.mozilla.org
主题: Re: Consequences of mis-issuance under CNNIC

On Mon, Mar 23, 2015 at 3:47 PM, Richard Barnes rbar...@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?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Charles Reiss

On 03/23/15 22:47, Richard Barnes wrote:
Dear dev.security.policy,

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

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread Daniel Micay

On 24/03/15 02:11 PM, Charles Reiss wrote:
 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.

This is a great idea. CAs are not taking the policies seriously because
it has been shown that there are no consequences to breaking them. The
potential breakage has been the excuse in the past, but that is only a
reason to continue trusting *existing* certificates.

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



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

On 24/03/15 13:18, quanxunz...@gmail.com wrote:
 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?

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

How would you define external, when writing the code?

Gerv

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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
 

 On Mar 24, 2015, at 10:08 AM, Amr Farouk a...@mcsholding.com wrote:
 
 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 mailto: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=cnnic...@lists.mozilla.org 
 mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org
 [mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org 
 mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表
 David E. Ross
 发送时间: 2015年3月24日 10:23
 收件人: mozilla-dev-security-pol...@lists.mozilla.org 
 mailto:mozilla-dev-security-pol...@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-security-pol...@lists.mozilla.org 
 mailto:mozilla-dev-security-pol...@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

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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=cnnic...@lists.mozilla.org
 [mailto:dev-security-policy-bounces+anyin=cnnic...@lists.mozilla.org] 代表
 David E. Ross
 发送时间: 2015年3月24日 10:23
 收件人: mozilla-dev-security-pol...@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-security-pol...@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-security-policy@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

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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.



signature.asc
Description: OpenPGP digital signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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






___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Consequences of mis-issuance under CNNIC

2015-03-24 Thread 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?



___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

答复: Consequences of mis-issuance under CNNIC