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-...
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.
The other solution is what Mozilla is doing with CRLite: https://blog.mozilla.org/security/2020/01/09/crlite-part-1-a...
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 :)
All (big) browsers have mechanisms functionally similar to CRLite. Apple has "valid" (not sure if that's the official name) and Google has CRLSets.
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.
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.
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.
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.
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.)
IMO, a good path building implementation has to support revocation, but that's for another conversation :)