Re: Criticism of Google Re: Google Trust Services roots

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:10, Peter

Re: Criticism of Google Re: Google Trust Services roots

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:

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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,

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

e, 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 Re: Google

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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 part of the root program is permitted to take possession of the root cert private key and p

Re: Criticism of Google Re: Google Trust Services roots

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

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 part of the root program is permitted to take possession of > the root cert private key and possibly the physical space, key personnel, >

Re: Criticism of Google Re: Google Trust Services roots

: 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 (m

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 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

Re: Criticism of Google Re: Google Trust Services roots

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? What would Mozilla's response be

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? 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,

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

RE: Criticism of Google Re: Google Trust Services roots

--- 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 trus

Re: Criticism of Google Re: Google Trust Services roots

* 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

RE: Criticism of Google Re: Google Trust Services roots

ts.mozilla.org Subject: Re: Criticism of Google Re: Google Trust Services roots 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 no

Re: Criticism of Google Re: Google Trust Services roots

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 the browser UI. The only way you can ac

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

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

Re: Criticism of Google Re: Google Trust Services roots

se 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 or > investigate (for example, in

Re: Criticism of Google Re: Google Trust Services roots

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

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 or > investigate (for example, in a forensic context) in the first place. I > hardly think this redefinition of

Re: Google Trust Services roots

On 27/03/17 23:18, okaphone.elektron...@gmail.com wrote: > Will that remain the responsibility of GlobalSign for any existing > certificates that have been signed with these roots? (Those would be > intermediate certificates, if I understand correctly.) Or does > revocation also require signing,

Re: Google Trust Services roots

It's probably my ignorance in these matters, but how does purchasing a root certificate affect revocation? Will that remain the responsibility of GlobalSign for any existing certificates that have been signed with these roots? (Those would be intermediate certificates, if I understand

Re: Google Trust Services roots

Clarified on the new thread you started, but I don't believe there's any inconsistency. Further details on the new thread you started. On Mon, Mar 27, 2017 at 10:02 AM, Roland Fantasia via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Anyone care to comment on the fact

Re: Google Trust Services roots

Anyone care to comment on the fact that Google's new subCAs under the GTS branding have inconsistent EKU and KU bits? What's more disturbing is FF doesn't make a fuss about it when connecting to the test sites (after adding the roots manually of course).

Re: Google Trust Services roots

On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > ‎I would be interested in knowing why Google felt it necessary to purchase > an existing root instead of, for example, pursuing a "new root" path along > the lines of what

Re: Google Trust Services roots

age   From: Ryan Hurst via dev-security-policy Sent: Wednesday, March 8, 2017 12:02 PM To: mozilla-dev-security-pol...@lists.mozilla.org Reply To: Ryan Hurst Subject: Re: Google Trust Services roots > Jakob: An open question is how revocation and OCSP status for the > existing inter

Re: Google Trust Services roots

On 16/03/17 10:50, Gervase Markham wrote: > https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership With these changes and the filing of https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this particular discussion RESOLVED. This means Mozilla plans to take no

Re: Google Trust Services roots

On 08/03/17 16:20, Gervase Markham wrote: > On 09/02/17 22:55, Peter Bowen wrote: >> Policy Suggestion A) When transferring a root that is EV enabled, it >> should be clearly stated whether the recipient of the root is also >> receiving the EV policy OID(s). > > I agree with this suggestion; we

Re: Google Trust Services roots

On 07/03/17 10:18, Gervase Markham wrote: > OK. Question for group: would it make sense to add the intermediate(s) > that GlobalSign is using for this purpose directly to the Mozilla trust > store, with the EV bit enabled, and then remove the EV bit from the > roots now owned by Google Trust

Re: Google Trust Services roots

On Thu, Mar 9, 2017 at 11:02 PM, Jakob Bohm via dev-security-policy wrote: > > Of all these, Starfield seems to be the only case where a single CA > name now refers to two different current CA operators (GoDaddy and > Amazon). All the others are cases of

Criticism of GMO GlobalSign Re: Google Trust Services roots

This is my second of three forks of this discussion on the transfer of 2 GlobalSign roots. This thread focuses on GMO GlobalSign because in my estimation they have put themselves in a precarious position that

RE: [FORGED] Criticism of Mozilla Re: Google Trust Services roots

;; Peter Kurrasch > <fhw...@gmail.com> > Cc: MozPol <mozilla-dev-security-pol...@lists.mozilla.org> > Subject: Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots > > Kurrasch via dev-security-policy <dev-security-policy@lists.mozilla.org> > writ

Re: Criticism of Mozilla Re: Google Trust Services roots

On 10/03/17 06:41, Peter Kurrasch wrote: > * Types of transfers: I don't think the situation was envisioned where a > single root would be transferred between entities in such a way that > company names and branding would become intermingled. My own personal > opinion is that such intermingling

Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots

Kurrasch via dev-security-policy writes: >* Types of transfers: I don't think the situation was envisioned where a >single root would be transferred between entities in such a way that company >names and branding would become intermingled. This has

Re: Criticism of Mozilla Re: Google Trust Services roots

Most are not directed at me so I won’t respond to each item, but for several I think I can provide some additional context, see below: > * Manner of transfer: As we learned from Ryan H., a second HSM was > introduced for the transfer of the private key meaning that for a period of > time 2

Re: Google Trust Services roots

> Of all these, Starfield seems to be the only case where a single CA > name now refers to two different current CA operators (GoDaddy and > Amazon). All the others are cases of complete takeover. None are > cases where the name in the certificate is a still operating CA > operator, but the

Re: Google Trust Services roots

On 10/03/2017 07:29, Ryan Hurst wrote: On Thursday, March 9, 2017 at 9:00:21 PM UTC-8, Peter Kurrasch wrote: By definition, a CPS is the authoritative document on what root certificates a CA operates and how they go about that operation. If the GlobalSign CPS has been updated to reflect the

Criticism of Mozilla Re: Google Trust Services roots

I've changed the subject of this thread because I have criticisms of all 3 parties involved in this transaction and will be bringing them up separately. That said, "criticism" may be too strong a word in this case because I think I do understand and appreciate the position that Mozilla is in

Re: Google Trust Services roots

> Best Regards, > > Richard > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Friday, March 10, 2017 2:16 PM > To: Richard Wang <rich...@wosign.com> > Cc: Ryan Sleevi <r...@sleevi.com>; Gervase Markham <g...@mozilla.org>; >

RE: Google Trust Services roots

- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Friday, March 10, 2017 2:16 PM To: Richard Wang <rich...@wosign.com> Cc: Ryan Sleevi <r...@sleevi.com>; Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots O

Re: Google Trust Services roots

On Thursday, March 9, 2017 at 9:00:21 PM UTC-8, Peter Kurrasch wrote: > By definition, a CPS is the authoritative document on what root > certificates a CA operates and how they go about that operation. If the > GlobalSign CPS has been updated to reflect the loss of their 2 roots, > that's fine.

Re: Google Trust Services roots

On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote: > Why we setup one EV OID for all roots is that we use the same policy for all > EV SSL certificate no matter it is issued by which root. The policy OID is > unique ID > > If Google use the GlobalSign EV OID, and

Re: Google Trust Services roots

By definition, a CPS is the authoritative document on what root certificates a CA operates and how they go about that operation. If the GlobalSign CPS has been updated to reflect the loss of their 2 roots, that's fine. Nobody is questioning that. What is being questioned is whether updating the

Re: Google Trust Services roots

On 08/03/2017 18:12, Ryan Hurst wrote: jacob: Could a reasonably condition be that decision authority, actual and physical control for a root are not moved until proper root program coordination has been done (an action which may occur after/before the commercial conclusion of a transaction).

Re: Google Trust Services roots

Clear, thanks. Best Regards, Richard > On 9 Mar 2017, at 22:05, Gervase Markham via dev-security-policy > wrote: > >> On 09/03/17 12:38, Richard Wang wrote: >> As my understanding, if WoSign buy an trusted EV enabled root key >> with EV OID today, then

Re: Google Trust Services roots

On 09/03/17 12:38, Richard Wang wrote: > As my understanding, if WoSign buy an trusted EV enabled root key > with EV OID today, then we can issue WoSign EV SSL cert using this EV > OID tomorrow, the browser will display EV green bar. Right? Technically, you are correct - such certs would produce

Re: Google Trust Services roots

As my understanding, if WoSign buy an trusted EV enabled root key with EV OID today, then we can issue WoSign EV SSL cert using this EV OID tomorrow, the browser will display EV green bar. Right? If right, we like this policy, thanks. Best Regards, Richard > On 9 Mar 2017, at 19:51, Gervase

Re: Google Trust Services roots

gt; > Richard > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Thursday, March 9, 2017 1:11 PM > To: Richard Wang <rich...@wosign.com> > Cc: Ryan Sleevi <r...@sleevi.com>; Gervase Markham <g...@mozilla.org>; > mozilla-d

Re: Google Trust Services roots

On 09/03/17 02:15, Richard Wang wrote: > So the policy can make clear that the root key transfer can't > transfer the EV OID, the receiver must use its own EV policy OID for > its EV SSL, the receiver can't use the transferor's EV OID. We could indeed write this into the policy, but it would have

Re: Google Trust Services roots

On 2017-03-09 05:21, Ryan Sleevi wrote: Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details. Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate.

RE: Google Trust Services roots

...@gmail.com] Sent: Thursday, March 9, 2017 1:11 PM To: Richard Wang <rich...@wosign.com> Cc: Ryan Sleevi <r...@sleevi.com>; Gervase Markham <g...@mozilla.org>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots Richard, I'm afraid a few things are con

