Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

I would like to thank everyone for your constructive input on this topic.
At the outset I stated a desire to ‘establish some objective criteria that
can be measured and applied fairly’. While some suggestions have been made,
no clear set of criteria has emerged. At the same time, we’ve heard the
argument that our time would be better spent on raising the bar for all CAs
in the program, regardless of their subjective value to typical users of
our products.

Some thought was also given to applying unique technical criteria to new
CAs, such as limiting certificate lifetime to 90 days or requiring ACME
support. It was pointed out, however, that this favors incumbents and
doesn’t drive improvement in the overall ecosystem.

The conclusion from this discussion is that we will not attempt to restrict
organizations from participating in the Mozilla CA program based on a
judgement of their value to our users. We will continue to require
applicants to demonstrate compliance with our policies, and reserve the
right to deny membership to any CA at our discretion, e.g. because they
have a documented pattern of misbehavior or we believe they intend to
violate our policies.

Here is a proposed update to the Mozilla Root Store Policy reflecting this
decision:

https://github.com/mozilla/pkipolicy/compare/master...inclusion-criteria?quick_pull=1

As always, comments are welcome. I intend to begin a discussion of the next
version of the policy soon and will plan to include this change in it.


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

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Fri, Jan 19, 2018 at 3:04 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 18/01/18 14:24, Ryan Sleevi wrote:
> > Isn't this effectively the VISA situation? When were their first audits -
> > late 2016 / early 2017?
>
> I'm not certain; I'll ask Kathleen.
>
> Visa's first BR audit was a PITRA dated 31 March 2016.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria (organizations)

[Jakob Bohm via dev-security-policy]

On 22/01/2018 10:47, Gervase Markham wrote:

On 19/01/18 13:20, Jakob Bohm wrote:

My suggestions are only meant to inspire formal rules written / chosen
by module leaders such as you.


But the entire point of this discussion is that we are pointing out it's
hard to make such rules in the way you have just made them without being
arbitrary, and arbitrariness is something we want to avoid. So giving us
an example arbitrary ruleset is not really moving the discussion forward
much.



Ok, I was replying mostly to your assessment that this would be subject
to approval of each CA by /me/.

For the too-big-to-ignore case, a formal no-human-judgement required
criteria would be something like the issue affecting at least a certain
percentage of Internet traffic of the relevant protocol (such as
https+imaps+pop3s+smtps and the "STARTTLS" equivalents for TLS uses in
Mozilla code, or e-mail traffic for S/MIME), not including internal
traffic by the CA owner and their closest partners.

For the vertical CA case, a formal criteria would be either prior
inclusion in the Mozilla root program or acceptance from two other root
programs in the CAB/F.

Though in both cases, I think that human judgement by the relevant
Mozilla people after public discussion would be a more accurate test,
since both are meant to be exceptional cases, not the norm.  As an
actual policy decision would be involved, the category approval (as
opposed to the technical approval) would need more than the usual 3 week
discussion.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria (organizations)

[Gervase Markham via dev-security-policy]

On 19/01/18 13:20, Jakob Bohm wrote:
> My suggestions are only meant to inspire formal rules written / chosen
> by module leaders such as you.

But the entire point of this discussion is that we are pointing out it's
hard to make such rules in the way you have just made them without being
arbitrary, and arbitrariness is something we want to avoid. So giving us
an example arbitrary ruleset is not really moving the discussion forward
much.

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

Re: Updating Root Inclusion Criteria (organizations)

[Jakob Bohm via dev-security-policy]

On 19/01/2018 11:09, Gervase Markham wrote:

On 19/01/18 01:05, Jakob Bohm wrote:

On 18/01/2018 11:01, Gervase Markham wrote:

On 17/01/18 19:49, Jakob Bohm wrote:

3. Major vertical CAs for high value business categories that issue
    publicly trusted certificates at better than EV level integrity.  For


How do you define "major"? And "high value business category"?


Major would be the biggest 1 to 3 of their kind, ignoring any covering
only a small fraction of the relevant web site/e-mail population even if
in the top 3.  Also any not doing this globally is not major.


I guess my question was ambiguous. Clearly it's very easy to come up
with arbitrary definitions for these things, but what's the rationale?
Why 1-3? Why not 1-8?



My suggestions are only meant to inspire formal rules written / chosen
by module leaders such as you.

Point of this is to avoid a bloated situation with 50+ financial
industry specific CAs and 50+ medical profession CAs etc.  This would
generally be for single worldwide organizations, with an option to
handle some kind of alliance schism in the industry, e.g. between those
who align with EuroCard/Visa/Mastercard (EVM) and another global group
that explicitly wants as little to do with the first group as possible.


High value business category would be a category where web users have an
extremely high need for genuineness.  Banks/central payment systems
would be the canonical example, with the VISA CA/SET combination as a
possible historic example (noting that it looks like they don't
currently qualify even if they did in the past).


You've just shifted the definitional problem to the words "extremely
high need for genuineness".

Proving examples of what you personally mean by these terms is not
sufficient to make a definition, unless the Mozilla policy becomes
"whatever Jakob Bohm decides".

Gerv




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria (organizations)

[Gervase Markham via dev-security-policy]

On 19/01/18 01:05, Jakob Bohm wrote:
> On 18/01/2018 11:01, Gervase Markham wrote:
>> On 17/01/18 19:49, Jakob Bohm wrote:
>>> 3. Major vertical CAs for high value business categories that issue
>>>    publicly trusted certificates at better than EV level integrity.  For
>>
>> How do you define "major"? And "high value business category"?
> 
> Major would be the biggest 1 to 3 of their kind, ignoring any covering
> only a small fraction of the relevant web site/e-mail population even if
> in the top 3.  Also any not doing this globally is not major.

I guess my question was ambiguous. Clearly it's very easy to come up
with arbitrary definitions for these things, but what's the rationale?
Why 1-3? Why not 1-8?

> High value business category would be a category where web users have an
> extremely high need for genuineness.  Banks/central payment systems
> would be the canonical example, with the VISA CA/SET combination as a
> possible historic example (noting that it looks like they don't
> currently qualify even if they did in the past).

You've just shifted the definitional problem to the words "extremely
high need for genuineness".

Proving examples of what you personally mean by these terms is not
sufficient to make a definition, unless the Mozilla policy becomes
"whatever Jakob Bohm decides".

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 18/01/18 14:24, Ryan Sleevi wrote:
> Or, conversely, that we cannot discuss inclusion policies in isolation from
> discussion root policies - we cannot simultaneously work to strengthen
> inclusion without acknowledging the elephant in the room of the extant CAs.

We aren't necessarily "strengthening" inclusion, in the sense of making
it harder to get in - the outcome of the discussion could be a loosening.

If we come up with new inclusion criteria and some existing CAs do not
meet them, we would need to have a separate discussion to decide what to
do, with the main options being grandfathering them in, restricting them
in some way, or removing them.

> Isn't this effectively the VISA situation? When were their first audits -
> late 2016 / early 2017?

I'm not certain; I'll ask Kathleen.

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

Re: Updating Root Inclusion Criteria (organizations)

[Jakob Bohm via dev-security-policy]

On 18/01/2018 11:01, Gervase Markham wrote:

On 17/01/18 19:49, Jakob Bohm wrote:

3. Major vertical CAs for high value business categories that issue
   publicly trusted certificates at better than EV level integrity.  For


How do you define "major"? And "high value business category"?



Major would be the biggest 1 to 3 of their kind, ignoring any covering
only a small fraction of the relevant web site/e-mail population even if
in the top 3.  Also any not doing this globally is not major.

High value business category would be a category where web users have an
extremely high need for genuineness.  Banks/central payment systems
would be the canonical example, with the VISA CA/SET combination as a
possible historic example (noting that it looks like they don't
currently qualify even if they did in the past).

Another example could be if a global medical organization (WHO or ICRC
or some NGO) were to issue certificates for secure communication with
doctors anywhere people might live or travel, using their specific
knowledge and resources to ensure that only actual doctors could get
certificates.  Here the high value would be the users life and physical
health, not money.

On the other hand, similar certificate services for e-commerce sites or
drugstores would probably not qualify as sufficiently high value to
entertain a category specific root inclusion.

Similarly a CA that only vouches for Banks in the US and Britain would
not qualify as Major, even if no larger banks-only CA exists.


4. Selected company CAs for a handful of too-bit-to-ignore companies
   that refuse to use a true public CA.


So you think Mozilla's policy should include formal acknowledgement that
some companies are too big to ignore?

How do you decide which companies are in this category?



This would very much be a subjective assessment. And would only be on a
provisional basis.  The key criteria would be how much normal users
would be hurt by that CA not being trusted.  Another key criteria would
be if they were already included (Google and Amazon).

