Name-constraining government CAs, or not

[Gervase Markham]

Hi everyone,

The topic of name-constraining government CAs, probably to the TLD(s) of
their territory(ies), has come up numerous times. I'd like to try and
hash out, once and for all, whether we think this is actually a good
idea, so we can decide to work towards doing it, or decide actively not
to do it. And then document the decision.

Questions
=========

The key questions I would like to discuss to begin with are:

1) "Is the security analysis relating to government CAs, as a class,
different to that relating to commercial CAs? If so, how exactly?"

2) "If it is different, does name-constraining government CAs make
things better, or not?"

These questions will probably lead us, in passing, to discuss how to
define "government CA", but let's try not to let that dominate the
discussion. If possible, stick to clear examples.

I think that if we can get clear answers to those questions, those would
form the basis of a policy to explain why we are (or are not) taking action.

Scope
=====

Out of scope for this discussion are:

* Whether we should name constrain CAs other than government CAs (note
it's possible we may decide not to name constrain government CAs as a
class, but later decide to name constrain some other class of CAs)

* The trustworthiness or otherwise of particular specific governments

* The exact details of which TLDs any particular government CA might be
constrained to

* The level of impact on the net of imposing such constraints

Background Information
======================

CAs currently in Mozilla's program which may fit one or more definitions
of "government CA" are:

* Consorci Administració Oberta de Catalunya (Consorci AOC, CATCert)*
* Government of France (ANSSI, DCSSI)
* Government of Hong Kong (SAR), Hongkong Post, Certizen*
* Government of Japan, Ministry of Internal Affairs and Communications*
* Government of Spain, Autoritat de Certificació de la Comunitat
Valenciana (ACCV)
* Government of Taiwan, Government Root Certification Authority (GRCA)*
* Government of The Netherlands, PKIoverheid
* Government of Turkey, Kamu Sertifikasyon Merkezi (Kamu SM)
* Hellenic Academic and Research Institutions Certification Authority
(HARICA)
* China Internet Network Information Center (CNNIC)

There are other possibly-government CAs who are in the process of
applying for inclusion (although some of these requests may be said to
be dormant), including:

* Government of India (CCA)
* Autoridad Certificadora Raíz Nacional de Uruguay (ACRN)
* PostSignum operated by Ceska posta s.p. (Czech Post)
* Fábrica Nacional de Moneda y Timbre (FNMT)
* ICP Brasil (Infra-Estrutura de Chaves Públicas Brasileira)
* Korea Information Security Agency (KISA)
* Latvian State Radio and Television Centre (LVRTC)
* Superintendencia de Servicios de Certificación Electrónica (SUSCERTE)
* PSC-FII
* South African Post Office Limited (SAPO)
* Swiss BIT, Swiss Federal Office of Information Technology, Systems and
Telecommunication (FOITT)
* U.S. Federal Public Key Infrastructure (US FPKI)

(Also, some of the first set of CAs are applying to add new roots.)

The audit status of these CAs is sometimes thought to be relevant. All
are audited to criteria we accept. Two (ANSSI/DCSSI and Kamu SM) are
audited by other parts of the government concerned; the rest are audited
by independent auditors, and so their audits are no different to any
other CA in the program.

Those CAs marked with a "*" to the right are those who have not yet
provided a BR audit. Some may also find this relevant.

Gerv

[David E. Ross]

There is an ongoing dispute between the U.S. and China whether the
government in China is behind attacks on both government and commercial
computer systems in the U.S. This is NOT to question the
trustworthiness of the government of China but to give one example of
the possibility of hostile actions by a government certification
authority (CA).

Snowden revealed how the U.S. NSA is intercepting Internet
communications in bulk. This is NOT to question the trustworthiness of
the government of the U.S. but to give another example of the
possibility of hostile actions by a government CA.

With "cyberwarfare" constantly discussed in the news, U.S. Congress, and
other venues, it appears to me that government CAs should indeed be
restricted to the TLDs of their respective jurisdictions.

Furthermore, since governments can apply pressure (often secretively) to
commercial enterprises, a similar restriction should be applied to all
commercial and non-government CAs. In this case, they should be
restricted to TLDs of those jurisdictions where they have registered and
whose governments have granted the CAs permission to operate.

--
David E. Ross

I am sticking with SeaMonkey 2.26.1 until saved passwords can
be used when autocomplete=off. See
<https://bugzilla.mozilla.org/show_bug.cgi?id=433238>.

[Ryan Sleevi]

On Thu, May 14, 2015 9:02 am, David E. Ross wrote:

> With "cyberwarfare" constantly discussed in the news, U.S. Congress, and
> other venues, it appears to me that government CAs should indeed be
> restricted to the TLDs of their respective jurisdictions.
>
> Furthermore, since governments can apply pressure (often secretively) to
> commercial enterprises, a similar restriction should be applied to all
> commercial and non-government CAs. In this case, they should be
> restricted to TLDs of those jurisdictions where they have registered and
> whose governments have granted the CAs permission to operate.

Unsurprisingly, this would make online communications less secure, rather
than more secure.

If I operate uncomfortable-for-the-us-government.com. If the US seizes
that domain (asserting jurisdiction over .com, as they have in the past),
then they can also compel a US CA to issue a cert. Or just use the
domain-validation case.

However, if I'm concerned about my users' security, I might choose to use
a Chinese CA, on the assumption that China will not blithely cooperate
with the US's request. That in and of itself doesn't offer security, but I
can make this more secure in several ways:

1) I can pin to that Chinese CA, *forcing* the USG to cooperate with the
Chinese gov to get a certificate
2) I could pin to an EV root, forcing the USG as newly-appointed owners of
that domain to go through an EV validation if they want to MITM my
customers
3) I could a-priori negotiate with the Chinese CA and develop a set of
authorized requestors for that certificate, with the Chinese CA's policies
such that they'll review that information before issuing, even if the
domain information changes

There are plenty of other controls that are practical, today, to provide
such damage mitigation. Indeed, they're helpful precisely when you *don't*
trust your government to responsibily/securely operate the TLD space.

Think about how it would be for sites like google.com.ccTLD. Any of those
.ccTLDs could MITM users traffic. Under today's policies, where Google can
pin users to its intermediate, that's not possible. In tomorrow's world,
versions of that intermediate would have to be signed by each of the
country's appropriate CAs, or be denied secure communications with that
country's citizens.

I think there's also the broader consideration of whether Mozilla's policy
interests are served by promoting borders on the Internet, which David's
proposal certainly does, but the broader question invariably does.
https://www.mozilla.org/en-US/about/manifesto/ , Items 2, 4, and 6 all
seem relevant to the broader discussion of the implications of such a
policy.

In case it's not clear, I think imposing name-constraints on CAs to be bad
for the web and not a scalable solution, even if it appears attractive :)

[Gervase Markham]

On 14/05/15 17:02, David E. Ross wrote:
> There is an ongoing dispute between the U.S. and China whether the
> government in China is behind attacks on both government and commercial
> computer systems in the U.S. This is NOT to question the
> trustworthiness of the government of China but to give one example of
> the possibility of hostile actions by a government certification
> authority (CA).

Is there any evidence that these attacks involve certificates issued by
a government CA?

> Snowden revealed how the U.S. NSA is intercepting Internet
> communications in bulk. This is NOT to question the trustworthiness of
> the government of the U.S. but to give another example of the
> possibility of hostile actions by a government CA.

Is there any evidence that these attacks involve certificates issued by
a government CA?

> With "cyberwarfare" constantly discussed in the news, U.S. Congress, and
> other venues, it appears to me that government CAs should indeed be
> restricted to the TLDs of their respective jurisdictions.

You will need to expand on that observation if you want to turn it into
an argument.

> Furthermore, since governments can apply pressure (often secretively) to
> commercial enterprises,

This assertion is relevant and should be discussed, as it relates to my
question 1). Is "the government told its own CA to issue a certificate"
exactly the same situation as "this government pressured a commercial CA
in its jurisdiction to issue a certificate"?

> a similar restriction should be applied to all
> commercial and non-government CAs. In this case, they should be
> restricted to TLDs of those jurisdictions where they have registered and
> whose governments have granted the CAs permission to operate.

This suggestion is wildly impractical, and also out of scope for this
discussion - note "out of scope" point 1).

Gerv

[Gervase Markham]

On 15/05/15 00:01, Ryan Sleevi wrote:
> On Thu, May 14, 2015 9:02 am, David E. Ross wrote:
>
>> With "cyberwarfare" constantly discussed in the news, U.S. Congress, and
>> other venues, it appears to me that government CAs should indeed be
>> restricted to the TLDs of their respective jurisdictions.
>>
>> Furthermore, since governments can apply pressure (often secretively) to
>> commercial enterprises, a similar restriction should be applied to all
>> commercial and non-government CAs. In this case, they should be
>> restricted to TLDs of those jurisdictions where they have registered and
>> whose governments have granted the CAs permission to operate.
>
> Unsurprisingly, this would make online communications less secure, rather
> than more secure.

Can we stop discussion of this particular point (name-constraining
non-government CAs) here, as it's been ruled explicitly out of scope?
Thanks :-)

> I think there's also the broader consideration of whether Mozilla's policy
> interests are served by promoting borders on the Internet, which David's
> proposal certainly does, but the broader question invariably does.
> https://www.mozilla.org/en-US/about/manifesto/ , Items 2, 4, and 6 all
> seem relevant to the broader discussion of the implications of such a
> policy.

It would be helpful if you could expand upon this point, and the
relationship you see between those three principles and the proposal.

> In case it's not clear, I think imposing name-constraints on CAs to be bad
> for the web and not a scalable solution, even if it appears attractive :)

Again, expansion on these points would be appreciated :-)

Gerv

[Ryan Sleevi]

On Fri, May 15, 2015 1:52 am, Gervase Markham wrote:
> On 15/05/15 00:01, Ryan Sleevi wrote:

> > I think there's also the broader consideration of whether Mozilla's
> > policy
> > interests are served by promoting borders on the Internet, which David's
> > proposal certainly does, but the broader question invariably does.
> > https://www.mozilla.org/en-US/about/manifesto/ , Items 2, 4, and 6 all
> > seem relevant to the broader discussion of the implications of such a
> > policy.
>

> It would be helpful if you could expand upon this point, and the
> relationship you see between those three principles and the proposal.

2) The Internet is a global public resource that must remain open and
accessible.

- By introducing a demarcation of power/privilege by "government" or not
(which still suffers from the definitional issue that you've entirely
danced around :P), it ostensibly undermines the notion of global (e.g. if
you're required, by local jurisdiction, to only use CAs approved by
Country A, then you can no longer apply for any arbitrary name but only
those CAs approved by Country A can issue to)

- By introduction restrictions on what government CAs can do, it creates a
different standard of openness. That is, it presumes corporations are
trustworthy and governments are not (this is your first question, which is
implicitly answered in the positive in any discussion pro-constraint), and
corporations can openly participate while governments cannot.

4) Individuals' security and privacy on the Internet are fundamental and
must not be treated as optional.

- In the pro-constraint case, which again arguably answers the first
question you pose by saying "Yes, there is a difference", it introduces
the beginnings of technical control to introduce borders on the Internet,
by (effectively) restricting what domains individuals can purchase, and
further encouraging a centralization of names that are in government
control. Using my previous message as an example, I may choose to purchase
resources from China and the US under the assumption that they will not
mutually aid eachother in compromising me, even if they may both
independently attempt to.

6) The effectiveness of the Internet as a public resource depends on
interoperability (protocols, data formats, content), innovation and
decentralized participation worldwide.

- Name-constraining CAs has the effect of centralizing protocols
(vis-a-vis DNS)

- Name-constraining CAs has the effect of discouraging interoperability by
introducing multiple semi-subjective criteria into the discussion of trust
("What is a Government CA", "What is a government TLD")

> > In case it's not clear, I think imposing name-constraints on CAs to be
> > bad
> > for the web and not a scalable solution, even if it appears attractive
> > :)
>

> Again, expansion on these points would be appreciated :-)

I'm sure just as you wish for me to expand on this, I wish to understand
what specifically you're asking about.

This conversation has been raised multiple times, and I've raised multiple
objections and concerns each time it's been raised. For better or for
worse, I've written fairly extensively on this list why it's a bad idea,
and why various proposed modifications are equally problematic.

I've at length answered your first question posed - which is whether there
is a fundamental difference - and pointed out the myriad of ways in which
there is not.

I've at length answered your second question posted - which is whether it
makes things better or worse - and demonstrated the many ways in which it
can make things worse.

