What ETSI TS 102 941 specifies
TS 102 941 sits inside the broader ETSI security architecture defined by TS 102 940. Where TS 102 940 says "there shall be an Enrolment Authority and an Authorization Authority", TS 102 941 specifies what they actually do, in what message format, with what crypto, and under what trust framework.
The spec covers four mechanisms, all glued together by a Root CA at the top and a Trust List Manager (TLM) overseeing the Root CA inventory:
- Enrolment — an ITS station presents a canonical pubkey to the Enrolment Authority (EA) and gets back an Enrolment Credential (EC) — a long-lived cert that proves the station is a legitimate member of the ecosystem.
- Authorization — the station presents its EC to the Authorization Authority (AA) and gets back an Authorization Ticket (AT) — a short-lived pseudonym cert it signs CAMs with.
- Trust list distribution — the TLM signs a CTL (Certificate Trust List, equivalent of ECTL) listing every Root CA the network is willing to accept.
- Revocation — Root CAs publish CRLs (Certificate Revocation Lists) flagging compromised subordinates.
The wire format is COER (Canonical OER), an ASN.1 binary encoding suitable for the size-constrained ITS-G5 channel. Outer signatures use IEEE 1609.2 SignedData wrappers, inner content uses TS 102 941-specific InnerEc and InnerAt structures.
EA and AA — the role split
The separation between Enrolment Authority and Authorization Authority is the privacy mechanism of the entire system. The EA knows the long-term identity of every station; the AA hands out pseudonyms. Neither alone can correlate a CAM seen on the wire to a real-world identity. Both together, in principle, can — which is why their physical separation (different operators, different data jurisdictions) is part of the trust model.
In testbed deployments the same operator typically runs both. Castell runs an EA, an AA and a MA (Misbehaviour Authority) from one stack, while keeping their crypto material logically separated.
How Castell implements TS 102 941
Versions and conformance
Castell declares compliance under TS 102 941 as v1.3.1 wire OER + v2.2.1 protocol semantics. The wire encoding follows the stable v1.3.1 format that the rest of the deployed ITS-G5 ecosystem still expects; the protocol behaviour, accepted CHOICE values, error responses and butterfly-vs-single signalling follow the more recent v2.2.1 semantics. This is the same hybrid most C-ITS testbeds adopt during the v1.3.1 → v2.x transition.
Decoding endpoints expose this distinction explicitly: POST /v221/ec-request-decode and POST /v221/at-request-decode parse incoming requests with v2.2.1-strict ASN.1, which makes it possible to verify conformance proofs against a known-good TS 102 941 v2.2.1 fixture without ambiguity.
Authorization mode
TS 102 941 v2.2.1 defines two ways a station can request an AT: single authorization — one AT per request, used when the station picks up a fresh pseudonym every few minutes — and butterfly key authorization — a batch of ATs derived from one expansion key, used in fleet contexts to minimise round-trips. The spec treats them as alternatives; supporting one is sufficient for conformance.
Castell supports single authorization. Butterfly is not implemented and not on the roadmap: single is sufficient for the integrator workflows the testbed serves, and butterfly's batching machinery adds significant complexity for marginal benefit outside fleet operations. The choice is exposed machine-readably under /capabilities.authorization_modes.
EC and AT request endpoints
# Enrolment Credential request — TS 102 941 §6.2.3.2
POST /ec-request
Content-Type: application/x-its-request
<COER-encoded EnrolmentRequest>
# Authorization Ticket request — TS 102 941 §6.2.3.3
POST /at-request
Content-Type: application/x-its-request
<COER-encoded AuthorizationRequest>Both endpoints respond with a COER-encoded signed message wrapping the issued credential, addressed back to the requester's canonical pubkey by HashedId8. The integration walkthrough shows the full Python flow including request construction.
CTL / ECTL
The Trust List Manager publishes the ECTL (European Certificate Trust List) per §6.4. In Castell this is at GET /getectl — see the ECTL landing for the full format details.
Per Root CA, a CTL listing the EAs and AAs subordinate to that Root is also published — Castell exposes this at GET /getctl/{hashedId8} with delta support at GET /getctl/{hashedId8}/{seq}.
TLM rotation
TS 102 941 §6.4.2.1 specifies that when the TLM is rotated, the outgoing TLM signs a link certificate attesting to the incoming TLM's public key. Stations bootstrap trust in the new TLM by verifying the link certificate against the old one they already pinned.
Castell implements this endpoint at GET /gettlmlinkcertificate[/{hashedId8}]. As of this writing the current TLM (74534B8C394779F4) is the first deployed; no rotation has occurred, so the endpoint returns a structured 404 with the rationale. The /capabilities.tlm_rotation field exposes this state machine-readably.
Related material
- ETSI TS 103 097 — the cert format and signed-message wrapper underneath TS 102 941.
- Integration walkthrough — full EC + AT + verify-CAM flow in Python.
- ECTL, Trust anchor — the trust material TS 102 941 distributes.
GET /conformance— Castell's own subset chain validation as a public artefact.