[est31]

> CAs that have been installed by the device owner or administrator into the operating system trust store are expected to continue to work as they do today.

Huh that's a really cool idea. I wonder how it's implemented, as it might be useful for the rustls-native-certs crate as well...

Edit: found it: Apparently there is a bool field is_issued_by_known_root that gets set by the differerent backends. https://chromium.googlesource.com/chromium/src/net/+/2f96522...

[sleevi]

No, that’s not it: none of the code has landed yet It’s a big enough change that we’re explaining before landing.

We’re taking an approach similar to Firefox’s implementation ( https://searchfox.org/mozilla-central/source/security/manage... ), which I helped advise on in the long ago days. It may end up using like that bool, but if you read through the commit history for how that code in Chrome works, you can see there are a lot of sharp edges.

[jiggawatts]

Firefox does Enterprise PKI wrong though. Very thoroughly wrong.

It only reads in the Root CA certificates in the Machine store.

It ignores the User store entirely.

It ignores the Intermediate CA store as well.

I bet Mozilla's logic is that Intermediate CA certificates can simply be "downloaded" dynamically, but Windows Server CAs use LDAP URLs by default, which Firefox doesn't support.

It also ignores CTLs, CRLs, revoked certificates, and a bunch of other Windows PKI stores.

Chrome was pleasant to use in that "it just worked", and this was a major reason it was adopted by large organisations and Firefox wasn't.

Please don't break this.

[sleevi]

Some of this isn’t correct (e.g. Firefox totally reads HKCU - https://searchfox.org/mozilla-central/source/security/manage... - which is necessary to work with AV ), but I’ll the the first to tell you that a number of these things aren’t planned to be supported, because the goal is not to reimplement CAPI and it’s 200+ undocumented (except by support contract) flags and features. LDAP CDPs are definitely a no-go, for example. CTLs, as another, are almost exclusively for server apps like IIS, and don’t correctly work in Chrome today, so no regression there. Definitely, making sure to enable metrics, and report issues, is a good way to help prioritize things that are important vs things that are possible, but profoundly ill-considered.

[jiggawatts]

It was 100% correct up until September 2019: https://bugzilla.mozilla.org/show_bug.cgi?id=1571548

Firefox still ignores the local Intermediate CA store, the revoked store, etc...

> because the goal is not to reimplement CAPI and it’s 200+ undocumented (except by support contract) flags and features.

The reality is that there are orgs out there with Enterprise CA Roots that have issued many intermediate CAs and tens of thousands leaf certificates.

Because of the arrogant behaviour of Mozilla and Google, it is now incredibly dangerous to run an Enterprise CA because it is no longer feasible to revoke an Intermediate CA!

Neither Firefox, nor Chrome check Intermediate CA CRLs or OCSP by default. Chrome up until recently would honour revocations via Group Policy, but Firefox would not.

Google uses CRLSets in Chrome for CA revocation, but good luck getting them to accept your Intermediate CA key that was compromised!

Now Google is going down the same selfish path: Because Google doesn't need Enteprise PKI -- because none of their products are used extensively for private networking -- they're more than happy to break hundreds of millions of deployed Windows private networks. Who cares, right? That's the competition!

"Do not be evil" was removed, remember?

[sleevi]

https://cloud.google.com/docs/chrome-enterprise/policies?pol...

There’s more that could be said, but I can see this is an emotionally loaded subject for you, so perhaps it’s best dealt with as it rolls out. Every feature has a cost: to complexity (CTLs are notoriously ‘weird’ on Windows, for example), to security (LDAP is a terrible protocol due to BER), or simply in the maintenance costs that prevent security improvements. Software engineering is about weighing those trade-offs: do you implement the feature that 10-100 users use, or do you spend time improving things for the other billion users? There are limits to what can be supported, and limits to what is even good to support in the first place, and while such pragmatism may seem like arrogance, the reality is less malicious: it just isn’t good software.

In any event, making sure usage statistics are enabled, and bugs are filed when actually, is a good way to help prioritize.

[jiggawatts]

> do you implement the feature that 10-100 users use

Try 10-500 million, perhaps a billion. Most medium-to-large corporations have an Enterprise PKI issuing internal-use certificates.

> do you spend time improving things for the other billion users?

Here's the thing: Google's users and Microsoft's users are much the same people, in roughly the same total numbers.

But Google would much rather have those people be only Google's users, and not Microsoft's users any longer.

Why implement a feature that helps "the competition"?

Why implement a client feature that your company's server products don't need or use?

Why bother with the private enterprise when your company only sells stuff via the public cloud?

Why bother with security at all if the attacks don't affect you directly?

These are very important question to think about, because the answers say something critical about the future of not just "The Web", but computing in general.

Google has decided they won't bother any longer. They now control a sufficient fraction of the HTML client market to force changes onto the market unilaterally, even if it that actively harms the security of their competitors.

As long as Google's needs are met, the job is done.

Microsoft customers' needs are no longer relevant...