For example, if users can't access the most popular search engine
(Google), cannot access key services for their OS (Microsoft in some
cases), or cannot access sites hosted by one of the top hosting
providers (Amazon) that would be a reason to include that root in
preference to forcing users to switch to a browser that does (Chrome,
IE, some Amazon browser).

As most large companies will have a hard time creating this situation
from scratch (because they would not be initially trusted by browsers
they can't get away with creating a situation where adding them to
browsers becomes a necessity), this will be mostly a transitional /
grandfathering category.

Note that with my more strict definition of a global public CA, cloud
providers (or other providers) that only vouch for their own customers
don't qualify in that category, since they are not open to all comers.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Alex Gaynor via dev-security-policy]

Self-assessment is insufficient :-)

That's why we require audits, review issued certificates for technical
violations, and attempt to empower domain owners to identify misissuance.

As we move to a world with greater participation of public CAs in
Certificate Transparency (hopefully 100% eventually), we can increasingly
rely on objective measures to judge across CAs.

Alex


On Thu, Jan 18, 2018 at 4:23 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should
> focus less on the questions of whether a CA
> > is "appropriate" or "deserving" of participation in the Mozilla Root
> > Program, and more on whether they are willing and able to fulfill the
> > expectations of them as a steward of global trust on the internet.
>
> If you ask any applicant "are you willing and able to fulfil what is
> expected of you as a steward of global trust on the Internet?", and they
> know they have to say "Yes" to get in, they will say "Yes". So is the
> upshot of your position that anyone who wants to apply can get in?
>
> Gerv
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Ryan Sleevi via dev-security-policy]

On Thu, Jan 18, 2018 at 9:33 AM, Ryan Sleevi  wrote:

>
>
> On Thu, Jan 18, 2018 at 9:11 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> On 18/01/18 13:55, Ryan Sleevi wrote:
>> > Was it your intent to redefine the problem like that? If not, do you
>> have
>> > those concerns about the objective measures, or is your goal to find
>> > objective measures which you subjectively believe to be 'fair'? For
>> > example, an objective measure would be "Paid for a 2-week vacation for
>> > Gervase Markham and family every year to a location of their choosing",
>> but
>> > I suspect that you might argue it's subjectively 'not fair'?
>>
>> If every CA had to do it, it would both be an objective measure and
>> subjectively fair. (Although one could argue it was unfair if I asked
>> one CA to send us to Bogor Regis and another to send us to the Maldives.
>> it would also mean a maximum of 26 CAs in the program at one time, and
>> in the past we have decided against a hard numerical limit.)
>>
>> I would like to find a set of objective measures which the group
>> considers as a whole to be "fair", in that the objective measures do not
>> use criteria which are irrelevant to operating as a CA (such as buying
>> my family a holiday). This may not be possible, of course - we will see
>> - but that doesn't stop me wanting it.
>
>
> To be honest, I think this highlights one of the challenges - namely, the
> lack of a numerical limit of CAs.
>
> Absent a numerical limit, there will always be the risk that CAs that
> "shouldn't" be in are accepted. One way to mitigate that is to try to raise
> the floor - but with the risk of rejecting CAs that "should" be in, for
> some value of "should" and "shouldn't" (both in terms of past failures and
> prediction of future failures).
>
> Another way to attempt to address that is to work to mitigate the damage
> of those that 'shouldn't' be in - both to the ecosystem and users - and
> inevitably, a key part of that would include some notion of agility. That
> agility extends to both software updates and to ecosystem updates.
>
> For example, an objective criteria might be that every new CA supports the
> ACME protocol with some minimum prescribed set of interoperable validation
> methods. In that model, all new CAs are afforded the same 'advantages' (or,
> from the CA perspective, 'disadvantages') of having an interoperable
> system, while addressing the ecosystem need by allowing ACME supporting
> clients to rapidly transition to other ACME supporting CAs in the event
> that the CA is determined they "shouldn't" be in (because they MITMed, for
> example)
>
> Similarly, requiring all CAs disclose their trusted certificates via
> Certificate Transparency offers an objective measure (modulo the nuance of
> defining what constitutes 'disclosure'), thus reducing the risk involved
> with scrying the various business purposes - and potentially providing
> incentives for those that /could/ use private PKIs to do so if they have
> concerns with such disclosure.
>
> Alternatively, all new CAs could be required to issue certificates for, at
> most, 90 days. This further helps reduce the risk of 'getting it wrong'.
>
> These are all objective measures that avoid the attempt to divine purpose
> and intent, and instead provide objective criteria based on the underlying
> set of concerns that necessitate the worry about intent. However, as you
> can also see, this inherently favors incumbents - so unless we treat an
> inclusion policy equivalent to an acceptance policy, it doesn't
> meaningfully improve the overall set of trust.
>
> This is why I think that some of the current proposals - such as scope or
> size - are problematic, as they are attempts to try to mitigate through
> policy the set of concerns that we could alternatively (and equitably)
> mitigate through technology, and with a greater benefit to the overall
> ecosystem :)
>

Apologies, accidentally tabbed to the send.

I was going to highlight the contrast of those proposals with an
alternative proposal. Limit the number of trusted root CAs to some
arbitrary number (say, 26). At that point, your criteria for who to include
becomes "Whomever is better than one of the existing 26, on whatever
dimensions the community values". At that point, you're no longer trying to
subjectively determine if the new CA rises past some abstract notion of the
minimum - you've instead got 26 concrete instances of some measure that you
can compare against, and see whether the new CA topples any of the
incumbents.

In the absence of having a strict limit, however, this isn't possible - and
so I think the answer needs to be "more agility" rather than "more policy".
Alternatively, if we (the community) want to limit to some subset, then we
can and should talk about the dimensions we value, and how to pit CAs
against eachother in a "Security and Policy Thunderdome" - where the most
secure CAs, the 

RE: Updating Root Inclusion Criteria

[Tim Hollebeek via dev-security-policy]

> I think this is a vote for the status quo, in which we have been accepting 
> CAs that don't meet the guidance provided under 'who may apply'

 

Perhaps slightly less strong than that.  I think Mozilla should be willing to 
consider accepting them if there is a compelling reason to do so.  “Why aren’t 
you running/participating in a private PKI?” should always be the first 
question, with the recognition that there are valid answers to that question.

 

-Tim

 



smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

Hi Ryan,

On 18/01/18 13:55, Ryan Sleevi wrote:
> I do want to point out that you are substantially changing the goals from
> what Wayne posited. That is, you have moved the goalpost from being
> 'objective' to being what is 'fair', and 'fair' will inherently be a
> subjective evaluation.

One of my goals in this discussion is to record some of the thoughts I
had on the topic, of which this is one. Those thoughts are far from
unchallengeable - as you have recognised, since you are challenging one
of them :-)

> Was it your intent to redefine the problem like that? If not, do you have
> those concerns about the objective measures, or is your goal to find
> objective measures which you subjectively believe to be 'fair'? For
> example, an objective measure would be "Paid for a 2-week vacation for
> Gervase Markham and family every year to a location of their choosing", but
> I suspect that you might argue it's subjectively 'not fair'?

If every CA had to do it, it would both be an objective measure and
subjectively fair. (Although one could argue it was unfair if I asked
one CA to send us to Bogor Regis and another to send us to the Maldives.
it would also mean a maximum of 26 CAs in the program at one time, and
in the past we have decided against a hard numerical limit.)

I would like to find a set of objective measures which the group
considers as a whole to be "fair", in that the objective measures do not
use criteria which are irrelevant to operating as a CA (such as buying
my family a holiday). This may not be possible, of course - we will see
- but that doesn't stop me wanting it.

Gerv

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

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 18, 2018, at 08:53, Ryan Sleevi  wrote:
> 
> If Mozilla was committed to an equitable set of criteria for both incumbents 
> and newcomers, then one natural consequence of this is that all incumbents 
> should be required to rotate their keys to new roots, created under audit 
> criteria acceptable to Mozilla, and to transition issuance to these roots. 
> This is, for what it's worth, notably similar to the consensus proposal 
> regarding Symantec and the Managed Partner Infrastructure, and serves to 
> mitigate a broad swath of risks.
> 
> So I don't see any argument suggesting it *shouldn't* apply to existing roots 
> - if anything, such a policy requirement would go substantially to both 
> reduce the benefits afforded to incumbents through entropy, and to ensure 
> that Mozilla's users are adequately protected as the emerging security and 
> threat landscape changes. It does not prevent devices which cannot update (as 
> you can cross-certify), but ensures that the security critical, 
> responsibly-developed applications that do update can ensure their users are 
> protected. 

