Re: Google Trust Services Root Inclusion Request
A few additional points: First off, thank you Rob and James for calling out unacceptable list behavior. Personal attacks will not be tolerated from anyone on this list. On Thu, Sep 27, 2018 at 10:26 AM Ryan Sleevi wrote: > > On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley > wrote: > >> Oh – I totally agree with you on the Google inclusion issue. Google meets >> the requirements for inclusion in Mozilla’s root policy so there’s no >> reason to exclude them. They have an audited CPS, support a community >> broader with certs than just Google, and have operated a CA without >> problems in the past. The discussion on Mozilla’s independence is important >> IMO where a) a Mozilla competitor as a module peer and b) having that same >> person also belong to a CA. There are legit concerns. Has any other CA >> served as a module owner? If not, why? I know Tim Hollebeek would be >> interested in being a peer. If he’s not permitted to be a peer, why not? >> > > Again, I don't think there is or should be a ban on module peers being employed by a CA. > I think this again conflates peership with ownership, and it's good to > revisit what policies are actually specified by how it works. > > I disagree with you as to the independence discussion being valuable, > because that conclusion rests on a misunderstanding about module ownership > and peership. Again, > https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ > addresses these concerns. It also is conflating MoCo and MoFo, which I know > was a topic that Gerv was particularly sensitive to. > > To your second part, the selection of peers, > https://wiki.mozilla.org/Modules addresses this - "A peer is a person > whom the owner has appointed to help them." and "Owners may add and remove > peers from their modules as they wish, without reference to anyone else" > > My observation is that peers are appointed in recognition of the level of work they've done for the module. Peer appointments are announced on the Mozilla governance list, and I believe that a search of recent peer announcements [1] supports my observation. If members of this list think there is someone whose contributions should be recognized by making them a peer, please let Kathleen and me know. Employees of CAs often have the knowledge needed to make meaningful contributions here, and we welcome their contributions. [1] https://groups.google.com/forum/#!searchin/mozilla.governance/peer%7Csort:date To be fair, separating out Ryan as a Google browser representative and Ryan >> as a module peer is…hard. Perhaps, he specifically is seen as more >> influential (from my point of view) than others simply because of his dual >> role. >> > > What is difficult separating out? You're intimating at some degree of > influence that is not transparent, but that's not supported by any > evidence. You're also intimating influence over Mozilla somehow, but that > seems like the separation would be easy. > > >> As I said before, Ryan’s a good module peer so I don’t disagree with your >> conclusion or any decision to keep him in that spot. But I think openness >> should include respectful conversation on the impact of influences, >> perceived or real, on the Mozilla direction. What might help alleviate >> concerns is to describe how you (as a module owner) are going to ensure >> that if Ryan is reviewing and approving code or CA policies, they won’t be >> unfairly biased towards google or against its competitors? Maybe that’s a >> bad question, but I’m spit-balling on how we can move past speculation to >> address concerns raised. >> > > Considering that all of this happens in the open, on m.d.s.p., what are > you using to support your thinking that there's some undue influence? Do > you believe that if the title peer is removed, the relationship changes? > Between questions asked and concerns raised? You're not just spit-balling, > you're intimating that the speculation has a reasonable foundation that > requires redress, but you're not actually addressing why that speculation > is seen as reasonable. That things happen here, transparently, should > itself serve to demonstrate the speculation as unfounded. Further, the > influence or lack of influence is based on the discussions that happen > here, and that regardless of any influence that may be perceived, the > community discussion that Wayne facilitates as Module Owner provides ample > opportunity to explore or influence in any other preferable direction. > > Just want to point out that Kathleen is currently still the CA Certificate Policy Module Owner. But let's humour the specious reasoning here, and imagine there was some > undue influence on the peership > - One scenario is that such influence is exercised, and that there isn't a > public review or discussion phase to 'undo' that influence, and that's bad. > That's not a failure of peership though, that's a failure of Module > Ownership > - Another scenario is that such influence is
Re: Google Trust Services Root Inclusion Request
On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley wrote: > Oh – I totally agree with you on the Google inclusion issue. Google meets > the requirements for inclusion in Mozilla’s root policy so there’s no > reason to exclude them. They have an audited CPS, support a community > broader with certs than just Google, and have operated a CA without > problems in the past. The discussion on Mozilla’s independence is important > IMO where a) a Mozilla competitor as a module peer and b) having that same > person also belong to a CA. There are legit concerns. Has any other CA > served as a module owner? If not, why? I know Tim Hollebeek would be > interested in being a peer. If he’s not permitted to be a peer, why not? > I think this again conflates peership with ownership, and it's good to revisit what policies are actually specified by how it works. I disagree with you as to the independence discussion being valuable, because that conclusion rests on a misunderstanding about module ownership and peership. Again, https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ addresses these concerns. It also is conflating MoCo and MoFo, which I know was a topic that Gerv was particularly sensitive to. To your second part, the selection of peers, https://wiki.mozilla.org/Modules addresses this - "A peer is a person whom the owner has appointed to help them." and "Owners may add and remove peers from their modules as they wish, without reference to anyone else" > To be fair, separating out Ryan as a Google browser representative and > Ryan as a module peer is…hard. Perhaps, he specifically is seen as more > influential (from my point of view) than others simply because of his dual > role. > What is difficult separating out? You're intimating at some degree of influence that is not transparent, but that's not supported by any evidence. You're also intimating influence over Mozilla somehow, but that seems like the separation would be easy. > As I said before, Ryan’s a good module peer so I don’t disagree with your > conclusion or any decision to keep him in that spot. But I think openness > should include respectful conversation on the impact of influences, > perceived or real, on the Mozilla direction. What might help alleviate > concerns is to describe how you (as a module owner) are going to ensure > that if Ryan is reviewing and approving code or CA policies, they won’t be > unfairly biased towards google or against its competitors? Maybe that’s a > bad question, but I’m spit-balling on how we can move past speculation to > address concerns raised. > Considering that all of this happens in the open, on m.d.s.p., what are you using to support your thinking that there's some undue influence? Do you believe that if the title peer is removed, the relationship changes? Between questions asked and concerns raised? You're not just spit-balling, you're intimating that the speculation has a reasonable foundation that requires redress, but you're not actually addressing why that speculation is seen as reasonable. That things happen here, transparently, should itself serve to demonstrate the speculation as unfounded. Further, the influence or lack of influence is based on the discussions that happen here, and that regardless of any influence that may be perceived, the community discussion that Wayne facilitates as Module Owner provides ample opportunity to explore or influence in any other preferable direction. But let's humour the specious reasoning here, and imagine there was some undue influence on the peership - One scenario is that such influence is exercised, and that there isn't a public review or discussion phase to 'undo' that influence, and that's bad. That's not a failure of peership though, that's a failure of Module Ownership - Another scenario is that such influence is exercised, and there is a public review and discussion phase. If the result produced by that influence is the same as the community expectation, then there's nothing improper here. If the result produced by that influence is different from the community expectation, then that can be corrected and identified during the review and discussion phase, and such 'influence' is actually either non-existent or equivalent to the same influence practiced by all participating members of the community - Another scenario is that there is no such influence, and the participation and peership is identical to that of what the community expects and concurs with. It's almost as if influence is being conflated with consistency - that is, if I'm expressing views that the community agrees with, I'm seen as influential, while ignoring the fact that if I express views the community disagrees with, they are just as influential as to call that out. Do you see the logical flaws here? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org
RE: Google Trust Services Root Inclusion Request
Maybe Jake’s opinion is not being discarded as readily as I supposed. However, Jake’s last message left me disturbed that he didn’t feel listened to. Apologies if I’m overblowing the issue, which are definitely hypothetical at this point. I did want Jake to feel like his input is an important part of this discussion board. Not saying anyone made him feel otherwise intentionally of course, but his last message seemed frustrated. From: Ryan Sleevi Sent: Wednesday, September 26, 2018 10:49 AM To: Jeremy Rowley Cc: Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: Google Trust Services Root Inclusion Request On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote: I also should also emphasize that I’m speaking as Jeremy Rowley, not as DigiCert. Note that I didn’t say Google controlled the policy. However, as a module peer, Google does have significant influence over the policy and what CAs are trusted by Mozilla. Although everyone can participate in Mozilla discussions publicly, it’s a fallacy to state that a general participant has similar sway or authority to a module peer. That’s the whole point of having a separate class for peers compared to us general public. With Google acting as a CA and module peer, you now have one CA heavily influencing who its competitors are, how its competitors operate, and what its competitors can do. Although I personally find that you never misuse your power as a module peer, I can see how Jake has concerns that Google (as a CA) has very heavy influence over the platform that has historically been the CA watchdog (Mozilla). Jeremy, I think this again deserves calling out, because this is misrepresenting what module peership does, as well as the CA relationship. I linked you to the definition of Module Ownership, which highlights and emphasizes that the module peer is simply a recognized helper. To the extent there is any influence, it is through the public discussions here. If your concern is that the title confers some special advantage, that's to misread what module peer is. If your concern is that the participation - which provides solid technical arguments as well as the policy alternatives - is influential, then what you're arguing against is public participation. You're presenting these as factual, and that's misleading, so I'd like to highlight what is actually entailed. The circumstances are different between the scenarios you describe with respect to the other browsers, as is market share. If Microsoft wants to change CAs (and they already use multiple), they can without impacting public perception. If Apple wants to use another CA, they can without people commenting how odd it is that Apple doesn’t use the Apple CA. With Google controlling the CA and the Google browser, all incentive to eliminate any misbehaving Google CA disappears for financial reasons, public perception, and because Google can control the messaging (through marketshare and influence over Mozilla policy). Note that there is historical precedent for Google treating Google special – i.e. the exclusion for Google in the Symantec distrust plan. Thus, I think Jake’s concerns should not be discarded so readily. I can understand and appreciate why you have this perspective. I disagree that it's an accurate representation, and as shown by the previous message, it does not have factual basis. I think it's misleading to suggest that the concerns are being discarded, much like yours - they're being responded to with supporting evidence and careful analysis. However, they do not hold water, and while it would be ideal to convince you of this as well, it's equally important to be transparent about it. Your argument above seems to boil down to "People would notice if Google changed CAs, but not if Microsoft" - yet that's not supported (see, example, the usage of Let's Encrypt by Google, or the former usage of WoSign by Microsoft). Your argument about incentives entirely ignores the incentives I just described to you previously - which look at public perception, internet security, and ecosystem stability. Your argument about influence over Mozilla policy has already been demonstrated as false and misleading, but it seems you won't be convinced by that. And your suggestion of special treatment ignores the facts of the situation (the validation issues, the scoping of audits, that Apple and 2 other CAs were also included in the exclusion), ignores the more significant special treatment granted by other vendors (e.g. Apple's exclusion of a host of mismanaged Symantec sub-CAs now under DigiCert's operational control), the past precedent (e.g. the gradual distrust of WoSign/StartCom through whitelists, of CNNIC through whitelists), and the public discussion involved so entirely that it's entirely unfounded. So I think your continued suggestion that it's be
RE: Google Trust Services Root Inclusion Request
Oh – I totally agree with you on the Google inclusion issue. Google meets the requirements for inclusion in Mozilla’s root policy so there’s no reason to exclude them. They have an audited CPS, support a community broader with certs than just Google, and have operated a CA without problems in the past. The discussion on Mozilla’s independence is important IMO where a) a Mozilla competitor as a module peer and b) having that same person also belong to a CA. There are legit concerns. Has any other CA served as a module owner? If not, why? I know Tim Hollebeek would be interested in being a peer. If he’s not permitted to be a peer, why not? To be fair, separating out Ryan as a Google browser representative and Ryan as a module peer is…hard. Perhaps, he specifically is seen as more influential (from my point of view) than others simply because of his dual role. As I said before, Ryan’s a good module peer so I don’t disagree with your conclusion or any decision to keep him in that spot. But I think openness should include respectful conversation on the impact of influences, perceived or real, on the Mozilla direction. What might help alleviate concerns is to describe how you (as a module owner) are going to ensure that if Ryan is reviewing and approving code or CA policies, they won’t be unfairly biased towards google or against its competitors? Maybe that’s a bad question, but I’m spit-balling on how we can move past speculation to address concerns raised. From: Wayne Thayer Sent: Wednesday, September 26, 2018 3:39 PM To: Ryan Sleevi Cc: Jeremy Rowley ; mozilla-dev-security-policy Subject: Re: Google Trust Services Root Inclusion Request I'm disputing the conclusion that is being drawn from Jake's concerns, rather than the concerns themselves. Primarily, I disagree with the conclusion that because Google owns a browser with dominant market share and - due to the substantial contributions they make here - because Google has considerable influence in this community, they should not be allowed to participate in our root program as a CA. Secondarily, I disagree that a Google employee should not be a peer of this module due to the potential for a conflict of interest. Unpacking this conclusion in terms of policy it implies, I think the argument being made is that any root store operator should be excluded from membership in the Mozilla program as a CA, and any employee of a CA should be prohibited from being a module peer. The argument is that this will protect us from future conflicts of interest (there seems to be agreement that the concern is hypothetical at this point). My conclusion is that rather than creating somewhat arbitrary, exclusionary rules, we can and should instead rely on the openness and inclusiveness of our process to protect us from conflicts of interest. If Google attempts to gain preferential treatment for their CA from Mozilla, our community can and will identify it, reject it, and hold Mozilla accountable for acting in their best interest. On Wed, Sep 26, 2018 at 9:49 AM Ryan Sleevi via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley mailto:jeremy.row...@digicert.com> > wrote: > I also should also emphasize that I’m speaking as Jeremy Rowley, not as > DigiCert. > > > > Note that I didn’t say Google controlled the policy. However, as a module > peer, Google does have significant influence over the policy and what CAs > are trusted by Mozilla. Although everyone can participate in Mozilla > discussions publicly, it’s a fallacy to state that a general participant > has similar sway or authority to a module peer. That’s the whole point of > having a separate class for peers compared to us general public. With > Google acting as a CA and module peer, you now have one CA heavily > influencing who its competitors are, how its competitors operate, and what > its competitors can do. Although I personally find that you never misuse > your power as a module peer, I can see how Jake has concerns that Google > (as a CA) has very heavy influence over the platform that has historically > been the CA watchdog (Mozilla). > Jeremy, I think this again deserves calling out, because this is misrepresenting what module peership does, as well as the CA relationship. I linked you to the definition of Module Ownership, which highlights and emphasizes that the module peer is simply a recognized helper. To the extent there is any influence, it is through the public discussions here. If your concern is that the title confers some special advantage, that's to misread what module peer is. If your concern is that the participation - which provides solid technical arguments as well as the policy alternatives - is influential, then what you're arguing against is public participation. You're presenting thes
Re: Re: Google Trust Services Root Inclusion Request
Richard, Unfortunately Gerv is no longer with us, so he cannot respond to this accusation. Having been involved in many discussions on m.d.s.p and with Gerv directly, I am very sure Gerv deeply owned the decisions on StartCom and WoSign. It was by no means Ryan telling Gerv or Mozilla what to do. Gerv put many hours into researching the issues and is the one who wrote the wiki and summary docs. Please give Gerv credit where credit is due. Thanks, Peter On Wed, Sep 26, 2018 at 11:55 PM Richard Wang via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module > Peer that gave too many pressures to the M.D.S.P community to misleading > the Community and to let Mozilla make the decision that Google want. > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
It is unfair that somebody attacked me in the WoSign sanction discussion, but no body say any word for this! Why? Due to Ryan is famous person and I am nobody? Best Regards, Richard Wang On Sep 27, 2018, at 18:24, James Burton mailto:j...@0.me.uk>> wrote: Richard, Your conduct is totally unacceptable and won’t be tolerated. You must read the forum rules regarding etiquette. Also I suggest you apologise to Ryan. James On Thu, 27 Sep 2018 at 10:33, Rob Stradling via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Richard, You might like to familiarize yourself with the Mozilla Forum Etiquette Ground Rules: https://www.mozilla.org/en-US/about/forums/etiquette/ Note this in particular: "Be civil. No personal attacks. Do not feel compelled to defend your honor in public. Posts containing personal attacks may be removed from the news server." On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote: > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer > that gave too many pressures to the M.D.S.P community to misleading the > Community and to let Mozilla make the decision that Google want. > > There are two facts to support my opinion: > > (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that > if we separate StartCom completely from WoSign, then Mozilla don't sanction > StartCom that still trust StartCom root. But Google as peer of Mozilla Module > don't agree this, and Ryan even found many very very old problems of StartCom > to be a "fact" that must be distrusted. Google changed the Mozilla decision! > > (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion > from Ryan Sleevi that Google changed the Mozilla initial decision, this also > is the fact. > > So, we can see Ryan not just a Mozilla Module Peer, he represents Google > browser that affect Mozilla to make the right decision. > > Ryan, don't feel too good about yourself. Peoples patiently look at your long > emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, > this is because you represent Google Chrome, and Google Chrome seriously > affects Mozilla that have the power to kill any CAs. If you leave Google, you > will be nothing, no one will care about your existence, and no one will care > what you say. So, please don't declare that you don't represent Google before > you speak next time, nonsense! > > Your myopic has brought global Internet security to the ditch. Chrome display > "Secure" for a website just it has SSL(https). Many fake banking websites and > fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it > is "Secure", this completely misleads global Internet users, resulting in > many users are deceived and lost property. Encryption is not equal to secure. > Secure means not only encryption, but also need to tell user the website's > true identity. Does a fake bank website encryption mean anything? nothing and > more worse. > > Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 > ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ > > 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets > Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 > > > Best Regards, > > Richard Wang > > Original Message ---- > From: Ryan Sleevi via dev-security-policy > Received: Thursday, 27 September 2018 00:53 > To: Jeremy Rowley > Cc: Ryan Sleevi ; mozilla-dev-security-policy > Subject: Re: Google Trust Services Root Inclusion Request > > > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley > mailto:jeremy.row...@digicert.com>> > wrote: > >> I also should also emphasize that I’m speaking as Jeremy Rowley, not as >> DigiCert. >> >> >> >> Note that I didn’t say Google controlled the policy. However, as a module >> peer, Google does have significant influence over the policy and what CAs >> are trusted by Mozilla. Although everyone can participate in Mozilla >> discussions publicly, it’s a fallacy to state that a general participant >> has similar sway or authority to a module peer. That’s the whole point of >> having a separate class for peers compared to us general public. With >> Google acting as a CA and module peer, you now have one CA heavily >> influencing who its competitors are, how its competitors operate, and what >> its competitors can do. Although I personally find that you never misuse >> your power as a module peer, I can see how Jake has concerns that Google >> (as a CA) has ver
Re: Google Trust Services Root Inclusion Request
On Wed, 26 Sep 2018 23:02:45 +0100 Nick Lamb via dev-security-policy wrote: > Thinking back to, for example, TSYS, my impression was that my post on > the Moral Hazard from granting this exception had at least as much > impact as you could expect for any participant. Mozilla declined to > authorise the (inevitable, to such an extent I pointed out that it > would happen months before it did) request for yet another exception > when TSYS asked again. Correction: The incident I'm thinking of is First Data, not TSYS, a different SHA-1 exception. Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
Richard, Your conduct is totally unacceptable and won’t be tolerated. You must read the forum rules regarding etiquette. Also I suggest you apologise to Ryan. James On Thu, 27 Sep 2018 at 10:33, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Richard, > > You might like to familiarize yourself with the Mozilla Forum Etiquette > Ground Rules: > https://www.mozilla.org/en-US/about/forums/etiquette/ > > Note this in particular: > "Be civil. > No personal attacks. Do not feel compelled to defend your honor in > public. Posts containing personal attacks may be removed from the news > server." > > On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote: > > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module > Peer that gave too many pressures to the M.D.S.P community to misleading > the Community and to let Mozilla make the decision that Google want. > > > > There are two facts to support my opinion: > > > > (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting > that if we separate StartCom completely from WoSign, then Mozilla don't > sanction StartCom that still trust StartCom root. But Google as peer of > Mozilla Module don't agree this, and Ryan even found many very very old > problems of StartCom to be a "fact" that must be distrusted. Google changed > the Mozilla decision! > > > > (2) For Symantec sanction, everyone can see the argues in M.D.S.P > discussion from Ryan Sleevi that Google changed the Mozilla initial > decision, this also is the fact. > > > > So, we can see Ryan not just a Mozilla Module Peer, he represents Google > browser that affect Mozilla to make the right decision. > > > > Ryan, don't feel too good about yourself. Peoples patiently look at your > long emails at M.D.S.P and listen to your bala bala speaking at the CABF > meeting, this is because you represent Google Chrome, and Google Chrome > seriously affects Mozilla that have the power to kill any CAs. If you leave > Google, you will be nothing, no one will care about your existence, and no > one will care what you say. So, please don't declare that you don't > represent Google before you speak next time, nonsense! > > > > Your myopic has brought global Internet security to the ditch. Chrome > display "Secure" for a website just it has SSL(https). Many fake banking > websites and fake PayPal websites have Lets Encrypt certificates, and > Google Chrome say it is "Secure", this completely misleads global Internet > users, resulting in many users are deceived and lost property. Encryption > is not equal to secure. Secure means not only encryption, but also need to > tell user the website's true identity. Does a fake bank website encryption > mean anything? nothing and more worse. > > > > Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 > ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ > > > > 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets > Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 > > > > > > Best Regards, > > > > Richard Wang > > > > Original Message > > From: Ryan Sleevi via dev-security-policy > > Received: Thursday, 27 September 2018 00:53 > > To: Jeremy Rowley > > Cc: Ryan Sleevi ; mozilla-dev-security-policy > > Subject: Re: Google Trust Services Root Inclusion Request > > > > > > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley < > jeremy.row...@digicert.com> > > wrote: > > > >> I also should also emphasize that I’m speaking as Jeremy Rowley, not as > >> DigiCert. > >> > >> > >> > >> Note that I didn’t say Google controlled the policy. However, as a > module > >> peer, Google does have significant influence over the policy and what > CAs > >> are trusted by Mozilla. Although everyone can participate in Mozilla > >> discussions publicly, it’s a fallacy to state that a general participant > >> has similar sway or authority to a module peer. That’s the whole point > of > >> having a separate class for peers compared to us general public. With > >> Google acting as a CA and module peer, you now have one CA heavily > >> influencing who its competitors are, how its competitors operate, and > what > >> its competitors can do. Although I personally find that you never > misuse > >> your power as a module peer, I can see how Jake has concerns that Google > &g
Re: Google Trust Services Root Inclusion Request
Richard, You might like to familiarize yourself with the Mozilla Forum Etiquette Ground Rules: https://www.mozilla.org/en-US/about/forums/etiquette/ Note this in particular: "Be civil. No personal attacks. Do not feel compelled to defend your honor in public. Posts containing personal attacks may be removed from the news server." On 27/09/2018 07:59, Richard Wang via dev-security-policy wrote: > Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer > that gave too many pressures to the M.D.S.P community to misleading the > Community and to let Mozilla make the decision that Google want. > > There are two facts to support my opinion: > > (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that > if we separate StartCom completely from WoSign, then Mozilla don't sanction > StartCom that still trust StartCom root. But Google as peer of Mozilla Module > don't agree this, and Ryan even found many very very old problems of StartCom > to be a "fact" that must be distrusted. Google changed the Mozilla decision! > > (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion > from Ryan Sleevi that Google changed the Mozilla initial decision, this also > is the fact. > > So, we can see Ryan not just a Mozilla Module Peer, he represents Google > browser that affect Mozilla to make the right decision. > > Ryan, don't feel too good about yourself. Peoples patiently look at your long > emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, > this is because you represent Google Chrome, and Google Chrome seriously > affects Mozilla that have the power to kill any CAs. If you leave Google, you > will be nothing, no one will care about your existence, and no one will care > what you say. So, please don't declare that you don't represent Google before > you speak next time, nonsense! > > Your myopic has brought global Internet security to the ditch. Chrome display > "Secure" for a website just it has SSL(https). Many fake banking websites and > fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it > is "Secure", this completely misleads global Internet users, resulting in > many users are deceived and lost property. Encryption is not equal to secure. > Secure means not only encryption, but also need to tell user the website's > true identity. Does a fake bank website encryption mean anything? nothing and > more worse. > > Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 > ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ > > 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets > Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 > > > Best Regards, > > Richard Wang > > Original Message ---- > From: Ryan Sleevi via dev-security-policy > Received: Thursday, 27 September 2018 00:53 > To: Jeremy Rowley > Cc: Ryan Sleevi ; mozilla-dev-security-policy > Subject: Re: Google Trust Services Root Inclusion Request > > > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley > wrote: > >> I also should also emphasize that I’m speaking as Jeremy Rowley, not as >> DigiCert. >> >> >> >> Note that I didn’t say Google controlled the policy. However, as a module >> peer, Google does have significant influence over the policy and what CAs >> are trusted by Mozilla. Although everyone can participate in Mozilla >> discussions publicly, it’s a fallacy to state that a general participant >> has similar sway or authority to a module peer. That’s the whole point of >> having a separate class for peers compared to us general public. With >> Google acting as a CA and module peer, you now have one CA heavily >> influencing who its competitors are, how its competitors operate, and what >> its competitors can do. Although I personally find that you never misuse >> your power as a module peer, I can see how Jake has concerns that Google >> (as a CA) has very heavy influence over the platform that has historically >> been the CA watchdog (Mozilla). >> > > Jeremy, I think this again deserves calling out, because this is > misrepresenting what module peership does, as well as the CA relationship. > > I linked you to the definition of Module Ownership, which highlights and > emphasizes that the module peer is simply a recognized helper. To the > extent there is any influence, it is through the public discussions here. > If your concern is that the title confers some special advantage, that's to &
RE: Re: Google Trust Services Root Inclusion Request
Sorry, I don't agree with this point. Ryan Sleevi is the Mozilla Module Peer that gave too many pressures to the M.D.S.P community to misleading the Community and to let Mozilla make the decision that Google want. There are two facts to support my opinion: (1) For StartCom sanction, Mozilla agreed in Oct 2nd 2016 London meeting that if we separate StartCom completely from WoSign, then Mozilla don't sanction StartCom that still trust StartCom root. But Google as peer of Mozilla Module don't agree this, and Ryan even found many very very old problems of StartCom to be a "fact" that must be distrusted. Google changed the Mozilla decision! (2) For Symantec sanction, everyone can see the argues in M.D.S.P discussion from Ryan Sleevi that Google changed the Mozilla initial decision, this also is the fact. So, we can see Ryan not just a Mozilla Module Peer, he represents Google browser that affect Mozilla to make the right decision. Ryan, don't feel too good about yourself. Peoples patiently look at your long emails at M.D.S.P and listen to your bala bala speaking at the CABF meeting, this is because you represent Google Chrome, and Google Chrome seriously affects Mozilla that have the power to kill any CAs. If you leave Google, you will be nothing, no one will care about your existence, and no one will care what you say. So, please don't declare that you don't represent Google before you speak next time, nonsense! Your myopic has brought global Internet security to the ditch. Chrome display "Secure" for a website just it has SSL(https). Many fake banking websites and fake PayPal websites have Lets Encrypt certificates, and Google Chrome say it is "Secure", this completely misleads global Internet users, resulting in many users are deceived and lost property. Encryption is not equal to secure. Secure means not only encryption, but also need to tell user the website's true identity. Does a fake bank website encryption mean anything? nothing and more worse. Ryan, 别自我感觉太好，别人耐心看你在M.D.S.P的长篇大论和听你在CABF meeting上说过没完 ，是因为你代表谷歌浏览器，而谷歌浏览器严重影响Mozilla对所有CA有生杀大权。如果你离开谷歌，你将什么也不是，没有人会理会你的存在，也没有人会在意你说的话。所以下次不要在发言之前就声明不代表谷歌，废话哦！ 你的短视把全球互联网安全带到了沟里，认为有SSL证书(https)就安全，许多假冒银行网站、假冒PayPal 网站都有Lets Encrypt证书，谷歌浏览器显示为安全，完全误导了全球互联网用户，导致许多用户上当受骗和财产损失。已加密并不等于安全，安全不仅意味着需要加密，而且还需要告知用户此网站的真实身份，一个假冒银行网站加密有任何意义吗？没有并且更糟糕。 Best Regards, Richard Wang Original Message From: Ryan Sleevi via dev-security-policy Received: Thursday, 27 September 2018 00:53 To: Jeremy Rowley Cc: Ryan Sleevi ; mozilla-dev-security-policy Subject: Re: Google Trust Services Root Inclusion Request On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley wrote: > I also should also emphasize that I’m speaking as Jeremy Rowley, not as > DigiCert. > > > > Note that I didn’t say Google controlled the policy. However, as a module > peer, Google does have significant influence over the policy and what CAs > are trusted by Mozilla. Although everyone can participate in Mozilla > discussions publicly, it’s a fallacy to state that a general participant > has similar sway or authority to a module peer. That’s the whole point of > having a separate class for peers compared to us general public. With > Google acting as a CA and module peer, you now have one CA heavily > influencing who its competitors are, how its competitors operate, and what > its competitors can do. Although I personally find that you never misuse > your power as a module peer, I can see how Jake has concerns that Google > (as a CA) has very heavy influence over the platform that has historically > been the CA watchdog (Mozilla). > Jeremy, I think this again deserves calling out, because this is misrepresenting what module peership does, as well as the CA relationship. I linked you to the definition of Module Ownership, which highlights and emphasizes that the module peer is simply a recognized helper. To the extent there is any influence, it is through the public discussions here. If your concern is that the title confers some special advantage, that's to misread what module peer is. If your concern is that the participation - which provides solid technical arguments as well as the policy alternatives - is influential, then what you're arguing against is public participation. You're presenting these as factual, and that's misleading, so I'd like to highlight what is actually entailed. > The circumstances are different between the scenarios you describe with > respect to the other browsers, as is market share. If Microsoft wants to > change CAs (and they already use multiple), they can without impacting > public perception. If Apple wants to use another CA, they can without > people commenting how odd it is that Apple doesn’t use the Apple CA. With > Google controlling the CA and the Google browser, all incentive to > eliminate any misbehaving Goog
RE: Re: Re: Google Trust Services Root Inclusion Request
Hi Ryan, Thanks for your point out the link "https://wiki.mozilla.org/CA:WoSign_Issues'. I think I need to say more words about "misleading" and "lie". I like to expose some FACTs to show the public, to let public know who is misleading and lie. For the initiate WoSign issues email in M.D.S.P in Aug 24, 2016 -- Issue 0 (a.k.a. Issue L: Any Port (Jan - Apr 2015), Mozilla wrote: "This problem was reported to Google, and thence to WoSign and resolved. Mozilla only became aware of it recently.” The FACT is Google Ryan Sleevi sent email to Richard Wang at April 4th 2015 to point out the problems (see below original email), NOT WoSign reported to Google, this is the first misleading and lie. The second "lie" is Ryan Sleevi is the Mozilla Module Peer, this mean Mozilla know this case, why someone say “Mozilla only became aware of it recently."(August 24, 2016)? This is second misleading and lie. - Original Message From: Ryan Sleevi Received: Saturday, 04 April 2015 09:25 To: Richard Wang Subject: WoSign Irregularities Hi Richard, It's come to our attention that WoSign may be issuing certificates that are not conforming to your CPS and not conforming to the Baseline Requirements. While we're still investigating the nature and scope, I was hoping you could take the opportunity and ensure that the certificates you're issuing are consistent with the Baseline Requirements and consistent to your CPS. Among other things, I've noted irregularities in: - Subject Information - Extensions - Certificate Policies - Issuer Alternative Name Could you please examine your certificates and let me know of any irregularities that you have detected and what steps have been taken (per Section 8.2 of your CPS) Also, can you please provide your most recent audit? The most recent BR audit available was for the period of 1 January 2013 through 31 December 2013, completed on 28 March 2014. I see you've already completed Seals 1843 (Principles & Practices) and 1842 (EV). When do you expect an audit for the period of 1 January 2014 through 31 December 2014 to be made available? --- Best Regards, Richard Wang Original Message From: Ryan Sleevi via dev-security-policy Received: Thursday, 27 September 2018 00:44 To: Richard Wang Cc: Ryan Sleevi ; mozilla-dev-security-policy ; Jeremy Rowley Subject: Re: Re: Google Trust Services Root Inclusion Request Hi Richard, A few corrections: On Wed, Sep 26, 2018 at 11:36 AM Richard Wang via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan mentioned WoSign/StartCom and 360, so I like to say some words. > > First, I think your idea is not a proper metaphor because 360 browser > can't compare to Google browser, Google browser have absolutely strong > market share to say YES/NO to all CAs, but I am sure not to Google CA. > That wasn't the comparison. I was more highlighting how you actively mislead (lied?) to the community about the relationship between the entities, by trying to argue as separate entities. While Google Trust Services is a separate legal entity, which is about ensuring there is a firewall between these organizations, my concern about bringing it up was because of how you actively mislead the community. > Third, your comparison of Apple and Microsoft is also not correct, they > use its own CA system for their own system use only, not for public, not to > be a global public CA like Google. > I'm afraid this also misunderstands things. Microsoft does issue certificates for end-users using its services (like Google). To the point of the discussion, however, it was about the assumption and implication that you cannot distrust an entity that operates a large web presence and also a CA, or that browsers would play special favors to the CAs of their properties, whether in-house or external. Both of these apply to all browsers - arguably, even Mozilla (which uses certs from DigiCert as well, either through the Amazon-branded sub-CA that DigiCert operates or directly through DigiCert) > Ryan, thank you for still remembering WoSign. > I think it will be very hard for the community to ever forget https://wiki.mozilla.org/CA:WoSign_Issues ___ 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 Root Inclusion Request
On Wed, 26 Sep 2018 16:03:58 + Jeremy Rowley via dev-security-policy wrote: > Note that I didn’t say Google controlled the policy. However, as a > module peer, Google does have significant influence over the policy > and what CAs are trusted by Mozilla. Although everyone can > participate in Mozilla discussions publicly, it’s a fallacy to state > that a general participant has similar sway or authority to a module > peer. I do not agree with this. I participate in m.d.s.policy as an individual and I don't think there has ever been a situation where I felt I did not have "similar sway or authority to a module peer". Thinking back to, for example, TSYS, my impression was that my post on the Moral Hazard from granting this exception had at least as much impact as you could expect for any participant. Mozilla declined to authorise the (inevitable, to such an extent I pointed out that it would happen months before it did) request for yet another exception when TSYS asked again. I think my situation may be different from yours Jeremy in that even when posting strictly in a personal capacity your "other hat" remains in view. I don't really have another hat, I'm a Relying Party from the Network. I want the Network to be able to Rely on the Web PKI and I seek the Prevention of Future Harm to myself and other Relying Parties. That lines up really well with Mozilla's goals (not quite perfectly since Mozilla cares primarily about Firefox not generic Relying Parties) Nick. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
I'm disputing the conclusion that is being drawn from Jake's concerns, rather than the concerns themselves. Primarily, I disagree with the conclusion that because Google owns a browser with dominant market share and - due to the substantial contributions they make here - because Google has considerable influence in this community, they should not be allowed to participate in our root program as a CA. Secondarily, I disagree that a Google employee should not be a peer of this module due to the potential for a conflict of interest. Unpacking this conclusion in terms of policy it implies, I think the argument being made is that any root store operator should be excluded from membership in the Mozilla program as a CA, and any employee of a CA should be prohibited from being a module peer. The argument is that this will protect us from future conflicts of interest (there seems to be agreement that the concern is hypothetical at this point). My conclusion is that rather than creating somewhat arbitrary, exclusionary rules, we can and should instead rely on the openness and inclusiveness of our process to protect us from conflicts of interest. If Google attempts to gain preferential treatment for their CA from Mozilla, our community can and will identify it, reject it, and hold Mozilla accountable for acting in their best interest. On Wed, Sep 26, 2018 at 9:49 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley > > wrote: > > > I also should also emphasize that I’m speaking as Jeremy Rowley, not as > > DigiCert. > > > > > > > > Note that I didn’t say Google controlled the policy. However, as a module > > peer, Google does have significant influence over the policy and what CAs > > are trusted by Mozilla. Although everyone can participate in Mozilla > > discussions publicly, it’s a fallacy to state that a general participant > > has similar sway or authority to a module peer. That’s the whole point of > > having a separate class for peers compared to us general public. With > > Google acting as a CA and module peer, you now have one CA heavily > > influencing who its competitors are, how its competitors operate, and > what > > its competitors can do. Although I personally find that you never misuse > > your power as a module peer, I can see how Jake has concerns that Google > > (as a CA) has very heavy influence over the platform that has > historically > > been the CA watchdog (Mozilla). > > > > Jeremy, I think this again deserves calling out, because this is > misrepresenting what module peership does, as well as the CA relationship. > > I linked you to the definition of Module Ownership, which highlights and > emphasizes that the module peer is simply a recognized helper. To the > extent there is any influence, it is through the public discussions here. > If your concern is that the title confers some special advantage, that's to > misread what module peer is. If your concern is that the participation - > which provides solid technical arguments as well as the policy alternatives > - is influential, then what you're arguing against is public participation. > > You're presenting these as factual, and that's misleading, so I'd like to > highlight what is actually entailed. > > > > The circumstances are different between the scenarios you describe with > > respect to the other browsers, as is market share. If Microsoft wants to > > change CAs (and they already use multiple), they can without impacting > > public perception. If Apple wants to use another CA, they can without > > people commenting how odd it is that Apple doesn’t use the Apple CA. With > > Google controlling the CA and the Google browser, all incentive to > > eliminate any misbehaving Google CA disappears for financial reasons, > > public perception, and because Google can control the messaging (through > > marketshare and influence over Mozilla policy). Note that there is > > historical precedent for Google treating Google special – i.e. the > > exclusion for Google in the Symantec distrust plan. Thus, I think Jake’s > > concerns should not be discarded so readily. > > > > I can understand and appreciate why you have this perspective. I disagree > that it's an accurate representation, and as shown by the previous message, > it does not have factual basis. I think it's misleading to suggest that the > concerns are being discarded, much like yours - they're being responded to > with supporting evidence and careful analysis. However, they do not hold > water, and while it would be ideal to convince you of this as well, it's > equally important to be transparent about it. > > Your argument above seems to boil down to "People would notice if Google > changed CAs, but not if Microsoft" - yet that's not supported (see, > example, the usage of Let's Encrypt by Google, or the former usage of > WoSign by Microsoft). Your argument about incentives entirely ignores
Re: Google Trust Services Root Inclusion Request
On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley wrote: > I also should also emphasize that I’m speaking as Jeremy Rowley, not as > DigiCert. > > > > Note that I didn’t say Google controlled the policy. However, as a module > peer, Google does have significant influence over the policy and what CAs > are trusted by Mozilla. Although everyone can participate in Mozilla > discussions publicly, it’s a fallacy to state that a general participant > has similar sway or authority to a module peer. That’s the whole point of > having a separate class for peers compared to us general public. With > Google acting as a CA and module peer, you now have one CA heavily > influencing who its competitors are, how its competitors operate, and what > its competitors can do. Although I personally find that you never misuse > your power as a module peer, I can see how Jake has concerns that Google > (as a CA) has very heavy influence over the platform that has historically > been the CA watchdog (Mozilla). > Jeremy, I think this again deserves calling out, because this is misrepresenting what module peership does, as well as the CA relationship. I linked you to the definition of Module Ownership, which highlights and emphasizes that the module peer is simply a recognized helper. To the extent there is any influence, it is through the public discussions here. If your concern is that the title confers some special advantage, that's to misread what module peer is. If your concern is that the participation - which provides solid technical arguments as well as the policy alternatives - is influential, then what you're arguing against is public participation. You're presenting these as factual, and that's misleading, so I'd like to highlight what is actually entailed. > The circumstances are different between the scenarios you describe with > respect to the other browsers, as is market share. If Microsoft wants to > change CAs (and they already use multiple), they can without impacting > public perception. If Apple wants to use another CA, they can without > people commenting how odd it is that Apple doesn’t use the Apple CA. With > Google controlling the CA and the Google browser, all incentive to > eliminate any misbehaving Google CA disappears for financial reasons, > public perception, and because Google can control the messaging (through > marketshare and influence over Mozilla policy). Note that there is > historical precedent for Google treating Google special – i.e. the > exclusion for Google in the Symantec distrust plan. Thus, I think Jake’s > concerns should not be discarded so readily. > I can understand and appreciate why you have this perspective. I disagree that it's an accurate representation, and as shown by the previous message, it does not have factual basis. I think it's misleading to suggest that the concerns are being discarded, much like yours - they're being responded to with supporting evidence and careful analysis. However, they do not hold water, and while it would be ideal to convince you of this as well, it's equally important to be transparent about it. Your argument above seems to boil down to "People would notice if Google changed CAs, but not if Microsoft" - yet that's not supported (see, example, the usage of Let's Encrypt by Google, or the former usage of WoSign by Microsoft). Your argument about incentives entirely ignores the incentives I just described to you previously - which look at public perception, internet security, and ecosystem stability. Your argument about influence over Mozilla policy has already been demonstrated as false and misleading, but it seems you won't be convinced by that. And your suggestion of special treatment ignores the facts of the situation (the validation issues, the scoping of audits, that Apple and 2 other CAs were also included in the exclusion), ignores the more significant special treatment granted by other vendors (e.g. Apple's exclusion of a host of mismanaged Symantec sub-CAs now under DigiCert's operational control), the past precedent (e.g. the gradual distrust of WoSign/StartCom through whitelists, of CNNIC through whitelists), and the public discussion involved so entirely that it's entirely unfounded. So I think your continued suggestion that it's being discarded so readily is, again, misleading and inaccurate. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Re: Google Trust Services Root Inclusion Request
Hi Richard, A few corrections: On Wed, Sep 26, 2018 at 11:36 AM Richard Wang via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Ryan mentioned WoSign/StartCom and 360, so I like to say some words. > > First, I think your idea is not a proper metaphor because 360 browser > can't compare to Google browser, Google browser have absolutely strong > market share to say YES/NO to all CAs, but I am sure not to Google CA. > That wasn't the comparison. I was more highlighting how you actively mislead (lied?) to the community about the relationship between the entities, by trying to argue as separate entities. While Google Trust Services is a separate legal entity, which is about ensuring there is a firewall between these organizations, my concern about bringing it up was because of how you actively mislead the community. > Third, your comparison of Apple and Microsoft is also not correct, they > use its own CA system for their own system use only, not for public, not to > be a global public CA like Google. > I'm afraid this also misunderstands things. Microsoft does issue certificates for end-users using its services (like Google). To the point of the discussion, however, it was about the assumption and implication that you cannot distrust an entity that operates a large web presence and also a CA, or that browsers would play special favors to the CAs of their properties, whether in-house or external. Both of these apply to all browsers - arguably, even Mozilla (which uses certs from DigiCert as well, either through the Amazon-branded sub-CA that DigiCert operates or directly through DigiCert) > Ryan, thank you for still remembering WoSign. > I think it will be very hard for the community to ever forget https://wiki.mozilla.org/CA:WoSign_Issues ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Google Trust Services Root Inclusion Request
I also should also emphasize that I’m speaking as Jeremy Rowley, not as DigiCert. Note that I didn’t say Google controlled the policy. However, as a module peer, Google does have significant influence over the policy and what CAs are trusted by Mozilla. Although everyone can participate in Mozilla discussions publicly, it’s a fallacy to state that a general participant has similar sway or authority to a module peer. That’s the whole point of having a separate class for peers compared to us general public. With Google acting as a CA and module peer, you now have one CA heavily influencing who its competitors are, how its competitors operate, and what its competitors can do. Although I personally find that you never misuse your power as a module peer, I can see how Jake has concerns that Google (as a CA) has very heavy influence over the platform that has historically been the CA watchdog (Mozilla). The circumstances are different between the scenarios you describe with respect to the other browsers, as is market share. If Microsoft wants to change CAs (and they already use multiple), they can without impacting public perception. If Apple wants to use another CA, they can without people commenting how odd it is that Apple doesn’t use the Apple CA. With Google controlling the CA and the Google browser, all incentive to eliminate any misbehaving Google CA disappears for financial reasons, public perception, and because Google can control the messaging (through marketshare and influence over Mozilla policy). Note that there is historical precedent for Google treating Google special – i.e. the exclusion for Google in the Symantec distrust plan. Thus, I think Jake’s concerns should not be discarded so readily. From: Ryan Sleevi Sent: Wednesday, September 26, 2018 12:43 AM To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services Root Inclusion Request (While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm going to emphasize that this response is in a personal capacity) On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org> > wrote: Jake's concern is legit if you believe certain assumptions. Criticizing his rationale doesn't seem correct, especially since Google does indeed have a root store. Although not traditional, Google runs a store of blacklisted CAs (see Symantec), which is every bit as effective as controlling CA compliance and operation as the inclusion process. To be clear: Google does indeed operate root stores on a host of devices, including Android and ChromeOS, not to mention Google Cloud functionality. FACT: As a browser, Google already interprets the CA/Browser requirements in many ways via, intentionally or not. The Google's policies, and how Google implements Chrome are all closely watched by CAs and help dictate how we interpret the various requirements. This fact combined with the assumption that Google will never distrust itself jumps to a conclusion that Google will only interpreting the BRs in Google CA's best interests. Why wouldn't they? Google is a for profit company. Self-promotion is kind-of in the description. The problem with this assumption, or at least what logically follows, is that every Browser would behave the same, beneficient towards the CA(s) they use for services. For example, Microsoft operates a root program, yet is also trusted by Mozilla through the subordinate CAs provided through the Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly, Apple operates a root program, yet is also trusted by Mozilla through subordinate CAs provided through the GeoTrust hierarchy, which is owned by... DigiCert. Google operates a root program, yet is also trusted by Mozilla through... the acquisition of key material (from GlobalSign) and the operation of independent roots. If we accept this assumption as sound, then it seems the argument is that DigiCert can also never be distrusted, and interpretations will always be to the benefit of DigiCert, because to distrust DigiCert or take sanction would be to disrupt 'critical' services like Azure or iTunes. Alternatively, one could argue/make assumptions that by virtue of Google previously having operated a subordinate under the GeoTrust hierarchy (DigiCert, formerly Symantec), that they've demonstrated it's possible to operate as subordinate or root. They demonstrably took steps regarding the Symantec hierarchy, even as it was the basis for trust of Google services. In that model, if Google CA were to take actions detrimental to the ecosystem, Google may interpret the BRs in the Internet trust and stabilities best interests, distrust the Google CA, and force Google to transition to an alternative solution precisely to avoid the alternative. The problem here is these are all assum
RE: Re: Google Trust Services Root Inclusion Request
Ryan mentioned WoSign/StartCom and 360, so I like to say some words. First, I think your idea is not a proper metaphor because 360 browser can't compare to Google browser, Google browser have absolutely strong market share to say YES/NO to all CAs, but I am sure not to Google CA. Second, I think Google to be a global public CA is a wrong decision, this is the same situation that one person is the athlete and the judge, how to guarantee the fair? This two business have conflict of interest. Third, your comparison of Apple and Microsoft is also not correct, they use its own CA system for their own system use only, not for public, not to be a global public CA like Google. So, I think accepting Google root to Mozilla trust store don't benefit for anyone except Google only, not for the Internet security community, not for the CA industry and not for end users. Ryan, thank you for still remembering WoSign. Best Regards, Richard Wang Original message From: Ryan Sleevi via dev-security-policy Received: 2018-09-26 14:48:28 To: Jeremy Rowley Cc: mozilla-dev-security-pol...@lists.mozilla.org Subject: Re: Google Trust Services Root Inclusion Request (While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm going to emphasize that this response is in a personal capacity) On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Jake's concern is legit if you believe certain assumptions. Criticizing his > rationale doesn't seem correct, especially since Google does indeed have a > root store. Although not traditional, Google runs a store of blacklisted > CAs > (see Symantec), which is every bit as effective as controlling CA > compliance > and operation as the inclusion process. > To be clear: Google does indeed operate root stores on a host of devices, including Android and ChromeOS, not to mention Google Cloud functionality. > FACT: As a browser, Google already interprets the CA/Browser requirements > in > many ways via, intentionally or not. The Google's policies, and how Google > implements Chrome are all closely watched by CAs and help dictate how we > interpret the various requirements. > > This fact combined with the assumption that Google will never distrust > itself jumps to a conclusion that Google will only interpreting the BRs in > Google CA's best interests. Why wouldn't they? Google is a for profit > company. Self-promotion is kind-of in the description. > The problem with this assumption, or at least what logically follows, is that every Browser would behave the same, beneficient towards the CA(s) they use for services. For example, Microsoft operates a root program, yet is also trusted by Mozilla through the subordinate CAs provided through the Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly, Apple operates a root program, yet is also trusted by Mozilla through subordinate CAs provided through the GeoTrust hierarchy, which is owned by... DigiCert. Google operates a root program, yet is also trusted by Mozilla through... the acquisition of key material (from GlobalSign) and the operation of independent roots. If we accept this assumption as sound, then it seems the argument is that DigiCert can also never be distrusted, and interpretations will always be to the benefit of DigiCert, because to distrust DigiCert or take sanction would be to disrupt 'critical' services like Azure or iTunes. Alternatively, one could argue/make assumptions that by virtue of Google previously having operated a subordinate under the GeoTrust hierarchy (DigiCert, formerly Symantec), that they've demonstrated it's possible to operate as subordinate or root. They demonstrably took steps regarding the Symantec hierarchy, even as it was the basis for trust of Google services. In that model, if Google CA were to take actions detrimental to the ecosystem, Google may interpret the BRs in the Internet trust and stabilities best interests, distrust the Google CA, and force Google to transition to an alternative solution precisely to avoid the alternative. The problem here is these are all assumptions that rest on ignoring pertinent details. > FACT: Google is a module peer in Mozilla NSS, which means Google has > significant influence over BR interpretation, the penalties related to CA > mis-issuance, and the requirements a CA has for operating within the space. > This gives one CA a lot of influence over how Mozilla treats the other > CAs. > The change in paradigm means a reasonable person (like Jake) could be > concerned with potential obfuscation of problems, a loss of policy > enforcement, and various other nefarious acts. I think most of us Mozilla > users see Mozilla as a watch-dog of the Internet so this combination of > Browser-CA-module peer reasonably causes unease. > Un
Re: Google Trust Services Root Inclusion Request
On 26/09/2018 09:43 πμ, Ryan Sleevi via dev-security-policy wrote: > (While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm > going to emphasize that this response is in a personal capacity) > > On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> Jake's concern is legit if you believe certain assumptions. Criticizing his >> rationale doesn't seem correct, especially since Google does indeed have a >> root store. Although not traditional, Google runs a store of blacklisted >> CAs >> (see Symantec), which is every bit as effective as controlling CA >> compliance >> and operation as the inclusion process. >> > > To be clear: Google does indeed operate root stores on a host of devices, > including Android and ChromeOS, not to mention Google Cloud functionality. > > >> FACT: As a browser, Google already interprets the CA/Browser requirements >> in >> many ways via, intentionally or not. The Google's policies, and how Google >> implements Chrome are all closely watched by CAs and help dictate how we >> interpret the various requirements. >> > > >> This fact combined with the assumption that Google will never distrust >> itself jumps to a conclusion that Google will only interpreting the BRs in >> Google CA's best interests. Why wouldn't they? Google is a for profit >> company. Self-promotion is kind-of in the description. >> > > The problem with this assumption, or at least what logically follows, is > that every Browser would behave the same, beneficient towards the CA(s) > they use for services. For example, Microsoft operates a root program, yet > is also trusted by Mozilla through the subordinate CAs provided through the > Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly, > Apple operates a root program, yet is also trusted by Mozilla through > subordinate CAs provided through the GeoTrust hierarchy, which is owned > by... DigiCert. > > Google operates a root program, yet is also trusted by Mozilla through... > the acquisition of key material (from GlobalSign) and the operation of > independent roots. > > If we accept this assumption as sound, then it seems the argument is that > DigiCert can also never be distrusted, and interpretations will always be > to the benefit of DigiCert, because to distrust DigiCert or take sanction > would be to disrupt 'critical' services like Azure or iTunes. > > Alternatively, one could argue/make assumptions that by virtue of Google > previously having operated a subordinate under the GeoTrust hierarchy > (DigiCert, formerly Symantec), that they've demonstrated it's possible to > operate as subordinate or root. They demonstrably took steps regarding the > Symantec hierarchy, even as it was the basis for trust of Google services. > In that model, if Google CA were to take actions detrimental to the > ecosystem, Google may interpret the BRs in the Internet trust and > stabilities best interests, distrust the Google CA, and force Google to > transition to an alternative solution precisely to avoid the alternative. > > The problem here is these are all assumptions that rest on ignoring > pertinent details. I would like to add that based on previous experience, Google has built a firewall between the Chrome and the rest of the teams. And it seems that there is a special treatment by the Chrome team, but not the one stated. Google trying to set the example is more strict when it comes to their own services. For example, you can see the history behind freezing the google-run Aviator log. Even though other logs, such as the ones run by Venafi and the DigiCert, had single MMD violations and were not disqualified, Google decided to freeze Aviator. I think this is a clear indication that Google does not favor their own services. Regards, Fotis > > >> FACT: Google is a module peer in Mozilla NSS, which means Google has >> significant influence over BR interpretation, the penalties related to CA >> mis-issuance, and the requirements a CA has for operating within the space. >> This gives one CA a lot of influence over how Mozilla treats the other >> CAs. >> The change in paradigm means a reasonable person (like Jake) could be >> concerned with potential obfuscation of problems, a loss of policy >> enforcement, and various other nefarious acts. I think most of us Mozilla >> users see Mozilla as a watch-dog of the Internet so this combination of >> Browser-CA-module peer reasonably causes unease. >> > > Unfortunately, this FACT isn't correct - it doesn't reflect the Module > Ownership Governance System, which is covered in > https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ . > A peer isn't the decision maker - that rests with the Owner, particularly > for matters of things like policy. > > We could discuss the semantics of Google vs Google Trust Services, but I > fully acknowledge that it would go over about as well as WoSign vs
Re: Google Trust Services Root Inclusion Request
(While covered in https://wiki.mozilla.org/CA/Policy_Participants , I'm going to emphasize that this response is in a personal capacity) On Wed, Sep 26, 2018 at 12:10 AM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Jake's concern is legit if you believe certain assumptions. Criticizing his > rationale doesn't seem correct, especially since Google does indeed have a > root store. Although not traditional, Google runs a store of blacklisted > CAs > (see Symantec), which is every bit as effective as controlling CA > compliance > and operation as the inclusion process. > To be clear: Google does indeed operate root stores on a host of devices, including Android and ChromeOS, not to mention Google Cloud functionality. > FACT: As a browser, Google already interprets the CA/Browser requirements > in > many ways via, intentionally or not. The Google's policies, and how Google > implements Chrome are all closely watched by CAs and help dictate how we > interpret the various requirements. > > This fact combined with the assumption that Google will never distrust > itself jumps to a conclusion that Google will only interpreting the BRs in > Google CA's best interests. Why wouldn't they? Google is a for profit > company. Self-promotion is kind-of in the description. > The problem with this assumption, or at least what logically follows, is that every Browser would behave the same, beneficient towards the CA(s) they use for services. For example, Microsoft operates a root program, yet is also trusted by Mozilla through the subordinate CAs provided through the Baltimore Cybertrust hierarchy, which is owned by... DigiCert. Similarly, Apple operates a root program, yet is also trusted by Mozilla through subordinate CAs provided through the GeoTrust hierarchy, which is owned by... DigiCert. Google operates a root program, yet is also trusted by Mozilla through... the acquisition of key material (from GlobalSign) and the operation of independent roots. If we accept this assumption as sound, then it seems the argument is that DigiCert can also never be distrusted, and interpretations will always be to the benefit of DigiCert, because to distrust DigiCert or take sanction would be to disrupt 'critical' services like Azure or iTunes. Alternatively, one could argue/make assumptions that by virtue of Google previously having operated a subordinate under the GeoTrust hierarchy (DigiCert, formerly Symantec), that they've demonstrated it's possible to operate as subordinate or root. They demonstrably took steps regarding the Symantec hierarchy, even as it was the basis for trust of Google services. In that model, if Google CA were to take actions detrimental to the ecosystem, Google may interpret the BRs in the Internet trust and stabilities best interests, distrust the Google CA, and force Google to transition to an alternative solution precisely to avoid the alternative. The problem here is these are all assumptions that rest on ignoring pertinent details. > FACT: Google is a module peer in Mozilla NSS, which means Google has > significant influence over BR interpretation, the penalties related to CA > mis-issuance, and the requirements a CA has for operating within the space. > This gives one CA a lot of influence over how Mozilla treats the other > CAs. > The change in paradigm means a reasonable person (like Jake) could be > concerned with potential obfuscation of problems, a loss of policy > enforcement, and various other nefarious acts. I think most of us Mozilla > users see Mozilla as a watch-dog of the Internet so this combination of > Browser-CA-module peer reasonably causes unease. > Unfortunately, this FACT isn't correct - it doesn't reflect the Module Ownership Governance System, which is covered in https://www.mozilla.org/en-US/about/governance/policies/module-ownership/ . A peer isn't the decision maker - that rests with the Owner, particularly for matters of things like policy. We could discuss the semantics of Google vs Google Trust Services, but I fully acknowledge that it would go over about as well as WoSign vs StartCom vs Qihoo 360. We could discuss https://wiki.mozilla.org/CA/Policy_Participants and its set of disclosures, but I'm sure some people will find that unsatisfying. What is perhaps most relevant is to highlight the fact that these questions of interpretation - of BRs or policies - happen on the list, that the module owner is the decision maker, and that public participation is fully welcomed, whether peers or otherwise. In that model - of transparency - doesn't support the claims being presented here as 'fact', and instead highlights them as 'assumption's that they are. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
On Mon, 17 Sep 2018 18:41:07 -0500 Jake Weisz via dev-security-policy wrote: > I guess under this logic, I withdraw my protest. As you say, Google > could simply start using these certificates, and Mozilla executives > would force you to accept them regardless of any policy violations in > order to keep people using Firefox. This whole process appears to > mostly just be a veneer of legitimacy on a process roughly akin to the > fair and democratic election of Vladimir Putin. :| As long as Google > remains legally answerable to no authority and an effective monopoly > in half a dozen markets, there is roughly no point for Mozilla to > maintain a CA policy: It should simply use Chrome's trusted store. I think you've misunderstood. What happened was that somebody turned your logic on itself, to show that it tears itself to pieces. The right conclusion to draw from that is "My whole position is senseless and I must reconsider". It's analogous to the mathematical "proof by contradiction". It certainly isn't our intent to say you're right, but only to follow your position to its self-defeating logical conclusion. Also, in passing, it would help if you knew that, for example, Chrome doesn't have a trust store, Google operates a root trust programme in its role as an Operating system vendor (for Android) but the Chrome browser uses the OS-provided trust store, a Chrome on Windows trusts the various obscure Government CAs that Microsoft decided are trustworthy, a Chrome on macOS trusts whatever Apple trusts, and so on. > Google's explanation in their announcement seems to confirm my > statement: That buying roots from GlobalSign is effectively > backdooring the CA process and making their certificates work in > products which would not otherwise trust them. Mechanically it is necessary to have trust from existing systems or you can't run a new CA for many years while you wait for new systems that do trust you to be deployed. [ For example for Let's Encrypt this was ensured by obtaining cross signatures on the Let's Encrypt intermediates from Identrust's DST Root CA X3. ] This fact makes a difference to what a CA might plausibly choose to do, operationally, but doesn't alter how trustworthy, or otherwise that CA is to operate a store today, which is the purpose of Mozilla's process here. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
A few thoughts, inlined below... On Monday, September 17, 2018 at 6:42:29 PM UTC-5, Jake Weisz wrote: > I guess under this logic, I withdraw my protest. As you say, Google > could simply start using these certificates, and Mozilla executives > would force you to accept them regardless of any policy violations in > order to keep people using Firefox. This whole process appears to > mostly just be a veneer of legitimacy on a process roughly akin to the > fair and democratic election of Vladimir Putin. :| As long as Google > remains legally answerable to no authority and an effective monopoly > in half a dozen markets, there is roughly no point for Mozilla to > maintain a CA policy: It should simply use Chrome's trusted store. Your summation here does not logically follow. Yes, it's true that with a giant installed base of Chrome and the ability to auto-update it, Google can more or less arbitrarily insert new trust into their browser with impunity. Having said that, they have historically not done so. In fact -- and I think this may be changing -- for now, Chrome on most platforms delegates initial trust decision to the OS's corresponding trust store. Chrome on MacOS / Chrome on IOS use the native APIs and Apple trust store to determine initial trust, then Chrome applies further logic to downgrade trust of certain scenarios (Symantec descendant certs, etc.) Chrome on Windows presently uses the Windows APIs and Windows trust store. It has been suggested that Chrome ultimately intends to maintain a formal Chrome trust store, but this is not the case today. Today this means that to be trusted on Windows, even in Chrome, you have to be in the Microsoft root program. To be trusted on Apple platforms, even in Chrome, you have to be in the Apple root program. To date, no one has caught Chrome trusting things it shouldn't by way of an automated update. If they tried to do that without good explanation, it would be easily caught at the level of scale that Chrome is used at. It is undeniable that the various titans of the internet wield enormous power over the software and infrastructure of the internet. Historically, Google is a significant enough contributor to Mozilla financially that it's hard to imagine that Mozilla would deny them much even if making Firefox trust everything that Chrome trusts didn't become competitively necessary. Nevertheless, even if Google were totally exempt from the standards for inclusion and even if Google didn't act honorably in their inclusions (though nothing has suggested this), your argument that Mozilla shouldn't bother with a trust store / root program is illogical. Even if Google got a truly free pass, someone still has to police the many others who want to be in the trust program. > Google's explanation in their announcement seems to confirm my > statement: That buying roots from GlobalSign is effectively > backdooring the CA process and making their certificates work in > products which would not otherwise trust them. Actually, Google took a bit of heat from the community and the Mozilla root program regarding the acquisitions of that root and of the transfer of the roots to Google. While ultimately no action was taken against Google or Globalsign as a direct result of those transfers, the transfers did evidence holes in the program's policies and further revisions were made and guidance given for any future transfers. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
I guess under this logic, I withdraw my protest. As you say, Google could simply start using these certificates, and Mozilla executives would force you to accept them regardless of any policy violations in order to keep people using Firefox. This whole process appears to mostly just be a veneer of legitimacy on a process roughly akin to the fair and democratic election of Vladimir Putin. :| As long as Google remains legally answerable to no authority and an effective monopoly in half a dozen markets, there is roughly no point for Mozilla to maintain a CA policy: It should simply use Chrome's trusted store. Google's explanation in their announcement seems to confirm my statement: That buying roots from GlobalSign is effectively backdooring the CA process and making their certificates work in products which would not otherwise trust them. -Jacob Weisz On Mon, Sep 17, 2018 at 6:19 PM, Wayne Thayer wrote: > On Mon, Sep 17, 2018 at 3:19 PM jtness--- via dev-security-policy > wrote: >> >> >> The risk of any given browser vendor also being a Root CA is small as most >> browser vendors do not have the requisite market share to make unilateral >> decisions. Google possesses over 60% of the browser market and 80% of the >> mobile operating system market. What avenues does Mozilla have to >> realistically push back if Google abuses their effective authority over the >> Internet via browser share in the CA space? Presumably "Firefox becomes the >> browser that can't establish a connection to google.com or gmail.com" is >> outside of the realm of realistic scenarios. Neither Apple nor Microsoft has >> the market share to summarily decide a CA is no longer in business, Google >> can. >> > I don't agree with this logic. Most websites care a lot about losing even 1% > of users to untrusted certificates. Also, a logical conclusion from this > argument is that Mozilla can't decide to deny this inclusion request, > especially given that Microsoft has already accepted these roots, because if > we do then Google will just go ahead and use them anyhow. I don't agree with > that conclusion either. > >> It would seem to me that Google is already the judge, jury, and >> executioner of the public key infrastructure, and they're about to have a >> strong financial interest in each CA that is found guilty. Presumably if >> Google were to summarily execute another large CA in the future, after >> launching their own certificate offering, they would see a large uptick in >> business. >> >> With regards to your linked discussion about the GlobalSign root >> acquisition, I see nothing but more reasons to be concerned. Is there any >> reason for Google to have acquired the roots from GlobalSign except to >> backdoor their way into already being in Mozilla's trusted store? I admit to >> being a layman on this matter, so what exactly is the legitimate case for >> Google acquiring GlobalSign roots? > > > I will defer to Google's post announcing the acquisition: > https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html >> >> > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
On Mon, Sep 17, 2018 at 3:19 PM jtness--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > The risk of any given browser vendor also being a Root CA is small as most > browser vendors do not have the requisite market share to make unilateral > decisions. Google possesses over 60% of the browser market and 80% of the > mobile operating system market. What avenues does Mozilla have to > realistically push back if Google abuses their effective authority over the > Internet via browser share in the CA space? Presumably "Firefox becomes the > browser that can't establish a connection to google.com or gmail.com" is > outside of the realm of realistic scenarios. Neither Apple nor Microsoft > has the market share to summarily decide a CA is no longer in business, > Google can. > > I don't agree with this logic. Most websites care a lot about losing even 1% of users to untrusted certificates. Also, a logical conclusion from this argument is that Mozilla can't decide to deny this inclusion request, especially given that Microsoft has already accepted these roots, because if we do then Google will just go ahead and use them anyhow. I don't agree with that conclusion either. It would seem to me that Google is already the judge, jury, and executioner > of the public key infrastructure, and they're about to have a strong > financial interest in each CA that is found guilty. Presumably if Google > were to summarily execute another large CA in the future, after launching > their own certificate offering, they would see a large uptick in business. > > With regards to your linked discussion about the GlobalSign root > acquisition, I see nothing but more reasons to be concerned. Is there any > reason for Google to have acquired the roots from GlobalSign except to > backdoor their way into already being in Mozilla's trusted store? I admit > to being a layman on this matter, so what exactly is the legitimate case > for Google acquiring GlobalSign roots? > I will defer to Google's post announcing the acquisition: https://security.googleblog.com/2017/01/the-foundation-of-more-secure-web.html > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
On Monday, September 17, 2018 at 1:18:47 PM UTC-5, Wayne Thayer wrote: > On Mon, Sep 17, 2018 at 9:43 AM Wayne Thayer wrote: > > > Even though the discussion period has ended, Mozilla will continue to > > consider factual information that is submitted as comments here: > > https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 > > > > Your concern about "without comment and then get approved" may stem from a > > misunderstanding of Mozilla's process, as documented here: > > https://wiki.mozilla.org/CA/Application_Verification A lack of comments > > indicates that the community is satisfied with the review that was > > performed on the inclusion request. > > > > Finally it seems that your concerns with this request have to do with > > browser vendors also operating CAs? If so, I think that is a topic that is > > much broader than this inclusion request. Google already operates as a CA > > via cross-signing, as do Microsoft and Apple. > > > > Correction: Google is already a root CA in Mozilla's program because they > acquired two roots from GlobalSign, as discussed here: > https://groups.google.com/d/msg/mozilla.dev.security.policy/1PDQv0GUW_s/oxDWH07VDgAJ > > On Mon, Sep 17, 2018 at 8:29 AM jtness--- via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> I am disappointed I didn't see this before the three week comment period, > >> because this is an incredible disaster. Mozilla is seriously considering > >> permitting a company with a completely unilateral ability to shut other > >> Root CAs down (via their market share over Chrome and Android, and that the > >> CAB has no legal authority to countermand their decisions on what CAs they > >> trust), to then also be a competitor to these companies which it can > >> unilaterally remove from the market? This is the sort of world-ending crud > >> that shouldn't pass through a random Google Group without comment and then > >> get approved. > >> > >> The risk of any given browser vendor also being a Root CA is small as most browser vendors do not have the requisite market share to make unilateral decisions. Google possesses over 60% of the browser market and 80% of the mobile operating system market. What avenues does Mozilla have to realistically push back if Google abuses their effective authority over the Internet via browser share in the CA space? Presumably "Firefox becomes the browser that can't establish a connection to google.com or gmail.com" is outside of the realm of realistic scenarios. Neither Apple nor Microsoft has the market share to summarily decide a CA is no longer in business, Google can. It would seem to me that Google is already the judge, jury, and executioner of the public key infrastructure, and they're about to have a strong financial interest in each CA that is found guilty. Presumably if Google were to summarily execute another large CA in the future, after launching their own certificate offering, they would see a large uptick in business. With regards to your linked discussion about the GlobalSign root acquisition, I see nothing but more reasons to be concerned. Is there any reason for Google to have acquired the roots from GlobalSign except to backdoor their way into already being in Mozilla's trusted store? I admit to being a layman on this matter, so what exactly is the legitimate case for Google acquiring GlobalSign roots? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
On Mon, Sep 17, 2018 at 9:43 AM Wayne Thayer wrote: > Even though the discussion period has ended, Mozilla will continue to > consider factual information that is submitted as comments here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 > > Your concern about "without comment and then get approved" may stem from a > misunderstanding of Mozilla's process, as documented here: > https://wiki.mozilla.org/CA/Application_Verification A lack of comments > indicates that the community is satisfied with the review that was > performed on the inclusion request. > > Finally it seems that your concerns with this request have to do with > browser vendors also operating CAs? If so, I think that is a topic that is > much broader than this inclusion request. Google already operates as a CA > via cross-signing, as do Microsoft and Apple. > > Correction: Google is already a root CA in Mozilla's program because they acquired two roots from GlobalSign, as discussed here: https://groups.google.com/d/msg/mozilla.dev.security.policy/1PDQv0GUW_s/oxDWH07VDgAJ On Mon, Sep 17, 2018 at 8:29 AM jtness--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> I am disappointed I didn't see this before the three week comment period, >> because this is an incredible disaster. Mozilla is seriously considering >> permitting a company with a completely unilateral ability to shut other >> Root CAs down (via their market share over Chrome and Android, and that the >> CAB has no legal authority to countermand their decisions on what CAs they >> trust), to then also be a competitor to these companies which it can >> unilaterally remove from the market? This is the sort of world-ending crud >> that shouldn't pass through a random Google Group without comment and then >> get approved. >> >> ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
Even though the discussion period has ended, Mozilla will continue to consider factual information that is submitted as comments here: https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 Your concern about "without comment and then get approved" may stem from a misunderstanding of Mozilla's process, as documented here: https://wiki.mozilla.org/CA/Application_Verification A lack of comments indicates that the community is satisfied with the review that was performed on the inclusion request. Finally it seems that your concerns with this request have to do with browser vendors also operating CAs? If so, I think that is a topic that is much broader than this inclusion request. Google already operates as a CA via cross-signing, as do Microsoft and Apple. On Mon, Sep 17, 2018 at 8:29 AM jtness--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I am disappointed I didn't see this before the three week comment period, > because this is an incredible disaster. Mozilla is seriously considering > permitting a company with a completely unilateral ability to shut other > Root CAs down (via their market share over Chrome and Android, and that the > CAB has no legal authority to countermand their decisions on what CAs they > trust), to then also be a competitor to these companies which it can > unilaterally remove from the market? This is the sort of world-ending crud > that shouldn't pass through a random Google Group without comment and then > get approved. > ___ > 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 Root Inclusion Request
I am disappointed I didn't see this before the three week comment period, because this is an incredible disaster. Mozilla is seriously considering permitting a company with a completely unilateral ability to shut other Root CAs down (via their market share over Chrome and Android, and that the CAB has no legal authority to countermand their decisions on what CAs they trust), to then also be a competitor to these companies which it can unilaterally remove from the market? This is the sort of world-ending crud that shouldn't pass through a random Google Group without comment and then get approved. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Google Trust Services Root Inclusion Request
The three week discussion period for this inclusion request has passed with no comments received. I am now closing this discussion with a recommendation to approve this request. Any further comments should be added directly to the bug. - Wayne On Thu, Aug 23, 2018 at 3:58 PM Wayne Thayer wrote: > This request is for inclusion of the Google Trust Services R1, R2, R3, and > R4 roots as documented in the following bug: > https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 > > Google’s application states: > Google is a commercial CA that will provide certificates to customers from > around the world. We will offer certificates for server authentication, > client authentication, email (both signing and encrypting), and code > signing. Customers of the Google PKI are the general public. We will not > require that customers have a domain registration with Google, use domain > suffixes where Google is the registrant, or have other services from Google. > > * BR Self-Assessment: > https://bug1325532.bmoattachments.org/attachment.cgi?id=8943360 > > * Summary of Information Gathered and Verified: > https://bug1325532.bmoattachments.org/attachment.cgi?id=8965095 > > * Root Certificate Download URL: > ** R1: https://pki.goog/gtsr1.crt > ** R2: https://pki.goog/gtsr2.crt > ** R3: https://pki.goog/gtsr3.crt > ** R4: https://pki.goog/gtsr4.crt > > * CP/CPS: > ** CP: https://pki.goog/GTS-CP-1.5.pdf > ** CPS: https://pki.goog/GTS-CPS-2.3.pdf > > * This request is to turn on the Websites trust bit (reference comment #29 > in the bug). EV treatment has not been requested. > ** EV Policy OID: N/A > > * Test Websites: > ** R1: https://good.r1demo.pki.goog https://revoked.r1demo.pki.goog > https://expired.r1demo.pki.goog > ** R2: https://good.r2demo.pki.goog https://revoked.r2demo.pki.goog > https://expired.r2demo.pki.goog > ** R3: https://good.r3demo.pki.goog https://revoked.r3demo.pki.goog > https://expired.r3demo.pki.goog > ** R4: > > * CRL URLs: > ** R1: http://crl.pki.goog/gtsr1/gtsr1.crl > ** R2: https://crl.pki.goog/gtsr2/gtsr2.crl > ** R3: https://crl.pki.goog/gtsR3/gtsr3.crl > ** R4: https://crl.pki.goog/gtsR4/gtsr4.crl > > * OCSP URLs: > ** R1: http://ocsp.pki.goog/gstr1 > ** R2: https://ocsp.pki.goog/gstr2 > ** R3: https://ocsp.pki.goog/gstr3 > ** R4: https://ocsp.pki.goog/gstr4 > > * Audit: Annual audits are performed by Ernst & Young according to the > WebTrust for CA and BR audit criteria. > ** WebTrust: https://cert.webtrust.org/SealFile?seal=2346=pdf > ** BR: https://cert.webtrust.org/SealFile?seal=2347=pdf > > I’ve reviewed the CP and CPS, BR Self Assessment, and related information > for the Google Trust Services inclusion request that is being tracked in > this bug and have the following comments: > > ==Good== > * Google has supplied a key generation ceremony audit report [1] > * Other than the disclosed intermediates and required test certificates, > no issuance has been detected from these roots. > * Section 1.4.2 of the CPS expressly forbids the use of Google > certificates for “man-in-the middle purposes” > * Appendix C of the current CPS indicates that Google limits the lifetime > of server certificates to 365 days. > > ==Meh== > * These 4 roots were created by GlobalSign and then transferred to Google. > A lengthy discussion regarding the transfer [2] occurred, primarily focused > on existing GlobalSign roots that were purchased rather than these new > roots. However, I believe the following concerns are relevant: > ** From the transfer on 11-August 2016 through 8-December 2016, at the > time it would not have been clear what, if any, policies applied to these > new roots. The applicable CPS during that period [3] makes no reference to > these roots. Google does state in their current CPS that these roots were > operated according to that CPS. > ** From the transfer on 11-August 2016 through the end of Google’s audit > period on 30-September, 2016, these roots were not explicitly covered by > either Google’s audit nor GlobalSign’s audit. However, since Google had > valid WebTrust audits during that period, I believe this is no different > than a CA creating a new root. A counter-argument is that Google prior to > the transfer was not operating publicly-trusted roots and thus should have > undergone a point-in-time audit as if they were a new CA. > > The discussion was concluded with the following statement: > >> > >> 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. >> > > * Earlier this year, Google’s OCSP service was down for over 2 days [4]. > During that time, concerns with Google’s incident