I mean, the definitional issues alone should show how subjective this is.
For example, I note you didn't include under "potential government CAs" as
LuxTrust ("Established in November 2005 through a partnership between the
Luxembourg government and major private financial actors in Luxembourg"),
or what the subtle implications are for Certinomis (which partners with La
Poste to perform identity validation, which is the mail service of France,
is definitionally an autonomous public enterprise since 1 January 1991,
when it was split from DGP, but which arguably operates within the
imprimatur of the French government)

I posit these as simply two examples of many to indicate the very
difficult challenges with separating 'operational capability'. However,
would we argue that a CA is wholly independent if it was seeded by
In-Q-Tel? Why or why not?

What about a CA operated by Verizon Business (aka GTE Cybertrust/Baltimore
Cybertrust?) Some are concerned that it may be participating in NSA
shenanigans (e.g.
http://rt.com/usa/168752-germany-boots-verizon-over-spying/ )? Or what
about several major US telecom providers' complicity in the NSA's
warrantless wiretapping -
http://www.wired.com/2010/01/fbi-att-verizon-violated-wiretapping-laws/ ?

There are so many more important things to spend our time on with regards
to improving trust. Simply embracing and encouraging greater transparency
(e.g. through Certificate Transparency) could go a long way in
establishing an objective basis for discussions about trustworthiness, and
the quality of audits, and the compliance and adherence to technical
requirements, rather than gut speculation and the jingoistic
sentimentality it inevitably invites.

[Chris Palmer]

On Fri, May 15, 2015 at 11:49 AM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:

> There are so many more important things to spend our time on with regards
> to improving trust. Simply embracing and encouraging greater transparency
> (e.g. through Certificate Transparency) could go a long way in
> establishing an objective basis for discussions about trustworthiness, and
> the quality of audits, and the compliance and adherence to technical
> requirements, rather than gut speculation and the jingoistic
> sentimentality it inevitably invites.

Surprising no one, I concur completely.

[Matt Palmer]

Everything that Ryan says below, is what I would have said if I were as
eloquent.

- Matt

On Fri, May 15, 2015 at 11:49:39AM -0700, Ryan Sleevi wrote:
> On Fri, May 15, 2015 1:52 am, Gervase Markham wrote:
> > On 15/05/15 00:01, Ryan Sleevi wrote:

> > > I think there's also the broader consideration of whether Mozilla's
> > > policy
> > > interests are served by promoting borders on the Internet, which David's
> > > proposal certainly does, but the broader question invariably does.
> > > https://www.mozilla.org/en-US/about/manifesto/ , Items 2, 4, and 6 all
> > > seem relevant to the broader discussion of the implications of such a
> > > policy.
> >

> > > In case it's not clear, I think imposing name-constraints on CAs to be
> > > bad
> > > for the web and not a scalable solution, even if it appears attractive
> > > :)
> >

> There are so many more important things to spend our time on with regards
> to improving trust. Simply embracing and encouraging greater transparency
> (e.g. through Certificate Transparency) could go a long way in
> establishing an objective basis for discussions about trustworthiness, and
> the quality of audits, and the compliance and adherence to technical
> requirements, rather than gut speculation and the jingoistic
> sentimentality it inevitably invites.
>

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

--
"Riding through the tunnel at 200 is something you should approach in the
same way you'd bonk your neighbours wife. A once in a while thing. Do it
often and you'll get caught."
-- Kel, aus.moto

[Eric Mill]

(I guess we're all wearing our affiliations on our backs, but disclosure:
I'm a US federal government employee, but am not speaking on behalf of the
USG, and don't have any professional affiliation with the US FPKI run out
of the Treasury Department.)

On Fri, May 15, 2015 at 11:49 AM, Ryan Sleevi <
ryan-mozde...@sleevi.com> wrote:

> On Fri, May 15, 2015 1:52 am, Gervase Markham wrote:
> > On 15/05/15 00:01, Ryan Sleevi wrote:

> > > I think there's also the broader consideration of whether Mozilla's
> > > policy
> > > interests are served by promoting borders on the Internet, which
> David's
> > > proposal certainly does, but the broader question invariably does.
> > > https://www.mozilla.org/en-US/about/manifesto/ , Items 2, 4, and 6 all
> > > seem relevant to the broader discussion of the implications of such a
> > > policy.
> >

> > It would be helpful if you could expand upon this point, and the
> > relationship you see between those three principles and the proposal.
>
> 2) The Internet is a global public resource that must remain open and
> accessible.
>
> - By introducing a demarcation of power/privilege by "government" or not
> (which still suffers from the definitional issue that you've entirely
> danced around :P), it ostensibly undermines the notion of global (e.g. if
> you're required, by local jurisdiction, to only use CAs approved by
> Country A, then you can no longer apply for any arbitrary name but only
> those CAs approved by Country A can issue to)
>
> - By introduction restrictions on what government CAs can do, it creates a
> different standard of openness. That is, it presumes corporations are
> trustworthy and governments are not

It does not presume corporations are trustworthy and governments are not.
It does presume that governments are different in some way than
corporations, and that that difference, in the context of the CA system and
the root program, might merit name constraints.

The health of the CA system, and the root program that manages it in many
ways, relies on leverage, accountability, and market forces to keep it in a
stable place that supports a strong internet. We all acknowledge the CA
system, like the DNS system, is imperfect and not fully centralized. It's
not all math -- it relies on human factors and institutional incentives.

Governments are not subject to the same kind of leverage, accountability or
market forces that corporations are. The legal constraints they operate
under are different, your likelihood of prevailing in a legal action
against them is different (and highly subject to the government in
question), and their business practices and incentives are going to be very
different.

In other words, you cannot expect a government CA to respond to the same
kinds of forces, either market pressure or deliberate browser/community
pressure, that a commercial CA would. This distinguishes those kinds of CAs
in a way that does *not* require to you to rest on the vague or general
idea that governments are less trustworthy than corporations.

Another factor is _why_ the government CA is applying to the trusted root
program. If the government CA only intends to issue certs for its own
properties, and its properties can reasonably be concluded to fall under a
clear name jurisdiction, then name constraints don't actually "constrain"
their business model. This avoids "slippery slope" concerns that might lead
to constraining a commercial CA against their will.

If a government CA is applying in order to provide certificates for its
country's corporations or citizens, that's a more complicated issue.
Treating ccTLDs (e.g. .in) as actually geographically bound, for the
purpose of a CA system, seems brittle and very much something that
*advances* the idea of the internet as geographically bound.

By contrast, to constrain a government to its own properties (e.g. .gov.in
or .gov) doesn't advance a geographic boundary, but an organizational
boundary.

The idea of constraining a government CA (like India or the US) to its own
properties is, to my mind, very different than constraining a corporation
(like Google or Microsoft) to its own properties. We, the browsers and
standards bodies of the internet and the people of the earth, have very
different leverage over abuses by a corporation than by a government.

> (this is your first question, which is
> implicitly answered in the positive in any discussion pro-constraint), and
> corporations can openly participate while governments cannot.

As described above, this is not always correct. In the case of a government
asking for admittance to the root program for the intent of issuing trusted
certs for its own organization, the government is not asking to "openly
participate" in the first place. They are asking to participate with a
closed set of domains, and name constraints can function to enforce that
closed participation.

Some people may also feel they are appropriate for corporate CAs who intend
to issue for themselves, but that's not what I'm arguing here, nor do I
feel there is risk of a slippery slope.

4) Individuals' security and privacy on the Internet are fundamental and
> must not be treated as optional.
>
> - In the pro-constraint case, which again arguably answers the first
> question you pose by saying "Yes, there is a difference", it introduces
> the beginnings of technical control to introduce borders on the Internet,
> by (effectively) restricting what domains individuals can purchase, and
> further encouraging a centralization of names that are in government
> control. Using my previous message as an example, I may choose to purchase
> resources from China and the US under the assumption that they will not
> mutually aid eachother in compromising me, even if they may both
> independently attempt to.
>

This argument only applies to scenarios in which the public (in any
country) is restricted in some way from the domains they can issue. When
constraining a government CA to issue in a namespace like .gov.in, or .gov,
no one's market choices are limited.

In fact, such a name constraint in the root program would also *not*
require that government to prevent other commercial CAs to issue
certificates for a government suffix. (And, briefly offering my own work
perspective, as someone who configures .gov certificates from commercial
CAs, I would never desire this sort of limitation.)

In short, the public's market choices are unaffected, and the government's
own market choices for their own properties are only expanded.

6) The effectiveness of the Internet as a public resource depends on
> interoperability (protocols, data formats, content), innovation and
> decentralized participation worldwide.
>

That's absolutely correct. However, neither DNS nor the CA system are fully
decentralized. They each depend on political tradeoffs and a careful
evaluation of incentives -- the current IANA transition
<https://www.newamerica.org/oti/controlling-internet-infrastructure/> is an
excellent reminder of that.

> - Name-constraining CAs has the effect of centralizing protocols
> (vis-a-vis DNS)
>

I don't understand the phrasing here. The trusted root program is already a
centralized repository of data that constrains who can become a CA.

> - Name-constraining CAs has the effect of discouraging interoperability by
> introducing multiple semi-subjective criteria into the discussion of trust
> ("What is a Government CA", "What is a government TLD")
>

You're absolutely right that there's a judgment call involved in deciding
"what is a government CA". CNNIC comes to mind as a contested example.

However, in cases where there is no ambiguity about whether the CA is a
government CA -- for example, a CA operated by public sector money in an
internationally recognized country who describes themselves as a government
and who intends to issue for other unambiguously government entities --
there's not much of a subjective judgment call involved there.

I've at length answered your second question posted - which is whether it
> makes things better or worse - and demonstrated the many ways in which it
> can make things worse.
>

I believe you've described the ways in which name constraints can make
things worse *if* various other clearly definable things happen, such as:
commercial CAs being restrained, or a cert for a ccTLD only being issuable
by a particular CA, or a government CA being restrained against their will
from issuing certificates for non-governmental entities. I think we can
discuss name constraining government CAs without invoking these scenarios.

Holistically, your argument describes a slippery slope. I don't believe
slippery slope arguments are wrong, but if you can define an unambiguous
rationale and line for certain behavior, I think the slippery slope
argument can be clearly outweighed.

