Allow callers to ignore selected critical extensions

[xyzzyz]

I'm working with a system that uses private critical extensions on X.509 certificate. They don't play a role during building a path, but are then used to enforce constraints on the objects being authenticated. Therefore, I'd like to be able to make rustls-webpki ignore these extensions when building a path, and verify these later separately.

I don't like how I had to add a new method to make sure that API is backwards-compatible. I think that verify_for_usage already has too many arguments as it is. I'd suggest adding a new API that's extensible by design: it should take an Options sort of an object as argument, the fields of which should be private; this way new functionality can be added by adding new public methods on the Options object.

I could do it in a separate PR, and then once it's merged, rebase this one on top of the other one. Thoughts?

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.03%. Comparing base (55a52f3) to head (88fc6de).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #485      +/-   ##
==========================================
+ Coverage   96.97%   97.03%   +0.05%     
==========================================
  Files          20       20              
  Lines        3936     4007      +71     
==========================================
+ Hits         3817     3888      +71     
  Misses        119      119              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ctz]

Therefore, I'd like to be able to make rustls-webpki ignore these extensions when building a path, and verify these later separately.

An earlier discussion on this: #232 (comment)

[xyzzyz]

Thanks for linking this, I have not seen this.

I think my approach matches the spirit of this comment moderately well:

looks like they record all extensions, plus a set of extension OIDs that were critical but not recognised by the core library. then chain verification fails if the unhandled-but-critical set is non-empty. but that means callers can potentially act on those extensions, delete them from the unhandled set, and then do verification afterwards?

In my approach, the user still needs to explicitly declare which critical extensions are to be ignored, and is free to do any processing before or after. The user will need to reparse the certificate to extract the extensions, but I think this is unavoidable in any case: rustls-webpki cannot offer much help in parsing the extensions it does not recognize.

At best, I guess what rustls-webpki could offer is an additional method on Cert:

impl Cert<'a> {
   pub fn extensions(&self) -> impl Iterator<Item = &[u8]>
}

that just iterates over the DER bytes of extensions.

We could actually go one step further, and introduce a public API for extension that just matches the RFC 5280 definition:

struct Extension<'a> { ... }

impl Extension<'a> { 
  pub fn oid(&self) -> &[u8] { ... }
  pub fn is_critical(&self) -> bool { ... }
  pub fn value(&self) -> &[u8] { ... }
}

and have the Cert::extensions return an Iterator over that. Would you like me to implement that?