Re: Google Trust Services roots

Richard, I'm afraid a few things are confused here. First, a single CA Operator may have multiple roots in the browser trust list. Each root may list one or more certificate policies that map to the EV policy. Multiple roots that follow the same policy may use the same policy IDs and different

RE: Google Trust Services roots

leevi.com<mailto:r...@sleevi.com>] Sent: Thursday, March 9, 2017 11:14 AM To: Gervase Markham <g...@mozilla.org<mailto:g...@mozilla.org>>; Richard Wang <rich...@wosign.com<mailto:rich...@wosign.com>>; mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla

Re: Google Trust Services roots

, March 9, 2017 11:14 AM > *To:* Gervase Markham <g...@mozilla.org>; Richard Wang <rich...@wosign.com>; > mozilla-dev-security-pol...@lists.mozilla.org > > > *Subject:* Re: Google Trust Services roots > > > > Hi Richard, > > > > That's not how Certific

RE: Google Trust Services roots

Richard Wang <rich...@wosign.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots Hi Richard, That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what

Re: Google Trust Services roots

ailto:dev-security-policy-bounces+richard= > wosign@lists.mozilla.org] On Behalf Of Gervase Markham via > dev-security-policy > Sent: Thursday, March 9, 2017 12:21 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Google Trust Services roots > > Having gaine

