date:20150324

* 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: Name Constraints

On 24/03/15 12:40, Peter Kurrasch wrote:
 I'm confused because it sounds like you're advocating for the status
 quo but I didn't think that was your position?

I am not in favour of non-consensual name constraints for CAs in
general. I think it would either be ineffective in improving security
(in milder forms) or lead to Mozilla making massive interventions into
the CA market which cannot possibly be done in a fair and reasonable
manner, along with a massive admininstrative burden (in stronger forms).

I am in favour of verbally encouraging all CAs to accept consensual name
constraints, and I am in favour of name-constraining a set of government
CAs to the TLD(s) associated with their country. It's a point of
discussion as to whether this is all government CAs simply because they
are controlled by governments, or just those who have not had the
standard audits, because they don't meet the standard criteria.

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: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: Name Constraints

On 24/03/15 05:01, Peter Kurrasch wrote:
 1) As a first step on the path to fairness, perhaps there can be
 agreement that the goal of any name constraint policy should be the idea
 that a single root does not get the whole internet. Maybe a whole CA
 organization might, but a single root should not. Could everyone agree?

I don't agree on that, because I don't yet think that a forced name
constraints policy for all CAs is a good idea at all.

Your proposal might reduce the risk to some degree, but not much. If I
broke into Foo CA's issuing system, and Foo CA has two roots, one for
one half of the internet, and the other for the other half, then I can
just use whichever half I need. This provides extra protection only in
the case where a CA is part-compromised and it happens to be the wrong
part for what the attacker wants to do.

The other problem is that some CAs don't have more than one root, and in
fact it's been both Mozilla and Microsoft policy to encourage CAs not to
multiply roots without end. I heard a soft limit of 3 being mentioned at
one point for Microsoft's program, although that may have been a rumour.
Certainly, some CAs in our program only have a single root. Do they get
penalized by being given only half the Internet because of that?

 2) ‎I picture a broadcast mechanism along the lines of OneCRL that
 would/could play a role in helping determine when a root's scope has
 become too broad. This mechanism combined with live browsing data could
 flag potential problems and conflicts with the policy agreements.

This all sounds like a massive technical effort and an administrative
nightmare, as well as affecting reliability (as all complex systems do).
You would need to make a clear case for a significant improvement in the
security of the internet, realisable in the short to medium term, in
order for something like this to even be contemplated.

 I guess a final thought is that the work Richard (?) did to come up with
 an initial set of constraints for the trusted roots is a good place to
 start‎ the conversation of how to fairly divvy up the DNS space. It's
 like saying to the CA's, since these are the areas where your business
 is, why not just constrain yourself to these TLD's? As long as it's not
 carved in stone it should be a reasonable way to go...?

If you were running a business with, say, 10 different product lines,
and the government came along and said you're currently making these 10
different products; we are going to pass a law which says you can't make
any other products without making it public that you intend to move into
a new area of business, asking us for permission and, if we decide to
give it, waiting a year or so, how would you react?

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

Require separation between Issuing CAs and Policy CAs

2015-03-24 Thread Peter Bowen

Today the Mozilla CA policy and the CAB Forum categorize CAs as either
Root CAs or Intermediate CAs.  However the reality is that the line is
not always clear between the two and this leads to uncertainty of what
requirements apply in various circumstances. For example, the Baseline
Requirements require that CAs do not issue Subscriber (End-Entity)
certificates from Root CAs, but a cross-signed CA might be able to
argue that its root is a subordinate CA.

One possible solution is to require that all certificates for CAs that
issue Subscriber certificates (those without CA:TRUE) have zero path
length constraint in the basic constraints extension. All CAs with
certificates with a longer allowed path length or no length constraint
would only be allowed to issue certificate types that a Root CA is
allowed to issue.

I think that this already is best practice for CAs and moving it to
requirement would make it possible to technically enforce the
practice.

It would not have prevented the most recent issue, but would help
prevent a whole class of other issues.

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

Re: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 11:26 am, Kai Engert wrote:
  Thoughts?

I don't believe this is reasonable/responsible.

For example, is it your intent to prevent Let's Encrypt from becoming
cross-certified? That's the effect of this proposal.

For example, is your intent to prevent Google from running its own
intermediate for its properties? That's the effect of this proposal.

