Forbid creation of non-constrained intermediates for external entities

[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

[Daniel Micay]

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

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. Private audits are clearly not working.

[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

[Daniel Micay]

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

[Florian Weimer]

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

[Florian Weimer]

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

[Daniel Micay]

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.

[Daniel Micay]

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.

[Daniel Micay]

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.

[Bruce]

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.

[Ryan Sleevi]

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

[Daniel Micay]

On 24/03/15 05:29 PM, Ryan Sleevi wrote:
>
> 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.

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.

They can come back to the table and ask for inclusion again after they
fix the problems that led to this situation. All of the cards are in the
hands of the browser and OS vendors.

You can tell them they have to open-source their infrastructure's code
so it can be audited for compliance before adding them back. Either the
CA complies or it's essentially dead. You can tell them they have to
implement Certificate Transparency. The blame is on entirely on the
maintainers of the trust stores when the system fails like this because
they have *chosen* to create this situation. The CAs will comply with
the rules you create because their livelihood depends on it. If they
don't, there are *plenty* of people / businesses who would be happy to
take their place.

[Daniel Micay]

Anyway, really hard to see how two browsers holding a majority of the
market share do not have all of the cards in their hands. This happened
because of your negligence and will continue to happen. It's a good
thing you don't sell your browser to your users because then they'd have
standing to sue you for the outrageous security claims. Can we please
stop pretending that the people involved in PKI are responsible?

[Ryan Sleevi]

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.

[Daniel Micay]

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.

[Daniel Micay]

> 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

[Ryan Sleevi]

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.

[Kai Engert]

On Tue, 2015-03-24 at 14:29 -0700, Ryan Sleevi wrote:
> For example, is your intent to prevent Google from running its own
> intermediate for its properties? That's the effect of this proposal.

Ryan, thanks for your detailed response. Let me start by replying to the
above part of your response.

I'm not convinced my suggestion prevents your example of a corporation
that wants an intermediate for their own purposes.

Couldn't you get an intermediate that's constrained to the list of
domains that Google controls?

If you're worried that the intermediates are getting too big (because
you have so many domains), couldn't you get multiple intermediates, each
constrained to a subset of the domains that Google controls?

In my suggestion this was scenario (a), and the CA wouldn't be
repsonsible for mis-issuance by intermediates that are constrained to
second-level domains (like google.com or google.co.uk).

Kai

[Ryan Sleevi]

On Tue, March 24, 2015 3:27 pm, Kai Engert wrote:
> Couldn't you get an intermediate that's constrained to the list of
> domains that Google controls?

And this was the part that has been repeatedly discussed on this list and
in the CA/Browser Forum, and which the answer for Google (and for a large
number of holders of intermediate CAs), "no".

I don't mean to be dismissive, but this is certainly not the first - or
the fifth - time this has come up. Without digging through the archives to
point you to specific messages, I think if you look during the past
discussions of "Technical Constraints" you can see why the dual-policy
(constrained || disclosed & audited) was adopted. I don't think adopting a
single-policy (constrained) addresses any of the concerns raised then and
that still apply now.

Cheers

[Daniel Micay]

On 24/03/15 06:21 PM, Ryan Sleevi wrote:
>
> 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")

I think most people would consider those to be statements of fact.

PKI is a complete joke and there's a whole lot that could be done to
improve it but most of it isn't being done. I'm not criticizing the
technical work but rather policy decisions. Many of us spoke out about
including this specific CA in the first place and are not surprised that
it handed out a certificate to be used for MITM attacks.

DNSSEC/DANE isn't perfect and we don't have it because you (browser
vendors) wanted to solve the problem in other ways. It's not a full
solution to the problem but at least only one TLD gets screwed over by
something like this. Everyone and their dog gets a TLD now anyway.

> 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 didn't say his proposal wasn't a zero tolerance policy. I said that
about removing a CA for egregarious policy violations like this, if they
don't implemented a mechanism like CT to provide proof that they're not
doing it on a broader scale. They could also open-source their
infrastructure's code to demonstrate that it enforces what it should and
promise that it's what they're really running. They have no shortage of
options here.

Anyway, you can remove the shiny green lock and treat it as an insecure
site without breaking HTTPS. Breaking stuff is not an excuse when you
have all of these options available.

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

It would be a lot more productive if there was less dismissal of the
people pointing out that things are not nearly as unfixable as they're
being portrayed. The situation is only this bad because there's an
unwillingness to take actions causing minor pain in the short term (i.e.
weeks).

I think "incompetent" and "negligence" are perfect words to describe
people who can't even keep an OCSP server running.

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

I'm not even stating that it would make sense to do that for this case,
only that this case is the latest one identifying the serious problem of
the browser / OS vendors being unwilling to remove CAs.

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

I certainly agree that CT is a major step forwards and everyone working
on implementing it is doing a great thing. It's mostly a political issue
rather than a technical one though, as are other improvements.

It's also not very useful if nothing is done in response to incidents it
uncovers...

IMO, the biggest positive would be an endless stream of these incidents
being discovered and erasing any trust left in the current PKI system
and the people responsible for it on both ends.

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

I'm not making personal attacks. I'm pointing out a pattern of
consistent negligence in enforcing the policy.

There's also a consistent pattern of rejecting solutions to the problem
like treating some uses of TLS as insecure (like this one) but not
breaking it completely without any clear response as to why. Most bugs
related to tuning things related to PKI are closed as WONTFIX with
little attempt to explain.

People who make policy decisions impacting the security of millions of
users are not above criticism, especially when they reject the stuff
other people come up with (like DANE, a soft-fail untrusted form of
HTTPS, and more).

I'd be happy to make a
mozilla-is-irresponsible-for-shipping-a-browser-with-no-sandbox-and-not-enforcing-CA-policy-and-more
mailing list but I'd still express my strong opinions here too.

[Daniel Micay]

> I'd be happy to make a
> mozilla-is-irresponsible-for-shipping-a-browser-with-no-sandbox-and-not-enforcing-CA-policy-and-more
> mailing list but I'd still express my strong opinions here too.

IMO, refusal to actually enforce the CA policy is identical to other
stupid decisions like Firefox not using PIE (ASLR) on Linux. In that
case, it's because one or two users had a workflow of navigating to the
directory and running the binary directly via a specific file manager
that can't run PIE binaries because libmagic considers them to be a library.

The choice to place minor short-term pain faced by a tiny minority of
end users over the security of everyone else is a consistent one. The
policy decisions are brain-dead across the board in Mozilla projects and
only the opinion of Mozilla employees really matters, regardless of the
"community" claims.

I say this as someone who wasted countless hours (>800 commits, many of
them substantial) contributing to Mozilla projects and learned of their
outright contempt for their users and their community.

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.

[Ryan Sleevi]

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.

[Daniel Micay]

On 24/03/15 08:33 PM, Ryan Sleevi wrote:
> 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).

