Assumptions and Limitations

SCMS API Available Endpoints

OpenSCMS implements the endpoints described in the IEEE 1609.2.1 (2022) standard. The endpoints are organized per SCMS component:

RA (Registration Authority)

  • Authorization Certificate Request (Table 10) - Can issue both pseudonym and identification/application certificates for EEs
  • Authorization certificate download (Tables 11, 12 and 14)
  • Successor Enrollment certificate request (Table 13)
  • CCF including CTL Download (Table 16)
  • Composite CRL including CTL download (Table 17)
  • Individual CA certificate Download (Table 18)
  • Individual CRL Download (Table 19) - Note: CRL download endpoint is available although OpenSCMS does not currently implement the MA component
  • CTL download (Table 20)
  • RA certificate download (Table 21)
  • Certificate management information status download (Table 23)

ECA (Enrollment Certificate Authority)

  • Enrollment cert request (Table 9)

RA Limitations

The "MA certificate download" (Table 22) and the "Misbehavior report submission" (Table 15) endpoints are not implemented as OpenSCMS currently does not implement a Misbehavior Authority component.

Types of Issued Certificates

A running instance of OpenSCMS can support multiple types of End Entities (EEs) or certificate requests simultaneously:

  • OBU clients can request pseudonym or identification certificates
  • RSU clients can request identification certificates

EE clients can request either implicit or explicit pseudonym certificates:

  • Implicit certificates rely on ECQV keys, reducing space (saving 64 bytes per certificate)
  • Explicit certificates rely on standard ECDSA over P256 keys and signatures

Both EE and CA certificates are assumed to be 1609.2 format (not X.509).

ASN.1 1609.2 Version

OpenSCMS currently supports the IEEE 1609.2.1 ASN.1 files with tag 2022-published. OpenSCMS provides transpiling utilities (via a fork of the ASN1C transpiler) to convert the IEEE 1609.2.1 ASN1.C files into C code. If new official ASN.1 files are published in the future, the utilities can be used for migration.

Bootstrapping Server Certificates

For testing purposes, OpenSCMS provides a script that generates sample elector certificates, a sample CA certificate chain, and a CTL signed by those elector certificates. The certificates are generated and stored in COER format at a filesystem folder, which should be accessible by the SCMS components for database loading (ECA, ACA, RA).

Limitation: Currently no MA or LA certificates are generated as the SCMS does not implement those components.

Issuing CTLs and Electors Assumptions

SCMS Certificate Trust Lists (CTLs) need to be typically signed by a quorum of multiple electors. Electors are independent entities that "notarize" SCMS Manager decisions without validating the actual CTLs.

The SCMS Manager is a consortium of stakeholders dedicated to the reliable and sustained operation of the V2X ecosystem, including automotive OEMs, roadside infrastructure, traffic management systems, and government agencies.

Current Status: OpenSCMS is not yet integrated with the SCMS Manager. The current CTL bootstrapping process generates sample electors who sign the CTL via a bootstrapping script.

Misbehaviour and Linkage Authorities

The current OpenSCMS does not handle misbehaviour mechanisms for potential EE certificate revocation as there is no well-established related standard in North America.

While in Europe the ETSI TS 103 759 standard defines an interoperable data structure and protocol for misbehavior reports, North American standards assume the function exists within the system design but lack a precise, universally standardized message type.

Although the Linkage Authority (LA) component is implemented and supports deployment of multiple instances, it currently operates as a standalone module. The LA is not integrated into the authorization certificate generation workflow, since OpenSCMS does not yet implement revocation or misbehavior-driven linkage mechanisms.

This limitation is consistent with the fact that misbehavior detection and revocation workflows are out of scope for IEEE 1609.2.1, but it should be clearly noted that the LA integration remains incomplete.

Future Feature: Misbehaviour support is a desired feature, ideally interoperable across North America, European, and other standards.