Support explicit EC parameters for Brainpool curves

[sfarestam-iproov]

Summary

Extend the explicit-to-named-curve mapping (added in #12916) to cover brainpoolP256r1, brainpoolP384r1, and brainpoolP512r1. These curves are already supported as named curves — this PR adds only the SpecifiedECDomain constants so that keys encoded with explicit domain parameters are recognized and mapped to the existing named curves.

Motivation

ICAO Doc 9303 (the international standard for machine-readable travel documents / ePassports), Part 12, Section 4.1.6.3 states:

"The elliptic curve domain parameters used to generate the ECDSA key pair MUST be described explicitly in the parameters of the public key, i.e. parameters MUST be of type ECParameters (no named curves, no implicit parameters) and MUST include the optional co-factor. ECPoints MUST be in uncompressed format."

The standard further recommends BSI TR-03111 for elliptic curve selection, which includes the Brainpool curves defined in RFC 5639.

Countries including Germany, Sweden, Finland, Switzerland, Austria, Cyprus, Lithuania, Latvia, Brazil, Russia, China, Turkey, and 20+ others issue ePassport CSCA and Document Signer certificates using Brainpool curves with explicit parameters, exactly as the standard mandates. These certificates are available in the publicly downloadable German CSCA Master List (580 certificates from 114 countries) and the Dutch CSCA Master List.

What this PR does

• Adds BRAINPOOLP256R1_DOMAIN, BRAINPOOLP384R1_DOMAIN, BRAINPOOLP512R1_DOMAIN constants (and _NO_SEED variants) to ec_constants.rs, with domain parameters from RFC 5639 Section 3
• Adds match arms in the SpecifiedCurve branch of ec_params_to_group in ec.rs, gated behind #[cfg(not(any(CRYPTOGRAPHY_IS_BORINGSSL, CRYPTOGRAPHY_IS_AWSLC)))] (same as the existing named-curve Brainpool entries)
• Adds test vectors generated with openssl ecparam -name <curve> -param_enc explicit [-no_seed] -genkey
• Extends the existing test_load_private_key_explicit_parameters and test_load_public_key_explicit_parameters parametrized tests

What this PR does NOT do

• Does not add any new curves — brainpoolP256r1, brainpoolP384r1, brainpoolP512r1 are already in the library
• Does not support arbitrary/custom explicit curves — only exact byte-level matches against RFC 5639 constants
• Does not change any behavior for BoringSSL or AWS-LC builds

References

• ICAO Doc 9303 Part 12 — Public Key Infrastructure for MRTDs (Section 4.1.6.3, p.16)
• RFC 5639 — Elliptic Curve Cryptography (ECC) Brainpool Standard Curves and Curve Generation
• BSI TR-03111 v2.10 — Elliptic Curve Cryptography (recommended by ICAO 9303)
• German CSCA Master List — 580 certificates from 114 countries (test data source)
• Dutch CSCA Master List — additional test data source
• #5659 — original issue requesting explicit EC parameter support (filed for ICAO 9303)
• #12916 — PR that added explicit parameter mapping for P-256/P-384/P-521

[reaperhulk]

Thanks for the contribution. One major challenge here is that we're actively interested in reducing the set of dependencies we have that keep us on OpenSSL in our wheels (see: https://cryptography.io/en/latest/statements/state-of-openssl/), and forks like aws-lc do not support brainpool. If we accept this patch then we will break all wheel users who rely on it when we switch off OpenSSL for our wheels. aws/aws-lc#2939 might be of interest to you. If aws-lc adds support then that significantly reduces my concern about long-term maintainability of this path.

[sfarestam-iproov]

Thanks for the review and context — I wasn't aware of the AWS-LC wheel migration plans.

I want to note that this PR does not add any new public-facing curves. BrainpoolP256r1, BrainpoolP384r1, and BrainpoolP512r1 are already exposed in the library's Python API (ec.py, _CURVE_TYPES, _OID_TO_CURVE) and already gated behind #[cfg(not(any(CRYPTOGRAPHY_IS_BORINGSSL, CRYPTOGRAPHY_IS_AWSLC)))] in the Rust code. This PR only extends the existing explicit-parameter-to-named-curve mapping in ec_constants.rs to cover these already-supported curves — it doesn't increase the OpenSSL-only API surface.

That said, I understand the broader concern about investing in OpenSSL-only code paths. I've added a comment on aws/aws-lc#2939 with the ICAO 9303 ePassport use case, since that issue could use more real-world demand signal to help AWS prioritize.

Happy to keep this PR open until the AWS-LC situation clarifies, or if you'd prefer to close it and revisit later, that works too.