Sure, Debian's frozen release model doesn't support security. They'll
only really backport stuff with CVEs assigned and even then it's not a
sure thing.

I was just complaining on oss-security about the link on their main page
(which is https, but no HSTS/HPKP) using plain http for the ISO links
with no indication that it's insecure, and no link/instructions to
validate via signature.

Other distributions use the newer versions of their ca-certificates
package, so what they do there matters whether or not their release
model is sane.

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

It's not community driven. They openly accept community contributions.
The development is open, but no more open than Chromium's. It's not a
closed door mess like Android, sure. If you contribute to Mozilla
projects with the expectation that you'll be treated as an equal or even
close to that, you are going to end up very disappointed like myself.

Mozilla has a history of ignoring community and just digs deeper and
deeper into a hole. The responses from paid employees tend to stick to
bullshit talking points or there's no explanation at all. I often see
Chromium make awful choices and then reverse them when users turns out
to be overwhelming against it, but not Firefox.

Mozilla is certainly a lot better at duping people into volunteering to
the project than Google, I'll give you that. Their marketing is great
and they always stay on message promoting themselves as something they
are really not.

[Daniel Micay]

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

[Chris Palmer]

On Mar 24, 2015 14:55, "Daniel Micay" <danie...@gmail.com> wrote:
>
> Anyway, really hard to see how two browsers holding a majority of the
> market share do not have all of the cards in their hands. This happened
> because of your negligence and will continue to happen. It's a good
> thing you don't sell your browser to your users because then they'd have

> standing to sue you for the outrageous security claims. Can we please
> stop pretending that the people involved in PKI are responsible?

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

