feat: support "verify" with FIPS crypto backend

[domodwyer]

Hi there! First off, thanks for this library and the careful thought put into the security aspects.

I'm working on a system that is deployed in FedRAMP environments, which requires FIPS certified crypto backends, and fortunately the aws-lc-rs crate used by x509-parser is already supported! However it's configured to use the non-FIPS backend when enabling the verify-aws feature today.

This PR adds a new feature flag verify-aws-fips to go alongside the existing verify-aws feature flag, enabling the FIPS-approved aws-lc-rs backend.

There's no code changes, just feature flag toggling 👍

---

• feat: support "verify" with FIPS crypto backend (8f355a0)

  Allow verifying cryptographic signatures using the AWS-LC's FIPS crypto
  backend.
  
  This change allows this library to be used in FedRAMP / US Gov
  deployments, which have a hard requirement on using FIPS-approved crypto
  modules only.
  
  The "verify-aws-fips" feature flag is functionally identical to using
  "verify-aws", but it selects the FIPS backend in aws-lc-rs.
  

[domodwyer]

This is basically all the source code changes in this PR: adding a new feature flag in the same place as verify-aws.

[domodwyer]

This is the new feature flag which switches on the fips feature of the aws-lc-rs crate.

It's either / or for the backends though, and the non-FIPS backend is enabled by default, so I've disabled the default features for aws-lc-rs and let the x509-parser feature flags enable the relevant crypto backend.

[domodwyer]

I figured it was a good idea to add a CI step to verify the FIPS backend is used when the fips flag is provided.

Specifically:

• The non-FIPS backend is not used (aws-lc-sys)
• The FIPS backend is used (aws-lc-fips-sys)

[cpu]

Thanks for the PR (& self-review), I will try to review it soon but I'm supportive of the general direction.

Security audit / security_audit (pull_request) - Failing after 3m

FWIW you can ignore this failing CI job, it's being addressed in #223

[domodwyer]

Awesome! No rush.

Thanks for the link - I see you're keeping support for a MSRV of 1.67.1 in the linked PR, but aws-lc-rs wants at least 1.70:

error: package aws-lc-fips-sys v0.13.11 cannot be built because it requires rustc 1.70.0 or newer, while the currently active rustc version is 1.67.1

Should I gate the CI checks agains the FIPS backend with if: matrix.rust != '1.67.1'?

[cpu]

Thanks for the link - I see you're keeping support for a MSRV of 1.67.1 in the linked PR, but aws-lc-rs wants at least 1.70

I think this will ultimately come down to @chifflier's preference. IMHO I think an MSRV of 1.67 is too stale and many crates in the ecosystem with larger use have more aggressive MSRVs (e.g. Tokio at 1.71, aws-lc-rs at 1.70, rustls at 1.83).

I would personally be in favour of taking an MSRV increase that was more in-line with those projects. 1.71 seems like an OK target and was a rust version released ~2 years ago.

[domodwyer]

It's a shame there's no way of getting hold of rust version metadata for downloads from crates.io in order to make an informed decision - I agree it's quite a low MSRV and I doubt there's a meaningful fraction of users on <1.71 these days.

I will leave it as-is for now, and make any changes after review / when there's a MSRV plan 👍

[cpu]

Thanks! Putting aside the question on how to handle MSRV this looks good to me otherwise.

[cpu]

1.71 seems like an OK target and was a rust version released ~2 years ago.

Another point in favour: in would allow taking a dev dep on wasm-bindgen & associated bits for #231

[DarkmatterVale]

Hey all! Interested in seeing this deployed in the next release. Where does this stand?

[cpu]

Where does this stand?

This branch is targeting main, so unless backported to the x509-parser-0.18 branch it would go out in a 0.19 beta, which as I understand things is blocked on #223

[domodwyer]

I'd be happy to backport to 0.18 if that helps? Would we have the same MSRV problem?

[cpu]

I'd be happy to backport to 0.18 if that helps?

It seems reasonable from my perspective, but I can't publish the crate so I think we're still blocked on chifflier (even setting aside the MSRV issue).

Would we have the same MSRV problem?

Yes, I believe so.

[domodwyer]

It's a shame there's no way of getting hold of rust version metadata for downloads from crates.io in order to make an informed decision - I agree it's quite a low MSRV and I doubt there's a meaningful fraction of users on <1.71 these days.

So fun fact, crates.io has a public Datadog dashboard that tracks requests by cargo version: https://p.datadoghq.com/sb/3a172e20-e9e1-11ed-80e3-da7ad0900002-973f4c1011257befa8598303217bfe3a?fromUser=false&refresh_mode=sliding&from_ts=1771511854139&to_ts=1772116654139&live=true

A quick check of this week of data shows that the highest ranking <1.71 version is 1.70 at 0.36%, and then after that, 1.65 at 0.07% of requests.