Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria

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%

Re: Updating Root Inclusion Criteria

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

RE: Updating Root Inclusion Criteria

> 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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

> 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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

> 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

Re: Updating Root Inclusion Criteria (organizations)

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.

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

> 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

Re: Updating Root Inclusion Criteria (organizations)

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

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

Re: Updating Root Inclusion Criteria

> 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

Re: Updating Root Inclusion Criteria

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

RE: Updating Root Inclusion Criteria

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