If it is, I think you're mistaken.
If it is not, then I think that can demonstrate why the proposal is broken.

The current Mozilla Policy sets forth sensible guidelines for how to deal
with and manage this situation. It, along with the Baseline Requirements,
requires both Point-in-Time Readiness Assessments and Period-of-Time
Audits for such intermediates; a PITRA before, a POT after 60 and before
90 days.

This is no different than Mozilla's requirements for root inclusions.

The fundamental difference between a sub-CA such as Let's Encrypt or
Google Internet Authority G2 and a Root CA is that the CP/CPS has not yet
been publicly reviewed. However, Mozilla updated the program requirements
in v2.1 to require disclosure. The work of Kathleen to further streamline
such disclosures (via Salesforce) represents a further accumulation of
machine-readable data for such discussions and eventual public review.

The cross-certifying CA certainly bears responsibility for those that they
have certified, a necessary tradeoff of circumventing the public review.
However, we must consider such subordinate failures as if it was the
root had done it, and carefully evaluate the circumstances surrounding it.

Your proposal fails to do this, and in short only recognizes Technically
Constrained sub-CAs as valid. I think that is mistaken, for all the
reasons that have been discussed repeatedly during such conversations on
technical constraints. Name constraints are simply insufficient here, nor
is it fair to assume that the failings of one CA are representative of the
ecosystem.

Hopefully you will be able to incorporate this feedback, as well as the
past three years' worth of discussion surrounding this, to find a proposal
that doesn't throw the baby out with the bathwater. If this is intended to
be a response to CNNIC, I think the policies are and have been clear on
this.

I also think extreme care is needed before proposing blanket
zero-tolerance policies. It's no accident that no program spells those out
- it's a recognition of complexities. Even the few places in the Baseline
Requirements that spell out hard actions - such as revocation periods -
have and do cause real and painful service disruptions, and need
revamping.

If you're not sure what I'm referring to, [1] provides further context.

Cheers,
Ryan

[1] https://cabforum.org/pipermail/public/2015-March/005288.html

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

Re: Forbid creation of non-constrained intermediates for external entities

Okay, so if a CA doesn't want to cause a service disruption for their
customers when this happens, they will implement CT. You can remove
their certificate and make a press release saying you wouldn't have
distrusted their old certificates if they implemented CT. I'm sure CT
will jump to the top of the priority lists of most CAs. Browser / OS
vendors really do hold all of the cards here. The CAs have to beg for
inclusion and go to extreme lengths to prove trust if you feel like
requiring it, but you don't.

I don't see how it's anything but a technical issue, and you're more
than up to solving it.

That's not a zero tolerance policy. It's an example of compromise where
in exchange for more lenience, the CAs have to do something. You have to
demonstrate that they have something to gain by showing that the
policies have teeth though.



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 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: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 2:50 pm, Daniel Micay wrote:
  There's no service disruption caused by not trusting any certs from the
  CA created after say, 3 weeks from now. They utterly failed to comply
  with numerous rules and if those policies have any real teeth behind
  them their time as a trusted root is over. If it remains as a trusted
  root, it's simply demonstrating to every other CA that compliance with
  those policies is unimportant as has been done in the past.

Except this fundamentally doesn't work, on a technology level.

The CA is responsible for setting the issuance dates of the certificates.
If you don't trust the CA, you cannot use those dates.

This is the same problem with Code Signing certificates (and other forms
of signatures), and why Time Stamping Authorities exist. You need a
counter-signature to assert the time at which the certificate was issued.

Now, we could go define a TSA for X.509v3 TLS certs, which is slightly
problematic because a TSA is a counter-signature and there's no good means
to smuggled counter-signatures for TLS without going proxy certs.

Or we could use Certificate Transparency, in which the SCT acts as a
lighter weight (but less secure) TSA counter-signature, since the SCT
issued by the log has a timestamp (set by the log) as to when it was
observed/issued.

Regardless, you're extremely optimistic, well beyond the point of
realistic, if you think a CA can execute such turn-around on a dime, of
which three weeks is. And it would still mean distrusting any/all
certificates prior to the 'distrust' date because they lacked actionable
establishment of the time at which they're issued.

