Introduce new XRequiredIfYPresent EKU policy with tests

[sgrams]

The spdm-rs library, which utilizes rustls-webpki for certificate validation, encountered an issue with custom EKU OID validation as described in spdm-rs issue #220.

To maintain backward compatibility with SPDM 1.0, spdm-rs must support the following EKU OID verification scenarios:

• For the Requester’s certificate: EKU OID { id-DMTF-spdm 4 } is required if EKU OID { id-DMTF-spdm 3 } is present.
• For the Responder’s certificate: EKU OID { id-DMTF-spdm 3 } is required if EKU OID { id-DMTF-spdm 4 } is present.

The current implementation of rustls/webpki does not support this specific EKU policy.
This PR introduces a new policy to enable the required EKU OID validation logic, ensuring proper interoperability with SPDM 1.0 devices.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 97.56%. Comparing base (7739a54) to head (086a348).
⚠️ Report is 10 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #372      +/-   ##
==========================================
+ Coverage   97.52%   97.56%   +0.04%     
==========================================
  Files          20       20              
  Lines        4081     4156      +75     
==========================================
+ Hits         3980     4055      +75     
  Misses        101      101              

☔ 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.

[djc]

It's not obvious to me that we'd want to support this kind of policy in the library. Couldn't you just handle this in an extra validation step?

[cpu]

Is there an equivalent API exposed by another popular certificate chain verifier library as a point of reference? At face value it seems off to encode a policy this fine-grained into the API.

[ctz]

I wonder if it is instead worth doing something like:

impl Cert {
  pub fn satisfies_extended_key_usage(&self, eku: ExtendedKeyUsage, _verified_path: &VerifiedPath<'_>)
    -> Result<(), Error>;
}

That would allow the particular logic to be constructed as needed, and then applied either after path verification, or during it using the existing verify_path callback (in case the logic has any path-dependent nature, which would allow alternative paths to be found.)

(The unused _verified_path parameter is a misuse-resistance measure, to ensure this function is only callable during or after a path verification.)

[sgrams]

Is there an equivalent API exposed by another popular certificate chain verifier library as a point of reference? At face value it seems off to encode a policy this fine-grained into the API.

I don't think there is any similar API proposed as a point of reference, as libspdm (the standard SPDM library) seems to implement this policy on its own and does not reuse any 3rd party verifier.
See https://github.com/DMTF/libspdm/blob/main/library/spdm_crypt_lib/libspdm_crypt_cert.c#L1257

I proposed the PR mainly because I wanted to reuse webpki library but couldn't find a correct way to skip EKU verification within verify_for_usage as eku is not an optional argument and for spdm-rs use case the "required" or "required_if_present" policy will always fail.

If you disagree to push this PR, please close it, I'll try to find another solution

[cpu]

I don't think there is any similar API proposed as a point of reference, as libspdm (the standard SPDM library) seems to implement this policy on its own and does not reuse any 3rd party verifier.

With a casual look this seems closer to what @ctz is proposing. Hopefully (🤞 ) some higher level of libspdm is doing the end to end path building and signature validation or you have bigger issues.

I think we would want to manage this similarly and have webpki do it's usual path building & verification, but offering your code a place to interrogate the EKUs for a specific end entity cert after that process has completed successfully.

[cpu]

(The unused _verified_path parameter is a misuse-resistance measure, to ensure this function is only callable during or after a path verification.)

If we take this route we should probably check self is on the verified path to prevent someone passing in a verified path for an unrelated chain.

[sgrams]

The newly defined API is resolving my issue, but it seems it lacks pub re-exports of KeyPurposeId and KeyPurposeIdIter. See #380