Yes, this is what I was thinking when I wrote the initial email. There are 
massive security benefits to Mozilla’s users if all CAs roll their roots and 
are re-evaluated after implementing an updated inclusion policy and ongoing 
requirements based on the goals that Alex described.

I don’t think the conversations are separate. They are necessarily the same. It 
doesn’t make sense to update the inclusion policies and not look at roots that 
are already included unless you want to continue favoring incumbents.

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 18/01/18 13:53, Ryan Sleevi wrote:
> But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at
> the detriment to both user security and the ecosystem. If your goal is for
> policies that do not favor incumbents, then it seems a significantly
> different discussion should happen - and proposals such as Jonathan's
> inherently provide a way to normalize that field.

If Jonathan's proposal were applied to all CAs, it might well reduce
incumbent advantage. But that would be a different discussion from
inclusion criteria. If it were applied only to new CAs, it would be
relevant to the current discussion - but then it would entrench
incumbent advantage.

> A prime example, recently highlighted in ongoing CA inclusion discussions,
> is whether or not a CA must have an unbroken series of audits since their
> key was created (the PITRA). 

Yes. It seems that we have come to the position that it does not
necessarily have to. But I would raise an eyebrow at a root that had
been operating for 10 years and had only got its first set of audits
last week.

> Obviously, during the introduction of the
> Baseline Requirements, this was not the case for any incumbents - and
> Mozilla further granted an effective 3 years for incumbents beyond the BRs
> effective date to come up to date, while simultaneously examining new CAs
> against the modernized criteria. 

I'm not sure it was that long, and even if it was, I think this
criticism is a little harsh given that we have been at the forefront of
giving the BRs any teeth at all.

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

Re: Updating Root Inclusion Criteria

[Ryan Sleevi via dev-security-policy]

On Thu, Jan 18, 2018 at 4:59 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/01/18 19:14, Ryan Hurst wrote:
> > Since Google's PKI was mentioned as an example, I can publicly state
> > that the plan is for Google to utilize the Google Trust Services
> > infrastructure to satisfy its SSL certificate needs. While I can not
> > announce specific product roadmaps I can say that this includes the
> > issuance of certificates for Google offerings involving hosting of
> > products and services for customers.
>
> This is an interesting situation because it points to an interesting
> ramification of a requirement which is anything like "issues certs to
> the public".
>
> We can compare large companies who happen to be in the cloud hosting
> business (e.g. Google, Amazon, Microsoft) with those that are not. The
> former category can pass a "issuing certs to the public" test and so
> qualify for inclusion, and can then use that same infra to issue their
> internal certs, or certs for their own public-facing domains and
> hostnames. A large company which happens not to be in the cloud hosting
> business cannot pass that test, and so has to use a 3rd party CA for
> their cert requirements.
>
> One could argue that deciding whether a large tech company gets the
> convenience of a self-hosted root based on whether they provide a
> particular service is not very fair.


Gerv,

I do want to point out that you are substantially changing the goals from
what Wayne posited. That is, you have moved the goalpost from being
'objective' to being what is 'fair', and 'fair' will inherently be a
subjective evaluation.

Was it your intent to redefine the problem like that? If not, do you have
those concerns about the objective measures, or is your goal to find
objective measures which you subjectively believe to be 'fair'? For
example, an objective measure would be "Paid for a 2-week vacation for
Gervase Markham and family every year to a location of their choosing", but
I suspect that you might argue it's subjectively 'not fair'?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Ryan Sleevi via dev-security-policy]

On Thu, Jan 18, 2018 at 4:24 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/01/18 15:13, Jonathan Rudenberg wrote:
> > I like this concept a lot. Some concrete ideas in this space:
> >
> > - Limit the validity period of root certificates to a few years, so that
> the criteria can be re-evaluated, updated, and re-applied on a rolling
> basis.
>
> Are you saying we should do this for new entrants only? If so, surely
> that would give existing CAs a significant competitive advantage? Or, if
> not, what is the relevance of your point to the question under
> consideration?
>

But Gerv, Mozilla's policies already unequally favor the incumbent CAs, at
the detriment to both user security and the ecosystem. If your goal is for
policies that do not favor incumbents, then it seems a significantly
different discussion should happen - and proposals such as Jonathan's
inherently provide a way to normalize that field.

A prime example, recently highlighted in ongoing CA inclusion discussions,
is whether or not a CA must have an unbroken series of audits since their
key was created (the PITRA). Obviously, during the introduction of the
Baseline Requirements, this was not the case for any incumbents - and
Mozilla further granted an effective 3 years for incumbents beyond the BRs
effective date to come up to date, while simultaneously examining new CAs
against the modernized criteria. This allows for substantial undetectable,
unreported misissuance (which, for what it's worth, we have seen in the
processing of root inclusion requests) for those that are 'grandfathered'
in.

If Mozilla was committed to an equitable set of criteria for both
incumbents and newcomers, then one natural consequence of this is that all
incumbents should be required to rotate their keys to new roots, created
under audit criteria acceptable to Mozilla, and to transition issuance to
these roots. This is, for what it's worth, notably similar to the consensus
proposal regarding Symantec and the Managed Partner Infrastructure, and
serves to mitigate a broad swath of risks.

So I don't see any argument suggesting it *shouldn't* apply to existing
roots - if anything, such a policy requirement would go substantially to
both reduce the benefits afforded to incumbents through entropy, and to
ensure that Mozilla's users are adequately protected as the emerging
security and threat landscape changes. It does not prevent devices which
cannot update (as you can cross-certify), but ensures that the security
critical, responsibly-developed applications that do update can ensure
their users are protected.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria (organizations)

[Gervase Markham via dev-security-policy]

On 17/01/18 19:49, Jakob Bohm wrote:
> 3. Major vertical CAs for high value business categories that issue
>   publicly trusted certificates at better than EV level integrity.  For

How do you define "major"? And "high value business category"?

> 4. Selected company CAs for a handful of too-bit-to-ignore companies
>   that refuse to use a true public CA.

So you think Mozilla's policy should include formal acknowledgement that
some companies are too big to ignore?

How do you decide which companies are in this category?

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 19:14, Ryan Hurst wrote:
> Since Google's PKI was mentioned as an example, I can publicly state
> that the plan is for Google to utilize the Google Trust Services
> infrastructure to satisfy its SSL certificate needs. While I can not
> announce specific product roadmaps I can say that this includes the
> issuance of certificates for Google offerings involving hosting of
> products and services for customers.

This is an interesting situation because it points to an interesting
ramification of a requirement which is anything like "issues certs to
the public".

We can compare large companies who happen to be in the cloud hosting
business (e.g. Google, Amazon, Microsoft) with those that are not. The
former category can pass a "issuing certs to the public" test and so
qualify for inclusion, and can then use that same infra to issue their
internal certs, or certs for their own public-facing domains and
hostnames. A large company which happens not to be in the cloud hosting
business cannot pass that test, and so has to use a 3rd party CA for
their cert requirements.

One could argue that deciding whether a large tech company gets the
convenience of a self-hosted root based on whether they provide a
particular service is not very fair.

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 15:41, Peter Bowen wrote:
> In the interest of transparency, I would like to add one more example
> to your list:
> 
> * Amazon Trust Services is a current program member.  Amazon applied
> independently but then subsequently bought a root from Go Daddy
> (obvious disclosure: Wayne was VP at Go Daddy at the time).  So far
> there is no public path to bring Amazon a public key/CSR you generate
> on you own server and have Amazon issue a certificate containing that
> public key.  The primary path to getting a certificate issued by
> Amazon is to use AWS Certificate Manager.  That being said, we have
> issued certificates to hundreds of thousands of domains and Mozilla
> telemetry data shows they are being widely used by users of Mozilla
> software products.

IOW, you can't bring your CSR to Amazon and get a certificate, but you
can bring your _domain_ to Amazon and get a certificate.

Gerv

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 15:13, Jonathan Rudenberg wrote:
> I like this concept a lot. Some concrete ideas in this space:
> 
> - Limit the validity period of root certificates to a few years, so that the 
> criteria can be re-evaluated, updated, and re-applied on a rolling basis.

Are you saying we should do this for new entrants only? If so, surely
that would give existing CAs a significant competitive advantage? Or, if
not, what is the relevance of your point to the question under
consideration?

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

Re: Updating Root Inclusion Criteria

[Gervase Markham via dev-security-policy]

On 17/01/18 14:54, Alex Gaynor wrote:> In summary, I think we should
focus less on the questions of whether a CA
> is "appropriate" or "deserving" of participation in the Mozilla Root
> Program, and more on whether they are willing and able to fulfill the
> expectations of them as a steward of global trust on the internet. 

