Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

Sure, happy to take a look. I think Ryan H. makes some good points and I'm not 
entirely opposed to acquisitions or transfers. My standpoint is that when a 
transfer is to take place, can we be sure that the right things do happen 
instead of leaving things to chance? It's the age old 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: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/compare/issue-57

Would you be kind enough to review that and see if it addresses your
points and, if not, suggest how it might change and why?

I can see the value of a "definition of intention" and the choosing of a
category, as long as we are careful to make sure the categories do not
preclude operations that we would like to see occur. As Ryan Hurst
notes, there is potentially significant value to the ecosystem in root
transfers.

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

Re: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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/compare/issue-57

Would you be kind enough to review that and see if it addresses your
points and, if not, suggest how it might change and why?

I can see the value of a "definition of intention" and the choosing of a
category, as long as we are careful to make sure the categories do not
preclude operations that we would like to see occur. As Ryan Hurst
notes, there is potentially significant value to the ecosystem in root
transfers.

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

Re: Criticism of Google Re: Google Trust Services roots

[admin--- via dev-security-policy]

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 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 public attestation must be given as to the intended
> >>> management of the root upon completion of the transfer. "Intention" must
> >>> be one of the following:
> >>>
> >>> A) The purchaser has been in compliance with Mozilla policies for more
> >>> than 12 months and will continue to administer (operate? manage?) the
> >>> root in accordance with those policies.
> >>>
> >>> B) The purchaser has not been in compliance with Mozilla policies for
> >>> more than 12 months but will ‎do so before the transfer takes place. The
> >>> purchaser will then continue to administer/operate/manage the root in
> >>> accordance with Mozilla policies.
> >>>
> >>> How about:
> >>
> >> B2) The purchaser is not part of the Mozilla root program and has not
> >> been so in the recent past, but intends to continue the program
> >> membership held by the seller.  The purchaser intends to complete
> >> approval negotiations with the Mozilla root program before the transfer
> >> takes place.  The purchaser intends to retain most of the expertise,
> >> personnel, equipment etc. involved in the operation of the CA, as will
> >> be detailed during such negotiations.
> >>
> >> This, or some other wording, would be for a complete purchase of the
> >> business rather than a merge into an existing CA, similar to what
> >> happened when Symantec purchased Verisign's original CA business years
> >> ago, or (on a much smaller scale) when Nets purchased the TDC's CA
> >> business unit and renamed it as DanID.
> >>
> >
> > Why is that desirable? If anything, such acquisitions seem to be more
> > harmful than helpful to the CA ecosystem. That is, why _wouldn't_ a merge
> > be useful/desirable? What problems are you attempting to solve?
> >
> 
> 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 practically the whole operation with no initial
> changes besides a name change.
> 
> Another variant of this scenario is when a CA restructures its formal
> ownership structure, such as inserting or removing one or more levels
> of companies between the ultimate owners and the CA operations
> activity.  In many cases this would technically be an acquisition by a
> new company that isn't a CA itself (as the acquiring company would
> often be an empty shell).  One example would be the recent creation of
> GTS from part of Google Inc, since GTS was a new company with no past
> CA activity, while the acquired Google division had a past as a SubCA
> and a recently acquired root cert.
> 
> 
> 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

Jakob,

I would add that in cases where CA organizations are acquired outright and the 
staff and infrastructure are retained it is often only for a limited period of 
time. 

In other words, the acquisition takes place and then after some relatively 
short period of time we see the acquirer try to:
- align operations with other parts of the business,
- achieve cost savings,
- improve technology, performance, scale and disaster recovery ability.

These all tend to result in a reboot of "what was there" prior to the 
acquisition.

In these situations dislocated key staff often finds new roles at another CA or 
move on to non-ca related roles and sleep better ;)

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

Re: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 root cert contained in the trusted
store (either on an individual root basis or as part of a company
acquisition), a public attestation must be given as to the intended
management of the root upon completion of the transfer. "Intention" must
be one of the following:

A) The purchaser has been in compliance with Mozilla policies for more
than 12 months and will continue to administer (operate? manage?) the
root in accordance with those policies.

B) The purchaser has not been in compliance with Mozilla policies for
more than 12 months but will ‎do so before the transfer takes place. The
purchaser will then continue to administer/operate/manage the root in
accordance with Mozilla policies.

How about:


B2) The purchaser is not part of the Mozilla root program and has not
been so in the recent past, but intends to continue the program
membership held by the seller.  The purchaser intends to complete
approval negotiations with the Mozilla root program before the transfer
takes place.  The purchaser intends to retain most of the expertise,
personnel, equipment etc. involved in the operation of the CA, as will
be detailed during such negotiations.

This, or some other wording, would be for a complete purchase of the
business rather than a merge into an existing CA, similar to what
happened when Symantec purchased Verisign's original CA business years
ago, or (on a much smaller scale) when Nets purchased the TDC's CA
business unit and renamed it as DanID.



Why is that desirable? If anything, such acquisitions seem to be more
harmful than helpful to the CA ecosystem. That is, why _wouldn't_ a merge
be useful/desirable? What problems are you attempting to solve?



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 practically the whole operation with no initial
changes besides a name change.

Another variant of this scenario is when a CA restructures its formal
ownership structure, such as inserting or removing one or more levels
of companies between the ultimate owners and the CA operations
activity.  In many cases this would technically be an acquisition by a
new company that isn't a CA itself (as the acquiring company would
often be an empty shell).  One example would be the recent creation of
GTS from part of Google Inc, since GTS was a new company with no past
CA activity, while the acquired Google division had a past as a SubCA
and a recently acquired root cert.


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: Criticism of Google Re: Google Trust Services roots

[admin--- via dev-security-policy]

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 I 
> think it's reasonable ‎to make that accommodation.
> 
> 
> Using a word like "all" could be going too far but at the moment I'm not sure 
> how to strike a softer tone and still have something that is precise and 
> enforceable.
> 


 

Peter, 

Sending this from my personal account (my work laptop isn't handy) so will 
avoid discussions of anything related to GTS but I wanted to share my 
perspective as someone who has done built a number of CAs as well as 
participated in and led several transfers.

Your text seems to suggest that there is something inherently good about 
keeping the current staff and infrastructure. My experience has been that is 
not necessarily the case. 

To be clear I understand your position, though I disagree, that being you see 
there is a value in one organization having all the certificates that bear the 
same brand. I don't wish to re-debate that with you I just wanted to provide 
some examples of where partial transfers have provided the Internet at large 
value.

The most recent example of this is DigiCert's acquisition of the Verizon 
assets. In this case, the existing staff and business leadership demonstrated a 
continual inability to in accordance with the requirements. 

DigiCert stepped up to provide the needed adult supervision and paying for the 
right to do so.

While it is true that in this case the keys were being acquired by a member of 
a root program I think the most important things are that an organization with 
the means, skills, and vested interest stepped up.

There have also been several (largely) non-public examples where organizations 
with tons of means loss all interest and the keys were left in the hands of the 
unqualified and uninterested audits don't show this. 

Thankfully in both of these cases, I think largely the right thing happened. In 
one case the sr. leadership at the business ultimately decided to destroy the 
key material once they understood what it could be used for. 

Of the possible outcomes, I guess it is fair to say that the outcome here was 
not bad but I have spent a big chunk of my career trying to get the web 
encrypted and honestly I wish those keys could have been used by a new entrant, 
maybe Let's Encrypt to make SSL more ubiquitous. This last point material 
because it took Let's Encrypt nearly two years to find someone to cross them.

There are also other cases where CAs were carved up and sold off in bits and 
the only thing that remained was the keys, none of the staff or other 
infrastructure was used.   These keys also went to other CAs.

Anyway, I personally think Mozilla Root Program should be managed with a high 
order goal of increasing the use of encryption on the web. Root sales and 
transfers have been a big part of how we have gotten to over 50% of the web 
being encrypted and I suspect it will continue to be important.

In short, I think it would be a shame if we precluded these transfers and 
instead think it is best to focus on how to make sure the receiving 
organization proves they can continue to meet the criteria, or like in the case 
of DigiCert's acquisition, they have a plan to remedy the issues that have been 
identified.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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 trusted
>> store (either on an individual root basis or as part of a company
>> acquisition), a public attestation must be given as to the intended
>> management of the root upon completion of the transfer. "Intention" must
>> be one of the following:
>>
>> A) The purchaser has been in compliance with Mozilla policies for more
>> than 12 months and will continue to administer (operate? manage?) the
>> root in accordance with those policies.
>>
>> B) The purchaser has not been in compliance with Mozilla policies for
>> more than 12 months but will ‎do so before the transfer takes place. The
>> purchaser will then continue to administer/operate/manage the root in
>> accordance with Mozilla policies.
>>
>> How about:
>
> B2) The purchaser is not part of the Mozilla root program and has not
> been so in the recent past, but intends to continue the program
> membership held by the seller.  The purchaser intends to complete
> approval negotiations with the Mozilla root program before the transfer
> takes place.  The purchaser intends to retain most of the expertise,
> personnel, equipment etc. involved in the operation of the CA, as will
> be detailed during such negotiations.
>
> This, or some other wording, would be for a complete purchase of the
> business rather than a merge into an existing CA, similar to what
> happened when Symantec purchased Verisign's original CA business years
> ago, or (on a much smaller scale) when Nets purchased the TDC's CA
> business unit and renamed it as DanID.
>

Why is that desirable? If anything, such acquisitions seem to be more
harmful than helpful to the CA ecosystem. That is, why _wouldn't_ a merge
be useful/desirable? What problems are you attempting to solve?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  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 I think it's reasonable ‎to make that accommodation.Using a word like "all" could be going too far but at the moment I'm not sure how to strike a softer tone and still have something that is precise and enforceable.From: Jakob Bohm via dev-security-policySent: Monday, April 24, 2017 8:42 PM‎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 trusted> store (either on an individual root basis or as part of a company> acquisition), a public attestation must be given as to the intended> management of the root upon completion of the transfer. "Intention" must> be one of the following:>> A) The purchaser has been in compliance with Mozilla policies for more> than 12 months and will continue to administer (operate? manage?) the> root in accordance with those policies.>> B) The purchaser has not been in compliance with Mozilla policies for> more than 12 months but will ‎do so before the transfer takes place. The> purchaser will then continue to administer/operate/manage the root in> accordance with Mozilla policies.>How about:B2) The purchaser is not part of the Mozilla root program and has notbeen so in the recent past, but intends to continue the programmembership held by the seller.  The purchaser intends to completeapproval negotiations with the Mozilla root program before the transfertakes place.  The purchaser intends to retain most of the expertise, personnel, equipment etc. involved in the operation of the CA, as willbe detailed during such negotiations.This, or some other wording, would be for a complete purchase of thebusiness rather than a merge into an existing CA, similar to whathappened when Symantec purchased Verisign's original CA business yearsago, or (on a much smaller scale) when Nets purchased the TDC's CAbusiness unit and renamed it as DanID.> C) The purchaser does not intend to operate the root in accordance with> Mozilla policies. Mozilla should remove trust from the root upon> completion of the transfer.‎
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 trusted
store (either on an individual root basis or as part of a company
acquisition), a public attestation must be given as to the intended
management of the root upon completion of the transfer. "Intention" must
be one of the following:

A) The purchaser has been in compliance with Mozilla policies for more
than 12 months and will continue to administer (operate? manage?) the
root in accordance with those policies.

B) The purchaser has not been in compliance with Mozilla policies for
more than 12 months but will ‎do so before the transfer takes place. The
purchaser will then continue to administer/operate/manage the root in
accordance with Mozilla policies.


How about:

B2) The purchaser is not part of the Mozilla root program and has not
been so in the recent past, but intends to continue the program
membership held by the seller.  The purchaser intends to complete
approval negotiations with the Mozilla root program before the transfer
takes place.  The purchaser intends to retain most of the expertise, 
personnel, equipment etc. involved in the operation of the CA, as will

be detailed during such negotiations.

This, or some other wording, would be for a complete purchase of the
business rather than a merge into an existing CA, similar to what
happened when Symantec purchased Verisign's original CA business years
ago, or (on a much smaller scale) when Nets purchased the TDC's CA
business unit and renamed it as DanID.


C) The purchaser does not intend to operate the root in accordance with
Mozilla policies. Mozilla should remove trust from the root upon
completion of the transfer.


The wording of the above needs some polish and perhaps clarification.
The idea is that the purchaser must be able to demonstrate some level of
competence at running a CA--perhaps by first cutting their teeth as a
sub-CA? If a organization is "on probation" with Mozilla, I don't think
it makes sense to let them assume more control or responsibility for
cert issuance so there should be a mechanism to limit that.

I also think we should allow for the possibility that someone may
legitimately want to remove a cert from the Mozilla program. Given the
disruption that such a move 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 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 reconsider policy. But what we need is
a clearly-stated and compelling case that changing the way we think
about these things would have significant and realisable benefits, and
that any downsides are fairly enumerated and balanced against those gains.




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: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  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 public attestation must be given as to the intended management of the root upon completion of the transfer. "Intention" must be one of the following:A) The purchaser has been in compliance with Mozilla policies for more than 12 months and will continue to administer (operate? manage?) the root in accordance with those policies.B) The purchaser has not been in compliance with Mozilla policies for more than 12 months but will ‎do so before the transfer takes place. The purchaser will then continue to administer/operate/manage the root in accordance with Mozilla policies.C) The purchaser does not intend to operate the root in accordance with Mozilla policies. Mozilla should remove trust from the root upon completion of the transfer.The wording of the above needs some polish and perhaps clarification. The idea is that the purchaser must be able to demonstrate some level of competence at running a CA--perhaps by first cutting their teeth as a sub-CA? If a organization is "on probation" with Mozilla, I don't think it makes sense to let them assume more control or responsibility for cert issuance so there should be a mechanism to limit that.I also think we should allow for the possibility that someone may legitimately want to remove a cert from the Mozilla program. Given the disruption that such a move can cause, it is much better to learn that up front so that appropriate plans can be made.From: Gervase Markham via dev-security-policySent: Tuesday, April 11, 2017 11:36 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Re: Criticism of Google Re: Google Trust Services rootsOn 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 inthis group, there's not a lot of right now, given that this is not myonly job) there's always room to reconsider policy. But what we need isa clearly-stated and compelling case that changing the way we thinkabout these things would have significant and realisable benefits, andthat any downsides are fairly enumerated and balanced against those gains.Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 policy. But what we need is
a clearly-stated and compelling case that changing the way we think
about these things would have significant and realisable benefits, and
that any downsides are fairly enumerated and balanced against those gains.

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

Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  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 overlap, yes, but the general idea is to be more prescriptive in ownership than the current policy states.Is there room to expand Mozilla policy in regards to ownership issues?From: Gervase Markham via dev-security-policySent: Friday, April 7, 2017 4:50 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Gervase MarkhamSubject: Re: Criticism of Google Re: Google Trust Services rootsOn 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 arenot this prescriptive so CAs have more flexibility in how they go aboutthings, but I believe they preserve the same security invariants.In general, I suggest that if others have policy problems they see, youlet them draft the solutions? :-)‎Gerv___dev-security-policy mailing listdev-security-policy@lists.mozilla.orghttps://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: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 CAs have more flexibility in how they go about
things, but I believe they preserve the same security invariants.

In general, I suggest that if others have policy problems they see, you
let them draft the solutions? :-)

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

Re: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 root cert, certainly if they have other roots
and even if they don't, has an obligation to notify us of the sale.
Until they do, they remain responsible for it, and whatever Easy Pete
does with it.

So I expect us to find out about the sale.

> Once I take possession of the root cert's private key and related
> assets, what will limit the bad actions that I intend to take?

If you start issuing certs without the relevant paperwork in place,
you'll be out of the root programs in the next security update, and
you'll have spent a lot of money on a worthless asset.

> And it's true that I may be prohibited from issuing certs per Mozilla
> policy, but that actually is a bit of a squishy statement. For example,
> I'll still need to reissue certs to the existing customers ‎as their
> certs expire or if they need rekeying. 

Er, no. No issuance is permitted. If you need to issue immediately, then
you need to make sure the paperwork is in place and Mozilla is happy
before possession is transferred. Then you can have near-uninterrupted
service.

> Leaving behind this land of hypotheticals‎, it seems to me the policy as
> written is weaker than it ought to be. My own opinion is that only a
> member CA should be allowed to purchase a root cert (and assets),
> regardless if it's only one cert or the whole company.

As noted in previous emails, I see membership as a consequence of owning
an included root, rather than a separate thing. Clearly there are grey
areas on joining and leaving, but it doesn't make sense to me for a
company to be a member of the program if they don't own a root.

> If that's going
> too far, I think details are needed for what "regular business
> operations" are allowed during the period between acquisition of the
> root and acceptance into the Mozilla root program. 

None. The root transfer policy is very clear:

"No issuance whatsoever is permitted from a root certificate which has
changed ownership by being sold by one company to another (as opposed to
by acquisition of the owning company) until the receiving company has
demonstrated to Mozilla that they have all the appropriate audits,
CP/CPS documents and other systems in place. In addition, if the
receiving company is new to the Mozilla root program, there must also be
a public discussion regarding their admittance to the root program."
https://wiki.mozilla.org/CA:RootTransferPolicy

A wise company would do this all in advance of taking possession if they
wanted to issue immediately upon acquisition.

In the GS/GTS case, GS kept a sub-CA and kept issuing from it under
their own paperwork for customer continuity, which was fine.

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

Re: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 policy version):



Are you suggesting that the current policies that have been pointed out are
insufficient to address these cases?



Others have suggested they were insufficient, I just tried to come up
with a wording for what others said was lacking.

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: Criticism of Google Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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 suggesting that the current policies that have been pointed out are
insufficient to address these cases?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

