bifurcation

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.

Heh, as I was saying about shorter lifetimes encouraging automation...

https://news.ycombinator.com/item?id=46210786

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.

Actually, it's in Beta now, and will be shipping to Firefox release channel users on Monday or Tuesday.

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.

Fingerprinting (in general) is the next thing on the agenda after First Party Isolation. Addressing canvas fingerprinting is in the plan:

https://wiki.mozilla.org/Security/Fingerprinting

https://bugzilla.mozilla.org/show_bug.cgi?id=1041818

In a word, yes.

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.

Other things I use all the time:

`openssl x509 -in $FILE -text | less`

https://lapo.it/asn1js

https://golang.org/pkg/crypto/x509/

https://github.com/agl/certificatetransparency

Yep, that should work fine. You'll just need to do the validation process for each domain.

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."

https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.p...

openssl req -new -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem

openssl s_server -accept 8000 -key key.pem -cert cert.pem -HTTP

The use of HTTPS doesn't destroy cacheability, it just requires that one of the legitimate endpoints authorize the cache to be there.

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.

https://lists.mozilla.org/listinfo/dev-platform

https://groups.google.com/forum/#!forum/mozilla.dev.platform

The Mozilla root program currently has a similar plan proposed, with a final decision pending in the next day or so.

https://groups.google.com/forum/#!topic/mozilla.dev.security...

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.

https://github.com/letsencrypt/node-acme/blob/master/lib/acm...

I don't know what the story is with that site

Turns out they had the wrong certificate chain provisioned. Seems to be fixed now.

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.

https://github.com/letsencrypt/acme-spec/blob/master/draft-b...

See also:

https://sendto.mozilla.org/

We're working on an FAQ. This thread has been really helpful in clarifying which Qs are FA :)

With regard to your questions:

Will it provide wildcard certs?

Not initially, but possibly in a future iteration.

Note that having an automatic CA addresses some of the use cases for wildcard certs. Namely, if you're using a wildcard cert just to avoid having to manage individual certs for foo-1.example.com through foo-N.example.com, you can just have them each automatically get a specific cert.

How does it auto-renew, does it have to run all the time?

That will depend on the software running on the web server. The current "node-acme" and "lets-encrypt-preview" implementations in the Github repo are examples. Ultimately, in addition to these tools, it would be great to have ACME / LE support built into web server platforms, which are already running all the time.

Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/

I don't know what the story is with that site, but I believe the Let's Encrypt CA will be cross-signed under the same IdenTrust CA that issued the cert for https://letsencrypt.org/. So Let's Encrypt certificates should work wherever that site works (which includes Chrome and Safari, at least on my MacBook).

Can every CA support issuing certs this way please? :)

I can't speak for other CAs, but we are definitely open to other CAs re-using technologies from Let's Encrypt to automate their operations. It would be even better for them to collaborate in developing the protocol. That's why we wrote ACME up using the IETF's document format, so that it can be developed in the IETF's open process with many stakeholders involved.

Getting to short-lived certificates is a goal, but the reality for now is that OCSP and CRLs are what implementations require, and what the CABF Baseline Requirements require. So we'll need to start with those.

The ultimate vision is to make it even easier than that -- you set the "turn on HTTPS" option, and the platform auto-configures HTTPS with a certificate and appropriate ciphers. That will require upgrades to apache, nginx, IIS, etc., though, so in the meantime, we have the "lets-encrypt" script to semi-automate things.