Just to clear up one point -- Let's Encrypt did not at all force ACME on the industry. We deliberately took it to the IETF so that we could get input from more parts of the industry (including some major refactors!). Instead of pressure from Let's Encrypt, I would attribute its success to the open process of the IETF, the awesome open-source community that made great ACME software (shoutout to Matt and Caddy!), and the resulting pressure on CAs for a better user experience from users and customers.
Hi there, ISRG co-founder and current board member here. In brief, shorter lifetimes force people to automate (which, e.g., avoids outages from manual processes) and mitigates the broken state of revocation in the Web PKI. That latter point especially is what I understand to be driving the Web PKI toward ever-shorter lifetimes.
I actually remember the discussion we had in ~2014 about what the default certificate lifetime should be. My opening bid was two weeks -- roughly the lifetime of an OCSP response. The choice to issue certificates with 90 day lifetimes was still quite aggressive in 2015, but it was a compromise with an even more aggressive position.
The idea here is to be lighter-weight than profiles, or the similar feature in Chrome. I've got three different containers going right now, side-by-side in one browser window. In addition to the per-tab basis, providing separation within a profile also means you don't have to set your preferences, addons, etc. independently each time.
For example, one of the major use cases for this sort of separation is being able to use multiple accounts on a site like Twitter or Facebook (which don't support multi-account) or Gmail (which does, but it's a bit rough). There's no reason I should have to have separate windows or separate addons for each of those accounts.
It's a mix. Some patches are just getting rebased and landed. For others, the Firefox and Tor Browser teams are working together to re-implement the feature in a way that makes more sense in the broader Firefox architecture.
For example, for First Party Isolation, we took the "origin attributes" feature that we built to support containers (user-specified tracking limitations) and reused it for isolation. In the containers case, origins get tagged with a user-specified label; with First Party Isolation, they get tagged with the top-level origin.
And to be clear, there's no "neutering" going on here. We're adding the full features that Tor Browser has, since the whole point of this exercise is to let Tor Browser user preference changes instead of patches. That means that the full capability of the Tor Browser features are in Firefox if users want to enable them.
When a server uses a Let's Encrypt certificate, a browser will consider it as issued under an IdenTrust root CA, which the browser trusts. So it will consider the Let's Encrypt certificate trusted.
Unfortunately, ECDSA support is not as universal as RSA.
But I understand that the plan is to start working on ECDSA support pretty much as soon as the first root is stood up, so it shouldn't be long after the start.
You've got things a little confused here. Let's Encrypt doesn't need to be part of the CABF in order to be included in the browsers, but they do need to demonstrate that they abide by the rules that CABF defines (the Baseline Requirements). They only need to join CABF if they want to be able to vote on those rules.
The CA/Browser Forum Baseline Requirements require that the CA have you sign one:
"Prior to the issuance of a Certificate, the CA SHALL obtain ... either: 1. The Applicant’s agreement to the Subscriber Agreement with the CA, or 2. The Applicant’s agreement to the Terms of Use agreement."
Hey, this is Richard, the author of the post. All the feedback here is great, but if you've got thoughts on whether we should pursue this strategy or not, please comment on the mozilla.dev.platform list.
That's correct. Also, if you've got an A/AAAA record for the domain name in question, you could run an ACME client on that box that spins up a temporary web server. That's what the node-acme demo client does.
Yes, we plan to apply a few mitigations of this type. Part of the idea of the "Proof of Possession of a Prior Key" challenge is so that if a web server requests a cert for a domain with an existing certificate, we can ask them to prove that they hold that certificate.