If you ask any applicant "are you willing and able to fulfil what is
expected of you as a steward of global trust on the Internet?", and they
know they have to say "Yes" to get in, they will say "Yes". So is the
upshot of your position that anyone who wants to apply can get in?

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

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Wed, Jan 17, 2018 at 3:32 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 17/01/2018 23:03, Jonathan Rudenberg wrote:
>
> You seem to be stuck inside some kind of ivory tower world where
> computers are king and everything is done by robots.
>
> This is an interesting debate, but I don't think it's getting us any
closer to answering the question at hand.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Wed, Jan 17, 2018 at 7:54 AM, Alex Gaynor  wrote:

> Hi Wayne,
>
> After some time thinking about it, I struggled to articulate what the
> right rules for inclusion were.
>
> Yes, that is the challenge.

So I decided to approach this from a different perspective: which is that I
> think we should design our other policies and requirements for CAs around
> what we'd expect for organizations operating towards a goal of securing the
> Internet as a global public resource.
>
> Towards that goal we should continue to focus on things like transparency
> (how this list is run, visibility of audit statements, certificate
> transparency) and driving technical improvements to the WebPKI (shorter
> certificate lifespans, fewer allowances for non-compliant certificates or
> use of deprecated formats and cryptography). If organizations wish to hold
> themselves to these (presumably higher) standards for what could equally
> well be a private PKI, I don't see that as a problem. On the flip side, we
> should not delay improvements because CAs with limited impact on the public
> internet struggle with compliance.
>
> Can we separate the ongoing work we need to do to improve the ecosystem
from a decision on root inclusion criteria? Or are you saying that we need
to set new requirements like these as a condition for changing the root
inclusion criteria?

In summary, I think we should focus less on the questions of whether a CA
> is "appropriate" or "deserving" of participation in the Mozilla Root
> Program, and more on whether they are willing and able to fulfill the
> expectations of them as a steward of global trust on the internet. This has
> the nice benefit of aligning well with Mozilla's mission to ensure the
> internet is a global public resource, open and accessible to all.
>
> With this approach we would welcome any CA that can meet the program's
requirements, regardless of the intended use of their certificates.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

On Wed, Jan 17, 2018 at 7:46 AM, Tim Hollebeek 
wrote:

> I support "encouraging" those who are currently using the public web PKI
> for
> internal uses to move to their own private PKIs.  The current situation is
> an
> artifact of the old notion that there should be a global "One CA List to
> Rule
> Them All" owned by the operating system, and everyone should use that.
> That notion is a bit antiquated, in my mind.  Applications and components
> that need a trust list really need to carefully select (or create!) an
> appropriate
> one instead of just grabbing the most convenient one.
>
> I think this is a vote for the status quo, in which we have been accepting
CAs that don't meet the guidance provided under 'who may apply'

I'm familiar with a few efforts in the financial space to transition away
> from
> browser trust lists for non-browser TLS, but as you can imagine, that's
> not a
> trivial effort and will take some time.  My only request would be that if
> the
> rules are going to change, that large companies and entire industries that
> may be affected be given enough notice to be able to come up with
> reasonable transition plans.
>
> Point taken. My immediate concern is for new applications, not with
existing CAs.

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

Re: Updating Root Inclusion Criteria (organizations)

[Jakob Bohm via dev-security-policy]

On 17/01/2018 22:51, Peter Bowen wrote:

On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policy
 wrote:

4. Selected company CAs for a handful of too-bit-to-ignore companies
   that refuse to use a true public CA.  This would currently probably
   be Microsoft, Amazon and Google.  These should be admitted only on
   a temporary basis to pressure such companies to use generally trusted
   independent CAs.


Jakob,

Can you please explain how you define "true public CA"?  How long
should new CAs have to meet this criteria?   I don't like carve outs
for "too-big-to-ignore".



True public CA = #1 to #3 in my list. For the 3 organizations mentioned,
this would probably be #1.

For #1 they would need to offer certificates to anyone willing to pay
the usual fee (possibly 0), passing validation and not barred by special
circumstances (Government embargoes, non-functional whois servers, known
cybercriminals etc.).  They would need to promise doing this as long as
they are fully operational, but obviously not during spin-up and
stand-down periods (where they would typically only sign internal
certificates, test sites etc.)

For #2 and #3 they would need to offer certificates to most entities
within their scope.

So Let's encrypt, Digicert, Globalsign etc. are true global CAs. (#1)

CNNIC, Deutche Telekom etc. are national CAs (#2)

VISA, ICAO etc. might operate vertical major CAs (#3)

The carve outs are there because as web users we have difficulty
avoiding websites using those specific organizations, thus needing to
trust them subject to as many limitations as the browser can practically
enforce.  The suggested time limits are there to help sunsetting the
carve-outs.



Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Jakob Bohm via dev-security-policy]

On 17/01/2018 23:03, Jonathan Rudenberg wrote:



On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy 
 wrote:

On 17/01/2018 21:14, Jonathan Rudenberg wrote:

On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy 
 wrote:

On 17/01/2018 16:13, Jonathan Rudenberg wrote:

On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
 wrote:

Hi Wayne,

After some time thinking about it, I struggled to articulate what the right
rules for inclusion were.

So I decided to approach this from a different perspective: which is that I
think we should design our other policies and requirements for CAs around
what we'd expect for organizations operating towards a goal of securing the
Internet as a global public resource.

Towards that goal we should continue to focus on things like transparency
(how this list is run, visibility of audit statements, certificate
transparency) and driving technical improvements to the WebPKI (shorter
certificate lifespans, fewer allowances for non-compliant certificates or
use of deprecated formats and cryptography). If organizations wish to hold
themselves to these (presumably higher) standards for what could equally
well be a private PKI, I don't see that as a problem. On the flip side, we
should not delay improvements because CAs with limited impact on the public
internet struggle with compliance.


I would say, that to limit the danger that such an essentially unused CA 
operator turns rogue, only CAs that provide certificates for public trust 
should be admitted in the future, more on that in another post.


I like this concept a lot. Some concrete ideas in this space:
- Limit the validity period of root certificates to a few years, so that the 
criteria can be re-evaluated, updated, and re-applied on a rolling basis.


This may be fine for TLS root CAs that are distributed in frequently
updated browsers (such as Firefox and Chrome).

It is absolutely fatal for roots that are also used for any of the
following:

- Distributed in browsers that don't get frequent updates (due to
  problems in that distribution channel), such as many browsers
  distributed in the firmware of mobile devices, TVs etc.

Distributing WebPKI roots in infrequently updated software is a bad idea and 
leads to disasters like the issues around the SHA-1 deprecation.


But what should then be done when that infrequently updated software is
in fact a general end user web browser (as opposed to the previously
discussed special cases of certain payment terminals)?  Remove TLS
support?  Trust all certificates without meaningful checks?  Pop up
certificate warnings for every valid certificate?


Don’t ship browsers that don’t get updates. The surface area is huge and there 
are many security bugs that are fixed regularly. Shipping browsers in a way 
that prevents them from being updated frequently is deeply irresponsible.



Unfortunately, people do that, in the billions.  Nothing we can do to
stop them.


The way the SHA-1 deprecation was done, with no widely implemented way
for TLS clients to signal their ability to support stronger algorithms,
has in fact created a situation where unreliable hacks are needed to
support older mobile browsers, including feeding unencrypted pages to
some of them.  The public stigma attached to this makes this something
that is rarely discussed in public, but is quietly done by webmasters that need 
to communicate with those systems.


This is false. TLS clients absolutely signal their ability to support specific 
algorithms, and there are several implementations of serving SHA-1 certificates 
to insecure clients.



Interesting that their is no published support or instructions in the
usual guides on TLS configuration best practices, nor much accommodation
by this root program for SHA-1-forever CAs.




- Used to (indirectly) sign items of long validity, such as e-mails
  (Thunderbird!), timestamps and software.

I don’t know much about S/MIME, but this doesn’t sound right. Of course 
certificates used to sign emails expire! That’s obviously expected, and I’d 
hope that the validation takes that into account.


The mechanisms vary by recipient software.  But a typical technique
combines a known-unmodified-since date (such as the date of reception or
a date certified by a cryptographic timestamps) to compare the relevant
validity dates in certificates against.

