ETSI TS 103 097 V1.2.1 (2015-06)

Intelligent Transport Systems (ITS); Security; Security header and certificate formats

RTS/ITS-00531

General Information

• Status: Published
• Publication Date: 11-Jun-2015
• Technical Committee: ITS WG5 - Security
• Current Stage: 12 - Completion
• Due Date: 24-Jun-2015
• Completion Date: 12-Jun-2015

Standards Content (Sample)

TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
Security;
Security header and certificate formats

2 ETSI TS 103 097 V1.2.1 (2015-06)

Reference
RTS/ITS-00531
Keywords
ITS, privacy, protocol, security
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2015.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
3 ETSI TS 103 097 V1.2.1 (2015-06)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
Introduction . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Basic format elements . 7
4.1 Presentation Language . 7
4.2 Specification of basic format elements . 9
4.2.1 IntX . 9
4.2.2 PublicKeyAlgorithm . 9
4.2.3 SymmetricAlgorithm . 9
4.2.4 PublicKey . 9
4.2.5 EccPoint . 10
4.2.6 EccPointType . 11
4.2.7 EncryptionParameters . 11
4.2.8 Signature . 11
4.2.9 EcdsaSignature . 12
4.2.10 SignerInfo . 12
4.2.11 SignerInfoType . 13
4.2.12 HashedId8 . 13
4.2.13 HashedId3 . 13
4.2.14 Time32 . 14
4.2.15 Time64 . 14
4.2.16 Time64WithStandardDeviation . 14
4.2.17 Duration . 14
4.2.18 TwoDLocation . 15
4.2.19 ThreeDLocation . 15
4.2.20 GeographicRegion . 15
4.2.21 RegionType. 16
4.2.22 CircularRegion . 16
4.2.23 RectangularRegion. 16
4.2.24 PolygonalRegion . 17
4.2.25 IdentifiedRegion . 17
4.2.26 RegionDictionary . 17
5 Specification of security header . 17
5.1 SecuredMessage . 17
5.2 Payload . 18
5.3 PayloadType . 18
5.4 HeaderField . 18
5.5 HeaderFieldType . 20
5.6 TrailerField . 20
5.7 TrailerFieldT ype . 20
5.8 RecipientInfo . 21
5.9 EciesEncryptedKey . 21
6 Specification of certificate format . 22
6.1 Certificate . 22
6.2 SubjectInfo . 23
ETSI
4 ETSI TS 103 097 V1.2.1 (2015-06)
6.3 SubjectType . 23
6.4 SubjectAttribute . 23
6.5 SubjectAttributeType . 24
6.6 SubjectAssurance . 24
6.7 ValidityRestriction . 25
6.8 ValidityRestrictionType . 25
6.9 ItsAidSsp . 25
7 Security profiles . 26
7.1 Security profile for CAMs . 26
7.2 Security profile for DENMs . 27
7.3 Generic security profile for other signed messages . 28
7.4 Profiles for certificates . 29
7.4.1 Introduction. 29
7.4.2 Authorization tickets (pseudonymous certificates) . 30
7.4.3 Enrolment credential (long-term certificates) . 30
7.4.4 Certificate authority certificates . 30
Annex A (informative): Data structure examples . 32
A.1 Example security envelope structure for CAM . 32
A.2 Example structure of a certificate . 33
Annex B (informative): Usage of ITS-AID and SSPs . 34
History . 35

