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