rust: add crate skeleton for X.509 path validation

[woodruffw]

This PR adds the core path validation algorithm and policy components, as well as the Python-side verification API.

I'll use this PR to add some basic types as well (and remove the default code), as well as hook this up to the CI's tests and coverage.

See #2381.

[woodruffw]

Design points:

1. I named the "top" type here Validator, which is a little generic. Do you have preferences here?
2. Should the trust store (currently Store) hold both trusted and untrusted parts, or just the trusted parts? My plan was to have it hold both in separate collections, but it could also be just the trusted certificates (with the top-level validation step taking in the untrusted certs separately).

[alex]

1. No strong views 2. Store should contain only trust parts -- or put another way, it should be possible to reuse a store across multiple validations.

…

On Fri, May 5, 2023 at 12:19 PM William Woodruff ***@***.***> wrote: Design points: 1. I named the "top" type here Validator, which is a little generic. Do you have preferences here? 2. Should the trust store (currently Store) hold both trusted and untrusted parts, or just the trusted parts? My plan was to have it hold both in separate collections, but it could also be just the trusted certificates (with the top-level validation step taking in the untrusted certs separately). — Reply to this email directly, view it on GitHub <#8873 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBDZWEVWJZRE64F4PZTXEUZDLANCNFSM6AAAAAAXXLIBQU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[woodruffw]

Related: WDYT about a Policy or Constraints type for the constraints associated with a particular EE cert validation step?

i.e., the top-level API use would be something like:

// Fallibility reflects construction invariants: must be nonempty, must be only CA:true, etc.
let store = Store::try_from(trusted_certs)?;

// Validator defaults to `SystemTime::now`, `Validator::with_time(...)` for control of the validation time.
let validator = Validator::new(store);

let built_chain = validator.validate(leaf, policy)?;

where policy would be something like:

// Fluent-style, or something else?
let policy = Policy::new()
  .untrusted_intermediates(...)
  .key_usages(...)
  .extended_key_usages(...);

[alex]

I don't think I understand why time goes on Validator and not policy. But otherwise this seems fine.

…

On Fri, May 5, 2023 at 12:58 PM William Woodruff ***@***.***> wrote: Related: WDYT about a Policy or Constraints type for the constraints associated with a particular EE cert validation step? i.e., the top-level API use would be something like: // Fallibility reflects construction invariants: must be nonempty, must be only CA:true, etc.let store = Store::try_from(trusted_certs)?; // Validator defaults to `SystemTime::now`, `Validator::with_time(...)` for control of the validation time.let validator = Validator::new(store); let built_chain = validator.validate(leaf, policy)?; where policy would be something like: // Fluent-style, or something else?let policy = Policy::new() .untrusted_intermediates(...) .key_usages(...) .extended_key_usages(...); — Reply to this email directly, view it on GitHub <#8873 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAAGBCPGBK65BK5ZXW33Z3XEU5SVANCNFSM6AAAAAAXXLIBQU> . You are receiving this because you commented.Message ID: ***@***.***>

-- All that is necessary for evil to succeed is for good people to do nothing.

[woodruffw]

I don't think I understand why time goes on Validator and not policy.

No particular reason, it makes more sense on Policy!

(My original rationale was based on 5280 specifying that the time is more "intrinsic" to verification than additional user-introduced constraints, but I see no reason to expose that kind of distinction in a public API, given that the user-facing behavior is the same.)

[woodruffw]

There's a lot more work to be done, but the end-to-end MVP is now in place:

    policy = PolicyBuilder(profile=Profile.RFC5280).build()
    store = Store([root])
    chain = verify(ee, policy, [intermediate], store)

    assert chain == [ee, intermediate, root]

(I added a small testcase that demonstrates this; I'll rewrite it to be more idiomatic after some rounds of review.)

[alex]

Some initial thoughts, I tried to focus on API/design.

There's a lot of code here, and as a general rule we don't land more than a few hundred LoC at a time, so one thing to start thinking about is how you're going to want to split it up.

[woodruffw]

There's a lot of code here, and as a general rule we don't land more than a few hundred LoC at a time, so one thing to start thinking about is how you're going to want to split it up.

Yep -- I'm thinking that the Certificate and Extension API changes can probably go in first, followed by the core path validation logic, followed by the Python bits.

[alex]

This didn't get fixed.

[woodruffw]

Done, replaced with a range check.

[alex]

This can just be merged into permits_leaf now (or vice-versa)