ing behind this land of hypotheticals‎, it seems to me the policy as
written is weaker than it ought to be. My own opinion is that only a
member CA should be allowed to purchase a root cert (and assets),
regardless if it's only one cert or the whole company. If that's going
too far, I think details are needed for what "regular business
operations" are allowed during the period between acquisition of the
root and acceptance into the Mozilla root program. And should there be a
maximum time allowed to become such a member?


*From: *Nick Lamb via dev-security-policy
*Sent: *Tuesday, April 4, 2017 3:42 AM
*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 part of the root program is permitted to take
possession of the root cert private key and possibly the physical space,
key personnel, networking infrastructure, revocation systems, and
responsibility for subordinates without having first demonstrated any
competence at ‎running a CA organization.

This appears to me to simply be a fact, not a policy.

Suppose Honest Achmed's used car business has got him into serious debt.
Facing bankruptcy, Achmed is ordered by a court to immediately sell the
CA to another company Rich & Dick LLC, which has never historically
operated a CA but has made informal offers previously.

Now, Mozilla could say, OK, if that happens we'll immediately distrust
the root. But to what end? This massively inconveniences everybody,
there's no upside except that in the hypothetical scenario where Rick &
Dick are bad guys the end users are protected (eventually, as distrust
trickles out into the wild) from bad issuances they might make. But a
single such issuance would trigger that distrust already under the
policy as written and we have no reason to suppose they're bad guys.

On the other hand, if Rich & Dick are actually an honest outfit, the
policy as written lets them talk to Mozilla, make representations to
m.d.s.policy and get themselves trusted, leaving the existing Honest
Achmed subscribers with working certificates while everything is
straightened out, all Rich & Dick need to do is leave issuance switched
off while they reach an agreement.

Because continuing trust is always at Mozilla's discretion if something
truly egregious happened (e.g. Achmed's CA is declared bankrupt, a San
Francisco start-up with four employees and $6Bn of capital buys their
hardware for pennies on the dollar and announces it'll be issuing free
MITM SSL certificates starting Monday morning) then Mozilla is still
free to take extraordinary action and distrust Achmed's root immediately
without waiting until Monday morning.





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: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  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 bad behaviors might cause. It's in this latter category that I think the current policy falls short.Consider a situation in which I have a business called Easy Pete's Finishing School for Nigerian Princes. As the name might suggest, the nature of my business is to train potential scammer after potential scammer and set them free on the Internet to conduct whatever naughty 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.Once I take possession of the root cert's private key and related assets, what will limit the bad actions that I intend to take? For the sake of appearances (to look like a good-guy CA) I'll apply to join the Mozilla root program but I'm only really going through the motions--even in a year's time I don't really expect to be any closer to completing the necessary steps to become an actual member.And it's true that I may be prohibited from issuing certs per Mozilla policy, but that actually is a bit of a squishy statement. For example, I'll still need to reissue certs to the existing customers ‎as their certs expire or if they need rekeying. Perhaps I'll also get those clients to provide me with their private key so I may hold it for "safe keeping". Sure, it's a violation of the BR's but I'm not concerned with that. Besides, it will take some time until anyone even figures out what I'm doing.The other recourse in the current policy is to distrust the root cert altogether. Even then it will take time to take full effect and who knows, maybe I can still use the root for code signing? And then there are the existing customers who are left holding a soon-to-be worthless certLeaving behind this land of hypotheticals‎, it seems to me the policy as written is weaker than it ought to be. My own opinion is that only a member CA should be allowed to purchase a root cert (and assets), regardless if it's only one cert or the whole company. If that's going too far, I think details are needed for what "regular business operations" are allowed during the period between acquisition of the root and acceptance into the Mozilla root program. And should there be a maximum time allowed to become such a member?From: Nick Lamb via dev-security-policySent: Tuesday, April 4, 2017 3:42 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Nick LambSubject: Re: Criticism of Google Re: Google Trust Services rootsOn 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, networking infrastructure, revocation systems, and responsibility for subordinates without having first demonstrated any competence at ‎running a CA organization.This appears to me to simply be a fact, not a policy.Suppose Honest Achmed's used car business has got him into serious debt. Facing bankruptcy, Achmed is ordered by a court to immediately sell the CA to another company Rich & Dick LLC, which has never historically operated a CA but has made informal offers previously.Now, Mozilla could say, OK, if that happens we'll immediately distrust the root. But to what end? This massively inconveniences everybody, there's no upside except that in the hypothetical scenario where Rick & Dick are bad guys the end users are protected (eventually, as distrust trickles out into the wild) from bad issuances they might make. But a single such issuance would trigger that distrust already under the policy as written and we have no reason to suppose they're bad guys.On the other hand, if Rich & Dick are actually an honest outfit, the policy as written lets them talk to Mozilla, make representations to m.d.s.policy and get themselves trusted, leaving the existing Honest Achmed subscribers with working certificates while everything is straightened out, all Rich & Dick need to do is leave issuance switched off while they reach an 

Re: Criticism of Google Re: Google Trust Services roots

[Nick Lamb via dev-security-policy]

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, 
> networking infrastructure, revocation systems, and responsibility for 
> subordinates without having first demonstrated any competence at ‎running a 
> CA organization.

This appears to me to simply be a fact, not a policy.

Suppose Honest Achmed's used car business has got him into serious debt. Facing 
bankruptcy, Achmed is ordered by a court to immediately sell the CA to another 
company Rich & Dick LLC, which has never historically operated a CA but has 
made informal offers previously.

Now, Mozilla could say, OK, if that happens we'll immediately distrust the 
root. But to what end? This massively inconveniences everybody, there's no 
upside except that in the hypothetical scenario where Rick & Dick are bad guys 
the end users are protected (eventually, as distrust trickles out into the 
wild) from bad issuances they might make. But a single such issuance would 
trigger that distrust already under the policy as written and we have no reason 
to suppose they're bad guys.

On the other hand, if Rich & Dick are actually an honest outfit, the policy as 
written lets them talk to Mozilla, make representations to m.d.s.policy and get 
themselves trusted, leaving the existing Honest Achmed subscribers with working 
certificates while everything is straightened out, all Rich & Dick need to do 
is leave issuance switched off while they reach an agreement.

Because continuing trust is always at Mozilla's discretion if something truly 
egregious happened (e.g. Achmed's CA is declared bankrupt, a San Francisco 
start-up with four employees and $6Bn of capital buys their hardware for 
pennies on the dollar and announces it'll be issuing free MITM SSL certificates 
starting Monday morning) then Mozilla is still free to take extraordinary 
action and distrust Achmed's root immediately without waiting until Monday 
morning.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

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, networking 
infrastructure, revocation systems, and responsibility for subordinates without 
having first demonstrated any competence at ‎running a CA organization.

I think we need to beef up this section of the policy but if you'd prefer to 
discuss that at a later time (separate from the Google acquisition thread), 
that will work for me.


  Original Message  
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 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, will Mozilla
> require that whatever entity is trying to purchase the root must be
> fully admitted into the root program before the transfer takes
> place?

No. As currently worded, it has to take place before issuance is permitted.

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

Re: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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, will Mozilla
> require that whatever entity is trying to purchase the root must be
> fully admitted into the root program before the transfer takes
> place?

No. As currently worded, it has to take place before issuance is permitted.

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

Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

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, will Mozilla require that whatever entity is trying 
to purchase the root must be fully admitted into the root program before the 
transfer takes place?

Also, let me state that I did not intend to besmirch the names of either HARICA 
or WoSign and I appreciate their indulging my use of their names in what turned 
out to be a sloppy illustration. Based on my review of HARICA's CPS some months 
ago, I was left with the impression of them as a tightly-focused ‎organization 
that, by all appearances, is well-run. And that was the image I had mind and 
had hoped to convey in using their name. By mentioning WoSign I was really 
thinking of only the state of their reputation at the moment--and I think it's 
fair to say it's been tarnished? The reasons for WoSign being in the position 
they are in were totally irrelevant to what I had in mind.

So what was my point? In essence, I wanted to suggest that not every company 
seeking to purchase a root from another company will necessarily have good 
intentions and even if they do, their intentions might not be in the interest 
of the public good. I think it's important to at least acknowledge that 
possibility and try to have policies in place that encourage the good and limit 
the bad.

I don't know if people are on board with this notion or if some hypothetical 
scenarios are needed at this point? For now I'll just pause and let others 
either ask or comment away.


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Friday, 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? 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 the receiving company is new to the
>> Mozilla root program, there must also be a public discussion regarding
>> their admittance to the root program."
>>
>> Without completing the necessary steps, GalaxyTrust would not be admitted to
>> the root program.
> 
> I've modified the quoted text a little to try to make this example
> clearer, as I think the prior example conflated multiple things and
> used language that did not help clarify the situation.
> 
> Is the revised example accurate?

The revised example is accurate.

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: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 the receiving company is new to the
>> Mozilla root program, there must also be a public discussion regarding
>> their admittance to the root program."
>>
>> Without completing the necessary steps, GalaxyTrust would not be admitted to
>> the root program.
> 
> I've modified the quoted text a little to try to make this example
> clearer, as I think the prior example conflated multiple things and
> used language that did not help clarify the situation.
> 
> Is the revised example accurate?

The revised example is accurate.

Gerv

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

Re: Criticism of Google Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

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 say that Google isn't the first
>> but I'm not aware of any commentary or airing of opposing viewpoints
>> as to the suitability of this practice going forward.
>
> As noted, I have no interest in banning this practice because I think
> the ecosystem effects would be negative.
>
>> Has Mozilla received any notification that other companies ‎intend to
>> acquire individual roots from another CA?
>
> Not to my knowledge, but they may have been communicating with Kathleen.
>
>> Also, does Mozilla have any policies (requirements?) regarding
>> individual root acquisition?
>
> https://wiki.mozilla.org/CA:RootTransferPolicy
> and
> https://github.com/mozilla/pkipolicy/issues/57
>
>> 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 the receiving company is new to the
> Mozilla root program, there must also be a public discussion regarding
> their admittance to the root program."
>
> Without completing the necessary steps, GalaxyTrust would not be admitted to
> the root program.

I've modified the quoted text a little to try to make this example
clearer, as I think the prior example conflated multiple things and
used language that did not help clarify the situation.

Is the revised example accurate?

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

Re: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 opposing viewpoints
> as to the suitability of this practice going forward.

As noted, I have no interest in banning this practice because I think
the ecosystem effects would be negative.

> Has Mozilla received any notification that other companies ‎intend to
> acquire individual roots from another CA? 

Not to my knowledge, but they may have been communicating with Kathleen.

> Also, does Mozilla have any policies (requirements?) regarding
> individual root acquisition? 

https://wiki.mozilla.org/CA:RootTransferPolicy
and
https://github.com/mozilla/pkipolicy/issues/57

> For example, how frequently should roots
> be allowed to change hands? What would Mozilla's response be if
> WoSign were to say that because of the tarnishing of their own brand
> they are acquiring the HARICA root? 

From the above URL: "In addition, if the receiving company is new to the
Mozilla root program, there must also be a public discussion regarding
their admittance to the root program."

Without completing the necessary steps, WoSign would not be admitted to
the root program.

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

Re: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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-GlobalSign roots. So the chains would be basically the same whether
GS or GTS owned the parent root. So how does requiring them to do it by
cross-signing improve things? Requiring them to do it by cross-signing
just exposes them to business risk which they don't have if they
actually own the roots.


For example, when doing ordinary browsing with https on-by-default,
users rarely bother checking the certificate beyond "the browser says
it is not a MitM attack, good".  Except when visiting a high value
site, such as a government site to file a change in ownership of an
entire house (such sites DO exist).  Then it makes sense to click on
the certificate user interface and check that the supposed "Government
Land Ownership Registry of the Kingdom of X" site is verified by
someone that could reasonably be trusted to do so (i.e. not a national
CA of the republic of Y or the semi-internal CA of some private
megacorp).


This is what we have CAA and HPKP for.


Those only work for sites that are able to deploy those (there are
technical limitations blocking deployment on some systems).

They by no means replace due diligence in high risk situations.




With this recent transaction, the browser could show "GlobalSign" when
it should show "Google", two companies with very different security and
privacy reputations.


If Google were issuing from a Google-owned intermediate under a
GlobalSign-owned root, why would the browser show "Google"? I don't
understand how you see the chain differing in this situation.



I am (consistently) referring to situations where the user has reason
to navigate to the part of the UI that displays the full chain, not the
dubious tooltips displayed under the encryption icon.


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: Criticism of Google Re: Google Trust Services roots

[Richard Wang via dev-security-policy]

Qihoo 360 CSO Mr. Tan updated this in the recent CAB Forum meeting in USA : CEO 
of WoSign is NA, Richard Wang is the COO. 


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of urijah--- 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 trust and confidence in this community.

Wasn't a prerequisite for that process your stepping down as CEO of WoSign?



On Thursday, March 30, 2017 at 9:49:25 PM UTC-4, Richard Wang wrote:
> To be transparent, WoSign are NOT "acquiring the HARICA root" that we NEVER 
> contact HARICA, and we don't think our brand is "tarnishing", we are working 
> hard to try to regain the trust and confidence in this community.
> 
> 
> Best Regards,
> 
> Richard
> 
> -Original Message-
> From: dev-security-policy 
> [mailto:dev-security-policy-bounces+richard=wosign.com@lists.mozilla.o
> rg] On Behalf Of Peter Kurrasch via dev-security-policy
> Sent: Thursday, March 30, 2017 9:02 PM
> To: Gervase Markham via dev-security-policy <g...@mozilla.org>; 
> 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 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 opposing viewpoints as to the suitability of this 
> practice going forward.
> 
> Has Mozilla received any notification that other companies ‎intend to acquire 
> individual roots from another CA? I wouldn't ask Mozilla to violate any 
> non-disclosures but surely it's possible to let the community know if we 
> should expect more of this? Ryan H. implied as much in a previous post but I 
> wasn't sure where he was coming from on that.
> 
> Also, does Mozilla have any policies (requirements?) regarding individual 
> root acquisition? For example, how frequently should roots be allowed to 
> change hands? What would Mozilla's response be if WoSign were to say that 
> because of the tarnishing of their own brand they are acquiring the HARICA 
> root? What if Vladimir Putin were to make such a purchase? Any requirements 
> on companies notifying the public when the acquisition takes place?
> 
> Perhaps this is putting too much of a burden on Mozilla as a somewhat 
> protector 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
> 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 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 research." It doesn't 
> > seem right that Google be allowed to unilaterally impose that change 
> > on the global PKI without any discussion from the security community.
> 
> As others in this thread have pointed out, this is not a new thing. I 
> wouldn't say that Google is "imposing" this need.
> 
> 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

___
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: Criticism of Google Re: Google Trust Services roots

[Florian Weimer via dev-security-policy]

* 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 opposing viewpoints as to the
> suitability of this practice going forward.

I think most of the DNs in the Mozilla root store still do not reflect
reality.  The restrictions on certificate naming do not apply to the
CAs themselves.  This is due to the way PKIX validation works.
Correcting the DNs would break the certificate chains.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Criticism of Google Re: Google Trust Services roots

[Richard Wang via dev-security-policy]

To be transparent, WoSign are NOT "acquiring the HARICA root" that we NEVER 
contact HARICA, and we don't think our brand is "tarnishing", we are working 
hard to try to regain the trust and confidence in this community.


Best Regards,

Richard

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On 
Behalf Of Peter Kurrasch via dev-security-policy
Sent: Thursday, March 30, 2017 9:02 PM
To: Gervase Markham via dev-security-policy <g...@mozilla.org>; 
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 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 opposing viewpoints as to the suitability of this practice going 
forward.

Has Mozilla received any notification that other companies ‎intend to acquire 
individual roots from another CA? I wouldn't ask Mozilla to violate any 
non-disclosures but surely it's possible to let the community know if we should 
expect more of this? Ryan H. implied as much in a previous post but I wasn't 
sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root 
acquisition? For example, how frequently should roots be allowed to change 
hands? What would Mozilla's response be if WoSign were to say that because of 
the tarnishing of their own brand they are acquiring the HARICA root? What if 
Vladimir Putin were to make such a purchase? Any requirements on companies 
notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector 
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
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 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 research." It doesn't seem right
> that Google be allowed to unilaterally impose that change on the
> global PKI without any discussion from the security community.

As others in this thread have pointed out, this is not a new thing. I wouldn't 
say that Google is "imposing" this need.

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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 opposing viewpoints as to the suitability of this practice going 
forward.

Has Mozilla received any notification that other companies ‎intend to acquire 
individual roots from another CA? I wouldn't ask Mozilla to violate any 
non-disclosures but surely it's possible to let the community know if we should 
expect more of this? Ryan H. implied as much in a previous post but I wasn't 
sure where he was coming from on that.

Also, does Mozilla have any policies (requirements?) regarding individual root 
acquisition? For example, how frequently should roots be allowed to change 
hands? What would Mozilla's response be if WoSign were to say that because of 
the tarnishing of their own brand they are acquiring the HARICA root? What if 
Vladimir Putin were to make such a purchase? Any requirements on companies 
notifying the public when the acquisition takes place?

Perhaps this is putting too much of a burden on Mozilla as a somewhat protector 
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
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 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 research." It doesn't
> seem right that Google be allowed to unilaterally impose that change
> on the global PKI without any discussion from the security
> community.

As others in this thread have pointed out, this is not a new thing. I
wouldn't say that Google is "imposing" this need.

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: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 the same whether
GS or GTS owned the parent root. So how does requiring them to do it by
cross-signing improve things? Requiring them to do it by cross-signing
just exposes them to business risk which they don't have if they
actually own the roots.

