Feature Request: Support for Brainpool Curves (RFC 5639) in TLS 1.2 and TLS 1.3

[obue]

Problem:

Regulatory Compliance Gap for European Markets (DACH Region) Currently, aws-lc does not support Brainpool Elliptic Curves (RFC 5639). While these curves are less common in the public Web PKI, they are a mandatory requirement for critical infrastructure (KRITIS), government applications, and the energy sector (Smart Meter Gateways) in Germany, Austria, and Switzerland.

Specifically, the German Federal Office for Information Security (BSI) Technical Guideline BSI TR-03116 mandates the use of Brainpool curves (primarily brainpoolP256r1, brainpoolP384r1, brainpoolP512r1) for secure connections in these sectors.

Impact on AWS Ecosystem: Developers building applications on AWS (e.g., using aws-lc-rs for Rust Lambda functions or s2n-tls with aws-lc backend) are currently blocked from entering these regulated markets if they rely on the native AWS crypto stack. They are forced to switch to alternative libraries (like OpenSSL or Bouncy Castle) via Foreign Function Interfaces (FFI), which negates the performance optimizations aws-lc provides for AWS Graviton (ARM) processors and complicates the supply chain.

Industry Context: Other major cryptographic libraries have recognized this enterprise need and added full TLS 1.3 support, diverging from the strict "NIST-only" web focus:

• OpenSSL: Added full Brainpool support for TLS 1.3 in Version 3.2.0 (Nov 2023) specifically to address these interoperability needs.
• WolfSSL: Fully supports these curves, often cited as a competitive advantage for embedded/automotive security.
• Bouncy Castle: Widely used in the Java ecosystem for this specific capability.

Solution:

The proposed solution is to integrate support for Brainpool curves into aws-lc's elliptic curve implementation and expose them for TLS negotiation.

1. Mathematical Primitives: Implement the curve parameters defined in RFC 5639 for P256r1, P384r1, and P512r1.
2. TLS 1.2 Support: Register the legacy NamedCurve codepoints as defined in RFC 7027.
3. TLS 1.3 Support: Implement RFC 8734, which defines the new NamedGroup (e.g., brainpoolP256r1tls13 / 0x001f) and SignatureScheme (e.g., ecdsa_brainpoolP256r1tls13_sha256 / 0x081A) identifiers required for TLS 1.3.

Architecture & Design Decisions:

• Does this change any public APIs? Yes. It would require adding new public constants/NIDs for these curves (e.g., NID_brainpoolP256r1) to allow applications to explicitly configure them.
• Which algorithm(s) will this impact? ECDHE (Key Exchange) and ECDSA (Signatures).

Requirements / Acceptance Criteria:

The solution must enable a client/server using aws-lc to successfully negotiate a TLS handshake using a Brainpool certificate or ephemeral key share.

RFC links:

• (https://datatracker.ietf.org/doc/html/rfc5639)
• (https://datatracker.ietf.org/doc/html/rfc7027) (TLS 1.2)
• (https://datatracker.ietf.org/doc/html/rfc8734) (TLS 1.3)

Related Issues: N/A (New request for aws-lc)
Will the Usage Guide or other documentation need to be updated? Yes, the list of supported curves/groups should be updated.

Testing:

• Interoperability: Integration tests ensuring successful handshakes with OpenSSL 3.2+ (which supports RFC 8734) and WolfSSL.
• Vectors: Validation against the test vectors provided in RFC 5639.
• Will this change trigger AWS LibCrypto Formal Verification changes? Ideally, yes. While a generic implementation is a good first step, formally verified assembly optimizations (similar to P-256) would be highly desirable for the long-term roadmap given the high-security context of these curves.
• Should this change be fuzz tested? Yes. Handling of non-NIST curve parameters should be fuzzed to prevent side-channel leaks or validation bypasses.

Out of scope:

• Small Curves: Support for Brainpool curves smaller than 256 bits (e.g., brainpoolP160r1) is not requested, as they do not meet modern security standards (BSI TR-03116) and are not required for the targeted enterprise use cases.
• Twisted Brainpool Curves: The "twisted" variants (e.g., brainpoolP256t1) are generally not required for TLS/X.509 usage, only the "random" (r1) variants are standard for certificates.

[dkostic]

Hi @obue, thanks for opening the issue and bringing this to our attention! We are looking into what it would take to implement support for these curves and prioritizing accordingly. In the meantime, could you please tell us more about your use case? For example, we are not aware of any major AWS service that supports Brainpool curves in their TLS endpoints. Moreover, BSI has been fine with NIST's recommendations so far, as far as we know.

[obue]

Hi @dkostic,
we are hosting strict BSI-regulated workloads on AWS, currently relying on a custom EKS stack because managed services like AWS ALB and WAF lack the necessary curve support.

This is a strict compliance blocker: BSI TR-03116-4 (Chapter 2.2.2) legally mandates the support of both secp256r1 (NIST P-256) and brainpoolP256r1. Furthermore, BSI TR-02102-2 (Chapter 3.6.2) explicitly recommends the Brainpool family (brainpoolP256r1, brainpoolP384r1, brainpoolP512r1) for long-term security. Our certification process is stalled because the BSI rejects reliance on NIST curves alone; the "dual-stack" cryptographic agility is a non-negotiable requirement for our classification level.

The lack of Brainpool support in AWS-LC has now created a critical supply chain issue. With the release of HAProxy 3.2.0, the ecosystem is migrating to AWS-LC to leverage performance gains and Post-Quantum Cryptography (PQC). Consequently, updating the kubernetes-ingress Helm chart (from 1.46.1 to 1.47.4) inadvertently breaks compliance for all regulated users by dropping Brainpool support. We are now forced to choose between running vulnerable/outdated software (OpenSSL variants) or non-compliant software (AWS-LC). Alternatives to HAProxy like Traefik or Envoy do not support such curves and NGINX is EOL.

Please consider this a root requirement for the entire AWS European Sovereign Cloud strategy. If aws-lc, the foundational library for modern AWS infrastructure, does not support these curves, then arguably no native AWS managed service will be able to serve the German public sector or critical infrastructure markets.

Technical Proposal: We understand that writing formally verified assembly for these curves is a significant effort. However, for compliance purposes, we would accept a generic C implementation (ported from OpenSSL) even if it incurs a performance penalty compared to the NIST curves. Additionally, please note that RFC 8734 explicitly standardizes Brainpool curves for TLS 1.3, ensuring they are compatible with modern protocol versions.

I am happy to provide further details on the BSI requirements if needed. You can also reach me directly via the LinkedIn profile linked in my GitHub bio.

[dkostic]

Thanks for detailed response, that's very helpful! We are looking into it and we'll get back to you as soon as possible.