I mean, the definitional issues alone should show how subjective this is.
> For example, I note you didn't include under "potential government CAs" as
> LuxTrust ("Established in November 2005 through a partnership between the
> Luxembourg government and major private financial actors in Luxembourg"),
> or what the subtle implications are for Certinomis (which partners with La
> Poste to perform identity validation, which is the mail service of France,
> is definitionally an autonomous public enterprise since 1 January 1991,
> when it was split from DGP, but which arguably operates within the
> imprimatur of the French government)
>
> I posit these as simply two examples of many to indicate the very
> difficult challenges with separating 'operational capability'. However,
> would we argue that a CA is wholly independent if it was seeded by
> In-Q-Tel? Why or why not?
>

You describe complicated and ambiguous situations. The best answer to this
kind of ambiguity is to err on the side of No. Don't name constrain them,
and if no name constraints means the root program isn't willing to accept
them, then don't do it.

>
> What about a CA operated by Verizon Business (aka GTE Cybertrust/Baltimore
> Cybertrust?) Some are concerned that it may be participating in NSA
> shenanigans (e.g.
> http://rt.com/usa/168752-germany-boots-verizon-over-spying/ )? Or what
> about several major US telecom providers' complicity in the NSA's
> warrantless wiretapping -
> http://www.wired.com/2010/01/fbi-att-verizon-violated-wiretapping-laws/ ?
>

That's a separate issue. You're definitely correct when you point to
corporate CAs not being definitionally more "trustworthy" than government
CAs. It's a hostile world out there.

However, I do think that if a CA *can* be clearly defined as a "government
CA", and that government CA is interested in issuing for itself -- then,
because an unambiguous government CA operates under fundamentally
different legal and operational constraints than a commercial CA, name
constraints only expand opportunity and flexibility for all parties
involved.

I'll also say that in my opinion, an *unconstrained* government CA whose
operational mandate is only to issue for itself has a worse impact on the
quality of the trust store than an unconstrained commercial CA. Name
constraints seem the only appropriate way to admit a government CA to the
trust store who is only supposed to be in the business of issuing for
themselves. If name constraints aren't applied, I'd advocate for rejecting
that CA's application.

> There are so many more important things to spend our time on with regards
> to improving trust. Simply embracing and encouraging greater transparency
> (e.g. through Certificate Transparency) could go a long way in
> establishing an objective basis for discussions about trustworthiness, and
> the quality of audits, and the compliance and adherence to technical
> requirements, rather than gut speculation and the jingoistic
> sentimentality it inevitably invites.
>

Certificate transparency and public key pinning are fantastic technical
patches to the global CA system, and the CAB BRs and audit quality are
crucial human patches.

Name constraints are also a patch, and they provide a function not offered
by CT, PKP, BRs, or audits. When applied in a non-ambiguous, narrow way on
actors who clearly differ in the accountability and leverage that human
institutions can bring to bear on them, those name constraints make the CA
system and root program more flexible, not more brittle.

-- Eric



>
> _______________________________________________

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



--

konklone.com | @konklone <https://twitter.com/konklone>

[Ryan Sleevi]

On Sat, May 16, 2015 4:45 pm, Eric Mill wrote:
> Another factor is _why_ the government CA is applying to the trusted root
> program. If the government CA only intends to issue certs for its own
> properties, and its properties can reasonably be concluded to fall under a
> clear name jurisdiction, then name constraints don't actually "constrain"
> their business model. This avoids "slippery slope" concerns that might
> lead
> to constraining a commercial CA against their will.

Just to be explicit here - you're defining government CAs not as CAs
operated by a government, but CAs that tailor exclusively to a government.
That is, the "why" is just a definitional short-hand for how to declare
something as government vs non-government.

In the cases where the CA is already restricted in its name issuance (e.g.
"Government of Japan" claims to only issue for .go.jp domains, HARICA is
already name constrained, etc), there is nothing intrinsically wrong or
objectionable with encoding that in code.

However, I don't think that's the thrust of Gerv's message, because
Mozilla's happily been doing it for some time already. It's a question of
whether it's right to *require* such constraints, and when and how to
determine what those constraints are.

So that we can discuss concrete matters, rather than hypotheticals (which,
while useful, I think idealize things a bit too much)

CATCert - Issues to individuals and corporations, not just public sector.

ANSSI/DCSSI - Applies to government *and* administrative organizations of
France. No explicit name constraint in their administrative policies is
documented, although has been unilaterally imposed by browsers as a result
of misissuance.

Certizen - Applies not just to e-governence but also e-commerce
organizations in Asia (not just HK)

Government of Japan - Two roots (GPKI, LGPKI), only one included (GPKI)
because they failed to respond in a timely manner w/r/t LGPKI questions.
The GPKI root is "mostly" .go.jp, except evena t time of application, they
had non-.go.jp names (
https://groups.google.com/d/msg/mozilla.dev.security.policy/XHaBWlrfIjk/ZtRW6ioT9CMJ
). The policies themselves don't constraint them to .go.jp, AFAICT

Government of Spain (ACCV) - Operates as a public CA that caters to the
citizens (e.g. how identity validation is performed) *and* local
corporations.

GRCA / Chungwa Telecom - Can't find any English version of their CP/CPS.
Their CP/CPS repository links to a revoked WebTrust seal (although they do
have a newer one), they lack a BR audit, etc. I haven't dug into the
Mozilla Salesforce to see actual details. From their original inclusion
request, and from the GRCA documentation, however, they're not exclusively
government sites.

PKIoverheid - Effectively a bridge CA (e.g. what Mozilla has so far
rejected from other countries, such as the US Government or that of
Brazil). PKIoverheid sets up the requirements for secondary CSPs, which it
then certifies and cross-signs. Per their CSP, they cater both to
government and businesses, and serve a Dutch community but not a Dutch
namespace.

Kamu SM - Similar to ACCV, GRCA, Certizen; no explicit government-only scope

HARICA - Already self-constrained

CNNIC - 'nuff said.

So looking in that above list - the list Gerv proposed as those that may
fit one or more definitions of "government CA", there is only one that is
exclusively tied to a domain namespace (HARICA), and one "almost"
constrained to a domain namespace (Government of Japan). The rest are all
operated by government, but apply to individuals and corporations and not
just public sector.

> If a government CA is applying in order to provide certificates for its
> country's corporations or citizens, that's a more complicated issue.
> Treating ccTLDs (e.g. .in) as actually geographically bound, for the
> purpose of a CA system, seems brittle and very much something that
> *advances* the idea of the internet as geographically bound.

As the above list shows, this is by far and away the dominant reason. If
you further read the CP/CPSes/inclusion bugs (which I went through before
replying to this message), you will find that the primary justification
for why the government CA even exists is because the government wants to
set its standards for identity validation according to local customs,
mores, and laws. This is important later on in this message.

> As described above, this is not always correct. In the case of a
> government
> asking for admittance to the root program for the intent of issuing
> trusted
> certs for its own organization, the government is not asking to "openly
> participate" in the first place. They are asking to participate with a
> closed set of domains, and name constraints can function to enforce that
> closed participation.

As described above, you can see this is not the case in general,
especially not the case for the CAs that people are concerned about today.

> In fact, such a name constraint in the root program would also *not*
> require that government to prevent other commercial CAs to issue
> certificates for a government suffix. (And, briefly offering my own work
> perspective, as someone who configures .gov certificates from commercial
> CAs, I would never desire this sort of limitation.)

You may not desire it, but as I described above, it's already the desire
of many of these governments' operating their CAs for precisely that.

Indeed, if you take the broader look at the policies of the governments
behind such CAs, you will often find that corporations will be enjoined to
use the chosen government CA (such as when it's a meta-CA, as with
PKIoverheid) or to use a CA that participates in the governments'
certification program.

Indeed, this is precisely why audit criteria like ETSI exist! Take a look
at India (required if handling taxpayer info to use an appropriately
certified CA) or Turkey (a roughly similar story).

That is, these government CAs exist not just to offer specialized services
for their citizenry, they exist to support the e-signature/e-commerce
regulations of the appropriate nationstates.

The logical implication of this is that if you can imagine a definition
where we say government CAs (those either operated directly by or under
the supervision of) a given state, like say India, would be constrained to
a namespace, such as .in, then *we're* (trust store maintainers, the
community at large) saying that commercial organizations that which to
perform those actions in India MUST use a .in domain (since they can't get
a cert from one of the CAs unless they do). And thus, naturally, have even
greater risk of interference by India (not to pick on India, it's just a
more familiar example a result of investigating India CCA)

I'm not concerned about such constraint policies *requiring* governments
from peventing other commercial CAs. They already do that. I'm worried
about it *enabling* even greater restrictions on an open Internet and that
governments' citizenry.

> However, in cases where there is no ambiguity about whether the CA is a
> government CA -- for example, a CA operated by public sector money in an
> internationally recognized country who describes themselves as a
> government
> and who intends to issue for other unambiguously government entities --
> there's not much of a subjective judgment call involved there.

Look through the examples Gerv noted, and you will see that while this is
a theoretical possibility for such entities, it is the exception, not the
rule, and thus doesn't answer the core question.

> I believe you've described the ways in which name constraints can make
> things worse *if* various other clearly definable things happen, such as:
> commercial CAs being restrained,

Already happening

> or a cert for a ccTLD only being issuable
> by a particular CA,

Already possible today

> or a government CA being restrained against their will
> from issuing certificates for non-governmental entities.

The natural implication for the CAs initially suggested as "government CAs"

> I think we can
> discuss name constraining government CAs without invoking these scenarios.

As you can see above, they're all very real *today*, so I don't think we
can, nor do I think we should, since we have amble evidence about the
existing nuance in the system that we cannot ignore and must account for.

> Name constraints are also a patch, and they provide a function not offered
> by CT, PKP, BRs, or audits. When applied in a non-ambiguous, narrow way on
> actors who clearly differ in the accountability and leverage that human
> institutions can bring to bear on them, those name constraints make the CA
> system and root program more flexible, not more brittle.

I understand and agree with you here - but I don't believe that's what is
under discussion here, because that definition has long been functioning
within Mozilla.

I say this because knowing Gerv, and having participated with him on the
call, I suspect that in part this is motivated by
https://cabforum.org/2015/04/16/2015-04-16-minutes/ , in which Microsoft
has suggested they'll require "government CAs" (definition not provided)
to be constrained (how not provided). The details of which are only
available under NDA with Microsoft.

Of course, that creates a variety of problems for public debate around the
issues, hence this thread here, which has also been renewed by other
discussions of constraining (or rejecting) government CAs in other fora.
So while I agree that a self-constrained (by law) government CA that
wishes technical constraints (or discloses their constraint) is a
non-issue for adding constraints, we do need to have the broader
discussion of "operated on or behalf of a government" and the implications
there, which are almost certainly unilaterally imposed rather than
self-imposed.

[Eric Mill]

On Sat, May 16, 2015 at 6:12 PM, Ryan Sleevi <
ryan-mozde...@sleevi.com> wrote:

> On Sat, May 16, 2015 4:45 pm, Eric Mill wrote:
> > Another factor is _why_ the government CA is applying to the trusted
> root
> > program. If the government CA only intends to issue certs for its own
> > properties, and its properties can reasonably be concluded to fall
> under a
> > clear name jurisdiction, then name constraints don't actually
> "constrain"
> > their business model. This avoids "slippery slope" concerns that might
> > lead
> > to constraining a commercial CA against their will.
>
> Just to be explicit here - you're defining government CAs not as CAs
> operated by a government, but CAs that tailor exclusively to a government.
> That is, the "why" is just a definitional short-hand for how to declare
> something as government vs non-government.
>

Well, I see "government vs non-government" as more a function of who
operationally controls it, and then the "why" of their target domains as a
measure of how forcibly the constraints are being imposed. But it probably
amounts to the same thing.

> In the cases where the CA is already restricted in its name issuance (e.g.
> "Government of Japan" claims to only issue for .go.jp domains, HARICA is
> already name constrained, etc), there is nothing intrinsically wrong or
> objectionable with encoding that in code.
>

Understood -- I think this fact had been obscured in previous and current
email threads about the topic, and may not have been obvious to observers.

> So that we can discuss concrete matters, rather than hypotheticals (which,
> while useful, I think idealize things a bit too much)
>

> ... [snip] ...
>
> CNNIC - 'nuff said.
>

I'm already happy I wrote my email, so that I could at least motivate the
list of government-ish CA applications being detailed somewhere besides PDF
attachments to bugzilla threads. :) That's super helpful and fascinating.

> If a government CA is applying in order to provide certificates for its
> > country's corporations or citizens, that's a more complicated issue.
> > Treating ccTLDs (e.g. .in) as actually geographically bound, for the
> > purpose of a CA system, seems brittle and very much something that
> > *advances* the idea of the internet as geographically bound.
>
> As the above list shows, this is by far and away the dominant reason. If
> you further read the CP/CPSes/inclusion bugs (which I went through before
> replying to this message), you will find that the primary justification
> for why the government CA even exists is because the government wants to
> set its standards for identity validation according to local customs,
> mores, and laws. This is important later on in this message.
>

The list above covers CAs currently in the root store, not those applying,
but yes, that was definitely illuminating.

That is, these government CAs exist not just to offer specialized services
> for their citizenry, they exist to support the e-signature/e-commerce
> regulations of the appropriate nationstates.
>
> The logical implication of this is that if you can imagine a definition
> where we say government CAs (those either operated directly by or under
> the supervision of) a given state, like say India, would be constrained to
> a namespace, such as .in, then *we're* (trust store maintainers, the
> community at large) saying that commercial organizations that which to
> perform those actions in India MUST use a .in domain (since they can't get
> a cert from one of the CAs unless they do). And thus, naturally, have even
> greater risk of interference by India (not to pick on India, it's just a
> more familiar example a result of investigating India CCA)
>
> I'm not concerned about such constraint policies *requiring* governments
> from peventing other commercial CAs. They already do that. I'm worried
> about it *enabling* even greater restrictions on an open Internet and that
> governments' citizenry.
>

That makes perfect sense, and that dynamic was not clear to me from past or
present email threads. Constraining government CAs, whose use by their
country's citizens and corporations is mandated, to a ccTLD amounts to a
restraint on citizens' and corporations' choice of DNS TLD.

However, what's to stop a government from mandating that commercial
organizations operating in their country must use a ccTLD to conduct
business? If that were to happen, wouldn't that render the concern above
moot, and leave the root program with only the downside of unconstrained
government CAs?

> Name constraints are also a patch, and they provide a function not
> offered
> > by CT, PKP, BRs, or audits. When applied in a non-ambiguous, narrow way
> on
> > actors who clearly differ in the accountability and leverage that human
> > institutions can bring to bear on them, those name constraints make the
> CA
> > system and root program more flexible, not more brittle.
>
> I understand and agree with you here - but I don't believe that's what is
> under discussion here, because that definition has long been functioning
> within Mozilla.
>
> I say this because knowing Gerv, and having participated with him on the
> call, I suspect that in part this is motivated by
> https://cabforum.org/2015/04/16/2015-04-16-minutes/ , in which Microsoft
> has suggested they'll require "government CAs" (definition not provided)
> to be constrained (how not provided). The details of which are only
> available under NDA with Microsoft.
>

That was also not at all obvious to me, or potentially other outside
observers. The policies of Microsoft's root program seem mostly out of
scope here, but whether or not those name constraint policies are disclosed
seems highly relevant to making productive decisions about "the CA system".

Of course, that creates a variety of problems for public debate around the
> issues, hence this thread here, which has also been renewed by other
> discussions of constraining (or rejecting) government CAs in other fora.



> So while I agree that a self-constrained (by law) government CA that
> wishes technical constraints (or discloses their constraint) is a
> non-issue for adding constraints, we do need to have the broader
> discussion of "operated on or behalf of a government" and the implications
> there, which are almost certainly unilaterally imposed rather than
> self-imposed.
>