I don't mean to suggest these problems aren't solvable, but they certainly
aren't as easy or managable as you might think. On the Chrome side, we're
actively investing in and investigating this.

To yield the most long-term viable result, supporting CT seems a
reasonable path towards having reliable time stamping, so that informed
decisions, including Accepting all the certs in the past, but none in the
future or Only accepting certs that have been logged can offer a
greater degree of public transparency, while minimizing disruption.

But zero-tolerance policies aren't the same as that.

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

Re: Forbid creation of non-constrained intermediates for external entities

 That's not a zero tolerance policy. It's an example of compromise where
 in exchange for more lenience, the CAs have to do something. You have to
 demonstrate that they have something to gain by showing that the
 policies have teeth though.

(removing a shiny green bar



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: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 3:11 pm, Daniel Micay wrote:
  That's not a zero tolerance policy. It's an example of compromise where
  in exchange for more lenience, the CAs have to do something. You have to
  demonstrate that they have something to gain by showing that the
  policies have teeth though.

Daniel,

It's difficult to have a discussion with you when you mount attacks (This
happened because of your negligence / Can you please stop pretending
that the people involved in PKI are responsible) and then change the
goalposts and definition arbitrarily and capriciously (That's not a zero
tolerance policy, when Kai's proposal is just that)

I can understand you're excited to discuss this topic, but it would be
helpful to be more productive in the commentary, and recognize the
messages being replied to.

As it stands, Kai's proposal is problematic, for the reasons I've
addressed. There is still a service disruption for every CA, it's just a
service disruption you view as acceptable because They should have used
CT. That doesn't make it not a service disruption, and it doesn't make it
not zero-tolerance.

Regardless of your feelings towards this particular incident, I think we
can agree that a world where every domain holder could, in event of a CA
compromise, validate that the compromised CA had not misissued
certificates by examining the public logs, of which all certificates were
required to be logged, is a good world. A world in which we can say All
currently disclosed certificates are and remain trusted; no new
certificates are trusted is also a world in which we can make more
informed decisions regarding misissuance. Those are worlds we want to go
to.

But they're neither the end-state nor are they wholly sufficient. And
while it's good to keep those potentialities in mind, it's also good to
recognize there are some worlds that we wouldn't want. I don't think we'd
want a world in which Let's Encrypt could not exist, or which would be
functionally delayed for 10 years. That benefits no one. This proposal
would require that - and even more, greater disruption for any CA that
disagreed and tried to help make Let's Encrypt a reality.

These are things we can discuss. Personal attacks? Those would best be
left for another forum.

___
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: Forbid creation of non-constrained intermediates for external entities

 To be fair, Debian and other projects have even lower security standards.
 
 That is, they still mark CACert as secure for SSL in stable (how is that
 not a security update relevant, even if fixed in Untable?!)

CACert is not nearly as bad as many of the CAs Mozilla actually
considers to be trustworthy. It still has a pile of crap codebase and
their auditing is very lacking, but at least you can see all the
information on where they're going wrong and right.

AFAIK, they haven't ever been hacked or issued any crazy invalid certs.

They were removed because they weren't too big to fail and aren't
willing or financially able to bribe their way through auditing.

Why are Comodo, TurkTrust, CNNIC and others still in the trust database?
It's money that matters, not security. It's a joke.



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: Forbid creation of non-constrained intermediates for external entities

On Tue, March 24, 2015 4:44 pm, Daniel Micay wrote:
  They're willing to set the security standards *really low* because all
  that matters is market share. I can't really understand how they ended
  up in the position of having the dominant trust store used by FOSS
  projects. Debian and other projects should move away from simply
  shipping Mozilla's trust store as-is ASAP.

To be fair, Debian and other projects have even lower security standards.

That is, they still mark CACert as secure for SSL in stable (how is that
not a security update relevant, even if fixed in Untable?!), haven't
updated the ca-certificates package to remove any of the CAs that Mozilla
removed for lack of current audits or modern crypto, and still include *as
trusted for SSL* all the certificates that can't even match Mozilla's
requirements for SSL (usually because of a lack of audits).

The two most important things for managing a root store:
- Keep it updated
- Keep on top of the audits

For what you decry about the Mozilla process, it's community driven and
excels at those two things, which is exactly how it became the dominant
trust store.

But yes, Debian moving away from what they do today would be great, if
only because their current use is even worse than you describe Mozilla's.

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

Re: Forbid creation of non-constrained intermediates for external entities

 Take a few deep breaths. Just breathe. There. Good.

If that's what helps you sleep at night. It remains a fact that browser
vendors chose to hand the keys to the castle to an organization known at
the time to be one of the largest distributors of malware in the world.
I'm not talking broadly about the Chinese government but specifically
about the CNNIC. Hard to see how this is a surprise...

The discovered certificate is the tip of the iceberg. If they weren't
following a dozen rules here, do you think they were elsewhere?



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

It has been discovered that an intermediate CA under the CNNIC root has
mis-issued certificates for some Google domains. Full details can be found
in blog posts by Google [0] and Mozilla [1]. We would like to discuss what
further action might be necessary in order to maintain the integrity of the
Mozilla root program, and the safety of its users.

There have been incidents of this character before. When ANSSI issued an
intermediate that was used for MitM, name constraints were added to limit
its scope to French government domains. When TurkTrust mis-issued
intermediate certificates, they changed their procedures and then they were
required to be re-audited in order to confirm their adherence to those
procedures.

We propose to add name constraints to the CNNIC root in NSS to minimize the
impact of any future mis-issuance incidents. The “update procedures and
re-audit” approach taken with TurkTrust is not suitable for this scenario.
Because the mis-issuance was done by a customer of CNNIC, it’s not clear
that updates to CNNIC’s procedures would address the risks that led to this
mis-issuance. We will follow up this post soon with a specific list of

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

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

proposed constraints.

Please send comments to this mailing list. We would like to have a final
plan by around 1 April.

Thanks,
--Richard

[0]
http://googleonlinesecurity.blogspot.com/2015/03/maintaining-digital-certificate-security.html
[1]
https://blog.mozilla.org/security/2015/03/23/revoking-trust-in-one-cnnic-intermediate-certificate/

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

Forbid creation of non-constrained intermediates for external entities

2015-03-24 Thread Kai Engert

This is a suggestion for stricter rules regarding the creation of
intermediate CA certificates that are issued by root CA certificates
included in the Mozilla CA list.

Every CA organization should be ultimately responsible that the
intermediate CA certificates they create will never be used in a MITM
device.

If an intermediate CA certificate controlled by the CA, or controlled by
a subordinate entity of the CA, is used in a MITM device, or used to
mis-issue a certificate, the discovery of an unrevoked mis-issued
certificate will result in the immediate removal of the respective root
CA certificate.

If a CA provides an intermediate CA certificate to an external
organization, then the intermediate CA certificate must contain a name
constraint extension, which restricts the abilities of the intermediate.

The constraint must either limit the intermediate to
(a) a set of second level domains the external organization controls.
or
(b) to exactly one TLD

The discovery of any unconstrained and unrevoked intermediate CA
certificate that isn't controlled by the root CA organization results in
the immediate removal of the root CA from the Mozilla CA list.

If the CA issues an intermediate CA that is constrained to a TLD, then
the primary CA is fully responsible for the actions of the external
organization, including deliberate and accidental misuse of the
intermediate. A misuse of the intermediate, or a misuse of any
subordinate certificate, is the full responsibility of the primary CA.

Because of the potential consequences of a misuse of an intermediate for
the primary CA, it is recommeded that a CA shall be very careful when
handing out an intermediate to an external organization, such as
enclosing the intermediate's key in an HSM, and requiring a contract
with the external organization, which would cover the monetary risk of
closing down the business of the primary CA.

The discovery of any misuse of where the primary CA has the full
reponsiblity shall result in the immediate removal of the CA from the
Mozilla list.

Thoughts?

Thanks,
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

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 to

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: Forbid creation of non-constrained intermediates for external entities

2015-03-24 Thread Kai Engert

On Tue, 2015-03-24 at 14:52 -0400, Daniel Micay wrote:
  Thoughts?
 
 I think it's a good policy, but like the current policies it cannot
 really be enforced because there is no way to validate compliance.

At least there'd be clarity about the immediate removal on discovery.

Kai


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

Re: Forbid creation of non-constrained intermediates for external entities

 At least there'd be clarity about the immediate removal on discovery.

I find it hard to believe that a business centered entirely around the
CA business would self-report this or any other issue if they knew it
would lead to removal. At the moment, the only incentive to report is
the potential greater damage from not doing it. If the entire business
is a CA and it's removed, then it's over. They have no incentive to
comply with a policy that would bankrupt them.

In fact, I'd expect that they could easily get in trouble for not
looking out for shareholder interests if they comply with a policy
that's above and beyond what is required by law. Is there any legal
weight behind the policies?

Mozilla is fine with continuing to empower a Chinese government
apparatus with the ability to MITM people around the world, even after
they are caught red-handed with such a certificate issued. Hard to
believe any explanation they offer about the existence of said
certificate. It's not hard for the Chinese military to set up a shell
company in the Middle East.



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

 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: Forbid creation of non-constrained intermediates for external entities

* Kai Engert:

 The discovery of any unconstrained and unrevoked intermediate CA
 certificate that isn't controlled by the root CA organization results in
 the immediate removal of the root CA from the Mozilla CA list.

In this case, wouldn't this require the removal of the Entrust root,
not just the CNNIC root?  Or wasn't the CNNIC SSL sub-CA certificate
extended beyond 2012?

Clearly, the removal of an actually relevant root CA from the trust
store is not going to happen because the user impact and subsequent
reduction in browser market share.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: address prefixes allowed for domain control validation

2015-03-24 Thread Kathleen Wilson


On 3/23/15 8:36 AM, Kathleen Wilson wrote:

Just to be clear... This is the wording copied as-is from the wiki page.
I have not proposed any changes yet -- I'm looking for your input on how
to update this wiki page, and I appreciate the input you all have
provided so far.

Thanks,
Kathleen


On 3/22/15 4:18 PM, Kathleen Wilson wrote:

After reading this:
https://raymii.org/s/blog/How_I_got_a_valid_SSL_certificate_for_my_ISPs_main_website.html



I'm thinking we need to update our wiki page:

https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs





Thanks to all of you who contributed to this discussion, and thanks to 
Ryan for providing the text that the following proposal is based on.


I did not see a lot of support to remove admin@ and administrator@, so 
the proposal is to simply point to the BRs as follows.


https://wiki.mozilla.org/CA:Problematic_Practices#Email_Address_Prefixes_for_DV_Certs
~~~Proposed Text~~~
Mozilla's CA Certificate Inclusion Policy requires CAs to conform to the 
Baseline Requirements (BRs) in the issuance and management of publicly 
trusted SSL certificates. This includes the BR restrictions on the use 
of email as a way of validating that the certificate subscriber owns or 
controls the domain name to be included in the certificate. CAs are 
expected to conform to BR Section 11.1.1, which restricts the email 
addresses that may be used to authenticate the subscriber to information 
listed in the registrant, technical, or administrative WHOIS 
records and a selected whitelist of local addresses, which includes 
local-parts of admin, administrator, webmaster, hostmaster, and 
postmaster.


A CA that authorizes certificate subscribers by contacting any other 
email addresses is deemed to be non-compliant with Mozilla's CA 
Certificate Inclusion Policy and non-conforming to the Baseline 
Requirements, and may have action taken upon it as described in 
Mozilla's CA Certificate Enforcement Policy. CAs are also reminded that 
Mozilla's CA Certificate Policy and the Baseline Requirements extend to 
any certificates that are technically capable of issuing SSL 
certificates, and subordinate CAs that fail to follow these requirements 
reflect upon the issuing CA that certified it.



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

* 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: Forbid creation of non-constrained intermediates for external entities

2015-03-24 Thread Bruce

On Tuesday, March 24, 2015 at 3:41:50 PM UTC-4, Florian Weimer wrote:
 * Kai Engert:
 
  The discovery of any unconstrained and unrevoked intermediate CA
  certificate that isn't controlled by the root CA organization results in
  the immediate removal of the root CA from the Mozilla CA list.
 
 In this case, wouldn't this require the removal of the Entrust root,
 not just the CNNIC root?  Or wasn't the CNNIC SSL sub-CA certificate
 extended beyond 2012?
 
 Clearly, the removal of an actually relevant root CA from the trust
 store is not going to happen because the user impact and subsequent
 reduction in browser market share.

Please note that the intermediate certificate which Entrust issued to CNNIC 
expired in 2012 and was not extended. Also note that the Basic Constraints had 
a path length of 0; as such the trust would not have extended to intermediates 
issued by CNNIC.
___
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: Forbid creation of non-constrained intermediates for external entities

* Daniel Micay:

 These rules would be a lot more meaningful if any new additions to the
 trust store were required to have Certificate Transparency implemented
 for the sake of auditing, along with a deadline for other CAs to put it
 in place. CT would have meant this was trivially caught *much* earlier
 by security researchers.

That depends on how many legitimate gmail.com certificates are out
there.  Organizations struggle to keep track of their own
certificates.  It's difficult to see how relative outsiders (and most
“security researchers” are) can cope with that, except by raising an
alarm about everything they see (which is not generally helpful).

