Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

CNNIC and legal jurisdiction

300 views
Skip to first unread message

Stephen Schultze

unread,
Jun 7, 2012, 11:23:19 AM6/7/12
to mozilla-dev-s...@lists.mozilla.org
Certificate Authorities are subject to the legal jurisdictions in which
they operate. Trusting a Certificate Authority can, depending on the
case, imply trust in the rule of law of that jurisdiction. As such, it
is reasonable to ask how trustworthy the rule of law is in a given CA's
jurisdiction, and how CA claims to maintain integrity and
trustworthiness in the face of coercive state actors. This is of course
one of the premises of a 2010 paper co-authored by Sid Stamm (who is a
peer in the Mozilla CA Certificates module).

The last time we discussed this issue was in the context of GlobalSign's
office in China. They assured us that because they hold their key
materials outside of the country and have non-China-based validation
checks in place, a coercive state actor would not succeed in compelling
rogue certificates.

CNNIC can offer no such assurance.

We know from ample evidence previously discussed in this forum that the
Chinese government surveils its citizens and others without meaningful
judicial oversight.

This constitutes a backdoor on the whole security model described in
their CPS, and is a threat to Mozilla users.

I'm sure that the CNNIC folks are well-meaning. They were very nice
when we visited at IETF Beijing
(https://www.dropbox.com/s/wvd43kymdnjawip/CNNIC_IETF_Beijing.jpg).
Unfortunately, they live and operate in a legal jurisdiction in which
their best intentions are undermined by the regime that governs them.
They are not even allowed by their government to participate directly in
the approval conversation we are having here. Despite all of their
technical expertise, CNNIC should not be granted authority to certify
any domain on the internet.

After all, in their own words, CNNIC "takes orders from the Ministry of
Information Industry (MII) to conduct daily business."

Steve

Gervase Markham

unread,
Jun 11, 2012, 6:46:01 AM6/11/12
to Stephen Schultze
On 07/06/12 16:23, Stephen Schultze wrote:
> Unfortunately, they live and operate in a legal jurisdiction in which
> their best intentions are undermined by the regime that governs them.
> They are not even allowed by their government to participate directly in
> the approval conversation we are having here.

Are you saying that based on recent assertions that people inside the
GFW cannot access this discussion, or do you have more specific
knowledge about CNNIC employees (who may well have a non-GFW connection)?

Gerv

Stephen Schultze

unread,
Jun 12, 2012, 3:29:17 PM6/12/12
to mozilla-dev-s...@lists.mozilla.org
I have no knowledge about what exceptions that CNNIC employees may have
to governmental censorship. Even if they have a non-GreatFireWall
connection, it's unclear whether they could "legally" use it for this
purpose. Based on their lack of participation in this forum, and
Kathleen's message, it seems that they either don't have access or that
access is hampered:
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/404c32c7a4d0e533#dbc8caabca60f326

This is, in any event, immaterial to the main point. CNNIC employees
would have no choice but to comply with the "legal" obligation to create
a rogue certificate if compelled to do so by the untrustworthy Chinese
government... or I suppose they *do* have a choice: be prosecuted by the
Chinese government.

This would not be counter to the assertion by CNNIC made on the bug,
stating that "We absolutely won’t deliver any Cert to any illegal
organization." (unless they contend that the Chinese Government is an
"illegal organization"):
https://bugzilla.mozilla.org/show_bug.cgi?id=607208#c16

But regardless of what assertions they make, the reality is that such
assertions cannot be trusted because there is insufficient judicial
oversight of government surveillance in their jurisdiction. As Sid
noted in his SSL MITM paper:

"The Chinese government, for example, has repeatedly compelled the
assistance of telecommunications and technology companies in assisting
it with its surveillance efforts "

Tom Lowenthal

unread,
Jun 12, 2012, 8:10:42 PM6/12/12
to mozilla-dev-s...@lists.mozilla.org
On 06/07/2012 08:23 AM, Stephen Schultze wrote:
> Certificate Authorities are subject to the legal jurisdictions in which
> they operate. Trusting a Certificate Authority can, depending on the
> case, imply trust in the rule of law of that jurisdiction. As such, it
> is reasonable to ask how trustworthy the rule of law is in a given CA's
> jurisdiction, and how CA claims to maintain integrity and
> trustworthiness in the face of coercive state actors. This is of course
> one of the premises of a 2010 paper co-authored by Sid Stamm (who is a
> peer in the Mozilla CA Certificates module).

In our CA root program, the CA makes promises in exchange for inclusion.
If we do not believe their promises, we should not include that CA. If a
CA breaks their promises, we should remove that CA.

I do not believe that CNNIC will comply with the Mozilla CA agreement. I
believe that MII will order CNNIC to violate the Mozilla CA agreement. I
believe that CNNIC would follow that order from MII to violate the
Mozilla CA agreement since CNNIC "takes orders from the Ministry of
Information Industry (MII) to conduct daily business".

For this reason, we should not approve this root inclusion request. If
our CA approval system does not provide grounds to reject an inclusion
request on this basis, then we have a major hole in our system.

David E. Ross

unread,
Jun 12, 2012, 8:32:14 PM6/12/12
to mozilla-dev-s...@lists.mozilla.org
I agree.

Furthermore, the lack of any comment in the newsgroup discussion from
anyone who is (1) an end-user of Mozilla products, (2) residing in
China, and (3) having at least the appearance of independence from CNNIC
and MMI leads me to believe that such individuals have been blocked from
providing negative comments on CNNIC's request. At least one
non-resident visitor to China has asserted that such a block does exist.
Thus, I recommend strongly against approving this request; and I would
also recommend strongly in favor of removing the existing CNNIC Root,
which I have marked as "untrusted" in my own configuration.

--

David E. Ross
<http://www.rossde.com/>.

Anyone who thinks government owns a monopoly on inefficient, obstructive
bureaucracy has obviously never worked for a large corporation.
� 1997 by David E. Ross

Gervase Markham

unread,
Jun 13, 2012, 6:27:24 AM6/13/12
to Stephen Schultze
On 12/06/12 20:29, Stephen Schultze wrote:
> I have no knowledge about what exceptions that CNNIC employees may have
> to governmental censorship. Even if they have a non-GreatFireWall
> connection, it's unclear whether they could "legally" use it for this
> purpose. Based on their lack of participation in this forum, and
> Kathleen's message, it seems that they either don't have access or that
> access is hampered:

I don't think Kathleen's message should be taken to imply that we have
knowledge that CNNIC are being hampered from contributing to this
discussion.

> This is, in any event, immaterial to the main point. CNNIC employees
> would have no choice but to comply with the "legal" obligation to create
> a rogue certificate if compelled to do so by the untrustworthy Chinese
> government... or I suppose they *do* have a choice: be prosecuted by the
> Chinese government.

In what way is this different from another CA operating under the
jurisdiction of another government? I'm pretty sure both the UK and the
US have laws which would allow them to secretly compel a CA to issue a
particular cert.

> But regardless of what assertions they make, the reality is that such
> assertions cannot be trusted because there is insufficient judicial
> oversight of government surveillance in their jurisdiction. As Sid
> noted in his SSL MITM paper:
>
> "The Chinese government, for example, has repeatedly compelled the
> assistance of telecommunications and technology companies in assisting
> it with its surveillance efforts "

Is your issue specific to CNNIC (why?), or any CA operating out of
mainland China? Are you suggesting that Mozilla needs a blacklist of
governments, such that we do not accept CAs under the jurisdiction of
those governments? How do you think such a blacklist could be created,
and using what criteria?

I guess this is a question for Tom and David as well, given their posts.

Gerv


Eddy Nigg

unread,
Jun 13, 2012, 7:05:00 AM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 06/13/2012 01:27 PM, From Gervase Markham:
> In what way is this different from another CA operating under the
> jurisdiction of another government? I'm pretty sure both the UK and
> the US have laws which would allow them to secretly compel a CA to
> issue a particular cert.

Which laws are those exactly? Can you point me to one? Which CA in the
US takes direct orders from the governments that would require them to
do that?

I also believe there is no filtering and interception policy in the US
as in China appears to be the case. As of recently I'm not entirely sure
about the UK though, there things seems to shift a bit....

--
Regards

Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

Moudrick M. Dadashov

unread,
Jun 13, 2012, 7:12:25 AM6/13/12
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Stephen Schultze

On 6/13/2012 1:27 PM, Gervase Markham wrote:
> On 12/06/12 20:29, Stephen Schultze wrote:
>> I have no knowledge about what exceptions that CNNIC employees may have
>> to governmental censorship. Even if they have a non-GreatFireWall
>> connection, it's unclear whether they could "legally" use it for this
>> purpose. Based on their lack of participation in this forum, and
>> Kathleen's message, it seems that they either don't have access or that
>> access is hampered:
> I don't think Kathleen's message should be taken to imply that we have
> knowledge that CNNIC are being hampered from contributing to this
> discussion.
>
>> This is, in any event, immaterial to the main point. CNNIC employees
>> would have no choice but to comply with the "legal" obligation to create
>> a rogue certificate if compelled to do so by the untrustworthy Chinese
>> government... or I suppose they *do* have a choice: be prosecuted by the
>> Chinese government.
> In what way is this different from another CA operating under the
> jurisdiction of another government? I'm pretty sure both the UK and the
> US have laws which would allow them to secretly compel a CA to issue a
> particular cert.
>
>> But regardless of what assertions they make, the reality is that such
>> assertions cannot be trusted because there is insufficient judicial
>> oversight of government surveillance in their jurisdiction. As Sid
>> noted in his SSL MITM paper:
>>
>> "The Chinese government, for example, has repeatedly compelled the
>> assistance of telecommunications and technology companies in assisting
>> it with its surveillance efforts "
> Is your issue specific to CNNIC (why?), or any CA operating out of
> mainland China? Are you suggesting that Mozilla needs a blacklist of
> governments, such that we do not accept CAs under the jurisdiction of
> those governments?
Black or grey list IMO makes sense. I'd not limit it to governments or
territories. Let me give you an example.

Imagine a company that owns tens of businesses all over the global
market and all these formally independent companies do business under
their own names. It's not easy to understand how the global empire
functions, but let's just look at the market sectors under the control
of these guys:

physical communication network infrastructure, Internet [backbone, IP
transit and last mile] access, DNS, web/application hosting, Data
center, Internet TV, mobile/fixed telephony, internet banking, bank user
authentication, bank document signing, electronic voting and finally a
CA business outside of their home country.

If you want to know what is really wrong here, just google "TeliaSonera
accused/abused" or something around that and have your own opinion. The
last time I spoke with the Swedish government rep (they partly own this
"private" business), he literally said: "the Swedish government was not
watching this company's business policies/practices outside of national
boundaries". In simple words: "money doesn't smell"...

We call this model a "pocket CA".

> How do you think such a blacklist could be created,
> and using what criteria?
good question, start with ownership, not easy but possible.

Thanks,
M.D.
> I guess this is a question for Tom and David as well, given their posts.
>
> Gerv
>
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy

Stephen Schultze

unread,
Jun 13, 2012, 10:35:36 AM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 6/13/12 6:27 AM, Gervase Markham wrote:
> On 12/06/12 20:29, Stephen Schultze wrote:
>> I have no knowledge about what exceptions that CNNIC employees may have
>> to governmental censorship. Even if they have a non-GreatFireWall
>> connection, it's unclear whether they could "legally" use it for this
>> purpose. Based on their lack of participation in this forum, and
>> Kathleen's message, it seems that they either don't have access or that
>> access is hampered:
>
> I don't think Kathleen's message should be taken to imply that we have
> knowledge that CNNIC are being hampered from contributing to this
> discussion.