> For example, when doing ordinary browsing with https on-by-default,
> users rarely bother checking the certificate beyond "the browser says
> it is not a MitM attack, good".  Except when visiting a high value
> site, such as a government site to file a change in ownership of an
> entire house (such sites DO exist).  Then it makes sense to click on
> the certificate user interface and check that the supposed "Government
> Land Ownership Registry of the Kingdom of X" site is verified by
> someone that could reasonably be trusted to do so (i.e. not a national
> CA of the republic of Y or the semi-internal CA of some private
> megacorp).

This is what we have CAA and HPKP for.

> With this recent transaction, the browser could show "GlobalSign" when
> it should show "Google", two companies with very different security and
> privacy reputations.  

If Google were issuing from a Google-owned intermediate under a
GlobalSign-owned root, why would the browser show "Google"? I don't
understand how you see the chain differing in this situation.

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

Re: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 expect!), their users would all
get cert warnings with the Mozilla trust DB!

Even as someone pretty well versed in the WebPKI, I don't think my
expectations about who the CA for a given site should be really are
actionable.

It seems to be that certs are for computers to consume, and only
incidentally for humans to read (*hit tip* to SICP).

Alex

PS: To expand a bit on this thought experiment, if I were to enumerate all
CAs over a bunch of websites, the only cases I can think of where human
intuition has a defensible conclusion, is that certain CAs _shouldn't_ sign
things, notably CAs intended only for limited usage (e.g. a Government CA
designed for signing government website certs). These cases are, I think,
much better handled by Name Constraints (or some other technical
constraint), and that's an entirely different subject altogether.



Which was precisely my point, except that to date, the few implemented
forms of name constraints seem unable to capture the real world
considerations that should exclude most CAs from a considerable part of
the Web name space:

- Country-specific CAs want to sign certificates for GTLD sites (.com,
 .net, .org, .name etc.) that are actually under that country
 jurisdiction.
- Cloud-hosting provider CAs (Microsoft, Google, Amazon) want to sign
 certificates for anything they host, regardless of TLD or country.

- Neither are appropriate CAs for any sites not under their
 administration/jurisdiction.

The special case of the old US Gov CA getting thrown out of Mozilla and
some other browsers is something of an outlier, but even then, it would
be odd if a US Gov site had a certificate from the Taiwan GRCA or the
Spanish guild of public notaries.

So until relevant technical constraints are actually ubiquitous in the
WebPKI, manual checking remains relevant.


On Wed, Mar 29, 2017 at 2:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:


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
hardly think this redefinition of trust anchor improves the state of the
global PKI and I sincerely hope it does not become a trend.



The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+
years.



That goal would be equally (in fact better) served by new market
entrants getting cross-signed by incumbents, like Let's encrypt did.

Problem is that whenever viewing a full cert chain in a typical browser
etc. that has reference "trusted" copies of all the incumbents,
disassociating the names in root CA and SubCA certificates from reality
creates misinformation in a context displayed as being "fully
validated" to known traceable roots by the Browser/etc.

For example, when doing ordinary browsing with https on-by-default,
users rarely bother checking the certificate beyond "the browser says
it is not a MitM attack, good".  Except when visiting a high value
site, such as a government site to file a change in ownership of an
entire house (such sites DO exist).  Then it makes sense to click on
the certificate user interface and check that the supposed "Government
Land Ownership Registry of the Kingdom of X" site is verified by
someone that could reasonably be trusted to do so (i.e. not a national
CA of the republic of Y or the semi-internal CA of some private
megacorp).

With this recent transaction, the browser could show "GlobalSign" when
it should show "Google", two companies with very different security and
privacy reputations.  One would expect a blogger/blogblog domain to
have a Google-issued certificate while one would expect the opposite of
anything hosted outside the Alphabet group.




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: Criticism of Google Re: Google Trust Services roots

[Alex Gaynor via dev-security-policy]

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 warnings with the Mozilla trust DB!

Even as someone pretty well versed in the WebPKI, I don't think my
expectations about who the CA for a given site should be really are
actionable.

It seems to be that certs are for computers to consume, and only
incidentally for humans to read (*hit tip* to SICP).

Alex

PS: To expand a bit on this thought experiment, if I were to enumerate all
CAs over a bunch of websites, the only cases I can think of where human
intuition has a defensible conclusion, is that certain CAs _shouldn't_ sign
things, notably CAs intended only for limited usage (e.g. a Government CA
designed for signing government website certs). These cases are, I think,
much better handled by Name Constraints (or some other technical
constraint), and that's an entirely different subject altogether.

On Wed, Mar 29, 2017 at 2:42 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> 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
>>> hardly think this redefinition of trust anchor improves the state of the
>>> global PKI and I sincerely hope it does not become a trend.
>>>
>>
>> The trouble is, you want to optimise the system for people who make
>> individual personal trust decisions about individual roots. We would
>> like to optimise it for ubiquitous minimum-DV encryption, which requires
>> mechanisms permitting new market entrants on a timescale less than 5+
>> years.
>>
>>
> That goal would be equally (in fact better) served by new market
> entrants getting cross-signed by incumbents, like Let's encrypt did.
>
> Problem is that whenever viewing a full cert chain in a typical browser
> etc. that has reference "trusted" copies of all the incumbents,
> disassociating the names in root CA and SubCA certificates from reality
> creates misinformation in a context displayed as being "fully
> validated" to known traceable roots by the Browser/etc.
>
> For example, when doing ordinary browsing with https on-by-default,
> users rarely bother checking the certificate beyond "the browser says
> it is not a MitM attack, good".  Except when visiting a high value
> site, such as a government site to file a change in ownership of an
> entire house (such sites DO exist).  Then it makes sense to click on
> the certificate user interface and check that the supposed "Government
> Land Ownership Registry of the Kingdom of X" site is verified by
> someone that could reasonably be trusted to do so (i.e. not a national
> CA of the republic of Y or the semi-internal CA of some private
> megacorp).
>
> With this recent transaction, the browser could show "GlobalSign" when
> it should show "Google", two companies with very different security and
> privacy reputations.  One would expect a blogger/blogblog domain to
> have a Google-issued certificate while one would expect the opposite of
> anything hosted outside the Alphabet group.
>
>
>
>
> 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
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Google Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

I'm not so sure I want to optimize the system in that way, but I am concerned 
about the (un)intended consequences of rapidly changing root ownership on the 
global PKI.

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 research." It doesn't seem right that Google be allowed to 
unilaterally impose that change on the global PKI without any discussion from 
the security community.

But you bring up a good point that there seems to be much interest of late to 
speed up the cycle times for various activities within the global PKI but it's 
not entirely clear to me what's driving it. My impression is that Google was 
keen to become a CA in their own right as quickly as possible, so is this 
interest based on what Google wants? Or is there a Mozilla mandate that I 
haven't seen (or someone else's mandate?)?


  Original Message  
From: Gervase Markham via dev-security-policy
Sent: Wednesday, March 29, 2017 9:48 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 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 anchor improves the state of the
> global PKI and I sincerely hope it does not become a trend.

The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+ years.

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: Criticism of Google Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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
hardly think this redefinition of trust anchor improves the state of the
global PKI and I sincerely hope it does not become a trend.


The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+ years.



That goal would be equally (in fact better) served by new market
entrants getting cross-signed by incumbents, like Let's encrypt did.

Problem is that whenever viewing a full cert chain in a typical browser
etc. that has reference "trusted" copies of all the incumbents,
disassociating the names in root CA and SubCA certificates from reality
creates misinformation in a context displayed as being "fully
validated" to known traceable roots by the Browser/etc.

For example, when doing ordinary browsing with https on-by-default,
users rarely bother checking the certificate beyond "the browser says
it is not a MitM attack, good".  Except when visiting a high value
site, such as a government site to file a change in ownership of an
entire house (such sites DO exist).  Then it makes sense to click on
the certificate user interface and check that the supposed "Government
Land Ownership Registry of the Kingdom of X" site is verified by
someone that could reasonably be trusted to do so (i.e. not a national
CA of the republic of Y or the semi-internal CA of some private
megacorp).

With this recent transaction, the browser could show "GlobalSign" when
it should show "Google", two companies with very different security and
privacy reputations.  One would expect a blogger/blogblog domain to
have a Google-issued certificate while one would expect the opposite of
anything hosted outside the Alphabet group.




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: Criticism of Google Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 anchor improves the state of the
> global PKI and I sincerely hope it does not become a trend.

The trouble is, you want to optimise the system for people who make
individual personal trust decisions about individual roots. We would
like to optimise it for ubiquitous minimum-DV encryption, which requires
mechanisms permitting new market entrants on a timescale less than 5+ years.

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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, and does it therefore become the
> responsibility of the new owner of the roots?

The latter - Mozilla would hold Google ultimately responsible for any
revocation-related requirements in these hierarchies. (They may, of
course, contract GlobalSign to manage some subset of it, but that's not
our business).

Gerv

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

Re: Google Trust Services roots

[okaphone.elektronika--- via dev-security-policy]

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.) Or does revocation also require 
signing, and does it therefore become the responsibility of the new owner of 
the roots?
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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 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).
> ___
> 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: Google Trust Services roots

[Roland Fantasia via dev-security-policy]

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).
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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's Encrypt did? All I could gather from the Google
> security blog is that they really want to be a root CA and to do it in a
> hurry. ‎Why the need to do it quickly, especially given the risks (attack
> surface)?


Clarification: I'm not speaking on behalf of Google

I think this demonstrates a lack of understanding of what Let's Encrypt
did. Let's Encrypt obtained a cross-signed certificate (from IdenTrust),
which is "purchasing" a signature for their key. This is one approach.
Purchasing a pre-existing signature (and key) is another. They are
functionally equivalent.

So what Google has done is what is what Let's Encrypt did.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

‎So this is the third of my 3 sets of criticisms regarding the acquisition of 
the GlobalSign roots by Google Trust Services. I apologize for the significant 
delay between the first 2 sets and this one. Hopefully people in the forum 
still feel this discussion relevant going forward even though the matter is 
considered resolved.

Several of the comments I made regarding GlobalSign also apply to Google, 
especially the intermingling of the two brands. The implications of the 
confusion and uncertainty leading to an exploitable attack are just as 
applicable to Google as they are to GlobalSign. However, when you consider the 
stature of Google both on the Internet and in consumer products, the 
ramifications are more significant. Or, if you will, the attack surface is 
quite different than if GlobalSign were to purchase a root from, say, Symantec.

I do fault Google for what I consider to be inadequate communication of the 
acquisition. This is not to say there's been no communication, just that I 
don't think it's enough, especially if you are not a CABF participant or don't 
keep up with Internet security news generally. Why not publish a message last 
October that regular folks on the Internet can understand? Why wait 3 months?‎ 
Why expect people to dig through a CPS to find what should be readily available 
information? 

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's Encrypt did? All I could gather from the Google security 
blog is that they really want to be a root CA and to do it in a hurry. ‎Why the 
need to do it quickly, especially given the risks (attack surface)?

I also would like to know what the plan or expectation is regarding formal 
separation between the infrastructures of Google and GlobalSign. The overlap is 
an understandable necessity during the transition but nonetheless presents 
another opportunity for improper access, loss (leaking) of data, and perhaps 
other nefarious activities. And, does Google have a published policy regarding 
the information collected, stored, and analyzed when people access the CRL and 
OCSP distribution nodes?

I do want to say I appreciate that someone with Ryan H.'s level of experience 
is involved in a transaction like this. There are undoubtedly many details to 
address that ensure a secure and proper transfer. I hope that someone on the 
GlobalSign side was equally experienced? The next time someone wants to 
purchase existing roots, the people involved might not have that same level of 
experience, and that should give everyone 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 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 but are
In the process of migrating that inhouse.

> Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) 
> URLs 
> listed in the CRL URL extensions in the GlobalSign operated non-expired 
> intermediaries? 

At this time Google produces CRLs and works with GlobalSign to publish those 
CRLs.

> Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for 
> the 
> acquired roots. 

This level of detail is not typically included in a CPS, for example, a service 
may change 
Which internet service provider or CDN service they use and not need update 
their CP/CPS.


> Jakob: Any relying party seeing the existing root in a chain would see the 
> name GlobalSign in the Issuer DN and naturally look to GlobalSign's 
> website and CP/CPS for additional information in trying to decide if 
> the chain should be trusted. 

The GlobalSign CPS indicates that the R2 and R4 are no longer under their 
control.

Additionally given the long term nature of CA keys, it is common for the DN not 
to accurately 
represent the organization that controls it. As I mentioned in an earlier 
response in the 90’s I 
created roots for a company called Valicert that has changed hands several 
times, additionally
Verisign, now Symantec in this context has a long history of acquiring CAs and 
as such they 
have CA certificates with many different names within them.

> Jakob: A relying party might assume, without detailed checks, that these 
> roots 
> are operated exclusively by GlobalSign in accordance with GlobalSign's 
> good reputation. 

As the former CTO of GlobalSign I love hearing about their good reputation ;)

However I would say the CP/CPS is the authoritative document here and since
GMO GlobalSign CP/CPS clea

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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
action against GTS based on what has been discovered and discussed. It
doesn't mean people can't continue to make suggestions about
improvements to our process, citing this situation.

Gerv

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 should update
> https://wiki.mozilla.org/CA:RootTransferPolicy

Now done: "When transferring ownership of a root that is EV-enabled, it
should be clearly stated whether the recipient of the root is also
receiving the (right to use the) EV policy OID(s) and, if so, it should
be confirmed that they have or will get the relevant audits before
issuing EV certs."

> Again, would this be covered by a requirement that no issuance was
> permitted from a transferred root until all the paperwork was in place,
> including appropriately-scoped audits? This might lead to a PITRA, but
> would not have to.

Now done: "No issuance whatsoever is permitted from a root certificate
which has changed ownership by being sold by one company to another (as
opposed to by acquisition of the owning company) until the receiving
company has demonstrated to Mozilla that they have all the appropriate
audits, CP/CPS documents and other systems in place. In addition, if the
receiving company is new to the Mozilla root program, there must also be
a public discussion regarding their admittance to the root program."

https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 Services?
> 
> This would scope EV permissions more closely to the audits, and so
> prevent Google from accidentally or intentionally issuing EV which was
> shown as such in Firefox, without having an EV audit.

Hearing no dissent, filed:
https://bugzilla.mozilla.org/show_bug.cgi?id=1347882

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

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

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 the name in the certificate is a still operating CA
> operator, but the root is actually operated by a different entity
> entirely.

There are a number of examples, but many of them are older and have
been removed from trust stores (usually due to key size):

Certplus - operated by both Docusign and Wosign
Starfield - Go Daddy and Amazon
TC TrustCenter - Symantec and Deutscher Sparkassen Verlag GmbH
(S-TRUST, DSV-Gruppe)
USERTRUST UTN-USERFirst - Symantec and Comodo
ValiCert - Go Daddy, SECOM, and RSA

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

Criticism of GMO GlobalSign Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

  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 warrants public discussion. In previous comments I've made, I've expressed disapproval at the fact that there is no mention of the transfer on GlobalSign's website. I did not find it under News‎ and Events nor under the SSL sales pages nor under the Resources page. I also could find no information about the existence of different roots that GlobalSign has and their intended use cases.The search result that Ryan H. mentions below is in fact a curious situation. A direct link to the CPS is listed, sure, but if you go to the ".../resources" page directly there is no mention of the CPS. I would assume that at some point a subscriber is required to accept the terms of the CPS and is then presented with an opportunity to obtain the actu‎al document, but what about the relying parties? Are relying parties allowed to obtain the document but only if they use a search engine to find it? Are we to expect that search engines will always and only return the correct version for the specific root in which I'm interested?To be fair, I don't know that any of this constitutes a violation of any BR requirement or Mozilla policy--I assume not.‎ I also assume that GlobalSign is not the only offender in this regard. Still, I expect better than this from any root CA participant; surely a CA can give me something rather than leave me with nothing?All that said, it is not even what causes me the most concern, which is the intermingling of the GlobalSign and ‎Google brands. Like it or not, there will always be questions like "Is this GlobalSign or is this Google?" and this creates a risk not only to GlobalSign but also the Internet community. (There is a risk to Google as well but I'll address that in a separate thread.)The risk is a result of the confusion and uncertainty that are introduced by the transfer of these 2 roots.‎ Consider that right now I could launch a phishing campaign targeting GlobalSign subscribers with a message along the lines of "Did you know that GlobalSign has sold your certificate to Google? Click here to learn what you can do to protect your website." Should the person click on a link I might put the person on a fake login screen or a malware distribution point or engage in any other nefarious act of my choosing. For that matter I might try to sell the person my own certificate service: "Leave GlobalSign and Google behind! Protect the privacy of your website visitors and buy my service instead!"The point here is that accuracy in my message is not needed. Instead, I can exploit the confusion and uncertainty (or, if you prefer, FUD) which can lead to damage to GlobalSign's reputation and possible loss of business. Conceivably this can also impact the global PKI if I'm able to gain unauthorized access to a subscriber's account and have certificates issued for my nefarious websites.All of this to say that it actually is important that GlobalSign put messaging on their website and generally be proactive in limiting the chances for misinformation, confusion, and so forth to propagate across the Internet. The last thing I'll mention is that I have questions as to whether GlobalSign has violated either their own CPS or privacy policy when it comes to their subscribers‎. Admittedly I haven't had a chance to review either document so it's quite possible I'm misinformed and I hope someone will correct me as appropriate.But the basic reasoning goes that there are some people who don't like Google and perhaps have chosen to use GlobalSign because they are not Google. Personally I think GlobalSign has an obligation to notify their subscribers with something to the effect that "after a certain date we will be sharing your payment information, certificate history, domain ownership, login activity to our Web portal, etc. with Google." However, if there are statements in either the doc that have been violated, that is a more serious issue.The exact information being shared with (or is now available to) Google has not been publicly disclosed so I couldn't say for sure what should be communicated. Still, I imagine there are subscribers who would be surprised to learn that information they thought was constrained to just GlobalSign is no longer so. ‎I think it's only fair that subscribers (and relying parties) be offered a chance to opt-out even if it means subscribers leaving GlobalSign for some other vendor. I don't know that such an offering has been made?‎I do hope that more can be publicly disclosed about what information is shared between GlobalSign and Google--including if the data sharing is related to only the 2 roots that were acquired or all GlobalSign roots. 

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