And to be clear, I've tried to frame the imposition of constraints as a
spectrum, not a binary. I think it's appropriate to apply *some* pressure
on a government CA to accept constraints when their administrative role is
clearly supposed to be for their own organizational needs, even if it
causes the CA operational or political friction. The constraint needn't
rise to the level of a law in that country.

Thanks for fleshing this discussion out with so much more detail, Ryan.
That was extremely helpful.

-- Eric

[Peter Bowen]

On Thu, May 14, 2015 at 8:25 AM, Gervase Markham <ge...@mozilla.org> wrote:
> The topic of name-constraining government CAs, probably to the TLD(s) of
> their territory(ies), has come up numerous times. I'd like to try and
> hash out, once and for all, whether we think this is actually a good
> idea, so we can decide to work towards doing it, or decide actively not
> to do it. And then document the decision.
>
> Questions
> =========
>
> The key questions I would like to discuss to begin with are:
>
> 1) "Is the security analysis relating to government CAs, as a class,
> different to that relating to commercial CAs? If so, how exactly?"
>
> 2) "If it is different, does name-constraining government CAs make
> things better, or not?"
>
> These questions will probably lead us, in passing, to discuss how to
> define "government CA", but let's try not to let that dominate the
> discussion. If possible, stick to clear examples.

I'll bite.

What if Mozilla puts a simple rule in place?

All CAs must either:
- Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a
assessor who meets the requirements of BR 8.2 or
- Be named constrained

"Government CAs" (whatever that means) can either choose to meet the
same standards as everyone else or be name constrained. If they want
to use an auditor who fails an independence test or do not want to
follow the BR, then they must be constrained.

This would seem to be a fairly simple rule.

Thanks,
Peter

[Ryan Sleevi]

On Sun, May 17, 2015 3:28 pm, Peter Bowen wrote:
> What if Mozilla puts a simple rule in place?
>
> All CAs must either:
> - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a
> assessor who meets the requirements of BR 8.2 or
> - Be named constrained
>
> "Government CAs" (whatever that means) can either choose to meet the
> same standards as everyone else or be name constrained. If they want
> to use an auditor who fails an independence test or do not want to
> follow the BR, then they must be constrained.
>
> This would seem to be a fairly simple rule.

Let's unpack this. It operates under the assumption that we want more, not
fewer, government CAs, and it operates under the assumption that the
current audit regimes are too onerous. Is that a fair summary?

Let's look at the CAs Gerv mentioned again. I'm using
https://wiki.mozilla.org/CA:IncludedCAs rather than Salesforce, for now.

* CATCert - Webtrust for CAs, but no BR audit
* ANSSI - ETSI TS 102 042 audit, but questionable as to who and how recent
(http://www.ssi.gouv.fr/administration/services-securises/igca/attestation-de-realisation-daudits-relatifs-a-ligca/
). Based on 2011 criteria, so unlikely BR compliant
* Certizen - Webtrust for CAs, but no BR audit
* Government of Japan - WebTrust for CAs, but no BR audit
* ACCV - Webtrust for BRs
* GRCA - Webtrust for CAs, but no BR audit
* PKIoverheid - Webtrust for BRs
* Kamu SM - ETSI TS 102 042, except by an auditor who may not be qualified
to actually perform the audit (ICTA)
* HARICA - ETSI TS 102 042
* CNNIC - Webtrust for BRs

So looking at the list of "government CAs", what we see is that only four
meet the proposed "BR" criteria (ACCV, PKIoverheid, HARICA, CNNIC), and at
least one of those stuffed things up epically (CNNIC), and at least one
was implicated in the most notorious stuffup (PKIoverheid's supervision of
Diginotar)


Now, the logical implication if we accept your criteria is how to decide
what to constrain them to. Should Mozilla be in a place to decide that .jp
users get less security than .com? How would Mozilla establish, for
example, that ANSSI was authorized for French TLDs? CNNIC is perhaps the
easier example, being the .cn holder, but Kamu SM doesn't control .tr.

And what about the Turkish CAs that have gone through WebTrust or ETSI
audits (thus paid the hundreds of thousands of US dollars inevitably
involved in the design, provisioning, and compliance with these policies).
They're competing with a Government entity who has a lower barrier to
entry than they do, and thus can be priced out of the .tr space by the
government itself. Should Mozilla have an opinion on that?

And what are the criteria we would use to establish government? India CCA,
for example, is in a similar case as CNNIC, in which the TLD registrar
also operates the CA, while the South African Post Office Limited isn't
the same as the ZADNA registry. How will we come up with a definition
that, for example, wouldn't allow Turktrust to apply with an 'unaudited'
root that happens to be recognized under the TBBM?

Why would the definition you propose be more desirable than simply
requiring a BR audit for *all* applicants? It would definitely support
that some TLDs have weaker security than other TLDs, by virtue of who can
issue.


I guess fundamentally I'm concerned with "government CAs" as an unanswered
definition, since I fear it inevitably becomes "any CA" can either "follow
the rules" or "be constrained". The most natural risk is that a US CA
(government or otherwise) could apply to be constrained for .com, without
having any audit controls in place. How would the proposed definition
prevent it? I posit it wouldn't, and we'd all lose because of that.

[Peter Bowen]

> Why would the definition you propose be more desirable than simply
> requiring a BR audit for *all* applicants? It would definitely support
> that some TLDs have weaker security than other TLDs, by virtue of who can
> issue.

I was assuming this discussion was based on the concept that
Government CAs did not need to meet all the audit criteria. Otherwise
why are we having it?

> I guess fundamentally I'm concerned with "government CAs" as an unanswered
> definition, since I fear it inevitably becomes "any CA" can either "follow
> the rules" or "be constrained". The most natural risk is that a US CA
> (government or otherwise) could apply to be constrained for .com, without
> having any audit controls in place. How would the proposed definition
> prevent it? I posit it wouldn't, and we'd all lose because of that.

I was attempting to use the definition that already exists in the
Mozilla policy, but was a little too short. Each CA must pass a BR
audit or be technically constrained to only issue certificates for
domains where the registrant has authorized the CA to act on their
behalf. Right now there is no option for a Root CA to be technically
constrained. I'm suggesting there may be CAs which "provide some
service relevant to typical users of [Mozilla] software products" even
if they don't pass a BR audit, because the service they provide is
used by a large number of typical users, so possibly it is appropriate
to allow technically constrained root CAs.

This still leaves open two issues:
1) What is the criteria for "relevant to typical users"? Does
allowing technically constrained roots open the doors to every
corporate CA claiming they issue certs for their public websites, so
they should be considered relevant?

2) What if a ccTLD has a registration agreement that says "all
registrants must authorize XX CA to operate on their behalf"? Does
this meet technical constraint rules?

Thanks,
Peter

[Ryan Sleevi]

On Sun, May 17, 2015 6:06 pm, Peter Bowen wrote:
> I was assuming this discussion was based on the concept that
> Government CAs did not need to meet all the audit criteria. Otherwise
> why are we having it?

Why indeed ;)

As I mentioned in my reply to Eric, my own suspicion is that this
conversation has restarted as a result of Microsoft's soft-announcement to
the CA/B Forum to look at constraining government CAs, and the question
inevitably is what should or can Mozilla do?

This is a conversation that's come up multiple times. In general, the
context has not been "How do we get more 'government CAs' in" but "What do
we do with the existing 'government' CAs?"

For example, there were concerns raised at the time of CNNIC's inclusion
that it was a government CA, and as such, should be treated differently
during its application. CNNIC denied that at the time of application
(although later changes in management structure made that denial more
problematic), and they were accepted because they fully complied with the
program requirements (WebTrust).

I think intrinsic to Gerv's remarks, especially when looking at the
existing CAs, is the question of whether we should treat governments
differently. Eric and David's responses are illustrative of that thing.

> This still leaves open two issues:
> 1) What is the criteria for "relevant to typical users"? Does
> allowing technically constrained roots open the doors to every
> corporate CA claiming they issue certs for their public websites, so
> they should be considered relevant?

Indeed. I didn't want to pose too many hypotheticals at once, but I think
this is one of the questions that falls out. If we believe unaudited CAs
are good for .ccTLD, should an unaudited CA be good for a ".brand" TLD?
Why or why not? As ICANN deals with the glut of thousands of new domain
names, should we allow a root (or more!) per gTLD be added? Why or why
not?

> 2) What if a ccTLD has a registration agreement that says "all
> registrants must authorize XX CA to operate on their behalf"? Does
> this meet technical constraint rules?

I'm not quite sure I follow this point.

[Peter Bowen]

On Sun, May 17, 2015 at 7:59 PM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:
> On Sun, May 17, 2015 6:06 pm, Peter Bowen wrote:
>> I was assuming this discussion was based on the concept that
>> Government CAs did not need to meet all the audit criteria. Otherwise
>> why are we having it?
>
> Why indeed ;)
>
> As I mentioned in my reply to Eric, my own suspicion is that this
> conversation has restarted as a result of Microsoft's soft-announcement to
> the CA/B Forum to look at constraining government CAs, and the question
> inevitably is what should or can Mozilla do?

As indicated, Microsoft has only released their draft of new
requirements under NDA, so the next best thing is to look at their
existing requirements for audits:
http://social.technet.microsoft.com/wiki/contents/articles/26675.windows-root-certificate-program-audit-requirements-for-cas.aspx

They do not require Government CAs to complete either ETSI or WebTrust
audits; instead they can claim "equivalency" under "local law or
regulation". It is announced that this is being phased out over the
next 18 months.

>From this thread, it seems clear that Mozilla does not intend to have
a similar allowances for government CAs. The only open item is when
Mozilla intends to enforce the requirement of having a BR audit and
remove the SSL trust bit from those that do not.

Thanks,
Peter

[Kurt Roeckx]

On 2015-05-14 17:25, Gervase Markham wrote:
> 2) "If it is different, does name-constraining government CAs make
> things better, or not?"

I think it only makes sense to name constrain a government CA if the
name constrained only covers government websites, and not all websites
in the country. Examples would be covering *.gov and *.go.jp. I think
that restricting them to *.jp, *.in, *.cn and so on doesn't actually add
enough value.

I would also like to point out that even when you have a government CA
for certain things that not all websites need to chain to the government
CA but that they can buy certificates from a commercial CA too.


Kurt

[Matt Palmer]

On Mon, May 18, 2015 at 12:26:26PM +0200, Kurt Roeckx wrote:
> On 2015-05-14 17:25, Gervase Markham wrote:

> >2) "If it is different, does name-constraining government CAs make
> >things better, or not?"
>

> I think it only makes sense to name constrain a government CA if the name
> constrained only covers government websites, and not all websites in the
> country. Examples would be covering *.gov and *.go.jp. I think that
> restricting them to *.jp, *.in, *.cn and so on doesn't actually add enough
> value.

This sounds an awful lot like "we're OK with someone having a
name-constrained intermediate that only covers a namespace they own".
Doesn't seem like we really need a separate rule just because they're a
government, although whether we'd want everyone trying to get their
name-constrained roots into Mozilla (rather than just, say, getting a
name-constrained intermediate) is a matter for some debate.

- Matt

[Kurt Roeckx]

We're only talking about name constraints at this point and not Extended
Key Usage. It's the combination of the two that would turn it into a
"Technically Constrained CA".

If we were to say that we require government CAs to be technically
constrained there would of course be no need to have them in the root
program. But as you say, whether we then still want them in the root
store or not in an other discussion.


Kurt

[Gervase Markham]

On 17/05/15 02:12, Ryan Sleevi wrote:
> I say this because knowing Gerv, and having participated with him on the
> call, I suspect that in part this is motivated by
> https://cabforum.org/2015/04/16/2015-04-16-minutes/ , in which Microsoft
> has suggested they'll require "government CAs" (definition not provided)
> to be constrained (how not provided). The details of which are only
> available under NDA with Microsoft.

Yes; it is correct to say that Microsoft mentioning this possibility is
what led me to try and reach a conclusion (one way or another) on this
debate.

I wanted to avoid the situation where they announced something, and a
load of people said "what a good idea; what is Mozilla doing?", and we
didn't know, and then we had to have a discussion in the shadow of their
first-mover status.

Gerv

[Gervase Markham]

On 17/05/15 23:28, Peter Bowen wrote:
> I'll bite.
>
> What if Mozilla puts a simple rule in place?
>
> All CAs must either:
> - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a
> assessor who meets the requirements of BR 8.2 or
> - Be named constrained

The result of that would be that Kamu SM would either change its auditor
or be name constrained. There would be no other changes. ANSSI is the
only other CA which does not use an auditor which fits our criteria, and
it is already name-constrained.

> This would seem to be a fairly simple rule.

Indeed. However, this has not addressed my question about whether the
security analysis for government CAs is different to that of commercial
CAs. :-)

Gerv

[Gervase Markham]

On 18/05/15 11:26, Kurt Roeckx wrote:
> I think it only makes sense to name constrain a government CA if the
> name constrained only covers government websites, and not all websites
> in the country. Examples would be covering *.gov and *.go.jp. I think
> that restricting them to *.jp, *.in, *.cn and so on doesn't actually add
> enough value.