RE: Google Trust Services roots

] On Behalf Of Gervase Markham via dev-security-policy Sent: Thursday, March 9, 2017 12:21 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate

Re: Google Trust Services roots

> Outside of EV, can you articulate why (preferably in a dedicated thread) > There have been requests over the years from a variety of CAs for this. > Each time, they've been rejected. If there's new information at hand, or a > better understanding of the landscape since then, it would be

Re: Google Trust Services roots

On Wed, Mar 8, 2017 at 1:02 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There are some limitations relative to where this domain information is > used, for example > in the case of an EV certificate, if Google were to request Microsoft > use this

Re: Google Trust Services roots

> Jakob: An open question is how revocation and OCSP status for the > existing intermediaries issued by the acquired roots is handled. Google is responsible for producing CRLs for from these roots. We are also currently relying on the OCSP responder infrastructure of GlobalSign for this root

Re: Google Trust Services roots

> pzb: Policy Suggestion A) When transferring a root that is EV enabled, it > should be clearly stated whether the recipient of the root is also > receiving the EV policy OID(s). > Gerv: I agree with this suggestion; we should update > https://wiki.mozilla.org/CA:RootTransferPolicy , and

Re: Google Trust Services roots

> jacob: Could a reasonably condition be that decision authority, actual and > physical control for a root are not moved until proper root program > coordination has been done (an action which may occur after/before the > commercial conclusion of a transaction). From a business perspective >

Re: Google Trust Services roots

> pzb: According to the opinion letter: > "followed the CA key generation and security requirements in its: > Google Internet Authority G2 CPS v1.4" (hyperlink omitted) > According to that CPS, "Key Pairs for the Google Internet Authority > are generated and installed in accordance with the

Re: Google Trust Services roots

On 08/03/2017 16:54, Gervase Markham wrote: On 08/03/17 03:54, Peter Kurrasch wrote: - Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself. Yes. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products

Re: Google Trust Services roots

Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions. Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan,

Re: Google Trust Services roots

On 08/03/17 03:54, Peter Kurrasch wrote: > - Google has acquired 2 root certificates from GMO GlobalSign but not > the ‎company itself. Yes. > GMO GlobalSign will continue to own other roots and > will use only those other roots for the various products and services > they choose to offer going

Re: Google Trust Services roots

Im trying to keep score here but am having difficulties. Can someone confirm if the following statements are correct:- Google has acquired 2 root certificates from GMO GlobalSign but not the ‎company itself. GMO GlobalSign will continue to own other roots and will use only those other roots