[Steve Medin via dev-security-policy]

> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Peter
> Gutmann via dev-security-policy
> Sent: Friday, March 10, 2017 4:15 AM
> To: Gervase Markham <g...@mozilla.org>; 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>
> 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 have been sold and re-
> sold for years.

But I read Peter K's nuance as transfer of less than all the roots owned by a 
CA and/or less than all of the roots in a given brand. When GMO bought 
GlobalSign from Ubizen/Cybertrust, the entire brand went and 
GTE/Baltimore/Betrusted remained with Cybertrust. When Verizon transferred to 
DigiCert, the entire browser trust portfolio moved.

> 
> >* 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 copies of the private key were in existence.
> 
> I would be surprised if only two copies were in existence, given the value of
> root keys I'd hope CAs have multiple backup copies.
> 

In my past experience, backups, rather than temporary transfer artifacts, are 
logically, physically, and geographically isolated at rest.

CAs that have been going concerns for many years may assume they intend to 
remain the owners of their roots until they expire. A shortcut results, 
certainly in the case of nCipher security worlds, where keys of common purpose 
and policy are mingled on common hardware, logically isolated by distinct m of 
n operator cardsets under an umbrella admin cardset.

By design, that becomes a split between what is transacting and what is not. At 
some point in time, witnessed by an auditor, in an environment secured 
commensurate with the presence of enabled root keys, transferred keys may need 
to be extracted and tested before the original copies are destroyed with 
witness of that destruction and to the satisfaction of the root buyer. During 
that test window, two copies exist.

Two copies should exist for that moment. Hot transfer of root keys from an HSM 
remaining in control of the seller and an HSM leaving with the buyer puts an 
entire PKI at risk. Copy, test, destroy is a recoverable scenario if a bad 
transfer and test occur.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Criticism of Mozilla Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 is not in the public interest and should
> be prohibited.  That very likely could be too strong a stance for
> Mozilla--which is fine--but it would be good to have Mozilla's position
> clearly articulated should a situation like this arise again.

Our position is that root transfers which mean the company named in the
root is no longer an operator are an inevitable fact of life. Trying to
stop them would have a number of negative effects, including making it
harder for new entrants to join the WebPKI - and I'd say that recently
new entrants have made a positive contribution to the security of the web.

If Firefox ever displays the CA name in UI that ordinary users are
likely to notice, we would need to take account of this issue. But we
don't, so we don't.

> * 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 copies of the private key were in existence.  Presumably one copy
> was destroyed at some point, but I'm not familiar with any relevant
> standards or requirements to know when/how that takes place.  Whatever the
> case may be, this situation seems to fall outside of the Root Transfer
> Policy as I now read it.

[citation needed]

> Also, did GlobalSign ever confirm to Mozilla that
> they are no longer in possession of or otherwise have access to the private
> key for those 2 roots?

I'm not sure, but I'm pretty sure Google would have made pretty sure
this was the case! :-)

> * Conduct of the transfer:  I think an expectation should be set that the
> "current holder of the trust" must be the one to drive the transfer.  Trust
> can be handed to someone else; reaching in and taking trust doesn't sound
> very...trustworthy?  To that end, I think the policy should state that the
> current root holder must do more than merely notify Mozilla about the
> change in ownership; the holder (and their auditor) must provide the
> audits, attestations, and answers to questions that come up.  Only after
> the transfer is complete would the "new holder" step in to perform those
> duties.

I think the policy already says this:

"When the physical relocation involves moving the certificate's private
key to another organization, the original organization who is
transferring the root certificate’s private key must ensure that the
transfer recipient is able to fully comply with Mozilla’s CA Certificate
Policy. The original organization will continue to be responsible for
the root certificate until the transfer recipient has provided Mozilla
with their Primary Point of Contact, CP/CPS documentation, and audit
statement (or opinion letter) confirming successful transfer of the root
certificate and key."

> * Public notification:  I appreciate that confidentiality is required when
> business transactions are being discussed but at some point, in the
> interest of transparency, the public must be notified of the transfer.  I
> think this is implied (or assumed) in the current policy, but it might be
> good to state explicitly that a public announcement must be made.  I would
> add that making an announcement at a CABF meeting is all well and good, but
> considering that most people on the Internet are not able to attend those
> meetings it would be good if an announcement could be made in other forums
> as well.

My proposal elsewhere in this thread is that any transferred cert not be
allowed to issue until "all the paperwork is in place" from the new CA -
which means providing Mozilla with the necessary CP/CPS, audits etc.,
which is inevitably a public process.

I don't think we can legislate for a minimum level of media coverage. :-)

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

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

[Peter Gutmann via dev-security-policy]

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 have been sold and re-
sold for years.

>* 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 copies of the private key were in existence.

I would be surprised if only two copies were in existence, given the value of
root keys I'd hope CAs have multiple backup copies.

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

Re: Criticism of Mozilla Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

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 copies of the private key were in existence.  Presumably one copy 
> was destroyed at some point, but I'm not familiar with any relevant 
> standards or requirements to know when/how that takes place.  Whatever the 
> case may be, this situation seems to fall outside of the Root Transfer 
> Policy as I now read it.  Also, did GlobalSign ever confirm to Mozilla that 
> they are no longer in possession of or otherwise have access to the private 
> key for those 2 roots? 

A few things are relevant to this comment. First, when designing a key 
management 
program for keys that may live ten or twenty years it is extremely important 
one builds a
disaster recovery plan. Such plans require duplicate copies of keys exist. 
Basically no 
responsible CA would not have backups of their keys.

Additionally given the reliability and performance requirements issuing CAs 
also, almost 
always, are deployed with a cluster of HSMs.

The point of mentioning the above is that having multiple copies of keys is a 
standard practice.

Regarding who has control over the associated keys, you are correct, as is the 
standard 
practice (this is my 8th transfer in my professional career) the process of 
transfer Involved 
reviewing the history and associated artifacts of the keys and ensuring, in the 
presence
of our auditors, all copies not belonging to Google were destroyed.

While I can not speak for GlobalSign I can state that I do know they notified 
all root relevant
programs that they no longer have control of the associated keys.


> * Conduct of the transfer:  I think an expectation should be set that the 
> "current holder of the trust" must be the one to drive the transfer.  Trust 
> can be handed to someone else; reaching in and taking trust doesn't sound 
> very...trustworthy?  To that end, I think the policy should state that the 
> current root holder must do more than merely notify Mozilla about the 
> change in ownership; the holder (and their auditor) must provide the 
> audits, attestations, and answers to questions that come up.  Only after 
> the transfer is complete would the "new holder" step in to perform those 
> duties. 

It is the expectation of the Mozilla Program as well as the Microsoft Program 
(and others)
that the current holder of the trust drives the transfer. That was what 
happened in this case
aswell.

As was noted in the original thread Mozilla does not publicly require 
permission to be secured but
does so privately and in this case that permission was secured, at least 
implicitly since we discussed
with Mozilla our purchase numerous times before terms were reached. Other 
programs, such as Microsoft make this requirement public so we explicitly 
secured their permission before finalizing terms as well. 

While securing such permission complicates the the process I think the value to 
the ecosystem is warrents the complication and I think it makes sense for 
Mozilla to formalize their requirement to secure permission before a transfer.


> * Public notification:  I appreciate that confidentiality is required when 
> business transactions are being discussed but at some point, in the 
> interest of transparency, the public must be notified of the transfer.  I 
> think this is implied (or assumed) in the current policy, but it might be 
> good to state explicitly that a public announcement must be made.  I would 
> add that making an announcement at a CABF meeting is all well and good, but 
> considering that most people on the Internet are not able to attend those 
> meetings it would be good if an announcement could be made in other forums 
> as well. 

This representation misrepresents what notification has taken place, for others 
I suggest 
reading the other thread for a more accurate representation.

To the specific policy suggestion, the fact that changes in the Mozilla program 
are all
tracked via public channels like the bug database and this forum mean that 
today public 
notice is already mandated. 

There may be value in requiring something “larger” than that, but defining that 
in a concrete
way is hard. In our case when we published our blog post it was picked up by 
many technical
publications but that is because we are Google. In historic transfers of keys, 
the actors in the
transfer were not as visible as Google and as such their public notices were, 
well... .not noticed.

One thing that could be a reasonable step is to require that on their document 
repository, for 
some period of time after a transfer they maintain notice there. I am not sure 
this materially
Moves the bar forward in that, I can say I have seen the web traffic for many 
repository pages for
Some of the larger 

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> 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 is actually operated by a different entity
> entirely.

That is true, but my point is that one can not rely on the name in root 
certificates, when certs are made to be good for well over a decade the concept 
of name continuity just doesn't hold.

> Also, I don't see Google on that list.

I noticed that too, Ill be reaching out to Microsoft to make sure its updated.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 loss of their 2 roots,
that's fine.  Nobody is questioning that.

What is being questioned is whether updating the GlobalSign CPS is
sufficient to address the needs, concerns, questions, or myriad other
issues that are likely to come up in the minds of GlobalSign subscribers
and relying parties--and, for that matter, Google's own subscribers and
relying parties.  To that, I think the answer must be: "no, it's not
enough".  Most people on the internet have never heard of a CPS and of
those who have, few will have ever read one and fewer still will have read
the GlobalSign CPS.


Again while I can not speak for GlobalSign I can say that there has been far
more public notice than a simple CP/CPS update.

In addition to the Google Blog post about the acquisition 
(https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html),
 the purchase was picked up by many high profile technology news sources, some 
of which included:
-  https://www.theregister.co.uk/2017/01/27/google_root_ca/
-  
http://www.infoworld.com/article/3162102/security/google-moves-into-root-certificate-authority-business.html
- http://www.securityweek.com/google-launches-its-own-root-certificate-authority

Also this topic has been discussed at great length in numerous forums around 
the web.

This is above and beyond the public notification that is built into the various 
root programs such as:

The Google Trust Services CP/CPs lists GlobalSign as subordinates
The Google Trust Services website has a link to the GlobalSign CP/CPS as well 
as their audit reports.
The Mozilla bug on this topic discusses the change in ownership,
The Mozilla CA registry will also reference the change in ownership,
The Microsoft CA registry will also reference the change in ownership,
The Mozilla Salesforce instance will reference the change in ownership,
This public thread discusses the change in ownership.


I am not sure there is much more meaningful options of notification left.



Those are all point-in-time news items, not pages that purport to be up
to date information of the current status when they are visited.


Additionally as stated, EV badges will still correctly reflect that it is 
GlobalSign who issues the associated certificates, and not Google.

The only opportunity for confusion comes from those who look at the 
certificates themselves and missed all of the above notifications.

It is also important to note that this is a very common situation, to see how 
common it is visit the page Microsoft maintains for Root Program members - 
https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx

You will notice the first column is the name of the current owner and the 
second column is the name in the certificate.

A few you will notice are:

Amazon,   Starfield Services Root Certificate Authority - G2
Asseco Data Systems S.A. (previously Unizeto Certum), Certum CA
Entrust, Trend Micro 1
Entrust, Trend Micro 2
Entrust, Trend Micro 3
Entrust, Trend Micro 4  
Comodo, The USERTrust Network™
Comodo, USERTrust (Client Authentication / Secure Email)
Comodo, USERTrust (Code Signing)
Comodo, USERTrust RSA Certification Authority
Comodo, UTN-USERFirst-Hardware
Symantec / GeoTrust
Symantec / Thawte   
Symantec / VeriSign
Trustwave, XRamp Global Certification Authority

And more...



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 is actually operated by a different entity
entirely.

Also, I don't see Google on that list.


While I sincerely want to make sure there are no surprises, given how common it 
is for names in root certificates not to match the current owner, those who are 
looking at certificate chains should not be relying on the value in the root 
certificate in the first place wrong in very significant situations.

Ryan




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

Criticism of Mozilla Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

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
regarding confidential transactions such as this.  And while Mozilla's
actions seem perfectly reasonable, I can't help but think this transaction
is a train wreck in the making.  It would be good if Mozilla could prevent
train wrecks when possible and to do so probably requires updates to the
Root Transfer Policy.

To that end, here are some thoughts to get things going:

* 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 is not in the public interest and should
be prohibited.  That very likely could be too strong a stance for
Mozilla--which is fine--but it would be good to have Mozilla's position
clearly articulated should a situation like this arise again.

* 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 copies of the private key were in existence.  Presumably one copy
was destroyed at some point, but I'm not familiar with any relevant
standards or requirements to know when/how that takes place.  Whatever the
case may be, this situation seems to fall outside of the Root Transfer
Policy as I now read it.  Also, did GlobalSign ever confirm to Mozilla that
they are no longer in possession of or otherwise have access to the private
key for those 2 roots?

* Conduct of the transfer:  I think an expectation should be set that the
"current holder of the trust" must be the one to drive the transfer.  Trust
can be handed to someone else; reaching in and taking trust doesn't sound
very...trustworthy?  To that end, I think the policy should state that the
current root holder must do more than merely notify Mozilla about the
change in ownership; the holder (and their auditor) must provide the
audits, attestations, and answers to questions that come up.  Only after
the transfer is complete would the "new holder" step in to perform those
duties.

* Public notification:  I appreciate that confidentiality is required when
business transactions are being discussed but at some point, in the
interest of transparency, the public must be notified of the transfer.  I
think this is implied (or assumed) in the current policy, but it might be
good to state explicitly that a public announcement must be made.  I would
add that making an announcement at a CABF meeting is all well and good, but
considering that most people on the Internet are not able to attend those
meetings it would be good if an announcement could be made in other forums
as well.


I imagine there are more things we'll want to discuss but hopefully this is
enough to start the discussion.


On Wed, Mar 8, 2017 at 9:54 AM, 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 and services
> > they choose to offer going forward.
>
> Not quite. GMO GlobalSign continues to control some subCAs of the roots
> it sold to Google, and is using those (presumably) to wind down its
> interest in those roots over time or support customer migrations to
> other roots. This happens to include issuing EV certificates.
>
> > There is no affiliation or business
> > relationship between GMO GlobalSign and Google after the completion of
> > the acquisition.
>
> We don't have information on this; the terms of the deal, and indeed any
> other deals the two companies may have made, are not public.
>
> > - No public announcement of the acquisition was made prior to January
> > 26, 2017 via the Google security blog.
>
> Depends what you mean by announcement, but they applied in a public bug
> for inclusion in the Mozilla root program in December:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1325532
> and, I think, announced their intention in a publicly-minuted meeting of
> the CAB Forum in Redmond in mid-October 2016.
>
> > - No disclosure has been made regarding what specific items were
> > acquired, including such things as: "private key material" (HSM's and
> > whatnot); computer equipment used as web servers, OCSP responders, etc.;
> > domain names, IP addresses, and other infrastructure used in the
> > operations and maintenance of the acquired roots; data such as
> > subscriber lists, databases, server logs, payment details and histories,
> > certificate issuance activities and histories, etc.; any access rights
> > to physical space such as 

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

That is the Starfield Services EV policy identifier, not the Starfield
EV policy identifier.  We clearly call out in section 1.1 of the our
CPS that Starfield Services Root Certificate Authority - G2 is covered
under the CPS.

On Thu, Mar 9, 2017 at 10:29 PM, Richard Wang <rich...@wosign.com> wrote:
> Good demo, thanks.
>
> I checked that you are using Startfield EV OID in Startfield name root and in 
> Amazon name root, means you are using the transferred root's EV OID. But I 
> checked your CPS that don't state this point, please advise, thanks.
>
>
> 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>; 
> mozilla-dev-security-pol...@lists.mozilla.org
> Subject: Re: Google Trust Services roots
>
> On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang <rich...@wosign.com> 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 OID, 
>> this means two companies use the same policy?
>>
>> It is better to do a test: Google issue a EV SSL certificate from this 
>> acquired root using the GlobalSign EV OID, then check every browser's UI 
>> display info, to check if that info will confuse the browser users.
>
> Richard,
>
> I'll make this easier:
>
> Go to https://good.sca1a.amazontrust.com/ and 
> https://good.sca0a.amazontrust.com/  in Safari and Microsoft IE/Edge.
> Tell me which CA issued the certificates for those sites.  (Note that we 
> don't send SCTs on those sites right now, so they aren't treated as EV in 
> Chrome, and we are still pending for EV in Mozilla)
>
> Thanks,
> Peter
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Google Trust Services roots

[Richard Wang via dev-security-policy]

Good demo, thanks.

I checked that you are using Startfield EV OID in Startfield name root and in 
Amazon name root, means you are using the transferred root's EV OID. But I 
checked your CPS that don't state this point, please advise, thanks.


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>; 
mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots

On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang <rich...@wosign.com> 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 OID, 
> this means two companies use the same policy?
>
> It is better to do a test: Google issue a EV SSL certificate from this 
> acquired root using the GlobalSign EV OID, then check every browser's UI 
> display info, to check if that info will confuse the browser users.

Richard,

I'll make this easier:

