ETSI TS 103 097 V1.1.1 (2013-04)

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

2 ETSI TS 103 097 V1.1.1 (2013-04)

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

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

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
Individual copies of the present document can be downloaded from:
http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or
perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF).
In case of dispute, the reference shall be the printing on ETSI printers of the 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:
http://portal.etsi.org/chaircor/ETSI_support.asp
Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© European Telecommunications Standards Institute 2013.
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.1.1 (2013-04)
Contents
Intellectual Property Rights . 5
Foreword . 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 CrlSeries . 11
4.2.9 Signature . 11
4.2.10 EcdsaSignature . 12
4.2.11 SignerInfo . 12
4.2.12 SignerInfoType . 13
4.2.13 HashedId8 . 13
4.2.14 HashedId3 . 13
4.2.15 Time32 . 13
4.2.16 Time64 . 14
4.2.17 Time64WithStandardDeviation . 14
4.2.18 Duration . 14
4.2.19 TwoDLocation . 14
4.2.20 ThreeDLocation . 15
4.2.21 GeographicRegion . 15
4.2.22 RegionType. 16
4.2.23 CircularRegion . 16
4.2.24 RectangularRegion. 16
4.2.25 PolygonalRegion . 16
4.2.26 IdentifiedRegion . 17
4.2.27 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 . 19
5.6 TrailerField . 20
5.7 TrailerFieldT ype . 20
5.8 RecipientInfo . 20
5.9 EciesNistP256EncryptedKey . 21
6 Specification of certificate format . 21
6.1 Certificate . 21
ETSI
4 ETSI TS 103 097 V1.1.1 (2013-04)
6.2 SubjectInfo . 22
6.3 SubjectType . 22
6.4 SubjectAttribute . 23
6.5 SubjectAttributeType . 23
6.6 SubjectAssurance . 24
6.7 ValidityRestriction . 24
6.8 ValidityRestrictionType . 25
6.9 ItsAidSsp . 25
6.10 ItsAidPriority . 25
6.11 ItsAidPrioritySsp . 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 . 28
7.4.1 Authorization tickets (pseudonymous certificates) . 29
7.4.2 Enrollment credential (long-term certificates) . 29
7.4.3 Certificate authority certificates . 29
Annex A (informative): Data structure examples . 31
A.1 Example security envelope structure for CAM . 31
A.2 Example structure of a certificate . 31
History . 33