ETSI
5 ETSI TS 103 097 V1.2.1 (2015-06)
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (http://ipr.etsi.org).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI Technical Committee Intelligent Transport Systems
(ITS).
Modal verbs terminology
In the present document "shall", "shall not", "should", "should not", "may", "need not", "will", "will not", "can" and
"cannot" are to be interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of
provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Introduction
Security mechanisms for ITS consist of a number of parts. An important part for interoperability is a common format
for data elements being transferred between ITS stations for security purposes.
The present document intends to provide such a format definition. A special focus is to include as much as possible
from existing standards. At the same time, the major goal is simplicity and extensibility of data structures.
ETSI
6 ETSI TS 103 097 V1.2.1 (2015-06)
1 Scope
The present document specifies security header and certificate formats for Intelligent Transport Systems. These formats
are defined specifically for securing G5 communication.
2 References
2.1 Normative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are necessary for the application of the present document.
[1] IEEE™ 1363-2000: "IEEE Standard Specifications For Public Key Cryptography".
[2] NIMA Technical Report TR8350.2: "Department of Defense World Geodetic System 1984. Its
Definition and Relationships with Local Geodetic Systems".
[3] ISO 3166-1: "Codes for the representation of names of countries and their subdivisions --
Part 1: Country codes".
[4] NIST SP 800-38C: "Recommendation for Block Cipher Modes of Operation: The CCM Mode for
Authentication and Confidentiality".
[5] IETF RFC 2246: "The TLS Protocol Version 1.0".
[6] ETSI TS 102 940: "Intelligent Transport Systems (ITS); Security; ITS communications security
architecture and security management".
[7] ETSI TS 102 965 (V1.2.1): "Intelligent Transport Systems (ITS); Application Object Identifier
(ITS-AID); Registration".
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
reference document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] IEEE™ 1363a-2004: "Standard Specifications For Public Key Cryptography - Amendment 1:
Additional Techniques".
[i.2] IEEE™ 1609.2-2012 (draft D12): "Wireless Access in Vehicular Environments - Security Services
for Applications and Management Messages".
[i.3] IEEE™ 1609.2-2012 (draft D17): "Wireless Access in Vehicular Environments - Security Services
for Applications and Management Messages".
[i.4] IEEE™ 1609.3-2010: "Wireless Access in Vehicular Environments (WAVE) - Networking
Services".
ETSI
7 ETSI TS 103 097 V1.2.1 (2015-06)
[i.5] Standards for Efficient Cryptography 4 (SEC 4): "Elliptic Curve Qu-Vanstone Implicit Certificate
Scheme (ECQV)".
[i.6] Antipa A., R. Gallant, and S. Vanstone: "Accelerated verification of ECDSA signatures", Selected
Areas in Cryptography, 12th International Workshop, SAC 2005, Kingston, ON, Canada,
August 11-12, 2005: Springer, 2005, pp. 307-318.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
enumeration: set of values with distinct meaning
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AES Advanced Encryption Standard
CA Certificate Authority
CAM Cooperative Awareness Message
CRL Certificate Revocation List
DENM Decentralized Environmental Notification Message
DHAES Diffie-Hellman: An Encryption Scheme
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
ECIES Elliptic Curve Integrated Encryption Scheme
ECQV Elliptic Curve Qu-Vanstone
NOTE: Implicit Certificate Scheme.
G5 5,9 GHz radio communications
ITS Intelligent Transport Systems
ITS-AID ITS Application ID
ITS-S Intelligent Transport Systems Station
LSB Least Significant Bit
NIMA National Imagery and Mapping Agency
NIST SP National Institute of Standards and Technology, Special Publication
PSID Provider Service Identifier
NOTE: It is a synonym for ITS-AID.
SSP Service Specific Permissions
TAI Temps Atomique International (International Atomic Time)
TLS Transport Layer Security
UTC Universal Time Coordinated
WGS World Geodetic System
4 Basic format elements
4.1 Presentation Language
The presentation language is derived from the Internet Engineering Task Force (IETF) RFC 2246 (TLS) [5] and from
IEEE 1609.2-2012 [i.2] (draft D12) and is described in table 1. The encoding of multi-byte elements of the presentation
language shall always use network byte order, i.e. big endian byte order, if applicable.
NOTE: The presentation language is not formally defined. Parsing tools based on this notation cannot be
guaranteed to be consistent or complete.
ETSI
8 ETSI TS 103 097 V1.2.1 (2015-06)
Table 1: Presentation language
Element Description Example(s)
variable_name
Variable names Variable names are given in lower case
uint8, uint16, uint32, uint64
Basic data types Basic data types are given in lower case
Composed data types are given with at
Composed data types MyDataType
least the first letter in upper case
// This is a comment
Comments Comments start with the "//" indicator
Numbers are given as signed or unsigned
uint8, uint16, uint32, uint64, sint32
Numbers
big-endian octets
uint8 Coordinates[2];
Fixed-length vectors have a data type and a // two uint8 values
Fixed-length vectors
uint32 Coordinates[8];
fixed octet size given in square brackets
// two uint32 values
uint8 AsciiChar;
The number in angle brackets gives the
AsciiChar Name<2^8-1>;
Variable-length vectors
maximum number of octets. Depending on // "abc" encoded as
// 0x03, 0x61, 0x62, 0x63
with fixed-length length the maximum size, the first 1 byte, 2 bytes,
AsciiChar LongName<2^16-1>;
encoding 4 bytes or 8 bytes encode the actual field
// "abc" encoded as
length
// 0x00, 0x03, 0x61, 0x62, 0x63
uint8 AsciiChar;
AsciiChar Name;
indicates variable-length encoding.