This obviously needs continued trust in the root certificates
that were relevant at that earlier time, including the ability
if the corresponding CAs to publish and update revocation
information after the end certificates expiry date.  (Consider the
case where an e-mail sender's personal certificate was
compromised 1 day before expiry, but that fact was not reported
to the CA until later, thus requiring the CA to publish changed
revocation information for an already expired certificate in

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 17, 2018, at 16:24, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 17/01/2018 21:14, Jonathan Rudenberg wrote:
>>> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy 
>>>  wrote:
>>> 
>>> On 17/01/2018 16:13, Jonathan Rudenberg wrote:
> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Hi Wayne,
> 
> After some time thinking about it, I struggled to articulate what the 
> right
> rules for inclusion were.
> 
> So I decided to approach this from a different perspective: which is that 
> I
> think we should design our other policies and requirements for CAs around
> what we'd expect for organizations operating towards a goal of securing 
> the
> Internet as a global public resource.
> 
> Towards that goal we should continue to focus on things like transparency
> (how this list is run, visibility of audit statements, certificate
> transparency) and driving technical improvements to the WebPKI (shorter
> certificate lifespans, fewer allowances for non-compliant certificates or
> use of deprecated formats and cryptography). If organizations wish to hold
> themselves to these (presumably higher) standards for what could equally
> well be a private PKI, I don't see that as a problem. On the flip side, we
> should not delay improvements because CAs with limited impact on the 
> public
> internet struggle with compliance.
>>> 
>>> I would say, that to limit the danger that such an essentially unused CA 
>>> operator turns rogue, only CAs that provide certificates for public trust 
>>> should be admitted in the future, more on that in another post.
>>> 
 I like this concept a lot. Some concrete ideas in this space:
 - Limit the validity period of root certificates to a few years, so that 
 the criteria can be re-evaluated, updated, and re-applied on a rolling 
 basis.
>>> 
>>> This may be fine for TLS root CAs that are distributed in frequently
>>> updated browsers (such as Firefox and Chrome).
>>> 
>>> It is absolutely fatal for roots that are also used for any of the
>>> following:
>>> 
>>> - Distributed in browsers that don't get frequent updates (due to
>>>  problems in that distribution channel), such as many browsers
>>>  distributed in the firmware of mobile devices, TVs etc.
>> Distributing WebPKI roots in infrequently updated software is a bad idea and 
>> leads to disasters like the issues around the SHA-1 deprecation.
> 
> But what should then be done when that infrequently updated software is
> in fact a general end user web browser (as opposed to the previously
> discussed special cases of certain payment terminals)?  Remove TLS
> support?  Trust all certificates without meaningful checks?  Pop up
> certificate warnings for every valid certificate?

Don’t ship browsers that don’t get updates. The surface area is huge and there 
are many security bugs that are fixed regularly. Shipping browsers in a way 
that prevents them from being updated frequently is deeply irresponsible.

> The way the SHA-1 deprecation was done, with no widely implemented way
> for TLS clients to signal their ability to support stronger algorithms,
> has in fact created a situation where unreliable hacks are needed to
> support older mobile browsers, including feeding unencrypted pages to
> some of them.  The public stigma attached to this makes this something
> that is rarely discussed in public, but is quietly done by webmasters that 
> need to communicate with those systems.

This is false. TLS clients absolutely signal their ability to support specific 
algorithms, and there are several implementations of serving SHA-1 certificates 
to insecure clients.

> 
>>> - Used to (indirectly) sign items of long validity, such as e-mails
>>>  (Thunderbird!), timestamps and software.
>> I don’t know much about S/MIME, but this doesn’t sound right. Of course 
>> certificates used to sign emails expire! That’s obviously expected, and I’d 
>> hope that the validation takes that into account.
> 
> The mechanisms vary by recipient software.  But a typical technique
> combines a known-unmodified-since date (such as the date of reception or
> a date certified by a cryptographic timestamps) to compare the relevant
> validity dates in certificates against.
> 
> This obviously needs continued trust in the root certificates
> that were relevant at that earlier time, including the ability
> if the corresponding CAs to publish and update revocation
> information after the end certificates expiry date.  (Consider the
> case where an e-mail sender's personal certificate was
> compromised 1 day before expiry, but that fact was not reported
> to the CA until later, thus requiring the CA to publish changed
> revocation information for an already expired certificate 

Re: Updating Root Inclusion Criteria (organizations)

[Peter Bowen via dev-security-policy]

On Wed, Jan 17, 2018 at 11:49 AM, Jakob Bohm via dev-security-policy
 wrote:
> 4. Selected company CAs for a handful of too-bit-to-ignore companies
>   that refuse to use a true public CA.  This would currently probably
>   be Microsoft, Amazon and Google.  These should be admitted only on
>   a temporary basis to pressure such companies to use generally trusted
>   independent CAs.

Jakob,

Can you please explain how you define "true public CA"?  How long
should new CAs have to meet this criteria?   I don't like carve outs
for "too-big-to-ignore".

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

Re: Updating Root Inclusion Criteria

[Jakob Bohm via dev-security-policy]

On 17/01/2018 21:14, Jonathan Rudenberg wrote:



On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy 
 wrote:

On 17/01/2018 16:13, Jonathan Rudenberg wrote:

On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
 wrote:

Hi Wayne,

After some time thinking about it, I struggled to articulate what the right
rules for inclusion were.

So I decided to approach this from a different perspective: which is that I
think we should design our other policies and requirements for CAs around
what we'd expect for organizations operating towards a goal of securing the
Internet as a global public resource.

Towards that goal we should continue to focus on things like transparency
(how this list is run, visibility of audit statements, certificate
transparency) and driving technical improvements to the WebPKI (shorter
certificate lifespans, fewer allowances for non-compliant certificates or
use of deprecated formats and cryptography). If organizations wish to hold
themselves to these (presumably higher) standards for what could equally
well be a private PKI, I don't see that as a problem. On the flip side, we
should not delay improvements because CAs with limited impact on the public
internet struggle with compliance.


I would say, that to limit the danger that such an essentially unused CA 
operator turns rogue, only CAs that provide certificates for public trust 
should be admitted in the future, more on that in another post.


I like this concept a lot. Some concrete ideas in this space:
- Limit the validity period of root certificates to a few years, so that the 
criteria can be re-evaluated, updated, and re-applied on a rolling basis.


This may be fine for TLS root CAs that are distributed in frequently
updated browsers (such as Firefox and Chrome).

It is absolutely fatal for roots that are also used for any of the
following:

- Distributed in browsers that don't get frequent updates (due to
  problems in that distribution channel), such as many browsers
  distributed in the firmware of mobile devices, TVs etc.


Distributing WebPKI roots in infrequently updated software is a bad idea and 
leads to disasters like the issues around the SHA-1 deprecation.



But what should then be done when that infrequently updated software is
in fact a general end user web browser (as opposed to the previously
discussed special cases of certain payment terminals)?  Remove TLS
support?  Trust all certificates without meaningful checks?  Pop up
certificate warnings for every valid certificate?

The way the SHA-1 deprecation was done, with no widely implemented way
for TLS clients to signal their ability to support stronger algorithms,
has in fact created a situation where unreliable hacks are needed to
support older mobile browsers, including feeding unencrypted pages to
some of them.  The public stigma attached to this makes this something
that is rarely discussed in public, but is quietly done by webmasters 
that need to communicate with those systems.



- Used to (indirectly) sign items of long validity, such as e-mails
  (Thunderbird!), timestamps and software.


I don’t know much about S/MIME, but this doesn’t sound right. Of course 
certificates used to sign emails expire! That’s obviously expected, and I’d 
hope that the validation takes that into account.



The mechanisms vary by recipient software.  But a typical technique
combines a known-unmodified-since date (such as the date of reception or
a date certified by a cryptographic timestamps) to compare the relevant
validity dates in certificates against.

