I think so -- I would consider crypto/x509's implementation good, and they similarly don't support revocation. More bluntly: it's not clear that revocation really works at all in the Web PKI; I've heard it described more as "homeopathic" than an actual security mechanism.
What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path building process as a dynamic search problem rather than a static one with a "single" result, any implementation you build will probably have the right "primitives" for future constraints (like revocations).
I do believe revocation in the webpki is important to implement, but it's not great today.
There are two promising paths forward, which are complementary: The simple option is short-lived certificates (7 days), which essentially don't require revocation as that's the timeline existing revocation technology can revoke on, but that has some adoption hurdles to overcome in the future.
They are collecting all CRLs from all public web CAs and producing a small, compressed representation of all revoked certificates. That can be pushed to clients, so there's no need for any network traffic (like OCSP checks or CRL downloads) to the wide variety of CAs in the ecosystem.
These "CRL Compact and Push" solutions benefit from shorter-lived certificates (eg, 90 days like Let's Encrypt does right now) because the set of revoked certs is smaller as they roll off once they expire.
I suspect platform verifiers like on Windows and Mac will hopefully ship something like this in the future, though they already have CRL and OCSP fetching and caching.
Non-platform verifiers like this one are really the hardest part to solve revocation. I would suggest supporting CRL checks, but that requires having disk space and caching infrastructure, which is hard for a library to know how to do universally. I think the answer is that we need to have most of our software outsource to a platform verifier, or at least some sort of system-wide revocation information cache or daemon. Maybe this means a new systemd component on Linux :)
There is also the third option, via must-staple, where OCSP responses are attached to the TLS handshake. This resolves the privacy issue [because otherwise clients have to talk directly to CAs and reveal what sites they're visiting].
All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.
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.
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.
Exactly. Because you currently don't check for revocation, you may end up selecting a path that's a dead end and you won't be able to recover. However, if your implementation has pluggable [dynamic] constraints, once you add support for revocation, it will work optimally.
You can run into the same problem with any other constraint, for example hash function deprecation, CA block, and so on.
Aside: Revocation works just fine, it's just that browsers decided not to implement it.
I don't think pluggability is the important thing here: a good path building implementation doesn't need to be pluggable to handle dynamic constraints correctly. More precisely: a "dead path" is only a problem if it somehow excludes otherwise present valid paths, which is not an issue if you chose to not support CRLs at all (you might accept revoked paths, but you certainly won't exclude non-revoked ones).
One of the problems with X.509 PKIs is that you can make them fractally complex; every implementation ends up setting its own "I give up, doing this is too painful" point. CRLs are a common "give up" point, and that probably won't change until CRLite or similar changes things here.
(AIA chasing and OCSP lookups are also similar pain points.)
Well, yes. If you choose to ignore revocation entirely, you will never have a dead path because of it. That will happen only if you path-build, then check revocation as two steps. (IIRC, Windows used to do this, or is still doing it.)
IMO, a good path building implementation has to support revocation, but that's for another conversation :)
What makes a path building implementation good is (IMO) its adherence to the rules Ryan Sleevi enumerates[1]: as long as you conceptualize the path building process as a dynamic search problem rather than a static one with a "single" result, any implementation you build will probably have the right "primitives" for future constraints (like revocations).
[1]: https://medium.com/@sleevi_/path-building-vs-path-verifying-...