There's also an ongoing effort to defang CT and make the data much
less useful, so CT could turn meaningless fairly soon.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Forbid creation of non-constrained intermediates for external entities

On 24/03/15 04:10 PM, Daniel Micay wrote:
 On 24/03/15 03:40 PM, Florian Weimer wrote:
 * Kai Engert:

 The discovery of any unconstrained and unrevoked intermediate CA
 certificate that isn't controlled by the root CA organization results in
 the immediate removal of the root CA from the Mozilla CA list.

 In this case, wouldn't this require the removal of the Entrust root,
 not just the CNNIC root?  Or wasn't the CNNIC SSL sub-CA certificate
 extended beyond 2012?

 Clearly, the removal of an actually relevant root CA from the trust
 store is not going to happen because the user impact and subsequent
 reduction in browser market share.
 
 They are not going to enforce the policies unless there is negative news
 coverage that outweighs whatever risk of losing market share they see
 from calling connections insecure when are known to be insecure.

In other words, if you want the responsible choice to be made in these
cases then you should be contacting news publications to shame Mozilla
into doing the right thing - not a Mozilla mailing list.



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: Forbid creation of non-constrained intermediates for external entities

On 24/03/15 03:58 PM, Florian Weimer wrote:
 * Daniel Micay:
 
 These rules would be a lot more meaningful if any new additions to the
 trust store were required to have Certificate Transparency implemented
 for the sake of auditing, along with a deadline for other CAs to put it
 in place. CT would have meant this was trivially caught *much* earlier
 by security researchers.
 
 That depends on how many legitimate gmail.com certificates are out
 there.  Organizations struggle to keep track of their own
 certificates.  It's difficult to see how relative outsiders (and most
 “security researchers” are) can cope with that, except by raising an
 alarm about everything they see (which is not generally helpful).
 
 There's also an ongoing effort to defang CT and make the data much
 less useful, so CT could turn meaningless fairly soon.

