Google Trust Services Root Inclusion Request

[Wayne Thayer]

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&file=pdf
** BR: https://cert.webtrust.org/SealFile?seal=2347&file=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 reporting mechanism were
raised, but it is not clear that there was ever a policy violation. Google
supplied a fairly detailed incident report.
* The CP is so heavily derived from the BRs that it provides almost no
useful information. It includes repeated references to things that “the CA”
should or must do without clearly identifying Google as “the CA”.

==Bad==
NOTE: the issues listed below were addressed by Google after I reported
them, but I am reporting them in the “bad” state in which I originally
found them.
* Version 2.2 of the CPS stated that domain validation method 1 was
performed for OV certificates. It did not state how domain validation is
performed for DV certificates. In addition to the fact that method #1 is
banned after 1-August, I do not believe this meets Mozilla policy section
2.2: “The CA's CP/CPS must clearly specify the procedure(s) that the CA
employs…”. Google has fixed this issue in CPS version 2.3, although it only
references BR section numbers to “clearly specify the procedures”.
* Section 6.1.1 of version 2.2 of the CPS can be interpreted to state that
the Google CA generates key pairs for its subscribers in violation of
Mozilla policy section 5.2. CPS version 2.3 has corrected this issue.
* The certificate profiles in CPS version 2.2 Appendix A indicated that TLS
certificates can be valid for up to 39 months. Google updated this to a max
validity period of 365 days in version 2.3.

This begins the 3-week comment period for this request [5].

I will greatly appreciate your thoughtful and constructive feedback on the
acceptance of these roots into the Mozilla CA program.

- Wayne

[1] https://bug1325532.bmoattachments.org/attachment.cgi?id=8844282
[2]
https://groups.google.com/d/msg/mozilla.dev.security.policy/1PDQv0GUW_s/oxDWH07VDgAJ
[3]
https://static.googleusercontent.com/media/pki.google.com/en//GIAG2-CPS-1.4.pdf
[4]
https://groups.google.com/d/msg/mozilla.dev.security.policy/MMO3HSYghwQ/XLRuxWtJAwAJ
[5] https://wiki.mozilla.org/CA/Application_Process

[Wayne Thayer]

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

[jtn...@gmail.com]

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.

[Wayne Thayer]

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.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Wayne Thayer]

On Mon, Sep 17, 2018 at 9:43 AM Wayne Thayer <wth...@mozilla.com> 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

[jtn...@gmail.com]

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?

[Wayne Thayer]

On Mon, Sep 17, 2018 at 3:19 PM jtness--- via dev-security-policy <
dev-secur...@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

>
>

[Jake Weisz]

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 <wth...@mozilla.com> wrote:

[Matthew Hardeman]

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.

[Nick Lamb]

On Mon, 17 Sep 2018 18:41:07 -0500
Jake Weisz via dev-security-policy

<dev-secur...@lists.mozilla.org> 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.

[Jeremy Rowley]

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.

ASSUMPTION: Google and Mozilla are the two browsers policing CA policy and
operations. This is fairly true as they are the two engaged publicly in
posting about issues and deciding publicly what to trust and distrust.
ASSUMPTION: Google will never distrust itself and likely won't be overly
harsh on itself if Google misses a few BRs here or there. This is probably
also true. Not many companies spend on creating infrastructure just to get
it kicked out. Note that I personally haven't found Google unreasonable
when there's a compliance issue as long as the disclosure is timely and
complete. As long as they keep up that same standard for requiring prompt
disclosure and remediation, this assumption is flawed.
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.
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.

Anyway, my two cents are that Jake's fear is reasonable and shouldn't be
minimized just because you have to trust some browser, especially where it
means trusting a browser that is separate from the one being discussed on
this forum (Mozilla).
Jeremy

-----Original Message-----
From: dev-security-policy <dev-security-...@lists.mozilla.org> On
Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, September 20, 2018 2:44 AM
To: dev-secur...@lists.mozilla.org
Cc: Jake Weisz <jtn...@gmail.com>
Subject: Re: Google Trust Services Root Inclusion Request

On Mon, 17 Sep 2018 18:41:07 -0500

Jake Weisz via dev-security-policy

_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org