Why not? How is the security analysis different for the two options?

Gerv

[Gervase Markham]

On 18/05/15 14:45, Gervase Markham wrote:
> On 17/05/15 23:28, Peter Bowen wrote:
>> I'll bite.
>>
>> What if Mozilla puts a simple rule in place?
>>
>> All CAs must either:
>> - Have a WebTrust for BR and ETSI TS 102 042 assessment conducted by a
>> assessor who meets the requirements of BR 8.2 or
>> - Be named constrained
>
> The result of that would be that Kamu SM would either change its auditor
> or be name constrained. There would be no other changes. ANSSI is the
> only other CA which does not use an auditor which fits our criteria, and
> it is already name-constrained.

Apologies, that's not true, if you want to require an unqualified BR
audit. There would be other CAs who didn't meet the first option -
although it's not just government CAs which don't yet have a BR audit,
so the changes would be on both sides of the aisle.

Gerv

[Gervase Markham]

On 17/05/15 00:45, Eric Mill wrote:
> Governments are not subject to the same kind of leverage, accountability or
> market forces that corporations are. The legal constraints they operate
> under are different, your likelihood of prevailing in a legal action
> against them is different (and highly subject to the government in
> question), and their business practices and incentives are going to be very
> different.
>
> In other words, you cannot expect a government CA to respond to the same
> kinds of forces, either market pressure or deliberate browser/community
> pressure, that a commercial CA would. This distinguishes those kinds of CAs
> in a way that does *not* require to you to rest on the vague or general
> idea that governments are less trustworthy than corporations.

....

> We, the browsers and standards bodies of the internet and the people >
of the earth, have very different leverage over abuses by a
> corporation than by a government.

These are the sort of differences that I was thinking of. I would be
interested in hearing from the "no constraints" proponents on why these
differences are not (sufficiently) important or not relevant.

> If a government CA is applying in order to provide certificates for its
> country's corporations or citizens, that's a more complicated issue.
> Treating ccTLDs (e.g. .in) as actually geographically bound, for the
> purpose of a CA system, seems brittle and very much something that
> *advances* the idea of the internet as geographically bound.

Well, governmental authority is geographically bound.

> By contrast, to constrain a government to its own properties (e.g. .gov.in
> or .gov) doesn't advance a geographic boundary, but an organizational
> boundary.

The position that constraining e.g. the Government of India to .in is
bad but to gov.in is OK is an interesting one. I didn't expect anyone to
make that argument.

Gerv

[Gervase Markham]

Before I reply, can I say that this level of informed and considered
debate is _exactly_ what I was looking for? Thanks to everyone who has
participated so far.

On 15/05/15 19:49, Ryan Sleevi wrote:
> - By introducing a demarcation of power/privilege by "government" or not
> (which still suffers from the definitional issue that you've entirely
> danced around :P), it ostensibly undermines the notion of global

I'm not sure that's so. It says that governments aren't global. If we
started name-constraining non-government CAs, it might well undermine
the notion of "global".

> (e.g. if
> you're required, by local jurisdiction, to only use CAs approved by
> Country A, then you can no longer apply for any arbitrary name but only
> those CAs approved by Country A can issue to)

I guess some jurisdiction could make that rule, but how does that relate
to what we are suggesting? Are you saying that if Mozilla
name-constrains government CAs, that would somehow encourage governments
to have "approved CA" lists for their citizens?

> - By introduction restrictions on what government CAs can do, it creates a
> different standard of openness. That is, it presumes corporations are
> trustworthy and governments are not (this is your first question, which is
> implicitly answered in the positive in any discussion pro-constraint), and
> corporations can openly participate while governments cannot.

I don't agree that name-constraining government CAs must necessarily be
interpreted as making a statement about their trustworthiness.

But I do also think that it is much more likely that people around the
world have divergent views of the trustworthiness of government X than
they do of random CA Y.

> - In the pro-constraint case, which again arguably answers the first
> question you pose by saying "Yes, there is a difference", it introduces
> the beginnings of technical control to introduce borders on the Internet,
> by (effectively) restricting what domains individuals can purchase, and
> further encouraging a centralization of names that are in government
> control.

If a government can make a law that "everyone has to use CA Foo", then
they can (if they want) just as easily make a law that "everyone has to
use a .ourcountry domain". If it were advantageous to them to do so,
wouldn't they do it already?

> 6) The effectiveness of the Internet as a public resource depends on
> interoperability (protocols, data formats, content), innovation and
> decentralized participation worldwide.
>
> - Name-constraining CAs has the effect of centralizing protocols
> (vis-a-vis DNS)

Not following you there either, I'm afraid :-(

> - Name-constraining CAs has the effect of discouraging interoperability by
> introducing multiple semi-subjective criteria into the discussion of trust
> ("What is a Government CA", "What is a government TLD")

I'm not sure that subjectivity is an interoperability issue. The fact
that the Government of Somwhereistan's certificate for .com is
recognised in IE and not in Firefox is an interoperability issue, of course.

>>> In case it's not clear, I think imposing name-constraints on CAs to be
>>> bad
>>> for the web and not a scalable solution, even if it appears attractive
>>> :)
>>
>> Again, expansion on these points would be appreciated :-)
>
> I'm sure just as you wish for me to expand on this, I wish to understand
> what specifically you're asking about.

How is it bad for the web? (You have started to expand on this already.)

How is it not a scalable solution?

> This conversation has been raised multiple times, and I've raised multiple
> objections and concerns each time it's been raised.

I hope (perhaps naively) that the outcome of this discussion will be
consensus, and a document outlining the reasoning, so we don't have to
discuss it again.

> For better or for
> worse, I've written fairly extensively on this list why it's a bad idea,
> and why various proposed modifications are equally problematic.

My apologies for having a short memory; feel free to reference earlier
posts you have made.

> I mean, the definitional issues alone should show how subjective this is.

I agree there are definitional issues; I don't agree that they are
collectively a showstopper.

> There are so many more important things to spend our time on with regards
> to improving trust. Simply embracing and encouraging greater transparency
> (e.g. through Certificate Transparency) could go a long way in
> establishing an objective basis for discussions about trustworthiness, and
> the quality of audits, and the compliance and adherence to technical
> requirements, rather than gut speculation and the jingoistic
> sentimentality it inevitably invites.

"Certificate Transparency is becoming a thing; therefore this move is
unnecessary, because if governments acted badly, we'd know" would be an
argument with reasonable weight.

Gerv

[Gervase Markham]

On 17/05/15 00:45, Eric Mill wrote:

> Governments are not subject to the same kind of leverage, accountability or
> market forces that corporations are. The legal constraints they operate
> under are different, your likelihood of prevailing in a legal action
> against them is different (and highly subject to the government in
> question), and their business practices and incentives are going to be very
> different.
>
> In other words, you cannot expect a government CA to respond to the same
> kinds of forces, either market pressure or deliberate browser/community
> pressure, that a commercial CA would. This distinguishes those kinds of CAs
> in a way that does *not* require to you to rest on the vague or general
> idea that governments are less trustworthy than corporations.

...

> We, the browsers and standards bodies of the internet and the people >
of the earth, have very different leverage over abuses by a
> corporation than by a government.

These are the sort of differences that I was thinking of. I would be
interested in hearing from the "no constraints" proponents on why these
differences are not (sufficiently) important or not relevant.

> If a government CA is applying in order to provide certificates for its
> country's corporations or citizens, that's a more complicated issue.
> Treating ccTLDs (e.g. .in) as actually geographically bound, for the
> purpose of a CA system, seems brittle and very much something that
> *advances* the idea of the internet as geographically bound.

Well, governmental authority is geographically bound.

> By contrast, to constrain a government to its own properties (e.g. .gov.in
> or .gov) doesn't advance a geographic boundary, but an organizational
> boundary.

[Kurt Roeckx]

On Mon, May 18, 2015 at 02:48:11PM +0100, Gervase Markham wrote:
> On 18/05/15 11:26, Kurt Roeckx wrote:

> > I think it only makes sense to name constrain a government CA if the
> > name constrained only covers government websites, and not all websites
> > in the country. Examples would be covering *.gov and *.go.jp. I think
> > that restricting them to *.jp, *.in, *.cn and so on doesn't actually add
> > enough value.
>

> Why not? How is the security analysis different for the two options?

There clearly is no trust in certain government, and maybe
governments in general. If the government CA is restricted to
only websites of the government itself, there is no need to trust
that they aren't going to abuse that CA.

On the other hand, if it covers the whole country, they can abuse
it for domains in that country, but not for other domains. I'm
not sure why you would find it acceptable that they can abuse it
in their own country.


Kurt

[Matt Palmer]

On Mon, May 18, 2015 at 02:50:30PM +0100, Gervase Markham wrote:
> On 17/05/15 00:45, Eric Mill wrote:

> > Governments are not subject to the same kind of leverage, accountability or
> > market forces that corporations are. The legal constraints they operate
> > under are different, your likelihood of prevailing in a legal action
> > against them is different (and highly subject to the government in
> > question), and their business practices and incentives are going to be very
> > different.
> >
> > In other words, you cannot expect a government CA to respond to the same
> > kinds of forces, either market pressure or deliberate browser/community
> > pressure, that a commercial CA would. This distinguishes those kinds of CAs
> > in a way that does *not* require to you to rest on the vague or general
> > idea that governments are less trustworthy than corporations.

> ....

> > We, the browsers and standards bodies of the internet and the people >
> of the earth, have very different leverage over abuses by a
> > corporation than by a government.
>

> These are the sort of differences that I was thinking of. I would be
> interested in hearing from the "no constraints" proponents on why these
> differences are not (sufficiently) important or not relevant.

I disagree that "we, the browsers and standards bodies of the Internet" have
very different leverage. In either case, if a CA misbehaves, their root
certs can be pulled from the trust store (or otherwise neutered). That
doesn't change because the CA is run by a corporation or a government.

> > By contrast, to constrain a government to its own properties (e.g. .gov.in
> > or .gov) doesn't advance a geographic boundary, but an organizational
> > boundary.
>

> The position that constraining e.g. the Government of India to .in is
> bad but to gov.in is OK is an interesting one. I didn't expect anyone to
> make that argument.

It's a perfectly reasonable one, assuming that gov.in is, in fact, reserved
for an identifiable entity. If an entity can demonstrate that they have
authority (not just *control*, as in a registrar, but *authority* to do with
it entirely as they see fit) over a namespace, they should be allowed to do
whatever they want within that namespace. It's no different than giving the
entity that has authority over example.com a constrained CA certificate over
that name.

- Matt

--
Yes, Java is so bulletproofed that to a C programmer it feels like being in
a straightjacket, but it's a really comfy and warm straightjacket, and the
world would be a safer place if everyone was straightjacketed most of the
time. -- Mark 'Kamikaze' Hughes

[Matt Palmer]

On Mon, May 18, 2015 at 02:45:26PM +0100, Gervase Markham wrote:
> On 17/05/15 23:28, Peter Bowen wrote:

> > This would seem to be a fairly simple rule.
>

> Indeed. However, this has not addressed my question about whether the
> security analysis for government CAs is different to that of commercial
> CAs. :-)

Short answer: no. Both a commercial CA and a government CA has the same
ability to damage the Internet PKI, and thus they should be held to the same
standards.

- Matt

--
Some people are like slinkies. They don't actually serve any real purpose, but
they still make you smile when you push them down the stairs.

[Eric Mill]

On Mon, May 18, 2015 at 9:15 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
>
> I disagree that "we, the browsers and standards bodies of the Internet"
> have
> very different leverage. In either case, if a CA misbehaves, their root
> certs can be pulled from the trust store (or otherwise neutered). That
> doesn't change because the CA is run by a corporation or a government.
>

Except that corporations and governments have totally different options
available as responses to this threat. A government without a trusted CA
has many paths to ensuring its root certificate appears on the browsers
and/or OSes of computers in its country.

There are also multiple trusted root programs, and a government can mandate
the use of the one that works with them most collaboratively.

A government may also view the removal of their root certificate as less
severe than a corporation would. For a commercial CA, the removal of their
root certificate is death (at least to their certficate business). For a
government, it may be only an inconvenience, and may not lead to the
shutdown of any operation depending on it. There are no market forces with
governments.

A commercial CA caught betraying sites or users may be abandoned by the
market, or its owners sued or even imprisoned. A government CA caught doing
something similar is unlikely to be held to the same account.

You're right, there *is* leverage. The nature and strength of that leverage
is different.

-- Eric

> > > By contrast, to constrain a government to its own properties (e.g. .
> gov.in
> > > or .gov) doesn't advance a geographic boundary, but an organizational
> > > boundary.
> >