The length itself is encoded with a number
// encoding examples: (the bits with
of "1" bits according to the additional
// grey background represent the
number of octets used to encode the length,
// length encoding of the vector's
followed by a "0" bit and the actual length
// length, X the first of the    //
Variable-length vectors value. The maximum length shall be 2 - 1, vector's following payload bits)
with variable-length i.e. at most seven "1" bits followed by a "0"
// Vector length 5:
length encoding bit shall be used for the variable-length
// Bits: 00000101 XXXXXXXX XXXXXXXX
length encoding. The length of variable-
length vectors with variable-length length
// Vector length 123:
encoding shall be encoded as positive
// Bits: 01111011 XXXXXXXX XXXXXXXX
integer using the minimum number of bits
necessary
// Vector length 388:
// Bits: 10000001 10000100 XXXXXXXX
opaque fieldname[n];
Opaque fields are blocks of data whose
opaque fieldname;
Opaque fields
content interpretation is not further specified
opaque fieldname;
enum {de(0), fr(1), it(2)} Country;
enum {de(0), fr(1), it(2), (2^8-1)}
Enumerations are list of labels with a unique
Country;
value for each label, and optionally a // both variants encoding in one
Enumerations
// octet
maximum value (which then determines
enum {de(0), fr(1), it(2), (2^16-1)}
length of encoding)
Country;
// Encoding in two octets
struct {
Name name;
Constructed types Constructed types contain other types
Country country;
} Person;
struct {
Name name;
Country country;
Case statements are used inside
select(country) {
constructed types to change the contents of case de:
Case statements
uint8 age;
the constructed type depending on the
case fr:
value of the variable given in brackets
AsciiChar given_name<2^8-1>;
}
} Person;
struct {
Name name;
extern Country country;
This is external data that has impact on a
select(country) {
case de:
struct, e.g. in a select statement. It shall be
External data
uint8 age;
described from where the external data is
case fr:
obtained
AsciiChar given_name<2^8-1>;
}
} Person;
ETSI
9 ETSI TS 103 097 V1.2.1 (2015-06)
4.2 Specification of basic format elements
4.2.1 IntX
int_x IntX;
This data type encodes an integer of variable length. The length of this integer is encoded by a number of 1 bits
followed by a 0 bit, where the number of 1 bits is equal to the number of additional octets used to encode the integer
besides those used (partially) to encode the length. The encoding of the length shall use at most 7 bits set to 1.
EXAMPLE: 00001010 encodes the integer 10, while 10001000 10001000 encodes the integer 2 184. The bits
encoding the length of the element are coloured with a grey background.
NOTE: This definition is similar to the definition of PSID in IEEE 1609.3-2010 [i.4], clause 8.1.3, but allows
bigger values of the encoded integer.
4.2.2 PublicKeyAlgorithm
enum {
ecdsa_nistp256_with_sha256(0),
ecies_nistp256(1),
reserved(240.255),
(2^8-1)
} PublicKeyAlgorithm;
This enumeration lists supported algorithms based on public key cryptography. Values in the range of 240 to 255 shall
not be used as they are reserved for internal testing purposes.
NOTE: This definition is similar to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.16, but
ecdsa_nistp224_with_sha224 is not supported by the present document. As a consequence, the
numbering of identical elements (e.g. ecies_nistp256) differs.
4.2.3 SymmetricAlgorithm
enum {
aes_128_ccm (0),
reserved (240.255),
(2^8-1)
} SymmetricAlgorithm;
This enumeration lists supported algorithms based on symmetric key cryptography. Values in the range of 240 to 255
shall not be used as they are reserved for internal testing purposes. The algorithm aes_128_ccm denotes the
symmetric key cryptography algorithm AES-CCM as specified in NIST SP 800-38C [4].
NOTE: Except naming, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.23.
4.2.4 PublicKey
struct {
PublicKeyAlgorithm algorithm;
select(algorithm) {
case ecdsa_nistp256_with_sha256:
EccPoint public_key;
case ecies_nistp256:
SymmetricAlgorithm supported_symm_alg;
EccPoint public_key;
unknown:
opaque  other_key;
}
} PublicKey;
This structure defines a wrapper for public keys by specifying the used algorithm and - depending on the value of
algorithm - the necessary data fields:
• ecdsa_nistp256_with_sha256: the specific details regarding ECC contained in an EccPoint structure shall be
given. The EccPoint used in a PublicKey shall not have EccPointType x_coordinate_only.
ETSI
10 ETSI TS 103 097 V1.2.1 (2015-06)
• ecies_nistp256: the specific details regarding ECC contained in an EccPoint structure and the symmetric key
algorithm contained in a SymmetricAlgorithm structure shall be given. The EccPoint used in a
PublicKey shall not have EccPointType x_coordinate_only.
• unknown: in all other cases, a variable-length vector containing opaque data shall be given.
NOTE: Except naming of included types, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2],
clause 6.3.31.
4.2.5 EccPoint
struct {
extern PublicKeyAlgorithm algorithm;
extern uint8  field_size;
EccPointType    type;
opaque   x[field_size];
select(type) {
case x_coordinate_only:
case compressed_lsb_y_0:
case compressed_lsb_y_1:
;
case uncompressed:
opaque   y[field_size];
unknown:
opaque   data;
}
} EccPoint;
This structure defines a public key based on elliptic curve cryptography according to IEEE 1363-2000 [1], clause 5.5.6.
An EccPoint encodes a coordinate on a two dimensional elliptic curve. The x coordinate of this point shall be
encoded in x as an unsigned integer. Depending on the key type, the y coordinate shall be encoded case-specific:
• x_coordinate_only: only the x coordinate is encoded, no additional data shall be given.
• compressed_lsb_y_0: the point is compressed and y's least significant bit is zero, no additional data shall
be given.
• compressed_lsb_y_1: the point is compressed and y's least significant bit is one, no additional data shall
be given.
• uncompressed: the y coordinate is encoded in the field y as an unsigned integer. The y coordinate
contained in a vector of length field_size containing opaque data shall be given.
• unknown: in all other cases, a variable-length vector containing opaque data shall be given.
The uint8 field_size defining the lengths of the vectors containing the raw keys shall be derived from the given
algorithm and the mapping as defined in table 2. The necessary algorithm shall be given as an external link to the
parameter pk_encryption specified in the structure RecipientInfo.
Table 2: Derivation of field sizes
depending on the used algorithm
PublicKeyAlgorithm value Length in octets
ecdsa_nistp256_with_sha256 32
ecies_nistp256 32
NOTE: Except inclusion of all remaining elements of the enumeration EccPointType that previously matched to
case uncompressed and inclusion of case unknown, this definition is identical to the EccPublicKey in
IEEE 1609.2 Draft D12 [i.2], clause 6.2.18.
ETSI
11 ETSI TS 103 097 V1.2.1 (2015-06)
4.2.6 EccPointType
enum {
x_coordinate_only(0),
compressed_lsb_y_0(2),
compressed_lsb_y_1(3),
uncompressed(4),
(2^8-1)
} EccPointType;
This enumeration lists supported ECC point types.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.19.
4.2.7 EncryptionParameters
struct {
SymmetricAlgorithm symm_algorithm;
select(symm_algorithm) {
case aes_128_ccm:
opaque  nonce[12];
unknown:
opaque  params;
}
} EncryptionParameters;
This structure holds basic parameters and additional data required for encryption and decryption of data using different
symmetric encryption algorithms. In case of aes_128_ccm a 12 octet nonce shall be given. The parameter Tlen
according to NIST SP 800-38C [4] shall be set to Tlen = 128 (bits) and no associated data shall be given. In other
cases the data shall be given as a variable-length vector containing opaque data. It is out of scope of this definition
how resulting ciphertexts are transported. Typically, a ciphertext should be put into a Payload data structure marked
as encrypted using the PayloadType.
NOTE: This structure is not available in IEEE 1609.2 Draft D12 [i.2].
4.2.8 Signature
struct {
PublicKeyAlgorithm algorithm;
select(algorithm) {
case ecdsa_nistp256_with_sha256:
EcdsaSignature ecdsa_signature;
unknown:
opaque  signature;
}
} Signature;
This structure defines a container that encapsulates signatures based on public key cryptography. Depending on the
value of algorithm, different data structures define the algorithm-specific details:
• ecdsa_nistp256_with_sha256: the signature contained in an EcdsaSignature structure shall be
given.
• unknown: in all other cases, a variable-length vector containing the signature as opaque data shall be given.
The data in this structure can be used to verify a data structure's integrity. In conjunction with a matching
SignerInfo structure, the data structure's authenticity can also be verified.
It is necessary to note the following points:
• Clause 5.6 defines which parts of a SecuredMessage data structure are covered by a signature.
• The length of the security_field variable length vector in the SecuredMessage containing
the Signature field shall be calculated before creating the signature using the length of the signature.
ETSI
12 ETSI TS 103 097 V1.2.1 (2015-06)
• Before calculating the actual signature, the length field of the surrounding variable length vector
TrailerField shall be calculated using the value of field_size, since this length field is part of the
signed content.
NOTE: Except naming and full inclusion (not marked as extern) of the enumeration
PublicKeyAlgorithm, this definition is identical to the one in IEEE.1609.2 Draft D12 [i.2],
clause 6.2.15.
4.2.9 EcdsaSignature
struct {
extern PublicKeyAlgorithm algorithm;
extern uint8  field_size;
EccPoint    R;
opaque   s[field_size];
} EcdsaSignature;
This structure defines the details needed to describe an ECDSA based signature. This field's length field_size is
derived from the applied ECDSA algorithm using the mapping as specified in table 2. The extern link that specifies the
algorithm points to the algorithm defined in the surrounding Signature structure. R contains the x coordinate of the
elliptic curve point resulting from multiplying the generator element by the ephemeral private key. The EccPointType
of R shall be set to either compressed_lsb_y_0, compressed_lsb_y_1 or x_coordinate_only.
NOTE 1: Except naming of included type PublicKeyAlgorithm, this definition is identical to the one in
IEEE 1609.2 Draft D12 [i.2], clause 6.2.17.
NOTE 2: It is possible to add extra information by transferring the complete point R in a compressed form instead
of only the x coordinate. This extra information may then be used for a faster signature verification
algorithm as outlined in "Accelerated verification of ECDSA signatures" [i.6].
4.2.10 SignerInfo
struct {
SignerInfoType type;
select(type){
case self:
;
case certificate_digest_with_sha256:
HashedId8  digest;
case certificate:
Certificate  certificate;
case certificate_chain:
Certificate  certificates;
case certificate_digest_with_other_algorithm:
PublicKeyAlgorithm algorithm;
HashedId8  digest;
unknown:
opaque  info;
}
} SignerInfo;
This structure defines how to give information about the signer of a message. The included cryptographic identity can
be used in conjunction with the structure Signature to verify a message's authenticity. Depending on the value of
type, the SignerInfo's data fields shall contain the following entries:
• self: the data is self-signed. Therefore, no additional data shall be given.
• certificate_digest_with_sha256: an 8 octet digest of the relevant certificate contained in a
HashedId8 structure shall be given.
• certificate: the relevant certificate itself contained in a Certificate structure shall be given.
• certificate_chain: a complete certificate chain contained in a variable-length vector of type
Certificate shall be given. The last element of the chain shall contain the certificate used to sign the
message, the next to last element shall contain the certificate of the CA that signed the last certificate and so
on. The first element of the chain needs not be a root certificate.
ETSI
13 ETSI TS 103 097 V1.2.1 (2015-06)
• certificate_digest_with_other_algorithm: an 8 octet digest contained in a HashedId8
structure and the corresponding public key algorithm contained in a PublicKeyAlgorithm structure shall
be given.
• unknown: in all other cases, a variable-length vector containing information as opaque data shall be given.
NOTE: Except naming, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.4.
4.2.11 SignerInfoType
enum {
self(0),
certificate_digest_with_sha256(1),
certificate(2),
certificate_chain(3),
certificate_digest_with_other_algorithm(4),
reserved(240.255),
(2^8-1)
} SignerInfoType;
This enumeration lists methods to describe a message's signer. Values in the range of 240 to 255 shall not be used as
they are reserved for internal testing purposes.
NOTE: This definition is similar to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.5, but naming and
certificate_digest_with_ecdsap224 is not supported by the present document. As a
consequence, the numbering of identical elements (e.g. certificate_chain) differs.
4.2.12 HashedId8
opaque HashedId8[8];
This value is used to identify data such as a certificate. It shall be calculated by first computing the SHA-256 hash of the
input data, and then taking the least significant eight bytes from the hash output.
A canonical encoding for the EccPoint R contained in the signature field of a Certificate shall be used
when calculating the SHA-256 hash from a Certificate. This canonical encoding shall temporarily replace the
value of the EccPointType of the point R of the Certificate with x_coordinate_only for the hash
computation.
NOTE 1: Except naming, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.6.
NOTE 2: The canonical encoding is used to remove the possibility of manipulating the certificate in a way that
results in different HashedId8 identifiers for the same certificate by changing the EccPointType.
Implementations that do not use the fast verification according to "Accelerated verification of ECDSA
signatures" [i.6] cannot detect this manipulation.
4.2.13 HashedId3
opaque HashedId3[3];
This value is used to give an indication on an identifier, where real identification is not required. This can be used to
request a certificate from other surrounding stations. It shall be calculated by first computing the SHA-256 hash of the
input data, and then taking the least significant three bytes from the hash output. If a corresponding HashedId8 value
is available, it can be calculated by truncating the longer HashedId8 to the least significant three bytes.
NOTE: This definition is not available in IEEE 1609.2 Draft D12 [i.2].
ETSI
14 ETSI TS 103 097 V1.2.1 (2015-06)
4.2.14 Time32
uint32 Time32;
Time32 is an unsigned 32-bit integer, encoded in big-endian format, giving the number of International Atomic Time
(TAI) seconds since 00:00:00 UTC, 01 January 2004.
NOTE 1: The period of 2 seconds lasts about 136 years that is until 2140.
NOTE 2: This definition is identical to the one in IEEE 1609.2 Draft D17 [i.3], clause 6.3.31.
4.2.15 Time64
uint64 Time64;
Time64 is a 64-bit unsigned integer, encoded in big-endian format, giving the number of International Atomic Time
(TAI) microseconds since 00:00:00 UTC, 01 January 2004.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D17 [i.3], clause 6.2.12.
4.2.16 Time64WithStandardDeviation
struct {
Time64 time;
uint8 log_std_dev;
} Time64WithStandardDeviation;

