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-policy-boun...@lists.mozilla.org> On
Behalf Of Nick Lamb via dev-security-policy
Sent: Thursday, September 20, 2018 2:44 AM
To: dev-security-policy@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@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.

_______________________________________________
dev-security-policy mailing list
dev-security-policy@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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

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

Reply via email to