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
Criticism of Google Re: Google Trust Services roots
(Renaming the thread to fork this particular discussion from any others on this transaction.)You raise a fair point, Ryan: I'm not well versed in how Let's Encrypt went about establishing their roots. I thought I had a good understanding but perhaps I had missed something. When I went to the Let's Encrypt site I found a diagram that showed one of their intermediates as cross-signed by IdenTrust; no mention of a root acquisition. Again, perhaps I've missed something so please let me know if that's the case. In a ironic way, this very uncertainty demonstrates the kind of confusion I was trying to highlight with my is-it-Google-or-GlobalSign comments.I think Kurt and I are on the same page regarding the precedent being established in this and prior acquisitions. In fact, I probably incorporated some of his points in my own commentary. I'm not sure if he'll agree with the what I view as the danger here: By purchasing a single root certificate, Google (and anyone else) is redefining the very concept of "trust anchor".Back in the early SSL days, one could look at the root cert, see the name on it, and decide right away if it's trustworthy ("oh yeah, I know VeriSign"). In other words, trust was contained entirely within the sequence of bytes that make up the root cert combined with one's own experience.A significant change to that model happened when CA companies began to be purchased by other companies. However, since they were complete acquisitions, it isn't so hard to add that one tidbit of knowledge to the thought process ("oh yeah, Symantec and VeriSign are the same"). So during this period of time trust was contained within the root certificate itself in conjunction with one's own experience and knowledge of CA company acquisitions.As more roots entered the scene, it became more frequent for one to encounter a root CA company that was unfamiliar. However, one could decide to ignore it because it was in another jurisdiction (country, government institution, etc.) that was not pertinent. Or one could, in fairly short order, do some Internet research on the CA company and make a decision--including possibly reading their CP/CPS. So, in essence, the anchor of trust is contained within the root cert combined with one's own knowledge, experience, and some research.Now, however, we are faced with a entirely different situation wherein the root certificate itself contributes little to establishing trust for a certificate chain. Any information contained in the cert is merely a starting point to research that particular cert: one must first determine who currently owns that root, possibly research the CA company if it's unfamiliar ("I know Google but what is this GTS all about?"), and probably find and read the CP/CPS to find the details about the new ownership ("so who is handling revocation now?").The kicker in all this is that one must perform these steps for every root one encounters, every time one encounters it: Did GlobalSign sell any other roots since the last time I checked? Has Google transferred ownership of the GlobalSign roots they purchased on to someone else? What about this Amazon root or Comodo or...?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.From: Kurt Roeckx via dev-security-policySent: Thursday, March 23, 2017 11:24 AMTo: mozilla-dev-security-pol...@lists.mozilla.orgReply To: Kurt RoeckxSubject: Re: Google Trust Services rootsOn 2017-03-23 16:39, Ryan Sleevi wrote:> On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy <> dev-security-policy@lists.mozilla.org> wrote:>>> I would be interested in knowing why Google felt it necessary to purchase>> an existing root instead of, for example, pursuing a "new root" path along>> the lines of what Let's Encrypt did? All I could gather from the Google>> security blog is that they really want to be a root CA and to do it in a>> hurry. Why the need to do it quickly, especially given the risks (attack>> surface)?>>> Clarification: I'm not speaking on behalf of Google>> I think this demonstrates a lack of understanding of what Let's
Re: Google Trust Services roots
On 27/03/17 23:18, okaphone.elektron...@gmail.com wrote: > Will that remain the responsibility of GlobalSign for any existing > certificates that have been signed with these roots? (Those would be > intermediate certificates, if I understand correctly.) Or does > revocation also require signing, and does it therefore become the > responsibility of the new owner of the roots? The latter - Mozilla would hold Google ultimately responsible for any revocation-related requirements in these hierarchies. (They may, of course, contract GlobalSign to manage some subset of it, but that's not our business). Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
It's probably my ignorance in these matters, but how does purchasing a root certificate affect revocation? Will that remain the responsibility of GlobalSign for any existing certificates that have been signed with these roots? (Those would be intermediate certificates, if I understand correctly.) Or does revocation also require signing, and does it therefore become the responsibility of the new owner of the roots? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Clarified on the new thread you started, but I don't believe there's any inconsistency. Further details on the new thread you started. On Mon, Mar 27, 2017 at 10:02 AM, Roland Fantasia via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Anyone care to comment on the fact that Google's new subCAs under the GTS > branding have inconsistent EKU and KU bits? What's more disturbing is FF > doesn't make a fuss about it when connecting to the test sites (after > adding the roots manually of course). > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Anyone care to comment on the fact that Google's new subCAs under the GTS branding have inconsistent EKU and KU bits? What's more disturbing is FF doesn't make a fuss about it when connecting to the test sites (after adding the roots manually of course). ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 2017-03-23 16:39, Ryan Sleevi wrote: On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: I would be interested in knowing why Google felt it necessary to purchase an existing root instead of, for example, pursuing a "new root" path along the lines of what Let's Encrypt did? All I could gather from the Google security blog is that they really want to be a root CA and to do it in a hurry. Why the need to do it quickly, especially given the risks (attack surface)? Clarification: I'm not speaking on behalf of Google I think this demonstrates a lack of understanding of what Let's Encrypt did. Let's Encrypt obtained a cross-signed certificate (from IdenTrust), which is "purchasing" a signature for their key. This is one approach. Purchasing a pre-existing signature (and key) is another. They are functionally equivalent. So what Google has done is what is what Let's Encrypt did. There are a few difference between the two: - With the signature from IdenTrust, Let's encrypt is not a trusted root CA, it's an intermediate CA. The ISRG also generated it's own root CA. - Let's encrypt has it's own name (Let's encrypt, ISRG) on the certificate. It's clear who the owner of the certificate it. It's not clear that a GlobalSign certificate is not owned or controlled by GlobalSign but instead by some other corporation that doesn't have any relation to the first. I find this second point rather annoying. As far as I know it's not the first time something like that happened. I would not have a problem with something like that if Google bought (all CAs from) GlobalSign, but I dislike that some CAs which appear to be from the same company are actually owned by several unrelated ones. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On Thu, Mar 23, 2017 at 8:37 AM, Peter Kurrasch via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I would be interested in knowing why Google felt it necessary to purchase > an existing root instead of, for example, pursuing a "new root" path along > the lines of what Let's Encrypt did? All I could gather from the Google > security blog is that they really want to be a root CA and to do it in a > hurry. Why the need to do it quickly, especially given the risks (attack > surface)? Clarification: I'm not speaking on behalf of Google I think this demonstrates a lack of understanding of what Let's Encrypt did. Let's Encrypt obtained a cross-signed certificate (from IdenTrust), which is "purchasing" a signature for their key. This is one approach. Purchasing a pre-existing signature (and key) is another. They are functionally equivalent. So what Google has done is what is what Let's Encrypt did. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
So this is the third of my 3 sets of criticisms regarding the acquisition of the GlobalSign roots by Google Trust Services. I apologize for the significant delay between the first 2 sets and this one. Hopefully people in the forum still feel this discussion relevant going forward even though the matter is considered resolved. Several of the comments I made regarding GlobalSign also apply to Google, especially the intermingling of the two brands. The implications of the confusion and uncertainty leading to an exploitable attack are just as applicable to Google as they are to GlobalSign. However, when you consider the stature of Google both on the Internet and in consumer products, the ramifications are more significant. Or, if you will, the attack surface is quite different than if GlobalSign were to purchase a root from, say, Symantec. I do fault Google for what I consider to be inadequate communication of the acquisition. This is not to say there's been no communication, just that I don't think it's enough, especially if you are not a CABF participant or don't keep up with Internet security news generally. Why not publish a message last October that regular folks on the Internet can understand? Why wait 3 months? Why expect people to dig through a CPS to find what should be readily available information? I would be interested in knowing why Google felt it necessary to purchase an existing root instead of, for example, pursuing a "new root" path along the lines of what Let's Encrypt did? All I could gather from the Google security blog is that they really want to be a root CA and to do it in a hurry. Why the need to do it quickly, especially given the risks (attack surface)? I also would like to know what the plan or expectation is regarding formal separation between the infrastructures of Google and GlobalSign. The overlap is an understandable necessity during the transition but nonetheless presents another opportunity for improper access, loss (leaking) of data, and perhaps other nefarious activities. And, does Google have a published policy regarding the information collected, stored, and analyzed when people access the CRL and OCSP distribution nodes? I do want to say I appreciate that someone with Ryan H.'s level of experience is involved in a transaction like this. There are undoubtedly many details to address that ensure a secure and proper transfer. I hope that someone on the GlobalSign side was equally experienced? The next time someone wants to purchase existing roots, the people involved might not have that same level of experience, and that should give everyone pause. Original Message From: Ryan Hurst via dev-security-policy Sent: Wednesday, March 8, 2017 12:02 PM To: mozilla-dev-security-pol...@lists.mozilla.org Reply To: Ryan Hurst Subject: Re: Google Trust Services roots > Jakob: An open question is how revocation and OCSP status for the > existing intermediaries issued by the acquired roots is handled. Google is responsible for producing CRLs for from these roots. We are also currently relying on the OCSP responder infrastructure of GlobalSign for this root but are In the process of migrating that inhouse. > Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) > URLs > listed in the CRL URL extensions in the GlobalSign operated non-expired > intermediaries? At this time Google produces CRLs and works with GlobalSign to publish those CRLs. > Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for > the > acquired roots. This level of detail is not typically included in a CPS, for example, a service may change Which internet service provider or CDN service they use and not need update their CP/CPS. > Jakob: Any relying party seeing the existing root in a chain would see the > name GlobalSign in the Issuer DN and naturally look to GlobalSign's > website and CP/CPS for additional information in trying to decide if > the chain should be trusted. The GlobalSign CPS indicates that the R2 and R4 are no longer under their control. Additionally given the long term nature of CA keys, it is common for the DN not to accurately represent the organization that controls it. As I mentioned in an earlier response in the 90’s I created roots for a company called Valicert that has changed hands several times, additionally Verisign, now Symantec in this context has a long history of acquiring CAs and as such they have CA certificates with many different names within them. > Jakob: A relying party might assume, without detailed checks, that these > roots > are operated exclusively by GlobalSign in accordance with GlobalSign's > good reputation. As the former CTO of GlobalSign I love hearing about their good reputation ;) However I would say the CP/CPS is the authoritative document h
Re: Google Trust Services roots
On 16/03/17 10:50, Gervase Markham wrote: > https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership With these changes and the filing of https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 , I consider this particular discussion RESOLVED. This means Mozilla plans to take no action against GTS based on what has been discovered and discussed. It doesn't mean people can't continue to make suggestions about improvements to our process, citing this situation. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 08/03/17 16:20, Gervase Markham wrote: > On 09/02/17 22:55, Peter Bowen wrote: >> Policy Suggestion A) When transferring a root that is EV enabled, it >> should be clearly stated whether the recipient of the root is also >> receiving the EV policy OID(s). > > I agree with this suggestion; we should update > https://wiki.mozilla.org/CA:RootTransferPolicy Now done: "When transferring ownership of a root that is EV-enabled, it should be clearly stated whether the recipient of the root is also receiving the (right to use the) EV policy OID(s) and, if so, it should be confirmed that they have or will get the relevant audits before issuing EV certs." > Again, would this be covered by a requirement that no issuance was > permitted from a transferred root until all the paperwork was in place, > including appropriately-scoped audits? This might lead to a PITRA, but > would not have to. Now done: "No issuance whatsoever is permitted from a root certificate which has changed ownership by being sold by one company to another (as opposed to by acquisition of the owning company) until the receiving company has demonstrated to Mozilla that they have all the appropriate audits, CP/CPS documents and other systems in place. In addition, if the receiving company is new to the Mozilla root program, there must also be a public discussion regarding their admittance to the root program." https://wiki.mozilla.org/CA:RootTransferPolicy#Change_in_Legal_Ownership Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 07/03/17 10:18, Gervase Markham wrote: > OK. Question for group: would it make sense to add the intermediate(s) > that GlobalSign is using for this purpose directly to the Mozilla trust > store, with the EV bit enabled, and then remove the EV bit from the > roots now owned by Google Trust Services? > > This would scope EV permissions more closely to the audits, and so > prevent Google from accidentally or intentionally issuing EV which was > shown as such in Firefox, without having an EV audit. Hearing no dissent, filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1347882 Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On Thu, Mar 9, 2017 at 11:02 PM, Jakob Bohm via dev-security-policy wrote: > > Of all these, Starfield seems to be the only case where a single CA > name now refers to two different current CA operators (GoDaddy and > Amazon). All the others are cases of complete takeover. None are > cases where the name in the certificate is a still operating CA > operator, but the root is actually operated by a different entity > entirely. There are a number of examples, but many of them are older and have been removed from trust stores (usually due to key size): Certplus - operated by both Docusign and Wosign Starfield - Go Daddy and Amazon TC TrustCenter - Symantec and Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe) USERTRUST UTN-USERFirst - Symantec and Comodo ValiCert - Go Daddy, SECOM, and RSA Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Criticism of GMO GlobalSign Re: Google Trust Services roots
This is my second of three forks of this discussion on the transfer of 2 GlobalSign roots. This thread focuses on GMO GlobalSign because in my estimation they have put themselves in a precarious position that warrants public discussion. In previous comments I've made, I've expressed disapproval at the fact that there is no mention of the transfer on GlobalSign's website. I did not find it under News and Events nor under the SSL sales pages nor under the Resources page. I also could find no information about the existence of different roots that GlobalSign has and their intended use cases.The search result that Ryan H. mentions below is in fact a curious situation. A direct link to the CPS is listed, sure, but if you go to the ".../resources" page directly there is no mention of the CPS. I would assume that at some point a subscriber is required to accept the terms of the CPS and is then presented with an opportunity to obtain the actual document, but what about the relying parties? Are relying parties allowed to obtain the document but only if they use a search engine to find it? Are we to expect that search engines will always and only return the correct version for the specific root in which I'm interested?To be fair, I don't know that any of this constitutes a violation of any BR requirement or Mozilla policy--I assume not. I also assume that GlobalSign is not the only offender in this regard. Still, I expect better than this from any root CA participant; surely a CA can give me something rather than leave me with nothing?All that said, it is not even what causes me the most concern, which is the intermingling of the GlobalSign and Google brands. Like it or not, there will always be questions like "Is this GlobalSign or is this Google?" and this creates a risk not only to GlobalSign but also the Internet community. (There is a risk to Google as well but I'll address that in a separate thread.)The risk is a result of the confusion and uncertainty that are introduced by the transfer of these 2 roots. Consider that right now I could launch a phishing campaign targeting GlobalSign subscribers with a message along the lines of "Did you know that GlobalSign has sold your certificate to Google? Click here to learn what you can do to protect your website." Should the person click on a link I might put the person on a fake login screen or a malware distribution point or engage in any other nefarious act of my choosing. For that matter I might try to sell the person my own certificate service: "Leave GlobalSign and Google behind! Protect the privacy of your website visitors and buy my service instead!"The point here is that accuracy in my message is not needed. Instead, I can exploit the confusion and uncertainty (or, if you prefer, FUD) which can lead to damage to GlobalSign's reputation and possible loss of business. Conceivably this can also impact the global PKI if I'm able to gain unauthorized access to a subscriber's account and have certificates issued for my nefarious websites.All of this to say that it actually is important that GlobalSign put messaging on their website and generally be proactive in limiting the chances for misinformation, confusion, and so forth to propagate across the Internet. The last thing I'll mention is that I have questions as to whether GlobalSign has violated either their own CPS or privacy policy when it comes to their subscribers. Admittedly I haven't had a chance to review either document so it's quite possible I'm misinformed and I hope someone will correct me as appropriate.But the basic reasoning goes that there are some people who don't like Google and perhaps have chosen to use GlobalSign because they are not Google. Personally I think GlobalSign has an obligation to notify their subscribers with something to the effect that "after a certain date we will be sharing your payment information, certificate history, domain ownership, login activity to our Web portal, etc. with Google." However, if there are statements in either the doc that have been violated, that is a more serious issue.The exact information being shared with (or is now available to) Google has not been publicly disclosed so I couldn't say for sure what should be communicated. Still, I imagine there are subscribers who would be surprised to learn that information they thought was constrained to just GlobalSign is no longer so. I think it's only fair that subscribers (and relying parties) be offered a chance to opt-out even if it means subscribers leaving GlobalSign for some other vendor. I don't know that such an offering has been made?I do hope that more can be publicly disclosed about what information is shared between GlobalSign and Google--including if the data sharing is related to only the 2 roots that were acquired or all GlobalSign roots.
RE: [FORGED] Criticism of Mozilla Re: Google Trust Services roots
> -Original Message- > From: dev-security-policy [mailto:dev-security-policy- > bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of Peter > Gutmann via dev-security-policy > Sent: Friday, March 10, 2017 4:15 AM > To: Gervase Markham ; Peter Kurrasch > > Cc: MozPol > Subject: Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots > > Kurrasch via dev-security-policy > writes: > > >* Types of transfers: I don't think the situation was envisioned where > >a single root would be transferred between entities in such a way that > >company names and branding would become intermingled. > > This has happened many times in the past, root certs have been sold and re- > sold for years. But I read Peter K's nuance as transfer of less than all the roots owned by a CA and/or less than all of the roots in a given brand. When GMO bought GlobalSign from Ubizen/Cybertrust, the entire brand went and GTE/Baltimore/Betrusted remained with Cybertrust. When Verizon transferred to DigiCert, the entire browser trust portfolio moved. > > >* Manner of transfer: As we learned from Ryan H., a second HSM was > >introduced for the transfer of the private key meaning that for a > >period of time 2 copies of the private key were in existence. > > I would be surprised if only two copies were in existence, given the value of > root keys I'd hope CAs have multiple backup copies. > In my past experience, backups, rather than temporary transfer artifacts, are logically, physically, and geographically isolated at rest. CAs that have been going concerns for many years may assume they intend to remain the owners of their roots until they expire. A shortcut results, certainly in the case of nCipher security worlds, where keys of common purpose and policy are mingled on common hardware, logically isolated by distinct m of n operator cardsets under an umbrella admin cardset. By design, that becomes a split between what is transacting and what is not. At some point in time, witnessed by an auditor, in an environment secured commensurate with the presence of enabled root keys, transferred keys may need to be extracted and tested before the original copies are destroyed with witness of that destruction and to the satisfaction of the root buyer. During that test window, two copies exist. Two copies should exist for that moment. Hot transfer of root keys from an HSM remaining in control of the seller and an HSM leaving with the buyer puts an entire PKI at risk. Copy, test, destroy is a recoverable scenario if a bad transfer and test occur. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Mozilla Re: Google Trust Services roots
On 10/03/17 06:41, Peter Kurrasch wrote: > * Types of transfers: I don't think the situation was envisioned where a > single root would be transferred between entities in such a way that > company names and branding would become intermingled. My own personal > opinion is that such intermingling is not in the public interest and should > be prohibited. That very likely could be too strong a stance for > Mozilla--which is fine--but it would be good to have Mozilla's position > clearly articulated should a situation like this arise again. Our position is that root transfers which mean the company named in the root is no longer an operator are an inevitable fact of life. Trying to stop them would have a number of negative effects, including making it harder for new entrants to join the WebPKI - and I'd say that recently new entrants have made a positive contribution to the security of the web. If Firefox ever displays the CA name in UI that ordinary users are likely to notice, we would need to take account of this issue. But we don't, so we don't. > * Manner of transfer: As we learned from Ryan H., a second HSM was > introduced for the transfer of the private key meaning that for a period of > time 2 copies of the private key were in existence. Presumably one copy > was destroyed at some point, but I'm not familiar with any relevant > standards or requirements to know when/how that takes place. Whatever the > case may be, this situation seems to fall outside of the Root Transfer > Policy as I now read it. [citation needed] > Also, did GlobalSign ever confirm to Mozilla that > they are no longer in possession of or otherwise have access to the private > key for those 2 roots? I'm not sure, but I'm pretty sure Google would have made pretty sure this was the case! :-) > * Conduct of the transfer: I think an expectation should be set that the > "current holder of the trust" must be the one to drive the transfer. Trust > can be handed to someone else; reaching in and taking trust doesn't sound > very...trustworthy? To that end, I think the policy should state that the > current root holder must do more than merely notify Mozilla about the > change in ownership; the holder (and their auditor) must provide the > audits, attestations, and answers to questions that come up. Only after > the transfer is complete would the "new holder" step in to perform those > duties. I think the policy already says this: "When the physical relocation involves moving the certificate's private key to another organization, the original organization who is transferring the root certificate’s private key must ensure that the transfer recipient is able to fully comply with Mozilla’s CA Certificate Policy. The original organization will continue to be responsible for the root certificate until the transfer recipient has provided Mozilla with their Primary Point of Contact, CP/CPS documentation, and audit statement (or opinion letter) confirming successful transfer of the root certificate and key." > * Public notification: I appreciate that confidentiality is required when > business transactions are being discussed but at some point, in the > interest of transparency, the public must be notified of the transfer. I > think this is implied (or assumed) in the current policy, but it might be > good to state explicitly that a public announcement must be made. I would > add that making an announcement at a CABF meeting is all well and good, but > considering that most people on the Internet are not able to attend those > meetings it would be good if an announcement could be made in other forums > as well. My proposal elsewhere in this thread is that any transferred cert not be allowed to issue until "all the paperwork is in place" from the new CA - which means providing Mozilla with the necessary CP/CPS, audits etc., which is inevitably a public process. I don't think we can legislate for a minimum level of media coverage. :-) Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: [FORGED] Criticism of Mozilla Re: Google Trust Services roots
Kurrasch via dev-security-policy writes: >* Types of transfers: I don't think the situation was envisioned where a >single root would be transferred between entities in such a way that company >names and branding would become intermingled. This has happened many times in the past, root certs have been sold and re- sold for years. >* Manner of transfer: As we learned from Ryan H., a second HSM was >introduced for the transfer of the private key meaning that for a period of >time 2 copies of the private key were in existence. I would be surprised if only two copies were in existence, given the value of root keys I'd hope CAs have multiple backup copies. Peter. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Criticism of Mozilla Re: Google Trust Services roots
Most are not directed at me so I won’t respond to each item, but for several I think I can provide some additional context, see below: > * Manner of transfer: As we learned from Ryan H., a second HSM was > introduced for the transfer of the private key meaning that for a period of > time 2 copies of the private key were in existence. Presumably one copy > was destroyed at some point, but I'm not familiar with any relevant > standards or requirements to know when/how that takes place. Whatever the > case may be, this situation seems to fall outside of the Root Transfer > Policy as I now read it. Also, did GlobalSign ever confirm to Mozilla that > they are no longer in possession of or otherwise have access to the private > key for those 2 roots? A few things are relevant to this comment. First, when designing a key management program for keys that may live ten or twenty years it is extremely important one builds a disaster recovery plan. Such plans require duplicate copies of keys exist. Basically no responsible CA would not have backups of their keys. Additionally given the reliability and performance requirements issuing CAs also, almost always, are deployed with a cluster of HSMs. The point of mentioning the above is that having multiple copies of keys is a standard practice. Regarding who has control over the associated keys, you are correct, as is the standard practice (this is my 8th transfer in my professional career) the process of transfer Involved reviewing the history and associated artifacts of the keys and ensuring, in the presence of our auditors, all copies not belonging to Google were destroyed. While I can not speak for GlobalSign I can state that I do know they notified all root relevant programs that they no longer have control of the associated keys. > * Conduct of the transfer: I think an expectation should be set that the > "current holder of the trust" must be the one to drive the transfer. Trust > can be handed to someone else; reaching in and taking trust doesn't sound > very...trustworthy? To that end, I think the policy should state that the > current root holder must do more than merely notify Mozilla about the > change in ownership; the holder (and their auditor) must provide the > audits, attestations, and answers to questions that come up. Only after > the transfer is complete would the "new holder" step in to perform those > duties. It is the expectation of the Mozilla Program as well as the Microsoft Program (and others) that the current holder of the trust drives the transfer. That was what happened in this case aswell. As was noted in the original thread Mozilla does not publicly require permission to be secured but does so privately and in this case that permission was secured, at least implicitly since we discussed with Mozilla our purchase numerous times before terms were reached. Other programs, such as Microsoft make this requirement public so we explicitly secured their permission before finalizing terms as well. While securing such permission complicates the the process I think the value to the ecosystem is warrents the complication and I think it makes sense for Mozilla to formalize their requirement to secure permission before a transfer. > * Public notification: I appreciate that confidentiality is required when > business transactions are being discussed but at some point, in the > interest of transparency, the public must be notified of the transfer. I > think this is implied (or assumed) in the current policy, but it might be > good to state explicitly that a public announcement must be made. I would > add that making an announcement at a CABF meeting is all well and good, but > considering that most people on the Internet are not able to attend those > meetings it would be good if an announcement could be made in other forums > as well. This representation misrepresents what notification has taken place, for others I suggest reading the other thread for a more accurate representation. To the specific policy suggestion, the fact that changes in the Mozilla program are all tracked via public channels like the bug database and this forum mean that today public notice is already mandated. There may be value in requiring something “larger” than that, but defining that in a concrete way is hard. In our case when we published our blog post it was picked up by many technical publications but that is because we are Google. In historic transfers of keys, the actors in the transfer were not as visible as Google and as such their public notices were, well... .not noticed. One thing that could be a reasonable step is to require that on their document repository, for some period of time after a transfer they maintain notice there. I am not sure this materially Moves the bar forward in that, I can say I have seen the web traffic for many repository pages for Some of the larger trust
Re: Google Trust Services roots
> Of all these, Starfield seems to be the only case where a single CA > name now refers to two different current CA operators (GoDaddy and > Amazon). All the others are cases of complete takeover. None are > cases where the name in the certificate is a still operating CA > operator, but the root is actually operated by a different entity > entirely. That is true, but my point is that one can not rely on the name in root certificates, when certs are made to be good for well over a decade the concept of name continuity just doesn't hold. > Also, I don't see Google on that list. I noticed that too, Ill be reaching out to Microsoft to make sure its updated. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 10/03/2017 07:29, Ryan Hurst wrote: On Thursday, March 9, 2017 at 9:00:21 PM UTC-8, Peter Kurrasch wrote: By definition, a CPS is the authoritative document on what root certificates a CA operates and how they go about that operation. If the GlobalSign CPS has been updated to reflect the loss of their 2 roots, that's fine. Nobody is questioning that. What is being questioned is whether updating the GlobalSign CPS is sufficient to address the needs, concerns, questions, or myriad other issues that are likely to come up in the minds of GlobalSign subscribers and relying parties--and, for that matter, Google's own subscribers and relying parties. To that, I think the answer must be: "no, it's not enough". Most people on the internet have never heard of a CPS and of those who have, few will have ever read one and fewer still will have read the GlobalSign CPS. Again while I can not speak for GlobalSign I can say that there has been far more public notice than a simple CP/CPS update. In addition to the Google Blog post about the acquisition (https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html), the purchase was picked up by many high profile technology news sources, some of which included: - https://www.theregister.co.uk/2017/01/27/google_root_ca/ - http://www.infoworld.com/article/3162102/security/google-moves-into-root-certificate-authority-business.html - http://www.securityweek.com/google-launches-its-own-root-certificate-authority Also this topic has been discussed at great length in numerous forums around the web. This is above and beyond the public notification that is built into the various root programs such as: The Google Trust Services CP/CPs lists GlobalSign as subordinates The Google Trust Services website has a link to the GlobalSign CP/CPS as well as their audit reports. The Mozilla bug on this topic discusses the change in ownership, The Mozilla CA registry will also reference the change in ownership, The Microsoft CA registry will also reference the change in ownership, The Mozilla Salesforce instance will reference the change in ownership, This public thread discusses the change in ownership. I am not sure there is much more meaningful options of notification left. Those are all point-in-time news items, not pages that purport to be up to date information of the current status when they are visited. Additionally as stated, EV badges will still correctly reflect that it is GlobalSign who issues the associated certificates, and not Google. The only opportunity for confusion comes from those who look at the certificates themselves and missed all of the above notifications. It is also important to note that this is a very common situation, to see how common it is visit the page Microsoft maintains for Root Program members - https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx You will notice the first column is the name of the current owner and the second column is the name in the certificate. A few you will notice are: Amazon, Starfield Services Root Certificate Authority - G2 Asseco Data Systems S.A. (previously Unizeto Certum), Certum CA Entrust, Trend Micro 1 Entrust, Trend Micro 2 Entrust, Trend Micro 3 Entrust, Trend Micro 4 Comodo, The USERTrust Network™ Comodo, USERTrust (Client Authentication / Secure Email) Comodo, USERTrust (Code Signing) Comodo, USERTrust RSA Certification Authority Comodo, UTN-USERFirst-Hardware Symantec / GeoTrust Symantec / Thawte Symantec / VeriSign Trustwave, XRamp Global Certification Authority And more... Of all these, Starfield seems to be the only case where a single CA name now refers to two different current CA operators (GoDaddy and Amazon). All the others are cases of complete takeover. None are cases where the name in the certificate is a still operating CA operator, but the root is actually operated by a different entity entirely. Also, I don't see Google on that list. While I sincerely want to make sure there are no surprises, given how common it is for names in root certificates not to match the current owner, those who are looking at certificate chains should not be relying on the value in the root certificate in the first place wrong in very significant situations. Ryan Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Criticism of Mozilla Re: Google Trust Services roots
I've changed the subject of this thread because I have criticisms of all 3 parties involved in this transaction and will be bringing them up separately. That said, "criticism" may be too strong a word in this case because I think I do understand and appreciate the position that Mozilla is in regarding confidential transactions such as this. And while Mozilla's actions seem perfectly reasonable, I can't help but think this transaction is a train wreck in the making. It would be good if Mozilla could prevent train wrecks when possible and to do so probably requires updates to the Root Transfer Policy. To that end, here are some thoughts to get things going: * Types of transfers: I don't think the situation was envisioned where a single root would be transferred between entities in such a way that company names and branding would become intermingled. My own personal opinion is that such intermingling is not in the public interest and should be prohibited. That very likely could be too strong a stance for Mozilla--which is fine--but it would be good to have Mozilla's position clearly articulated should a situation like this arise again. * Manner of transfer: As we learned from Ryan H., a second HSM was introduced for the transfer of the private key meaning that for a period of time 2 copies of the private key were in existence. Presumably one copy was destroyed at some point, but I'm not familiar with any relevant standards or requirements to know when/how that takes place. Whatever the case may be, this situation seems to fall outside of the Root Transfer Policy as I now read it. Also, did GlobalSign ever confirm to Mozilla that they are no longer in possession of or otherwise have access to the private key for those 2 roots? * Conduct of the transfer: I think an expectation should be set that the "current holder of the trust" must be the one to drive the transfer. Trust can be handed to someone else; reaching in and taking trust doesn't sound very...trustworthy? To that end, I think the policy should state that the current root holder must do more than merely notify Mozilla about the change in ownership; the holder (and their auditor) must provide the audits, attestations, and answers to questions that come up. Only after the transfer is complete would the "new holder" step in to perform those duties. * Public notification: I appreciate that confidentiality is required when business transactions are being discussed but at some point, in the interest of transparency, the public must be notified of the transfer. I think this is implied (or assumed) in the current policy, but it might be good to state explicitly that a public announcement must be made. I would add that making an announcement at a CABF meeting is all well and good, but considering that most people on the Internet are not able to attend those meetings it would be good if an announcement could be made in other forums as well. I imagine there are more things we'll want to discuss but hopefully this is enough to start the discussion. On Wed, Mar 8, 2017 at 9:54 AM, Gervase Markham wrote: > On 08/03/17 03:54, Peter Kurrasch wrote: > > - Google has acquired 2 root certificates from GMO GlobalSign but not > > the company itself. > > Yes. > > > GMO GlobalSign will continue to own other roots and > > will use only those other roots for the various products and services > > they choose to offer going forward. > > Not quite. GMO GlobalSign continues to control some subCAs of the roots > it sold to Google, and is using those (presumably) to wind down its > interest in those roots over time or support customer migrations to > other roots. This happens to include issuing EV certificates. > > > There is no affiliation or business > > relationship between GMO GlobalSign and Google after the completion of > > the acquisition. > > We don't have information on this; the terms of the deal, and indeed any > other deals the two companies may have made, are not public. > > > - No public announcement of the acquisition was made prior to January > > 26, 2017 via the Google security blog. > > Depends what you mean by announcement, but they applied in a public bug > for inclusion in the Mozilla root program in December: > https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 > and, I think, announced their intention in a publicly-minuted meeting of > the CAB Forum in Redmond in mid-October 2016. > > > - No disclosure has been made regarding what specific items were > > acquired, including such things as: "private key material" (HSM's and > > whatnot); computer equipment used as web servers, OCSP responders, etc.; > > domain names, IP addresses, and other infrastructure used in the > > operations and maintenance of the acquired roots; data such as > > subscriber lists, databases, server logs, payment details and histories, > > certificate issuance activities and histories, etc.; any access rights > > to physical space such as offices, data cente
Re: Google Trust Services roots
That is the Starfield Services EV policy identifier, not the Starfield EV policy identifier. We clearly call out in section 1.1 of the our CPS that Starfield Services Root Certificate Authority - G2 is covered under the CPS. On Thu, Mar 9, 2017 at 10:29 PM, Richard Wang wrote: > Good demo, thanks. > > I checked that you are using Startfield EV OID in Startfield name root and in > Amazon name root, means you are using the transferred root's EV OID. But I > checked your CPS that don't state this point, please advise, thanks. > > > Best Regards, > > Richard > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Friday, March 10, 2017 2:16 PM > To: Richard Wang > Cc: Ryan Sleevi ; Gervase Markham ; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Google Trust Services roots > > On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote: >> Why we setup one EV OID for all roots is that we use the same policy >> for all EV SSL certificate no matter it is issued by which root. The >> policy OID is unique ID >> >> If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, >> this means two companies use the same policy? >> >> It is better to do a test: Google issue a EV SSL certificate from this >> acquired root using the GlobalSign EV OID, then check every browser's UI >> display info, to check if that info will confuse the browser users. > > Richard, > > I'll make this easier: > > Go to https://good.sca1a.amazontrust.com/ and > https://good.sca0a.amazontrust.com/ in Safari and Microsoft IE/Edge. > Tell me which CA issued the certificates for those sites. (Note that we > don't send SCTs on those sites right now, so they aren't treated as EV in > Chrome, and we are still pending for EV in Mozilla) > > Thanks, > Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Google Trust Services roots
Good demo, thanks. I checked that you are using Startfield EV OID in Startfield name root and in Amazon name root, means you are using the transferred root's EV OID. But I checked your CPS that don't state this point, please advise, thanks. Best Regards, Richard -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Friday, March 10, 2017 2:16 PM To: Richard Wang Cc: Ryan Sleevi ; Gervase Markham ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote: > Why we setup one EV OID for all roots is that we use the same policy > for all EV SSL certificate no matter it is issued by which root. The > policy OID is unique ID > > If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, > this means two companies use the same policy? > > It is better to do a test: Google issue a EV SSL certificate from this > acquired root using the GlobalSign EV OID, then check every browser's UI > display info, to check if that info will confuse the browser users. Richard, I'll make this easier: Go to https://good.sca1a.amazontrust.com/ and https://good.sca0a.amazontrust.com/ in Safari and Microsoft IE/Edge. Tell me which CA issued the certificates for those sites. (Note that we don't send SCTs on those sites right now, so they aren't treated as EV in Chrome, and we are still pending for EV in Mozilla) Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On Thursday, March 9, 2017 at 9:00:21 PM UTC-8, Peter Kurrasch wrote: > By definition, a CPS is the authoritative document on what root > certificates a CA operates and how they go about that operation. If the > GlobalSign CPS has been updated to reflect the loss of their 2 roots, > that's fine. Nobody is questioning that. > > What is being questioned is whether updating the GlobalSign CPS is > sufficient to address the needs, concerns, questions, or myriad other > issues that are likely to come up in the minds of GlobalSign subscribers > and relying parties--and, for that matter, Google's own subscribers and > relying parties. To that, I think the answer must be: "no, it's not > enough". Most people on the internet have never heard of a CPS and of > those who have, few will have ever read one and fewer still will have read > the GlobalSign CPS. Again while I can not speak for GlobalSign I can say that there has been far more public notice than a simple CP/CPS update. In addition to the Google Blog post about the acquisition (https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html), the purchase was picked up by many high profile technology news sources, some of which included: - https://www.theregister.co.uk/2017/01/27/google_root_ca/ - http://www.infoworld.com/article/3162102/security/google-moves-into-root-certificate-authority-business.html - http://www.securityweek.com/google-launches-its-own-root-certificate-authority Also this topic has been discussed at great length in numerous forums around the web. This is above and beyond the public notification that is built into the various root programs such as: > The Google Trust Services CP/CPs lists GlobalSign as subordinates > The Google Trust Services website has a link to the GlobalSign CP/CPS as well > as their audit reports. > The Mozilla bug on this topic discusses the change in ownership, > The Mozilla CA registry will also reference the change in ownership, > The Microsoft CA registry will also reference the change in ownership, > The Mozilla Salesforce instance will reference the change in ownership, > This public thread discusses the change in ownership. I am not sure there is much more meaningful options of notification left. Additionally as stated, EV badges will still correctly reflect that it is GlobalSign who issues the associated certificates, and not Google. The only opportunity for confusion comes from those who look at the certificates themselves and missed all of the above notifications. It is also important to note that this is a very common situation, to see how common it is visit the page Microsoft maintains for Root Program members - https://social.technet.microsoft.com/wiki/contents/articles/37425.microsoft-trusted-root-certificate-program-participants-as-of-march-9-2017.aspx You will notice the first column is the name of the current owner and the second column is the name in the certificate. A few you will notice are: Amazon, Starfield Services Root Certificate Authority - G2 Asseco Data Systems S.A. (previously Unizeto Certum), Certum CA Entrust, Trend Micro 1 Entrust, Trend Micro 2 Entrust, Trend Micro 3 Entrust, Trend Micro 4 Comodo, The USERTrust Network™ Comodo, USERTrust (Client Authentication / Secure Email) Comodo, USERTrust (Code Signing) Comodo, USERTrust RSA Certification Authority Comodo, UTN-USERFirst-Hardware Symantec / GeoTrust Symantec / Thawte Symantec / VeriSign Trustwave, XRamp Global Certification Authority And more... While I sincerely want to make sure there are no surprises, given how common it is for names in root certificates not to match the current owner, those who are looking at certificate chains should not be relying on the value in the root certificate in the first place wrong in very significant situations. Ryan ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On Wed, Mar 8, 2017 at 10:14 PM, Richard Wang wrote: > Why we setup one EV OID for all roots is that we use the same policy for all > EV SSL certificate no matter it is issued by which root. The policy OID is > unique ID > > If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, > this means two companies use the same policy? > > It is better to do a test: Google issue a EV SSL certificate from this > acquired root using the GlobalSign EV OID, then check every browser's UI > display info, to check if that info will confuse the browser users. Richard, I'll make this easier: Go to https://good.sca1a.amazontrust.com/ and https://good.sca0a.amazontrust.com/ in Safari and Microsoft IE/Edge. Tell me which CA issued the certificates for those sites. (Note that we don't send SCTs on those sites right now, so they aren't treated as EV in Chrome, and we are still pending for EV in Mozilla) Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
By definition, a CPS is the authoritative document on what root certificates a CA operates and how they go about that operation. If the GlobalSign CPS has been updated to reflect the loss of their 2 roots, that's fine. Nobody is questioning that. What is being questioned is whether updating the GlobalSign CPS is sufficient to address the needs, concerns, questions, or myriad other issues that are likely to come up in the minds of GlobalSign subscribers and relying parties--and, for that matter, Google's own subscribers and relying parties. To that, I think the answer must be: "no, it's not enough". Most people on the internet have never heard of a CPS and of those who have, few will have ever read one and fewer still will have read the GlobalSign CPS. It would be good if you could elaborate more on what steps Google will be taking to communicate to the general public that GlobalSign means GlobalSign except when it means Google and that sometimes Google will mean GlobalSign as well. On Wed, Mar 8, 2017 at 12:02 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Jakob: An open question is how revocation and OCSP status for the > > existing intermediaries issued by the acquired roots is handled. > > Google is responsible for producing CRLs for from these roots. We are also > currently > relying on the OCSP responder infrastructure of GlobalSign for this root > but are > In the process of migrating that inhouse. > > > Jakob: Does GTS sign regularly updated CRLs published at the > (GlobalSign) URLs > > listed in the CRL URL extensions in the GlobalSign operated non-expired > > intermediaries? > > At this time Google produces CRLs and works with GlobalSign to publish > those CRLs. > > > Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS > for the > > acquired roots. > > This level of detail is not typically included in a CPS, for example, a > service may change > Which internet service provider or CDN service they use and not need > update their CP/CPS. > > > > Jakob: Any relying party seeing the existing root in a chain would see > the > > name GlobalSign in the Issuer DN and naturally look to GlobalSign's > > website and CP/CPS for additional information in trying to decide if > > the chain should be trusted. > > The GlobalSign CPS indicates that the R2 and R4 are no longer under their > control. > > Additionally given the long term nature of CA keys, it is common for the > DN not to accurately > represent the organization that controls it. As I mentioned in an earlier > response in the 90’s I > created roots for a company called Valicert that has changed hands several > times, additionally > Verisign, now Symantec in this context has a long history of acquiring CAs > and as such they > have CA certificates with many different names within them. > > > Jakob: A relying party might assume, without detailed checks, that these > roots > > are operated exclusively by GlobalSign in accordance with GlobalSign's > > good reputation. > > As the former CTO of GlobalSign I love hearing about their good reputation > ;) > > However I would say the CP/CPS is the authoritative document here and since > GMO GlobalSign CP/CPS clearly states the keys are no longer in their > control I believe this > Should not be an issue. > > > Jakob: Thus a clear notice that these "GlobalSign roots" are no longer > > operated by GlobalSign at any entrypoint where a casual relying party > > might go to check who "GlobalSign R?" is would be appropriate. > > I would argue the CA’s CP/CPS’s are the authoritative documents here and > would > Satisfy this requirement. > > > Jakob: If possible, making Mozilla products present these as "Google", > not > > "GlobalSign" in short-form UIs (such as the certificate chain tree-like > > display element). Similarly for other root programs (for example, the > > Microsoft root program could change the "friendly name" of these). > > I agree with Jakob here, given the frequency in which roots change hands, > it would make > sense to have an ability to do this. Microsoft maintains this capability > that is made available > to the owner. > > There are some limitations relative to where this domain information is > used, for example > in the case of an EV certificate, if Google were to request Microsoft > use this capability the > EV badge would say verified by Google. This is because they display the > root name for the > EV badge. However, it is the subordinate CA in accordance with its CP/CPS > that is responsible > for vetting, as such the name displayed in this case should be GlobalSign. > > Despite these limitations, it may make sense in the case of Firefox to > maintain a similar capability. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-poli
Re: Google Trust Services roots
On 08/03/2017 18:12, Ryan Hurst wrote: jacob: Could a reasonably condition be that decision authority, actual and physical control for a root are not moved until proper root program coordination has been done (an action which may occur after/before the commercial conclusion of a transaction). From a business perspective this could be comparable to similar requirements imposed on some physical objects that can have public interest implications. Microsoft has a similar requirement in their program, we had to get permission from them before we could finalize commercial terms for this acquisition. I personally think this is a good policy and one I think Mozilla should adopt as well. It adds more complexity to these acquisitions in that one needs to get the approvals from multiple parties but I think that the value to the ecosystem warrants this complexity. Jacob: For clarity could Google and/or GTS issue a dedicated CP/CPS pair for the brief period where Google (not GTS) had control of the former GlobalSign root (such a CP/CPS would be particularly simple given that no certificates were issued). Such as CP/CPS should also clarify any practices and procedures for signing revocation related data (CRLs, OCSP responses, OCSP responder certificates) from that root during the transition. The CP/CPS would also need to somehow state that the former GlobalSign issued certificates remain valid, though no further such certificates were issued in this interim period. Similarly could Google and/or GTS issue a dedicated CP/CPS pair for the new roots during the brief period where Google (not GTS) had control of those new roots. While we want to work with the community to provide assurances we followed best practices and the required policies in this transfer I do not think this would provide any further insights. Before the transfer we, and our auditors, reviewed the CP/CPS, as well as the policies and procedures associated with the the management of these keys, and found them to be both compliant with both the requirements and best practices. In other words, both we, and our auditors, are stating, as supported by the opinion letter, that we believe the Google CP/CPS covered these keys during this period. If we created a new CP/CPS for that period it would, at best, be a subset of the Google CP/CPS and offer no new information other than the omission of a few details. Could you maybe clarify what your goals are with this request, with that we can potentially propose an alternate approach to address those concerns. This was merely suggested as a possible way to formally answer the fears and questions posed by others about the situation during the transition and the discussed inapplicability of some wording in the old Google CP/CPS to the new situation. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Clear, thanks. Best Regards, Richard > On 9 Mar 2017, at 22:05, Gervase Markham via dev-security-policy > wrote: > >> On 09/03/17 12:38, Richard Wang wrote: >> As my understanding, if WoSign buy an trusted EV enabled root key >> with EV OID today, then we can issue WoSign EV SSL cert using this EV >> OID tomorrow, the browser will display EV green bar. Right? > > Technically, you are correct - such certs would produce the EV UI. > However, if you didn't have an EV audit which covered the root, your > root would quickly get kicked out of the root programs. > > Gerv > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 09/03/17 12:38, Richard Wang wrote: > As my understanding, if WoSign buy an trusted EV enabled root key > with EV OID today, then we can issue WoSign EV SSL cert using this EV > OID tomorrow, the browser will display EV green bar. Right? Technically, you are correct - such certs would produce the EV UI. However, if you didn't have an EV audit which covered the root, your root would quickly get kicked out of the root programs. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
As my understanding, if WoSign buy an trusted EV enabled root key with EV OID today, then we can issue WoSign EV SSL cert using this EV OID tomorrow, the browser will display EV green bar. Right? If right, we like this policy, thanks. Best Regards, Richard > On 9 Mar 2017, at 19:51, Gervase Markham wrote: > >> On 09/03/17 02:15, Richard Wang wrote: >> So the policy can make clear that the root key transfer can't >> transfer the EV OID, the receiver must use its own EV policy OID for >> its EV SSL, the receiver can't use the transferor's EV OID. > > We could indeed write this into the policy, but it would have the effect > of stopping the receiver of the root from issuing EV certs until the > updated root store with the new policy OID mapping was in all Firefoxes. > Given that OIDs are just opaque identifiers, it seems unnecessary to > require this. > > What security or other problem is caused if e.g. Google were to use an > EV OID originally used by (or still used by) GlobalSign, assuming the > two companies agreed that was OK? > > Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Yes, it means the two companies used the same policy for issuance - as identified by that policy. Did you read the ETSI materials I suggested you do? Perhaps this would make it easier for you. I don't think encouraging a CA to misissue - which if you read other people's replies, you would see Ryan identified it as misissuance (but not for the reasons you note), is productive. Misissuing is very bad, as you hopefully know. If two certificates, from different organizations, have the same policy OID, it means they were issued in whatever manner necessary to comply with that OID at the time they were issued. And that's perfectly ok and not at all prohibited. If your worried that GlobalSign's policy might describe GlobalSign-only things, then you're forgetting GlobalSign can update their policy at any time. Just like we use the same CABF EV OID despite the policies for EV changing every time we update the EVG, at any point GlobalSign could indicate their EV OID "just" means following the EVGs, which any organization that is trusted to issue certificates can do at any time. On Thu, Mar 9, 2017 at 1:14 AM Richard Wang via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Why we setup one EV OID for all roots is that we use the same policy for > all EV SSL certificate no matter it is issued by which root. The policy OID > is unique ID > > If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, > this means two companies use the same policy? > > It is better to do a test: Google issue a EV SSL certificate from this > acquired root using the GlobalSign EV OID, then check every browser's UI > display info, to check if that info will confuse the browser users. > > > Best Regards, > > Richard > > -Original Message- > From: Peter Bowen [mailto:pzbo...@gmail.com] > Sent: Thursday, March 9, 2017 1:11 PM > To: Richard Wang > Cc: Ryan Sleevi ; Gervase Markham ; > mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Google Trust Services roots > > Richard, > > I'm afraid a few things are confused here. > > First, a single CA Operator may have multiple roots in the browser trust > list. Each root may list one or more certificate policies that map to the > EV policy. Multiple roots that follow the same policy may use the same > policy IDs and different roots from the same operator may use different > policies. > > For example, I see the following in the Microsoft trust list: > > CN=CA 沃通根证书,O=WoSign CA Limited,C=CN > CN=Class 1 Primary CA,O=Certplus,C=FR > CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN CN=CA WoSign > ECC Root,O=WoSign CA Limited,C=CN CN=Certification Authority of WoSign > G2,O=WoSign CA Limited,C=CN each of these has one EV mapped policy: > 1.3.6.1.4.1.36305.2 > > CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy > 1.3.6.1.4.1.34697.2.1 mapped to EV > CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy > 1.3.6.1.4.1.34697.2.2 mapped to EV > CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy > 1.3.6.1.4.1.34697.2.3 mapped to EV > CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy > 1.3.6.1.4.1.34697.2.4 mapped to EV > All of these are from the same company but each has their own policy > identifier. > > The information on "Identified by " in Microsoft's browsers > comes from the "Friendly Name" field in the trust list. For example the > friendly name of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign 1999". > > For something like the AffirmTrust example, they could easily sell one > root along with the exclusive right to use that root's EV OID without > impacting their other OIDs. > > Does that make sense? > > Thanks, > Peter > > On Wed, Mar 8, 2017 at 8:44 PM, Richard Wang via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > I don’t think so, please check this page: > https://cabforum.org/object-registry/ that listed most CA’s EV OID, and > all browsers ask for the CA’s own EV OID when applying inclusion and EV > enabled. So, as I understand that the browser display EV green bar and > display the “Identified by CA name” is based on this CA’s EV OID. > > > > > > > > I don’t think Symantec have the reason to use GlobalSign EV OID in its > EV SSL certificate, why Symantec don’t use his own EV OID? If Symantec > issued a EV SSL using GlobalSign's EV OID, I think IE browser will display > this EV SSL is identified by GlobalSign, not by Symantec. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 09/03/17 02:15, Richard Wang wrote: > So the policy can make clear that the root key transfer can't > transfer the EV OID, the receiver must use its own EV policy OID for > its EV SSL, the receiver can't use the transferor's EV OID. We could indeed write this into the policy, but it would have the effect of stopping the receiver of the root from issuing EV certs until the updated root store with the new policy OID mapping was in all Firefoxes. Given that OIDs are just opaque identifiers, it seems unnecessary to require this. What security or other problem is caused if e.g. Google were to use an EV OID originally used by (or still used by) GlobalSign, assuming the two companies agreed that was OK? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 08/03/17 17:43, Ryan Hurst wrote: >> Gerv: We do require this, but not publicly. I note and recognise Ryan's >> concern about requiring advance disclosure of private deals. I could see >> a requirement that a transferred root was not allowed to issue anything >> until the appropriate paperwork was publicly in place. Would that be >> suitable? > > Could you clarify what you mean by appropriate paperwork? Mozilla requires that roots in our program have certain paperwork in place in order to be issuing certs. We need the organization to publish a CP and CPS which relate to the root, and we need audits (ongoing or PITRA), and so on. That's what I mean. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 2017-03-09 05:21, Ryan Sleevi wrote: Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details. Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate. They describe the policies relative to how the certificate was issued and validated. This is much clearer if you read the relevant ETSI TS/EN series of docs related to Certificate Policies. To your point about identifying the issuer, I may be misunderstanding your point, but it sounds like you're just confused about how browsers work. Browsers don't look up the EV OID to determine who the issuer is, so if you're concerned that would present a problem, it doesn't. Instead, browsers look for *any* EV enabled OID in the leaf certificate, then attempt to build/verify that a chain can be built to one or more root certificates "enabled" for that OID. If they can, the leaf is called EV, and the browser determines who issued it by looking at the root. I would also like to see that all EV certificates actually have the CABF EV OID, possibly in addition to any CA specific OID. I would actually like to see that for all CABF OIDs, it's currently only required for the IV certificates as far as I know. Kurt ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Google Trust Services roots
Why we setup one EV OID for all roots is that we use the same policy for all EV SSL certificate no matter it is issued by which root. The policy OID is unique ID If Google use the GlobalSign EV OID, and GlobalSign also use this EV OID, this means two companies use the same policy? It is better to do a test: Google issue a EV SSL certificate from this acquired root using the GlobalSign EV OID, then check every browser's UI display info, to check if that info will confuse the browser users. Best Regards, Richard -Original Message- From: Peter Bowen [mailto:pzbo...@gmail.com] Sent: Thursday, March 9, 2017 1:11 PM To: Richard Wang Cc: Ryan Sleevi ; Gervase Markham ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots Richard, I'm afraid a few things are confused here. First, a single CA Operator may have multiple roots in the browser trust list. Each root may list one or more certificate policies that map to the EV policy. Multiple roots that follow the same policy may use the same policy IDs and different roots from the same operator may use different policies. For example, I see the following in the Microsoft trust list: CN=CA 沃通根证书,O=WoSign CA Limited,C=CN CN=Class 1 Primary CA,O=Certplus,C=FR CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN CN=CA WoSign ECC Root,O=WoSign CA Limited,C=CN CN=Certification Authority of WoSign G2,O=WoSign CA Limited,C=CN each of these has one EV mapped policy: 1.3.6.1.4.1.36305.2 CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.1 mapped to EV CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.2 mapped to EV CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.3 mapped to EV CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.4 mapped to EV All of these are from the same company but each has their own policy identifier. The information on "Identified by " in Microsoft's browsers comes from the "Friendly Name" field in the trust list. For example the friendly name of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign 1999". For something like the AffirmTrust example, they could easily sell one root along with the exclusive right to use that root's EV OID without impacting their other OIDs. Does that make sense? Thanks, Peter On Wed, Mar 8, 2017 at 8:44 PM, Richard Wang via dev-security-policy wrote: > I don’t think so, please check this page: > https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all > browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. > So, as I understand that the browser display EV green bar and display the > “Identified by CA name” is based on this CA’s EV OID. > > > > I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL > certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV > SSL using GlobalSign's EV OID, I think IE browser will display this EV SSL is > identified by GlobalSign, not by Symantec. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Richard, I'm afraid a few things are confused here. First, a single CA Operator may have multiple roots in the browser trust list. Each root may list one or more certificate policies that map to the EV policy. Multiple roots that follow the same policy may use the same policy IDs and different roots from the same operator may use different policies. For example, I see the following in the Microsoft trust list: CN=CA 沃通根证书,O=WoSign CA Limited,C=CN CN=Class 1 Primary CA,O=Certplus,C=FR CN=Certification Authority of WoSign,O=WoSign CA Limited,C=CN CN=CA WoSign ECC Root,O=WoSign CA Limited,C=CN CN=Certification Authority of WoSign G2,O=WoSign CA Limited,C=CN each of these has one EV mapped policy: 1.3.6.1.4.1.36305.2 CN=AffirmTrust Commercial,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.1 mapped to EV CN=AffirmTrust Networking,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.2 mapped to EV CN=AffirmTrust Premium,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.3 mapped to EV CN=AffirmTrust Premium ECC,O=AffirmTrust,C=US has policy 1.3.6.1.4.1.34697.2.4 mapped to EV All of these are from the same company but each has their own policy identifier. The information on "Identified by " in Microsoft's browsers comes from the "Friendly Name" field in the trust list. For example the friendly name of CN=Class 1 Primary CA,O=Certplus,C=FR is "WoSign 1999". For something like the AffirmTrust example, they could easily sell one root along with the exclusive right to use that root's EV OID without impacting their other OIDs. Does that make sense? Thanks, Peter On Wed, Mar 8, 2017 at 8:44 PM, Richard Wang via dev-security-policy wrote: > I don’t think so, please check this page: > https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all > browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. > So, as I understand that the browser display EV green bar and display the > “Identified by CA name” is based on this CA’s EV OID. > > > > I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL > certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV > SSL using GlobalSign's EV OID, I think IE browser will display this EV SSL is > identified by GlobalSign, not by Symantec. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Google Trust Services roots
I don’t think so, please check this page: https://cabforum.org/object-registry/ that listed most CA’s EV OID, and all browsers ask for the CA’s own EV OID when applying inclusion and EV enabled. So, as I understand that the browser display EV green bar and display the “Identified by CA name” is based on this CA’s EV OID. I don’t think Symantec have the reason to use GlobalSign EV OID in its EV SSL certificate, why Symantec don’t use his own EV OID? If Symantec issued a EV SSL using GlobalSign's EV OID, I think IE browser will display this EV SSL is identified by GlobalSign, not by Symantec. Best Regards, Richard From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, March 9, 2017 12:21 PM To: Gervase Markham ; Richard Wang ; Ryan Sleevi ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details. Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate. They describe the policies relative to how the certificate was issued and validated. This is much clearer if you read the relevant ETSI TS/EN series of docs related to Certificate Policies. To your point about identifying the issuer, I may be misunderstanding your point, but it sounds like you're just confused about how browsers work. Browsers don't look up the EV OID to determine who the issuer is, so if you're concerned that would present a problem, it doesn't. Instead, browsers look for *any* EV enabled OID in the leaf certificate, then attempt to build/verify that a chain can be built to one or more root certificates "enabled" for that OID. If they can, the leaf is called EV, and the browser determines who issued it by looking at the root. So if Symantec were to issue such a certificate using GlobalSign's EV OID, and Symantec's root was enabled for that OID, and it validated according to RFC5280 for that OID, then the certificate would appear as a Symantec-issued (because Symantec root) EV cert. Of course, I have oversimplified this for you - the actual UI browsers tend to take is not from the root, but from the issuing intermediate, or metadata external to the root, so it's also not an issue for the root to say Symantec, ValiCert, Equifax, Norton, or something else - because that's ignored when better data is available, and it always is, if the CA is responsive to root program requirements. On Wed, Mar 8, 2017 at 10:31 PM Richard Wang mailto:rich...@wosign.com>> wrote: Maybe I don’t say it clearly. The EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, right? Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV OID is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6 And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no CABF EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1 What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID for its EV SSL. So, no EV OID transfer issue for root key transfer. Best Regards, Richard From: Ryan Sleevi [mailto:r...@sleevi.com<mailto:r...@sleevi.com>] Sent: Thursday, March 9, 2017 11:14 AM To: Gervase Markham mailto:g...@mozilla.org>>; Richard Wang mailto:rich...@wosign.com>>; mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Google Trust Services roots Hi Richard, That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what you describe. Because of this, it's unclear to me, and I suspect many other readers, why you believe this is the case, or if you meant that it SHOULD be the case (for example, developing a new policy requirement), why you believe this. Perhaps you could share more details about your reasoning? On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: As I understand, the EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, so the root key transfer doesn't have the EV OID transfer case, CA can't transfer its own EV OID to other CA exception the CA is full acquired. So the policy can make clear that the root key transfer can't transfer the EV OID, the receiver must use its own EV policy OID for its EV SSL, the receiver can't u
Re: Google Trust Services roots
Well, you still said the same thing, and I understood what you said, but not why you said it or why you believe it. That's why I was asking for new details. Certificate Policy OIDs don't say who the certificate belongs to or who issued the certificate. They describe the policies relative to how the certificate was issued and validated. This is much clearer if you read the relevant ETSI TS/EN series of docs related to Certificate Policies. To your point about identifying the issuer, I may be misunderstanding your point, but it sounds like you're just confused about how browsers work. Browsers don't look up the EV OID to determine who the issuer is, so if you're concerned that would present a problem, it doesn't. Instead, browsers look for *any* EV enabled OID in the leaf certificate, then attempt to build/verify that a chain can be built to one or more root certificates "enabled" for that OID. If they can, the leaf is called EV, and the browser determines who issued it by looking at the root. So if Symantec were to issue such a certificate using GlobalSign's EV OID, and Symantec's root was enabled for that OID, and it validated according to RFC5280 for that OID, then the certificate would appear as a Symantec-issued (because Symantec root) EV cert. Of course, I have oversimplified this for you - the actual UI browsers tend to take is not from the root, but from the issuing intermediate, or metadata external to the root, so it's also not an issue for the root to say Symantec, ValiCert, Equifax, Norton, or something else - because that's ignored when better data is available, and it always is, if the CA is responsive to root program requirements. On Wed, Mar 8, 2017 at 10:31 PM Richard Wang wrote: > Maybe I don’t say it clearly. > > > > The EV SSL have two policy OID, one is the CABF EV OID, another one is the > CA's EV OID, right? > > Check the EV SSL for www.symantec.com, the CABF EV OID is 2.23.140.1.1, > and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6 > > And check www.gloabalsign.com EV SSL that no CABF EV OID, GlobalSign EV > OID is 1.3.6.1.4.1.4146.1.1 > > > > What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to > GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, > so Google can’t use this EV OID for its own EV SSL, Google must use its own > EV OID for its EV SSL. > > > > So, no EV OID transfer issue for root key transfer. > > > > > > Best Regards, > > > > Richard > > > > *From:* Ryan Sleevi [mailto:r...@sleevi.com] > *Sent:* Thursday, March 9, 2017 11:14 AM > *To:* Gervase Markham ; Richard Wang ; > mozilla-dev-security-pol...@lists.mozilla.org > > > *Subject:* Re: Google Trust Services roots > > > > Hi Richard, > > > > That's not how Certificate Policy OIDs work - either in the specifications > or in the Baseline Requirements. I'm also not aware of any program > requiring what you describe. > > > > Because of this, it's unclear to me, and I suspect many other readers, why > you believe this is the case, or if you meant that it SHOULD be the case > (for example, developing a new policy requirement), why you believe this. > > > > Perhaps you could share more details about your reasoning? > > > > On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > As I understand, the EV SSL have two policy OID, one is the CABF EV OID, > another one is the CA's EV OID, so the root key transfer doesn't have the > EV OID transfer case, CA can't transfer its own EV OID to other CA > exception the CA is full acquired. > > So the policy can make clear that the root key transfer can't transfer the > EV OID, the receiver must use its own EV policy OID for its EV SSL, the > receiver can't use the transferor's EV OID. > > Best Regards, > > Richard > > -Original Message- > From: dev-security-policy [mailto:dev-security-policy-bounces+richard= > wosign@lists.mozilla.org] On Behalf Of Gervase Markham via > dev-security-policy > Sent: Thursday, March 9, 2017 12:21 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Google Trust Services roots > > Having gained a good understanding of Peter and Ryan's positions, I think > I am now in a position to evaluate Peter's helpful policy suggestions. > > Whether or not we decide to make updates, as Kathleen pronounced herself > satisfied at the time with Google's presented documentation and migration > plan, it would be unreasonable for us to retroactively censure Google for > following that plan. > > On 09
RE: Google Trust Services roots
Maybe I don’t say it clearly. The EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, right? Check the EV SSL for www.symantec.com<http://www.symantec.com>, the CABF EV OID is 2.23.140.1.1, and the Symantec EV OID is 2.16.840.1.113733.1.7.23.6 And check www.gloabalsign.com<http://www.gloabalsign.com> EV SSL that no CABF EV OID, GlobalSign EV OID is 1.3.6.1.4.1.4146.1.1 What I mean is the GlobalSign EV OID 1.3.6.1.4.1.4146.1.1 is belong to GlobalSign that the browser can identity the EV SSL Issuer is GlobalSign, so Google can’t use this EV OID for its own EV SSL, Google must use its own EV OID for its EV SSL. So, no EV OID transfer issue for root key transfer. Best Regards, Richard From: Ryan Sleevi [mailto:r...@sleevi.com] Sent: Thursday, March 9, 2017 11:14 AM To: Gervase Markham ; Richard Wang ; mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots Hi Richard, That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what you describe. Because of this, it's unclear to me, and I suspect many other readers, why you believe this is the case, or if you meant that it SHOULD be the case (for example, developing a new policy requirement), why you believe this. Perhaps you could share more details about your reasoning? On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: As I understand, the EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, so the root key transfer doesn't have the EV OID transfer case, CA can't transfer its own EV OID to other CA exception the CA is full acquired. So the policy can make clear that the root key transfer can't transfer the EV OID, the receiver must use its own EV policy OID for its EV SSL, the receiver can't use the transferor's EV OID. Best Regards, Richard -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+richard<mailto:dev-security-policy-bounces%2Brichard>=wosign@lists.mozilla.org<mailto:wosign@lists.mozilla.org>] On Behalf Of Gervase Markham via dev-security-policy Sent: Thursday, March 9, 2017 12:21 AM To: mozilla-dev-security-pol...@lists.mozilla.org<mailto:mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: Google Trust Services roots Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions. Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan, it would be unreasonable for us to retroactively censure Google for following that plan. On 09/02/17 22:55, Peter Bowen wrote: > Policy Suggestion A) When transferring a root that is EV enabled, it > should be clearly stated whether the recipient of the root is also > receiving the EV policy OID(s). I agree with this suggestion; we should update https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it into the main policy when we fix https://github.com/mozilla/pkipolicy/issues/57 . ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto:dev-security-policy@lists.mozilla.org> https://lists.mozilla.org/listinfo/dev-security-policy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Hi Richard, That's not how Certificate Policy OIDs work - either in the specifications or in the Baseline Requirements. I'm also not aware of any program requiring what you describe. Because of this, it's unclear to me, and I suspect many other readers, why you believe this is the case, or if you meant that it SHOULD be the case (for example, developing a new policy requirement), why you believe this. Perhaps you could share more details about your reasoning? On Wed, Mar 8, 2017 at 9:15 PM Richard Wang via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > As I understand, the EV SSL have two policy OID, one is the CABF EV OID, > another one is the CA's EV OID, so the root key transfer doesn't have the > EV OID transfer case, CA can't transfer its own EV OID to other CA > exception the CA is full acquired. > > So the policy can make clear that the root key transfer can't transfer the > EV OID, the receiver must use its own EV policy OID for its EV SSL, the > receiver can't use the transferor's EV OID. > > Best Regards, > > Richard > > -Original Message- > From: dev-security-policy [mailto:dev-security-policy-bounces+richard= > wosign@lists.mozilla.org] On Behalf Of Gervase Markham via > dev-security-policy > Sent: Thursday, March 9, 2017 12:21 AM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Re: Google Trust Services roots > > Having gained a good understanding of Peter and Ryan's positions, I think > I am now in a position to evaluate Peter's helpful policy suggestions. > > Whether or not we decide to make updates, as Kathleen pronounced herself > satisfied at the time with Google's presented documentation and migration > plan, it would be unreasonable for us to retroactively censure Google for > following that plan. > > On 09/02/17 22:55, Peter Bowen wrote: > > Policy Suggestion A) When transferring a root that is EV enabled, it > > should be clearly stated whether the recipient of the root is also > > receiving the EV policy OID(s). > > I agree with this suggestion; we should update > https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually > incorporate it into the main policy when we fix > https://github.com/mozilla/pkipolicy/issues/57 . > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Google Trust Services roots
As I understand, the EV SSL have two policy OID, one is the CABF EV OID, another one is the CA's EV OID, so the root key transfer doesn't have the EV OID transfer case, CA can't transfer its own EV OID to other CA exception the CA is full acquired. So the policy can make clear that the root key transfer can't transfer the EV OID, the receiver must use its own EV policy OID for its EV SSL, the receiver can't use the transferor's EV OID. Best Regards, Richard -Original Message- From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosign@lists.mozilla.org] On Behalf Of Gervase Markham via dev-security-policy Sent: Thursday, March 9, 2017 12:21 AM To: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services roots Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions. Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan, it would be unreasonable for us to retroactively censure Google for following that plan. On 09/02/17 22:55, Peter Bowen wrote: > Policy Suggestion A) When transferring a root that is EV enabled, it > should be clearly stated whether the recipient of the root is also > receiving the EV policy OID(s). I agree with this suggestion; we should update https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it into the main policy when we fix https://github.com/mozilla/pkipolicy/issues/57 . ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
> Outside of EV, can you articulate why (preferably in a dedicated thread) > There have been requests over the years from a variety of CAs for this. > Each time, they've been rejected. If there's new information at hand, or a > better understanding of the landscape since then, it would be good to > articulate why, specifically for Mozilla products :) Outside EV I think it would be very hard to make the case, though Mozilla does maintain a certificate viewer that is easily accessible I have to imagine it is almost never used. As such, in the case of DV I think it would not make much sense. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On Wed, Mar 8, 2017 at 1:02 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > There are some limitations relative to where this domain information is > used, for example > in the case of an EV certificate, if Google were to request Microsoft > use this capability the > EV badge would say verified by Google. This is because they display the > root name for the > EV badge. However, it is the subordinate CA in accordance with its CP/CPS > that is responsible > for vetting, as such the name displayed in this case should be GlobalSign. > > Despite these limitations, it may make sense in the case of Firefox to > maintain a similar capability. Outside of EV, can you articulate why (preferably in a dedicated thread) There have been requests over the years from a variety of CAs for this. Each time, they've been rejected. If there's new information at hand, or a better understanding of the landscape since then, it would be good to articulate why, specifically for Mozilla products :) ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
> Jakob: An open question is how revocation and OCSP status for the > existing intermediaries issued by the acquired roots is handled. Google is responsible for producing CRLs for from these roots. We are also currently relying on the OCSP responder infrastructure of GlobalSign for this root but are In the process of migrating that inhouse. > Jakob: Does GTS sign regularly updated CRLs published at the (GlobalSign) > URLs > listed in the CRL URL extensions in the GlobalSign operated non-expired > intermediaries? At this time Google produces CRLs and works with GlobalSign to publish those CRLs. > Jakob: Hopefully these things are answered somewhere in the GTS CP/CPS for > the > acquired roots. This level of detail is not typically included in a CPS, for example, a service may change Which internet service provider or CDN service they use and not need update their CP/CPS. > Jakob: Any relying party seeing the existing root in a chain would see the > name GlobalSign in the Issuer DN and naturally look to GlobalSign's > website and CP/CPS for additional information in trying to decide if > the chain should be trusted. The GlobalSign CPS indicates that the R2 and R4 are no longer under their control. Additionally given the long term nature of CA keys, it is common for the DN not to accurately represent the organization that controls it. As I mentioned in an earlier response in the 90’s I created roots for a company called Valicert that has changed hands several times, additionally Verisign, now Symantec in this context has a long history of acquiring CAs and as such they have CA certificates with many different names within them. > Jakob: A relying party might assume, without detailed checks, that these > roots > are operated exclusively by GlobalSign in accordance with GlobalSign's > good reputation. As the former CTO of GlobalSign I love hearing about their good reputation ;) However I would say the CP/CPS is the authoritative document here and since GMO GlobalSign CP/CPS clearly states the keys are no longer in their control I believe this Should not be an issue. > Jakob: Thus a clear notice that these "GlobalSign roots" are no longer > operated by GlobalSign at any entrypoint where a casual relying party > might go to check who "GlobalSign R?" is would be appropriate. I would argue the CA’s CP/CPS’s are the authoritative documents here and would Satisfy this requirement. > Jakob: If possible, making Mozilla products present these as "Google", not > "GlobalSign" in short-form UIs (such as the certificate chain tree-like > display element). Similarly for other root programs (for example, the > Microsoft root program could change the "friendly name" of these). I agree with Jakob here, given the frequency in which roots change hands, it would make sense to have an ability to do this. Microsoft maintains this capability that is made available to the owner. There are some limitations relative to where this domain information is used, for example in the case of an EV certificate, if Google were to request Microsoft use this capability the EV badge would say verified by Google. This is because they display the root name for the EV badge. However, it is the subordinate CA in accordance with its CP/CPS that is responsible for vetting, as such the name displayed in this case should be GlobalSign. Despite these limitations, it may make sense in the case of Firefox to maintain a similar capability. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
> pzb: Policy Suggestion A) When transferring a root that is EV enabled, it > should be clearly stated whether the recipient of the root is also > receiving the EV policy OID(s). > Gerv: I agree with this suggestion; we should update > https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually > incorporate it into the main policy when we fix > https://github.com/mozilla/pkipolicy/issues/57 . I think this is good. > Gerv: https://wiki.mozilla.org/CA:RootTransferPolicy says that "The > organization who is transferring ownership of the root certificate’s > private key must ensure that the transfer recipient is able to fully > comply with Mozilla’s CA Certificate Policy. The original organization > will continue to be responsible for the root certificate's private key > until the transfer recipient has provided Mozilla with their Primary > Point of Contact, CP/CPS documentation, and audit statement (or opinion > letter) confirming successful transfer of the root certificate and key." > Gerv: I would say that an organization which has acquired a root certificate > in the program and which has provided Mozilla with the above-mentioned > information is thereby a member of the program. As the policy says that > the transferring entity continues to be responsible until the > information is provided, that seems OK to me. This seems reasonable to me also. > Gerv: This position would logically lead to the position that a root > inclusion > request from an organization which does not have any roots is also, > implicitly, an application to become a member of the program but the two > things are distinct. One can become a member of the program in other > ways. Membership is sort of something that happens to one automatically > when one successfully achieves ownership of an included root. This seems reasonable to me also. > pzb: Policy Suggestion B) Require that any organization wishing to become > a member of the program submit a bug with links to content > demonstrating compliance with the Mozilla policy. Require that this > be public prior to taking control of any root in the program. > Gerv: We do require this, but not publicly. I note and recognise Ryan's > concern about requiring advance disclosure of private deals. I could see > a requirement that a transferred root was not allowed to issue anything > until the appropriate paperwork was publicly in place. Would that be > suitable? Could you clarify what you mean by appropriate paperwork? > pzb: Policy Suggestion C) Recognize that root transfers are distinct from > the acquisition of a program member. Acquisition of a program > member (meaning purchase of the company) is a distinctly different > activity from moving only a private key, as the prior business > controls no longer apply in the latter case. > Gerv: https://wiki.mozilla.org/CA:RootTransferPolicy does make this distinction, I feel - how could it be better made? After re-reading this text I personally think this is clear. > pzb: Policy Suggestion D) Moving from being a RA to a CA or moving from > being a single tier/online (i.e. Subordinate-only) CA to being a > multi-tier/root CA requires a PITRA > Gerv: Again, would this be covered by a requirement that no issuance was > permitted from a transferred root until all the paperwork was in place, > including appropriately-scoped audits? This might lead to a PITRA, but > would not have to. This seems reasonable to me also. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Gerv has already responded and while his response is correct I have a little more detail I can share, see bellow. > Peter Kurrash: I'm trying to keep score here but am having difficulties. Can > someone confirm if > the following statements are correct: > - Google has acquired 2 root certificates from GMO GlobalSign but not the > company itself. Correct, two root certificates and their keys were acquired. > Peter Kurrash: GMO GlobalSign will continue to own other roots and will use > only those other roots for > the various products and services they choose to offer going forward. There > is no affiliation or business > relationship between GMO GlobalSign and Google after the completion of the > acquisition. Mostly correct, we do have a contractual obligation to GMO GlobalSign relative to the subordinate that exists under GlobalSign R2, that subordinate is owned and operated by GMO GlobalSign. The terms of this agreement require us to provide revocation services while they migrate their customers off. It also requires them to maintain their WebTrust accreditation. I must also add that Google is large organization and may now, or in the future, have other agreements with GMO GlobalSign but I can say those agreements would likely be orthogonal to this transaction. > Peter Kurrash:No public announcement of the acquisition was made prior to > January 26, 2017 > via the Google security blog. No, this is not correct, the first public announcement was at the CAB/Forum in mid October 2016 and the second was the Mozilla bug database on December 22nd, 2016. > Peter Kurrash: No disclosure has been made regarding what specific items were > acquired, > including such things as: "private key material" (HSM's and whatnot); > computer equipment used > as web servers, OCSP responders, etc.; domain names, IP addresses, and > other infrastructure > used in the operations and maintenance of the acquired roots; data such as > subscriber lists, > databases, server logs, payment details and histories, certificate issuance > activities and histories, > etc.; any access rights to physical space such as offices, data centers, > development and test > facilities, and so forth; and last, but not least, any personnel, > documentation, training materials, > or other knowledge products. That is correct, we did not enumerate the items > involved in the exchange. The auditor's opinion letter covering the transfer is the most explicit public document covering the transfer. I can say that the acquisition included the acquisition of the root key material and corresponding certificates. Additionally the transfer included tooling, documentation and training related to the aforementioned assets. The elements included were within the scope necessary to enable us to satisfy auditors of proper historical and future management of the associated keys. For those who are interested I can also add we did not purchase the GMO GlobalSign HSMs, instead we purchased our own HSMs directly from the manufacturer. These HSMs were compatible with what were in use by GMO GlobalSign and we utilized the key migration capabilities of those devices to migrate those keys to our HSMs. > Peter Kurrash: The scope of impact to existing GlobalSign customers is not > known. Neither > GMO GlobalSign nor Google have notified any existing clients of the > acquisition. I can not speak for GMO GlobalSign or what GMO GlobalSign has or has not told affected customers, that said I do know that they have updated their CP/CPS. I can say that our key migration plan was chosen, in part, to provide GMO GlobalSign enough time to migrate affected customers to CAs operated under their other roots. > Peter Kurrash: The GlobalSign web site has no mention of this acquisition > for reasons which are > unknown. Further, the web site does not make their CP/CPS documents readily > available limiting the > ability for current subscribers and relying parties to decide if continued > use of a cert chaining up to > these roots is acceptable to them. I can not speak for GMO GlobalSign or what GMO GlobalSign has or has not done, however a Google search of “GlobalSign CPS” has the first match of https://www.globalsign.com/en/repository/ which has their CP/CPS. Additionally I am not aware of a requirement to do notification, I would only expect notification if it materially impacted them and I personally would argue that since GMO GlobalSign continues to operate many other roots as well as the related sub CA there is not a material impact. > Peter Kurrash: A relying party who takes the initiative to review a > certificate chain that goes up to either > of the acquired roots will see that it is anchored (or "verified by") > GlobalSign. No mention of Google will > be made anywhere in the user > interface. GMO GlobalSign continues to maintain an active WebTrust audit for the CA under R2. As the operator of the issu
Re: Google Trust Services roots
> jacob: Could a reasonably condition be that decision authority, actual and > physical control for a root are not moved until proper root program > coordination has been done (an action which may occur after/before the > commercial conclusion of a transaction). From a business perspective > this could be comparable to similar requirements imposed on some > physical objects that can have public interest implications. Microsoft has a similar requirement in their program, we had to get permission from them before we could finalize commercial terms for this acquisition. I personally think this is a good policy and one I think Mozilla should adopt as well. It adds more complexity to these acquisitions in that one needs to get the approvals from multiple parties but I think that the value to the ecosystem warrants this complexity. > Jacob: For clarity could Google and/or GTS issue a dedicated CP/CPS pair for > the brief period where Google (not GTS) had control of the former > GlobalSign root (such a CP/CPS would be particularly simple given that > no certificates were issued). Such as CP/CPS should also clarify any > practices and procedures for signing revocation related data (CRLs, > OCSP responses, OCSP responder certificates) from that root during the > transition. The CP/CPS would also need to somehow state that the > former GlobalSign issued certificates remain valid, though no further > such certificates were issued in this interim period. > Similarly could Google and/or GTS issue a dedicated CP/CPS pair for the > new roots during the brief period where Google (not GTS) had control of > those new roots. While we want to work with the community to provide assurances we followed best practices and the required policies in this transfer I do not think this would provide any further insights. Before the transfer we, and our auditors, reviewed the CP/CPS, as well as the policies and procedures associated with the the management of these keys, and found them to be both compliant with both the requirements and best practices. In other words, both we, and our auditors, are stating, as supported by the opinion letter, that we believe the Google CP/CPS covered these keys during this period. If we created a new CP/CPS for that period it would, at best, be a subset of the Google CP/CPS and offer no new information other than the omission of a few details. Could you maybe clarify what your goals are with this request, with that we can potentially propose an alternate approach to address those concerns. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
> pzb: According to the opinion letter: > "followed the CA key generation and security requirements in its: > Google Internet Authority G2 CPS v1.4" (hyperlink omitted) > According to that CPS, "Key Pairs for the Google Internet Authority > are generated and installed in accordance with the contract between > Google and GeoTrust, Inc., the Root CA." > Are you asserting that the authority for the key generation process > the new Google roots is "the contract between Google and GeoTrust, > Inc."? No, that is not the intent of that statement, it is a good catch. This is simply a poorly worded statement. To clarify our acquisition of these keys and certificates are independent of our agreement with GeoTrust, Inc. The Intent of that statement is to say that the technical requirements of that contract, which in essence refer to meeting the WebTrust requirements, were followed. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 08/03/2017 16:54, Gervase Markham wrote: On 08/03/17 03:54, Peter Kurrasch wrote: - Google has acquired 2 root certificates from GMO GlobalSign but not the company itself. Yes. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products and services they choose to offer going forward. Not quite. GMO GlobalSign continues to control some subCAs of the roots it sold to Google, and is using those (presumably) to wind down its interest in those roots over time or support customer migrations to other roots. This happens to include issuing EV certificates. An open question is how revocation and OCSP status for the existing intermediaries issued by the acquired roots is handled. For example, does GTS or GlobalSign run active OCSP servers at the URLs listed in the AIA of the GlobalSign operated non-expired intermediaries that positively confirm the validity of each of those intermediaries? Does GTS sign regularly updated CRLs published at the (GlobalSign) URLs listed in the CRL URL extensions in the GlobalSign operated non-expired intermediaries? Hopefully these things are answered somewhere in the GTS CP/CPS for the acquired roots. ... ... - The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Why would this be a requirement by anyone? Any relying party seeing the existing root in a chain would see the name GlobalSign in the Issuer DN and naturally look to GlobalSign's website and CP/CPS for additional information in trying to decide if the chain should be trusted. A relying party might assume, without detailed checks, that these roots are operated exclusively by GlobalSign in accordance with GlobalSign's good reputation. Thus a clear notice that these "GlobalSign roots" are no longer operated by GlobalSign at any entrypoint where a casual relying party might go to check who "GlobalSign R?" is would be appropriate. If possible, making Mozilla products present these as "Google", not "GlobalSign" in short-form UIs (such as the certificate chain tree-like display element). Similarly for other root programs (for example, the Microsoft root program could change the "friendly name" of these). Further, the web site does not make their CP/CPS documents readily available Which website? The CP/CPS documents for which root(s)? The GTS CP and CPS are here: http://pki.goog/. - A relying party who takes the initiative to review a certificate chain that goes up to either of the acquired roots will see that it is anchored (or "verified by") GlobalSign. No mention of Google will be made anywhere in the user interface. I would expect there to be intermediate certificates with Google's name in; it's not permitted to issue EE certs directly from a root. However, neither GlobalSign's nor Google's name would appear in primary UI in Firefox, as we don't display CA names. At least in one Mozilla-based browser, the UI shows the name of the Intermediary as a tooltip, not of the root. So OK for this case. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Having gained a good understanding of Peter and Ryan's positions, I think I am now in a position to evaluate Peter's helpful policy suggestions. Whether or not we decide to make updates, as Kathleen pronounced herself satisfied at the time with Google's presented documentation and migration plan, it would be unreasonable for us to retroactively censure Google for following that plan. On 09/02/17 22:55, Peter Bowen wrote: > Policy Suggestion A) When transferring a root that is EV enabled, it > should be clearly stated whether the recipient of the root is also > receiving the EV policy OID(s). I agree with this suggestion; we should update https://wiki.mozilla.org/CA:RootTransferPolicy , and eventually incorporate it into the main policy when we fix https://github.com/mozilla/pkipolicy/issues/57 . > I think that this is the key issue. In my reading, "root > certificates" are not members of the program. Rather organizations > (legal entities) are members and each member has some number of root > certificates. > > Google was not a member of the program and had not applied to be a > member of the program at the time they received the roots already in > the program. This seems problematic to me. https://wiki.mozilla.org/CA:RootTransferPolicy says that "The organization who is transferring ownership of the root certificate’s private key must ensure that the transfer recipient is able to fully comply with Mozilla’s CA Certificate Policy. The original organization will continue to be responsible for the root certificate's private key until the transfer recipient has provided Mozilla with their Primary Point of Contact, CP/CPS documentation, and audit statement (or opinion letter) confirming successful transfer of the root certificate and key." I would say that an organization which has acquired a root certificate in the program and which has provided Mozilla with the above-mentioned information is thereby a member of the program. As the policy says that the transferring entity continues to be responsible until the information is provided, that seems OK to me. This position would logically lead to the position that a root inclusion request from an organization which does not have any roots is also, implicitly, an application to become a member of the program but the two things are distinct. One can become a member of the program in other ways. Membership is sort of something that happens to one automatically when one successfully achieves ownership of an included root. > Policy Suggestion B) Require that any organization wishing to become > a member of the program submit a bug with links to content > demonstrating compliance with the Mozilla policy. Require that this > be public prior to taking control of any root in the program. We do require this, but not publicly. I note and recognise Ryan's concern about requiring advance disclosure of private deals. I could see a requirement that a transferred root was not allowed to issue anything until the appropriate paperwork was publicly in place. Would that be suitable? > Policy Suggestion C) Recognize that root transfers are distinct from > the acquisition of a program member. Acquisition of a program > member (meaning purchase of the company) is a distinctly different > activity from moving only a private key, as the prior business > controls no longer apply in the latter case. https://wiki.mozilla.org/CA:RootTransferPolicy does make this distinction, I feel - how could it be better made? > Policy Suggestion D) Moving from being a RA to a CA or moving from > being a single tier/online (i.e. Subordinate-only) CA to being a > multi-tier/root CA requires a PITRA Again, would this be covered by a requirement that no issuance was permitted from a transferred root until all the paperwork was in place, including appropriately-scoped audits? This might lead to a PITRA, but would not have to. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 08/03/17 03:54, Peter Kurrasch wrote: > - Google has acquired 2 root certificates from GMO GlobalSign but not > the company itself. Yes. > GMO GlobalSign will continue to own other roots and > will use only those other roots for the various products and services > they choose to offer going forward. Not quite. GMO GlobalSign continues to control some subCAs of the roots it sold to Google, and is using those (presumably) to wind down its interest in those roots over time or support customer migrations to other roots. This happens to include issuing EV certificates. > There is no affiliation or business > relationship between GMO GlobalSign and Google after the completion of > the acquisition. We don't have information on this; the terms of the deal, and indeed any other deals the two companies may have made, are not public. > - No public announcement of the acquisition was made prior to January > 26, 2017 via the Google security blog. Depends what you mean by announcement, but they applied in a public bug for inclusion in the Mozilla root program in December: https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 and, I think, announced their intention in a publicly-minuted meeting of the CAB Forum in Redmond in mid-October 2016. > - No disclosure has been made regarding what specific items were > acquired, including such things as: "private key material" (HSM's and > whatnot); computer equipment used as web servers, OCSP responders, etc.; > domain names, IP addresses, and other infrastructure used in the > operations and maintenance of the acquired roots; data such as > subscriber lists, databases, server logs, payment details and histories, > certificate issuance activities and histories, etc.; any access rights > to physical space such as offices, data centers, development and test > facilities, and so forth; and last, but not least, any personnel, > documentation, training materials, or other knowledge products. I have not seen such disclosure. > - The scope of impact to existing GlobalSign customers is not known. Well, as Globalsign continues to operate those subCAs, I would hope the impact on GlobalSign customers is minimal. > Neither GMO GlobalSign nor Google have notified any existing clients of > the acquisition. Unless we hear from such clients, we can't know this one way or the other. > - The GlobalSign web site has no mention of this acquisition for reasons > which are unknown. Why would this be a requirement by anyone? > Further, the web site does not make their CP/CPS > documents readily available Which website? The CP/CPS documents for which root(s)? The GTS CP and CPS are here: http://pki.goog/. > - A relying party who takes the initiative to review a certificate chain > that goes up to either of the acquired roots will see that it is > anchored (or "verified by") GlobalSign. No mention of Google will be > made anywhere in the user interface. I would expect there to be intermediate certificates with Google's name in; it's not permitted to issue EE certs directly from a root. However, neither GlobalSign's nor Google's name would appear in primary UI in Firefox, as we don't display CA names. > - Google has acquired these roots in order to better serve their > subscribers, which are organizations (not people) throughout the many > Google companies. That's a question for Google. > Relying parties (i.e. end users of the various Google > products) are not affected positively or negatively by this acquisition. That's a matter of opinion :-) > - Mozilla granted Google's request to keep the acquisition confidential > based on statements made by Google and Google's auditor E&Y. That implies a cause and effect which is not present in the way suggested. We require that changes of ownership be disclosed, but we don't require them to be made public. Google and GlobalSign disclosed this change of ownership in accordance with our requirements. We also expect to see various audits which meet our auditing requirements over any transition period; my understanding is that Kathleen was satisfied with the documentation she saw. However, the keeping confidential of the acquisition was not conditioned on the presentation of audit documentation. > Neither > GlobalSign nor their auditors offered any opinion on this matter. Would you expect them to? Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Previous attempt had a major formatting snafu. Resending.From: Peter KurraschSent: Tuesday, March 7, 2017 9:35 PMI'm trying to keep score here but am having difficulties. Can someone confirm if the following statements are correct:- Google has acquired 2 root certificates from GMO GlobalSign but not the company itself. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products and services they choose to offer going forward. There is no affiliation or business relationship between GMO GlobalSign and Google after the completion of the acquisition. - No public announcement of the acquisition was made prior to January 26, 2017 via the Google security blog.- No disclosure has been made regarding what specific items were acquired, including such things as: "private key material" (HSM's and whatnot); computer equipment used as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure used in the operations and maintenance of the acquired roots; data such as subscriber lists, databases, server logs, payment details and histories, certificate issuance activities and histories, etc.; any access rights to physical space such as offices, data centers, development and test facilities, and so forth; and last, but not least, any personnel, documentation, training materials, or other knowledge products.- The scope of impact to existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google have notified any existing clients of the acquisition.- The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Further, the web site does not make their CP/CPS documents readily available limiting the ability for current subscribers and relying parties to decide if continued use of a cert chaining up to these roots is acceptable to them.- A relying party who takes the initiative to review a certificate chain that goes up to either of the acquired roots will see that it is anchored (or "verified by") GlobalSign. No mention of Google will be made anywhere in the user interface.- Google has acquired these roots in order to better serve their subscribers, which are organizations (not people) throughout the many Google companies. Relying parties (i.e. end users of the various Google products) are not affected positively or negatively by this acquisition.- Mozilla granted Google's request to keep the acquisition confidential based on statements made by Google and Google's auditor E&Y. Neither GlobalSign nor their auditors offered any opinion on this matter.Thank you. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
I'm trying to keep score here but am having difficulties. Can someone confirm if the following statements are correct:- Google has acquired 2 root certificates from GMO GlobalSign but not the company itself. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products and services they choose to offer.- No public announcement of the acquisition was made prior to January 26, 2017 via the Google security blog.- No disclosure has been made regarding what specific items were acquired, including such things as: "private key material" (HSM's and whatnot); computer equipment used as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure used in the operations and maintenance of the acquired roots; data such as subscriber lists, server logs, payment details and histories, certificate issuance activities and histories, etc.; and any access rights to physical space such as offices, data centers, development and test facilities, and so forth.- The scope of impact to existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google have notified any existing clients of the acquisition.- The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Further, the web site does not make their CP/CPS documents readily available limiting the ability for current subscribers and relying parties to decide if continued use of a cert chaining up to these roots is acceptable for them.- A relying party who actually takes the initiative to review a certificate chain will see that it is anchored (or "verified by") GlobalSign. No mention of Google will be made anywhere.- Google has acquired these roots in order to "better serve" their subscribers, which are organizations (not people) throughout the many Google companies. Relying parties are not affected positively or negatively by this acquisition. - Mozilla granted Google's request to keep the acquisition confidential based on statements made by Google and Google's auditor E&Y. GlobalSign nor their auditors offered any opinion on this matter.I'm trying to keep score here but am having difficulties. Can someone confirm if the following statements are correct:
- Google has acquired 2 root certificates from GMO GlobalSign but not the company itself. GMO GlobalSign will continue to own other roots and will use only those other roots for the various products and services they choose to offer.
- No public announcement of the acquisition was made prior to January 26, 2017 via the Google security blog.
- No disclosure has been made regarding what specific items were acquired, including such things as: "private key material" (HSM's and whatnot); computer equipment used as web servers, OCSP responders, etc.; domain names, IP addresses, and other infrastructure used in the operations and maintenance of the acquired roots; data such as subscriber lists, server logs, payment details and histories, certificate issuance activities and histories, etc.; and any access rights to physical space such as offices, data centers, development and test facilities, and so forth.
- The scope of impact to existing GlobalSign customers is not known. Neither GMO GlobalSign nor Google have notified any existing clients of the acquisition.
- The GlobalSign web site has no mention of this acquisition for reasons which are unknown. Further, the web site does not make their CP/CPS documents readily available limiting the ability for current subscribers and relying parties to decide if continued use of a cert chaining up to these roots is acceptable for them.
- A relying party who actually takes the initiative to review a certificate chain will see that it is anchored (or "verified by") GlobalSign. No mention of Google will be made anywhere.
- Google has acquired these roots in order to "better serve" their subscribers, which are organizations (not people) throughout the many Google companies. Relying parties are not affected positively or negatively by this acquisition.
- Mozilla granted Google's request to keep the acquisition confidential based on statements made by Google and Google's auditor E&Y. GlobalSign nor their auditors offered any opinion on this matter.
___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
On 07/03/2017 18:29, Ryan Hurst wrote: pzb: I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. Again, sorry for the delay in responding, I will be more prompt moving forward. pzb: This does not resolve the concern. The BRs require an "an unbroken sequence of audit periods". Given that GlobalSign clearly cannot make any assertion about the roots after 11 August 2016, you would have a gap from 11 August 2016 to 30 September 2016 in your sequence of audit periods if your next report runs 1 October 2016 to 30 September 2017. I understand your point but this is not entirely accurate. Our strategy, to ensure a smooth transition, which was reviewed with the auditors and root program administrators was that we take possession of the root key material and manage it offline, in accordance with our existing WebTrust audit and the “Key Storage, Backup and Recovery Criterion”. It was our, and EY's opinion that the existing controls and ongoing WebTrust audits were sufficient given this plan and scope. As such, during the period in question, the existing audits provide an un-broken sequence of audit periods. That said, we will follow-up with our auditors to see if it is possible to extend the scope of our 2017 audit to also cover this interval to ensure the community has further assurances of continuity. pzb: Based on my personal experience, it is possible to negotiate a deal and set a closing date in the future. This is standard for many acquisitions; you frequently see purchases announced with a closing date in the future for all kinds of deals. The gap between signing the deal and closing gives acquirers the opportunity to complete the steps in B. As I stated, I think that moving forward this could be a good policy change, I am hesitant to see any user agent adopt policies that are overly prescriptive of commercial terms between two independent parties. Could a reasonably condition be that decision authority, actual and physical control for a root are not moved until proper root program coordination has been done (an action which may occur after/before the commercial conclusion of a transaction). From a business perspective this could be comparable to similar requirements imposed on some physical objects that can have public interest implications. pzb: You appear to be confusing things here. "Subordinate CA Certificate Life Cycle Management" is the portion of the WebTrust criteria that covers the controls around issuing certificates with the cA component of the basicConstraints extension set to true. It has nothing to do with operating a subordinate CA. I am familiar with the "Subordinate CA Certificate Life Cycle Management" controls I just should have been more explicit in my earlier response. These keys were generated and stored in accordance with Asset Classification and Management Criterion, and Key Storage, Backup and Recovery Criterion. Before utilizing the associated keys in any activity covered by the “Subordinate CA Certificate Life Cycle Management” criterion all associated policies and procedures were created, tested and then reviewed by our auditors. Additionally, those auditors were present during the associated ceremony. All such activities which will be covered under our 2017 audit. This is similar to how a CA can, and does, revise and extend their policies between audits to cover new products and services. This is consistent with the approach we discussed, and had approved with the various root program administrators. pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the applicable CPS for your _root CAs_ between 11 August 2016 and 8 December 2016. The Google CPS makes these statements. Therefore, you are stating that the roots (not just GIA G2) were only permitted to issue Certificates to Google and Google Affiliates. Correct, these roots were not used to issue certificates at all until last week and when one was used, it was used to issue a subordinate CA certificate to Google. Though we do not have a product or service to announce currently, we can say we will expand the use of GTS beyond GIAG2, at which time policies, procedures, CP and CPS will be updated accordingly. This progression makes sense as we're moving from a constrained intermediate to a Root. Mozilla has consistently taken the position that roots that exclusively issue to a single company are not acceptable in the root program. Google and its affiliate companies are more than a single company. Additionally, clearly the intent of this rule is to prevent thousands of organizations issuing a handful of certificates polluting the root store. In the case of Google and its Affiliate companies, we operate products and services for our customers. This is similar to how Amazon and a number of other root operators
Re: Google Trust Services roots
> pzb: I appreciate you finally sending responses. I hope you appreciate > that they are clearly not adequate, in my opinion. Please see the > comments inline. Again, sorry for the delay in responding, I will be more prompt moving forward. > pzb: This does not resolve the concern. The BRs require an "an unbroken > sequence of audit periods". Given that GlobalSign clearly cannot make > any assertion about the roots after 11 August 2016, you would have a > gap from 11 August 2016 to 30 September 2016 in your sequence of audit > periods if your next report runs 1 October 2016 to 30 September 2017. I understand your point but this is not entirely accurate. Our strategy, to ensure a smooth transition, which was reviewed with the auditors and root program administrators was that we take possession of the root key material and manage it offline, in accordance with our existing WebTrust audit and the “Key Storage, Backup and Recovery Criterion”. It was our, and EY's opinion that the existing controls and ongoing WebTrust audits were sufficient given this plan and scope. As such, during the period in question, the existing audits provide an un-broken sequence of audit periods. That said, we will follow-up with our auditors to see if it is possible to extend the scope of our 2017 audit to also cover this interval to ensure the community has further assurances of continuity. > pzb: Based on my personal experience, it is possible to negotiate a deal > and set a closing date in the future. This is standard for many > acquisitions; you frequently see purchases announced with a closing > date in the future for all kinds of deals. The gap between signing > the deal and closing gives acquirers the opportunity to complete the > steps in B. As I stated, I think that moving forward this could be a good policy change, I am hesitant to see any user agent adopt policies that are overly prescriptive of commercial terms between two independent parties. > pzb: You appear to be confusing things here. "Subordinate CA Certificate > Life Cycle Management" is the portion of the WebTrust criteria that > covers the controls around issuing certificates with the cA component > of the basicConstraints extension set to true. It has nothing to do > with operating a subordinate CA. I am familiar with the "Subordinate CA Certificate Life Cycle Management" controls I just should have been more explicit in my earlier response. These keys were generated and stored in accordance with Asset Classification and Management Criterion, and Key Storage, Backup and Recovery Criterion. Before utilizing the associated keys in any activity covered by the “Subordinate CA Certificate Life Cycle Management” criterion all associated policies and procedures were created, tested and then reviewed by our auditors. Additionally, those auditors were present during the associated ceremony. All such activities which will be covered under our 2017 audit. This is similar to how a CA can, and does, revise and extend their policies between audits to cover new products and services. This is consistent with the approach we discussed, and had approved with the various root program administrators. > pzb: You have stated that the Google CPS (not the GTS CP/CPS) was the > applicable CPS for your _root CAs_ between 11 August 2016 and 8 > December 2016. The Google CPS makes these statements. Therefore, you > are stating that the roots (not just GIA G2) were only permitted to > issue Certificates to Google and Google Affiliates. Correct, these roots were not used to issue certificates at all until last week and when one was used, it was used to issue a subordinate CA certificate to Google. Though we do not have a product or service to announce currently, we can say we will expand the use of GTS beyond GIAG2, at which time policies, procedures, CP and CPS will be updated accordingly. This progression makes sense as we're moving from a constrained intermediate to a Root. > Mozilla has consistently taken the position that roots that exclusively issue to a > single company are not acceptable in the root program. Google and its affiliate companies are more than a single company. Additionally, clearly the intent of this rule is to prevent thousands of organizations issuing a handful of certificates polluting the root store. In the case of Google and its Affiliate companies, we operate products and services for our customers. This is similar to how Amazon and a number of other root operators operate products and services for their customers, the core difference being the breadth of user facing products we have. > This does not address the question. The Google CPS clearly states > that it only covers the GIA G2 CA. You have stated that the Google > CPS (not the GTS CP/CPS) was the applicable CPS for your _root CAs_ > between 11 August 2016 and 8 December 2016. This puts your statement > at adds with what is written in th
Re: Google Trust Services roots
On 07/03/17 03:14, Ryan Hurst wrote: >> Gerv: Just to be clear: GlobalSign continues to operate at least one subCA >> under a root which Google has purchased, and that root is EV-enabled, >> and the sub-CA continues to do EV issuance (and is audited as such) but >> the root is no longer EV audited, and nor is the rest of the hierarchy? > > Yes, that is correct. OK. Question for group: would it make sense to add the intermediate(s) that GlobalSign is using for this purpose directly to the Mozilla trust store, with the EV bit enabled, and then remove the EV bit from the roots now owned by Google Trust Services? This would scope EV permissions more closely to the audits, and so prevent Google from accidentally or intentionally issuing EV which was shown as such in Firefox, without having an EV audit. Gerv ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
First, let me apologize for the delay in my response, I have had a draft of this letter in my inbox for a while and have just been unable to get back to it and finish it due to scheduling conflicts. I promise to address all other questions in a more prompt manner. > pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for EVcertificates for all EV-enabled roots > (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923). > 1) Do you consider it mis-issuance for Google to issue a certificate containing the 2.23.140.1.1 OID? > Policy Suggestion A) When transferring a root that is EV enabled, it should be clearly stated whether the > recipient of the root is also receiving the EV policy OID(s). rmh: Yes. We believe that until we have: - The associated policies, procedures, and other associated work completed, - Have successfully completed an EV audit, - And have been approved by one or more of the various root programs as an EV issuer. That it would be an example of miss-issuance for us to issue such a certificate. > pzb: Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 December 2016, Google Inc. operated these Roots according to Google Inc.’s Certification Practice Statement." The basic WebTrust for CA and WebTrust BR audit reports for the period ending September 30, 2016 explicitly state they are for "subordinate CA under external Root CA" and do not list the roots in the GTS CPS at all. > > rmh: I believe this will be answered by my responses to your third and fourth observations. > It was not. rmh: I just attached two opinion letters from our auditors, I had previously provided these to the root programs directly but it took some time to get permission to release them publicly. One letter is covering the key generation ceremony of the new roots, and another covering the transfer of the keys to our facilities. In this second report you will find the following statement: ``` In our opinion, as of November 17, 2016, Google Trust Services LLC Management’s Assertion, as referred to above, is fairly stated, in all material respects, based on Certification Practices Statement Management Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and Criteria for Certification Authorities v2.0. ``` Based on our conversations with the various root program operator's prior to our acquisition it has been our plan and understanding, that we can utilize these opinion letters to augment the webtrust audit with the material details, relating to these activities. It is our hope that this also addresses you specific concern here. > 2) Will Google be publishing an audit report for a period starting 11 > August 2016 that covers the transferred GS roots? If so, can you > estimate the end of period date? rmh: It is our belief, based on our conversations with the various root store operators, as well as our own auditors that the transfer itself is covered by the opinion letters. With that said our audit period is October 1st to the end of September. The associated report will be released between October and November, depending on our auditors schedules. > pzb: I think that this is the key issue. In my reading, "root > certificates" are not members of the program. Rather organizations > (legal entities) are members and each member has some number of root > certificates. > Google was not a member of the program and had not applied to be a > member of the program at the time they received the roots already in > the program. This seems problematic to me. > Policy Suggestion B) Require that any organization wishing to become a > member of the program submit a bug with links to content demonstrating > compliance with the Mozilla policy. Require that this be public prior > to taking control of any root in the program. > Policy Suggestion C) Recognize that root transfers are distinct from > the acquisition of a program member. Acquisition of a program member > (meaning purchase of the company) is a distinctly different activity > from moving only a private key, as the prior business controls no > longer apply in the latter case. We discussed the topic of disclosure with the root program administrators prior to our acquisition. Our goal was to tell the community as soon as possible, the complexity of this transaction made it hard to get a hard date for that announcement. Based on our conversations with root program administrators we were told the policy did not require disclosure to be public which left the timing of that notification up to us. As for the recommendation to clarify the policy in this area, I think it would be valuable to do that. Both of your recommendations seem reasonable, my concern with B) is how to do so in a way that does not make it impossible or even more complicated to successfully negotiate such a deal. As long as the disclosure was limited to intent t
Re: Google Trust Services roots
One more question, in addition to the ones in my prior response: On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > rmh: I just attached two opinion letters from our auditors, I had previously > provided these to the root programs directly but it took some time to get > permission to release them publicly. One letter is covering the key > generation ceremony of the new roots, and another covering the transfer of > the keys to our facilities. In this second report you will find the > following statement: > > ``` > In our opinion, as of November 17, 2016, Google Trust Services LLC > Management’s Assertion, as referred to above, is fairly stated, in all > material respects, based on Certification Practices Statement Management > Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key > Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and > Criteria for Certification Authorities v2.0. > ``` According to the opinion letter: "followed the CA key generation and security requirements in its: o Google Internet Authority G2 CPS v1.4" (hyperlink omitted) According to that CPS, "Key Pairs for the Google Internet Authority are generated and installed in accordance with the contract between Google and GeoTrust, Inc., the Root CA." Are you asserting that the authority for the key generation process for the new Google roots is "the contract between Google and GeoTrust, Inc."? Thanks, Peter ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
Ryan, I appreciate you finally sending responses. I hope you appreciate that they are clearly not adequate, in my opinion. Please see the comments inline. On Mon, Mar 6, 2017 at 6:02 PM, Ryan Hurst wrote: > First, let me apologize for the delay in my response, I have had a draft of > this letter in my inbox for a while and have just been unable to get back to > it and finish it due to scheduling conflicts. I promise to address all other > questions in a more prompt manner. > > >> pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for >> EVcertificates for all EV-enabled roots >> (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923). > > >> 1) Do you consider it mis-issuance for Google to issue a certificate >> containing the 2.23.140.1.1 OID? > >> Policy Suggestion A) When transferring a root that is EV enabled, it >> should be clearly stated whether the >> recipient of the root is also receiving the EV policy OID(s). > > > rmh: Yes. We believe that until we have: > > - The associated policies, procedures, and other associated work completed, > > - Have successfully completed an EV audit, > > - And have been approved by one or more of the various root programs as an > EV issuer. > > > That it would be an example of miss-issuance for us to issue such a > certificate. Given the EV-enabled status, this seems like a reasonable path forward. >> pzb: Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 >> December 2016, Google Inc. operated these Roots according to Google Inc.’s >> Certification Practice Statement." The basic WebTrust for CA and WebTrust >> BR audit reports for the period ending September 30, 2016 explicitly state >> they are for "subordinate CA under external Root CA" and do not list the >> roots in the GTS CPS at all. > >> rmh: I believe this will be answered by my responses to your third and >> fourth observations. > > >> It was not. > > rmh: I just attached two opinion letters from our auditors, I had previously > provided these to the root programs directly but it took some time to get > permission to release them publicly. One letter is covering the key > generation ceremony of the new roots, and another covering the transfer of > the keys to our facilities. In this second report you will find the > following statement: > > > ``` > In our opinion, as of November 17, 2016, Google Trust Services LLC > Management’s Assertion, as referred to above, is fairly stated, in all > material respects, based on Certification Practices Statement Management > Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key > Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and > Criteria for Certification Authorities v2.0. > ``` > > Based on our conversations with the various root program operator's prior to > our acquisition it has been our plan and understanding, that we can utilize > these opinion letters to augment the webtrust audit with the material > details, relating to these activities. It is our hope that this also > addresses you specific concern here. > >> 2) Will Google be publishing an audit report for a period starting 11 >> August 2016 that covers the transferred GS roots? If so, can you >> estimate the end of period date? > > rmh: It is our belief, based on our conversations with the various root > store operators, as well as our own auditors that the transfer itself is > covered by the opinion letters. With that said our audit period is October > 1st to the end of September. The associated report will be released between > October and November, depending on our auditors schedules. This does not resolve the concern. The BRs require an "an unbroken sequence of audit periods". Given that GlobalSign clearly cannot make any assertion about the roots after 11 August 2016, you would have a gap from 11 August 2016 to 30 September 2016 in your sequence of audit periods if your next report runs 1 October 2016 to 30 September 2017. >> pzb: I think that this is the key issue. In my reading, "root >> certificates" are not members of the program. Rather organizations >> (legal entities) are members and each member has some number of root >> certificates. > >> Google was not a member of the program and had not applied to be a >> member of the program at the time they received the roots already in >> the program. This seems problematic to me. > >> Policy Suggestion B) Require that any organization wishing to become a >> member of the program submit a bug with links to content demonstrating >> compliance with the Mozilla policy. Require that this be public prior >> to taking control of any root in the program. > >> Policy Suggestion C) Recognize that root transfers are distinct from >> the acquisition of a program member. Acquisition of a program member >> (meaning purchase of the company) is a distinctly different activity >> from moving only a private key, as the prior business controls no >> longer apply in the latter case. > >
Re: Google Trust Services roots
> Gerv: Which EV OID are you referring to, precisely? I was referring to the GlobalSign EV Certificate Policy OID (1.3.6.1.4.1.4146.1.1) but more concretely I meant any and all EV related OIDs, including the CAB Forum OID of 2.23.140.1.1. > Gerv: Just to be clear: GlobalSign continues to operate at least one subCA > under a root which Google has purchased, and that root is EV-enabled, > and the sub-CA continues to do EV issuance (and is audited as such) but > the root is no longer EV audited, and nor is the rest of the hierarchy? Yes, that is correct. > Gerv: Can you tell us what the planned start/end dates for the audit period > of > that annual audit are/will be? Our audit period is October 1st to the end of September. The associated report will be released between October and November, depending on our auditors schedules. > Gerv: Are the Google roots and/or the GlobalSign-acquired roots currently > issuing EE certificates? Were they issuing certificates between 11th August 2016 and 8th December 2016? No they were not issuing certificates between 11th August 2016 and 8th December 2016. We generated our first certificate, a subordinate CA, last week, that CA is not yet in use. Ryan Hurst Product Manager ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services roots
[Trying to resend without the quoted email to get through the spam filter] First, let me apologize for the delay in my response, I have had a draft of this letter in my inbox for a while and have just been unable to get back to it and finish it due to scheduling conflicts. I promise to address all other questions in a more prompt manner. > pzb: Mozilla recognizes 2.23.140.1.1 as being a valid OID for EVcertificates for all EV-enabled roots > (https://bugzilla.mozilla.org/show_bug.cgi?id=1243923). > 1) Do you consider it mis-issuance for Google to issue a certificate containing the 2.23.140.1.1 OID? > Policy Suggestion A) When transferring a root that is EV enabled, it should be clearly stated whether the > recipient of the root is also receiving the EV policy OID(s). rmh: Yes. We believe that until we have: - The associated policies, procedures, and other associated work completed, - Have successfully completed an EV audit, - And have been approved by one or more of the various root programs as an EV issuer. That it would be an example of miss-issuance for us to issue such a certificate. > pzb: Second, according to the GTS CPS v1.3, "Between 11 August 2016 and 8 December 2016, Google Inc. operated these Roots according to Google Inc.’s Certification Practice Statement." The basic WebTrust for CA and WebTrust BR audit reports for the period ending September 30, 2016 explicitly state they are for "subordinate CA under external Root CA" and do not list the roots in the GTS CPS at all. > > rmh: I believe this will be answered by my responses to your third and fourth observations. > It was not. rmh: I just attached two opinion letters from our auditors, I had previously provided these to the root programs directly but it took some time to get permission to release them publicly. One letter is covering the key generation ceremony of the new roots, and another covering the transfer of the keys to our facilities. In this second report you will find the following statement: ``` In our opinion, as of November 17, 2016, Google Trust Services LLC Management’s Assertion, as referred to above, is fairly stated, in all material respects, based on Certification Practices Statement Management Criterion 2.2, Asset Classification and Management Criterion 3.2, and Key Storage, Backup and Recovery Criterion 4.2 of the WebTrust Principles and Criteria for Certification Authorities v2.0. ``` Based on our conversations with the various root program operator's prior to our acquisition it has been our plan and understanding, that we can utilize these opinion letters to augment the webtrust audit with the material details, relating to these activities. It is our hope that this also addresses you specific concern here. > 2) Will Google be publishing an audit report for a period starting 11 > August 2016 that covers the transferred GS roots? If so, can you > estimate the end of period date? rmh: It is our belief, based on our conversations with the various root store operators, as well as our own auditors that the transfer itself is covered by the opinion letters. With that said our audit period is October 1st to the end of September. The associated report will be released between October and November, depending on our auditors schedules. > pzb: I think that this is the key issue. In my reading, "root > certificates" are not members of the program. Rather organizations > (legal entities) are members and each member has some number of root > certificates. > Google was not a member of the program and had not applied to be a > member of the program at the time they received the roots already in > the program. This seems problematic to me. > Policy Suggestion B) Require that any organization wishing to become a > member of the program submit a bug with links to content demonstrating > compliance with the Mozilla policy. Require that this be public prior > to taking control of any root in the program. > Policy Suggestion C) Recognize that root transfers are distinct from > the acquisition of a program member. Acquisition of a program member > (meaning purchase of the company) is a distinctly different activity > from moving only a private key, as the prior business controls no > longer apply in the latter case. We discussed the topic of disclosure with the root program administrators prior to our acquisition. Our goal was to tell the community as soon as possible, the complexity of this transaction made it hard to get a hard date for that announcement. Based on our conversations with root program administrators we were told the policy did not require disclosure to be public which left the timing of that notification up to us. As for the recommendation to clarify the policy in this area, I think it would be valuable to do that. Both of your recommendations seem reasonable, my concern with B) is how to do so in a way that does not make it impossible or even more complicated to successfully negotiate such a dea