This obviously needs continued trust in the root certificates
that were relevant at that earlier time, including the ability
if the corresponding CAs to publish and update revocation
information after the end certificates expiry date.  (Consider the
case where an e-mail sender's personal certificate was
compromised 1 day before expiry, but that fact was not reported
to the CA until later, thus requiring the CA to publish changed
revocation information for an already expired certificate in
order to protect relying parties (recipients) from trusting
fraudulent signatures made with the compromised key.


- Apply for inclusion in other root programs with slow/costly/
  inefficient distribution of new root certificates (At least one
  major software vendor has these problems in their root program).


This isn’t Mozilla’s problem, and one can come up with a variety of 
straightforward workarounds.


The big problem is that the formats for communicating the certificate
chain from the certificate holder to the relying parties are quite
limited in how they can accommodate different relying parties trusting
different roots from each CA.  Requiring CAs to set up extra workarounds
just to satisfy an arbitrary policy like yours is an unneeded
complication for everybody but Mozilla and Chrome.




- Make all certificates issued by CAs 

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 17, 2018, at 14:27, Jakob Bohm via dev-security-policy 
>  wrote:
> 
> On 17/01/2018 16:13, Jonathan Rudenberg wrote:
>>> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
>>>  wrote:
>>> 
>>> Hi Wayne,
>>> 
>>> After some time thinking about it, I struggled to articulate what the right
>>> rules for inclusion were.
>>> 
>>> So I decided to approach this from a different perspective: which is that I
>>> think we should design our other policies and requirements for CAs around
>>> what we'd expect for organizations operating towards a goal of securing the
>>> Internet as a global public resource.
>>> 
>>> Towards that goal we should continue to focus on things like transparency
>>> (how this list is run, visibility of audit statements, certificate
>>> transparency) and driving technical improvements to the WebPKI (shorter
>>> certificate lifespans, fewer allowances for non-compliant certificates or
>>> use of deprecated formats and cryptography). If organizations wish to hold
>>> themselves to these (presumably higher) standards for what could equally
>>> well be a private PKI, I don't see that as a problem. On the flip side, we
>>> should not delay improvements because CAs with limited impact on the public
>>> internet struggle with compliance.
> 
> I would say, that to limit the danger that such an essentially unused CA 
> operator turns rogue, only CAs that provide certificates for public trust 
> should be admitted in the future, more on that in another post.
> 
>> I like this concept a lot. Some concrete ideas in this space:
>> - Limit the validity period of root certificates to a few years, so that the 
>> criteria can be re-evaluated, updated, and re-applied on a rolling basis.
> 
> This may be fine for TLS root CAs that are distributed in frequently
> updated browsers (such as Firefox and Chrome).
> 
> It is absolutely fatal for roots that are also used for any of the
> following:
> 
> - Distributed in browsers that don't get frequent updates (due to
>  problems in that distribution channel), such as many browsers
>  distributed in the firmware of mobile devices, TVs etc.

Distributing WebPKI roots in infrequently updated software is a bad idea and 
leads to disasters like the issues around the SHA-1 deprecation.

> - Used to (indirectly) sign items of long validity, such as e-mails
>  (Thunderbird!), timestamps and software.

I don’t know much about S/MIME, but this doesn’t sound right. Of course 
certificates used to sign emails expire! That’s obviously expected, and I’d 
hope that the validation takes that into account.

> - Apply for inclusion in other root programs with slow/costly/
>  inefficient distribution of new root certificates (At least one
>  major software vendor has these problems in their root program).

This isn’t Mozilla’s problem, and one can come up with a variety of 
straightforward workarounds.

>> - Make all certificates issued by CAs under a root that is trusted for TLS 
>> in scope for the Baseline Requirements, and don’t allow issuing things like 
>> client certificates that have much more relaxed requirements (if any). This 
>> helps avoid ambiguity around scope.
> 
> Again this would be a major problem for roots that are used outside web
> browsers, including roots used for e-mail certificates (Thunderbird).
> 
> The ecosystem already suffers from the need to keep multiple trusted
> root certificates per CA organization due to artifacts of existing
> rules, no need to make this worse by multiplying this with the number
> of certificate end uses.

I’m having trouble seeing how sharding roots based on compliance type is a 
problem. Not doing so complicates reasoning about compliance unnecessarily.

>> - Limit the maximum validity period of leaf certificates issued to a sane 
>> upper bound like 90 days. This will help ensure that we don’t rust old 
>> crypto and standards in place and makes it less likely that a CA is “too big 
>> to fail” due to a set of customers that are not expecting to replace their 
>> certificates regularly.
> 
> This would be a *major* problem for any end users not using Let's
> encrypt, and would seemingly seek to destroy a major advantage of using
> a real CA over Let's encrypt.

Obviously this is completely false. Ridiculous diversions about “real” CAs 
aside, many other CAs issue certificates to automated management systems and 
this is obviously the way forward. Humans should not be managing certificate 
lifecycles.

> The only "too big to fail" problem we had recently was when the oldest,
> and biggest CA ever was forced out of business by some very loud people
> on this list.  And the problem was that those people demanded rushed
> punishment in the extreme with little or no consideration for who would
> be hurt in the process.

This is not true. Readers of this list are almost certainly quite familiar with 
the events that caused Google 

Re: Updating Root Inclusion Criteria (organizations)

[Jakob Bohm via dev-security-policy]

As for what CA organizations to include in a future iteration of the 
Mozilla root store, I would say that there are 4 groups that I (as a 
browser user) would like to get included and 2 which I would not:


1. Global public CAs that provide certificates to subscribers from all
  over the world subject to appropriate security controls to avoid
  issuing to people other than what the certificate states and avoid
  technical compromise of the certificate infrastructure and the relying
  party software.

2. National public and government CAs that issue certificates only to
  their own subjects (citizens, organizations, institutions) to similar
  high standards further enhanced by their authoritative knowledge of
  the true identities of subscribers.  However trust in those should be
  technically constrained (either in the roots or in extra root store
  metadata) to only the country identifiers they are actually
  authoritative for.  For example the Taiwan Governmemt roots should
  only be trusted for the .tw TLD (or perhaps some government
  subdomain).  Similar any new Danish national CA (replacing the dead
  TDC CA) would only be trusted for the .dk, .fo and .gl TLDs .
  The C= and jurisdictionOfIncorporation parts of distinguished names
  should also be restricted.

3. Major vertical CAs for high value business categories that issue
  publicly trusted certificates at better than EV level integrity.  For
  example if the VISA CA was issuing public certificates for the
  customer facing secure account web interfaces of most of the
  participating banks and credit card issuers, worldwide, they would be
  valuable CA to include.  The same would be true if the (now historic)
  SET payment standard had been included in Firefox and relied on VISA
  issued certificates for the payment servers.

4. Selected company CAs for a handful of too-bit-to-ignore companies
  that refuse to use a true public CA.  This would currently probably
  be Microsoft, Amazon and Google.  These should be admitted only on
  a temporary basis to pressure such companies to use generally trusted
  independent CAs.

Root operators not to include:

-1. Root programs that engage in actually harmful activities such as
  MiTM attacks or mandatory key escrow.  Seems many "ElDAS" style CAs in
  the EU do the latter.

-2. Root programs that serve only themselves and have not become too-big
  to ignore.


On 17/01/2018 00:45, Wayne Thayer wrote:

I would like to open a discussion about the criteria by which Mozilla
decides which CAs we should allow to apply for inclusion in our root store.

Section 2.1 of Mozilla’s current Root Store Policy states:

CAs whose certificates are included in Mozilla's root program MUST:

 1.provide some service relevant to typical users of our software
products;




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Jakob Bohm via dev-security-policy]

On 17/01/2018 16:13, Jonathan Rudenberg wrote:



On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
 wrote:

Hi Wayne,

After some time thinking about it, I struggled to articulate what the right
rules for inclusion were.

So I decided to approach this from a different perspective: which is that I
think we should design our other policies and requirements for CAs around
what we'd expect for organizations operating towards a goal of securing the
Internet as a global public resource.

Towards that goal we should continue to focus on things like transparency
(how this list is run, visibility of audit statements, certificate
transparency) and driving technical improvements to the WebPKI (shorter
certificate lifespans, fewer allowances for non-compliant certificates or
use of deprecated formats and cryptography). If organizations wish to hold
themselves to these (presumably higher) standards for what could equally
well be a private PKI, I don't see that as a problem. On the flip side, we
should not delay improvements because CAs with limited impact on the public
internet struggle with compliance.




I would say, that to limit the danger that such an essentially unused CA 
operator turns rogue, only CAs that provide certificates for public 
trust should be admitted in the future, more on that in another post.




I like this concept a lot. Some concrete ideas in this space:

- Limit the validity period of root certificates to a few years, so that the 
criteria can be re-evaluated, updated, and re-applied on a rolling basis.


This may be fine for TLS root CAs that are distributed in frequently
updated browsers (such as Firefox and Chrome).

It is absolutely fatal for roots that are also used for any of the
following:

 - Distributed in browsers that don't get frequent updates (due to
  problems in that distribution channel), such as many browsers
  distributed in the firmware of mobile devices, TVs etc.
 - Used to (indirectly) sign items of long validity, such as e-mails
  (Thunderbird!), timestamps and software.
 - Apply for inclusion in other root programs with slow/costly/
  inefficient distribution of new root certificates (At least one
  major software vendor has these problems in their root program).



- Make all certificates issued by CAs under a root that is trusted for TLS in 
scope for the Baseline Requirements, and don’t allow issuing things like client 
certificates that have much more relaxed requirements (if any). This helps 
avoid ambiguity around scope.


Again this would be a major problem for roots that are used outside web
browsers, including roots used for e-mail certificates (Thunderbird).

