Make JWKParser EC curve handling extensible: delegate to the active CryptoProvider #50282

danilkiff · 2026-06-23T20:16:38Z

danilkiff
Jun 23, 2026

Context

JWKParser.createECPublicKey (core) maps the JWK crv through a fixed switch and rejects anything else:

switch (crv) {
    case "P-256": name = "secp256r1"; break;
    case "P-384": name = "secp384r1"; break;
    case "P-521": name = "secp521r1"; break;
    default: throw new RuntimeException("Unsupported curve");
}

The key point: the layer directly underneath is already curve-agnostic. CryptoProvider.createECParams(name) resolves the curve through the active provider's named-curve table, which knows far more than these three (brainpool, the secp* family, etc.). So a JWK on a non-P-curve fails for one reason only -- this hardcoded switch overrides an already-extensible provider layer, even when the active crypto provider fully supports the curve.

This is not a request to add a curve or algorithm to core. No curve is added to core; the supported set comes from whichever CryptoProvider is active. The ask is to stop core from special-casing what the SPI is already designed to handle.

Concretely, this blocks any externally-provided EC key -- client registration, IdP jwks_uri, or inline jwks -- whose curve is not one of the three NIST P-curves, regardless of provider capability.

Motivation

PQC readiness (Post-Quantum Cryptography (PQC) readiness #43690, Review what is needed for PQC readiness in Keycloak #45168, Investigate and plan what is needed for OpenID Connect and OAuth 2.0 to be PQC ready #48824): hybrid schemes and provider-specific deployments increasingly need EC keys on curves beyond the three P-curves; the parser shouldn't be the bottleneck.
Custom CryptoProvider: a deployment that plugs in its own crypto provider (own curves/parameters) cannot get those keys through JWKParser today, even though the provider could construct them.

Proposal

Delegate curve handling to the active CryptoProvider instead of hardcoding it in core.

Keep the P-256/384/521 mapping and all existing behavior unchanged.
The provider advertises which curves it supports (a capability/supported-curves set). JWKParser consults that set for any crv outside the standard three; a crv no active provider advertises stays rejected. This is an explicit allow-list, not catch-all "try everything" -- the accepted surface is exactly what the active provider declares.

Seeking guidance on which option is preferred:

Minimal -- for an advertised crv the standard set doesn't cover, route to createECParams (which already delegates to the provider's curve table). Delivers: standard-encoded EC keys on any provider-known named curve (e.g. brainpool). This is the clean, immediate PQC/ecosystem win.
Full (provider-defined JWK -> key) -- add a CryptoProvider hook to build the PublicKey from a JWK whose crv the provider owns, so the provider controls curve parameters, point/coordinate representation, and key factory. Delivers, in addition to Minimal: provider-defined curves whose JWK -> key construction differs from the standard EC assumption -- which the Minimal form structurally cannot reach.

Scope: this is the parse/inbound side only (createECPublicKey, for externally received keys). The publish side (JWKBuilder / JWKS output) is a separate topic and out of scope here.

Constraints

Do not weaken handling or validation of the existing P-256/384/521 curves.
A crv no active provider advertises must still be rejected -- no silent accept.
No new attack surface. Point-on-curve validation must not be weakened. Any curve accepted beyond P-256/384/521 must still reject a public-key point that does not lie on the curve, and that rejection must not depend on JCA provider ordering or on incidental key-factory behavior (Add explicit EC point-on-curve validation in BCEcdhEsAlgorithmProvider #48960). Existing P-256/384/521 validation must stay unchanged.

Questions

Is delegating curve resolution to the active CryptoProvider the right direction, or should new curves be added case-by-case to the switch?
Minimal (createECParams for an advertised crv) vs. a full provider JWK -> key hook -- which do you prefer?
What shape should the capability surface take -- a Set<String> of supported curve names, a per-provider allow-list, or a supports(crv) query?
Where should this validation live -- a baseline on-curve check in core (provider-agnostic, no BouncyCastle dependency in core), with deeper per-curve checks (e.g. a subgroup check for a cofactor > 1 curve) owned by the provider that opts the curve in?

Support provider-defined JWE protected header parameters #50043 -- provider-owned JWE protected header parameters (sibling extensibility topic).
Add explicit EC point-on-curve validation in BCEcdhEsAlgorithmProvider #48960 -- explicit EC point-on-curve validation; the validation a non-NIST/provider curve must own.
Add ECDH-ES JWE Algorithm Provider #23928 -- Add ECDH-ES JWE Algorithm Provider (precedent for EC/JOSE provider extensibility).
PQC readiness: Post-Quantum Cryptography (PQC) readiness #43690, Review what is needed for PQC readiness in Keycloak #45168, Investigate and plan what is needed for OpenID Connect and OAuth 2.0 to be PQC ready #48824, Add ML-DSA SignatureProviderFactory and ClientSignatureVerifierProviderFactory‎ #43684

danilkiff · 2026-06-23T22:28:41Z

danilkiff
Jun 23, 2026
Author

A working (AI-assisted) reference covering the "Minimal" option (Question 2) and the core-side validation (Question 4): feature/jwkparser-delegate-ec-curves. I'd like to agree on the direction here first, before moving on to an issue/PR.

The diff is an SPI contract, aligning the in-tree providers to it (which also fixes a latent NPE on unknown curve names in the default and FIPS providers), a baseline on-curve check in core, and the JWKParser delegation:

CryptoProvider.getSupportedECCurves() -- a default method returning an empty set, so core adds no curves on its own.
JWKParser.createECPublicKey -- beyond P-256/384/521, a crv is accepted only if the active provider advertises it (resolved via createECParams); anything else is still rejected.
createECParams now returns null for an unsupported curve (it previously NPEd on an unknown name in the default/FIPS providers); the in-tree providers are aligned, so JWKParser is just a null-check rather than a try/catch.
For a provider-advertised curve, core explicitly checks the point lies on the curve (y^2 == x^3 + a*x + b mod p, pure-JDK, no BouncyCastle dependency in core) before building the key -- this is the baseline on-curve check from Question 4; a deeper per-curve check (e.g. a cofactor > 1 subgroup check) would be owned by the provider that opts the curve in.

Tests (non-NIST curve, brainpoolP256r1): rejected by the default provider; accepted once a provider advertises the curve; an advertised-but-unresolvable curve is rejected cleanly (no opaque error); and a point not on the advertised curve is rejected by core. Existing curve handling (P-256/384/521) is unchanged.

0 replies

Navigation Menu

Repository navigation

Make JWKParser EC curve handling extensible: delegate to the active CryptoProvider #50282

Uh oh!

{{title}}

Uh oh!

Uh oh!

{{editor}}'s edit

{{editor}}'s edit

Uh oh!

Replies: 1 comment

Uh oh!

{{title}}

Uh oh!

Select a reply

Uh oh!

Make JWKParser EC curve handling extensible: delegate to the active CryptoProvider #50282

Uh oh!

Uh oh!

danilkiff Jun 23, 2026

Context

Motivation

Proposal

Constraints

Questions

Related

Replies: 1 comment

Uh oh!

danilkiff Jun 23, 2026 Author

danilkiff
Jun 23, 2026

danilkiff
Jun 23, 2026
Author