> > The position that constraining e.g. the Government of India to .in is
> > bad but to gov.in is OK is an interesting one. I didn't expect anyone to
> > make that argument.
>
> It's a perfectly reasonable one, assuming that gov.in is, in fact,
> reserved
> for an identifiable entity. If an entity can demonstrate that they have
> authority (not just *control*, as in a registrar, but *authority* to do
> with
> it entirely as they see fit) over a namespace, they should be allowed to do
> whatever they want within that namespace. It's no different than giving
> the
> entity that has authority over example.com a constrained CA certificate
> over
> that name.
>
> - Matt
>
> --
> Yes, Java is so bulletproofed that to a C programmer it feels like being in
> a straightjacket, but it's a really comfy and warm straightjacket, and the
> world would be a safer place if everyone was straightjacketed most of the
> time. -- Mark 'Kamikaze' Hughes
>

[Matt Palmer]

On Mon, May 18, 2015 at 10:32:05PM -0400, Eric Mill wrote:
> On Mon, May 18, 2015 at 9:15 PM, Matt Palmer <mpa...@hezmatt.org> wrote:
> > I disagree that "we, the browsers and standards bodies of the Internet"
> > have
> > very different leverage. In either case, if a CA misbehaves, their root
> > certs can be pulled from the trust store (or otherwise neutered). That
> > doesn't change because the CA is run by a corporation or a government.
>
> Except that corporations and governments have totally different options
> available as responses to this threat. A government without a trusted CA
> has many paths to ensuring its root certificate appears on the browsers
> and/or OSes of computers in its country.
>
> There are also multiple trusted root programs, and a government can mandate
> the use of the one that works with them most collaboratively.
>
> A government may also view the removal of their root certificate as less
> severe than a corporation would. For a commercial CA, the removal of their
> root certificate is death (at least to their certficate business). For a
> government, it may be only an inconvenience, and may not lead to the
> shutdown of any operation depending on it. There are no market forces with
> governments.
>
> A commercial CA caught betraying sites or users may be abandoned by the
> market, or its owners sued or even imprisoned. A government CA caught doing
> something similar is unlikely to be held to the same account.

I don't see the relevance of anything you wrote, to the perspective of "we,
the browsers and standards bodies of the Internet". We're not here to solve
all the ills of the world; we're here to generate policy for determining
which organisations can be trusted with skeleton keys to the Mozilla-using
parts of the Internet.

- Matt

[Eric Mill]

You said: "I disagree that "we, the browsers and standards bodies of the
Internet" have
very different leverage [over governments than corporations]." My
description above wasn't to lay out the ills of the world, but to describe
why the kind of leverage that browsers and the Mozilla trusted root program
have over a government is very different.

This difference in leverage is important. I'm not saying it justifies
universal name constraints for governments, like the kind that Microsoft is
mysteriously proposing or that Ryan is arguing (persuasively) against as a
blanket policy. I am saying that you can't assign the same weight to how
effective the threat of yanking them from the trust store will be.

If you rule out a policy on name constraining governments in their ccTLD,
then I think the only places left to express this difference in leverage
are in the level of auditing requirements you apply (or exempt) government
applicants from, and whether or not you accept the application at all.

As a relative newcomer to the scene, it's not obvious to me why audit
requirements upon an unconstrained government CA should ever be less
onerous than those of an unconstrained commercial CA.

-- Eric


> - Matt

[Ryan Sleevi]

On Mon, May 18, 2015 10:39 pm, Eric Mill wrote:
> You said: "I disagree that "we, the browsers and standards bodies of the
> Internet" have
> very different leverage [over governments than corporations]." My
> description above wasn't to lay out the ills of the world, but to describe
> why the kind of leverage that browsers and the Mozilla trusted root
> program
> have over a government is very different.

While not helpful to fully fleshing things out, I think I am going to have
to disagree with you on whether or not the leverage is different.

I don't believe it is, either in favour of the browser or in favour of the
government. That is, the browser still has the power to remove a root cert
at will, government or otherwise, when things go badly. Recent events have
illustrated that.

You suggest that governments have leverage to impose or forbid some
browsers, but I don't really think that's accurate or viable. South Korea
is an excellent example of this - where the reliance on SEED directly
(and, indirectly, ActiveX) caused them to miss out on quite a bit of
improvement that the rest of the develop[ed/ing] world saw in Internet
opportunities.

Likewise, Russia's dependence on/insistence on GOST has prove equally...
troublesome.

So yes, a country could require their root, but the usability alone will
lead to a population disatisfied with the government more than a
population disatisfied with a given browser.

> I am saying that you can't assign the same weight to how
> effective the threat of yanking them from the trust store will be.

Personally, I don't find the argument compelling. I think recent events
have shown how much even a government CA cares about their inclusion
status in various root programs. Especially in the case of *all the CAs
Gerv listed*, inclusion *matters* because it forms a meaningful part of
public life for most, and a meaningful part of commercial life for another
large portion. So "who" operates it is irrelevent - the *why* matters.

As a further case in point, consider the facts surrounding Diginotar. The
delays were specifically to accomodate the Dutch who happened to have
built critical government infrastructure using certs from Diginotar. This
is why, for example, the Dutch (and Diginotar) were advising people to
"click through" the warnings to proceed to government sites.

So whether commercial CA or government CA (for virtually any definition we
chose), inclusion, and the removal thereof, IS a meaningful consequence.

> If you rule out a policy on name constraining governments in their ccTLD,
> then I think the only places left to express this difference in leverage
> are in the level of auditing requirements you apply (or exempt) government
> applicants from, and whether or not you accept the application at all.
>
> As a relative newcomer to the scene, it's not obvious to me why audit
> requirements upon an unconstrained government CA should ever be less
> onerous than those of an unconstrained commercial CA.

Agreed. And for Mozilla inclusions, at present, they aren't (mod the ISO
21188:2006 acceptance criteria and that the BR audits are only now
beginning to be enforced, as per the normal sunset of existing inclusions)

[Gervase Markham]

On 19/05/15 02:15, Matt Palmer wrote:
> I disagree that "we, the browsers and standards bodies of the Internet" have
> very different leverage. In either case, if a CA misbehaves, their root
> certs can be pulled from the trust store (or otherwise neutered). That
> doesn't change because the CA is run by a corporation or a government.

I think it does. A CA has no power to compel their customers to remain
their customers; a government does. If we decide to pull the root of the
Government of Somewhereistan, and that government responds by requiring
that all secure websites in .swistan (or all websites hosted on their
territory) use their root, either we have to blink, or all those sites
end up broken in Firefox.

We see this kind of problem to some degree at the moment. The Government
of Brazil has a CA but has not yet managed to meet Mozilla's
requirements for inclusion. For any other commercial CA, that would be a
serious problem, and lead to a loss of business. But they don't seem to
mind that much:
https://bugzilla.mozilla.org/show_bug.cgi?id=438825

In other words, governments _are_ more immune to the leverage of browsers.

Gerv

[Gervase Markham]

On 18/05/15 17:39, Kurt Roeckx wrote:
> On the other hand, if it covers the whole country, they can abuse
> it for domains in that country, but not for other domains. I'm
> not sure why you would find it acceptable that they can abuse it
> in their own country.

Some countries, AIUI, do not have an equivalent of gov.uk or go.jp. What
would you do in those cases?

Gerv

[Matt Palmer]

On Tue, May 19, 2015 at 11:03:06AM +0100, Gervase Markham wrote:
> On 19/05/15 02:15, Matt Palmer wrote:

> > I disagree that "we, the browsers and standards bodies of the Internet" have
> > very different leverage. In either case, if a CA misbehaves, their root
> > certs can be pulled from the trust store (or otherwise neutered). That
> > doesn't change because the CA is run by a corporation or a government.

[...]

> We see this kind of problem to some degree at the moment. The Government
> of Brazil has a CA but has not yet managed to meet Mozilla's
> requirements for inclusion. For any other commercial CA, that would be a
> serious problem, and lead to a loss of business. But they don't seem to
> mind that much:
> https://bugzilla.mozilla.org/show_bug.cgi?id=438825
>
> In other words, governments _are_ more immune to the leverage of browsers.

The *leverage* that can be applied to any particular CA doesn't change based
on who operates it. Regardless of the operator, the only leverage we have
is removal of the CA's root certs from the trust store (or otherwise
neutering them). That certain CAs may not see that as a sufficient reason
to play nice isn't something we can influence.

A low care factor re: removal isn't any sort of bright-line test for
givernment CAs; various corporate CA business models or other factors may
also render them rather more uncaring than the median to the threat of a
browser's leverage. At the same time, some government CAs no doubt would be
severely hampered in their operations were they to be removed from the
Mozilla trust store.

If you want to discuss what to do about CAs for whom the threat of removal
is not a sufficient motivator for good behaviour, let's have that
discussion; no reason to artificially limit it to CAs run by governments.

- Matt

--
Apparently if you are aware that the From: field can be, and often is,
forged, you are overqualified to write antivirus software.
-- Jamie Zawinski, http://www.jwz.org/gruntle/virus.html

[Kurt Roeckx]

Please note that I didn't argue for either adding them or not adding
them, but that to me adding them only makes sense when you can do it
specific enough.

Maybe that means that if the result of this discussion is that they
should be constrained, that they somehow must have an equivalent of
..gov, .gov.uk, and .go.jp.

Please note such a domain should not necessary have some special meaning
in DNS, and it could just be something like "government.TLD" in which
they might have subdomains or not.

Also having something as .gov.uk doesn't mean that all websites in
..gov.uk need to use the UK root CA.


Kurt

[Kurt Roeckx]

On 2015-05-14 17:25, Gervase Markham wrote:

> CAs currently in Mozilla's program which may fit one or more definitions
> of "government CA" are:

It might be a little out of scope of your question, but maybe we should
agree on what we think the (government) CAs should be able to do and
what not.

For instance:
- Websites for the government
- Websites for non-government but government related companies
- Websites for everybody
- Signing other not technically constrained (non-government) CAs
- Identity of citizen
- Role identity
- Code signing
- s/mime
- Internal communication (internal only websites, internal mail, ...)
- ...


Is the answer difference between a commercial CA and a government CA?


Kurt

[Gervase Markham]

On 19/05/15 12:14, Matt Palmer wrote:
> The *leverage* that can be applied to any particular CA doesn't change based
> on who operates it. Regardless of the operator, the only leverage we have
> is removal of the CA's root certs from the trust store (or otherwise
> neutering them). That certain CAs may not see that as a sufficient reason
> to play nice isn't something we can influence.

This seems a bit like playing with words. If you prefer, the levers that
we have are exactly the same, but the effect they have is different. I
call that different leverage; call it something else if you want.

> A low care factor re: removal isn't any sort of bright-line test for
> givernment CAs; various corporate CA business models or other factors may
> also render them rather more uncaring than the median to the threat of a
> browser's leverage.

Can you give an example of an active CA in the root store at the moment
which wouldn't care very much about being removed?

> At the same time, some government CAs no doubt would be
> severely hampered in their operations were they to be removed from the
> Mozilla trust store.

To the extent of shutting down their public operations and telling all
sites to get a root from an alternative CA?

> If you want to discuss what to do about CAs for whom the threat of removal
> is not a sufficient motivator for good behaviour, let's have that
> discussion; no reason to artificially limit it to CAs run by governments.

If a commercial CA would be unthreatened by a removal, then the question
would arise: why are we including them in the first place?

Gerv

[Gervase Markham]

On 19/05/15 13:14, Kurt Roeckx wrote:
> On 2015-05-14 17:25, Gervase Markham wrote:
>> CAs currently in Mozilla's program which may fit one or more definitions
>> of "government CA" are:
>
> It might be a little out of scope of your question, but maybe we should
> agree on what we think the (government) CAs should be able to do and
> what not.

It is out of scope. If the security analysis for governments turns out
to be exactly the same as that for commercial CAs, then there is no
argument for making their capabilities any different.

If we decide the analysis is, in fact, different, we can then go on to
consider what the reasons we have identified for the difference suggest
to us about the best way to react to that difference.

Gerv

[Peter Kurrasch]

‎‎Returning to your original post, Gerv....

> Questions
> =========
> ‎
> The key questions I would like to discuss to begin with are:
> 
> 1) "Is the security analysis relating to government CAs, as a class,
> different to that relating to commercial CAs? If so, how exactly?"

I'll start by offering up 2 definitions:

"Government" is the expression and exercise of policies, priorities, and power by a group of people for the purposes of establishing and maintaining a particular worldview.

A "government CA" is a certificate issuing organization which is owned by, operated by, or run under strict mandate by a governing body, its agencies, or its agents.

When considering the security analysis, I think about both the operation of a government CA (i.e. all the things the audits intend to cover) and the impact of bad acts by that CA. My impression is that the former is getting enough attention so I'll just focus on the latter.

So here is where the difference really lies between government and commercial CAs: control. Governments and, therefore, government CAs wield a level of control that commercial entities normally do not. They have the power to control who is allowed access to web sites that talk about evolution or climate change or plans for citizen uprisings. They have the ability to send agents to your home and harrass you for engaging in immoral acts over the internet.

The power is genuinely immense, and since there is so much more at stake, the security analysis must be considered differently than for commercial CAs.

 

