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.70%. Comparing base (aa4686f) to head (bf3d39f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #485      +/-   ##
==========================================
+ Coverage   97.67%   97.70%   +0.03%     
==========================================
  Files          20       20              
  Lines        3995     4050      +55     
==========================================
+ Hits         3902     3957      +55     
  Misses         93       93              

☔ View full report in Codecov by Harness.
📢 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?

[xyzzyz]

Hey, I rebased the branch to use the new PathBuilder API. Please take a look.

[briansmith]

An X.509 certificate with critical extensions that uses "private critical extensions" is not a WebPKI certificate so it is out of scope of this library.

If there is interest in supporting non-WebPKI-conformant certificates then I think it would be good if the API for that made a clear distinction between WebPKI certificate processing and non-WebPKI certificate processing. There are definitely a lot of certificate hierarchies that aren't too different from the WebPKI where this library almost works for them, so it is tempting to add features to support this.

[djc]

The idea I've been kicking around is to have a trait Extensions and replace extensions fields in Cert with a T: Extensions, which should have some methods for a minimal set of extensions that we need to build a verified path. That way (a) we can keep doing our thing and (b) we offer an extension point that people who want to go off the web PKI path can more easily customize.

[briansmith]

Even still, I think it would be good to have more of a distinction in the API between "Hey, I'm using this to validate a WebPKI certificate" vs. other certificates. The recent addition of things like the RequiredXIfYPresent EKU policy stuff already have started to make it difficult to see what parts of this code are relevant to the WebPKi and which aren't.

With respect to this potential API, I think we should also enforce that the ignored critical extensions are NOT standardized extensions. e.g. don't let this API be used to ignore policy-related extensions or other WebPKI-relevant extensions. Otherwise, we encourage people to build applications that are incompatible with more fully-featured standard WebPKI-compatible libraries. One potential way to do this would be to validate that the extensions to ignore have OIDs that aren't in standardized OID namespaces.

The main footgun in APIs like this, which let the application process extensions themselves, is that now that extension processing doesn't influence path building. This is most likely to happen when the extensions are in CA certificates. I suggest that any such API accept separate sets of extensions for end-entity and CA certificates. In the case of the OP's issue, based on the original summary, it seems likely that those extensions are in end-entity certificates?

[xyzzyz]

I think people use rustls-webpki for all kind of certificate validation, not just the WebPKI profile, because there simply aren't any pure Rust alternatives that are nearly as solid. The only other realistic option is to use OpenSSL bindings, or an OpenSSL derived library like AWS LC.

There would be value in implementing path building API which mirrors closely the algorithm described in RFC 5280, including the specified inputs, and hooks into each step. Many extensions describe their processing in terms of how to modify the RFC 5280 algorithm.

See, for example, RFC 5937, Using Trust Anchor Constraints during Certification Path Processing: it tells you how to modify the inputs to the RFC 5280 algorithm, but then doesn't require any special processing during building, because the modification to the inputs will affect how the standard algorithm operates. Doing this is impossible with current rustls-webpki API, which deliberately forgets all the information on the trust anchors except the data that's actually needed.

With respect to this potential API, I think we should also enforce that the ignored critical extensions are NOT standardized extensions. e.g. don't let this API be used to ignore policy-related extensions or other WebPKI-relevant extensions.

My change does not disable processing of the critical extensions that are part of WebPKI, and in fact I added a test for it: ignored_critical_extensions_do_not_disable_supported_extension_parsing

I suggest that any such API accept separate sets of extensions for end-entity and CA certificates.

My change does exactly that, compare ignored_critical_extension_on_end_entity vs. ignored_critical_extension_on_end_entity, although I did not exactly intend it to be that way, it just ended up being forced by the existing API, which required parsing the EndEntityCert before calling verify_for_usage, but did not parse the intermediates until it actually needs them in the process of path building.

In the case of the OP's issue, based on the original summary, it seems likely that those extensions are in end-entity certificates?

I actually struggle with two distinct kinds of private extensions, believe it or not. Once is on end-entity only, and the other affects the entire path.

I will give you an example of a public extensions, however. Consider the processing procedure described in RFC 5913. It plays absolutely no role during actual path building (at least so far as I understand it), and can be applied separately to the finished verified path.

[djc]

I think people use rustls-webpki for all kind of certificate validation, not just the WebPKI profile, because there simply aren't any pure Rust alternatives that are nearly as solid. The only other realistic option is to use OpenSSL bindings, or an OpenSSL derived library like AWS LC.

I think our stance has been that we try to enable these use cases where they don't require significant added complexity/maintenance burden our side and don't materially affect the security posture of actual WebPKI validation.

[xyzzyz]

Hey, is there any path to resolution here? I think the proposed API makes the risk of accidental misuse minimal.

[ctz]

I think people use rustls-webpki for all kind of certificate validation, not just the WebPKI profile, because there simply aren't any pure Rust alternatives that are nearly as solid.

I am wondering if you have evaluated https://github.com/pyca/cryptography/tree/main/src/rust/cryptography-x509 and https://github.com/pyca/cryptography/tree/main/src/rust/cryptography-x509-verification ?

[xyzzyz]

Thanks for bringing this to my attention. I didn't know that it even exist -- probably because the authors don't publish it as a stand-alone rust crate, and instead only intend to use it as a backend implementation for Python library. Consequently, the effort required from my side to use would be rather big: I'd have to maintain a complex fork. They don't seem to support no_std, which I need, which would make the fork diverge significantly.

Given how much energy that would require, I'd rather spend it on implementing a fully-general and extensible RFC 5280 algorithm implementation within the RustCrypto ecosystem (ie. crates like der, x509_cert etc) that I'm already invested in quite heavily.

At the same time, rustls-webpki does almost exactly what I want, so you can obviously see the appeal of tweaking one little thing.

[cpu]

I'd rather spend it on implementing a fully-general and extensible RFC 5280 algorithm implementation within the RustCrypto ecosystem (ie. crates like der, x509_cert etc) that I'm already invested in quite heavily.

If you're invested in RustCrypto you might also find https://github.com/carl-wallace/rust-pki/tree/main/certval interesting. I don't know what the status is, but AIUI it's supported by some of the RustCrypto contributors and built on that ecosystem.

[xyzzyz]

@cpu these seem pretty interesting, but also unfinished/abandoned? They don't seem to be published on crates.io, and so I don't know if anyone actually uses them, making me hesitant to try them. I know this is a kind of a chicken and egg problem, but it is what it is.

[xyzzyz]

(by the way, I rebased this PR onto main)