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
dev-security-policy ;
> mozilla-dev-security-pol...@lists.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
e: 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 not aware o
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
(Renaming the thread to fork this particular discussion from any others on this transaction.)You raise a fair point, Ryan: I'm not well versed in how Let's Encrypt went about establishing their roots. I thought I
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, an
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 correctly
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 tha
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).
_
On 2017-03-23 16:39, Ryan Sleevi wrote:
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 ro
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 Let'
ryone pause.
Original Message
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 t
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
actio
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
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 Servic
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 complete takeover. None are
> cases where
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 warr
t; Cc: MozPol
> Subject: 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 e
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 i
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 happened many times in the past, root certs ha
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 cop
> 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 root
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 los
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
regar
;
> Richard
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Friday, March 10, 2017 2:16 PM
> To: Richard Wang
> Cc: Ryan Sleevi ; Gervase Markham ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Google Trust Services roots
al Message-
From: Peter Bowen [mailto:pzbo...@gmail.com]
Sent: Friday, March 10, 2017 2:16 PM
To: Richard Wang
Cc: Ryan Sleevi ; Gervase Markham ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots
On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote:
> Why we
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.
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 GlobalSign also use this EV OI
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
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). Fr
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 we can issue WoSign EV SSL cert using th
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
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 M
>
>
> Best Regards,
>
> Richard
>
> -Original Message-
> From: Peter Bowen [mailto:pzbo...@gmail.com]
> Sent: Thursday, March 9, 2017 1:11 PM
> To: Richard Wang
> Cc: Ryan Sleevi ; Gervase Markham ;
> mozilla-dev-security-pol...@lists.mozilla.org
> Subje
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
On 08/03/17 17:43, Ryan Hurst wrote:
>> Gerv: We do require this, but not publicly. I note and recognise Ryan's
>> concern about requiring advance disclosure of private deals. I could see
>> a requirement that a transferred root was not allowed to issue anything
>> until the appropriate paperwor
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. The
:pzbo...@gmail.com]
Sent: Thursday, March 9, 2017 1:11 PM
To: Richard Wang
Cc: Ryan Sleevi ; Gervase Markham ;
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots
Richard,
I'm afraid a few things are confused here.
First, a single CA Operator may have multiple ro
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
ot by Symantec.
Best Regards,
Richard
From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, March 9, 2017 12:21 PM
To: Gervase Markham ; Richard Wang ; Ryan
Sleevi ; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots
Well, you still said the
CA is full acquired.
>
> 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.
>
> Best Regards,
>
> Richard
>
> -Orig
-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
you describe.
Because of this
essage-
> From: dev-security-policy [mailto: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 Tru
d=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 gained a good understanding of Peter and Ryan's positions, I think
> 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 good
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 capa
> 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 bu
> 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 event
Gerv has already responded and while his response is correct I have a little
more detail I can share, see bellow.
> Peter Kurrash: I'm trying to keep score here but am having difficulties. Can
> someone confirm if
> the following statements are correct:
> - Google has acquired 2 root certifica
> 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
> t
> 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 contra
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 an
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,
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
Previous attempt had a major formatting snafu. Resending.
I'm 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
fo
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 do
> 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
On 07/03/17 03:14, Ryan Hurst wrote:
>> Gerv: Just to be clear: GlobalSign continues to operate at least one subCA
>> under a root which Google has purchased, and that root is EV-enabled,
>> and the sub-CA continues to do EV issuance (and is audited as such) but
>> the root is no longer EV audit
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 all
other questions in a more prompt manner.
> pzb: Mozilla recognizes 2.23.14
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
> permission to release the
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 draft of
> this lett
> 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 opera
[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 all
1 - 100 of 127 matches
Mail list logo