Ok, then I'll just take their silence as the evidence... along with the
documentation in this newsgroup and on the bugzilla entry that posting
to Google Groups is blocked by the GFW. Supposedly Chinese people can
still post here by sending an email (although CNNIC hasn't done so). I
guess it's a matter of interpretation whether or not this counts as
"hampered," but as I noted before, this is a side issue.

>> This is, in any event, immaterial to the main point. CNNIC employees
>> would have no choice but to comply with the "legal" obligation to create
>> a rogue certificate if compelled to do so by the untrustworthy Chinese
>> government... or I suppose they *do* have a choice: be prosecuted by the
>> Chinese government.
>
> In what way is this different from another CA operating under the
> jurisdiction of another government? I'm pretty sure both the UK and the
> US have laws which would allow them to secretly compel a CA to issue a
> particular cert.

This, too, was discussed in the GlobalSign approval process:
https://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/ecc83d8b64b17e1/37dad4e372f34d65#8669f1cd8398414a

The difference is judicial oversight and meaningful rule of law.

>> But regardless of what assertions they make, the reality is that such
>> assertions cannot be trusted because there is insufficient judicial
>> oversight of government surveillance in their jurisdiction. As Sid
>> noted in his SSL MITM paper:
>>
>> "The Chinese government, for example, has repeatedly compelled the
>> assistance of telecommunications and technology companies in assisting
>> it with its surveillance efforts "
>
> Is your issue specific to CNNIC (why?), or any CA operating out of
> mainland China? Are you suggesting that Mozilla needs a blacklist of
> governments, such that we do not accept CAs under the jurisdiction of
> those governments? How do you think such a blacklist could be created,
> and using what criteria?

I'm considering the root approval that is in front of us today, which is
I believe the task that the community has been asked to perform.

It may well be that other root requests present similar problems based
on their jurisdiction of operations. It need not always be the case
that this results in non-approval, though. For example, the GlobalSign
approval ultimately went through because of certain assurances that they
made which are not applicable here (for the record, I didn't agree with
that approval, but such is the community consensus process).

Steve

Johnathan Nightingale

unread,
Jun 13, 2012, 10:37:02 AM6/13/12
to Tom Lowenthal, mozilla-dev-s...@lists.mozilla.org
On Jun 12, 2012, at 8:10 PM, Tom Lowenthal wrote:

> I do not believe that CNNIC will comply with the Mozilla CA agreement. I
> believe that MII will order CNNIC to violate the Mozilla CA agreement. I
> believe that CNNIC would follow that order from MII to violate the
> Mozilla CA agreement since CNNIC "takes orders from the Ministry of
> Information Industry (MII) to conduct daily business".
>
> For this reason, we should not approve this root inclusion request. If
> our CA approval system does not provide grounds to reject an inclusion
> request on this basis, then we have a major hole in our system.

Tom, I think Kathleen's pretty responsive to concrete feedback about specific areas of non-compliance with our policy, but "I do not believe… for this reason we should not approve" is a pretty hard standard to ask CAs to adhere to. Participation in the root and EV programs is at our sole discretion, but I'd also like us not to be capricious and arbitrary in that discretion.

CNNIC got slathered with innuendo when they applied for basic inclusion into the program and I was one of the loudest saying "Please, someone, anyone, show me a mis-issued CNNIC cert - they are easy to detect, non-repudiable, and conclusive!" So far I haven't gotten one, but if you have new information there, I'd be extremely keen to know it (as, I suspect, would Kathleen).

J

---
Johnathan Nightingale
Sr. Director of Firefox Engineering
@johnath

Stephen Schultze

unread,
Jun 13, 2012, 10:43:40 AM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 6/13/12 10:37 AM, Johnathan Nightingale wrote:
> On Jun 12, 2012, at 8:10 PM, Tom Lowenthal wrote:
>
>> I do not believe that CNNIC will comply with the Mozilla CA
>> agreement. I believe that MII will order CNNIC to violate the
>> Mozilla CA agreement. I believe that CNNIC would follow that order
>> from MII to violate the Mozilla CA agreement since CNNIC "takes
>> orders from the Ministry of Information Industry (MII) to conduct
>> daily business".
>>
>> For this reason, we should not approve this root inclusion request.
>> If our CA approval system does not provide grounds to reject an
>> inclusion request on this basis, then we have a major hole in our
>> system.
>
> Tom, I think Kathleen's pretty responsive to concrete feedback about
> specific areas of non-compliance with our policy, but "I do not
> believe� for this reason we should not approve" is a pretty hard
> standard to ask CAs to adhere to. Participation in the root and EV
> programs is at our sole discretion, but I'd also like us not to be
> capricious and arbitrary in that discretion.
>
> CNNIC got slathered with innuendo when they applied for basic
> inclusion into the program and I was one of the loudest saying
> "Please, someone, anyone, show me a mis-issued CNNIC cert - they are
> easy to detect, non-repudiable, and conclusive!" So far I haven't
> gotten one, but if you have new information there, I'd be extremely
> keen to know it (as, I suspect, would Kathleen).

Johnathan,

Mozilla's policy is to "determine which CA certificates are included in
software products distributed by Mozilla, based on the benefits and
risks of such inclusion to typical users of those products." This is
not a "presumed innocent" posture, but rather one that evaluates the
relative benefits and risks. The major risks here have been
well-documented by none other than one of the module peers, and there
has been no counter to this risk other than a claim that "nobody has
proven that harm has already occurred."

Even if a rogue certificate were discovered (and they are not, as you
claim, necessarily easy to detect, especially when used in targeted
fashion), the damage would already have been done.

Steve

Jan Schejbal

unread,
Jun 13, 2012, 2:41:40 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
Am 2012-06-13 16:37, schrieb Johnathan Nightingale:
> CNNIC got slathered with innuendo when they applied for basic
> inclusion into the program and I was one of the loudest saying
> "Please, someone, anyone, show me a mis-issued CNNIC cert - they are
> easy to detect, non-repudiable, and conclusive!" So far I haven't
> gotten one, but if you have new information there, I'd be extremely
> keen to know it (as, I suspect, would Kathleen).

I'd like to know what will happen even if such a cert shows up. After
all, there were multiple cases where false certificates were found from
reputable CAs. The CAs claimed that these were "honest mistakes" (i.e.
they did something terribly wrong, but they did not intentionally
mis-issue certs), and were allowed to stay in the program.

Note that I do NOT want to imply, nor do I believe, that any of these
false certificates were issued intentionally. AFAIK, the debate was also
limited to the question if someone doing such mistakes/showing such a
disregard for security can be a CA, but no claims of intentional
misissuing came up. (Except for the company-internal MITM cert, where
policy was changed after discovery)

Now, however, what if a fradulent cert signed by CNNIC shows up, and
CNNIC claims that they got hacked? Usually, it is extremely hard to
verify or falsify such claims, especially if great effort is put into
making false claims. Will Mozilla do the same thing as they did with the
other CAs (i.e. keep), or will they apply a different standard, and
remove the root?

The current discussion implies that if such a cert were to be found, the
root would be gone. However, this shows that there is obviously
significantly less trust in CNNIC than in the other CAs, where such
mistakes were tolerated.


Kind regards,
Jan

--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...


Phillip Hallam-Baker

unread,
Jun 13, 2012, 3:54:48 PM6/13/12
to Johnathan Nightingale, mozilla-dev-s...@lists.mozilla.org, Tom Lowenthal
+1

This argument seems to be deteriorating into 'we can't trust China'.
And that is really not a productive discussion.

I don't want to get into the various acts of perfidy perpetrated by
various governments but our own are not exactly perfect on that score.
When I first came to the US, not so long ago, we had Louis Freeh
abusing the power of the FBI in an attempt to bully people into not
deploying any strong crypto at all. And lets not forget which
government was the first to admit making the first cyber attack on a
civil nuclear facility.

The problem isn't 'China' or 'The US'. The problem is the spooks and
kooks and it does not matter much if they are Chinese or US. I have
been in meetings where recently retired admirals talk about the need
to plan for an immediate declaration of martial law in the case of a
cyber attack. It is pretty obvious that there are folk on both sides
who would love to see a gratifyingly expensive cyber arms race and are
trying to signal to China and Russia that they want to engage.


If you have been following the name constraints bit discussion on
PKIX, well take a look at the organization that the people opposing
that particular change ultimately work for. Then consider what the
effect of deploying NC bits in practice is likely to be (everyone revs
software as the bugs are ironed out). Then ask yourself why that
organization might want to avoid that type of examination.


There is a structural problem in that commercial CAs are designed to
provide controls against commercial risks. They are not designed to
provide an infrastructure to enable global crypto-revolution. They are
most certainly not designed to be resistant to coercion by state
actors and I don't see how any system can be unless it removes all
possibility of exercising discretion in which case the system is
utterly unusable (Give me a jar of the same magic pixie dust Sovereign
Keys uses to avoid problems and I can solve all the problems in CA
based PKI as well).

What we can do is to design transparency into the system so that even
though a default is possible, it is easily observable and thus
pointless.

I don't think the Google CT proposal is necessarily the way to go. In
fact I am pretty sure we should have some sort of workshop event first
and do some whiteboarding, brainstorming etc.




On Wed, Jun 13, 2012 at 10:37 AM, Johnathan Nightingale
<joh...@mozilla.com> wrote:
> On Jun 12, 2012, at 8:10 PM, Tom Lowenthal wrote:
>
>> I do not believe that CNNIC will comply with the Mozilla CA agreement. I
>> believe that MII will order CNNIC to violate the Mozilla CA agreement. I
>> believe that CNNIC would follow that order from MII to violate the
>> Mozilla CA agreement since CNNIC "takes orders from the Ministry of
>> Information Industry (MII) to conduct daily business".
>>
>> For this reason, we should not approve this root inclusion request. If
>> our CA approval system does not provide grounds to reject an inclusion
>> request on this basis, then we have a major hole in our system.
>
> Tom, I think Kathleen's pretty responsive to concrete feedback about specific areas of non-compliance with our policy, but "I do not believe… for this reason we should not approve" is a pretty hard standard to ask CAs to adhere to. Participation in the root and EV programs is at our sole discretion, but I'd also like us not to be capricious and arbitrary in that discretion.
>
> CNNIC got slathered with innuendo when they applied for basic inclusion into the program and I was one of the loudest saying "Please, someone, anyone, show me a mis-issued CNNIC cert - they are easy to detect, non-repudiable, and conclusive!" So far I haven't gotten one, but if you have new information there, I'd be extremely keen to know it (as, I suspect, would Kathleen).
>
> J
>
> ---
> Johnathan Nightingale
> Sr. Director of Firefox Engineering
> @johnath
>
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy



--
Website: http://hallambaker.com/

ianG

unread,
Jun 13, 2012, 7:48:45 PM6/13/12
to dev-secur...@lists.mozilla.org
There are two issues I see difficulties here. Firstly, what is the
principle by which they are to be knocked out, and how does that
principle apply to others?

with that in mind, here are some thoughts.


On 8/06/12 01:23 AM, Stephen Schultze wrote:
> Certificate Authorities are subject to the legal jurisdictions in which
> they operate. Trusting a Certificate Authority can, depending on the
> case, imply trust in the rule of law of that jurisdiction.

To amplify this point, many agreements have clauses in them reminding
parties of such responsibilities.

It's probably beyond the scope of a simple email discussion to get a
meaningful grip on how these contracts will play in such a situation -
which is to say that it is not entirely clear that one can conclude
anything easily from them.


> As such, it
> is reasonable to ask how trustworthy the rule of law is in a given CA's
> jurisdiction, and how CA claims to maintain integrity and
> trustworthiness in the face of coercive state actors. This is of course
> one of the premises of a 2010 paper co-authored by Sid Stamm (who is a
> peer in the Mozilla CA Certificates module).
>
> The last time we discussed this issue was in the context of GlobalSign's
> office in China. They assured us that because they hold their key
> materials outside of the country and have non-China-based validation
> checks in place, a coercive state actor would not succeed in compelling
> rogue certificates.

OK, but that likely means they hold their key materials in other places
and other checks are pervertable by other places. So we might validly
ask which place, and what perversions exist there.


> CNNIC can offer no such assurance.
>
> We know from ample evidence previously discussed in this forum that the
> Chinese government surveils its citizens and others without meaningful
> judicial oversight.


Well not quite. The Chinese government has arranged its laws so that
they can do so, within their law. This happens to be their legal process.

This concept happens to be rather unfamiliar and unpopular in other
countries. Specifically, the USA has a tradition of separation of
surveillance - the NSA is "banned" from surveilling its own citizens,
and there are some constitutional protections. But this separation is
less popular elsewhere, in the sense of not being as strong. If I
recall correction, Russia and France still maintain their rights to spy
on their own citizens, and Britain has its infamous RIP act.

http://en.wikipedia.org/wiki/Regulation_of_Investigatory_Powers_Act_2000

Which leads to two points, being that I'm not sure you can properly
state that there is no meaningful judicial oversight; more likely you
can state that the judicial oversight is incompatible with the
expectations of some other peoples. Secondly, other countries do the
same. Is this principle to be established and applied to them?

> This constitutes a backdoor on the whole security model described in
> their CPS, and is a threat to Mozilla users.


Well, it's one example of a general backdoor. Not to overstate the
case, but the backdoor has always existed, and it exists for every CA.

In some security schools of thought, the TTP is referred to as a CVP -
centralized vulnerability party - to emphasise the existance of the
backdoor. It is only in commercial PKI that the "backdoor" isn't
formally recognised as a threat, for normal marketing purposes, because
it makes it hard to sell certificates when they can be clearly breached
under legal process.

What we seem to be building here is a claim that CVPs in China are
somehow more vulnerable than those elsewhere. Sure. We just need to
analyse what "more" means.


> I'm sure that the CNNIC folks are well-meaning. They were very nice when
> we visited at IETF Beijing
> (https://www.dropbox.com/s/wvd43kymdnjawip/CNNIC_IETF_Beijing.jpg).
> Unfortunately, they live and operate in a legal jurisdiction in which
> their best intentions are undermined by the regime that governs them.


What are their best intentions? I would expect them to say that they
are getting SSL out as best they can and they are doing so under limited
and difficult circumstances. I would also say that they are succeeding
in doing that.

Question may reduce to, is the perfect the enemy of the good?


> They are not even allowed by their government to participate directly in
> the approval conversation we are having here.


I think that is no different in effect to most other CAs. Most other
CAs do not expect their people to participate in this forum. Instead,
communications go through one or two designated public voices, and
others are expected to stay out. This is just normal rules of business,
but they are harsh rules. If someone were to speak their mind in this
forum, they could expect to lose their jobs.

Nobody has ever demanded that CAs permit their people speak freely here
because it is understood that USA CAs in particular wrap their people up
in such overbearing NDAs that they can't reasonably talk even if given a
faux permission. The culture of the NDA is extremely strong, and it is
extremely damaging to this forum, we've just all grown used to it an no
longer notice it.

In sum, I'm not sure this point stands. The current situation is that
other than a few standouts, most CAs communicate through their official
mouthpieces.


> Despite all of their
> technical expertise, CNNIC should not be granted authority to certify
> any domain on the internet.
>
> After all, in their own words, CNNIC "takes orders from the Ministry of
> Information Industry (MII) to conduct daily business."


All businesses take instructions from their owners. It's a bit more
complicated when the business has entered into a contract to do X and
the owner states "do !X". We would need to analyse the contracts
carefully to see whether this statement applies equally to other CAs.

Where this does get interesting is that in the last year we have
discussed the principle that a CA is not permitted to ever do an MITM.
Is there ever an exception to this?

As a strawman, I suggest there is: if done under lawful order of an
appropriate court. I wish it weren't so, and I'd welcome attempts to
deal with this seriously -- but that won't be happening in any
discussion of CNNIC.



iang

Tom Lowenthal

unread,
Jun 13, 2012, 7:53:06 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 06/13/2012 03:27 AM, Gervase Markham wrote:

> In what way is this different from another CA operating under the
> jurisdiction of another government? I'm pretty sure both the UK and the
> US have laws which would allow them to secretly compel a CA to issue a
> particular cert.

Without engaging with the legal question, if a CA *did* issue a cert
like this, we should immediately revoke their root without further
conversation. This is the only way to impose a commercial pressure and
provide a financial incentive for CAs not to lie.
I think we need to make smart decisions that sensibly weigh the risks to
our users. If we think that a CA has a high risk of issuing fraudulent
certs, we shouldn't add them.

If I think that I'd be less secure with their root in my browser, and
that I'd tell anyone who asks that they should remove that root to
improve their security then I think that we shouldn't add that root.
We're making trust decisions on behalf of our users. Our only obligation
is to our users, not to any CA.

Sid, a module peer, has published an academic paper with observations
which should lead us to reasonably believe that adding this root places
our users at significantly increased risk of attack by a hostile actor.
A host of other evidence indicates that we might have quite some
difficulty identifying these attacks if they are done effectively.

Even though we have not seen conclusive evidence of a specific attack
from CNNIC, we *have* seen evidence that should convince us that adding
their root will reduce our users' expected security. We should therefore
not add them.



signature.asc

Tom Lowenthal

unread,
Jun 13, 2012, 7:58:01 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 06/13/2012 04:48 PM, ianG wrote:
> All businesses take instructions from their owners. It's a bit more
> complicated when the business has entered into a contract to do X and
> the owner states "do !X". We would need to analyse the contracts
> carefully to see whether this statement applies equally to other CAs.
>
> Where this does get interesting is that in the last year we have
> discussed the principle that a CA is not permitted to ever do an MITM.
> Is there ever an exception to this?
>
> As a strawman, I suggest there is: if done under lawful order of an
> appropriate court. I wish it weren't so, and I'd welcome attempts to
> deal with this seriously -- but that won't be happening in any
> discussion of CNNIC.

I think that no CA with a Mozilla-trusted root should ever facilitate
MiM attacks, whether compelled by contract, national law, blackmail, or
any other reason. That have an obligation to us never to facilitate
these attacks. If they have contradictory obligation somewhere else, then:

1. they were misleading when they promised to follow our rules, and
2. they have to choose which obligation is more important to them.

If they choose that other obligation, then we should remove their root
without further discussion.


signature.asc

David E. Ross

unread,
Jun 13, 2012, 8:30:13 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
This is the key issue. Legallities are a side issue.

When someone visits an HTTPS Web site using a Mozilla-based product,
there is not only authentication of the site but also encryption of data
flowing back and forth. I do not trust any certification authority
based in a nation with a totalitarian regime not to provide that regime
with the unencrypted content of such data. After all, such a regime may
have hacked the root certificate of a certification authority based in
other nations (e.g., the DigiNotar fiasco).

My objection to CNNIC would also apply to a request from a certification
authority with ties to the governments of Iran, Syria, Sundan, and
several other nations.

Eddy Nigg

unread,
Jun 13, 2012, 8:32:53 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 06/14/2012 02:58 AM, From Tom Lowenthal:
>
> I think that no CA with a Mozilla-trusted root should ever facilitate
> MiM attacks, whether compelled by contract, national law, blackmail, or
> any other reason. That have an obligation to us never to facilitate
> these attacks. If they have contradictory obligation somewhere else, then:
>
> 1. they were misleading when they promised to follow our rules, and
> 2. they have to choose which obligation is more important to them.

The Mozilla CA Policy has clear requirements under which circumstances a
certificate may be issued. For example for server certificates the
minimum requirement is a domain name control validation.

So this is the promise and obligation the CAs have to follow (at least).
The BR sets forth additional requirements for other aspects of the
certificates. In this respect the requirements have been clear for a
long time, if Mozilla thinks that a CA might not comply to it, this
could be obviously a problem.

ianG

unread,
Jun 13, 2012, 9:05:01 PM6/13/12
to dev-secur...@lists.mozilla.org
On 14/06/12 09:58 AM, Tom Lowenthal wrote:
> On 06/13/2012 04:48 PM, ianG wrote:
>> All businesses take instructions from their owners. It's a bit more
>> complicated when the business has entered into a contract to do X and
>> the owner states "do !X". We would need to analyse the contracts
>> carefully to see whether this statement applies equally to other CAs.
>>
>> Where this does get interesting is that in the last year we have
>> discussed the principle that a CA is not permitted to ever do an MITM.
>> Is there ever an exception to this?
>>
>> As a strawman, I suggest there is: if done under lawful order of an
>> appropriate court. I wish it weren't so, and I'd welcome attempts to
>> deal with this seriously -- but that won't be happening in any
>> discussion of CNNIC.
>
> I think that no CA with a Mozilla-trusted root should ever facilitate
> MiM attacks, whether compelled by contract, national law, blackmail, or
> any other reason. That have an obligation to us never to facilitate
> these attacks. If they have contradictory obligation somewhere else, then:
>
> 1. they were misleading when they promised to follow our rules, and
> 2. they have to choose which obligation is more important to them.
>
> If they choose that other obligation, then we should remove their root
> without further discussion.



OK, so this works as long as the law isn't applied to Mozilla.

Has anyone thought to get (say) the EFF or similar lawyers to have a
look at this question? They have a bit of track record in dealing with
this very issue in a local law context.

iang

Phillip Hallam-Baker

unread,
Jun 13, 2012, 9:08:12 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
Since Iran and Sudan are both under a US embargo, there is nothing
Mozilla could do with them anyway.

I don't think this issue can be addressed by having people shout out
countries they don't trust on an open mailing list. That is going to
get pretty unpleasant pretty quickly. Actually I think it already has.

And sticking an invalid return address into your email is a pretty
silly thing to do.


On Wed, Jun 13, 2012 at 8:30 PM, David E. Ross <nob...@nowhere.invalid> wrote:
> On 6/13/12 4:58 PM, Tom Lowenthal wrote:
> This is the key issue.  Legallities are a side issue.
>
> When someone visits an HTTPS Web site using a Mozilla-based product,
> there is not only authentication of the site but also encryption of data
> flowing back and forth.  I do not trust any certification authority
> based in a nation with a totalitarian regime not to provide that regime
> with the unencrypted content of such data.  After all, such a regime may
> have hacked the root certificate of a certification authority based in
> other nations (e.g., the DigiNotar fiasco).
>
> My objection to CNNIC would also apply to a request from a certification
> authority with ties to the governments of Iran, Syria, Sundan, and
> several other nations.
>
> --
>
> David E. Ross
> <http://www.rossde.com/>.
>
> Anyone who thinks government owns a monopoly on inefficient, obstructive
> bureaucracy has obviously never worked for a large corporation.
> © 1997 by David E. Ross

Phillip Hallam-Baker

unread,
Jun 13, 2012, 9:17:13 PM6/13/12
to ianG, dev-secur...@lists.mozilla.org
Seems to me that the correct approach to take here would be to copy
the approach taken by banks who face a real threat of coercion of
their employees.

Every bank I have dealt with has the same policy wrt robberies. The
staff must hand over the cash without question. In fact many have a
policy of sacking someone on the spot if they don't comply (unless
there is some other issue).


The key thing with cyber warfare is that it relies on secrecy. No
intel service is going to be coercing a CA into doing anything that is
going to be observable and observed.




On Wed, Jun 13, 2012 at 9:05 PM, ianG <ia...@iang.org> wrote:
> On 14/06/12 09:58 AM, Tom Lowenthal wrote:
>>
>> On 06/13/2012 04:48 PM, ianG wrote:
>>>
>>> All businesses take instructions from their owners.  It's a bit more
>>> complicated when the business has entered into a contract to do X and
>>> the owner states "do !X".  We would need to analyse the contracts
>>> carefully to see whether this statement applies equally to other CAs.
>>>
>>> Where this does get interesting is that in the last year we have
>>> discussed the principle that a CA is not permitted to ever do an MITM.
>>> Is there ever an exception to this?
>>>
>>> As a strawman, I suggest there is:  if done under lawful order of an
>>> appropriate court.  I wish it weren't so, and I'd welcome attempts to
>>> deal with this seriously -- but that won't be happening in any
>>> discussion of CNNIC.
>>
>>
>> I think that no CA with a Mozilla-trusted root should ever facilitate
>> MiM attacks, whether compelled by contract, national law, blackmail, or
>> any other reason. That have an obligation to us never to facilitate
>> these attacks. If they have contradictory obligation somewhere else, then:
>>
>> 1. they were misleading when they promised to follow our rules, and
>> 2. they have to choose which obligation is more important to them.
>>
>> If they choose that other obligation, then we should remove their root
>> without further discussion.
>
>
>
>
> OK, so this works as long as the law isn't applied to Mozilla.
>
> Has anyone thought to get (say) the EFF or similar lawyers to have a look at
> this question?  They have a bit of track record in dealing with this very
> issue in a local law context.
>
> iang
>

Stephen Schultze

unread,
Jun 13, 2012, 9:28:27 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 6/13/12 7:48 PM, ianG wrote:
> Which leads to two points, being that I'm not sure you can properly
> state that there is no meaningful judicial oversight; more likely you
> can state that the judicial oversight is incompatible with the
> expectations of some other peoples. Secondly, other countries do the
> same. Is this principle to be established and applied to them?

It's not about the expectations of some peoples versus others. It's
about the compatibility of the rule of law in a particular jurisdiction
with the requirements of the Mozilla Cert Policy. For example, is there
significant risk that the Chinese government would succeed in compelling
CNNIC to "knowingly issue certificates without the knowledge of the
entities whose information is referenced in the certificates"?

The answer appears to be "yes," because of the way the rule of law and
judicial oversight works in that jurisdiction. It also appears, based
on past behavior of the Chinese government, that such a scenario is
possible or even probable.

The task of the community in the root approval process is to asses
whether this is an acceptable risk based on the purported benefits.
It's not an easy conversation to have, but it's important.

It's not politics or imperialism or viewpoint or "shouting out
countries" as PHB says... it's just logic.

Yes, of course it would apply to other countries. I think you'd have a
much harder time making a case about the US or UK, but there's no reason
to categorically rule them out. Feel free to discuss it when roots
based in those jurisdictions come up for review.

Fun factoid: Microsoft still includes in their root list the CA of the
Government of Tunisia... the cert is from before the ouster of dictator
Ben Ali. Mozilla does not (and never has).

David E. Ross

unread,
Jun 13, 2012, 10:42:20 PM6/13/12
to mozilla-dev-s...@lists.mozilla.org
On 6/13/12 6:08 PM, Phillip Hallam-Baker wrote [in part]:
> And sticking an invalid return address into your email is a pretty
> silly thing to do.

It's not silly when posting to newsgroups on which spammers' E-mail
address harvesters can operate. In any case, my real E-mail address is
seen in the complete headers on the Organization: header-line.

Peter Gutmann

unread,
Jun 14, 2012, 4:36:18 AM6/14/12
to jan.sche...@gmx.de, mozilla-dev-s...@lists.mozilla.org
Jan Schejbal <jan.sche...@gmx.de> writes:
>Am 2012-06-13 16:37, schrieb Johnathan Nightingale:
>> CNNIC got slathered with innuendo when they applied for basic
>> inclusion into the program and I was one of the loudest saying
>> "Please, someone, anyone, show me a mis-issued CNNIC cert - they are
>> easy to detect, non-repudiable, and conclusive!" So far I haven't
>> gotten one, but if you have new information there, I'd be extremely
>> keen to know it (as, I suspect, would Kathleen).
>
>I'd like to know what will happen even if such a cert shows up. After all,
>there were multiple cases where false certificates were found from reputable
>CAs. The CAs claimed that these were "honest mistakes" (i.e. they did
>something terribly wrong, but they did not intentionally mis-issue certs),
>and were allowed to stay in the program.

I've been trying to hold back from posting a mini-rant about that as well. As
far as we can tell, neither CNNIC not Turktrust, another perpetual CA
whipping-boy, have ever:

- Sold certs to the Russian mafia.
- Sold certs for large, well-known organisations like Microsoft, Apple, etc,
to entities who quite obviously weren't Microsoft, Apple, etc.
- Sold invalid EV certs.
- Sold certs containing unqualified names, RFC 1918 addresses, or a million
other problems.
- Outsourced their certificate issuing to Iran.
- [Three more pages of problems that large, well-known CAs have been caught
with].

The sole reason why anyone is complaining about CNNIC is because of the first
'C' in the name (and for Turktrust it's the first four letters). If they were
called VeriGlobalTrustCertSign then no-one would bat an eyelid.

A second point, which doesn't seem to have come up yet, is that for any
untrustworthy CA $ut-ca (call them CNNIC, Turktrust, Diginotar, Comodo, or
Verisign, whoever you think is most appropriate) we *need* CAs like $ut-ca in
the system because it means that we have to build a system that's more than
just the complete house of cards we have at the moment. If any random CA can
bring down the entire house of cards then the entire system is broken.
Conversely, if the system really does work then it should be able to cope with
the presence of $ut-ca. Saying "our system is so incredibly fragile that we
have to exclude $ut-ca in order to avoid complete collapse" is an admission
that the whole thing doesn't work.

Peter.

Eddy Nigg

unread,
Jun 14, 2012, 5:07:24 AM6/14/12
to mozilla-dev-s...@lists.mozilla.org
On 06/14/2012 11:36 AM, From Peter Gutmann:
> The sole reason why anyone is complaining about CNNIC is because of
> the first 'C' in the name (and for Turktrust it's the first four letters).

The only thing that really bothers me with all this - only AFTER CNNIC
was already included in the browser (I've been actually reviewing it
back at that time and commented on their inclusion request) a huge
outcry from Chinese users happened, mostly at Bugzilla and also
sometimes here.

Today we are back at another discussion and.... NOTHING. This is
disturbing that nobody appears to have anything to say from all those
that previously commented at the bug and elsewhere. What's going on? Is
this real? Why?

Gervase Markham

unread,
Jun 14, 2012, 5:12:38 AM6/14/12
to mozilla-dev-s...@lists.mozilla.org
On 13/06/12 12:05, Eddy Nigg wrote:
> On 06/13/2012 01:27 PM, From Gervase Markham:
>> In what way is this different from another CA operating under the
>> jurisdiction of another government? I'm pretty sure both the UK and
>> the US have laws which would allow them to secretly compel a CA to
>> issue a particular cert.
>
> Which laws are those exactly? Can you point me to one?

I'm pretty sure the UK Government could use the Regulation of
Investigatory Powers Act:
http://en.wikipedia.org/wiki/Regulation_of_Investigatory_Powers_Act_2000
to do this.

In the US, they could use a National Security Letter:
http://en.wikipedia.org/wiki/National_Security_Letter
under the USA PATRIOT Act:
http://en.wikipedia.org/wiki/US_PATRIOT_Act

The argument would be that the cert is necessarily for legal covert
surveillance of a particular individual or group.

Gerv

Gervase Markham

unread,
Jun 14, 2012, 5:29:39 AM6/14/12
to jan.sche...@gmx.de
On 13/06/12 19:41, Jan Schejbal wrote:
> Am 2012-06-13 16:37, schrieb Johnathan Nightingale:
>> CNNIC got slathered with innuendo when they applied for basic
>> inclusion into the program and I was one of the loudest saying
>> "Please, someone, anyone, show me a mis-issued CNNIC cert - they are
>> easy to detect, non-repudiable, and conclusive!" So far I haven't
>> gotten one, but if you have new information there, I'd be extremely
>> keen to know it (as, I suspect, would Kathleen).
>
> I'd like to know what will happen even if such a cert shows up.

As in all cases, it depends on the circumstances.

> Now, however, what if a fradulent cert signed by CNNIC shows up, and
> CNNIC claims that they got hacked? Usually, it is extremely hard to
> verify or falsify such claims, especially if great effort is put into
> making false claims. Will Mozilla do the same thing as they did with the
> other CAs (i.e. keep), or will they apply a different standard, and
> remove the root?

It is factually not true that Mozilla has kept all CAs who issued
fraudulent certs and then said "er, we got hacked".

DigiNotar claimed this. We pulled their roots anyway.

Gerv

Gervase Markham

unread,
Jun 14, 2012, 5:31:57 AM6/14/12
to Stephen Schultze
On 14/06/12 02:28, Stephen Schultze wrote:
> Yes, of course it would apply to other countries. I think you'd have a
> much harder time making a case about the US or UK, but there's no reason
> to categorically rule them out. Feel free to discuss it when roots
> based in those jurisdictions come up for review.

I don't think that works. If we are to have a new doctrine of
"untrustworthy host country", then we need to understand what our
criteria are, and an important part of that process is looking at
existing countries which host CAs and deciding whether they would be in
or out under various proposed sets of criteria.

Gerv

Gervase Markham

unread,
Jun 14, 2012, 5:32:23 AM6/14/12
to Tom Lowenthal
On 14/06/12 00:53, Tom Lowenthal wrote:
> On 06/13/2012 03:27 AM, Gervase Markham wrote:
>
>> In what way is this different from another CA operating under the
>> jurisdiction of another government? I'm pretty sure both the UK and the
>> US have laws which would allow them to secretly compel a CA to issue a
>> particular cert.
>
> Without engaging with the legal question, if a CA *did* issue a cert
> like this, we should immediately revoke their root without further
> conversation. This is the only way to impose a commercial pressure and
> provide a financial incentive for CAs not to lie.

I agree. But that fact isn't an argument for or against the inclusion of
CNNIC.

If you want to have a doctrine of "untrustworthy host country", then you
need to come up with a clear definition for who 'qualifies'.

> I think we need to make smart decisions that sensibly weigh the risks to
> our users. If we think that a CA has a high risk of issuing fraudulent
> certs, we shouldn't add them.

I agree; so let's define "high".

> If I think that I'd be less secure with their root in my browser, and
> that I'd tell anyone who asks that they should remove that root to
> improve their security then I think that we shouldn't add that root.

As Jonathan said, I would find it hard to use "Tom's gut feeling" (or
even "the majority of gut feelings among module peers") as our
definition of "untrustworthy host country".

> Sid, a module peer, has published an academic paper with observations
> which should lead us to reasonably believe that adding this root places
> our users at significantly increased risk of attack by a hostile actor.
> A host of other evidence indicates that we might have quite some
> difficulty identifying these attacks if they are done effectively.

I think we should be changing our browser and the SSL ecosystem to make
such attacks easier to detect. Pinning is the obvious technical route to
that end. That's how DigiNotar was discovered.

Gerv

Erwann Abalea

unread,
Jun 14, 2012, 8:28:35 AM6/14/12
to mozilla-dev-s...@lists.mozilla.org
Le jeudi 14 juin 2012 11:07:24 UTC+2, Eddy Nigg a écrit :
> On 06/14/2012 11:36 AM, From Peter Gutmann:
> > The sole reason why anyone is complaining about CNNIC is because of
> > the first 'C' in the name (and for Turktrust it's the first four letters).
>
> The only thing that really bothers me with all this - only AFTER CNNIC
> was already included in the browser (I've been actually reviewing it
> back at that time and commented on their inclusion request) a huge
> outcry from Chinese users happened, mostly at Bugzilla and also
> sometimes here.
>
> Today we are back at another discussion and.... NOTHING. This is
> disturbing that nobody appears to have anything to say from all those
> that previously commented at the bug and elsewhere. What's going on? Is
> this real? Why?

That's a good question. This request has been suspended for several months, I discovered it when Kathleen announced it. In the meantime, no chinese individual posted anything on it. Since the announcement here, only one individual commented on the bugzilla ticket.

I now reject the argument of Chinese government coercion. I agree it's still possible, but the recent Flame events unbalanced all this. Comparing "potential Chinese coercion actions on CNNIC" against "real attacks on MD5-enabled CA used to defeat Windows Update and propagate a virus" should be convincing.

Phillip Hallam-Baker

unread,
Jun 14, 2012, 9:14:00 AM6/14/12
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
When I was working at CERN developing crypto code for the Web back in
1993/4 I was getting the Jacob Appelbaum treatment of being searched
by customs entering and leaving the UK (the French only searched when
I was entering).

The UK System X telephone exchange protocols were deliberately
designed so that every telephone handset could be turned into a
passive bugging device whether it was on the hook or not. In the old
days when you could only get your phone from BT and it had to be
hardwired into the socket, MI6 could listen into any conversation in
range of a telephone handset microphone by just sending it the signal
'turn on microphone'.

One of the main reasons that the Web took off was that the US White
House adopted the Web as a publication standard. One of the people
involved recently told me that they were aware of the Web long before
Mosaic as CERN is one of the most intensively spied on research labs
on the planet.

Then there is the Bush administration torture program, the warrantless
wiretap program and the ongoing internment without trial at
Guantanamo. How can anyone in the US point the finger at China with a
straight face? Rule of law there was suspended in 2000 when Katherine
Harris and the Supreme Court conspired to steal the presidential
election for that guy who blew $5 billion on tax cuts for the 1% and
killed half a million people in an attempt to invade Mesopotamia.

All that despite the fact that the statistics show that all these
programs were an abject failure when the UK Heath government attempted
to apply them in Northern Ireland after the previous Wilson government
sent the troops in to protect the Catholic population from Protestant
terrorist gangs. The provisional IRA created by the Heath government
policies which depended on support from the protestant terrorist
leaders to stay in office. The number of deaths due to terrorism
dropped to a third immediately after HMG applied the 'criminalization'
strategy modelled after the approach successfully applied by the West
German government against the RAF (Baader-Meinhof).


So lets not get into a political conversation about whose government
is best OK? As I pointed out before, there is a long history of
lawless abuse of power in the US, the UK and pretty much every Western
power if people want to bother to look. And those abuses bear a
striking resemblance to the pattern of abuse in China.

The only reason we don't mention them is that we are trained to
consider it impolite to bring up such subjects in conversation and to
consider the people who insist on mentioning the abuses to be the
dangerous radicals rather than the people who commit them. They get
tenured professorships in Stanford and seats on corporate boards.



On Thu, Jun 14, 2012 at 5:12 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 13/06/12 12:05, Eddy Nigg wrote:
>> On 06/13/2012 01:27 PM, From Gervase Markham:
>>> In what way is this different from another CA operating under the
>>> jurisdiction of another government? I'm pretty sure both the UK and
>>> the US have laws which would allow them to secretly compel a CA to
>>> issue a particular cert.
>>
>> Which laws are those exactly? Can you point me to one?
>
> I'm pretty sure the UK Government could use the Regulation of
> Investigatory Powers Act:
> http://en.wikipedia.org/wiki/Regulation_of_Investigatory_Powers_Act_2000
> to do this.
>
> In the US, they could use a National Security Letter:
> http://en.wikipedia.org/wiki/National_Security_Letter
> under the USA PATRIOT Act:
> http://en.wikipedia.org/wiki/US_PATRIOT_Act
>
> The argument would be that the cert is necessarily for legal covert
> surveillance of a particular individual or group.
>
> Gerv

Phillip Hallam-Baker

unread,
Jun 14, 2012, 9:21:24 AM6/14/12
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Tom Lowenthal
On Thu, Jun 14, 2012 at 5:32 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 14/06/12 00:53, Tom Lowenthal wrote:

>> Sid, a module peer, has published an academic paper with observations
>> which should lead us to reasonably believe that adding this root places
>> our users at significantly increased risk of attack by a hostile actor.
>> A host of other evidence indicates that we might have quite some
>> difficulty identifying these attacks if they are done effectively.
>
> I think we should be changing our browser and the SSL ecosystem to make
> such attacks easier to detect. Pinning is the obvious technical route to
> that end. That's how DigiNotar was discovered.

+1 but I think we need to proceed in a slightly different direction to
merely deploying pinning.

The pinning reports must have been warning the user of a problem long
before Google were aware that the problem existed. In fact it was the
dissidents walking back the cat after arrests that led to Google being
notified.

So I believe that what we need is a combination of security policy
(including pinning) and an infrastructure that allows policy
violations to be trapped and acted upon.

In other words we need to move the model from thinking that security
is only about protecting the user of the client to protecting the
community of users.

--
Website: http://hallambaker.com/

Stephen Schultze

unread,
Jun 14, 2012, 9:32:47 AM6/14/12
to mozilla-dev-s...@lists.mozilla.org
The notion that this is a "new doctrine" is a red herring. The current
policy says that requests should be evaluated based on risk to end users
and criteria like whether or not the CA is likely to "knowingly issue
certificates without the knowledge of the entities whose information is
referenced in the certificates." Either your risk analysis is holistic,
or you should specifically disclaim certain types of risk that Mozilla
is unwilling to consider.

Sure, you should apply this standard across all countries. This does
not require an extensive new standard to be defined before you can start
doing this... the same way that many risk factors are assessed on a
case-by-case basis when they come up in the review process.

I have proposed the criteria of substantive judicial review of
unconstrained government-compelled surveillance. This mitigates the
types of risks identified in the Mozilla Cert Policy. In the US and UK,
there is good evidence of this being in place (even if I don't always
agree with the outcome). In China, the opposite seems to be true.

But misdirection of the conversation to other countries distracts from
frank discussion of the local facts for the CA being discussed, and I
have yet to see folks on the list engage with that in earnest.

Making other technical fixes to the system that mitigate these risks is
also encouraged, but to the extent that those solutions are not deployed
today and proven to work, the risks will still apply.

Phillip Hallam-Baker

unread,
Jun 14, 2012, 10:16:44 AM6/14/12
to Stephen Schultze, mozilla-dev-s...@lists.mozilla.org
It does not appear that there has been any judicial review of the use
of torture by US government or the warrantless wiretap program. In
fact the US courts seem to have studiously avoided making any ruling.

Waterboarding is certainly torture under US and international law. A
Japanese general was executed for use of waterboarding as a war crime.
And the warrantless wiretap program was obviously unconstitutional.

Seems to me that this proposal is a bunch of jingoistic nonsense
rather than a set of objective criteria.


On Thu, Jun 14, 2012 at 9:32 AM, Stephen Schultze
<sjschult...@gmail.com> wrote:
> On 6/14/12 5:31 AM, Gervase Markham wrote:
>>
> The notion that this is a "new doctrine" is a red herring.  The current
> policy says that requests should be evaluated based on risk to end users and
> criteria like whether or not the CA is likely to "knowingly issue
> certificates without the knowledge of the entities whose information is
> referenced in the certificates."  Either your risk analysis is holistic, or
> you should specifically disclaim certain types of risk that Mozilla is
> unwilling to consider.
>
> Sure, you should apply this standard across all countries.  This does not
> require an extensive new standard to be defined before you can start doing
> this... the same way that many risk factors are assessed on a case-by-case
> basis when they come up in the review process.
>
> I have proposed the criteria of substantive judicial review of unconstrained
> government-compelled surveillance.  This mitigates the types of risks
> identified in the Mozilla Cert Policy.  In the US and UK, there is good
> evidence of this being in place (even if I don't always agree with the
> outcome).  In China, the opposite seems to be true.
>
> But misdirection of the conversation to other countries distracts from frank
> discussion of the local facts for the CA being discussed, and I have yet to
> see folks on the list engage with that in earnest.
>
> Making other technical fixes to the system that mitigate these risks is also
> encouraged, but to the extent that those solutions are not deployed today
> and proven to work, the risks will still apply.
>

Stephen Schultze

unread,
Jun 14, 2012, 10:23:57 AM6/14/12
to mozilla-dev-s...@lists.mozilla.org
I'm not sure where torture fits in to CA risk analysis, although these
conversations unfortunately seem to slide toward these types of
unhelpful discussions.

EFF has documented the substantial judicial (and other) review of the
warrantless wiretapping program:
https://www.eff.org/issues/nsa-spying

They don't necessarily agree with where it's gone, nor do I, but there
it is.

But let's assume that Mozilla disagrees, and thinks that the US behavior
is a significant risk to end users. I suppose the reasoning is that
"everybody does it", therefore Mozilla won't consider it in the risk
analysis. If that's the case, I'd like to see that stated explicitly.

Phillip Hallam-Baker

unread,
Jun 14, 2012, 11:00:41 AM6/14/12
to Stephen Schultze, mozilla-dev-s...@lists.mozilla.org
On Thu, Jun 14, 2012 at 10:23 AM, Stephen Schultze
<sjschult...@gmail.com> wrote:
> I'm not sure where torture fits in to CA risk analysis, although these
> conversations unfortunately seem to slide toward these types of unhelpful
> discussions.

You decided to engage in a series of unsubstantiated attacks on China.
I pointed out that objectively the same criteria would exclude US CAs.
I don't see how that is off topic.


> EFF has documented the substantial judicial (and other) review of the
> warrantless wiretapping program:
> https://www.eff.org/issues/nsa-spying

Which only took place after it was discovered and mostly consisted of
the courts deciding that they were going to avoid doing anything.

As the page says "EFF is fighting these illegal activities on multiple
fronts.". Note the use of the future tense as in continuing to fight
as in, the courts are still trying to dodge responsibility and avoid
holding their political patrons accountable.

> They don't necessarily agree with where it's gone, nor do I, but there it
> is.

So the standard you propose is judicial review even if it is clear
that the review in question is going to be futile and ignore the
actual behavior at issue?

How does a sham judicial review do anything to mitigate the risks you
are concerned about?

> But let's assume that Mozilla disagrees, and thinks that the US behavior is
> a significant risk to end users.  I suppose the reasoning is that "everybody
> does it", therefore Mozilla won't consider it in the risk analysis.  If
> that's the case, I'd like to see that stated explicitly.

The solution here is what Gerv, Peter, I and several others have been
proposing: Transparency controls that are designed to ensure that any
government coerced compromise becomes apparent.


> On 6/14/12 10:16 AM, Phillip Hallam-Baker wrote:
>>

Stephen Schultze

unread,
Jun 14, 2012, 11:51:48 AM6/14/12
to mozilla-dev-s...@lists.mozilla.org
On 6/14/12 11:00 AM, Phillip Hallam-Baker wrote:
> On Thu, Jun 14, 2012 at 10:23 AM, Stephen Schultze
> <sjschult...@gmail.com> wrote:
>> I'm not sure where torture fits in to CA risk analysis, although these
>> conversations unfortunately seem to slide toward these types of unhelpful
>> discussions.
>
> You decided to engage in a series of unsubstantiated attacks on China.
> I pointed out that objectively the same criteria would exclude US CAs.
> I don't see how that is off topic.

Torture is off topic and only serves to unhelpfully push us toward a
Godwin's Law violation.

The Chinese government's tactic of compelling companies to help them
with surveillance is broadly accepted as fact, as cited by the
peer-reviewed article published by one of the module owners.

>> EFF has documented the substantial judicial (and other) review of the
>> warrantless wiretapping program:
>> https://www.eff.org/issues/nsa-spying
>
> Which only took place after it was discovered and mostly consisted of
> the courts deciding that they were going to avoid doing anything.
>
> As the page says "EFF is fighting these illegal activities on multiple
> fronts.". Note the use of the future tense as in continuing to fight
> as in, the courts are still trying to dodge responsibility and avoid
> holding their political patrons accountable.

This is what we call the adversarial process. This is desirable.

>> They don't necessarily agree with where it's gone, nor do I, but there it
>> is.
>
> So the standard you propose is judicial review even if it is clear
> that the review in question is going to be futile and ignore the
> actual behavior at issue?
>
> How does a sham judicial review do anything to mitigate the risks you
> are concerned about?

I don't think that the EFF or others on the leading edge of this fight
would characterize the standard of judicial review in the US this way.
That being said, if you'd like to argue that this is the case, go ahead.

>> But let's assume that Mozilla disagrees, and thinks that the US behavior is
>> a significant risk to end users. I suppose the reasoning is that "everybody
>> does it", therefore Mozilla won't consider it in the risk analysis. If
>> that's the case, I'd like to see that stated explicitly.
>
> The solution here is what Gerv, Peter, I and several others have been
> proposing: Transparency controls that are designed to ensure that any
> government coerced compromise becomes apparent.

Indeed, such controls are useful (and I have been vociferously arguing
for some of them) but many are not present today nor are they comprehensive.

Either the threat scenario is real or it's not. You seem to think it's
real, but too widespread to combat. If it's real but Mozilla chooses
not to consider it in making root inclusion decisions, let's hear that.

In any case, this back-and-forth, like others I have had with you, has
become quite impolite. Feel free to take a parting shot, but I'm done
with responding to your unhelpful aspersions.

Tom Lowenthal

unread,
Jun 14, 2012, 2:23:34 PM6/14/12
to mozilla-dev-s...@lists.mozilla.org
On 06/14/2012 01:36 AM, Peter Gutmann wrote:
> A second point, which doesn't seem to have come up yet, is that for any
> untrustworthy CA $ut-ca (call them CNNIC, Turktrust, Diginotar, Comodo, or
> Verisign, whoever you think is most appropriate) we *need* CAs like $ut-ca in
> the system because it means that we have to build a system that's more than
> just the complete house of cards we have at the moment. If any random CA can
> bring down the entire house of cards then the entire system is broken.
> Conversely, if the system really does work then it should be able to cope with
> the presence of $ut-ca. Saying "our system is so incredibly fragile that we
> have to exclude $ut-ca in order to avoid complete collapse" is an admission
> that the whole thing doesn't work.

I thoroughly agree. We have a critical, lethal design flaw in that any
CA can issue any cert for anyone at any time. We should fix that, and
are working to.

However, given that we have this critical flaw and vulnerability, in the
short term, I want to resist actions which make it easier to exploit.


signature.asc

Tom Lowenthal

unread,
Jun 14, 2012, 2:53:16 PM6/14/12
to mozilla-dev-s...@lists.mozilla.org
On 06/13/2012 03:27 AM, Gervase Markham wrote:
>>> In what way is this different from another CA operating under the
>>> jurisdiction of another government? I'm pretty sure both the UK and the
>>> US have laws which would allow them to secretly compel a CA to issue a
>>> particular cert.

On 14/06/12 00:53, Tom Lowenthal wrote:
>> Without engaging with the legal question, if a CA *did* issue a cert
>> like this, we should immediately revoke their root without further
>> conversation. This is the only way to impose a commercial pressure and
>> provide a financial incentive for CAs not to lie.

On 06/14/2012 02:32 AM, Gervase Markham wrote:
> If you want to have a doctrine of "untrustworthy host country", then you
> need to come up with a clear definition for who 'qualifies'.

I do not propose a doctrine of "untrustworthy host country", I propose a
doctrine of "untrustworthy CA". If a CA is subject to coercion by a
country with a history of communication interception and human rights
abuses, that should be a factor which we weigh when assessing their
their expected trustworthiness.


On 14/06/12 00:53, Tom Lowenthal wrote:
>> If I think that I'd be less secure with their root in my browser, and
>> that I'd tell anyone who asks that they should remove that root to
>> improve their security then I think that we shouldn't add that root.

On 06/14/2012 02:32 AM, Gervase Markham wrote:
> As Jonathan said, I would find it hard to use "Tom's gut feeling" (or
> even "the majority of gut feelings among module peers") as our
> definition of "untrustworthy host country".

I'm about to slide gently off topic into my opinion about how Mozilla
should assign trust in our PKI. Sorry about that.

In every other module, the module peers, representing what they think is
the will of the community, make normative decisions about what code to
include, which features to add, and what they think the product covered
by that module should look like. There are baseline standards: code must
not be written poorly, it my conform to our style conventions, and it
must work. However, a well-written patch is not guaranteed acceptance if
it implements a feature that the module owners think is
counterproductive or undesirable.

I think that we should have the same approach here. If a CA wants root
inclusion, they must meet our clearly documented standards. If they
don't then they are welcome to come back once they have their house in
order. However, simply having recent audits and a HSM* should not
entitle a CA to root acceptance.

For a CA's root to be added -- an assignment of *enormous* trust on
behalf of our users -- we should be convinced beyond all reasonable
doubt that adding them does a positive service to our users. If a CA
submits a statement that

> [the CA] takes orders from the Ministry of Information Industry (MII)
> to conduct daily business,

that should be sufficient to persuade us that adding this root probably
*does not serve our users*. That determination should be all that we
need to reject their request.

Yes, this is a normative decision made by the module peers. Yes, there
is no oracle that a CA can use to guarantee inclusion. However, I do not
think that this state of affairs would be a problem. The module peers
should represents users' needs, which are hard to divine in advance.
Trust decisions are difficult, and subtle. That's why we need
trustworthy, thoughtful module peers to make good decisions on users'
behalf.


*I understand that this is a gross oversimplification of the reasonable
and rigorous standards we hold CAs to.

signature.asc

Sid Stamm

unread,
Jun 14, 2012, 4:19:50 PM6/14/12
to Tom Lowenthal
On 06/13/2012 04:53 PM, Tom Lowenthal wrote:
> Sid, a module peer, has published an academic paper with observations
> which should lead us to reasonably believe that adding this root places
> our users at significantly increased risk of attack by a hostile actor.
> A host of other evidence indicates that we might have quite some
> difficulty identifying these attacks if they are done effectively.

Tom, you are mischaracterizing my position. The observations simply
state that any CA who can be forced by a state to misissue certificates
may contribute to state-run SSL man-in-the-middle attacks. It says
nothing about CNNIC or any other individual CA.

> Even though we have not seen conclusive evidence of a specific attack
> from CNNIC, we *have* seen evidence that should convince us that adding
> their root will reduce our users' expected security. We should therefore
> not add them.

Can you share the evidence you speak of? Are there actions you have
seen taken by CNNIC that directly show how our users are at increased
risk? If you are just expressing the general feeling that adding more
CAs in general increases risk, that is a position I agree with. I don't
see any convincing evidence that shows this specific inclusion request
is worse than others.

-Sid

Stephen Schultze

unread,
Jun 14, 2012, 4:34:38 PM6/14/12
to mozilla-dev-s...@lists.mozilla.org
Is it not accurate to read your paper as saying that a CA based in China
is more likely to be coerced into state-run SSL man-in-the-middle
attacks than a CA in a jurisdiction that has not demonstrated a
willingness to compel companies to surveil citizens?

Sid Stamm

unread,
Jun 14, 2012, 4:49:24 PM6/14/12
to Stephen Schultze
> Is it not accurate to read your paper as saying that a CA based in China
> is more likely to be coerced into state-run SSL man-in-the-middle
> attacks than a CA in a jurisdiction that has not demonstrated a
> willingness to compel companies to surveil citizens?

That was not my intent. Regardless, I am not the sole author on that
paper, and there are multiple edits floating around (the first draft
text was less than perfect and some drafts more accurately reflect my
opinion than others).

You quoted a line about compelling telecommunications companies; I'm
not sure of the context of this quote, but I'm confident there are other
governments who also lean on telecom to wiretap civilians.

-Sid

Moudrick M. Dadashov

unread,
Jun 14, 2012, 5:11:19 PM6/14/12
to Sid Stamm, mozilla-dev-s...@lists.mozilla.org, Stephen Schultze
Hi Sid,

is this paper published/available?

Thanks,
M.D.

On 6/14/2012 11:49 PM, Sid Stamm wrote:
>> Is it not accurate to read your paper as saying that a CA based in China
>> is more likely to be coerced into state-run SSL man-in-the-middle
>> attacks than a CA in a jurisdiction that has not demonstrated a
>> willingness to compel companies to surveil citizens?
> That was not my intent. Regardless, I am not the sole author on that
> paper, and there are multiple edits floating around (the first draft
> text was less than perfect and some drafts more accurately reflect my
> opinion than others).
>
> You quoted a line about compelling telecommunications companies; I'm
> not sure of the context of this quote, but I'm confident there are other
> governments who also lean on telecom to wiretap civilians.
>
> -Sid
>

Sid Stamm

unread,
Jun 14, 2012, 5:21:21 PM6/14/12
to Moudrick M. Dadashov, mozilla-dev-s...@lists.mozilla.org, Stephen Schultze

On 06/14/2012 02:11 PM, Moudrick M. Dadashov wrote:
> Hi Sid,
>
> is this paper published/available?

I think this is the paper to which Steve and Tom are referring:
http://files.cloudprivacy.net/ssl-mitm.pdf

-Sid


>
> Thanks,
> M.D.
>
> On 6/14/2012 11:49 PM, Sid Stamm wrote:
>>> Is it not accurate to read your paper as saying that a CA based in China
>>> is more likely to be coerced into state-run SSL man-in-the-middle
>>> attacks than a CA in a jurisdiction that has not demonstrated a
>>> willingness to compel companies to surveil citizens?

Stephen Schultze

unread,
Jun 14, 2012, 6:52:45 PM6/14/12
to mozilla-dev-s...@lists.mozilla.org
So do you think that the compelled certificate creation attack at the
core of your paper's thesis should ever be considered as part of the
risk analysis of root approvals? If so, how?

Sid Stamm

unread,
Jun 14, 2012, 7:09:34 PM6/14/12
to Stephen Schultze
> So do you think that the compelled certificate creation attack at the
> core of your paper's thesis should ever be considered as part of the
> risk analysis of root approvals? If so, how?

I think that all CAs potentially present this risk (misissuance) to
users. When a CA is admitted to our program, they promise not to
misissue, and we must hold them up to this standard.

If a CA misissues for any reason -- including a compelled certificate
attack -- I would consider it grounds for removal from our program.

All CAs can misissue. Our inclusion criteria don't currently disallow
CAs that can *potentially* missisue, only those who actually do.

-Sid

ch...@soghoian.net

unread,
Jun 14, 2012, 5:26:01 PM6/14/12
to mozilla-dev-s...@lists.mozilla.org
Hi all,

As the other author of the paper, let me chime in here (I should note though that I speak for myself alone).

The line that Steve quoted was:

"The Chinese government, for example, has repeatedly compelled the assistance
of telecommunications and technology companies in assisting it with its surveillance efforts"

That sentence was present in the first, and final (published) drafts of the paper.
See: http://files.cloudprivacy.net/ssl-mitm.pdf, at page 5.

As you will see in the pdf, that sentence was supported by two references, which are:

John Markoff . Surveillance of skype messages found in china. The New York Times, October 1 2008. www.nytimes.com/2008/10/02/technology/internet/02skype.html.

Andrew Jacobs. China requires censorship software on new pcs. The New York Times, June 8 2009. www.nytimes.com/2009/06/09/world/asia/09china.html

Based on these incidents alone, I feel like the statement in the paper was quite reasonable.

However, let me also note, that the motivation for this paper was my discovery (at a surveillance industry conference) of a _US_ company selling gear designed to MITM HTTPS connections using government compelled certificates.

The legal authority for such compelled disclosure in the US is unclear, but DOJ would likely rely on the All Writs Act, which serves as a general catch all surveillance authority. See: https://www.eff.org/deeplinks/2005/10/all-surveillance-act

The Chinese government isn't the only government that compels companies to assist it in surveillance of its citizens. The US has been doing it since the days of the telegraph.

Regards,

Chris

Phillip Hallam-Baker

unread,
Jun 14, 2012, 7:39:18 PM6/14/12
to Stephen Schultze, mozilla-dev-s...@lists.mozilla.org
So when you make accusations against the Chinese government it is OK
but when someone points out that your own government has a pretty
terrible record on the respect for law front they are 'aspersions' and
risk invoking Godwins law.

Glad we got that straight.

The fact is that all governments engage in espionage and there are
pretty good reasons why they should.


On Thu, Jun 14, 2012 at 11:51 AM, Stephen Schultze
<sjschult...@gmail.com> wrote:
> On 6/14/12 11:00 AM, Phillip Hallam-Baker wrote:
>>
>> On Thu, Jun 14, 2012 at 10:23 AM, Stephen Schultze
>> <sjschult...@gmail.com>  wrote:
>>>
>>> I'm not sure where torture fits in to CA risk analysis, although these
>>>
>>> conversations unfortunately seem to slide toward these types of unhelpful
>>> discussions.
>>
>>
>> You decided to engage in a series of unsubstantiated attacks on China.
>> I pointed out that objectively the same criteria would exclude US CAs.
>> I don't see how that is off topic.
>
>
> Torture is off topic and only serves to unhelpfully push us toward a
> Godwin's Law violation.
>
> The Chinese government's tactic of compelling companies to help them with
> surveillance is broadly accepted as fact, as cited by the peer-reviewed
> article published by one of the module owners.
>
>>> EFF has documented the substantial judicial (and other) review of the
>>> warrantless wiretapping program:
>>> https://www.eff.org/issues/nsa-spying
>>
>>
>> Which only took place after it was discovered and mostly consisted of
>> the courts deciding that they were going to avoid doing anything.
>>
>> As the page says "EFF is fighting these illegal activities on multiple
>> fronts.". Note the use of the future tense as in continuing to fight
>> as in, the courts are still trying to dodge responsibility and avoid
>> holding their political patrons accountable.
>
>
> This is what we call the adversarial process.  This is desirable.
>
>>> They don't necessarily agree with where it's gone, nor do I, but there it
>>> is.
>>
>>
>> So the standard you propose is judicial review even if it is clear
>> that the review in question is going to be futile and ignore the
>> actual behavior at issue?
>>
>> How does a sham judicial review do anything to mitigate the risks you
>> are concerned about?
>
>
> I don't think that the EFF or others on the leading edge of this fight would
> characterize the standard of judicial review in the US this way. That being
> said, if you'd like to argue that this is the case, go ahead.
>
>>> But let's assume that Mozilla disagrees, and thinks that the US behavior
>>> is
>>> a significant risk to end users.  I suppose the reasoning is that
>>> "everybody
>>> does it", therefore Mozilla won't consider it in the risk analysis.  If
>>> that's the case, I'd like to see that stated explicitly.
>>
>>
>> The solution here is what Gerv, Peter, I and several others have been
>> proposing: Transparency controls that are designed to ensure that any
>> government coerced compromise becomes apparent.
>
>
> Indeed, such controls are useful (and I have been vociferously arguing for
> some of them) but many are not present today nor are they comprehensive.
>
> Either the threat scenario is real or it's not.  You seem to think it's
> real, but too widespread to combat.  If it's real but Mozilla chooses not to
> consider it in making root inclusion decisions, let's hear that.
>
> In any case, this back-and-forth, like others I have had with you, has
> become quite impolite.  Feel free to take a parting shot, but I'm done with
> responding to your unhelpful aspersions.
>

Stephen Schultze

unread,
Jun 14, 2012, 7:57:38 PM6/14/12
to mozilla-dev-s...@lists.mozilla.org
A big +1 to everything that Chris said, including the US's history of
compelling companies to assist in surveillance. I argue that the degree
and form is different in the US and China (as does, upon my reading, the
paper), but it is undeniably true that it happens in the US.

As far as Sid's comment about whether or not the inclusion process
considers *potential* to mis-issue certs... I think as written and in
practice it clearly does. It refers to *risk* to users. Likewise,
there are many CA practices that are considered risky or
problematic--increasing but not guaranteeing the likelihood of
mis-issuance--that have weighed for or against inclusion in the past.

That being said, there appears to be a consensus by the module owners
that Mozilla does not want to be in the role of considering these risks,
so I'll let my end of the thread die.

Steve

ianG

unread,
Jun 14, 2012, 10:02:51 PM6/14/12
to dev-secur...@lists.mozilla.org
On 15/06/12 09:09 AM, Sid Stamm wrote:
>> So do you think that the compelled certificate creation attack at the
>> core of your paper's thesis should ever be considered as part of the
>> risk analysis of root approvals? If so, how?
>
> I think that all CAs potentially present this risk (misissuance) to
> users. When a CA is admitted to our program, they promise not to
> misissue, and we must hold them up to this standard.
>
> If a CA misissues for any reason -- including a compelled certificate
> attack -- I would consider it grounds for removal from our program.
>
> All CAs can misissue. Our inclusion criteria don't currently disallow
> CAs that can *potentially* missisue, only those who actually do.


The problem with setting up any line in the sand about possible causes
of misuse -- accidental or deliberate -- is that the spooks who want
these things will use the accidents against us.

We need solid lines. e.g., none at all. Or, only through due process
(less solid but customary).

It may be time to have that debate - is there any exception? Or not?

To build on Phillip's comments, a standard risk analysis by a CA will
accept that there is a possibility of a valid legal demand for an MITM cert.

How do we deal with that?

iang

ianG

unread,
Jun 14, 2012, 10:20:10 PM6/14/12
to dev-secur...@lists.mozilla.org
On 15/06/12 09:57 AM, Stephen Schultze wrote:

> That being said, there appears to be a consensus by the module owners
> that Mozilla does not want to be in the role of considering these risks,
> so I'll let my end of the thread die.


Allow me to speculate on Mozilla's position using my words. They can
disagree if they like.

Mozilla aren't concerned about CNNIC. They are concerned about the
precedent set. They know that if CNNIC is knocked out on any basis, the
same basis will be used against CAs in USA, Europe and other countries.
Especially, USA, UK, Germany, Russia are all countries carrying
serious downsides in surveillance.

And, especially in USA, pressure can be brought to bear on Mozilla
Foundation through informal channels and through the courts. The US
government thinks nothing of bending its power to push Foundations
around. US CAs have little qualms about sending their teams of lawyers
in for a quite informal-but-serious chat.

If Mozilla Foundation wants to take on that fight, they to get need
their ducks in a row. So far we lack even one stationary bird. A lot
of quaking does not a regiment make.

(And, Mozilla Foundation have not shown any history that even places
them in the contest. They're simply not into that sort of political /
freedom / democracy battle.)

As I say, that's my view. They might think differently. But I'd be
very surprised if they'd act differently ;)



iang

ianG

unread,
Jun 14, 2012, 10:22:51 PM6/14/12
to dev-secur...@lists.mozilla.org
Hmmm... nice try, but we are way beyond the point where the we can hold
back from making matters worse. We don't have that option; the system
has grown way beyond its plausible scale limits, given the
house-of-cards architecture and implicit flaw. One more isn't going to
change it, as has been seen from the spike of CA incidents over the last
1-2 years.



iang

ianG

unread,
Jun 14, 2012, 10:29:01 PM6/14/12
to Phillip Hallam-Baker, dev-secur...@lists.mozilla.org
On 14/06/12 11:17 AM, Phillip Hallam-Baker wrote:
> Seems to me that the correct approach to take here would be to copy
> the approach taken by banks who face a real threat of coercion of
> their employees.
>
> Every bank I have dealt with has the same policy wrt robberies. The
> staff must hand over the cash without question. In fact many have a
> policy of sacking someone on the spot if they don't comply (unless
> there is some other issue).


Yes. Just by way of direct example, here is what CAcert does.

If trusted people are faced with a legal demand (+/- guns) they are not
to interfere with the operation of that demand. In contrast, they have
no permission or process to assist in such things, only the Arbitrator
has that power.


> The key thing with cyber warfare is that it relies on secrecy. No
> intel service is going to be coercing a CA into doing anything that is
> going to be observable and observed.


This is exactly the conclusion we came up with at CAcert.

Every legal demand is automatically filed as a dispute before a CAcert
Arbitrator - absolutely no exceptions. Then, any such legal demand can
be considered - in a legal framework.


(Please note that as CAcert is a user community, it can do things
differently. Therefore the above process is not to be seen as a
recommendation for other CAs.)

iang

Jan Schejbal

unread,
Jun 14, 2012, 10:46:36 PM6/14/12
to mozilla-dev-s...@lists.mozilla.org
Am 2012-06-14 01:58, schrieb Tom Lowenthal:
> If they choose that other obligation, then we should remove their root
> without further discussion.

Please note that having this as a policy might actually protect the CAs:
A government request for a fake cert would probably be considered
unreasonable by courts if fullfilling that request could mean removal of
the CA from trust lists and thus the destruction of the CA's main business.

Kind regards,
Jan

--
Please avoid sending mails, use the group instead.
If you really need to send me an e-mail, mention "FROM NG"
in the subject line, otherwise my spam filter will delete your mail.
Sorry for the inconvenience, thank the spammers...


ianG

unread,
Jun 14, 2012, 10:49:28 PM6/14/12
to dev-secur...@lists.mozilla.org
Hi Tom,

On 15/06/12 04:53 AM, Tom Lowenthal wrote:
> On 06/13/2012 03:27 AM, Gervase Markham wrote:
>>>> In what way is this different from another CA operating under the
>>>> jurisdiction of another government? I'm pretty sure both the UK and the
>>>> US have laws which would allow them to secretly compel a CA to issue a
>>>> particular cert.
>
> On 14/06/12 00:53, Tom Lowenthal wrote:
>>> Without engaging with the legal question, if a CA *did* issue a cert
>>> like this, we should immediately revoke their root without further
>>> conversation. This is the only way to impose a commercial pressure and
>>> provide a financial incentive for CAs not to lie.
>
> On 06/14/2012 02:32 AM, Gervase Markham wrote:
>> If you want to have a doctrine of "untrustworthy host country", then you
>> need to come up with a clear definition for who 'qualifies'.
>
> I do not propose a doctrine of "untrustworthy host country", I propose a
> doctrine of "untrustworthy CA". If a CA is subject to coercion by a
> country with a history of communication interception and human rights
> abuses, that should be a factor which we weigh when assessing their
> their expected trustworthiness.


The factor is being weighed.

The reason for not giving it much weight is lack of direct evidence, and
the suspicion that China is a stalking horse for political purposes.


> On 14/06/12 00:53, Tom Lowenthal wrote:

> I'm about to slide gently off topic into my opinion about how Mozilla
> should assign trust in our PKI. Sorry about that.
>
> In every other module, the module peers, representing what they think is
> the will of the community, make normative decisions about what code to
> include, which features to add, and what they think the product covered
> by that module should look like. There are baseline standards: code must
> not be written poorly, it my conform to our style conventions, and it
> must work. However, a well-written patch is not guaranteed acceptance if
> it implements a feature that the module owners think is
> counterproductive or undesirable.
>
> I think that we should have the same approach here.


This module is different. Consider...

Does any other module have to do deal with commercial companies that are
prepared to sue to keep in the root list because their income is
directly related to list inclusion? Dissidents that live free or not by
use of crypto? A security architecture that has switched from 18 years
of apparent perfection to complete failure in the space of a year? A
vested and documented state interest in failure, etc etc? A user base
that has a completely unmeasurable and unknowable risk and exposure to
the system? A defined and documented failure mode (phishing) that costs
the users hundreds of million dollars? A government spying apparatus
that would think nothing of leaning on the Foundation?


> If a CA wants root
> inclusion, they must meet our clearly documented standards. If they
> don't then they are welcome to come back once they have their house in
> order. However, simply having recent audits and a HSM* should not
> entitle a CA to root acceptance.
>
> For a CA's root to be added -- an assignment of *enormous* trust on
> behalf of our users -- we should be convinced beyond all reasonable
> doubt that adding them does a positive service to our users. If a CA
> submits a statement that
>
>> [the CA] takes orders from the Ministry of Information Industry (MII)
>> to conduct daily business,
>
> that should be sufficient to persuade us that adding this root probably
> *does not serve our users*. That determination should be all that we
> need to reject their request.


OK. But if that statement is changed to:

[the CA] follows the rule of law in its country,

are we still in business? How about:

[the CA] is directly regulated by the state,

which applies to all European-style QC providers?


> Yes, this is a normative decision made by the module peers. Yes, there
> is no oracle that a CA can use to guarantee inclusion. However, I do not
> think that this state of affairs would be a problem. The module peers
> should represents users' needs, which are hard to divine in advance.
> Trust decisions are difficult, and subtle. That's why we need
> trustworthy, thoughtful module peers to make good decisions on users'
> behalf.


As a matter of long standing policy - No. The decisions on CA inclusion
are made by Mozilla Foundation, in consultation with this forum. It is
written in the policy. It is different to the routine coding inclusion
process.


> *I understand that this is a gross oversimplification of the reasonable
> and rigorous standards we hold CAs to.


Well, as gross oversimplifications go, "audit+HSMs" is a more accurate
than most complicated understandings of PKI. It's certainly more
accurate than "reasonable and rigorous standards" ;)



iang

ianG

unread,
Jun 15, 2012, 12:36:34 AM6/15/12
to dev-secur...@lists.mozilla.org
The point that we need to establish the metric by which other CAs are
going to be tested has now been well made, so just some other points...


On 15/06/12 01:51 AM, Stephen Schultze wrote:
> On 6/14/12 11:00 AM, Phillip Hallam-Baker wrote:
>> On Thu, Jun 14, 2012 at 10:23 AM, Stephen Schultze
>> <sjschult...@gmail.com> wrote:
>>> I'm not sure where torture fits in to CA risk analysis, although these
>>> conversations unfortunately seem to slide toward these types of
>>> unhelpful
>>> discussions.
>>
>> You decided to engage in a series of unsubstantiated attacks on China.
>> I pointed out that objectively the same criteria would exclude US CAs.
>> I don't see how that is off topic.
>
> Torture is off topic


I do not feel that torture is off topic (*). When SSL fails due to
surveillance, dissidents (can/may) get captured. When they get
captured, torture is one of the options awaiting them.

It might be OK for some to excuse the situation by saying that SSL was
never meant to deal with state-level attacks, but for various and many
reasons, this excuse does not stand up. The SSL community presents
certificate-based solutions as the standard, and as strong. Mozilla
signs up to that standard and won't permit any other solution - because
SSL is strong.

They can't have it both ways. The possibilities of
users-being-dissidents, surveillance, capture torture and so forth are
very much on topic.


> and only serves to unhelpfully push us toward a
> Godwin's Law violation.

Godwin's law is generally cited by the slashdot crowd to shut down
opposition. It is a form of argument abuse. We happen to be dealing
with exactly the questions that Godwin's so-called law focusses on --
draconian practices and regimes -- and we can't easily avoid that topic.


> The Chinese government's tactic of compelling companies to help them
> with surveillance is broadly accepted as fact, as cited by the
> peer-reviewed article published by one of the module owners.

Sure, stipulated.


>>> EFF has documented the substantial judicial (and other) review of the
>>> warrantless wiretapping program:
>>> https://www.eff.org/issues/nsa-spying
>>
>> Which only took place after it was discovered and mostly consisted of
>> the courts deciding that they were going to avoid doing anything.
>>
>> As the page says "EFF is fighting these illegal activities on multiple
>> fronts.". Note the use of the future tense as in continuing to fight
>> as in, the courts are still trying to dodge responsibility and avoid
>> holding their political patrons accountable.
>
> This is what we call the adversarial process. This is desirable.


Conceptually desirable, but practically worthless.

Having fairly closely followed some of those, I'm pretty sure that there
is approximately zero judicial review of the surveillance program, as we
know it. (OK, they have secret courts... What was the statistic - one
rejection out of multiple tens of thousands?) Approximately equal to
China which also has secret courts.


>>> They don't necessarily agree with where it's gone, nor do I, but
>>> there it
>>> is.
>>
>> So the standard you propose is judicial review even if it is clear
>> that the review in question is going to be futile and ignore the
>> actual behavior at issue?
>>
>> How does a sham judicial review do anything to mitigate the risks you
>> are concerned about?
>
> I don't think that the EFF or others on the leading edge of this fight
> would characterize the standard of judicial review in the US this way.
> That being said, if you'd like to argue that this is the case, go ahead.

The doctrine of State Secrets shuts down the judiciary's ability to
participate in judicial review.

>>> But let's assume that Mozilla disagrees, and thinks that the US
>>> behavior is
>>> a significant risk to end users. I suppose the reasoning is that
>>> "everybody
>>> does it", therefore Mozilla won't consider it in the risk analysis. If
>>> that's the case, I'd like to see that stated explicitly.
>>
>> The solution here is what Gerv, Peter, I and several others have been
>> proposing: Transparency controls that are designed to ensure that any
>> government coerced compromise becomes apparent.


+1

> Indeed, such controls are useful (and I have been vociferously arguing
> for some of them) but many are not present today nor are they
> comprehensive.
>
> Either the threat scenario is real or it's not. You seem to think it's
> real, but too widespread to combat.

The threats and risks are understandable, yes, but only at an intuitive
level. We can't really judge how likely they are.

> If it's real but Mozilla chooses not
> to consider it in making root inclusion decisions, let's hear that.

If the argument is that the risk is sufficient to knock out the CA, then
it fails right there. Nobody's done a risk analysis.

(I know that from an academic standpoint - there are methods and
standpoints that exist for risk analysis, and nothing's been put on the
table that looks like a risk analysis.)






iang


(*) In a past life, I spent a decade or so building OpenPGP
(Java-side) and other things like that. It is clear to me from that
experience that a lot of dissidents rely on various and many forms of
crypto to conduct their operations.

Gervase Markham

unread,
Jun 19, 2012, 10:27:13 AM6/19/12
to Tom Lowenthal
On 14/06/12 19:53, Tom Lowenthal wrote:
> I do not propose a doctrine of "untrustworthy host country", I propose a
> doctrine of "untrustworthy CA".

But that doesn't get us much further forward, because you are proposing
that a CA be deemed untrustworthy because of the characteristics of its
host country.

> If a CA is subject to coercion by a
> country with a history of communication interception and human rights
> abuses, that should be a factor which we weigh when assessing their
> their expected trustworthiness.

How would you make a list of such countries?

> I'm about to slide gently off topic into my opinion about how Mozilla
> should assign trust in our PKI. Sorry about that.

No apology necessary!

> For a CA's root to be added -- an assignment of *enormous* trust on
> behalf of our users -- we should be convinced beyond all reasonable
> doubt that adding them does a positive service to our users.

Surely, by that criteria, we would never add a new CA, if every CA
begins with 0 issued certs, and therefore adding them (at the time of
addition) is no benefit?

> If a CA
> submits a statement that
>
>> [the CA] takes orders from the Ministry of Information Industry (MII)
>> to conduct daily business,
>
> that should be sufficient to persuade us that adding this root probably
> *does not serve our users*. That determination should be all that we
> need to reject their request.

Would it be sufficient if the relevant Ministry of Information Industry
was a branch of the UK government? Or the US government? Or the French
government? If not, then it's not this statement you have a problem
with, it's the Chinese government.

Is it the "daily business" that's the problem, or the fact that there is
some risk of government coercion at any time?

Gerv

Phillip Hallam-Baker

unread,
Jun 19, 2012, 10:43:32 AM6/19/12
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org, Tom Lowenthal
+1

But, what is really being seen here is the fact that one size fits all
is not going to work as a basis for 'absolute' security when nation
states are possible attackers.

We can adopt the 'Sovereign Keys' approach of pretend administrators
won't make mistakes so there is no need for any slack in the system.
Or we can design a practical system that has slack and can be deployed
but will inevitably have the risk that the slack be abused.


The only really good solution here is to allow the individual user to
tailor their security settings in a way that includes curating the
roots and/or certificates. This is what the US federal government does
with SCVP, it is what XKMS does. It is also what I think we are going
to need as a solution to the hard-fail revocation problem.

That is what I am trying to do with Omnibroker.



On Tue, Jun 19, 2012 at 10:27 AM, Gervase Markham <ge...@mozilla.org> wrote:
> On 14/06/12 19:53, Tom Lowenthal wrote:
>> I do not propose a doctrine of "untrustworthy host country", I propose a
>> doctrine of "untrustworthy CA".
>
> But that doesn't get us much further forward, because you are proposing
> that a CA be deemed untrustworthy because of the characteristics of its
> host country.
>
>> If a CA is subject to coercion by a
>> country with a history of communication interception and human rights
>> abuses, that should be a factor which we weigh when assessing their
>> their expected trustworthiness.
>
> How would you make a list of such countries?
>
>> I'm about to slide gently off topic into my opinion about how Mozilla
>> should assign trust in our PKI. Sorry about that.
>
> No apology necessary!
>
>> For a CA's root to be added -- an assignment of *enormous* trust on
>> behalf of our users -- we should be convinced beyond all reasonable
>> doubt that adding them does a positive service to our users.
>
> Surely, by that criteria, we would never add a new CA, if every CA
> begins with 0 issued certs, and therefore adding them (at the time of
> addition) is no benefit?
>
>> If a CA
>> submits a statement that
>>
>>> [the CA] takes orders from the Ministry of Information Industry (MII)
>>> to conduct daily business,
>>
>> that should be sufficient to persuade us that adding this root probably
>> *does not serve our users*. That determination should be all that we
>> need to reject their request.
>
> Would it be sufficient if the relevant Ministry of Information Industry
> was a branch of the UK government? Or the US government? Or the French
> government? If not, then it's not this statement you have a problem
> with, it's the Chinese government.
>
> Is it the "daily business" that's the problem, or the fact that there is
> some risk of government coercion at any time?
>
> Gerv
0 new messages