Multi-curve certificates
on 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 survives 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).

Those three are the curves Castell issues. The TS 103 097 profile approves ECDSA with SHA-256/384, ECIES and AES-128 as specified in IEEE 1609.2, and inherits its curve set from the base types. That base module (Ieee1609Dot2BaseTypes) defines the point CHOICEs EccP256CurvePoint and EccP384CurvePoint. Its Signature CHOICE carries ecdsaNistP256Signature and ecdsaBrainpoolP256r1Signature, then, after the ASN.1 extension marker, ecdsaBrainpoolP384r1Signature, ecdsaNistP384Signature and sm2Signature. Castell issues the three above. The rest are structurally valid in the format but outside the testbed's issuance policy.

Why multi-curve matters

European C-ITS deployments standardised on Brainpool curves for sovereignty reasons. The curves come from the 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 signs in one family only forces every station in the ecosystem to support that family. A multi-curve PKI lets a station bring whichever curve its hardware secure-element supports and fold it into the same trust framework. Castell lets 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 sets 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. The limit is IEEE 1609.2, not Castell. Even in the draft v4-d8 of 1609.2-2025, the reconstructionValue field of an implicit cert is hardcoded to EccP256CurvePoint. The standard has no codepath for a P-384 reconstruction value, so no compliant PKI can issue one. Brainpool P-384r1 certs from Castell are always explicit, with the public key carried directly in the cert body.

What about future curves

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

Related material

• ETSI TS 103 097: the certificate format that carries these curves on the wire.
• ETSI TS 102 941: the EC and AT flows where the curve CHOICE is set.
• 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.