Three curves.
All in one PKI.

The curves Castell supports

The machine-readable list comes from GET /capabilities under curves_supported. As of this writing:

All three are accepted for initial enrolment (EC request) and for authorization (AT request). The pubkey CHOICE tag is preserved end-to-end through EC and AT decoding — earlier versions of Castell sometimes coerced Brainpool tags back to NIST during validation, which broke enrolment for stations that genuinely held Brainpool material; that bug is fixed since v0.8.8 (see changelog).

Why multi-curve matters

European C-ITS deployments historically standardised on Brainpool curves for sovereignty reasons — the curves originate from Bundesamt für Sicherheit in der Informationstechnik (BSI) and avoid the NIST/NSA parameter-derivation provenance that other regions accept without concern. North American C-V2X deployments and most general-purpose ECC libraries default to NIST P-256.

A PKI that only signs in one family forces every station in the ecosystem to support that family. A multi-curve PKI lets stations bring whichever curve their hardware secure-element happens to support, and have it integrated into the same trust framework. Castell is built to let you exercise both regimes against the same Root CA.

How to request a cert with a specific curve

The pubkey CHOICE inside your EC or AT request determines the issued cert's curve. Generate the keypair on the curve you want, build the request with the matching CHOICE tag (ecdsaNistP256, ecdsaBrainpoolP256r1 or ecdsaBrainpoolP384r1), and submit it. Castell honours whichever curve you ask for.

# Pseudocode — generate a Brainpool P-384r1 keypair and request enrolment
from cryptography.hazmat.primitives.asymmetric import ec
priv = ec.generate_private_key(ec.BrainpoolP384R1())
pub  = priv.public_key()

# Build EcRequest with ecdsaBrainpoolP384r1 in the verificationKey CHOICE
# (full Python flow in /integration)
ec_request = build_ec_request(pub, choice_tag="ecdsaBrainpoolP384r1")
issued_cert = post_ec(ec_request)

Caveat — Brainpool P-384r1 implicit certs are spec-impossible

Castell does not support Brainpool P-384r1 in implicit certificate form. This is not a Castell limitation but an IEEE 1609.2 constraint: even in the draft v4-d8 of 1609.2-2025, the reconstructionValue field of an implicit cert is hardcoded to EccP256CurvePoint. There is no codepath in the standard for a P-384 reconstruction value, so no compliant PKI can issue one. Brainpool P-384r1 certs from Castell are always explicit — public key carried directly in the cert body.

What about future curves

Post-quantum signature schemes (ML-DSA, SLH-DSA, Falcon) are tracked in Castell's research backlog but not in production. The structural issue is signature size: ML-DSA-65 produces ~3309-byte signatures, which exceeds the CAM 1400-byte cap by more than the entire CAM payload. Until ETSI/IEEE publish PQC amendments that address the air-interface fit — or until ITS-G5 / sidelink media grow MTU — PQC stays research-only. No production claim until that window opens.

Related material

• Trust anchors — the cross-curve Root CA, TLM and MA.
• ECTL — the signed Root CA list that anchors the multi-curve hierarchy.
• Integration walkthrough — concrete EC + AT flow including curve selection.
• GET /capabilities — live list under curves_supported.