Go to https://good.sca1a.amazontrust.com/ and 
https://good.sca0a.amazontrust.com/  in Safari and Microsoft IE/Edge.
Tell me which CA issued the certificates for those sites.  (Note that we don't 
send SCTs on those sites right now, so they aren't treated as EV in Chrome, and 
we are still pending for EV in Mozilla)

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

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

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.  Nobody is questioning that.
> 
> What is being questioned is whether updating the GlobalSign CPS is
> sufficient to address the needs, concerns, questions, or myriad other
> issues that are likely to come up in the minds of GlobalSign subscribers
> and relying parties--and, for that matter, Google's own subscribers and
> relying parties.  To that, I think the answer must be: "no, it's not
> enough".  Most people on the internet have never heard of a CPS and of
> those who have, few will have ever read one and fewer still will have read
> the GlobalSign CPS.

Again while I can not speak for GlobalSign I can say that there has been far 
more public notice than a simple CP/CPS update. 

In addition to the Google Blog post about the acquisition 
(https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html),
 the purchase was picked up by many high profile technology news sources, some 
of which included:
-  https://www.theregister.co.uk/2017/01/27/google_root_ca/
-  
http://www.infoworld.com/article/3162102/security/google-moves-into-root-certificate-authority-business.html
- http://www.securityweek.com/google-launches-its-own-root-certificate-authority

Also this topic has been discussed at great length in numerous forums around 
the web. 

This is above and beyond the public notification that is built into the various 
root programs such as:
> The Google Trust Services CP/CPs lists GlobalSign as subordinates
> The Google Trust Services website has a link to the GlobalSign CP/CPS as well 
> as their audit reports.
> The Mozilla bug on this topic discusses the change in ownership,
> The Mozilla CA registry will also reference the change in ownership,
> The Microsoft CA registry will also reference the change in ownership,
> The Mozilla Salesforce instance will reference the change in ownership,
> This public thread discusses the change in ownership.

I am not sure there is much more meaningful options of notification left.

Additionally as stated, EV badges will still correctly reflect that it is 
GlobalSign who issues the associated certificates, and not Google.

The only opportunity for confusion comes from those who look at the 
certificates themselves and missed all of the above notifications.

It is also important to note that this is a very common situation, to see how 
common it is visit the page Microsoft maintains for Root Program members - 
https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx

You will notice the first column is the name of the current owner and the 
second column is the name in the certificate.

A few you will notice are:

Amazon,   Starfield Services Root Certificate Authority - G2
Asseco Data Systems S.A. (previously Unizeto Certum), Certum CA
Entrust, Trend Micro 1
Entrust, Trend Micro 2
Entrust, Trend Micro 3
Entrust, Trend Micro 4  
Comodo, The USERTrust Network™
Comodo, USERTrust (Client Authentication / Secure Email)
Comodo, USERTrust (Code Signing)
Comodo, USERTrust RSA Certification Authority
Comodo, UTN-USERFirst-Hardware
Symantec / GeoTrust
Symantec / Thawte   
Symantec / VeriSign
Trustwave, XRamp Global Certification Authority

And more...

While I sincerely want to make sure there are no surprises, given how common it 
is for names in root certificates not to match the current owner, those who are 
looking at certificate chains should not be relying on the value in the root 
certificate in the first place wrong in very significant situations. 

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

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

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 OID, 
> this means two companies use the same policy?
>
> It is better to do a test: Google issue a EV SSL certificate from this 
> acquired root using the GlobalSign EV OID, then check every browser's UI 
> display info, to check if that info will confuse the browser users.

Richard,

I'll make this easier:

Go to https://good.sca1a.amazontrust.com/ and
https://good.sca0a.amazontrust.com/  in Safari and Microsoft IE/Edge.
Tell me which CA issued the certificates for those sites.  (Note that
we don't send SCTs on those sites right now, so they aren't treated as
EV in Chrome, and we are still pending for EV in Mozilla)

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

Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

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 GlobalSign CPS is
sufficient to address the needs, concerns, questions, or myriad other
issues that are likely to come up in the minds of GlobalSign subscribers
and relying parties--and, for that matter, Google's own subscribers and
relying parties.  To that, I think the answer must be: "no, it's not
enough".  Most people on the internet have never heard of a CPS and of
those who have, few will have ever read one and fewer still will have read
the GlobalSign CPS.

It would be good if you could elaborate more on what steps Google will be
taking to communicate to the general public that GlobalSign means
GlobalSign except when it means Google and that sometimes Google will mean
GlobalSign as well.



On Wed, Mar 8, 2017 at 12:02 PM, Ryan Hurst via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> > 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
> but are
> In the process of migrating that inhouse.
>
> > Jakob: Does GTS sign regularly updated CRLs published at the
> (GlobalSign) URLs
> > listed in the CRL URL extensions in the GlobalSign operated non-expired
> > intermediaries?
>
> At this time Google produces CRLs and works with GlobalSign to publish
> those CRLs.
>
> > Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS
> for the
> > acquired roots.
>
> This level of detail is not typically included in a CPS, for example, a
> service may change
> Which internet service provider or CDN service they use and not need
> update their CP/CPS.
>
>
> > Jakob: Any relying party seeing the existing root in a chain would see
> the
> > name GlobalSign in the Issuer DN and naturally look to GlobalSign's
> > website and CP/CPS for additional information in trying to decide if
> > the chain should be trusted.
>
> The GlobalSign CPS indicates that the R2 and R4 are no longer under their
> control.
>
> Additionally given the long term nature of CA keys, it is common for the
> DN not to accurately
> represent the organization that controls it. As I mentioned in an earlier
> response in the 90’s I
> created roots for a company called Valicert that has changed hands several
> times, additionally
> Verisign, now Symantec in this context has a long history of acquiring CAs
> and as such they
> have CA certificates with many different names within them.
>
> > Jakob: A relying party might assume, without detailed checks, that these
> roots
> > are operated exclusively by GlobalSign in accordance with GlobalSign's
> > good reputation.
>
> As the former CTO of GlobalSign I love hearing about their good reputation
> ;)
>
> However I would say the CP/CPS is the authoritative document here and since
>  GMO GlobalSign CP/CPS clearly states the keys are no longer in their
> control I believe this
> Should not be an issue.
>
> > Jakob: Thus a clear notice that these "GlobalSign roots" are no longer
> > operated by GlobalSign at any entrypoint where a casual relying party
> > might go to check who "GlobalSign R?" is would be appropriate.
>
> I would argue the CA’s CP/CPS’s are the authoritative documents here and
> would
> Satisfy this requirement.
>
> > Jakob: If possible, making Mozilla products present these as "Google",
> not
> > "GlobalSign" in short-form UIs (such as the certificate chain tree-like
> > display element).  Similarly for other root programs (for example, the
> > Microsoft root program could change the "friendly name" of these).
>
> I agree with Jakob here, given the frequency in which roots change hands,
> it would make
> sense to have an ability to do this. Microsoft maintains this capability
> that is made available
> to the owner.
>
> 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 capability the
> EV badge would say verified by Google. This is because they display the
> root name for the
> EV badge. However, it is the subordinate CA in accordance with its CP/CPS
> that is responsible
> for vetting, as such the name displayed in this case should be GlobalSign.
>
> Despite these limitations, it may make sense in the case of Firefox to
> maintain a similar capability.
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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).  From a business perspective
this could be comparable to similar requirements imposed on some
physical objects that can have public interest implications.


Microsoft has a similar requirement in their program, we had to get permission
from them before we could finalize commercial terms for this acquisition.
I personally think this is a good policy and one I think Mozilla should adopt 
as well.

It adds more complexity to these acquisitions in that one needs to get the 
approvals
from multiple parties but I think that the value to the ecosystem warrants
this complexity.



Jacob: For clarity could Google and/or GTS issue a dedicated CP/CPS pair for
the brief period where Google (not GTS) had control of the former
GlobalSign root (such a CP/CPS would be particularly simple given that
no certificates were issued).  Such as CP/CPS should also clarify any
practices and procedures for signing revocation related data (CRLs,
OCSP responses, OCSP responder certificates) from that root during the
transition.  The CP/CPS would also need to somehow state that the
former GlobalSign issued certificates remain valid, though no further
such certificates were issued in this interim period.



Similarly could Google and/or GTS issue a dedicated CP/CPS pair for the
new roots during the brief period where Google (not GTS) had control of
those new roots.


While we want to work with the community to provide assurances we followed
best practices and the required policies in this transfer I do not think this 
would provide
any further insights.

Before the transfer we, and our auditors, reviewed the CP/CPS, as well as the 
policies
and procedures associated with the the management of these keys, and found them 
to be
both compliant with both the requirements and best practices. In other words,
both we, and our auditors, are stating, as supported by the opinion letter, 
that we believe the
Google CP/CPS covered these keys during this period.

If we created a new CP/CPS for that period it would, at best, be a subset of the
Google CP/CPS and offer no new information other than the omission of a few 
details.

Could you maybe clarify what your goals are with this request, with that we can 
potentially
propose an alternate approach to address those concerns.




This was merely suggested as a possible way to formally answer the
fears and questions posed by others about the situation during the
transition and the discussed inapplicability of some wording in the
old Google CP/CPS to the new situation.


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: Google Trust Services roots

[Richard Wang via dev-security-policy]

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 this EV
>> OID tomorrow, the browser will display EV green bar. Right? 
> 
> Technically, you are correct - such certs would produce the EV UI.
> However, if you didn't have an EV audit which covered the root, your
> root would quickly get kicked out of the root programs.
> 
> 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: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 the EV UI.
However, if you didn't have an EV audit which covered the root, your
root would quickly get kicked out of the root programs.

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

Re: Google Trust Services roots

[Richard Wang via dev-security-policy]

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 Markham  wrote:
> 
>> 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 the effect
> of stopping the receiver of the root from issuing EV certs until the
> updated root store with the new policy OID mapping was in all Firefoxes.
> Given that OIDs are just opaque identifiers, it seems unnecessary to
> require this.
> 
> What security or other problem is caused if e.g. Google were to use an
> EV OID originally used by (or still used by) GlobalSign, assuming the
> two companies agreed that was OK?
> 
> Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

Yes, it means the two companies used the same policy for issuance - as
identified by that policy. Did you read the ETSI materials I suggested you
do? Perhaps this would make it easier for you.

I don't think encouraging a CA to misissue - which if you read other
people's replies, you would see Ryan identified it as misissuance (but not
for the reasons you note), is productive. Misissuing is very bad, as you
hopefully know.

If two certificates, from different organizations, have the same policy
OID, it means they were issued in whatever manner necessary to comply with
that OID at the time they were issued. And that's perfectly ok and not at
all prohibited.

If your worried that GlobalSign's policy might describe GlobalSign-only
things, then you're forgetting GlobalSign can update their policy at any
time. Just like we use the same CABF EV OID despite the policies for EV
changing every time we update the EVG, at any point GlobalSign could
indicate their EV OID "just" means following the EVGs, which any
organization that is trusted to issue certificates can do at any time.

On Thu, Mar 9, 2017 at 1:14 AM Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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 OID,
> this means two companies use the same policy?
>
> It is better to do a test: Google issue a EV SSL certificate from this
> acquired root using the GlobalSign EV OID, then check every browser's UI
> display info, to check if that info will confuse the browser users.
>
>
> Best Regards,
>
> 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-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 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 roots from the same operator may use different
> policies.
>
> For example, I see the following in the Microsoft trust list:
>
> CN=CA 沃通根证书,O=WoSign CA Limited,C=CN
> CN=Class 1 Primary CA,O=Certplus,C=FR
> CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN CN=CA WoSign
> ECC Root,O=WoSign CA Limited,C=CN CN=Certification Authority of WoSign
> G2,O=WoSign CA Limited,C=CN each of these has one EV mapped policy:
> 1.3.6.1.4.1.36305.2
>
> CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy
> 1.3.6.1.4.1.34697.2.1 mapped to EV
> CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy
> 1.3.6.1.4.1.34697.2.2 mapped to EV
> CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy
> 1.3.6.1.4.1.34697.2.3 mapped to EV
> CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy
> 1.3.6.1.4.1.34697.2.4 mapped to EV
> All of these are from the same company but each has their own policy
> identifier.
>
> The information on "Identified by " in Microsoft's browsers
> comes from the "Friendly Name" field in the trust list. For example the
> friendly name of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign 1999".
>
> For something like the AffirmTrust example, they could easily sell one
> root along with the exclusive right to use that root's EV OID without
> impacting their other OIDs.
>
> Does that make sense?
>
> Thanks,
> Peter
>
> On Wed, Mar 8, 2017 at 8:44 PM, Richard Wang via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
> > I don’t think so, please check this page:
> https://cabforum.org/object-registry/ that listed most CA’s EV OID, and
> all browsers ask for the CA’s own EV OID when applying inclusion and EV
> enabled. So, as I understand that the browser display EV green bar and
> display the “Identified by CA name” is based on this CA’s EV OID.
> >
> >
> >
> > I don’t think Symantec have the reason to use GlobalSign EV OID in its
> EV SSL certificate, why Symantec don’t use his own EV OID? If Symantec
> issued a EV SSL using GlobalSign's EV OID, I think IE browser will display
> this EV SSL is identified by GlobalSign, not by Symantec.
> ___
> 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: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 the effect
of stopping the receiver of the root from issuing EV certs until the
updated root store with the new policy OID mapping was in all Firefoxes.
Given that OIDs are just opaque identifiers, it seems unnecessary to
require this.

What security or other problem is caused if e.g. Google were to use an
EV OID originally used by (or still used by) GlobalSign, assuming the
two companies agreed that was OK?

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

Re: Google Trust Services roots

[Kurt Roeckx via dev-security-policy]

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. They describe the policies relative to how the
certificate was issued and validated. This is much clearer if you read the
relevant ETSI TS/EN series of docs related to Certificate Policies.

To your point about identifying the issuer, I may be misunderstanding your
point, but it sounds like you're just confused about how browsers work.
Browsers don't look up the EV OID to determine who the issuer is, so if
you're concerned that would present a problem, it doesn't.

Instead, browsers look for *any* EV enabled OID in the leaf certificate,
then attempt to build/verify that a chain can be built to one or more root
certificates "enabled" for that OID. If they can, the leaf is called EV,
and the browser determines who issued it by looking at the root.


I would also like to see that all EV certificates actually have the CABF 
EV OID, possibly in addition to any CA specific OID. I would actually 
like to see that for all CABF OIDs, it's currently only required for the 
IV certificates as far as I know.



Kurt


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

RE: Google Trust Services roots

[Richard Wang via dev-security-policy]

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 OID, this 
means two companies use the same policy? 

It is better to do a test: Google issue a EV SSL certificate from this acquired 
root using the GlobalSign EV OID, then check every browser's UI display info, 
to check if that info will confuse the browser users.


Best Regards,

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-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 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 roots from the same operator may use different policies.

For example, I see the following in the Microsoft trust list:

CN=CA 沃通根证书,O=WoSign CA Limited,C=CN
CN=Class 1 Primary CA,O=Certplus,C=FR
CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN CN=CA WoSign ECC 
Root,O=WoSign CA Limited,C=CN CN=Certification Authority of WoSign G2,O=WoSign 
CA Limited,C=CN each of these has one EV mapped policy: 1.3.6.1.4.1.36305.2

CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.1 mapped to EV
CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.2 mapped to EV
CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.3 mapped to EV
CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.4 mapped to EV
All of these are from the same company but each has their own policy identifier.

The information on "Identified by " in Microsoft's browsers comes 
from the "Friendly Name" field in the trust list. For example the friendly name 
of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign 1999".

For something like the AffirmTrust example, they could easily sell one root 
along with the exclusive right to use that root's EV OID without impacting 
their other OIDs.

Does that make sense?

Thanks,
Peter

On Wed, Mar 8, 2017 at 8:44 PM, Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org> wrote:
> I don’t think so, please check this page: 
> https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all 
> browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. 
> So, as I understand that the browser display EV green bar and display the 
> “Identified by CA name” is based on this CA’s EV OID.
>
>
>
> I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL 
> certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV 
> SSL using GlobalSign's EV OID, I think IE browser will display this EV SSL is 
> identified by GlobalSign, not by Symantec.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

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 roots from the same operator may
use different policies.

For example, I see the following in the Microsoft trust list:

CN=CA 沃通根证书,O=WoSign CA Limited,C=CN
CN=Class 1 Primary CA,O=Certplus,C=FR
CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN
CN=CA WoSign ECC Root,O=WoSign CA Limited,C=CN
CN=Certification Authority of WoSign G2,O=WoSign CA Limited,C=CN
each of these has one EV mapped policy: 1.3.6.1.4.1.36305.2

CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.1 mapped to EV
CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.2 mapped to EV
CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.3 mapped to EV
CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy
1.3.6.1.4.1.34697.2.4 mapped to EV
All of these are from the same company but each has their own policy identifier.

The information on "Identified by " in Microsoft's browsers
comes from the "Friendly Name" field in the trust list. For example
the friendly name of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign
1999".

For something like the AffirmTrust example, they could easily sell one
root along with the exclusive right to use that root's EV OID without
impacting their other OIDs.

Does that make sense?

Thanks,
Peter

On Wed, Mar 8, 2017 at 8:44 PM, Richard Wang via dev-security-policy
 wrote:
> I don’t think so, please check this page: 
> https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all 
> browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. 
> So, as I understand that the browser display EV green bar and display the 
> “Identified by CA name” is based on this CA’s EV OID.
>
>
>
> I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL 
> certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV 
> SSL using GlobalSign's EV OID, I think IE browser will display this EV SSL is 
> identified by GlobalSign, not by Symantec.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Google Trust Services roots

