OpenSCMS: a read of the 1609.2.1 credential lifecycle

What OpenSCMS actually implements

The project publishes an OpenAPI-first backend written in Rust, with the cryptographic primitives handled by a C core wired through bindgen. Three of the SCMS server-side authorities are in the box today:

• Registration Authority (RA) — accepts enrollment requests from devices and mediates between the device and the CAs.
• Enrollment Certificate Authority (ECA) — issues the long-lived enrollment certificates that identify a device as authorised to obtain short-lived credentials.
• Authorization Certificate Authority (ACA) — issues the pseudonym certificates that vehicles actually use to sign safety messages.

That is roughly the spine of credential issuance, and it is the slice that a testbed operator or a stack integrator hits first when they want to exercise sign-verify with something more realistic than a self-signed loop.

Why the RA/ECA/ACA slice matters

Everything else in the SCMS architecture — policy, misbehaviour, linkage, revocation — orbits this spine. The enrollment certificate is the anchor: without it, a device has no basis for asking for pseudonyms. The authorization CA is where the actual identities used on the wire come from. Getting these two right, with an RA in front, is what closes the loop between “the device exists” and “the device is trusted to broadcast”.

For anyone comparing SCMS to the European model, the RA + ECA + ACA shape is what makes both worlds recognisable to each other. ETSI TS 102 941 splits responsibility slightly differently — the Enrollment Authority is the direct issuer, not fronted by an RA — but the two-step enrollment then authorization pattern is the same. If you can read an OpenSCMS request/response cycle, you can read an ETSI 102 941 one.

Reading it next to ETSI TS 102 941

The two credential-management frameworks converge on a common problem — how to hand a moving vehicle a stream of short-lived certificates without exposing a stable identity on the air — and diverge on the machinery around it. A short crib for anyone reading both specs in the same afternoon:

• Long-term identity. SCMS calls it an enrollment certificate, issued by the ECA via the RA. ETSI calls it an enrolment credential, issued by the Enrolment Authority directly.
• Short-term pseudonyms. SCMS calls them pseudonym certificates from the ACA (formerly PCA in older text). ETSI calls them authorization tickets from the Authorization Authority.
• Policy distribution. SCMS has a Policy Generator that signs and distributes global policy files. ETSI relies on the Certificate Trust List published by the Trust List Manager and, for European deployments, the CPOC-hosted ECTL.
• Misbehaviour. SCMS defines a Misbehavior Authority with linkage authorities that can revoke a device’s future pseudonyms without ever learning its identity. ETSI is still catching up here — TS 103 759 exists, but a shipping open reference is scarce.

The RA/ECA/ACA subset in OpenSCMS therefore acts as a Rosetta Stone: whichever framework you learned first, the request-response contracts of the other one become tractable.

What is still open

The visible scope stops at RA/ECA/ACA. Not yet in the box:

• Policy Generator — the global policy file signer.
• Misbehavior Authority — the entity that decides a device is misbehaving and revokes it.
• Linkage Authorities — the pair of entities whose split knowledge is what makes SCMS pseudonymity unlinkable in the first place.
• CRL Generator — the certificate revocation list producer.

None of these are minor. A production SCMS without a Misbehavior Authority is a system that cannot recover from a misbehaving device. A system without Linkage Authorities is a system whose pseudonyms are not, in the strict sense, unlinkable. The current OpenSCMS release is honest about being an enrolment-and-authorization spine; it is not a full SCMS.

Where OpenSCMS fits in an experimenter’s stack

For a research group running a V2X testbed, the sensible read is:

1. Use OpenSCMS to stand up the credential flow end-to-end from enrolment to authorization.
2. Wire it against a message-side implementation — v2verifier is the natural pair for exercising 1609.2 signing and verification with the certificates the ACA produces.
3. Treat the missing components as known missing, not as future features to wait for. A misbehaviour experiment, for instance, still needs a stand-in for the MA.

For anyone whose main interest is the European trust model, the value is comparative: OpenSCMS is a live artefact against which to check how the two families describe the same problem, and where each one is more precise than the other. The specs on both sides read differently after you have watched a real RA answer a real ECA.

Where to find it

• Site: openscms.net
• Repository: github.com/OpenSCMS/OpenSCMS
• License: Apache 2.0
• Language: Rust with a C cryptographic core
• Standard: IEEE 1609.2.1 (2022)

A resource entry for OpenSCMS lives in the resources catalogue.