[Daniel Micay]

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

[Chris Palmer]

On Mar 24, 2015 16:11, "Daniel Micay" <danie...@gmail.com> wrote:
>
> On 24/03/15 06:21 PM, Ryan Sleevi wrote:
> >
> > 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")
>
> I think most people would consider those to be statements of fact.

Here are some facts:

* Browser people detected this misissuance
* Browser people acted fast to untrust the offending ICA
* Browser people conceived of and are implementing CT
* Browser people convinced CAs to implement CT by using their limited
political capital carefully
* Browser people conceived of and implemented key pinning
* Browser people opened up the CA/Browser Forum somewhat
* CAs don't want to go out of business
* Browser people can't break the internet
* A key way to improve things is to build, not burn, bridges
* The internet is loosely coupled, and the incentives and capabilities of
people using it vary widely
* Secure introduction in a globally distributed system is an unsolved
problem
* Even if by some chance you had the solution, you're going to have a hard
time getting heard now

[Daniel Micay]

> * Browser people detected this misissuance

This one, but not at least several others issued by this CA.

> * Browser people acted fast to untrust the offending ICA

Yes, but not the root which issued it in violation of many of the
policies for the trust store, despite strong language implying that this
would likely for violating a specific one of those rules.

> * Browser people conceived of and are implementing CT
> * Browser people convinced CAs to implement CT by using their limited
> political capital carefully

> * Browser people opened up the CA/Browser Forum somewhat

I'm well aware of that. I think the Chromium developers have done a
fantastic job on the technical end of things and that's the only place
where *I* see anything moving forwards. AFAIK, Mozilla dragged their
feet a lot on CT and isn't actively pushing for it with - correct me if
I'm wrong, but that's the strong impression I get from lurking on
relevant IRC channels.

> * Browser people conceived of and implemented key pinning

That's nice for Google and the other (dozen?) sites, but AFAIK you're
not willing to pin just any keys. It's not scalable and creates an
anti-competitive situation where the big companies have an inherent
security advantage. Letting CryptoCat and Tor pin their keys was a nice
move, but what about everyone else?

> * CAs don't want to go out of business

That's why browser vendors have more far more power than you're willing
to admit. You can kill their business by changing one a line of code...

> * Browser people can't break the internet

Taking away a green lock while not even downgrading to http doesn't
break the internet. It's not a black and white removal situation. If a
browser can take away the EV bar for lack of CT, it can certainly take
away the lock completely for egregarious lack of compliance with these
policies.

> * A key way to improve things is to build, not burn, bridges
> * The internet is loosely coupled, and the incentives and capabilities
> of people using it vary widely
> * Secure introduction in a globally distributed system is an unsolved
> problem

Sure, that's why a CA was added despite being known to distribute
malware and perform MITM attacks to crack down on political dissidents.

Determining whether to add a CA is very much a political decision and
it's essentially a matter of choosing sides since all users end up with
the same CAs.

> * Even if by some chance you had the solution, you're going to have a
> hard time getting heard now

The people who voiced strong, justified concerns against including this
CA weren't heard before. I doubt I'm saying anything that hasn't already
been said before on discussions you've read.

If I wanted to do that I'd just file a Chromium bug rather than ranting
on a mailing list where I've never seen any significant community input
taken into account before.

Trusting a CA known to distribute malware even after they've clearly
broken policies is more offensive than any words I can dream of
stringing together.

[Rob Stradling]

On 24/03/15 19:58, Florian Weimer wrote:
<snip>

> There's also an ongoing effort to defang CT and make the data much
> less useful, so CT could turn meaningless fairly soon.

Huh?

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

[Florian Weimer]

* Rob Stradling:

> On 24/03/15 19:58, Florian Weimer wrote:
> <snip>
>> There's also an ongoing effort to defang CT and make the data much
>> less useful, so CT could turn meaningless fairly soon.
>
> Huh?

The work on name redaction worries me.

[Florian Weimer]

* Florian Weimer:

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

According to the CNNIC CPS, the sub-CA certificate still exists:

“According to the agreement of CNNIC and Entrust, CNNIC intermediate
root CNNIC SSL is trusted by Entrust root certificate also. The domain
certificates issued by CNNIC Trusted Network Service Center may be
generated through different route either by CNNIC root or by Entrust
root.”

