problem of encouraging
the good and preventing the bad.
Original Message
From: Gervase Markham
Sent: Tuesday, April 25, 2017 4:28 AM
To: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots
Hi Peter,
On 25/04/17 02
Hi Peter,
On 25/04/17 02:10, Peter Kurrasch wrote:
> Fair enough. I propose the following for consideration:
As it happens, I have been working on encoding:
https://wiki.mozilla.org/CA:RootTransferPolicy
into our policy. A sneak preview first draft is here:
https://github.com/mozilla/pkipolicy/c
On Tue, Apr 25, 2017 at 12:58 AM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Look at my two examples of past acquisitions. As far as I remember, in
> neither case was the purchasing security company previously a trusted
> CA, and they took over practical
On Monday, April 24, 2017 at 9:58:29 PM UTC-7, Jakob Bohm wrote:
> On 25/04/2017 05:04, Ryan Sleevi wrote:
> > On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> On 25/04/2017 03:10, Peter Kurrasch wrote:
> >>
> >>> Fair
On 25/04/2017 05:04, Ryan Sleevi wrote:
On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
On 25/04/2017 03:10, Peter Kurrasch wrote:
Fair enough. I propose the following for consideration:
Prior to transferring ownership of a
On Monday, April 24, 2017 at 8:02:15 PM UTC-7, Peter Kurrasch wrote:
> I see what you're saying and there should be some consideration for that
> scenario. If the acquiring company will keep all the same infrastructure and
> staff and if decision making authority will remain with that staff, then
On Mon, Apr 24, 2017 at 9:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 25/04/2017 03:10, Peter Kurrasch wrote:
>
>> Fair enough. I propose the following for consideration:
>>
>> Prior to transferring ownership of a root cert contained in the trust
I see what you're saying and there should be some consideration for that scenario. If the acquiring company will keep all the same infrastructure and staff and if decision making authority will remain with that st
ove can cause, it is much better to learn that
up front so that appropriate plans can be made.
*From: *Gervase Markham via dev-security-policy
*Sent: *Tuesday, April 11, 2017 11:36 AM
*To: *mozilla-dev-security-pol...@lists.mozilla.org
*Reply To: *Gervase Markham
*Subject: *Re: Criticism of Google R
Fair enough. I propose the following for consideration:Prior to transferring ownership of a root cert contained in the trusted store (either on an individual root basis or as part of a company acquisition), a pub
On 11/04/17 14:05, Peter Kurrasch wrote:
> Is there room to expand Mozilla policy in regards to ownership issues?
Subject to available time (which, as you might guess by the traffic in
this group, there's not a lot of right now, given that this is not my
only job) there's always room to reconsider
I think Jacob was merely attempting to provide a more thought out alternative to my proposal basically requiring potential CA owners to first be "accepted" into the Mozilla trusted root program. There is some over
On 06/04/17 18:42, Jakob Bohm wrote:
> Here are some ideas for reasonable new/enhanced policies (rough
> sketches to be discussed and honed before insertion into a future
> Mozilla policy version):
I'm not sure what's new or enhanced about them. Our current policies are
not this prescriptive so CA
On 06/04/17 03:24, Peter Kurrasch wrote:
> things they like. It's a very lucrative business so when I see a root
> cert coming up for sale it's a no-brainer for me to go out and purchase
> it. Having access to a root will undoubtedly come in handy as I grow my
> business.
The previous owner of the
On 06/04/2017 23:49, Ryan Sleevi wrote:
On Thu, Apr 6, 2017 at 1:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Here are some ideas for reasonable new/enhanced policies (rough
sketches to be discussed and honed before insertion into a future
Mozilla p
On Thu, Apr 6, 2017 at 1:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Here are some ideas for reasonable new/enhanced policies (rough
> sketches to be discussed and honed before insertion into a future
> Mozilla policy version):
>
Are you suggestin
M
*To: *mozilla-dev-security-pol...@lists.mozilla.org
*Reply To: *Nick Lamb
*Subject: *Re: Criticism of Google Re: Google Trust Services roots
On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote:
I must be missing something still? The implication here is that a
purchaser who is not yet p
On Thursday, April 6, 2017 at 3:24:53 AM UTC+1, Peter Kurrasch wrote:
> I have no issue with the situations you describe below. Mozilla should act to
> encourage the good behaviors that we would want a new, acquiring CA to
> exhibit while prohibiting the bad--or at least limiting the damage those
I have no issue with the situations you describe below. Mozilla should act to encourage the good behaviors that we would want a new, acquiring CA to exhibit while prohibiting the bad--or at least limiting the dama
On Monday, 3 April 2017 23:34:44 UTC+1, Peter Kurrasch wrote:
> I must be missing something still? The implication here is that a purchaser
> who is not yet part of the root program is permitted to take possession of
> the root cert private key and possibly the physical space, key personnel,
>
From: Gervase Markham
Sent: Saturday, April 1, 2017 6:02 AM
To: Peter Kurrasch; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 31/03/17 20:26, Peter Kurrasch wrote:
> The revised example is not entirely what I had in mind (more
On 31/03/17 20:26, Peter Kurrasch wrote:
> The revised example is not entirely what I had in mind (more on that
> in a minute) but as written now is mostly OK by me. I do have a
> question as to whether the public discussion as mentioned must take
> place before the actual transfer? In other words,
ay, March 31, 2017 12:28 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 31/03/17 17:39, Peter Bowen wrote:
>>> For example, how frequently should roots
>>> be allowed to change hands? Wha
On 31/03/17 17:39, Peter Bowen wrote:
>>> For example, how frequently should roots
>>> be allowed to change hands? What would Mozilla's response be if
>>> GalaxyTrust (an operator not in the program)
>>> were to say that they are acquiring the HARICA root?
>>
>> From the above URL: "In addition, if
On Fri, Mar 31, 2017 at 8:18 AM, Gervase Markham via
dev-security-policy wrote:
> On 30/03/17 15:01, Peter Kurrasch wrote:
>> By "not new", are you referring to Google being the second(?)
>> instance where a company has purchased an individual root cert from
>> another company? It's fair enough to
On 30/03/17 15:01, Peter Kurrasch wrote:
> By "not new", are you referring to Google being the second(?)
> instance where a company has purchased an individual root cert from
> another company? It's fair enough to say that Google isn't the first
> but I'm not aware of any commentary or airing of op
On 30/03/2017 08:08, Gervase Markham wrote:
On 29/03/17 20:42, Jakob Bohm wrote:
That goal would be equally (in fact better) served by new market
entrants getting cross-signed by incumbents, like Let's encrypt did.
Google will be issuing from Google-branded intermediates under the
ex-GlobalSig
derstandings :)
Dimitris.
Original Message
From: Gervase Markham via dev-security-policy
Sent: Thursday, March 30, 2017 1:06 AM
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 29/03/17 20:46, Peter
--- via dev-security-policy
Sent: Friday, March 31, 2017 2:07 PM
To: mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Criticism of Google Re: Google Trust Services roots
> and we don't think our brand is "tarnishing", we are working hard to try to
> regain the tr
* Peter Kurrasch via dev-security-policy:
> By "not new", are you referring to Google being the second(?) instance
> where a company has purchased an individual root cert from another
> company? It's fair enough to say that Google isn't the first but I'm
> not aware of any commentary or airing of
tector of the global PKI but I'm not sure who else is in a better position
> for that role?
>
>
> Original Message
> From: Gervase Markham via dev-security-policy
> Sent: Thursday, March 30, 2017 1:06 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
> Repl
To: mozilla-dev-security-pol...@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root
eply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it
> appears in
On 29/03/17 20:42, Jakob Bohm wrote:
> That goal would be equally (in fact better) served by new market
> entrants getting cross-signed by incumbents, like Let's encrypt did.
Google will be issuing from Google-branded intermediates under the
ex-GlobalSign roots. So the chains would be basically th
On 29/03/17 20:46, Peter Kurrasch wrote:
> It's not inconsequential for Google to say: "From now on, nobody can
> trust what you see in the root certificate, even if some of it
> appears in the browser UI. The only way you can actually establish
> trust is to do frequent, possibly complicated resea
On 29/03/2017 20:52, Alex Gaynor wrote:
I don't think it's a good idea to design our system around the idea of
"What would a user be looking for if they read the cert chain manually".
For example, in the US, if such a government agency chose to use a
Government CA (as a user might reasonably expe
I don't think it's a good idea to design our system around the idea of
"What would a user be looking for if they read the cert chain manually".
For example, in the US, if such a government agency chose to use a
Government CA (as a user might reasonably expect!), their users would all
get cert warni
.@lists.mozilla.org
Reply To: Gervase Markham
Subject: Re: Criticism of Google Re: Google Trust Services roots
On 29/03/17 15:35, Peter Kurrasch wrote:
> In other words, what used to be a trust anchor is now no better at
> establishing trust than the end-entity cert one is trying to validate o
On 29/03/2017 16:47, Gervase Markham wrote:
On 29/03/17 15:35, Peter Kurrasch wrote:
In other words, what used to be a trust anchor is now no better at
establishing trust than the end-entity cert one is trying to validate or
investigate (for example, in a forensic context) in the first place. I
On 29/03/17 15:35, Peter Kurrasch wrote:
> In other words, what used to be a trust anchor is now no better at
> establishing trust than the end-entity cert one is trying to validate or
> investigate (for example, in a forensic context) in the first place. I
> hardly think this redefinition of trust
40 matches
Mail list logo