[Richard Wang via dev-security-policy]

I don’t think so, please check this page: https://cabforum.org/object-registry/ 
that listed most CA’s EV OID, and all browsers ask for the CA’s own EV OID when 
applying inclusion and EV enabled. So, as I understand that the browser display 
EV green bar and display the “Identified by CA name” is based on this CA’s EV 
OID.



I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL 
certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV SSL 
using GlobalSign's EV OID, I think IE browser will display this EV SSL is 
identified by GlobalSign, not by Symantec.





Best Regards,



Richard



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, March 9, 2017 12:21 PM
To: Gervase Markham <g...@mozilla.org>; Richard Wang <rich...@wosign.com>; Ryan 
Sleevi <r...@sleevi.com>; mozilla-dev-security-pol...@lists.mozilla.org
Subject: Re: Google Trust Services roots



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. They describe the policies relative to how the certificate was 
issued and validated. This is much clearer if you read the relevant ETSI TS/EN 
series of docs related to Certificate Policies.



To your point about identifying the issuer, I may be misunderstanding your 
point, but it sounds like you're just confused about how browsers work. 
Browsers don't look up the EV OID to determine who the issuer is, so if you're 
concerned that would present a problem, it doesn't.



Instead, browsers look for *any* EV enabled OID in the leaf certificate, then 
attempt to build/verify that a chain can be built to one or more root 
certificates "enabled" for that OID. If they can, the leaf is called EV, and 
the browser determines who issued it by looking at the root.



So if Symantec were to issue such a certificate using GlobalSign's EV OID, and 
Symantec's root was enabled for that OID, and it validated according to RFC5280 
for that OID, then the certificate would appear as a Symantec-issued (because 
Symantec root) EV cert.



Of course, I have oversimplified this for you - the actual UI browsers tend to 
take is not from the root, but from the issuing intermediate, or metadata 
external to the root, so it's also not an issue for the root to say Symantec, 
ValiCert, Equifax, Norton, or something else - because that's ignored when 
better data is available, and it always is, if the CA is responsive to root 
program requirements.





On Wed, Mar 8, 2017 at 10:31 PM Richard Wang 
<rich...@wosign.com<mailto:rich...@wosign.com>> wrote:

   Maybe I don’t say it clearly.



   The EV SSL have two policy OID, one is the CABF EV OID, another one is the 
CA's EV OID, right?

   Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV 
OID is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6

   And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no 
CABF EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1



   What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to 
GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so 
Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID 
for its EV SSL.



   So, no EV OID transfer issue for root key transfer.





   Best Regards,



   Richard



   From: Ryan Sleevi [mailto:r...@sleevi.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-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, it's unclear to me, and I suspect many other readers, why 
you believe this is the case, or if you meant that it SHOULD be the case (for 
example, developing a new policy requirement), why you believe this.



   Perhaps you could share more details about your reasoning?



   On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

  As I understand, the EV SSL have two policy OID, one is the CABF EV OID, 
another one is the CA's EV OID, so the root key transfer doesn't have the EV 
OID transfer case, CA can't transfer its own EV OID to other CA exception the 
CA is full acquired.

  So the policy can make clear that the root key transfer can't trans

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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. They describe the policies relative to how the
certificate was issued and validated. This is much clearer if you read the
relevant ETSI TS/EN series of docs related to Certificate Policies.

To your point about identifying the issuer, I may be misunderstanding your
point, but it sounds like you're just confused about how browsers work.
Browsers don't look up the EV OID to determine who the issuer is, so if
you're concerned that would present a problem, it doesn't.

Instead, browsers look for *any* EV enabled OID in the leaf certificate,
then attempt to build/verify that a chain can be built to one or more root
certificates "enabled" for that OID. If they can, the leaf is called EV,
and the browser determines who issued it by looking at the root.

So if Symantec were to issue such a certificate using GlobalSign's EV OID,
and Symantec's root was enabled for that OID, and it validated according to
RFC5280 for that OID, then the certificate would appear as a
Symantec-issued (because Symantec root) EV cert.

Of course, I have oversimplified this for you - the actual UI browsers tend
to take is not from the root, but from the issuing intermediate, or
metadata external to the root, so it's also not an issue for the root to
say Symantec, ValiCert, Equifax, Norton, or something else - because that's
ignored when better data is available, and it always is, if the CA is
responsive to root program requirements.


On Wed, Mar 8, 2017 at 10:31 PM Richard Wang <rich...@wosign.com> wrote:

> Maybe I don’t say it clearly.
>
>
>
> The EV SSL have two policy OID, one is the CABF EV OID, another one is the
> CA's EV OID, right?
>
> Check the EV SSL for www.symantec.com, the CABF EV OID is 2.23.140.1.1,
> and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6
>
> And check www.gloabalsign.com EV SSL that no CABF EV OID, GlobalSign EV
> OID is 1.3.6.1.4.1.4146.1.1
>
>
>
> What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to
> GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign,
> so Google can’t use this EV OID for its own EV SSL, Google must use its own
> EV OID for its EV SSL.
>
>
>
> So, no EV OID transfer issue for root key transfer.
>
>
>
>
>
> Best Regards,
>
>
>
> Richard
>
>
>
> *From:* Ryan Sleevi [mailto:r...@sleevi.com]
> *Sent:* Thursday, 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 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, it's unclear to me, and I suspect many other readers, why
> you believe this is the case, or if you meant that it SHOULD be the case
> (for example, developing a new policy requirement), why you believe this.
>
>
>
> Perhaps you could share more details about your reasoning?
>
>
>
> On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> As I understand, the EV SSL have two policy OID, one is the CABF EV OID,
> another one is the CA's EV OID, so the root key transfer doesn't have the
> EV OID transfer case, CA can't transfer its own EV OID to other CA
> exception 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
>
> -Original Message-----
> 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 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, it would be unreasonable for us to retroactively censure Google for
> following that plan.
>
> On 09/02/17 22:55, Peter Bowen wrote:
> > Polic

RE: Google Trust Services roots

[Richard Wang via dev-security-policy]

Maybe I don’t say it clearly.



The EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's 
EV OID, right?

Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV OID 
is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6

And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no CABF 
EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1



What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to 
GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so 
Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID 
for its EV SSL.



So, no EV OID transfer issue for root key transfer.





Best Regards,



Richard



From: Ryan Sleevi [mailto:r...@sleevi.com]
Sent: Thursday, 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 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, it's unclear to me, and I suspect many other readers, why you 
believe this is the case, or if you meant that it SHOULD be the case (for 
example, developing a new policy requirement), why you believe this.



Perhaps you could share more details about your reasoning?



On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy 
<dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org>>
 wrote:

   As I understand, the EV SSL have two policy OID, one is the CABF EV OID, 
another one is the CA's EV OID, so the root key transfer doesn't have the EV 
OID transfer case, CA can't transfer its own EV OID to other CA exception 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

   -Original Message-
   From: dev-security-policy 
[mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto: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<mailto: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 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, 
it would be unreasonable for us to retroactively censure Google for following 
that plan.

   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 should update 
https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it 
into the main policy when we fix
   https://github.com/mozilla/pkipolicy/issues/57 .


   ___
   dev-security-policy mailing list
   
dev-security-policy@lists.mozilla.org<mailto: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: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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, it's unclear to me, and I suspect many other readers, why
you believe this is the case, or if you meant that it SHOULD be the case
(for example, developing a new policy requirement), why you believe this.

Perhaps you could share more details about your reasoning?

On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> As I understand, the EV SSL have two policy OID, one is the CABF EV OID,
> another one is the CA's EV OID, so the root key transfer doesn't have the
> EV OID transfer case, CA can't transfer its own EV OID to other CA
> exception 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
>
> -Original Message-
> 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 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, it would be unreasonable for us to retroactively censure Google for
> following that plan.
>
> 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 should update
> https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually
> incorporate it into the main policy when we fix
> https://github.com/mozilla/pkipolicy/issues/57 .
>
>
> ___
> 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: Google Trust Services roots

[Richard Wang via dev-security-policy]

As I understand, the EV SSL have two policy OID, one is the CABF EV OID, 
another one is the CA's EV OID, so the root key transfer doesn't have the EV 
OID transfer case, CA can't transfer its own EV OID to other CA exception 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

-Original Message-
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 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, 
it would be unreasonable for us to retroactively censure Google for following 
that plan.

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 should update 
https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it 
into the main policy when we fix
https://github.com/mozilla/pkipolicy/issues/57 .


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

Re: Google Trust Services roots

[admin--- via dev-security-policy]

> 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 to 
> articulate why, specifically for Mozilla products :) 

Outside EV I think it would be very hard to make the case, though Mozilla does 
maintain a certificate viewer that is easily accessible I have to imagine it is 
almost never used. As such, in the case of DV I think it would not make much 
sense.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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 capability the
> EV badge would say verified by Google. This is because they display the
> root name for the
> EV badge. However, it is the subordinate CA in accordance with its CP/CPS
> that is responsible
> for vetting, as such the name displayed in this case should be GlobalSign.
>
> Despite these limitations, it may make sense in the case of Firefox to
> maintain a similar capability.


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 to
articulate why, specifically for Mozilla products :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> 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 but are
In the process of migrating that inhouse.

> Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) 
> URLs 
> listed in the CRL URL extensions in the GlobalSign operated non-expired 
> intermediaries? 

At this time Google produces CRLs and works with GlobalSign to publish those 
CRLs.

> Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for 
> the 
> acquired roots. 

This level of detail is not typically included in a CPS, for example, a service 
may change 
Which internet service provider or CDN service they use and not need update 
their CP/CPS.


> Jakob: Any relying party seeing the existing root in a chain would see the 
> name GlobalSign in the Issuer DN and naturally look to GlobalSign's 
> website and CP/CPS for additional information in trying to decide if 
> the chain should be trusted. 

The GlobalSign CPS indicates that the R2 and R4 are no longer under their 
control.

Additionally given the long term nature of CA keys, it is common for the DN not 
to accurately 
represent the organization that controls it. As I mentioned in an earlier 
response in the 90’s I 
created roots for a company called Valicert that has changed hands several 
times, additionally
Verisign, now Symantec in this context has a long history of acquiring CAs and 
as such they 
have CA certificates with many different names within them.

> Jakob: A relying party might assume, without detailed checks, that these 
> roots 
> are operated exclusively by GlobalSign in accordance with GlobalSign's 
> good reputation. 

As the former CTO of GlobalSign I love hearing about their good reputation ;)

However I would say the CP/CPS is the authoritative document here and since
 GMO GlobalSign CP/CPS clearly states the keys are no longer in their control I 
believe this
Should not be an issue.

> Jakob: Thus a clear notice that these "GlobalSign roots" are no longer 
> operated by GlobalSign at any entrypoint where a casual relying party 
> might go to check who "GlobalSign R?" is would be appropriate. 

I would argue the CA’s CP/CPS’s are the authoritative documents here and would
Satisfy this requirement.

> Jakob: If possible, making Mozilla products present these as "Google", not 
> "GlobalSign" in short-form UIs (such as the certificate chain tree-like 
> display element).  Similarly for other root programs (for example, the 
> Microsoft root program could change the "friendly name" of these). 

I agree with Jakob here, given the frequency in which roots change hands, it 
would make
sense to have an ability to do this. Microsoft maintains this capability that 
is made available
to the owner.

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 capability the
EV badge would say verified by Google. This is because they display the root 
name for the 
EV badge. However, it is the subordinate CA in accordance with its CP/CPS that 
is responsible
for vetting, as such the name displayed in this case should be GlobalSign.

Despite these limitations, it may make sense in the case of Firefox to maintain 
a similar capability.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> 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 eventually 
> incorporate it into the main policy when we fix 
> https://github.com/mozilla/pkipolicy/issues/57 . 

I think this is good.


> Gerv: https://wiki.mozilla.org/CA:RootTransferPolicy says that "The 
> organization who is transferring ownership of the root certificate’s 
> private key must ensure that the transfer recipient is able to fully 
> comply with Mozilla’s CA Certificate Policy. The original organization 
> will continue to be responsible for the root certificate's private key 
> until the transfer recipient has provided Mozilla with their Primary 
> Point of Contact, CP/CPS documentation, and audit statement (or opinion 
> letter) confirming successful transfer of the root certificate and key." 

> Gerv: I would say that an organization which has acquired a root certificate 
> in the program and which has provided Mozilla with the above-mentioned 
> information is thereby a member of the program. As the policy says that 
> the transferring entity continues to be responsible until the 
> information is provided, that seems OK to me. 

This seems reasonable to me also.

> Gerv: This position would logically lead to the position that a root 
> inclusion 
> request from an organization which does not have any roots is also, 
> implicitly, an application to become a member of the program but the two 
> things are distinct. One can become a member of the program in other 
> ways. Membership is sort of something that happens to one automatically 
> when one successfully achieves ownership of an included root. 

This seems reasonable to me also.


> pzb: Policy Suggestion B) Require that any organization wishing to become 
> a member of the program submit a bug with links to content 
> demonstrating compliance with the Mozilla policy.  Require that this 
> be public prior to taking control of any root in the program. 

> 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 paperwork was publicly in place. Would that be 
> suitable? 

Could you clarify what you mean by appropriate paperwork?


> pzb: Policy Suggestion C) Recognize that root transfers are distinct from 
> the acquisition of a program member.  Acquisition of a program 
> member (meaning purchase of the company) is a distinctly different 
> activity from moving only a private key, as the prior business 
> controls no longer apply in the latter case. 

> Gerv: https://wiki.mozilla.org/CA:RootTransferPolicy does make this 
distinction, I feel - how could it be better made? 

After re-reading this text I personally think this is clear.


> pzb: Policy Suggestion D) Moving from being a RA to a CA or moving from 
> being a single tier/online (i.e. Subordinate-only) CA to being a 
> multi-tier/root CA requires a PITRA 

> Gerv: Again, would this be covered by a requirement that no issuance was 
> permitted from a transferred root until all the paperwork was in place, 
> including appropriately-scoped audits? This might lead to a PITRA, but 
> would not have to. 

This seems reasonable to me also.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> 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 
> this could be comparable to similar requirements imposed on some 
> physical objects that can have public interest implications. 

Microsoft has a similar requirement in their program, we had to get permission
from them before we could finalize commercial terms for this acquisition. 
I personally think this is a good policy and one I think Mozilla should adopt 
as well.

It adds more complexity to these acquisitions in that one needs to get the 
approvals
from multiple parties but I think that the value to the ecosystem warrants 
this complexity.


> Jacob: For clarity could Google and/or GTS issue a dedicated CP/CPS pair for 
> the brief period where Google (not GTS) had control of the former 
> GlobalSign root (such a CP/CPS would be particularly simple given that 
> no certificates were issued).  Such as CP/CPS should also clarify any 
> practices and procedures for signing revocation related data (CRLs, 
> OCSP responses, OCSP responder certificates) from that root during the 
> transition.  The CP/CPS would also need to somehow state that the 
> former GlobalSign issued certificates remain valid, though no further 
> such certificates were issued in this interim period. 

> Similarly could Google and/or GTS issue a dedicated CP/CPS pair for the 
> new roots during the brief period where Google (not GTS) had control of 
> those new roots. 

While we want to work with the community to provide assurances we followed
best practices and the required policies in this transfer I do not think this 
would provide
any further insights.

Before the transfer we, and our auditors, reviewed the CP/CPS, as well as the 
policies 
and procedures associated with the the management of these keys, and found them 
to be
both compliant with both the requirements and best practices. In other words,
both we, and our auditors, are stating, as supported by the opinion letter, 
that we believe the 
Google CP/CPS covered these keys during this period.

If we created a new CP/CPS for that period it would, at best, be a subset of 
the 
Google CP/CPS and offer no new information other than the omission of a few 
details.

Could you maybe clarify what your goals are with this request, with that we can 
potentially 
propose an alternate approach to address those concerns. 

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> 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 contract between
> Google and GeoTrust, Inc., the Root CA."

> Are you asserting that the authority for the key generation process
> the new Google roots is "the contract between Google and GeoTrust,
> Inc."?

No, that is not the intent of that statement, it is a good catch. This is 
simply a poorly worded statement.

To clarify our acquisition of these keys and certificates are independent of 
our agreement with GeoTrust, Inc. 

The Intent of that statement is to say that the technical requirements of that 
contract, which in essence refer to meeting the WebTrust requirements, were 
followed.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 and services
they choose to offer going forward.


Not quite. GMO GlobalSign continues to control some subCAs of the roots
it sold to Google, and is using those (presumably) to wind down its
interest in those roots over time or support customer migrations to
other roots. This happens to include issuing EV certificates.



An open question is how revocation and OCSP status for the
existing intermediaries issued by the acquired roots is handled.

For example, does GTS or GlobalSign run active OCSP servers at the URLs
listed in the AIA of the GlobalSign operated non-expired intermediaries
that positively confirm the validity of each of those intermediaries?

Does GTS sign regularly updated CRLs published at the (GlobalSign) URLs
listed in the CRL URL extensions in the GlobalSign operated non-expired
intermediaries?

Hopefully these things are answered somewhere in the GTS CP/CPS for the
acquired roots.



...

...


- The GlobalSign web site has no mention of this acquisition for reasons
which are unknown.


Why would this be a requirement by anyone?


Any relying party seeing the existing root in a chain would see the
name GlobalSign in the Issuer DN and naturally look to GlobalSign's
website and CP/CPS for additional information in trying to decide if
the chain should be trusted.

A relying party might assume, without detailed checks, that these roots
are operated exclusively by GlobalSign in accordance with GlobalSign's
good reputation.

Thus a clear notice that these "GlobalSign roots" are no longer
operated by GlobalSign at any entrypoint where a casual relying party
might go to check who "GlobalSign R?" is would be appropriate.