Re: Google Trust Services roots

On 07/03/2017 18:29, Ryan Hurst wrote: pzb: I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. Again, sorry for the delay in responding, I will be more prompt moving forward. pzb: This

Re: Google Trust Services roots

> pzb: I appreciate you finally sending responses. I hope you appreciate > that they are clearly not adequate, in my opinion. Please see the > comments inline. Again, sorry for the delay in responding, I will be more prompt moving forward. > pzb: This does not resolve the concern. The BRs

Re: Google Trust Services roots

One more question, in addition to the ones in my prior response: On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > rmh: I just attached two opinion letters from our auditors, I had previously > provided these to the root programs directly but it took some time to get >

Re: Google Trust Services roots

Ryan, I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > First, let me apologize for the delay in my response, I have had a

Re: Google Trust Services roots

> Gerv: Which EV OID are you referring to, precisely? I was referring to the GlobalSign EV Certificate Policy OID (1.3.6.1.4.1.4146.1.1) but more concretely I meant any and all EV related OIDs, including the CAB Forum OID of 2.23.140.1.1. > Gerv: Just to be clear: GlobalSign continues to

Re: Google Trust Services roots

[Trying to resend without the quoted email to get through the spam filter] First, let me apologize for the delay in my response, I have had a draft of this letter in my inbox for a while and have just been unable to get back to it and finish it due to scheduling conflicts. I promise to address

Re: Google Trust Services roots

Ryan H, On 23/02/17 04:40, Peter Bowen wrote: > Both Gerv and I posted follow up questions almost two weeks ago. I > know you have been busy with CT days. When do you expect to have > answers available? Ping? :-) Gerv ___ dev-security-policy

Re: Google Trust Services roots

Ryan, Both Gerv and I posted follow up questions almost two weeks ago. I know you have been busy with CT days. When do you expect to have answers available? Thanks, Peter On Fri, Feb 10, 2017 at 2:01 AM, Gervase Markham via dev-security-policy wrote: >

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On Mon, Feb 13, 2017 at 4:14 AM, Gervase Markham via dev-security-policy wrote: > On 10/02/17 12:40, Inigo Barreira wrote: >> I see many "should" in this link. Basically those indicating "should notify >> Mozilla" and "should follow the physical relocation

RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

=startcomca@lists.mozilla.org] On Behalf Of Gervase Markham via dev-security-policy Sent: lunes, 13 de febrero de 2017 13:15 To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots) Hi Inigo. On 10/02/17 12:40

Re: Google Trust Services roots

On Fri, Feb 10, 2017 at 8:00 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am trying to say that I use the word "issue" as the weakest category, > orders of magnitude less serious than an absolute cause for rejection. And I'm trying to suggest that

Re: Google Trust Services roots

On 10/02/2017 16:34, Ryan Sleevi wrote: On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: For clarity, I was pointing out that GTS seems to have chosen a method likely to fail if an when actually needed, due to the typical

Re: Google Trust Services roots

On Thu, Feb 9, 2017 at 11:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > For clarity, I was pointing out that GTS seems to have chosen a method > likely to fail if an when actually needed, due to the typical dynamics > of large human organizations.

RE: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

gn.com>; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots) On 10/02/17 06:15, Richard Wang wrote: > I think Mozilla should have a very clear policy for: > (1) If a company that not a public trusted CA acquired

Re: Google Trust Services roots

Hi Ryan, On 09/02/17 19:55, Ryan Hurst wrote: > - The EV OID associated with this permission is associated with GlobalSign > and not Google and, Which EV OID are you referring to, precisely? > - GlobalSign is active member in good standing with the respective root > programs and, > - Google

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On 10/02/17 05:10, Peter Bowen wrote: > On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via >> A) The date Google took control of the GlobalSign roots >> B) The date Google publicly announced GTS >> >> you will see there's quite a big delta. If you assume Google told >> Mozilla about event A)

Re: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

On 10/02/17 06:15, Richard Wang wrote: > I think Mozilla should have a very clear policy for: > (1) If a company that not a public trusted CA acquired a trusted root key, > what the company must do? > (2) If a company is a public trusted CA that acquired a trusted root key, > what the company

Re: Google Trust Services roots

On 10/02/2017 05:42, Ryan Sleevi wrote: On Thu, Feb 9, 2017 at 3:39 PM, Jakob Bohm via dev-security-policy > wrote: Additional issue #2: The information at https://pki.goog/ about how to report

  1   2   >