What an ECTL is
The ECTL — European Certificate Trust List — is a signed file containing the hashed identifiers and full certificates of the Root CAs that the trust framework recognises. It is the artefact that lets a vehicle decide whether a freshly received certificate chain ultimately roots in a Root CA the policy authority has approved.
In production C-ITS, the ECTL is signed by the Trust List Manager (TLM) and published by the CPOC — the EU Certificate Policy Operations Centre run by the JRC. In a testbed like Castell, the same role is played by Castell's own TLM keypair. The semantics are identical; only the policy provenance differs.
ETSI TS 102 941 defines the trust model. ETSI TS 103 097 defines the wire format of the signed message that carries it. IEEE 1609.2 sits underneath both for the cryptographic primitives.
How Castell serves the ECTL
Castell exposes the current ECTL at GET /getectl. The response is the full COER-encoded ToBeSignedTlmCtl wrapped in a signed message, returned as application/octet-stream.
curl -sS https://pki.skyv2x.com/getectl -o ectl.coer
file ectl.coer
# ectl.coer: data
wc -c ectl.coer
# ~730 bytes (current size — grows with each Root CA in the list)The endpoint also exposes a JRC-profile alias at GET /getectl/{hashedId8} for clients that follow the EU CPOC URL convention. Both return the same bytes — only the response headers differ slightly (the JRC alias adds X-Alias-Of: /getectl).
Every change to the Root CA inventory bumps the ECTL sequence number. Stacks that cache the ECTL should compare sequence numbers between fetches and re-validate the chain if it advanced. A delta endpoint GET /getdeltaectl/{hashedId8}/{seq} is available for clients that prefer incremental updates.
What is inside
The signed payload (ToBeSignedTlmCtl) contains, per Root CA entry:
- HashedId8 — the 8-byte fingerprint used everywhere else in ITS to refer back to the cert.
- The full Root CA certificate — explicit ECC, COER-encoded per TS 103 097.
- Access points — the URLs at which the Root CA publishes its own subordinate metadata.
- Lifetime metadata — issuance time and validity window, used to decide whether the entry has expired.
The outer signature is an EcdsaP256Signature produced by the TLM private key. Verifying it requires pinning the TLM certificate, which Castell publishes separately at GET /tlm.
Consuming it from a V2X stack
The typical integration sequence is:
- Pin the TLM cert once, out of band, by fetching
/tlmand verifying its fingerprint matches the value in/capabilities.trust_anchors.tlm. - Fetch
/getectl. Verify its signature against the pinned TLM cert. - Parse the payload. Extract each Root CA entry's certificate and HashedId8.
- Use the extracted Root CAs to validate any subsequent EC, AT or ITS station certificate chain you receive.
- Cache the sequence number. Re-fetch periodically (the spec suggests a few hours; Castell does not throttle the endpoint).
Caveat — this is the testbed ECTL
The ECTL Castell serves contains Castell's own testbed Root CAs, not the real EU CPOC trust list. Vehicles operating in real C-ITS deployments must use the CPOC-issued ECTL. Castell's ECTL is for development, conformance testing and decoder reference work — it lets you exercise the full TS 102 941 trust-validation path against a deterministic file you control end-to-end, without needing CPOC enrolment.
Related material
- Trust anchor — Castell's Root CA cert, the entity the ECTL ultimately roots in.
- Multi-curve support — which ECC curves Castell signs with and accepts.
- Integration walkthrough — end-to-end EC + AT + verify CAM example.
GET /capabilities— machine-readable summary of trust material exposed.