If possible, making Mozilla products present these as "Google", not
"GlobalSign" in short-form UIs (such as the certificate chain tree-like
display element).  Similarly for other root programs (for example, the
Microsoft root program could change the "friendly name" of these).




Further, the web site does not make their CP/CPS
documents readily available


Which website? The CP/CPS documents for which root(s)?

The GTS CP and CPS are here: http://pki.goog/.


- A relying party who takes the initiative to review a certificate chain
that goes up to either of the acquired roots will see that it is
anchored (or "verified by") GlobalSign. No mention of Google will be
made anywhere in the user interface.


I would expect there to be intermediate certificates with Google's name
in; it's not permitted to issue EE certs directly from a root. However,
neither GlobalSign's nor Google's name would appear in primary UI in
Firefox, as we don't display CA names.


At least in one Mozilla-based browser, the UI shows the name of the
Intermediary as a tooltip, not of the root.  So OK for this case.



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: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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, it would be unreasonable for us to retroactively censure
Google for following that plan.

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 should update
https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually
incorporate it into the main policy when we fix
https://github.com/mozilla/pkipolicy/issues/57 .

> I think that this is the key issue.  In my reading, "root 
> certificates" are not members of the program.  Rather organizations 
> (legal entities) are members and each member has some number of root 
> certificates.
> 
> Google was not a member of the program and had not applied to be a 
> member of the program at the time they received the roots already in 
> the program.  This seems problematic to me.

https://wiki.mozilla.org/CA:RootTransferPolicy says that "The
organization who is transferring ownership of the root certificate’s
private key must ensure that the transfer recipient is able to fully
comply with Mozilla’s CA Certificate Policy. The original organization
will continue to be responsible for the root certificate's private key
until the transfer recipient has provided Mozilla with their Primary
Point of Contact, CP/CPS documentation, and audit statement (or opinion
letter) confirming successful transfer of the root certificate and key."

I would say that an organization which has acquired a root certificate
in the program and which has provided Mozilla with the above-mentioned
information is thereby a member of the program. As the policy says that
the transferring entity continues to be responsible until the
information is provided, that seems OK to me.

This position would logically lead to the position that a root inclusion
request from an organization which does not have any roots is also,
implicitly, an application to become a member of the program but the two
things are distinct. One can become a member of the program in other
ways. Membership is sort of something that happens to one automatically
when one successfully achieves ownership of an included root.

> Policy Suggestion B) Require that any organization wishing to become
> a member of the program submit a bug with links to content
> demonstrating compliance with the Mozilla policy.  Require that this
> be public prior to taking control of any root in the program.

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 paperwork was publicly in place. Would that be
suitable?

> Policy Suggestion C) Recognize that root transfers are distinct from 
> the acquisition of a program member.  Acquisition of a program
> member (meaning purchase of the company) is a distinctly different
> activity from moving only a private key, as the prior business
> controls no longer apply in the latter case.

https://wiki.mozilla.org/CA:RootTransferPolicy does make this
distinction, I feel - how could it be better made?

> Policy Suggestion D) Moving from being a RA to a CA or moving from 
> being a single tier/online (i.e. Subordinate-only) CA to being a 
> multi-tier/root CA requires a PITRA

Again, would this be covered by a requirement that no issuance was
permitted from a transferred root until all the paperwork was in place,
including appropriately-scoped audits? This might lead to a PITRA, but
would not have to.

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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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

Not quite. GMO GlobalSign continues to control some subCAs of the roots
it sold to Google, and is using those (presumably) to wind down its
interest in those roots over time or support customer migrations to
other roots. This happens to include issuing EV certificates.

> There is no affiliation or business
> relationship between GMO GlobalSign and Google after the completion of
> the acquisition.

We don't have information on this; the terms of the deal, and indeed any
other deals the two companies may have made, are not public.

> - No public announcement of the acquisition was made prior to January
> 26, 2017 via the Google security blog.

Depends what you mean by announcement, but they applied in a public bug
for inclusion in the Mozilla root program in December:
https://bugzilla.mozilla.org/show_bug.cgi?id=1325532
and, I think, announced their intention in a publicly-minuted meeting of
the CAB Forum in Redmond in mid-October 2016.

> - No disclosure has been made regarding what specific items were
> acquired, including such things as: "private key material" (HSM's and
> whatnot); computer equipment used as web servers, OCSP responders, etc.;
> domain names, IP addresses, and other infrastructure used in the
> operations and maintenance of the acquired roots; data such as
> subscriber lists, databases, server logs, payment details and histories,
> certificate issuance activities and histories, etc.; any access rights
> to physical space such as offices, data centers, development and test
> facilities, and so forth; and last, but not least, any personnel,
> documentation, training materials, or other knowledge products.

I have not seen such disclosure.

> - The scope of impact to existing GlobalSign customers is not known.

Well, as Globalsign continues to operate those subCAs, I would hope the
impact on GlobalSign customers is minimal.

> Neither GMO GlobalSign nor Google have notified any existing clients of
> the acquisition.

Unless we hear from such clients, we can't know this one way or the other.

> - The GlobalSign web site has no mention of this acquisition for reasons
> which are unknown. 

Why would this be a requirement by anyone?

> Further, the web site does not make their CP/CPS
> documents readily available 

Which website? The CP/CPS documents for which root(s)?

The GTS CP and CPS are here: http://pki.goog/.

> - A relying party who takes the initiative to review a certificate chain
> that goes up to either of the acquired roots will see that it is
> anchored (or "verified by") GlobalSign. No mention of Google will be
> made anywhere in the user interface.

I would expect there to be intermediate certificates with Google's name
in; it's not permitted to issue EE certs directly from a root. However,
neither GlobalSign's nor Google's name would appear in primary UI in
Firefox, as we don't display CA names.

> - Google has acquired these roots in order to better serve their
> subscribers, which are organizations (not people) throughout the many
> Google companies. 

That's a question for Google.

> Relying parties (i.e. end users of the various Google
> products) are not affected positively or negatively by this acquisition.

That's a matter of opinion :-)

> - Mozilla granted Google's request to keep the acquisition confidential
> based on statements made by Google and Google's auditor E 

That implies a cause and effect which is not present in the way
suggested. We require that changes of ownership be disclosed, but we
don't require them to be made public. Google and GlobalSign disclosed
this change of ownership in accordance with our requirements. We also
expect to see various audits which meet our auditing requirements over
any transition period; my understanding is that Kathleen was satisfied
with the documentation she saw. However, the keeping confidential of the
acquisition was not conditioned on the presentation of audit documentation.

> Neither
> GlobalSign nor their auditors offered any opinion on this matter.

Would you expect them to?

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

Re: Google Trust Services roots

[Peter Kurrasch via dev-security-policy]

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 
for the various products and services they choose to offer.- No 
public announcement of the acquisition was made prior to January 26, 2017 via 
the Google security blog.- No disclosure has been made regarding what 
specific items were acquired, including such things as: private key 
material (HSMs and whatnot); computer equipment used as web 
servers, OCSP responders, etc.; domain names, IP addresses, and other 
infrastructure used in the operations and maintenance of the acquired roots; 
data such as subscriber lists, server logs, payment details and histories, 
certificate issuance activities and histories, etc.; and any access rights to 
physical space such as offices, data centers, development and test facilities, 
and so forth.- The scope of impact to existing GlobalSign customers 
is not known. Neither GMO GlobalSign nor Google have notified any existing 
clients of the acquisition.- The GlobalSign web site has no mention 
of this acquisition for reasons which are unknown. Further, the web site does 
not make their CP/CPS documents readily available limiting the ability for 
current subscribers and relying parties to decide if continued use of a cert 
chaining up to these roots is acceptable for them.- A relying party 
who actually takes the initiative to review a certificate chain will see that 
it is anchored (or verified by) GlobalSign. No mention of Google 
will be made anywhere.- Google has acquired these roots in order to 
better serve their subscribers, which are organizations (not 
people) throughout the many Google companies. Relying parties are not affected 
positively or negatively by this acquisition. - Mozilla granted 
Googles request to keep the acquisition confidential based on statements 
made by Google and Googles auditor EY. GlobalSign nor their auditors 
offered any opinion on this matter.Iapos;m trying to keep 
score here but am having difficulties. Can someone confirm if the following 
statements are correct:br/br/- 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 for the 
various products and services they choose to offer.br/br/- No 
public announcement of the acquisition was made prior to January 26, 2017 via 
the Google security blog.br/br/- No disclosure has been made 
regarding what specific items were acquired, including such things as: 
quot;private key materialquot; (HSMapos;s and whatnot); computer 
equipment used as web servers, OCSP responders, etc.; domain names, IP 
addresses, and other infrastructure used in the operations and maintenance of 
the acquired roots; data such as subscriber lists, server logs, payment details 
and histories, certificate issuance activities and histories, etc.; and any 
access rights to physical space such as offices, data centers, development and 
test facilities, and so forth.br/br/- The scope of impact to 
existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google 
have notified any existing clients of the acquisition.br/br/- 
The GlobalSign web site has no mention of this acquisition for reasons which 
are unknown. Further, the web site does not make their CP/CPS documents readily 
available limiting the ability for current subscribers and relying parties to 
decide if continued use of a cert chaining up to these roots is acceptable for 
them.br/br/- A relying party who actually takes the initiative 
to review a certificate chain will see that it is anchored (or 
quot;verified byquot;) GlobalSign. No mention of Google will be made 
anywhere.br/br/- Google has acquired these roots in order to 
quot;better servequot; their subscribers, which are organizations 
(not people) throughout the many Google companies. Relying parties are not 
affected positively or negatively by this acquisition. br/br/- 
Mozilla granted Googleapos;s request to keep the acquisition confidential 
based on statements made by Google and Googleapos;s auditor Eamp;Y. 
GlobalSign nor their auditors offered any opinion on this 
matter.br/br/br/
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 does not resolve the concern.  The BRs require an "an unbroken



sequence of audit periods".  Given that GlobalSign clearly cannot make



any assertion about the roots after 11 August 2016, you would have a



gap from 11 August 2016 to 30 September 2016 in your sequence of audit



periods if your next report runs 1 October 2016 to 30 September 2017.



I understand your point but this is not entirely accurate. Our strategy, to
ensure a smooth transition, which was reviewed with the auditors and root
program administrators was that we take possession of the root key material
and manage it offline, in accordance with our existing WebTrust audit and
the “Key Storage, Backup and Recovery Criterion”.  It was our, and EY's
opinion that the existing controls and ongoing WebTrust audits were
sufficient given this plan and scope.

As such, during the period in question, the existing audits provide an
un-broken sequence of audit periods.

That said, we will follow-up with our auditors to see if it is possible to
extend the scope of our 2017 audit to also cover this interval to ensure
the community has further assurances of continuity.


pzb: Based on my personal experience, it is possible to negotiate a deal



and set a closing date in the future.  This is standard for many



acquisitions; you frequently see purchases announced with a closing



date in the future for all kinds of deals.  The gap between signing



the deal and closing gives acquirers the opportunity to complete the



steps in B.


As I stated, I think that moving forward this could be a good policy
change, I am hesitant to see any user agent adopt policies that are overly
prescriptive of commercial terms between two independent parties.



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
this could be comparable to similar requirements imposed on some
physical objects that can have public interest implications.




pzb: You appear to be confusing things here.  "Subordinate CA Certificate



Life Cycle Management" is the portion of the WebTrust criteria that



covers the controls around issuing certificates with the cA component



of the basicConstraints extension set to true.  It has nothing to do



with operating a subordinate CA.


I am familiar with the "Subordinate CA Certificate Life Cycle Management"
controls

I just should have been more explicit in my earlier response.

These keys were generated and stored in accordance with Asset
Classification and Management Criterion, and Key Storage, Backup and
Recovery Criterion.

Before utilizing the associated keys in any activity covered by the
“Subordinate CA

Certificate Life Cycle Management” criterion all associated policies and
procedures were

created, tested and then reviewed by our auditors. Additionally, those
auditors were

present during the associated ceremony. All such activities which will be
covered under

our 2017 audit.

This is similar to how a CA can, and does, revise and extend their policies
between

audits to cover new products and services.

This is consistent with the approach we discussed, and had approved with
the various root program administrators.



pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the



applicable CPS for your _root CAs_ between 11 August 2016 and 8



December 2016.  The Google CPS makes these statements.  Therefore, you



are stating that the roots (not just GIA G2) were only permitted to



issue Certificates to Google and Google Affiliates.


Correct, these roots were not used to issue certificates at all until last
week and when one was used, it was used to issue a subordinate CA
certificate to Google.

Though we do not have a product or service to announce currently, we can
say we will expand the  use of GTS beyond GIAG2, at which time policies,
procedures, CP and CPS will be updated accordingly. This progression makes
sense as we're moving from a constrained intermediate to a Root.


Mozilla has consistently taken the position that roots that exclusively

issue to a


single company are not acceptable in the root program.


Google and its affiliate companies are more than a single company.

Additionally, clearly the intent of this rule is to prevent thousands of
organizations issuing a handful of certificates polluting the root store.

In the case of Google and its Affiliate companies, we operate products and
services for our

customers. This is similar to how Amazon and a number of other root

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> 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 require an "an unbroken

> sequence of audit periods".  Given that GlobalSign clearly cannot make

> any assertion about the roots after 11 August 2016, you would have a

> gap from 11 August 2016 to 30 September 2016 in your sequence of audit

> periods if your next report runs 1 October 2016 to 30 September 2017.


I understand your point but this is not entirely accurate. Our strategy, to
ensure a smooth transition, which was reviewed with the auditors and root
program administrators was that we take possession of the root key material
and manage it offline, in accordance with our existing WebTrust audit and
the “Key Storage, Backup and Recovery Criterion”.  It was our, and EY's
opinion that the existing controls and ongoing WebTrust audits were
sufficient given this plan and scope.

As such, during the period in question, the existing audits provide an
un-broken sequence of audit periods.

That said, we will follow-up with our auditors to see if it is possible to
extend the scope of our 2017 audit to also cover this interval to ensure
the community has further assurances of continuity.

> pzb: Based on my personal experience, it is possible to negotiate a deal

> and set a closing date in the future.  This is standard for many

> acquisitions; you frequently see purchases announced with a closing

> date in the future for all kinds of deals.  The gap between signing

> the deal and closing gives acquirers the opportunity to complete the

> steps in B.

As I stated, I think that moving forward this could be a good policy
change, I am hesitant to see any user agent adopt policies that are overly
prescriptive of commercial terms between two independent parties.


> pzb: You appear to be confusing things here.  "Subordinate CA Certificate

> Life Cycle Management" is the portion of the WebTrust criteria that

> covers the controls around issuing certificates with the cA component

> of the basicConstraints extension set to true.  It has nothing to do

> with operating a subordinate CA.

I am familiar with the "Subordinate CA Certificate Life Cycle Management"
controls

I just should have been more explicit in my earlier response.

These keys were generated and stored in accordance with Asset
Classification and Management Criterion, and Key Storage, Backup and
Recovery Criterion.

Before utilizing the associated keys in any activity covered by the
“Subordinate CA

Certificate Life Cycle Management” criterion all associated policies and
procedures were

created, tested and then reviewed by our auditors. Additionally, those
auditors were

present during the associated ceremony. All such activities which will be
covered under

our 2017 audit.

This is similar to how a CA can, and does, revise and extend their policies
between

audits to cover new products and services.

This is consistent with the approach we discussed, and had approved with
the various root program administrators.


> pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the

> applicable CPS for your _root CAs_ between 11 August 2016 and 8

> December 2016.  The Google CPS makes these statements.  Therefore, you

> are stating that the roots (not just GIA G2) were only permitted to

> issue Certificates to Google and Google Affiliates.

Correct, these roots were not used to issue certificates at all until last
week and when one was used, it was used to issue a subordinate CA
certificate to Google.

Though we do not have a product or service to announce currently, we can
say we will expand the  use of GTS beyond GIAG2, at which time policies,
procedures, CP and CPS will be updated accordingly. This progression makes
sense as we're moving from a constrained intermediate to a Root.

> Mozilla has consistently taken the position that roots that exclusively
issue to a

> single company are not acceptable in the root program.

Google and its affiliate companies are more than a single company.

Additionally, clearly the intent of this rule is to prevent thousands of
organizations issuing a handful of certificates polluting the root store.

In the case of Google and its Affiliate companies, we operate products and
services for our

customers. This is similar to how Amazon and a number of other root
operators operate

products and services for their customers, the core difference being the
breadth of user

facing products we have.

> This does not address the question.  The Google CPS clearly states

> that it only covers the GIA G2 CA.  You have stated that the Google

> CPS (not the GTS CP/CPS) was the applicable CPS for your _root CAs_

> between 11 August 2016 and 8 December 2016.  This puts your statement

> at adds with what is written in 

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

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 them publicly. One letter is covering the key
> generation ceremony of the new roots, and another covering the transfer of
> the keys to our facilities. In this second report you will find the
> following statement:
>
> ```
> In our opinion, as of November 17, 2016, Google Trust Services LLC
> Management’s Assertion, as referred to above, is fairly stated, in all
> material respects, based on Certification Practices Statement Management
> Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key
> Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
> Criteria for Certification Authorities v2.0.
> ```

According to the opinion letter:

"followed the CA key generation and security requirements in its:
o 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 contract between
Google and GeoTrust, Inc., the Root CA."