In the case of gmail.com, any certificate not valid with the pinning in
Chromium is highly suspicious. There may be some false positives, but
running it by the organization behind the domain can confirm it. You may
even get a bounty for finding something like this...

If they're not able to confirm or deny the validity of the certificate,
that's a separate juicy scandal.



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: Forbid creation of non-constrained intermediates for external entities

On 24/03/15 03:40 PM, Florian Weimer wrote:
 * Kai Engert:
 
 The discovery of any unconstrained and unrevoked intermediate CA
 certificate that isn't controlled by the root CA organization results in
 the immediate removal of the root CA from the Mozilla CA list.
 
 In this case, wouldn't this require the removal of the Entrust root,
 not just the CNNIC root?  Or wasn't the CNNIC SSL sub-CA certificate
 extended beyond 2012?
 
 Clearly, the removal of an actually relevant root CA from the trust
 store is not going to happen because the user impact and subsequent
 reduction in browser market share.

They are not going to enforce the policies unless there is negative news
coverage that outweighs whatever risk of losing market share they see
from calling connections insecure when are known to be insecure.



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

Does any part of CNNIC's CPS cover issuing external subCAs at all? When did 
CNNIC start issuing external subCAs?
I am afraid we don't have issuing external subCAs in CPS. This is the first 
time we try to issueing an external subCAs just for testing propose.
We decided to discuss external SUBCAs authorization with our audit team in this 
year WebTrust audit in April.

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

