Re: Criticism of Google Re: Google Trust Services roots
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
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
On Tue, Apr 25, 2017 at 12:58 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Look at my two examples of past acquisitions. As far as I remember, in > neither case was the purchasing security company previously a trusted > CA, and they took over practically the whole operation with no initial > changes besides a name change. > Yes. And that worked out badly for security. Put differently, it sounds like you're suggesting it's more desirable to 'keep everything the same', when it is fairly consistent that only by changing and integrating is progress made and security achieved. Both VeriSign and Verizon are proof of the bad and the good. > 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. I'm afraid I've yet again lost the point you're trying to make. Perhaps it would help if I stated it differently: Peter's original suggestion was "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." This would cover the situation of formal restructuring - by providing a statement of continued commitment. This would cover the situation of merging/integration - by providing a statement of continued commitment. This would cover the situation of independent operation - by providing a statement of continued commitment. In response to this, you suggested "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," The first sentence has generally resulted in more harm than good. Combined with the second sentence, it appears you believe this would be the desirable outcome - moreso than a statement of continued commitment. I'm asking you what problem you were trying to solve, and how you sought to achieve that, because it would seem that your proposal, as an endorsement for 'independent' operation in such acquisitions, is generally more harmful than helpful to the Web PKI security. ___ 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
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
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
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
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
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 PMOn 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
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
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
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
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
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
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
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
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
sting customers who are left holding a soon-to-be worthless cert 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. 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
On Thursday, April 6, 2017 at 3:24:53 AM UTC+1, Peter Kurrasch wrote: > I have no issue with the situations you describe below. Mozilla should act to > encourage the good behaviors that we would want a new, acquiring CA to > exhibit while prohibiting the bad--or at least limiting the damage those 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 cert > > > > > 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. 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? Mozilla could change it policy to say that any newly acquired roots which are not bought by existing root members should have temporary distrust block placed on the root until new program member has met all the requirements defined in the root program inclusion policy and if the root member doesn't meet the requirements within x amount of time the root will be remove permanently from the root store. I understand this option would affect the existing subscribers using that particular root but we must maintain certain level of trust in the root program. ___ 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
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 agr
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. ___ 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
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
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
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
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
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
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
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
On 30/3/2017 4:01 μμ, Peter Kurrasch via dev-security-policy 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. 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? Hi Peter, This public discussion around the Root transfer, triggered an update in Mozilla's Root Transfer Policy <https://wiki.mozilla.org/CA:RootTransferPolicy>. Specifically (emphasis mine): "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. *" I believe this covers the "unknown" members to the Mozilla Root program quite well. I would also suggest that you try not to use existing Companies/Organizations as examples (although I also find it very tempting sometimes) because there may be misunderstandings :) Dimitris. Original Message From: Gervase Markham via dev-security-policy Sent: Thursday, March 30, 2017 1:06 AM To: mozilla-dev-security-pol...@lists.mozilla.org Reply To: Gervase Markham Subject: Re: Criticism of Google Re: Google Trust Services roots On 29/03/17 20:46, Peter 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
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 ; > 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
* 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
> 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@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 ; > 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
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 ; 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
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
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
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
Re: Criticism of Google Re: Google Trust Services roots
On 29/03/2017 20:52, Alex Gaynor wrote: I don't think it's a good idea to design our system around the idea of "What would a user be looking for if they read the cert chain manually". For example, in the US, if such a government agency chose to use a Government CA (as a user might reasonably 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
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
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
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
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