This structure defines how to encode time along with the standard deviation of time values. log_std_dev values
0 to 254 represent the rounded up value of the log to the base 1,134666 of the implementation's estimate of the standard
deviation in units of nanoseconds. Values greater than 1,134666 nanoseconds are represented by the value 254, i.e. a
day or longer. If the standard deviation is unknown, value 255 shall be used.
NOTE 1: This definition is identical to the one in IEEE 1609.2 Draft D17 [i.3], clause 6.2.11.
NOTE 2: This definition is currently unused in the security profiles in clause 7.
4.2.17 Duration
uint16 Duration;
This uint16 encodes the duration of a time span (e.g. a certificate's validity). The first three bits shall encode the units
as given in table 3. The remaining 13 bits shall be treated as an integer encoded.
NOTE 1: Except naming, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.5.
NOTE 2: This definition is currently unused in the security profiles in clause 7.
Table 3: Interpretation of duration unit bits
Bits Interpretation
000 seconds
001 minutes (60 seconds)
010 hours (3 600 seconds)
011 60 hour blocks (216 000 seconds)
100 years (31 556 925 seconds)
101, 110, 111 undefined
ETSI
15 ETSI TS 103 097 V1.2.1 (2015-06)
4.2.18 TwoDLocation
struct {
sint32 latitude;
sint32 longitude;
} TwoDLocation;
This structure defines how to specify a two dimensional location. It is used to define validity regions of a certificate.
latitude and longitude encode a coordinate in tenths of micro degrees relative to the World Geodetic System
(WGS)-84 datum as defined in NIMA Technical Report TR8350.2 [2].
The permitted values of latitude range from -900 000 000 to [phone]. The value 900 000 001 shall indicate
the latitude as not being available.
The permitted values of longitude range from -1 800 000 000 to [phone]. The value 1 800 000 001 shall
indicate the longitude as not being available.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.18.
4.2.19 ThreeDLocation
struct {
sint32 latitude;
sint32 longitude;
opaque elevation[2];
} ThreeDLocation;
This structure defines how to specify a three dimensional location. latitude and longitude encode coordinate in
tenths of micro degrees relative to the World Geodetic System (WGS)-84 datum as defined in NIMA Technical
Report TR8350.2 [2].
The permitted values of latitude range from -900 000 000 to [phone]. The value 900 000 001 shall indicate
the latitude as not being available.
The permitted values of longitude range from -1 800 000 000 to [phone]. The value 1 800 000 001 shall
indicate the longitude as not being available.
elevation shall contain the elevation relative to the WGS-84 ellipsoid in decimetres. The value is interpreted as an
asymmetric signed integer with an encoding as follows:
• 0x0000 to 0xEFFF: positive numbers with a range from 0 metres to +6 143,9 metres. All numbers above
+6 143,9 are also represented by 0xEFFF.
• 0xF001 to 0xFFFF: negative numbers with a range from -409,5 metres to -0,1 metres. All numbers
below -409,5 are also represented by 0xF001.
• 0xF000: an unknown elevation.
EXAMPLES: 0x0000 = 0 metre
0x03E8 = 100 metres
0xF7D1 = -209,5 metres (0xF001 + 0x07D0 = -409,5 metres + 200 metres).
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.12.
4.2.20 GeographicRegion
struct {
RegionType  region_type;
select(region_type){
case circle:
CircularRegion circular_region;
case rectangle:
RectangularRegion rectangular_region;
case polygon:
PolygonalRegion polygonal_region;
case id:
ETSI
16 ETSI TS 103 097 V1.2.1 (2015-06)
IdentifiedRegion id_region;
case none:
;
unknown:
opaque  other_region;
}
} GeographicRegion;
This structure defines how to encode geographic regions. These regions can be used to limit the validity of certificates.
In case of rectangle, the region shall consist of a variable-length vector of rectangles that may be overlapping or
disjoint. The variable-length vector shall not contain more than 6 rectangles. The region covered by the rectangles shall
be continuous and shall not contain holes.
NOTE: Except inclusion of case id, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2],
clause 6.3.13.
4.2.21 RegionType
enum {
none(0),
circle(1),
rectangle(2),
polygon(3),
id(4),
reserved(240.255),
(2^8-1)
} RegionType;
This enumeration lists possible region types. Values in the range of 240 to 255 shall not be used as they are reserved for
internal testing purposes.
NOTE: This definition is similar to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.14, but the identifier
numbering differs, the region ID id was added and from_issuer removed.
4.2.22 CircularRegion
struct {
TwoDLocation  center;
uint16     radius;
} CircularRegion;
This structure defines a circular region
...