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 👍