[tptacek]

Of course, the point is that by bylaws the CAs themselves agreed to, in their own BRs, they're required to revoke the certificates within 7 days. It's a SHALL requirement.

The CAs can't have it both ways: a BR balloting process that they rely on for moral authority when disputing that the majority of deployed browsers have added new security requirements (like shorter-lived certificates), and BRs that they ignore when they screw up.

[peterwwillis]

Can't they have it however they want as long as the vendors that matter go along with it? I feel like Ryan is sort of pointing that out, that an excuse of "oh well we needed to support vendor X" gives them carte blanche. It's not like customers are going to knock down their doors for not following BRs. At the end of the day, the biggest vendors are where their bread gets buttered.

If Mozilla isn't the majority browser vendor, who cares what they insist on? And if all the CAs band together and say, sorry losers, we're gonna keep doing things our way, what are the browsers gonna do? Cut all their users off from the internet "because principles"? Apple is playing a dangerous game that I don't think will work out in different circumstances. They can't hide behind "protecting users" if their users end up unable to access the internet securely.

We got into this mess because we wanted organizational independence and distributed trust, without considering what internal conflicts would mean to the end users. I'm going to call it and say that within a decade, you'll have to pick which CA you want to trust at browser install time (though you can guess which CA will be the default on which devices).

[tptacek]

This is a weird comment. Leave aside that anything the Mozilla root program does will, if history is a guide, likely be backed immediately by Google. Minority browser or not, if your CA isn't trusted by Mozilla, you will lose all your customers. Nobody is going to do business with the CA that offers "the majority of browser users" when the rest of the CAs offer all the browser users. The CAs have almost no cards to play here.

[tialaramex]

> And if all the CAs band together and say, sorry losers, we're gonna keep doing things our way, what are the browsers gonna do?

For one thing you should consider that several of the companies that make browsers also operate a Certificate Authority. For example Google's GTS is represented in that m.d.s.policy thread by Ryan Hurst (whereas Ryan Sleevi is there mostly choosing not to put on his Chromium Web PKI hat). Microsoft likewise controls trusted roots. Apple does operate its own PKI but is not presently broadly trusted, though if it felt the need I'm sure they have people.

Also the most popular (for this purpose) Certificate Authority is ISRG's Let's Encrypt and they've got no reason not to co-operate. The Web PKI is all they do anyway.

This is often portrayed as though browsers are obliged to either distrust everything instantly or allow CAs to do whatever they like, but neither of those is realistic. The major trust stores all already have imposed constraints short of distrust.

You bring up Apple as an example. Unless I've missed it somewhere Apple never announced their 398 day limit as a matter of issuance policy it's simply a fact that Safari and the Mac operating system won't trust new certificates with longer lifespans after a set date. So if one or more CAs decided not to co-operate, nothing happens at first. Nothing whatsoever.

Then, gradually, a few subscribers buy (or renew) 2 year certificates, and these new certificates don't work in Safari. Some of these subscribers will call customer services at the CA where they purchased the certificate. Why doesn't it work in Safari? How can they fix this?

What does the CA say? "We intentionally sold you a product that won't work. Ha ha ha, it's a funny joke, we have your money and you've got useless garbage" ? Maybe they instead try to blame Apple. Apple will point out that the CA knew this wouldn't work and suggest the subscriber seek a refund.

The subscriber demands a refund. The CA is now losing money and it is seeing negative reputational impact. Somebody threatens to sue. It is not a good day to be the CA.

At the subscriber's offices, an IT person has a brainwave and switches to a provider that isn't deliberately disobeying. The web site is back working. Champagne all round.

To achieve the desired robustness/ reliability the Web PKI is structured in a way that makes any individual Certificate Authority expendable. As a subscriber this means you should plan for your CA going away with at most a few days notice. Most people won't do that. Too bad, individually you're expendable too.

[nickf]

Apple did actually make the limit a matter of their policy. Start date is September 1, technical enforcement comes 'later', but the requirement is going to be part of their policy. https://lists.cabforum.org/pipermail/public/2020-April/01494... Plus, it's not just Safari - it's the TLS stack in macOS/iOS etc. - Apple's KB article mentions nothing of Safari, but just like their enforcement of CT, it's basically OS-wide.

[peterwwillis]

I don't think this is how it would (could?) play out. The CA would say, "Your Apple software is buggy, because nothing else has this weird limit. You can buy a 1 year cert from us to fix your issue. But because you already bought a 2 year cert, and Apple is being a jerk to you, here's an additional 1 year cert. Tell Apple they suck for making you jump through this hoop." And Apple would drone on about security or privacy or whatever being worth the customer now having to do more work. If nobody else played ball, it really would be just Apple annoying everybody. For reasons I can't yet fathom, the rest of the CAs and browsers seemed to chicken out instead of calling their bluff.