Regards,

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

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

On 03/23/15 22:47, Richard Barnes wrote:
 Dear dev.security.policy,
 
 It has been discovered that an intermediate CA under the CNNIC root 
 has mis-issued certificates for some Google domains.  Full details can 
 be found in blog posts by Google [0] and Mozilla [1].  We would like 
 to discuss what further action might be necessary in order to maintain 
 the integrity of the Mozilla root program, and the safety of its users.
 
 There have been incidents of this character before.  When ANSSI issued 
 an intermediate that was used for MitM, name constraints were added to 
 limit its scope to French government domains.  When TurkTrust 
 mis-issued intermediate certificates, they changed their procedures 
 and then they were required to be re-audited in order to confirm their 
 adherence to those procedures.
 
 We propose to add name constraints to the CNNIC root in NSS to 
 minimize the impact of any future mis-issuance incidents.  The “update 
 procedures and re-audit” approach taken with TurkTrust is not suitable for 
 this scenario.
 Because the mis-issuance was done by a customer of CNNIC, it’s not 
 clear that updates to CNNIC’s procedures would address the risks that 
 led to this mis-issuance.  We will follow up this post soon with a 
 specific list of proposed constraints.
 
 Please send comments to this mailing list.  We would like to have a 
 final plan by around 1 April.

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

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