ETSI
5 ETSI TS 103 097 V1.1.1 (2013-04)
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).
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.1.1 (2013-04)
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
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
referenced 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.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] IEEE Std. 1363-2000: "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 637-2: "Intelligent Transport Systems (ITS);Vehicular Communications;Basic Set of
Applications; Part 2: Specification of Cooperative Awareness Basic Service".
2.2 Informative references
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 Std 1363a-2004: "Standard Specifications For Public Key Cryptography-
Amendment 1: Additional Techniques".
[i.2] IEEE Std. 1609.2-2012 (draft D12): "Wireless Access in Vehicular Environments - Security
Services for Applications and Management Messages".
[i.3] IEEE Std. 1609.2-2012 (draft D17): "Wireless Access in Vehicular Environments - Security
Services for Applications and Management Messages".
[i.4] IEEE Std. 1609.3-2010: "Wireless Access in Vehicular Environments (WAVE) - Networking
Services".
ETSI
7 ETSI TS 103 097 V1.1.1 (2013-04)
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:
CA Certificate Authority
CAM Cooperative Awareness Message
CRL Certificate Revocation List
DENM Decentralized Environmental Notification Message
ECC Elliptic Curve Cryptography
ECDSA Elliptic Curve Digital Signature Algorithm
G5 5,9 GHz radio communications
ITS Intelligent Transport Systems
ITS-AID ITS Application ID
ITS-S Intelligent Transport Systems Station
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)
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 Std. 1609.2-2012 [i.2] (draft D12) and is described in table 1.
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.1.1 (2013-04)
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, i.e. network byte order
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;
AsciiChar Name<2^8-1>;
The number in angle brackets gives the
Variable-length vectors
// "abc" encoded as
maximum number of octets. Depending on
// 0x03, 0x61, 0x62, 0x63
with fixed length
the maximum size, the first 1, 2, 4 or 8 bytes
AsciiChar LongName<2^16-1>;
encoding
encode the actual field length
// "abc" encoded as
// 0x00, 0x03, 0x61, 0x62, 0x63
uint8 AsciiChar;
AsciiChar Name;
// encoding examples: (the bits with
// grey background represent the
// length encoding of the vector's
indicates variable-length encoding.
// length, X the first of the    //
The length itself is encoded with a number
vector's following payload bits)
Variable-length vectors
of "1" bits according to the additional
with variable-length
// Vector length 5:
number of octets used to encode the length,
encoding
// Bits: 00000101 XXXXXXXX XXXXXXXX
followed by a "0" bit and the actual length
value.
// Vector length 123:
// Bits: 01111011 XXXXXXXX XXXXXXXX
// 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)}
Country;
Enumerations are list of labels with a unique
// both variants encoding in one
value for each label, and optionally a
// octet
Enumerations
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.1.1 (2013-04)
4.2 Specification of basic format elements
4.2.1 IntX
IntX int_x;
This data type encodes an integer of variable length. The length of this integer is encoded by a number of 1 bit followed
by a 0 bit, where the number of 1 bit is equal to the number of additional octets used to encode the integer besides those
used (partially) to encode the length.
EXAMPLE: 00001010 encodes the integer 10, while 10001000 10001000 encodes the integer 2 184. The bits
encoding the length of the element are colored 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. ecdsa_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;
ETSI
10 ETSI TS 103 097 V1.1.1 (2013-04)
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.
• 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.
• 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 Std 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 in network byte order. 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. 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
NOTE: Except inclusion of all remaining elements of the enumeration EccPointTypethat 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.1.1 (2013-04)
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 key 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. 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 CrlSeries
uint32 CrlSeries;
This number identifies a CRL series. The definition of a CRL series itself is outside the scope of the present document.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.21.
4.2.9 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.
ETSI
12 ETSI TS 103 097 V1.1.1 (2013-04)
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 bullet 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.
• 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.10 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. The field s contains the 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 associated ECC public key.
NOTE: 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.
4.2.11 SignerInfo
struct {
SignerInfoType type;
select(type){
case self:
;
case certificate_digest_with_ecdsap256:
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. This shall only be used in case of a
certificate request.
ETSI
13 ETSI TS 103 097 V1.1.1 (2013-04)
• certificate_digest_with_ecdsap256: 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.
• 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.12 SignerInfoType
enum {
self(0),
certificate_digest_with_ecdsap256(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.13 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.
NOTE: Except naming, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.6.
4.2.14 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.1.1 (2013-04)
4.2.15 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, 1 January, 2010.
NOTE 1: The period of 2 seconds lasts about 136 years, that is until 2146.
NOTE 2: Except change of the epoch (starting with 2010 instead of 2004), this definition is identical to the one in
IEEE 1609.2 Draft D17 [i.3], clause 6.3.31.
4.2.16 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, 1 January, 2010.
NOTE: Except change of the epoch (starting with 2010 instead of 2004, this definition is identical to the one in
IEEE 1609.2 Draft D17 [i.3], clause 6.2.12.
4.2.17 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 253 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. The value 254 represents any value greater than 1,134666 nanoseconds, i.e. a day
or longer. The value 255 indicates that the standard deviation is not known.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D17 [i.3], clause 6.2.11.
4.2.18 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 in network byte order.
NOTE: Except naming, this definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.5.
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.1.1 (2013-04)
4.2.19 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 +900 000 000. 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 +1 800 000 000. 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.20 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 +900 000 000. 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 +1 800 000 000. 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 decimeters. The value is interpreted as an
asymmetric signed integer with an encoding as follows:
• 0x0000 to 0xEFFF: positive numbers with a range from 0 to +6 143,9 meters. All numbers above +6 143,9 are
also represented by 0xEFFF.
• 0xF001 to 0xFFFF: negative numbers with a range from -409,5 to -0,1 meters. All numbers below -409,5 are
also represented by 0xF001.
• 0xF000: an unknown elevation.
EXAMPLES: 0x0000 = 0 meters
0x03E8 = 100 meters
0xF7D1 = -209,5 meters (0xF001 + 0x07D0 = -409,5 meters + 200 meters)
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.2.12.
ETSI
16 ETSI TS 103 097 V1.1.1 (2013-04)
4.2.21 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:
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.22 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.23 CircularRegion
struct {
TwoDLocation  center;
uint16     radius;
} CircularRegion;
This structure defines a circular region with radius given in meters and center at center. The region shall include
all points on the reference ellipsoid's surface with a distance smaller or equal than the radius to the center point.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.15.
ETSI
17 ETSI TS 103 097 V1.1.1 (2013-04)
4.2.24 RectangularRegion
struct {
TwoDLocation northwest;
TwoDLocation southeast;
} RectangularRegion;
This structure defines a rectangular region with the uppermost, leftmost point at northwest and the rightmost, lowest
point at southeast.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.16.
4.2.25 PolygonalRegion
TwoDLocation PolygonalRegion;

This variable-length vector describes a region by enumerating points on the region's boundary. The points shall be
linked to each other, with the last point linked to the first. No intersections shall occur and no more than 12 points shall
be given. The specified region shall be continuous and shall not contain holes.
NOTE: This definition is identical to the one in IEEE 1609.2 Draft D12 [i.2], clause 6.3.17.
4.2.26 IdentifiedRegion
struct {
RegionDictionary region_dictionary;
Int16  region_identifier;
IntX  local_region;
} IdentifiedRegion;
This structure defines a predefined geographic region determined by the region dictionary region_dictionary and
the region identifier region_identifier. local_region may optionally specify a more detailed region within
the region. If the whole region is meant, local_region shall be set to 0.
NOTE: This definition is not available in IEEE 1609.2 Draft D12 [i.2].
4.2.27 RegionDictionary
enum {
iso_3166_1(0),
un_stats(1),
(2^8-1)
} RegionDictionary;
This enumeration lists dictionaries containing two-octet records of globally defined regions. The dictionary that
corresponds to iso_3166_1 shall contain values that correspond to numeric country codes as defined in
ISO 3166-1 [3]. The dictionary that corresponds to un_stats shall contain values as defined by the United Nations
Statistics Division, which is a superset of ISO 3166-1 [3] including compositions of regions.
NOTE: This definition is not available in IEEE 1609.2 Draft D12 [i.2].
ETSI
18 ETSI TS 103 097 V1.1.1 (2013-04)
5 Specification of security header
5.1 SecuredMessage
struct {
uint8  protocol_version;
uint8  security_profile;
HeaderField header_fields;
Payload  payload_fields;
TrailerField trailer_fields;
} SecuredMessage;
This structure defines how to encode a generic secured message:
• protocol_version specifies the applied protocol version. For compliance with the present document,
protocol version 1 shall be used.
• security_profile specifies the security profile for this secured message. The profiles define the contents
of the variable header, payload and trailer fields. A message that does not conform to the profile is invalid. The
default value shall be set to 0, if no specific profile is used.
• header_fields is a variable-length vector that contains multiple information fields of interest to the
security layer. If not defined otherwise in a message profile, the sequence of header fields shall be encoded in
ascending numerical
...