Certificate Practice Statement of the Trusted Network Service Center of
the China Internet Network Information Center (CNNIC)
Version No.: 3.03
Validity from July 1st, 2013
<http://www1.cnnic.cn/IS/fwqzs/CNNICfwqzsywgz/201208/W020130929345948738150.pdf>

However, Entrust does not list the sub-CA certificate here:

<http://www.entrust.net/about/third-party-sub-ca.htm>

As far as I can see, there are several explanations for that:

* It was omitted by accident.

* The CNNIC root was signed (although only signatures on the
intermediate CNNIC SSL CA certificate have been documented so far, I
think).

* Entrust assumes that once an organization has a root in the Mozilla
program, any sub-CAs controlled by that organization is exempted
from disclosure.

* The CNNIC CPS is incorrect, and they no longer run an
Entrust-sponsored sub-CA.

[Rob Stradling]

I wondered if that was what you were referring to.

The purpose of the name redaction work is to resolve a major barrier to
adoption of CT, without reducing the security. It is absolutely _not_
an effort to "defang CT"!

Please share your concerns on the TRANS list.

[Florian Weimer]

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

Sorry, Bruce, I saw your message just now, it was not properly
threaded.

It is good to know that the certificate was not extended. But as I
wrote in my other message, the CNNIC CPS from 2013 onwards claims that
the Entrust signature is still valid. :-(

[Erwann Abalea]

Le mercredi 25 mars 2015 07:02:06 UTC+1, Daniel Micay a écrit :
> > * Browser people detected this misissuance
>
> This one, but not at least several others issued by this CA.

Are you still talking about facts? Then please provide other mississued certificates.

> > * CAs don't want to go out of business
>
> That's why browser vendors have more far more power than you're willing
> to admit. You can kill their business by changing one a line of code...

Does killing CA business create a shining new good world free of all Evil(tm)?

> > * Even if by some chance you had the solution, you're going to have a
> > hard time getting heard now
>
> The people who voiced strong, justified concerns against including this
> CA weren't heard before. I doubt I'm saying anything that hasn't already
> been said before on discussions you've read.

They were heard. Their concerns were shared and studied. They weren't able to provide convincing arguments that the CA acted badly *as a CA*.
That's different *now*, and while we *now* have good arguments they behaved badly, but it doesn't make the past 5 years of rant more true. Get your timeline straight.

[Florian Weimer]

* Daniel Micay:

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

Ugh, surely there has to be a better way.

I sometimes get carried away and post acerbic comments about things
like the dynamics of maintaining a market share (sorry about that),
but what you propose is totally over the top.

The present can of worms is not just about an unwillingness to do the
right thing (whatever that is), but there are one or two unsolved
engineering problems involved. You simply can't make those go away by
media pressure.

[Gervase Markham]

On 25/03/15 10:27, Florian Weimer wrote:
> * The CNNIC CPS is incorrect, and they no longer run an
> Entrust-sponsored sub-CA.

I believe this is the correct answer. Quoting Bruce Morton in this thread:

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

Gerv

[Florian Weimer]

* Gervase Markham:

> On 25/03/15 10:27, Florian Weimer wrote:

>> * The CNNIC CPS is incorrect, and they no longer run an
>> Entrust-sponsored sub-CA.
>

> I believe this is the correct answer. Quoting Bruce Morton in this thread:
>
> "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."

Yes, I saw this message only after I had posted the above.

This leads to the question why Ernst & Young, CNNIC's auditors, have
not caught this discrepancy between the CPS and actual business
practice. The most recent audit
<https://cert.webtrust.org/SealFile?seal=1731&file=pdf> already covers
the time period when CNNIC ceased to be an Entrust sub-CA.

(I think to clean up this mess, we should focus on formal mistakes by
auditors, not things that can be downplayed as operational glitches.)

[Bruce]

The CNNIC CPS is incorrect. The intermediate certificate which Entrust issued to CNNIC has expired in March 1, 2012. The certificate was never reissued.

Please note that the intermediate certificate was issued from a 1024-bit RSA root which has been removed from Firefox.

Also note that the intermediate certificate had a pathlength of 0. This pathlength means that the Entrust root would not provide trust to any intermediate which CNNIC issued.