My understanding is that stapling is the victim of the usual incompetence and laziness that infects a lot of systems where if one in a billion fail closed that would be considered a disaster but one in ten fail open is considered fine. You can't achieve meaningful security this way.
The browser vendors have learned that you have to do it yourself or it won't be done well enough to be useful. So you pull every CRL, do a bunch of compression or other tricks, then give your users that data and now they have working revocation.
When Bob's CA and Kebab Shop breaks their revocation stack, instead of dozens of poor individual users or web site owners confused and calling Bob's outsourced call centre in Pakistan with no sign of a fix, now a Google account exec asks Bob's CTO whether they forgot to say they were getting out of the CA business...
I agree this isn't a desirable outcome, but it might be all we have.
> The browser vendors have learned that you have to do it yourself
Cool. We already got the internet ossified on TCP + UDP, other L4 protocols just get stuck in firewalls and whatnot. Now we're progressing in ossification of HTTP. <insert expletives here>
To be clear: this OCSP decision seems to be driven directly and only by web/HTTP consumers. Anything else is just not considered.
It is called the Web PKI after all. If somebody else actually wants to do all the hard work they're welcome, but my impression is that there's only enthusiasm for bitching and whining which won't get the work done.
We follow standards set by the CA/B forum, undergo WebTrust Audits, and are accepted into the root programs run by the browser vendors (Primarily: Apple, Mozilla, Microsoft, and Chrome). That is the WebPKI.
I am not implying that, but merely defining what the WebPKI is and where we fit into it.
Let's Encrypt's primary goal is to encrypt the web, and most of our decision making is based on that. It isn't so much about HTTP as it is the ecosystem.
You can use our certificates for any TLS Server use-case. I wouldn't suggest using our certificates for things which aren't TLS servers, though.
Thanks for the clarification. I guess I'll have to find a few friends to run an ACME service together with. Unfortunately, in most cases the certificate store is global across applications, so presumably we'll hit a brick wall with browser requirements.
(The services are all TLS based. They are just not HTTP based, and CRLs are generally delivered via HTTP. And I'm not going to wrangle a HTTP client into my mail server, or worse, postgres instance. The latter could also work with a local CA, it's primarily SMTP that doesn't.)
(...or I just ignore revocation and cross my fingers it'll never come up...)
Wait. What. Let's Encrypt CRLs are only available to browser vendors? So you can't even do a CRL check in an SMTP server if you wanted to?
> Our new CRL URLs will be disclosed only in CCADB, so that the Apple and Mozilla root programs can consume them without exposing them to potentially large download traffic from the rest of the internet at large.
The browser vendors have learned that you have to do it yourself or it won't be done well enough to be useful. So you pull every CRL, do a bunch of compression or other tricks, then give your users that data and now they have working revocation.
When Bob's CA and Kebab Shop breaks their revocation stack, instead of dozens of poor individual users or web site owners confused and calling Bob's outsourced call centre in Pakistan with no sign of a fix, now a Google account exec asks Bob's CTO whether they forgot to say they were getting out of the CA business...
I agree this isn't a desirable outcome, but it might be all we have.