3 ms·
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
by ivanr 3y ago
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.
- woodruffw 3y agoI 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.)
- ivanr 3y agoWell, 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 :)