> 2) "If it is different, does name-constraining government CAs make
> things better, or not?"

One situation that is addressed by name constraints is that today it's generally possible for any CA to issue a cert for any domain. In the context of a security analysis that's problematic which is why name constraints has its appeal.

Combine that with the power of governments and add a dash of crime show drama cliché: motive, means, opportunity. ‎The desire--or, perhaps, need--to institute controls gives governments the motive. The extent to which governments own/operate/control the internet infrastructure (or other access to web sites) and are able to issue certs provides the means. And if any CA can issue any cert the opportunity is always there.

So if a decision is made to require name constraints by a government CA that would have the benefit of limiting the opportunities for bad acts. Absent that, are there other mechanisms worth considering that would have a beneficial impact on the motive, means, opportunity formula? One example that comes to mind is separating cert issuance with control of the infrastructure. Still, the question remains what limits do we want to place on governments?

[Kurt Roeckx]

On 2015-05-21 14:56, Peter Kurrasch wrote:
> > 2) "If it is different, does name-constraining government CAs make
> > things better, or not?"
>
> One situation that is addressed by name constraints is that today it's
> generally possible for any CA to issue a cert for any domain. In the
> context of a security analysis that's problematic which is why name
> constraints has its appeal.
>
> Combine that with the power of governments and add a dash of crime show
> drama cliché: motive, means, opportunity. ‎The desire--or, perhaps,
> need--to institute controls gives governments the motive. The extent to
> which governments own/operate/control the internet infrastructure (or
> other access to web sites) and are able to issue certs provides the
> means. And if any CA can issue any cert the opportunity is always there.
>
> So if a decision is made to require name constraints by a government CA
> that would have the benefit of limiting the opportunities for bad acts.
> Absent that, are there other mechanisms worth considering that would
> have a beneficial impact on the motive, means, opportunity formula? One
> example that comes to mind is separating cert issuance with control of
> the infrastructure. Still, the question remains what limits do we want
> to place on governments?

As you say, it limits the opportunities. But does it limit it enough?


Kurt

[Gervase Markham]

On 21/05/15 13:56, Peter Kurrasch wrote:
> ‎‎Returning to your original post, Gerv....

Thank you :-)

> So here is where the difference really lies between government and
> commercial CAs: control. Governments and, therefore, government CAs
> wield a level of control that commercial entities normally do not. They
> have the power to control who is allowed access to web sites that talk
> about evolution or climate change or plans for citizen uprisings. They
> have the ability to send agents to your home and harrass you for
> engaging in immoral acts over the internet.
>
> The power is genuinely immense, and since there is so much more at
> stake, the security analysis must be considered differently than for
> commercial CAs.

Other things governments have the power to do, which are relevant:

1) Mandate that all government websites (which, these days, citizens
often have no option but to use) use a particular CA, such as their
own;

2) Mandate that all websites hosted in their country use a particular
CA, such as their own;

3) Compel a CA within their borders to issue a certificate, and not
tell anyone.

1) and 2) are reasons why commercial pressures do not apply to
government CAs. 1) actually seems a reasonable thing for a government to
do - and it's one big reason why we have governmental CAs in the program
in the first place. 2) is, to my mind, not reasonable.

3) is sometimes given as a reason why government CAs are not all that
different from commercial CAs - "if a government CA can't misissue a
cert, they can just compel a CA to do it for them, so what's the
difference?". But I think there are several differences:

* Not all governments have the power to compel silent cert creation
(some governments still have some ideas about civil liberties);

* Most governments do not host a CA within their borders;

* For those which do, there is sometimes a defence of severe hardship;
if the CA knew its business would be blown up were the misissuance
discovered, it could argue against being compelled to do so.

So while it may be possible to find a jurisdiction where there is no
effective difference between a government CA and a commercial CA hosted
there, I would say this is not true for the large majority of jurisdictions.

>> 2) "If it is different, does name-constraining government CAs make
>> things better, or not?"
>
> One situation that is addressed by name constraints is that today it's
> generally possible for any CA to issue a cert for any domain. In the
> context of a security analysis that's problematic which is why name
> constraints has its appeal.
>
> Combine that with the power of governments and add a dash of crime show
> drama cliché: motive, means, opportunity. ‎The desire--or, perhaps,
> need--to institute controls gives governments the motive. The extent to
> which governments own/operate/control the internet infrastructure (or
> other access to web sites) and are able to issue certs provides the
> means. And if any CA can issue any cert the opportunity is always there.

This is a relevant point. Without even considering motive, governments,
as opposed to commercial CAs, generally have both means and opportunity
to do MITM attacks on their citizens. A commercial CA generally does
not, although that's not entirely true, as some organizations which
control significant bits of internet infrastructure are also CAs or subCAs.

> So if a decision is made to require name constraints by a government CA
> that would have the benefit of limiting the opportunities for bad acts.
> Absent that, are there other mechanisms worth considering that would
> have a beneficial impact on the motive, means, opportunity formula? One
> example that comes to mind is separating cert issuance with control of
> the infrastructure.

I can see the superficial attractiveness of this, although I think that
it would have significantly greater definitional issues than "what is a
government CA?" How do you decide whether a company has enough control
of infrastructure that they can't be a CA? Do you consider local or only
international factors? What if they are a CA, and they grow - do you
have to stop trusting them? And so on.

Gerv

[yuhong...@hotmail.com]

On Thursday, May 14, 2015 at 8:25:52 AM UTC-7, Gervase Markham wrote:
> There are other possibly-government CAs who are in the process of
> applying for inclusion (although some of these requests may be said to
> be dormant), including:
>
> * Government of India (CCA)
> * Autoridad Certificadora Raíz Nacional de Uruguay (ACRN)
> * PostSignum operated by Ceska posta s.p. (Czech Post)
> * Fábrica Nacional de Moneda y Timbre (FNMT)
> * ICP Brasil (Infra-Estrutura de Chaves Públicas Brasileira)
> * Korea Information Security Agency (KISA)
> * Latvian State Radio and Television Centre (LVRTC)
> * Superintendencia de Servicios de Certificación Electrónica (SUSCERTE)
> * PSC-FII
> * South African Post Office Limited (SAPO)
> * Swiss BIT, Swiss Federal Office of Information Technology, Systems and
> Telecommunication (FOITT)
> * U.S. Federal Public Key Infrastructure (US FPKI)
>
> (Also, some of the first set of CAs are applying to add new roots.)

I have been thinking of allowing new government roots to be added under the same criteria as Microsoft's root program provided that the roots are name constrained.

[Brian Smith]

Gervase Markham <ge...@mozilla.org> wrote:

> 1) "Is the security analysis relating to government CAs, as a class,
> different to that relating to commercial CAs? If so, how exactly?"
>

It seems reasonable to assume that governments that have publicly-trusted
roots will provide essential government services from websites secured
using certificates that depend on those roots staying publicly-trusted.
Further, it is likely that, especially in the long run, they will do
things, including pass legislation, that would make it difficult for them
to offer these services using certificates issued by CAs other than
themselves, as being in full control will be seen as being a national
security issue. Further, governments may even pass laws that make it
illegal for browser makers to take any enforcement action that would reduce
or eliminate access to these government services. In fact, it might already
be illegal to do so in some circumstances.

The main sticks that browsers have in enforcing their CA policies is the
threat of removal. However, such a threat seem completely empty when
removal means that essential government services become inaccessible and
when the removal would likely lead to, at best, a protracted legal battle
with the government--perhaps in a secret court. Instead, it is likely that
browser makers would find that they cannot enforce their CA policies in any
meaningful way against government CAs. Thus, government CAs' ability to
create and enforce real-world laws likely will make them "above the law" as
far as browsers' CA policies are concerned.

Accordingly, when a browser maker adds a government CA to their default
trust store, and especially when that government CA has jurisdiction over
them, the browser maker should assume that they will never be able to
enforce any aspect of their policy for that CA in a way that would affect
existing websites that use that CA. And, they will probably never be able
to remove that CA, even if that CA were to be found to mis-issue
certificates or even if that CA established a policy of openly
man-in-the-middling websites.

IIRC, in the past, we've seen CAs that lapse in compliance with Mozilla's
CA policies and that have claimed they cannot do the work to become
compliant again until new legislation has passed to authorize their budget.
These episodes are mild examples show that government legislative processes
already have a negative impact on government CAs' compliance with browsers'
CA policies.

2) "If it is different, does name-constraining government CAs make
> things better, or not?"
>

Name constraints would allow governments that insist on providing
government services using certificates that they've issued themselves to do
so in a way that is totally independent of any browser policies. When a
government agrees to the name constraints, such as the case of the US FPKI
it seems like a no-brainer to add them.

More generally, browsers should encourage CAs to agree to name constraints,
regardless of the "government" status of the CA.

As far as what to do when a CA that is--or seems like--a government CA
wants to be able to issue certificates for everybody, I agree with Ryan
Sleevi and the other Googlers. In general, it seems like CT or similar
technology is needed to deal with the fact that browsers have (probably)
admitted, and will admit, untrustworthy CAs into their programs.

Cheers,
Brian

[Ryan Sleevi]

On Sat, May 30, 2015 2:47 pm, Brian Smith wrote:
> It seems reasonable to assume that governments that have publicly-trusted
> roots will provide essential government services from websites secured
> using certificates that depend on those roots staying publicly-trusted.
> Further, it is likely that, especially in the long run, they will do
> things, including pass legislation, that would make it difficult for them
> to offer these services using certificates issued by CAs other than
> themselves, as being in full control will be seen as being a national
> security issue. Further, governments may even pass laws that make it
> illegal for browser makers to take any enforcement action that would
> reduce
> or eliminate access to these government services. In fact, it might
> already
> be illegal to do so in some circumstances.

While your first two claims are backed by fact and precedent ("Government
CAs sometimes exist to provide government services" and "Governments
sometimes pass laws to require certain CAs"), I think you're wildly off
the mark on others.

It should bear repeating that governments can pass laws of any sort. There
are already plenty of laws that require the use of certain TSPs, which are
entrusted to commercial entities rather than government CAs. Does becoming
a TSP make them a government CA? Of course not (unless you would like to
argue that, say, Symantec is a government CA by virtue of participating as
a TSP in the US FPKI).

However, that you later bring in the idea that government's may pass laws
that make it illegal for browsers to take enforcement is, arguably,
without merit or evidence. If we accept that "governments may pass laws to
do X", then we can also logically assume two related statements

1) Governments may pass laws to compel a CA to issue a certificate to a
party other than a domain applicant.
2) Governments may pass laws to compel browser makers to include
particular roots as trusted.

The added tinge of uncertainty "In fact, it might already be illegal to do
in some circumstances" adds to the fear and doubt already sowed here.

I appreciate the argument you're making, but I don't think it stands up,
beyond a normal and healthy point of paranoia. With respect to
distinguishing a "government CA" from a "commercial CA", however, it
doesn't actually advance your point, because the same arguments could be
made to sow the same fear, uncertainty, and doubt of any commercial CA.

> The main sticks that browsers have in enforcing their CA policies is the
> threat of removal. However, such a threat seem completely empty when
> removal means that essential government services become inaccessible and
> when the removal would likely lead to, at best, a protracted legal battle
> with the government--perhaps in a secret court.

Ah, but if we're worried about protracted legal battles in secret courts,
why aren't we worried about protracted legal battles in secret courts for
inclusion requests? After all, if we were to deny any applicant, who knows
what secret courts may summon the trust stores!

I hope you can see that this argument is without merit, even if
well-intentioned, in that you can argue any position you want by reducing
it to these terms. As such, I don't think it bears consideration - it's a
null argument.

The other part - that removal disrupts government services - relies on an
artificial dichotomy between government and commercial lives. How often do
you pay your taxes each year? Now how often do you Tweet or email or
purchase something online? The risk of disruption to everyday activities
is unquestionably higher for commercial CAs, rather than lower, so doesn't
that mean we can't remove commercial CAs?

> Instead, it is likely that
> browser makers would find that they cannot enforce their CA policies in
> any
> meaningful way against government CAs.

This is a hypothesis that cannot be established, and the arguments used to
establish it in this email can apply to any position one wants to take. As
a result, I find it hard to take it on its face.

After all, why wouldn't we argue that the risk of being sued for tortious
interference exists if a browser removes trust, ergo they can't enforce
their CA policies in any meaningful way?

> Thus, government CAs' ability to
> create and enforce real-world laws likely will make them "above the law"
> as
> far as browsers' CA policies are concerned.
>
> Accordingly, when a browser maker adds a government CA to their default
> trust store, and especially when that government CA has jurisdiction over
> them, the browser maker should assume that they will never be able to
> enforce any aspect of their policy for that CA in a way that would affect
> existing websites that use that CA. And, they will probably never be able
> to remove that CA, even if that CA were to be found to mis-issue
> certificates or even if that CA established a policy of openly
> man-in-the-middling websites.

I find these arguments without supporting merit.

