Trust and privacy
management for C-ITS

What ETSI TS 102 941 specifies

TS 102 941 sits inside the ETSI security architecture of TS 102 940. Where TS 102 940 says "there shall be an Enrolment Authority and an Authorization Authority", TS 102 941 says what they 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, where an ITS station presents a canonical pubkey to the Enrolment Authority (EA) and gets back an Enrolment Credential (EC), the long-lived cert that proves it belongs to the ecosystem.
• Authorization, where the station presents its EC to the Authorization Authority (AA) and gets back an Authorization Ticket (AT), the short-lived pseudonym cert it signs CAMs with.
• Trust list distribution, where the TLM signs a CTL (Certificate Trust List, the same as the ECTL) listing every Root CA the network accepts.
• Revocation, where Root CAs publish CRLs (Certificate Revocation Lists) flagging compromised subordinates.

The wire format is COER (Canonical OER), an ASN.1 binary encoding sized for the ITS-G5 channel. Outer signatures use IEEE 1609.2 SignedData wrappers; the inner content uses the TS 102 941 InnerEc and InnerAt structures.

The message set

Every exchange in TS 102 941 §6 is one of a small set of request/response pairs, each carried as a COER-encoded signed message:

The request messages carry certificateFormat = ts103097v131; the inner structures (InnerEcRequest, InnerAtRequest and their responses) are what the decode endpoints below parse.

EA and AA: the role split

The split between the Enrolment Authority and the Authorization Authority is the privacy mechanism of the system. The EA knows each station's long-term identity; the AA hands out pseudonyms. Neither alone can tie a CAM on the wire to a real identity. Both together can, in principle, 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 v1.3.1 format the ITS-G5 ecosystem expects. Protocol behaviour, accepted CHOICE values, error responses and butterfly-vs-single signalling follow the newer v2.2.1 semantics. Most C-ITS testbeds run this hybrid through the v1.3.1 → v2.x transition.

Decoding endpoints make this explicit. POST /v221/ec-request-decode and POST /v221/at-request-decode parse requests with v2.2.1-strict ASN.1, so you can check conformance proofs against a known-good TS 102 941 v2.2.1 fixture.

Authorization mode

TS 102 941 v2.2.1 defines two ways a station can request an AT. Single authorization returns one AT per request, for a station that picks up a fresh pseudonym every few minutes. Butterfly key authorization returns a batch of ATs derived from one expansion key, used in fleet contexts to cut round-trips. The spec treats them as alternatives, and supporting one is enough for conformance.

Castell supports single authorization. Butterfly is not implemented and not on the roadmap. Single covers the integrator workflows the testbed serves, and butterfly's batching machinery adds real complexity for little benefit outside fleet operations. Castell reports the choice 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, request construction included.

CTL / ECTL

The Trust List Manager publishes the ECTL (European Certificate Trust List) per §6.3.1, served by Castell at GET /getectl. The ECTL landing covers the format in full, full and delta lists included.

Each Root CA also publishes a CTL listing the EAs and AAs subordinate to it. Castell serves 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 rotates, the outgoing TLM signs a link certificate attesting to the incoming TLM's public key. A station bootstraps trust in the new TLM by verifying that link certificate against the old one it already pinned.

Castell implements this endpoint at GET /gettlmlinkcertificate[/{hashedId8}]. The current TLM (B52CD033B4BA4AE4) replaced its predecessor as part of a full hierarchy regeneration, not through a link certificate, so the endpoint returns a structured 404 with the rationale. The /capabilities.tlm_rotation field reports this state.

Related material

• ETSI TS 103 097: the cert format and signed-message wrapper underneath TS 102 941.
• ECTL, Trust anchor: the trust material TS 102 941 distributes.
• Multi-curve support: the ECC curves the EA and AA sign and accept.
• Misbehaviour reporting: the MA and the revocation path that feeds the CRL.
• Integration walkthrough: full EC + AT + verify-CAM flow in Python.
• GET /conformance: Castell's own subset chain validation as a public artefact.