Hacker News Reader

Comment by mcpherrinm | Hacker News Reader

Google's CRLSets don't cover nearly the full set of revocations (AFAIK).

I don't know the details of how "valid" works, but as the Apple root program has recently required CAs to publish full CRLs, I assume they're planning something similar.

I mostly cite CRLite as it's well-documented.

I don't think OCSP must-staple is deployable. It requires code changes to effectively every webserver in the world, and that doesn't seem to be happening. I think it is stuck in a spiral of non-adoption, where there's no incentive for anyone to make progress. I believe short-lived certs (7 days) are more deployable in the ecosystem today than ocsp must-staple, with similar security properties. Certificate automation is already desirable, and it's not as big a leap once flows are automated.

This isn't going to happen overnight at least. Years, probably many. But it's happening.

View on HN

"The spiral of non-adoption" is an interesting blog post someone should write. I bet there are a couple more examples besides the obvious one.

It could also be a festival/performance site for unadopted technologies. Sunday, Sunday, key signing ceremony at Non-adoption Spiral!

I think you're right about CRLSets. IMO, Mozilla really wanted to solve the problem, whereas Chrome just wanted to have a solution that they could use for emergency revocation of certificates of high-profile sites (and intermediates/roots). Small-time sites won't be in CRLSets, although if you know the right people and make enough noise you may be added to their list. As for Apple, no one knows what's going on because they don't like to share :)

OCSP must-staple doesn't require code changes. It's a "flag" you set on a certificate. Maybe what you mean is that OCSP stapling is not enabled by default on many installations, and that's true. IIS got it right, and Caddy (obviously, the only platform that got everything right).

Again, we're in this place only because browsers don't care about revocation. If they pushed for it, things would fall into place very quickly. But they're going in the opposite direction.

Short-lived certificates are great, assuming you're fine with a 3.5 day (on average) window of opportunity for exploitation. There's a potentially major problem with clock skew, as many clients have inaccurate clocks. Personally, I recommend that certificates are obtained at least a week before they're deployed; a month would be better. Then rotated a month before they expire. That's how you minimise the problems due to clock skew.

As far as I can figure out, most ocsp staples are valid for 7 days, so short lived certificates would be equivalent, but simpler?

Indeed, you're right. Must-staple and short-lived certificates have the same problem with clock skew.

Apple shared the details of valid.apple.com in a WWDC talk: https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytn...

Slides: https://devstreaming-cdn.apple.com/videos/wwdc/2017/701jvytn...

You can also find the client-side code if you dig around under https://opensource.apple.com/source/Security/

It aims to cover all certificates, similar to Mozilla's CRLite.

Reply on news.ycombinator.com