The ecosystem already suffers from the need to keep multiple trusted
root certificates per CA organization due to artifacts of existing
rules, no need to make this worse by multiplying this with the number
of certificate end uses.


- Limit the maximum validity period of leaf certificates issued to a sane upper 
bound like 90 days. This will help ensure that we don’t rust old crypto and 
standards in place and makes it less likely that a CA is “too big to fail” due 
to a set of customers that are not expecting to replace their certificates 
regularly.


This would be a *major* problem for any end users not using Let's
encrypt, and would seemingly seek to destroy a major advantage of using
a real CA over Let's encrypt.

The only "too big to fail" problem we had recently was when the oldest,
and biggest CA ever was forced out of business by some very loud people
on this list.  And the problem was that those people demanded rushed
punishment in the extreme with little or no consideration for who would
be hurt in the process.

All in all, such a requirement would do nothing but harm.




I think with these and other similar requirements, we move closer towards 
ensuring that the roots accepted are operated with the high level goals 
described by Alex in mind, and allow more agility at the root store level to 
respond to issues.

Jonathan




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Ryan Hurst via dev-security-policy]

On Tuesday, January 16, 2018 at 3:46:03 PM UTC-8, Wayne Thayer wrote:
> I would like to open a discussion about the criteria by which Mozilla
> decides which CAs we should allow to apply for inclusion in our root store.
> 
> Section 2.1 of Mozilla’s current Root Store Policy states:
> 
> CAs whose certificates are included in Mozilla's root program MUST:
> > 1.provide some service relevant to typical users of our software
> > products;
> >
> 
> Further non-normative guidance for which organizations may apply to the CA
> program is documented in the ‘Who May Apply’ section of the application
> process at https://wiki.mozilla.org/CA/Application_Process . The original
> intent of this provision in the policy and the guidance was to discourage a
> large number of organizations from applying to the program solely for the
> purpose of avoiding the difficulties of distributing private roots for
> their own internal use.
> 
> Recently, we’ve encountered a number of examples that cause us to question
> the usefulness of the currently-vague statement(s) we have that define
> which CAs to accept, along a number of different axes:
> 
> * Visa is a current program member that has an open request to add another
> root. They only issue a relatively small number of certificates per year to
> partners and for internal use. They do not offer certificates to the
> general public or to anyone with whom they do not have an existing business
> relationship.
> 
> * Google is also a current program member, admitted via the acquisition of
> an existing root, but does not currently, to the best of our knowledge,
> meet the existing inclusion criteria, even though it is conceivable that
> they would issue certificates to the public in the future.
> 
> * There are potential applicants for CA status who deploy a large number of
> certificates, but only on their own infrastructure and for their own
> domains, albeit that this infrastructure is public-facing rather than
> company-internal.
> 
> * We have numerous government CAs in the program or in the inclusion
> process that only intend to issue certificates to their own institutions.
> 
> * We have at least one CA applying for the program that (at least, it has
> been reported in the press) is controlled by an entity which may wish to
> use it for MITM.
> 
> There are many potential options for resolving this issue. Ideally, we
> would like to establish some objective criteria that can be measured and
> applied fairly. It’s possible that this could require us to define
> different categories of CAs, each with different inclusion criteria. Or it
> could be that we should remove the existing ‘relevance’ requirement and
> inclusion guidelines and accept any applicant who can meet all of our other
> requirements.
> 
> With this background, I would like to encourage everyone to provide
> constructive input on this topic.
> 
> Thanks,
> 
> Wayne

Wayne,

I recall facing this topic at Microsoft when I was defining the root policy for 
them. At the time I failed to effectively come up with language that would 
capture all of the use cases we felt were important. This is why we ended up 
with what was at the time a vague statement on broad value to Microsoft 
consumers.

With that said, despite the challenges associated with the tasks, I agree this 
is an area where clarity is needed.

Since Google's PKI was mentioned as an example, I can publicly state that the 
plan is for Google to utilize the Google Trust Services infrastructure to 
satisfy its SSL certificate needs. While I can not announce specific product 
roadmaps I can say that this includes the issuance of certificates for Google 
offerings involving hosting of products and services for customers.

Ryan Hurst
Product Manager 
Google
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Peter Bowen via dev-security-policy]

On Tue, Jan 16, 2018 at 3:45 PM, Wayne Thayer via dev-security-policy
 wrote:
> I would like to open a discussion about the criteria by which Mozilla
> decides which CAs we should allow to apply for inclusion in our root store.
>
> Section 2.1 of Mozilla’s current Root Store Policy states:
>
> CAs whose certificates are included in Mozilla's root program MUST:
>> 1.provide some service relevant to typical users of our software
>> products;
>>
>
> Further non-normative guidance for which organizations may apply to the CA
> program is documented in the ‘Who May Apply’ section of the application
> process at https://wiki.mozilla.org/CA/Application_Process . The original
> intent of this provision in the policy and the guidance was to discourage a
> large number of organizations from applying to the program solely for the
> purpose of avoiding the difficulties of distributing private roots for
> their own internal use.
>
> Recently, we’ve encountered a number of examples that cause us to question
> the usefulness of the currently-vague statement(s) we have that define
> which CAs to accept, along a number of different axes:
>
[snip]
>
> There are many potential options for resolving this issue. Ideally, we
> would like to establish some objective criteria that can be measured and
> applied fairly. It’s possible that this could require us to define
> different categories of CAs, each with different inclusion criteria. Or it
> could be that we should remove the existing ‘relevance’ requirement and
> inclusion guidelines and accept any applicant who can meet all of our other
> requirements.
>
> With this background, I would like to encourage everyone to provide
> constructive input on this topic.

Wayne,

In the interest of transparency, I would like to add one more example
to your list:

* Amazon Trust Services is a current program member.  Amazon applied
independently but then subsequently bought a root from Go Daddy
(obvious disclosure: Wayne was VP at Go Daddy at the time).  So far
there is no public path to bring Amazon a public key/CSR you generate
on you own server and have Amazon issue a certificate containing that
public key.  The primary path to getting a certificate issued by
Amazon is to use AWS Certificate Manager.  That being said, we have
issued certificates to hundreds of thousands of domains and Mozilla
telemetry data shows they are being widely used by users of Mozilla
software products.

Thanks,
Peter

P.S. I'm very much looking forward to the Firefox ESR 60 release, as
that will mark Amazon inclusion for EV in all Mozilla products.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Updating Root Inclusion Criteria

[Jonathan Rudenberg via dev-security-policy]

> On Jan 17, 2018, at 09:54, Alex Gaynor via dev-security-policy 
>  wrote:
> 
> Hi Wayne,
> 
> After some time thinking about it, I struggled to articulate what the right
> rules for inclusion were.
> 
> So I decided to approach this from a different perspective: which is that I
> think we should design our other policies and requirements for CAs around
> what we'd expect for organizations operating towards a goal of securing the
> Internet as a global public resource.
> 
> Towards that goal we should continue to focus on things like transparency
> (how this list is run, visibility of audit statements, certificate
> transparency) and driving technical improvements to the WebPKI (shorter
> certificate lifespans, fewer allowances for non-compliant certificates or
> use of deprecated formats and cryptography). If organizations wish to hold
> themselves to these (presumably higher) standards for what could equally
> well be a private PKI, I don't see that as a problem. On the flip side, we
> should not delay improvements because CAs with limited impact on the public
> internet struggle with compliance.


I like this concept a lot. Some concrete ideas in this space:

- Limit the validity period of root certificates to a few years, so that the 
criteria can be re-evaluated, updated, and re-applied on a rolling basis.
- Make all certificates issued by CAs under a root that is trusted for TLS in 
scope for the Baseline Requirements, and don’t allow issuing things like client 
certificates that have much more relaxed requirements (if any). This helps 
avoid ambiguity around scope.
- Limit the maximum validity period of leaf certificates issued to a sane upper 
bound like 90 days. This will help ensure that we don’t rust old crypto and 
standards in place and makes it less likely that a CA is “too big to fail” due 
to a set of customers that are not expecting to replace their certificates 
regularly.

I think with these and other similar requirements, we move closer towards 
ensuring that the roots accepted are operated with the high level goals 
described by Alex in mind, and allow more agility at the root store level to 
respond to issues.

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

Re: Updating Root Inclusion Criteria

[Alex Gaynor via dev-security-policy]

Hi Wayne,

After some time thinking about it, I struggled to articulate what the right
rules for inclusion were.

So I decided to approach this from a different perspective: which is that I
think we should design our other policies and requirements for CAs around
what we'd expect for organizations operating towards a goal of securing the
Internet as a global public resource.