Are you asserting that the authority for the key generation process
for the new Google roots is "the contract between Google and GeoTrust,
Inc."?

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

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

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 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.140.1.1 as being a valid OID for
>> EVcertificates for all EV-enabled roots
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).
>
>
>> 1) Do you consider it mis-issuance for Google to issue a certificate
>> containing the 2.23.140.1.1 OID?
>
>> 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).
>
>
> rmh: Yes. We believe that until we have:
>
> - The associated policies, procedures, and other associated work completed,
>
> - Have successfully completed an EV audit,
>
> - And have been approved by one or more of the various root programs as an
> EV issuer.
>
>
> That it would be an example of miss-issuance for us to issue such a
> certificate.

Given the EV-enabled status, this seems like a reasonable path forward.

>> pzb:  Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8
>> December 2016, Google Inc. operated these Roots according to Google Inc.’s
>> Certification Practice Statement."  The basic WebTrust for CA and WebTrust
>> BR audit reports for the period ending September 30, 2016 explicitly state
>> they are for "subordinate CA under external Root CA" and do not list the
>> roots in the GTS CPS at all.
>
>> rmh: I believe this will be answered by my responses to your third and
>> fourth observations.
>
>
>> It was not.
>
> 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 them publicly. One letter is covering the key
> generation ceremony of the new roots, and another covering the transfer of
> the keys to our facilities. In this second report you will find the
> following statement:
>
>
> ```
> In our opinion, as of November 17, 2016, Google Trust Services LLC
> Management’s Assertion, as referred to above, is fairly stated, in all
> material respects, based on Certification Practices Statement Management
> Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key
> Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
> Criteria for Certification Authorities v2.0.
> ```
>
> Based on our conversations with the various root program operator's prior to
> our acquisition it has been our plan and understanding, that we can utilize
> these opinion letters to augment the webtrust audit with the material
> details, relating to these activities. It is our hope that this also
> addresses you specific concern here.
>
>> 2) Will Google be publishing an audit report for a period starting 11
>> August 2016 that covers the transferred GS roots?  If so, can you
>> estimate the end of period date?
>
> rmh: It is our belief, based on our conversations with the various root
> store operators, as well as our own auditors that the transfer itself is
> covered by the opinion letters. With that said our audit period is October
> 1st to the end of September. The associated report will be released between
> October and November, depending on our auditors schedules.

This does not resolve the concern.  The BRs require an "an unbroken
sequence of audit periods".  Given that GlobalSign clearly cannot make
any assertion about the roots after 11 August 2016, you would have a
gap from 11 August 2016 to 30 September 2016 in your sequence of audit
periods if your next report runs 1 October 2016 to 30 September 2017.

>> pzb: I think that this is the key issue.  In my reading, "root
>> certificates" are not members of the program.  Rather organizations
>> (legal entities) are members and each member has some number of root
>> certificates.
>
>> Google was not a member of the program and had not applied to be a
>> member of the program at the time they received the roots already in
>> the program.  This seems problematic to me.
>
>> Policy Suggestion B) Require that any organization wishing to become a
>> member of the program submit a bug with links to content demonstrating
>> compliance with the Mozilla policy.  Require that this be public prior
>> to taking control of any root in the program.
>
>> Policy Suggestion C) Recognize that root transfers are distinct from
>> the acquisition of a program member.  Acquisition of a program member
>> (meaning purchase of the company) is a distinctly different activity
>> from moving only a private key, as the prior business controls no
>> longer apply in the 

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

> 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 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 audited, and nor is the rest of the hierarchy? 

Yes, that is correct.

> Gerv: Can you tell us what the planned start/end dates for the audit period 
> of 
> that annual audit are/will be? 

Our audit period is October 1st to the end of September. The associated report 
will be released between October and November, depending on our auditors 
schedules. 

> Gerv: Are the Google roots and/or the GlobalSign-acquired roots currently 
> issuing EE certificates? Were they issuing certificates between 11th 
August 2016 and 8th December 2016? 

No they were not issuing certificates between 11th August 2016 and 8th December 
2016.

We generated our first certificate, a subordinate CA, last week, that CA is not 
yet in use.

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

Re: Google Trust Services roots

[Ryan Hurst via dev-security-policy]

[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
other questions in a more prompt manner.

> pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for
EVcertificates for all EV-enabled roots
> (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923).

> 1) Do you consider it mis-issuance for Google to issue a certificate
containing the 2.23.140.1.1 OID?

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

rmh: Yes. We believe that until we have:
- The associated policies, procedures, and other associated work completed,
- Have successfully completed an EV audit,
- And have been approved by one or more of the various root programs as an
EV issuer.

That it would be an example of miss-issuance for us to issue such a
certificate.



> pzb:  Second, according to the GTS CPS v1.3, "Between 11 August 2016 and
8 December 2016, Google Inc. operated these Roots according to Google
Inc.’s Certification Practice Statement."  The basic WebTrust for CA and
WebTrust BR audit reports for the period ending September 30, 2016
explicitly state they are for "subordinate CA under external Root CA" and
do not list the roots in the GTS CPS at all.
>
> rmh: I believe this will be answered by my responses to your third and
fourth observations.

> It was not.

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 them publicly. One letter is covering the
key generation ceremony of the new roots, and another covering the transfer
of the keys to our facilities. In this second report you will find the
following statement:

```
In our opinion, as of November 17, 2016, Google Trust Services LLC
Management’s Assertion, as referred to above, is fairly stated, in all
material respects, based on Certification Practices Statement Management
Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key
Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and
Criteria for Certification Authorities v2.0.
```

Based on our conversations with the various root program operator's prior
to our acquisition it has been our plan and understanding, that we can
utilize these opinion letters to augment the webtrust audit with the
material details, relating to these activities. It is our hope that this
also addresses you specific concern here.


> 2) Will Google be publishing an audit report for a period starting 11
> August 2016 that covers the transferred GS roots?  If so, can you
> estimate the end of period date?

rmh: It is our belief, based on our conversations with the various root
store operators, as well as our own auditors that the transfer itself is
covered by the opinion letters. With that said our audit period is October
1st to the end of September. The associated report will be released between
October and November, depending on our auditors schedules.


> pzb: I think that this is the key issue.  In my reading, "root
> certificates" are not members of the program.  Rather organizations
> (legal entities) are members and each member has some number of root
> certificates.

> Google was not a member of the program and had not applied to be a
> member of the program at the time they received the roots already in
> the program.  This seems problematic to me.

> Policy Suggestion B) Require that any organization wishing to become a
> member of the program submit a bug with links to content demonstrating
> compliance with the Mozilla policy.  Require that this be public prior
> to taking control of any root in the program.

> Policy Suggestion C) Recognize that root transfers are distinct from
> the acquisition of a program member.  Acquisition of a program member
> (meaning purchase of the company) is a distinctly different activity
> from moving only a private key, as the prior business controls no
> longer apply in the latter case.

We discussed the topic of disclosure with the root program administrators
prior to our acquisition. Our goal was to tell the community as soon as
possible, the complexity of this transaction made it hard to get a hard
date for that announcement. Based on our conversations with root program
administrators we were told the policy did not require disclosure to be
public which left the timing of that notification up to us.

As for the recommendation to clarify the policy in this area, I think it
would be valuable to do that.

Both of your recommendations seem reasonable, my concern with B) is how to
do so in a way that does not make it impossible or even more complicated to
successfully negotiate such a 

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Peter Bowen via dev-security-policy]

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:
> 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 will not be issuing EV SSL certificates,
>> - Google will operate these roots under their own CP/CPS’s and associated 
>> OIDs,
>> - Google issuing a certificate with the GlobalSign OIDs would qualify as 
>> miss-issuance.
>>
>> That it would be acceptable for us not to undergo a EV SSL audit,
>> and that GlobalSign could keep the EV right for the associated subordinate
>> CA for the remaining validity period to facilitate the transition
>> (assuming continued compliance).
>
> 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 audited, and nor is the rest of the hierarchy?
>
>> When looking at this issue it is important to keep in mind Google has
>> operated a WebTrust audited subordinate CA under Symantec for quite a
>> long time. As part of this they have maintained audited facilities,
>> and procedures appropriate for offline key management, CRL/OCSP
>> generation, and other related activities. Based on this, and the
>> timing of both our audit, and key transfer all parties concluded it
>> would be sufficient to have the auditors provide an opinion letter
>> about the transfer of the keys and have those keys covered by the
>> subsequent annual audit.
>
> Can you tell us what the planned start/end dates for the audit period of
> that annual audit are/will be?
>
> Are the Google roots and/or the GlobalSign-acquired roots currently
> issuing EE certificates? Were they issuing certificates between 11th
> August 2016 and 8th December 2016?
>
> 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: Public disclosure of root ownership transfers (was: Re: Google Trust Services roots)

[Peter Bowen via dev-security-policy]

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 section".
>
> It may be that this document does need redoing in formal policy
> language. In the mean time, anyone uncertain about its meaning should
> ask Kathleen.

Gerv,

In addition to updating it to follow formal policy language, I would
suggest adding it directly to the policy.  As it stands today there
are 79 pages in the wiki starting with "CA:".  It simply isn't
possible to know which ones are effectively part of the policy and
which are other random things.  I realize building and maintaining
long policies is time consuming, but it is important to be clear.  CAs
are routinely called out for unclear or incomplete CPs and CPSes, so I
think it is fair to ask Browsers to have clear and complete trust
store policies.

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

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

[Inigo Barreira via dev-security-policy]

Yes, I know what happened but it´s not what the document says. Unless there´s 
another document, it seems to me that you haven´t acted according to what this 
page says. If I understand correcly, a should is a conditional and then it´s 
not a requirement. Furthermore there´s no indication on the consequences if you 
don´t do it, at least in this document. Maybe I´m missing some others, for 
sure, but i´d like to have the full picture.


Best regards

Iñigo Barreira
CEO
StartCom CA Limited

-Original Message-
From: dev-security-policy 
[mailto:dev-security-policy-bounces+inigo=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, Inigo Barreira wrote:
> I see many "should" in this link. Basically those indicating "should 
> notify Mozilla" and "should follow the physical relocation section".

It may be that this document does need redoing in formal policy language. In 
the mean time, anyone uncertain about its meaning should ask Kathleen.

> What does it happen if you don´t notify Mozilla?

Well, this was a factor in our dis-trust of WoSign and StartCom, so I guess the 
answer is "we take it seriously" :-)

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

Re: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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 it's in the category that is below the floor
acceptable for discussion in the group, because it's purely speculative and
without ability to evaluate.

It might be appropriate to raise as a "suggestion" during a public review
phase (which this is not), but that it's misleading and misrepresenting to
suggest it's an "issue" with any weight whatsoever, precisely because it's
absent factual detail and cannot be evaluated in any way - much like
statements such as "Government X might do Y to this CA", which is no more
valuable than a statement "Unicorns might exist and be morally repulsed by
this particular arrangement of words in the CPS". Yes, it's a possibility,
but it's in no way actionable, and it's certainly not appropriate to
suggest that, say, Mozilla should require the CA to change the sequence, to
avoid offending the Unicorns and thus bringing about the destruction of
Earth.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 dynamics
of large human organizations.  Presumably an organization of such
magnitude is likely to have contact points more dedicated to
time-sensitive action-required messages than the contact point they chose.

So while it's useful for you to draw attention to this, it's without

evidence or basis for you to suggest that this is an "issue", per se -
that is, it seemingly in no way conflicts with Mozilla policy or
industry practice.



I find that it is an issue, but not an absolute cause for rejection.





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.



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: Google Trust Services roots

[Ryan Sleevi via dev-security-policy]

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.  Presumably an organization of such
> magnitude is likely to have contact points more dedicated to
> time-sensitive action-required messages than the contact point they chose.
>
> So while it's useful for you to draw attention to this, it's without
>> evidence or basis for you to suggest that this is an "issue", per se -
>> that is, it seemingly in no way conflicts with Mozilla policy or
>> industry practice.
>>
>
> I find that it is an issue, but not an absolute cause for rejection.


I think Peter's response basically highlights why this is not an issue, at
least how Mozilla has historically determined them:

"I think the point is that issues raised about CAs need to be grounded in
fact.  "Universal Trust Services wrote Y in their CPS but did not do Y as
demonstrated by Z" is something that can be evaluated factually  "UTS wrote
Y in their CPS but might not being doing Y" without any evidence is not
something that can be evaluated factually."

Basically, the issue you're raising is, even in the most charitable sense,
not an actionable grounds for rejection - even in part - which you seem to
believe it is ("but not an absolute cause for rejection" - implying it
contributes to some sum total of issues). It might be an opportunity for
the CA to reconsider things, but in the same way that "But the Government
of X might require the CA to do something" is free of evidence and cannot
be evaluated factually, "But they might not abide by the BRs" is free of
evidence and cannot be evaluated factually. It's simply noise.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Inigo Barreira via dev-security-policy]

Gerv,

I see many "should" in this link. Basically those indicating "should notify
Mozilla" and "should follow the physical relocation section". But in
physical relocation and personnel changes sections it seems to me there´s a
contradiction because there are some must. Can you explain the differences?
According to the above mentioened there´s a should, so you´re able to not
follow what it´s indicated in the following ones, then the must does not
take effect, is this correct?
What does it happen if you don´t notify Mozilla?

Best regards

Iñigo Barreira
CEO
StartCom CA Limited


-Original Message-
From: dev-security-policy
[mailto:dev-security-policy-bounces+inigo=startcomca@lists.mozilla.org]
On Behalf Of Gervase Markham via dev-security-policy
Sent: viernes, 10 de febrero de 2017 10:48
To: Richard Wang <rich...@wosign.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 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 must do?
> (3) If a company is a public trusted CA, but distrusted by Mozilla, this
company acquired a trusted root key, what the company must do?

We do: https://wiki.mozilla.org/CA:RootTransferPolicy .

Gerv

___
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

Re: Google Trust Services roots

[Gervase Markham via dev-security-policy]

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 will not be issuing EV SSL certificates,
> - Google will operate these roots under their own CP/CPS’s and associated 
> OIDs,
> - Google issuing a certificate with the GlobalSign OIDs would qualify as 
> miss-issuance.
> 
> That it would be acceptable for us not to undergo a EV SSL audit,
> and that GlobalSign could keep the EV right for the associated subordinate
> CA for the remaining validity period to facilitate the transition
> (assuming continued compliance).

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 audited, and nor is the rest of the hierarchy?

> When looking at this issue it is important to keep in mind Google has
> operated a WebTrust audited subordinate CA under Symantec for quite a
> long time. As part of this they have maintained audited facilities,
> and procedures appropriate for offline key management, CRL/OCSP
> generation, and other related activities. Based on this, and the
> timing of both our audit, and key transfer all parties concluded it
> would be sufficient to have the auditors provide an opinion letter
> about the transfer of the keys and have those keys covered by the
> subsequent annual audit.

Can you tell us what the planned start/end dates for the audit period of
that annual audit are/will be?

Are the Google roots and/or the GlobalSign-acquired roots currently
issuing EE certificates? Were they issuing certificates between 11th
August 2016 and 8th December 2016?

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

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

[Gervase Markham via dev-security-policy]

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) before it happened, then you can see the problem.
> 
> Google says they took control on 11 August 2016.

So that's date A).

> On 19 October 2016, Google publicly stated "Update on the Google PKI:
> new roots were generated and web trust audits were performed, the
> report on this is forthcoming,"
> (https://cabforum.org/2016/10/19/2016-10-19-20-f2f-meeting-39-minutes/#Google)

Then you can consider this as Date B) :-)

> I appreciate the business realities of pre-disclosure, but that is not
> the case here.  There is no excuse for having taken control of
> existing roots and not disclosing such once they disclosed that they
> are intending to become a root CA.

This may or may not be what people think the policy _should_ be, but the
policy currently _is_ that disclosures of ownership change do not have
to be public. Mozilla does not require public disclosure of change of
ownership at any time.

Gerv

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

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

[Gervase Markham via dev-security-policy]

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 must do?
> (3) If a company is a public trusted CA, but distrusted by Mozilla, this 
> company acquired a trusted root key, what the company must do?

We do: https://wiki.mozilla.org/CA:RootTransferPolicy .

Gerv

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

Re: Google Trust Services roots

[Jakob Bohm via dev-security-policy]

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 misissuance directs visitors to a generic reporting page for
code vulnerabilities, which (by their nature) tends to require reaction
times measured in days/weeks rather than the 1 day maximum specified
in Google's CPS.


(To be clear, I am responding only as an individual, neither as Mozilla
peer or Google employee, although I recognize you will likely disregard
my remarks regardless.)

In the past, such comments have generally been seen as
offtopic/accusatory, because they are inherently absent of evidence of
any malfeasance. Indeed, your very comment seems to suggest that Google
is not adhering to its CP/CPS, but without evidence, and such
implication comes not based on any action that Google has taken, but
based on your view of what 'others' do or the 'class' of bugs.

I highlight this because we (the community) see the occasional remark
like this; most commonly, it's directed at organizations in particular
countries, on the basis that we shouldn't trust "them" because they're
in one of "those countries". However, the Mozilla policy is structured
to provide objective criteria and assessments of that.

In this case, I do not believe you are being accurate or fair to present
it as an "issue"; you are implying that Google will not adhere to its
CP/CPS, but without evidence. The nature of incident reporting via this
method may indeed be risky, but it's neither forbidden nor intrinsically
wrong. If you look at many members in the Mozilla program, you will see
far less specificity as to a problem report and the acceptable means of
reporting this.



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.  Presumably an organization of such
magnitude is likely to have contact points more dedicated to
time-sensitive action-required messages than the contact point they chose.


So while it's useful for you to draw attention to this, it's without
evidence or basis for you to suggest that this is an "issue", per se -
that is, it seemingly in no way conflicts with Mozilla policy or
industry practice.


I find that it is an issue, but not an absolute cause for rejection.


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