https://clicktime.symantec.com/a/1/7AOYHq00os6KKJ9wHSw7rrgbQyaeEt31vMTT9xYjD
no=?d=nO2upofMId4kAC6tWzorxLnC7d1bJz9gI5CvzMLuKwBzi5GZ7jQbSPsFfxuuA2NUtLVbj8
-wOhF70XEiVFxMdvb5MBANlD6VRHCpyXyPPZgBt15IeNiOHRP54RnX8RsoR6_3b4HibMFfJ_2snB
E1XTQif9_Xfx2TMgffR1EKoPeflpWk9oSW1Agndr694ck1lh2gdljowf8ZHPWfAMhyUjFKeGQBDY
xcTrGd5a5yI1LnpAfn90ojGHbHtN4ARlD9bjXPKDRbyiNSbnzeANCyDSqtD3vOdG5zfXLv4NHrxC
EomXMN99EYvgCIsxlNBiuuOFlrBybSMIKLLo3hEnvE646Olx8mURipQr5wWJNFnJe8n9sxsnQt6K
mMwYLdLMEKEsCuqleL892KcpCKowCUfTHq_N7kyb_JmPFk-g%3D%3D&u=https%3A%2F%2Flists
.mozilla.org%2Flistinfo%2Fdev-security-policy

[Ryan Sleevi]

(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-secur...@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.

[Fotis Loukos]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>


--
Fotis Loukos, PhD
Director of Security Architecture
SSL Corp
e: fot...@ssl.com
w: https://www.ssl.com

[Richard Wang]

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-s...@lists.mozilla.org
Subject: Re: Google Trust Services Root Inclusion Request

[Jeremy Rowley]

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 <ry...@sleevi.com>
Sent: Wednesday, September 26, 2018 12:43 AM
To: Jeremy Rowley <jeremy...@digicert.com>
Cc: mozilla-dev-s...@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)

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.

[Ryan Sleevi]

Hi Richard,

A few corrections:

On Wed, Sep 26, 2018 at 11:36 AM Richard Wang via dev-security-policy <
dev-secur...@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

[Ryan Sleevi]

On Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley <jeremy...@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 being discarded so readily
is, again, misleading and inaccurate.

[Wayne Thayer]

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.

[Nick Lamb]

On Wed, 26 Sep 2018 16:03:58 +0000
Jeremy Rowley via dev-security-policy

<dev-secur...@lists.mozilla.org> 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.

[Richard Wang]

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 <sle...@google.com>
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

Hi Richard,

A few corrections:

[Richard Wang]

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

[Rob Stradling]

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

--
Rob Stradling
Senior Research & Development Scientist
Email: R...@ComodoCA.com
Bradford, UK
Office: +441274730505
ComodoCA.com

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.

[James Burton]

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

[Nick Lamb]

On Wed, 26 Sep 2018 23:02:45 +0100
Nick Lamb via dev-security-policy

<dev-secur...@lists.mozilla.org> 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.

[Richard Wang]

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 <j...@0.me.uk<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 Wed, Sep 26, 2018 at 12:04 PM Jeremy Rowley <jeremy...@digicert.com<mailto:jeremy...@digicert.com>>

> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>

> https://lists.mozilla.org/listinfo/dev-security-policy
>
>
> _______________________________________________
> dev-security-policy mailing list

> dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>

> https://lists.mozilla.org/listinfo/dev-security-policy
>

--
Rob Stradling
Senior Research & Development Scientist

Email: R...@ComodoCA.com<mailto:R...@ComodoCA.com>
Bradford, UK
Office: +441274730505
ComodoCA.com<http://ComodoCA.com>

This message and any files associated with it may contain legally
privileged, confidential, or proprietary information. If you are not the
intended recipient, you are not permitted to use, copy, or forward it,
in whole or in part without the express consent of the sender. Please
notify the sender by reply email, disregard the foregoing messages, and
delete it immediately.
_______________________________________________
dev-security-policy mailing list

dev-secur...@lists.mozilla.org<mailto:dev-secur...@lists.mozilla.org>
https://lists.mozilla.org/listinfo/dev-security-policy

[Peter Bowen]

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

[Jeremy Rowley]

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 <wth...@mozilla.com>
Sent: Wednesday, September 26, 2018 3:39 PM
To: Ryan Sleevi <ry...@sleevi.com>
Cc: Jeremy Rowley <jeremy...@digicert.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
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.

[Jeremy Rowley]

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 <ry...@sleevi.com>
Sent: Wednesday, September 26, 2018 10:49 AM
To: Jeremy Rowley <jeremy...@digicert.com>

Cc: Ryan Sleevi <ry...@sleevi.com>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>
Subject: Re: Google Trust Services Root Inclusion Request

[Ryan Sleevi]

On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley <jeremy...@digicert.com>
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?

[Wayne Thayer]

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 <ry...@sleevi.com> wrote:

>
> On Thu, Sep 27, 2018 at 11:17 AM Jeremy Rowley <jeremy...@digicert.com>
> 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

> Just want to point out that Kathleen is currently still the CA Certificate
Policy Module Owner.