Towards that goal we should continue to focus on things like transparency
(how this list is run, visibility of audit statements, certificate
transparency) and driving technical improvements to the WebPKI (shorter
certificate lifespans, fewer allowances for non-compliant certificates or
use of deprecated formats and cryptography). If organizations wish to hold
themselves to these (presumably higher) standards for what could equally
well be a private PKI, I don't see that as a problem. On the flip side, we
should not delay improvements because CAs with limited impact on the public
internet struggle with compliance.

In summary, I think we should focus less on the questions of whether a CA
is "appropriate" or "deserving" of participation in the Mozilla Root
Program, and more on whether they are willing and able to fulfill the
expectations of them as a steward of global trust on the internet. This has
the nice benefit of aligning well with Mozilla's mission to ensure the
internet is a global public resource, open and accessible to all.

Alex

On Tue, Jan 16, 2018 at 6:45 PM, Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I would like to open a discussion about the criteria by which Mozilla
> decides which CAs we should allow to apply for inclusion in our root store.
>
> Section 2.1 of Mozilla’s current Root Store Policy states:
>
> CAs whose certificates are included in Mozilla's root program MUST:
> > 1.provide some service relevant to typical users of our software
> > products;
> >
>
> Further non-normative guidance for which organizations may apply to the CA
> program is documented in the ‘Who May Apply’ section of the application
> process at https://wiki.mozilla.org/CA/Application_Process . The original
> intent of this provision in the policy and the guidance was to discourage a
> large number of organizations from applying to the program solely for the
> purpose of avoiding the difficulties of distributing private roots for
> their own internal use.
>
> Recently, we’ve encountered a number of examples that cause us to question
> the usefulness of the currently-vague statement(s) we have that define
> which CAs to accept, along a number of different axes:
>
> * Visa is a current program member that has an open request to add another
> root. They only issue a relatively small number of certificates per year to
> partners and for internal use. They do not offer certificates to the
> general public or to anyone with whom they do not have an existing business
> relationship.
>
> * Google is also a current program member, admitted via the acquisition of
> an existing root, but does not currently, to the best of our knowledge,
> meet the existing inclusion criteria, even though it is conceivable that
> they would issue certificates to the public in the future.
>
> * There are potential applicants for CA status who deploy a large number of
> certificates, but only on their own infrastructure and for their own
> domains, albeit that this infrastructure is public-facing rather than
> company-internal.
>
> * We have numerous government CAs in the program or in the inclusion
> process that only intend to issue certificates to their own institutions.
>
> * We have at least one CA applying for the program that (at least, it has
> been reported in the press) is controlled by an entity which may wish to
> use it for MITM.
>
> There are many potential options for resolving this issue. Ideally, we
> would like to establish some objective criteria that can be measured and
> applied fairly. It’s possible that this could require us to define
> different categories of CAs, each with different inclusion criteria. Or it
> could be that we should remove the existing ‘relevance’ requirement and
> inclusion guidelines and accept any applicant who can meet all of our other
> requirements.
>
> With this background, I would like to encourage everyone to provide
> constructive input on this topic.
>
> Thanks,
>
> Wayne
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Updating Root Inclusion Criteria

[Tim Hollebeek via dev-security-policy]

Wayne,

I support "encouraging" those who are currently using the public web PKI for 
internal uses to move to their own private PKIs.  The current situation is an 
artifact of the old notion that there should be a global "One CA List to Rule 
Them All" owned by the operating system, and everyone should use that.
That notion is a bit antiquated, in my mind.  Applications and components
that need a trust list really need to carefully select (or create!) an 
appropriate 
one instead of just grabbing the most convenient one.

I'm familiar with a few efforts in the financial space to transition away from
browser trust lists for non-browser TLS, but as you can imagine, that's not a 
trivial effort and will take some time.  My only request would be that if the
rules are going to change, that large companies and entire industries that
may be affected be given enough notice to be able to come up with
reasonable transition plans.

-Tim

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+tim.hollebeek=digicert@lists.mozilla.org] On Behalf Of Wayne
> Thayer via dev-security-policy
> Sent: Tuesday, January 16, 2018 4:46 PM
> To: mozilla-dev-security-policy 
> <mozilla-dev-security-pol...@lists.mozilla.org>
> Subject: Updating Root Inclusion Criteria
> 
> I would like to open a discussion about the criteria by which Mozilla decides
> which CAs we should allow to apply for inclusion in our root store.
> 
> Section 2.1 of Mozilla’s current Root Store Policy states:
> 
> CAs whose certificates are included in Mozilla's root program MUST:
> > 1.provide some service relevant to typical users of our software
> > products;
> >
> 
> Further non-normative guidance for which organizations may apply to the CA
> program is documented in the ‘Who May Apply’ section of the application
> process at https://wiki.mozilla.org/CA/Application_Process . The original
> intent of this provision in the policy and the guidance was to discourage a 
> large
> number of organizations from applying to the program solely for the purpose
> of avoiding the difficulties of distributing private roots for their own 
> internal
> use.
> 
> Recently, we’ve encountered a number of examples that cause us to question
> the usefulness of the currently-vague statement(s) we have that define which
> CAs to accept, along a number of different axes:
> 
> * Visa is a current program member that has an open request to add another
> root. They only issue a relatively small number of certificates per year to
> partners and for internal use. They do not offer certificates to the general
> public or to anyone with whom they do not have an existing business
> relationship.
> 
> * Google is also a current program member, admitted via the acquisition of an
> existing root, but does not currently, to the best of our knowledge, meet the
> existing inclusion criteria, even though it is conceivable that they would 
> issue
> certificates to the public in the future.
> 
> * There are potential applicants for CA status who deploy a large number of
> certificates, but only on their own infrastructure and for their own domains,
> albeit that this infrastructure is public-facing rather than company-internal.
> 
> * We have numerous government CAs in the program or in the inclusion
> process that only intend to issue certificates to their own institutions.
> 
> * We have at least one CA applying for the program that (at least, it has been
> reported in the press) is controlled by an entity which may wish to use it for
> MITM.
> 
> There are many potential options for resolving this issue. Ideally, we would 
> like
> to establish some objective criteria that can be measured and applied fairly. 
> It’s
> possible that this could require us to define different categories of CAs, 
> each
> with different inclusion criteria. Or it could be that we should remove the
> existing ‘relevance’ requirement and inclusion guidelines and accept any
> applicant who can meet all of our other requirements.
> 
> With this background, I would like to encourage everyone to provide
> constructive input on this topic.
> 
> Thanks,
> 
> Wayne
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy


smime.p7s
Description: S/MIME cryptographic signature
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Updating Root Inclusion Criteria

[Wayne Thayer via dev-security-policy]

I would like to open a discussion about the criteria by which Mozilla
decides which CAs we should allow to apply for inclusion in our root store.

Section 2.1 of Mozilla’s current Root Store Policy states:

CAs whose certificates are included in Mozilla's root program MUST:
> 1.provide some service relevant to typical users of our software
> products;
>

Further non-normative guidance for which organizations may apply to the CA
program is documented in the ‘Who May Apply’ section of the application
process at https://wiki.mozilla.org/CA/Application_Process . The original
intent of this provision in the policy and the guidance was to discourage a
large number of organizations from applying to the program solely for the
purpose of avoiding the difficulties of distributing private roots for
their own internal use.

Recently, we’ve encountered a number of examples that cause us to question
the usefulness of the currently-vague statement(s) we have that define
which CAs to accept, along a number of different axes:

* Visa is a current program member that has an open request to add another
root. They only issue a relatively small number of certificates per year to
partners and for internal use. They do not offer certificates to the
general public or to anyone with whom they do not have an existing business
relationship.

* Google is also a current program member, admitted via the acquisition of
an existing root, but does not currently, to the best of our knowledge,
meet the existing inclusion criteria, even though it is conceivable that
they would issue certificates to the public in the future.

* There are potential applicants for CA status who deploy a large number of
certificates, but only on their own infrastructure and for their own
domains, albeit that this infrastructure is public-facing rather than
company-internal.

* We have numerous government CAs in the program or in the inclusion
process that only intend to issue certificates to their own institutions.

* We have at least one CA applying for the program that (at least, it has
been reported in the press) is controlled by an entity which may wish to
use it for MITM.

There are many potential options for resolving this issue. Ideally, we
would like to establish some objective criteria that can be measured and
applied fairly. It’s possible that this could require us to define
different categories of CAs, each with different inclusion criteria. Or it
could be that we should remove the existing ‘relevance’ requirement and
inclusion guidelines and accept any applicant who can meet all of our other
requirements.

With this background, I would like to encourage everyone to provide
constructive input on this topic.

Thanks,

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