IEEE 1609.2 V2X Certificate Reference
The certificate format used by every signed V2X message and by every PKI authority that issues V2X credentials. Structurally similar to X.509 but encoded in COER rather than DER, with a different field set, a different signature scheme, and a fundamentally different lifecycle model.
Scope & status
What 1609.2 defines
Certificate format, secured-message wrapper structure, signature schemes, encryption schemes, and trust-management primitives for the IEEE 1609 WAVE protocol family. The certificate format also serves the ETSI ITS stack via the equivalence layer in ETSI TS 103 097.
Current edition
IEEE 1609.2-2022 (and amendments) supersedes the 2016 baseline. The encoding floor (COER) and the certificate skeleton are stable across editions; what evolves is the permitted PSID list, the signature/encryption suites, and the geographic-region representation.
What 1609.2 does NOT define
It does not define the PKI authority structure (that is in ETSI TS 102 941), the secured-message header on the wire (that is in ETSI TS 103 097), or the ITS station security services (ISO 21177). 1609.2 is the certificate format and the cryptographic primitives, not the operational PKI architecture.
Certificate structure (top-level)
A 1609.2 CertificateBase is the ASN.1 type that every issued certificate conforms to. The top-level shape is identical across explicit and implicit certificate types — what varies is the verification key indicator and whether a trailing signature is present.
version
Uint8 — fixed at 3 in current spec. Sentinel for forward compatibility.
type
CertificateType ENUMERATED — explicit (0) or implicit (1). Explicit certs carry a verification key + a separate signature; implicit certs carry a reconstruction value from which the verification key is derived. Both forms are supported in V2X deployments.
issuer
IssuerIdentifier CHOICE: self HashAlgorithm (root cert), sha256AndDigest HashedId8, or sha384AndDigest HashedId8. The HashedId8 is the last 8 bytes of the SHA hash over the issuer's COER-encoded certificate — the V2X analogue of an X.509 Authority Key Identifier.
toBeSigned
ToBeSignedCertificate SEQUENCE — the structural body. Holds identifier, validity, application permissions, region (optional), assurance level (optional), verification key indicator, and other optional descriptors.
signature
Signature CHOICE — optional for implicit certificates, present for explicit certificates. ECDSA over the COER-encoded toBeSigned.
ToBeSignedCertificate fields
id
CertificateId CHOICE: linkageData (Pseudonymous Certificates), name Hostname, binaryId OCTET STRING, or none NULL. PCs use linkageData to support privacy-preserving revocation; ECs commonly use binaryId.
cracaId
HashedId3 — identifies the Certificate Revocation Authorising CA. Three-byte short identifier; ties a certificate to the revocation authority that manages it.
crlSeries
CrlSeries Uint16 — indexes the specific revocation series this certificate is enrolled in. Together with cracaId, identifies the CRL the verifier must check.
validityPeriod
SEQUENCE { start Time32, duration Duration }. Time32 is seconds since the IEEE 1609 epoch (2004-01-01T00:00:00 UTC). Duration is a CHOICE of microseconds, milliseconds, seconds, minutes, hours, sixty-hours, or years — one selected branch.
region
Optional GeographicRegion CHOICE — circular, rectangular, polygonal, or identified region. Restricts where the certificate is valid. Often omitted for global certs.
assuranceLevel
Optional SubjectAssurance OCTET STRING(1) — assurance + confidence bits per IEEE 1609.2 §6.4.18. Encodes hardware-binding strength at issuance time.
appPermissions
Optional SequenceOfPsidSsp — the PSIDs (application identifiers, e.g. BSM, SPaT, MAP) and SSPs (service-specific permissions) this certificate is authorised to sign messages for.
certIssuePermissions
Optional SequenceOfPsidGroupPermissions — only present in CA certs; defines which application permissions this CA is allowed to issue downstream.
verifyKeyIndicator
VerificationKeyIndicator CHOICE: verificationKey PublicVerificationKey (explicit certs) or reconstructionValue EccP256CurvePoint (implicit certs, ECQV).
Encoding: COER, not DER
What COER is
Canonical Octet Encoding Rules — ASN.1 X.696, the canonical subset of OER. Schema-driven (no on-wire tags), big-endian, fixed integer encoding where the schema bounds allow it, length-prefixed where needed. Distinct from DER, which is tag-length-value with universal-class tags.
Why COER (not DER)
COER produces shorter encodings — no per-field tag overhead. A V2X message broadcast at 10 Hz on PC5 sidelink benefits from every byte saved. The trade-off: COER decoders need the schema; you cannot decode a 1609.2 cert with a generic ASN.1 walker.
SEQUENCE preamble
A SEQUENCE with extensibility marker and/or OPTIONALs starts with a preamble byte (or bytes): one bit per OPTIONAL indicating presence, plus the extension presence bit if the SEQUENCE is extensible. Skipping the preamble is the most common decoding bug in hand-rolled parsers.
Length encoding
Short form (one byte, length < 128) or long form (first byte's high bit set, lower 7 bits give the count of following length octets). Same shape as DER length, simpler interpretation: the length always immediately precedes the variable-length content.
Public key & signature shapes
PublicVerificationKey
CHOICE over four ECDSA schemes: ecdsaNistP256, ecdsaBrainpoolP256r1, ecdsaNistP384, ecdsaBrainpoolP384r1. The selected branch carries an EccP256CurvePoint or EccP384CurvePoint.
EccP256CurvePoint
CHOICE with five branches: x-only OCTET STRING(32), fill NULL (placeholder), compressed-y-0 OCTET STRING(32), compressed-y-1 OCTET STRING(32), uncompressedP256 SEQUENCE { x, y }. Compressed forms are most common on the wire.
EccP384CurvePoint
Same five-branch structure, 48-byte coordinates instead of 32. Used by P-384 deployments — less common in vehicular V2X today, more common in long-validity infrastructure certificates.
Signature
CHOICE over the four ECDSA schemes above. The selected branch carries { rSig EccP256CurvePoint, sSig OCTET STRING(32) } or the P-384 equivalent. rSig is encoded as a curve point to facilitate point-recovery optimisations on some verifier implementations.
Comparison with X.509
| Property | X.509 (RFC 5280) | IEEE 1609.2 |
|---|---|---|
| Encoding | DER (TLV) | COER (schema-driven, untagged) |
| Typical size | 1.0 – 2.5 kB | 120 – 250 bytes |
| Subject identifier | DN (Subject + SAN) | CertificateId CHOICE (often linkageData for PCs — no identity) |
| Issuer identifier | Issuer DN | HashedId8 (last 8 bytes of SHA over issuer cert) |
| Typical lifetime | 1 – 10 years (EE), longer (CA) | 5 – 10 minutes (PC), years (EC), decades (root) |
| Permissions | KU, EKU OIDs | SequenceOfPsidSsp (PSID + SSP) |
| Region restriction | Not standard | GeographicRegion (circular / rectangular / polygonal) |
| Implicit certs | Not supported | First-class (ECQV reconstruction value) |
| Trust anchor | Root CA store | Self-signed root cert with issuer = self |
Companion V2X tooling
Walk a certificate
IEEE 1609.2 V2X Certificate Parser — hand-rolled COER decoder for the certificate subset. Hex, Base64, or PEM input. Tree output with field-by-field references back to the relevant 1609.2 sections. Three worked example certificates included.
Validate a chain
V2X Certificate Chain Validator — structural chain validation. Walks root → intermediate → end-entity, computes HashedId8 for each cert, verifies the issuer-linkage chain. Structural validation only — signature verification is a separate gate.
Adjacent standards
ETSI TS 103 097 (secured-message header, certificate equivalence) · ETSI TS 102 941 (trust + privacy management) · ISO 21177 (ITS station security services).
Architecture pages
V2X PKI technology page · V2X security solution · Connected mobility industry page · Device identity at scale.
External references
Standards bodies
IEEE 1609 Working Group (WAVE) · IEEE Standards Association (1609.2 editions and amendments) · ITU-T X.696 (OER) · ITU-T X.680 (ASN.1)
Companion AmbiSecure pages
IoT Security Co-Processor · Secure Elements · JavaCard development
Disclaimer
This page is a structural reference summary derived from the publicly available structure of IEEE 1609.2. It is not a substitute for the standard itself. For implementation conformance, consult the published IEEE standard directly.