The reality is the CAs could tell Mozilla to go pound sand and they would have no recourse. Is there not a governing body for certificate policies with voting members?
CA trust should be handled at the OS vendor level. Mozilla having its own trust anchors is a relic of the past. If CAs refuse to comply, they at worst inconvenience 2.5% of their customers temporarily until they find a better browser.
Who's the "vendor" for Linux? IBM?
The outcome of this idea is Google & Microsoft can MITM all internet traffic.
Google, MS, and Apple already handle their own CA trust. So this conspiracy theory would already be true.
There are countless companies and groups (but only a handful that serve the vast majority of users) releasing a version of Linux bundled with a GNU userland and other open source niceties, all designed to work together as a system. These are colloquially called "Linux distributions".
As for Microsoft, they are simply asleep at the wheel, trusting terrible CAs that do things like misissue a google.com certificate <https://bugzilla.mozilla.org/show_bug.cgi?id=1934361>.
(Also, the revocations would not be without warning - mechanisms like ARI can inform server operators prior to revocation so the certificate can be automatically replaced.)
Unless you run an enterprise CA, in which case Chrome doesn't check for revocation AT ALL. Google went rogue and made up their own rules. The whole of PKI should be ripped up and not left up to those who can shout loudest.
What does this protect you from? If a private key is stolen from a device? If it went unnoticed for 45 days, the device is probably still compromised, and the threat actor will just steal the new key. If you can automate issuing certificates, you can automate stealing them too.
Sounds like a great way to garner more business for Big PKI.
You are not wrong about the malware part though. Said undetected malware would continue to be undetected and continue to expose the private bits no matter how (in)frequently you rotate.
???
why would you need to issue new certificates for "enforcing modern tls + ciphers and various other changes"? There's nothing preventing you from using a newly minted letsencrypt certificate with sslv3, for instance.
Obviously, one can actively choose to go out of their way and do something bone-headed - nothing can stop that.
But on the flip side those 30 unlucky souls are gonna be pissed. There's so many other less disruptive ways you could do this.
If this is permitted, then I see no problem with this plan. It will force people to do what they already should be doing: have a plan in place to rotate certificates in case of revocation.
> The point is that right now revocation is so painful that it’s causing CAs to side with subscriber convenience over the integrity of the web PKI. Sampled, controlled revocations let us identify points of pain before they have security implications, and motivate Subscribers to prepare their systems—whether through automation or not, up to them, I’m not their dad—to tolerate on-time revocation. We care about the likely outcomes of automation, such as tolerance of short revocation or expiry timelines, really, but if BigSlowCo wants to staff a 24-hour cert maintenance squad such that they don’t (successfully) pressure their CA into blowing revocation deadlines, that’s their opex choice. Directly evaluating ecosystem capability around prompt revocation is the only way I can think of to identify areas of danger or weakness before they become issues for the web.
This is like testing the fire extinguishers.
As opposed to 30-random entities.
Technically ACME supports challenges that work without "direct connection to the internet", eg. DNS.