___
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: Name Constraints

2015-03-24 Thread Peter Kurrasch

‎Looping back in the mail list which was dropped by mistake The issues at hand are: Who will choose to self-constrain? Who should be forced to constrain? Who benefits from any constraints made?To that last question, it's a bit of a paradox because we are asking an entity to take action that has minimal benefit to itself. The benefit from the constraints actually goes to everyone else on the internet!True, an argument could be made that a CA which constrains itself will be less of a target ‎for attack because their ability to issue fraudulent certs is, in theory, reduced. While I don't disagree with that argument I don't find it all that persuasive because quite apart from whether a CA is a desirable target, once it's been compromised the result is the same: everyone within that CA's sphere of influence is at risk. If that sphere of influence is "the whole internet" we now have a big problem. If that sphere is only "everyone in .cn" then I'm still concerned, but less so.So that's the thinking behind my previous suggestion that "nobody gets the whole internet". A compromise or sloppiness or deliberate fraud at one CA should not mean that everyone is potentially at risk.Now, as to who will want to self-constrain, I don't think it's a very long list. Anyone who chooses to do so should be lauded, of course, but they are basically doing it out of the goodness of their hearts. As I said, the benefit doesn't really go to the CA and since there is a potential loss of business if they can't issue certs for some customers I really don't see a strong motivation to self-constrain.As to who should be forced to constrain, this is controversial. I would argue that everyone should be forced, but that has certain problems. One can argue that only government-run and certain other CA's should be forced but then we are put in the position of having to decide objectively which ones are more‎ trustworthy than others. That can be a tricky path to navigate and doesn't change the underlying threat: that any CA can be a victim of outright attack, sloppy operations, deliberate bad acts, and even simple mistakes.So while it may be safer, forcing constraints on everyone creates problems. And while it may be more doable, forcing only some CA's might not have enough of an impact. It's a giant risk/reward calculation.Hopefully this better explains where I'm coming from. From: Gervase MarkhamSent: Tuesday, March 24, 2015 12:37 PM‎On 24/03/15 17:26, Peter Kurrasch wrote: Be careful you don't invalidate your whole argument: that people should self-constrain even though the security benefit is minimal.It depends from whose perspective. The security benefit to the CA systemof HARICA, the Greek academic CA, name-constraining itself to .gr, .organd .net (I think) was minimal. But the security benefit to HARICAitself was significant, because if they can't issue for .com it makesthem much less of a target.So I think some smaller CAs may be open to voluntarily taking on nameconstraints. I'm also not sure I see the reason to target government-run CA's?You really don't see any reason why people might be less trusting ofgovernment-run CAs? :-)Also, we have an audit exception for government-run CAs. They often haveinternal audits only, and we can't easily tell them to go away and get aWebTrust audit. So we might decide that in order to take advantage ofthat exception, you have to be name constrained.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