> IIRC, in the past, we've seen CAs that lapse in compliance with Mozilla's
> CA policies and that have claimed they cannot do the work to become
> compliant again until new legislation has passed to authorize their
> budget.
> These episodes are mild examples show that government legislative
> processes
> already have a negative impact on government CAs' compliance with
> browsers'
> CA policies.

I agree, this is the strongest argument against government CAs presented
in this thread, and I wish this, rather than the musings of secret courts
and "maybe impossibles", was the core of your argument.

These arguments apply not just to government CAs (that may rely on
external controls for financing, such as budgets, as you mention) but also
to small commercial CAs (whose profit margins may be too thin to implement
controls).

The response to both should be the same - removal.

> More generally, browsers should encourage CAs to agree to name
> constraints,
> regardless of the "government" status of the CA.

Of this, I absolutely agree. But I think there's a fine line between
"encouraging" and "requiring", and how it's presented is key.

Most importantly, I don't believe for a second that constraints justify a
relaxation of security policy - they're an optional control for the CA to
opt-in to, as a means of reducing their exposure.

Name constraints can't replace compliance with the Mozilla Security
Policy, nor should it, in part or in whole.

> In general, it seems like CT or similar
> technology is needed to deal with the fact that browsers have (probably)
> admitted, and will admit, untrustworthy CAs into their programs.

Here again, we find ourselves in agreement in the midst of remarkable
disagreement.

To be clear, my words are strong here because your argument is so
appealing and so enchanting in a world of post-Snowdonia, in which "trust
no one" is the phrase du jour, in which the NSA is the secret puppet
master of all of NIST's activities, and in which vanity crypto sees a
great resurgence. Your distinctions of government CAs, and their ability,
while well intentioned, rest on arguments that are logically unsound and
suspect, though highly appetizing for those who aren't following the
matter closely.

As such, I want to concretely and directly refute them, at the risk of
sounding rude or dismissive, rather than couch the disagreement in softer
language that may suggest some part of me agrees with your position.
Unquestionably, I appreciate you making these arguments, and I hope you'll
continue to engage in the discussion with the same depth of knowledge and
expertise, and I hope you find this email "spirited" rather than
"dismissive".

[Peter Bowen]

On Sun, May 31, 2015 at 3:43 PM, Ryan Sleevi
<ryan-mozde...@sleevi.com> wrote:
> On Sat, May 30, 2015 2:47 pm, Brian Smith wrote:
>> IIRC, in the past, we've seen CAs that lapse in compliance with Mozilla's
>> CA policies and that have claimed they cannot do the work to become
>> compliant again until new legislation has passed to authorize their
>> budget.
>> These episodes are mild examples show that government legislative
>> processes
>> already have a negative impact on government CAs' compliance with
>> browsers' CA policies.
>

> These arguments apply not just to government CAs (that may rely on
> external controls for financing, such as budgets, as you mention) but also
> to small commercial CAs (whose profit margins may be too thin to implement
> controls).
>
> The response to both should be the same - removal.
>
>> More generally, browsers should encourage CAs to agree to name
>> constraints, regardless of the "government" status of the CA.
>
> Of this, I absolutely agree. But I think there's a fine line between
> "encouraging" and "requiring", and how it's presented is key.
>
> Most importantly, I don't believe for a second that constraints justify a
> relaxation of security policy - they're an optional control for the CA to
> opt-in to, as a means of reducing their exposure.
>
> Name constraints can't replace compliance with the Mozilla Security
> Policy, nor should it, in part or in whole.

This thread has spent almost 50 messages discussing government CAs
while barely touching on the vast majority of CAs in the program -
non-government CAs.

What if the focus was much simpler -- what will it take to get strong
uniform enforcement of the Mozilla policy for all CAs? Specifically
ensuring that every CA in the program has disclosed the whole
hierarchy below their program CA down the the point you hit path
length 0 or name constrained CAs and that every disclosed CA is
operating under audited controls that assure that it is meeting the
Mozilla requirements for all certificates, including the Baseline
Requirements for all SSL certificates.

We can discuss Government CAs until we are blue in the face, but the
reality is a poorly run non-government CA is just was much of a threat
to public trust as any government CA.

Thanks,
Peter

[Brian Smith]

On Sun, May 31, 2015 at 12:43 PM, Ryan Sleevi <
ryan-mozde...@sleevi.com> wrote:

> However, that you later bring in the idea that government's may pass laws
>
that make it illegal for browsers to take enforcement is, arguably,
> without merit or evidence. If we accept that "governments may pass laws to
> do X", then we can also logically assume two related statements
>
> 1) Governments may pass laws to compel a CA to issue a certificate to a
> party other than a domain applicant.
> 2) Governments may pass laws to compel browser makers to include
> particular roots as trusted.
>
> The added tinge of uncertainty "In fact, it might already be illegal to do
> in some circumstances" adds to the fear and doubt already sowed here.
>

The practical effects of FUD is really the concern I am raising. The
question I was responding to is basically "How is the threat model
different for Government CAs vs non-Government CAs?" Are browser makers
going to have additional fear, uncertainty, and doubt about taking
enforcement action that would negatively impact governments' essential
services? I think the publicly-available information on the DigiNotar and
ANSSI incidents at least hints that the answer is "yes." Do governments
have an unfair advantage as far as legal action regarding root removal is
concerned, to the point where browser makers should be especially concerned
about legal fights with them? I think it's kind of obvious that the answer
is "yes," though I agree my reasoning is based on speculation.

I agree with you that these concerns also apply in scenerios where
governments have some kind of relationship with a commercial CA.

> After all, why wouldn't we argue that the risk of being sued for tortious
>
interference exists if a browser removes trust, ergo they can't enforce
> their CA policies in any meaningful way?
>

It seems like a safe bet that whoever has the most money is most likely to
win a legal battle. Governments generally have more money than anybody
else. It's better to avoid getting into such legal battles in the first
place.

> More generally, browsers should encourage CAs to agree to name
>
> constraints,
> > regardless of the "government" status of the CA.
>
> Of this, I absolutely agree. But I think there's a fine line between
> "encouraging" and "requiring", and how it's presented is key.
>
> Most importantly, I don't believe for a second that constraints justify a
> relaxation of security policy - they're an optional control for the CA to
> opt-in to, as a means of reducing their exposure.
>
> Name constraints can't replace compliance with the Mozilla Security
> Policy, nor should it, in part or in whole.
>

My hope, which may be too optimistic, is that the USG is content with
issuing itself certificates only for *.gov and *.mil, that they are willing
to be constrained to issuing certificates only to *.gov and *.mil, and that
we can easily help them get to the point where they are **effectively**
constrained to *.gov and *.mil. More generally, I hope that other
government CAs would also do likewise. Obviously there are a lot of cases
where the distinction between government CA and commercial CA is blurred,
but I don't think we should let those less clear situations stop us from
working with governments to improve the situation for situations where the
distinction is clear and meaningful.

> To be clear, my words are strong here because your argument is so
> appealing and so enchanting in a world of post-Snowdonia, in which "trust
> no one" is the phrase du jour, in which the NSA is the secret puppet
> master of all of NIST's activities, and in which vanity crypto sees a
> great resurgence. Your distinctions of government CAs, and their ability,
> while well intentioned, rest on arguments that are logically unsound and
> suspect, though highly appetizing for those who aren't following the
> matter closely.
>

I didn't and don't intend to make that kind of argument. My argument is
simpler: I expect less enforcement action against government CAs than
against commercial CAs by browser makers and I expect more incidents of
non-compliance from government CAs. In the situations where
governments--indeed any CAs--are willing to accept constraints, at least,
we should add the constraints, to reduce the negative consequences of of a
government CA being non-compliant and a browser delaying or forgoing
enforcement action.

I freely admit that my thinking is based on speculative inferences from my
understanding of the publicly-available history of browser CA policy
enforcement. I agree with you that the browser makers shouldn't delay or
forgo enforcement in these situations. In a perfect world we wouldn't need
to consider mitigations for if/when they do.

My specific concern is that, while some proposals for the use of name
constraints aren't good, this discussion is moving toward us not trying
very hard to convince governments to accept very useful and practical name
constraints. Name constraints do have a place in this.

Cheers,
Brian

[Eric Mill]

On Sun, May 31, 2015 at 6:43 PM, Ryan Sleevi <
ryan-mozde...@sleevi.com> wrote:

> On Sat, May 30, 2015 2:47 pm, Brian Smith wrote:

> > The main sticks that browsers have in enforcing their CA policies is the
> > threat of removal. However, such a threat seem completely empty when
> > removal means that essential government services become inaccessible and
> > when the removal would likely lead to, at best, a protracted legal
> battle
> > with the government--perhaps in a secret court.
>
> Ah, but if we're worried about protracted legal battles in secret courts,
> why aren't we worried about protracted legal battles in secret courts for
> inclusion requests? After all, if we were to deny any applicant, who knows
> what secret courts may summon the trust stores!
>

For what it's worth, I agree with Ryan's rebuttal. I definitely believe
government CAs respond to different incentives than commercial CAs, but we
can't go around living in total fear of the government doing any old
irrational or power-grabbing thing.

Governments, including the US government, manage political capital and
resources the same way other institutions do, and we should use real
precedent as a guide, rather than speculated muscle-flexing.

> IIRC, in the past, we've seen CAs that lapse in compliance with Mozilla's
> > CA policies and that have claimed they cannot do the work to become
> > compliant again until new legislation has passed to authorize their
> > budget.
> > These episodes are mild examples show that government legislative
> > processes
> > already have a negative impact on government CAs' compliance with
> > browsers'
> > CA policies.
>

> I agree, this is the strongest argument against government CAs presented
> in this thread, and I wish this, rather than the musings of secret courts
> and "maybe impossibles", was the core of your argument.
>

> These arguments apply not just to government CAs (that may rely on
> external controls for financing, such as budgets, as you mention) but also
> to small commercial CAs (whose profit margins may be too thin to implement
> controls).
>
> The response to both should be the same - removal.
>

Completely agree.

-- Eric

[Gervase Markham]

On 31/05/15 23:43, Ryan Sleevi wrote:
> I agree, this is the strongest argument against government CAs presented
> in this thread, and I wish this, rather than the musings of secret courts
> and "maybe impossibles", was the core of your argument.
>
> These arguments apply not just to government CAs (that may rely on
> external controls for financing, such as budgets, as you mention) but also
> to small commercial CAs (whose profit margins may be too thin to implement
> controls).
>
> The response to both should be the same - removal.

The problem with that is that a government CA removed for this reason
may not care - which speaks to Brian's other points. I do think we have
less ability to control the actions of government CAs with the tools at
our disposal, because they are not subject to market forces, and
removing them hurts only us and our users.

Gerv

[Tom Ritter]

Are https://technet.microsoft.com/en-us/library/cc751157.aspx and
http://aka.ms/auditreqs the MSFT components (previously?) under NDA?

====

Government CAs must restrict server authentication to .gov domains and
may only issues other certificates to the ISO3166 country codes that
the country has sovereign control over (see http://aka.ms/auditreqs
section III for the definition of a “Government CA”).

Government CAs that also operate as commercial, non-profit, or other
publicly-issuing entities must use a different root for all such
certificate issuances (see http://aka.ms/auditreqs section III for the
definition of a “Commercial CA”).

====

Effective July 1, 2015, Government CAs may choose to either obtain the
above WebTrust or ETSI-based audit(s) required of Commercial CAs, or
to use an Equivalent Audit. If a Government CA chooses to obtain a
WebTrust or ETSI-based audit, Microsoft will treat the Government CA
as a Commercial CA. The Government CA can then operate without
limiting the certificates it issues, provided it issues commercial
(including non-profit) certificates from a different root than its
government certificates and it signs a commercial CA contract with
Microsoft.

... more about audits ...

====

A “Government CA” is an entity that is established by the sovereign
government of the jurisdiction in which the entity operates, and whose
existence and operations are directly or indirectly subject to the
control of the sovereign government anywhere in the PKI chain.

A “Commercial CA” is an entity that is legally recognized in the
jurisdiction(s) in which the entity operates (e.g., corporation or
other legal person), that operates on a for-profit basis, and that
issues digital certificates to other CAs or to the general public.

“Certification Authority” or “CA” means an entity that issues digital
certificates in accordance with Local Laws and Regulations.

“Local Laws and Regulations” means the laws and regulations applicable
to a CA under which the CA is authorized to issue digital
certificates, which set forth the applicable policies, rules, and
standards for issuing, maintaining, or revoking certificates,
including audit frequency and procedure.

====

-tom

[Peter Bowen]

On Fri, Jun 12, 2015 at 3:46 PM, Tom Ritter <t...@ritter.vg> wrote:
> Are https://technet.microsoft.com/en-us/library/cc751157.aspx and
> http://aka.ms/auditreqs the MSFT components (previously?) under NDA?

The published requirements are not under NDA. Microsoft released a
draft version under NDA for feedback.