CRL support tasks

[cpu]

A meta-issue to collect up some of the pieces I think will be needed to complete CRL support in Webpki.

For now I'm trying to limit the scope to verifying end-entity certificate revocation state (based on discussion in rustls/rustls#1164 and similar functionality in other TLS libraries), and not considering CRLs during path-building, however where possible we should leave the door open for supporting that in the future.

• Support for parsing CRLs #54
• Support for parsing large ASN.1 values #58
• Trust anchor and intermediate certificate key usage support #52
• Allow path building to return the validated path #53
• Allow providing CRLs for use with end entity client certificate validation. #55
• Support for identifying the correct CRL for a subject, and finding a serial in the CRL. #56
• Options for improving build_chain error specificity #79

Auxiliary work (nice to have, not required for initial support):

• CRL optimization: rework to avoid linear scan of CRL contents #80
• CRL optimization: verify CRL signatures once, up-front. #81

[cpu]

@ctz @djc @jbr @jsha I would be interested in your input on each of these issues when you have time, and on the initial parsing support I have prepared in #44

I have a very crude prototype validating an end entity client certificate against a CRL but I'm not satisfied with the implementation. I've pulled out these issues based on my experience implementing the prototype as a way to try and make progress on some of the trickier parts.

One question I have in mind above and beyond the individual tasks is how important it is to folks to keep webpki alloc-free given Rustls only uses it with the alloc feature enabled. It makes the implementation of some details less performant and harder to wrangle (though admittedly part of that is probably my own unfamiliarity with this programming style coming mostly from garbage collected languages) .

[djc]

I guess it's fine to only enable CRL support with alloc enabled. Do you expect you'll also need to "regress" existing parts of the code base to allocate, where they currently don't?

[cpu]

I think I've managed to push the functionality where I'd want to consider using alloc out to traits that the consumer can implement, or that we can provide behind a alloc feature flag in-crate. I haven't had to regress any existing parts after all. I think since up-front discussion of the design space hasn't been producing much engagement I'll try to get my code up for review as-is and we can iterate on the various trade offs there.

[djc]

I think I've managed to push the functionality where I'd want to consider using alloc out to traits that the consumer can implement, or that we can provide behind a alloc feature flag in-crate.

Nice!

I haven't had to regress any existing parts after all. I think since up-front discussion of the design space hasn't been producing much engagement I'll try to get my code up for review as-is and we can iterate on the various trade offs there.

Right -- sorry for the lack of feedback. I did look at all the issues you filed a few weeks ago to see if there was something there to respond to, but I don't have enough context yet on either the webpki code base or the subject matter of CRL to have much pre-existing input. Hope to follow-up with reviews once you start submitting stuff, though.

[cpu]

Right -- sorry for the lack of feedback.

no worries, not criticism just acknowledging that I think a different strategy will work better. I appreciate your reviews :-) Once the webpki test refactoring lands I can push my next block of work that builds on #44 and #26. I could share it before then if folks want but the combined diff is pretty enormous and IMO distracting.

[cpu]

Closing this out 🎉 There are a couple of optimizations left but I think the base functionality is here.

I'm going to switch to working on getting this exposed in Rustls. Separately we should consider cutting a release when we're confident that the pieces are arranged correctly.