ETSI TS 102 941 V1.3.1 (2019-02)

TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
Security;
Trust and Privacy Management
2 ETSI TS 102 941 V1.3.1 (2019-02)

Reference
RTS/ITS-00552
Keywords
interoperability, ITS, management, 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
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 prevailing version of an ETSI
deliverable is the one made publicly available in PDF format at www.etsi.org/deliver.
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
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
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.

© ETSI 2019.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and
of the oneM2M Partners. ®
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
3 ETSI TS 102 941 V1.3.1 (2019-02)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definition of terms, symbols, abbreviations and notation . 8
3.1 Terms . 8
3.2 Symbols . 8
3.3 Abbreviations . 8
3.4 Notation . 9
4 ITS authority hierarchy . 9
5 Privacy in ITS . 10
6 Trust and privacy management . 11
6.1 ITS-S Security Lifecycle . 11
6.1.1 ITS-S Life-cycle management . 11
6.1.2 Manufacture . 12
6.1.3 Enrolment . 12
6.1.4 Authorization . 13
6.1.5 Maintenance . 14
6.1.6 End of life . 14
6.2 Public Key Infrastructure . 14
6.2.0 General . 14
6.2.0.1 Messages format . 14
6.2.0.2 Signed and encrypted data structures . 16
6.2.1 CA certificate request . 17
6.2.2 Enrolment/Authorization assumption and requirements . 20
6.2.3 Message Sequences. 23
6.2.3.1 Introduction . 23
6.2.3.2 Enrolment Management . 23
6.2.3.2.0 Overview . 23
6.2.3.2.1 Enrolment request . 24
6.2.3.2.2 Enrolment response . 26
6.2.3.3 Authorization Management . 28
6.2.3.3.0 Overview . 28
6.2.3.3.1 Authorization request . 29
6.2.3.3.2 Authorization response . 34
6.2.3.4 Authorization Validation protocol . 35
6.2.3.4.0 Overview . 35
6.2.3.4.1 Authorization validation request . 36
6.2.3.4.2 Authorization validation response . 37
6.3 Generation, distribution and use of Trust information lists . 39
6.3.1 Generation and distribution of CTL by TLM . 39
6.3.2 Generation and distribution of CTL by RCA . 40
6.3.3 Generation and distribution of CRL by RCA . 41
6.3.4 Specification of Full CTL and Delta CTL . 41
6.3.5 Transmission of CTL and CRL. 42
6.3.6 CTL and CRL use by ITS-Ss . 42
7 Security association and key management between ITS Stations . 43
7.0 Introduction . 43
7.1 Broadcast SAs . 43
ETSI
4 ETSI TS 102 941 V1.3.1 (2019-02)
7.2 Multicast SAs . 43
7.3 Unicast SAs . 44
Annex A (normative): ITS security management messages specified in ASN.1 . 46
A.1 ITS trust and privacy messages specified in ASN.1 . 46
A.2 Security management messages structures . 46
A.2.1 Security data structures . 46
A.2.2 Security Management messages for CA . 47
A.2.3 Security Management messages for ITS-S_WithPrivacy . 49
A.2.4 Security Management messages for ITSS_NoPrivacy . 51
A.2.5 Enrolment and authorization data types . 52
A.2.5.1 Enrolment . 52
A.2.5.2 Authorization . 53
A.2.5.3 AuthorizationValidation . 54
A.2.6 Offline message structures . 56
A.2.7 Trust lists data types . 56
Annex B (normative): Service specific parameters (SSPs) definition . 59
B.1 Overview . 59
B.2 CTL SSPs definition . 59
B.3 CRL SSPs definition . 60
B.4 Certificate request messages SSPs definition . 60
B.5 Security Management certificate permissions . 61
Annex C (informative): Communication profiles for security credential provisioning services
(EC request, AT request) . 62
C.0 General . 62
C.1 Communication profiles description . 63
Annex D (normative): Communication profiles for CTL and CRL . 67
D.1 CTL request and response protocol . . 67
D.2 CRL request and response protocol . 67
D.3 Broadcast communication of CTL/CRL . 68
Annex E (informative): Encryption of a message from a sender to a receiver . 69
Annex F (informative): Bibliography . 71
Annex G (informative): Change history . 72
History . 73

ETSI
5 ETSI TS 102 941 V1.3.1 (2019-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables 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 (https://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.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
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.
ETSI
6 ETSI TS 102 941 V1.3.1 (2019-02)
1 Scope
The present document specifies the trust and privacy management for Intelligent Transport System (ITS)
communications. Based upon the security services defined in ETSI TS 102 731 [1] and the security architecture defined
in ETSI TS 102 940 [5], it identifies the trust establishment and privacy management required to support security in an
ITS environment and the relationships that exist between the entities themselves and the elements of the ITS reference
architecture defined in ETSI EN 302 665 [2].
The present document identifies and specifies security services for the establishment and maintenance of identities and
cryptographic keys in an Intelligent Transport System (ITS). Its purpose is to provide the functions upon which systems
of trust and privacy can be built within an ITS.
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
referenced document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://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] ETSI TS 102 731: "Intelligent Transport Systems (ITS); Security; Security Services and
Architecture".
[2] ETSI EN 302 665: "Intelligent Transport Systems (ITS); Communications Architecture".
[3] ETSI TS 103 097: "Intelligent Transport Systems (ITS); Security; Security header and certificate
formats".
[4] ETSI TS 102 942: "Intelligent Transport Systems (ITS); Security; Access control".
[5] ETSI TS 102 940: "Intelligent Transport Systems (ITS); Security; ITS communications security
architecture and security management".
[6] ISO/IEC 8824-1:2015: "Information technology -- Abstract Syntax Notation One (ASN.1):
Specification of basic notation".
[7] Recommendation ITU-T X.696 (08/2014): "Information Technology-Specification of Octet
Encoding Rules (OER)".
[8] Void.
[9] ETSI TS 102 943: "Intelligent Transport Systems (ITS); Security; Confidentiality services".
[10] ETSI EN 302 637-2: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set
of Applications; Part 2: Specification of Cooperative Awareness Basic Service".
[11] ETSI EN 302 637-3: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set
of Applications; Part 3: Specifications of Decentralized Environmental Notification Basic
Service".
[12] ETSI TS 103 301: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Facilities layer protocols and communication requirements for infrastructure
services".
ETSI
7 ETSI TS 102 941 V1.3.1 (2019-02)
[13] NIST FIPS PUB 198-1: "The Keyed-Hash Message Authentication Code (HMAC)".
[14] Void.
[15] IETF RFC 4862: "IPv6 Stateless Address Autoconfiguration".
[16] ETSI EN 302 636-6-1: "Intelligent Transport Systems (ITS); Vehicular Communications;
GeoNetworking; Part 6: Internet Integration; Sub-part 1: Transmission of IPv6 Packets over
GeoNetworking Protocols".
[17] Void.
[18] ETSI EN 302 636-4-1: "Intelligent Transport Systems (ITS); Vehicular communications;
GeoNetworking; Part 4: Geographical addressing and forwarding for point-to-point and point-to-
multipoint communications; Sub-part 1: Media-Independent Functionality".
[19] ETSI TS 102 965: "Intelligent Transport Systems (ITS); Application Object Identifier (ITS-AID);
Registration".
[20] IEEE 802.11™: "IEEE Standard for Information technology -- Telecommunications and
information exchange between systems -- Local and metropolitan area networks-Specific
requirements -- Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
Specifications".
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
referenced 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] ISO/IEC 15408-2: "Information technology - Security techniques - Evaluation criteria for IT
security; Part 2: Security functional components".
[i.2] ETSI TR 102 638: "Intelligent Transport Systems (ITS); Vehicular Communications; Basic Set of
Applications; Definitions".
[i.3] IETF RFC 4046: "Multicast Security (MSEC) Group Key Management Architecture".
[i.4] IETF RFC 4301: "Security Architecture for the Internet Protocol".
[i.5] IETF RFC 4302: "IP Authentication Header".
[i.6] IETF RFC 4303: "IP Encapsulating Security Payload (ESP)".
[i.7] IETF RFC 5246: "The Transport Layer Security (TLS) Protocol Version 1.2".
[i.8] IETF RFC 3547: "The Group Domain of Interpretation".
[i.9] IETF RFC 3830: "MIKEY: Multimedia Internet KEYing".
[i.10] IETF RFC 4535: "GSAKMP: Group Secure Association Key Management Protocol".
[i.11] IETF RFC 4306: "Internet Key Exchange (IKEv2) Protocol", December 2005.
[i.12] IETF RFC 4877: "Mobile IPv6 Operation with IKEv2 and the Revised IPsec Architecture".
[i.13] ETSI TS 102 723-8: "Intelligent Transport Systems (ITS); OSI cross-layer topics; Part 8: Interface
between security entity and network and transport layer".
ETSI
8 ETSI TS 102 941 V1.3.1 (2019-02)
[i.14] CVRIA: "Connected Vehicle Reference Implementation Architecture".
NOTE: Available at http://www.iteris.com/cvria/.
[i.15] ISO 21210-2010: "Intelligent Transport Systems (ITS) - Communications access for land mobiles
(CALM) - Ipv6 networking".
3 Definition of terms, symbols, abbreviations and
notation
3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 102 731 [1], ETSI TS 102 940 [5],
ISO/IEC 15408-2 [i.1] and the following apply:
delta CTL: partial CTL that only contains CTL entries that have been updated since the issuance of the prior, base CTL
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 103 097 [3], ETSI TS 102 940 [21], ETSI
EN 302 636-4-1 [18] and the following apply:
AA Authorization Authority
AES Advanced Encryption Standard
ASN Abstract Syntax Notation
AT Authorization Ticket
CA Certification Authority
CBC-MAC Cipher Block Chaining Message Authentication Code
CCH Control CHannel
CCM Counter with CBC-MAC
CCMS Cooperative-ITS Certificate Management System
COER Canonical Octet Encoding Rule
CPOC C-ITS Point Of Contact
CRL Certificate Revocation List
CTL Certificate Trust List
CVRIA Connected Vehicle Reference Implementation Architecture
DC Distribution Centre
DEN Decentralized Environmental Notification
DENM Decentralized Environmental Notification Message
EA Enrolment Authority
EC Enrolment Credential
ECC Elliptic Curve Cryptography
ECTL European Certificate Trust List
EV Electric Vehicle
FIPS Federal Information Processing Standard
GET command HTTP GET
GN/BTP GeoNetworking/Basic Transport Protocol
GN6 GeoNetworking-IPv6
HMAC keyed-Hash Message Authentication Code
HTTP Hyper Text Transfer Protocol
IETF Internet Engineering Task Force
IP Internet Protocol
ITS-AID ITS Application ID
ETSI
9 ETSI TS 102 941 V1.3.1 (2019-02)
ITU-T International Telecommunication Union - Telecommunication Standardization Sector
KDF Key Derivation Function
LTE Long Term Evolution (4G)
MSB Most Signicant Bit
MSEC Multicast SECurity
OBD On-Board Diagnosis
PA Policy Authority
PDU Protocol Data Unit
PII Personally Identifiable Information
POP Proof Of Possession
PSID Provider Service Identifier
RCA Root Certification Authority
RFC Request For Comment
SA Security Association
SCH Service CHannel
SLAAC StateLess Address Auto Configuration
SM Security Management
SSP Service Specific Permissions
TCP Transmission Control Protocol
TLM Trust List Manager
TLS Transport Layer Security
URL Uniform Resource Locator
V2I Vehicle-to-Infrastructure
WLAN Wireless Local Area Network
XOR eXclusive OR function
3.4 Notation
The requirements identified in the present document include:
a) mandatory requirements strictly to be followed in order to conform to the present document. Such
requirements are indicated by clauses without any additional marking;
b) requirements strictly to be followed if applicable to the type of ITS Station concerned.
Such requirements are indicated by clauses marked by "[CONDITIONAL]"; and where relevant is marked by an
identifier of the type of ITS-S for which the clauses are applicable as follows:
• [Itss_WithPrivacy] is used to denote requirements applicable to ITS-S for which pseudonymity has to be
assured and re-identification by the AA is not allowed. This includes for instance personal user vehicle ITS-S
or personal ITS-S Portable.
• [Itss_NoPrivacy] is used to denote requirements applicable to ITS-S for which pseudonymity does not have to
be assured and are allowed to be re-identified by the AA. This may be for instance fixed or mobile RSUs or
special vehicles.
4 ITS authority hierarchy
Trust and privacy management requires secure distribution and maintenance (including revocation when applicable) of
trust relationships, which may be enabled by specific security parameters that include enrolment credentials that provide
rd
3 party certificates of proof of identity or other attributes such as pseudonym certificates. Public key certificates and
Public Key Infrastructure (PKI) are used to establish and maintain trust between the ITS-S and other ITS-S and
authorities.
ETSI TS 102 731 [1] specifies requirements on security management services and security management roles such as
EAs and AAs. The ITS security architecture is defined in ETSI TS 102 940 [5] and covers both the secured
Communication Architecture, the architecture of the ITS-S Communication security system and the Security
Management System architecture.
ETSI
10 ETSI TS 102 941 V1.3.1 (2019-02)
The present document assumes the definition of the security management entities specified in ETSI TS 102 940 [5] and
the top-level entities for the management of multiple Root CAs collaborating within a single Trust Model. For ease of
reading and for further specification of trust and privacy management the relevant tables from ETSI TS 102 940 [5] are
copied here.
Table 1: Functional element roles of the PKI
Functional element Description
Root Certification Authority The Root CA is the highest level CA in the certification hierarchy. It provides EA and
AA with proof that it may issue enrolment credentials, respectively authorization tickets
Enrolment Authority Security management entity responsible for the life cycle management of enrolment
credentials. Authenticates an ITS-S and grants it access to ITS communications
Authorization Authority Security management entity responsible for issuing, monitoring the use of authorization
tickets. Provides an ITS-S with authoritative proof that it may use specific ITS services
Distribution Centre Provides to ITS-S the updated trust information necessary for performing the validation
(optional) process to control that received information is coming from a legitimate and authorized
ITS-S or a PKI certification authority by publishing the CTL and CRL
Sending ITS-S Acquires rights to access ITS communications from Enrolment Authority
Negotiates rights to invoke ITS services from Authorization Authority
Sends single-hop and relayed broadcast messages
Relaying ITS-S Receives broadcast message from the sending ITS-S and forwards them to the
receiving ITS-S if required
Receiving ITS-S Receives broadcast messages from the sending or relaying ITS-S
Manufacturer Installs necessary information for security management in ITS-S at production
Operator Installs and updates necessary information for security management in ITS-S during
operation
Table 2: Functional element roles of the top-level trust management
Functional element Description
Policy Authority Policy authority is a role composed by the representatives of public and private
stakeholders (e.g. Authorities, Road Operators, Vehicle Manufacturers, etc.)
participating to the C-ITS trust model. It designates and authorizes the TLM and the
CPOC to operate in the C-ITS Trust system. It decides if root CAs are trustable and
approves/removes the Root CAs operation in C-ITS trust domain by notifying the
TLM about approved/revoked Root CAs certificates
Central Point of Contact The CPOC is a unique entity appointed by the Policy Authority. It has responsibility
(optional) to establish and contribute to ensure communication exchange between the Root
CAs, to collect the Root CA certificates and provide them to the Trust List Manager
(TLM). The CPOC is also responsible for distributing the ECTL to any interested
entities in the trust model
Trust List Manager Trust List Manager is responsible for creating the list of root CA certificates and TLM
certificates and signing it. The signed list issued by the TLM is called the ECTL

5 Privacy in ITS
ISO/IEC 15408-2 [i.1] identifies 4 key attributes that relate to privacy:
• anonymity;
• pseudonymity;
• unlinkability; and
• unobservability.
ETSI
11 ETSI TS 102 941 V1.3.1 (2019-02)
Anonymity alone is insufficient for protection of an ITS user's privacy and unsuitable as a solution for ITS, as one of
the main requirements of ITS is that the ITS-S should be observable in order to provide improved safety. Consequently,
pseudonymity and unlinkability offer the appropriate protection of the privacy of a sender of basic ITS safety messages
(CAM and DENM). Pseudonymity ensures that an ITS-S may use a resource or service without disclosing its identity
but can still be accountable for that use [i.1]. Unlinkability ensures that an ITS-S may make multiple uses of resources
or services without others being able to link them together [i.1].
Pseudonymity shall be provided by using temporary identifiers in ITS safety messages, and never transmitting the
station's canonical identifier in communications between ITS stations. Unlinkability can be achieved by limiting the
amount of detailed immutable (or slowly changing) information carried in the ITS safety message, thus preventing the
possible association of transmissions from the same vehicle over a long time period (such as two similar transmissions
broadcast on different days).
ITS Privacy is provided in two dimensions:
i) privacy of ITS registration and authorization tickets provisioning:
- ensured by permitting knowledge of the canonical identifier of an ITS-S to only a limited number of
authorities (EAs);
- provided by the separation of the duties and roles of PKI authorities into an entity verifying the canonical
identifier known as the Enrolment Authority (EA) and an entity responsible for authorizing and
managing services known as the Authorization Authority (AA);
ii) privacy of communications between ITS-Ss.
Separation of duties for enrolment (identification and authentication) and for authorization has been shown in ETSI
TS 102 731 [1] as an essential component of privacy management and provides protection against attacks on a user's
privacy. However, it is possible for the EA role to be delegated to the manufacturer and for the EA and AA roles to be
assumed by a single authority.
When the same operational authority manages both the EA and AA, it shall guarantee privacy of requesting ITS-S i.e.
providing all the technical and organizational measures to ensure that ITS identity information held by the EA is kept
separately to avoid re-identification of pseudonym certificates (ATs).
When dedicated authorities are used only for certificates provisioning to ITS-S which do not have privacy requirements
such as Road-Side Units, the EA and AA may not provide technical and operational separation.
6 Trust and privacy management
6.1 ITS-S Security Lifecycle
6.1.1 ITS-S Life-cycle management
The ITS-S Security Lifecycle includes the following stages (see Figure 1):
• initial ITS-S configuration during manufacture;
• enrolment;
• authorization;
• operation and maintenance;
• end of life.
ETSI
12 ETSI TS 102 941 V1.3.1 (2019-02)

Figure 1: ITS Station Security Life Cycle
6.1.2 Manufacture
As part of the ITS-S manufacturing process, the following information elements associated with the identity of the
station shall be established within the ITS-S itself and within the Enrolment Authority (EA):
• In the ITS-S, the following information elements shall be established using a physically secure process. The
specification of this physically secure process is out of scope for the present document:
- a canonical identifier which is globally unique (see note 1);
- contact information for the EA and AA which will issue certificates for the ITS-S:
 network address;
 public key certificate;
- the set of current known trusted AA certificates which the ITS-S may use to trust communications from
other ITS-S;
- a public/private key pair for cryptographic purposes (canonical key pair); and
- the trust anchor (Root CA) public key certificate and the DC network address;
- in case of a multiple root CAs architecture as specified in [5], the TLM public key certificate and the
CPOC network address.
NOTE 1: The management of the canonical identifier and the means to guarantee uniqueness are not addressed in
the present document.
• In the EA, the following three items of information shall be established, all associated with each other (see
note 2):
- the permanent canonical identifier of the ITS-S;
- the profile information for the ITS-S that may contain an initial list of maximum appPermissions
(ITS-AIDs with SSPs), region restrictions and assurance level which may be modified over time;
- the public key from the key pair belonging to the ITS-S (canonical public key).
NOTE 2: The process for establishing this information within the ITS-S and the EA is beyond the scope of the
present document.
6.1.3 Enrolment
The ITS-S requests its enrolment certificate from the EA (see clause 6.2.3.2).
The state transitions for enrolment are shown in Figure 2.
ETSI
13 ETSI TS 102 941 V1.3.1 (2019-02)

Figure 2: Simplified state machine for the enrolment process
After a successful enrolment process, the ITS-S shall possess an enrolment credential that shall be used in subsequent
authorization requests.
For renewing the Enrolment Certificate at the EA, the ITS-S shall send an EnrolmentRequest signed by the previous
valid enrolment credential issued by this EA.
6.1.4 Authorization
Having received the enrolment credentials (i.e. in state "Enrolled" as shown in Figure 2), the ITS-S is able to request its
authorization ticket(s) from the AA (see clause 6.2.3.3).

Figure 3: Simplified state machine for the authorization process
ETSI
14 ETSI TS 102 941 V1.3.1 (2019-02)
NOTE 1: This state machine only considers one instance of Authorization Request for one service (or class of
services). Eventually, an ITS-S may perform several Authorization Requests to fill a pool of ATs stored
in ITS-S memory (depending of the policy). The management of the pool of ATs within an ITS-S is out
of the scope of the present document.
When in the state "Authorized for service" the ITS-S has a set of authorization tickets to allow signed transmission of
messages to any other ITS-S that do not reveal the canonical identity nor the enrolment credential of the transmitting
ITS-S.
NOTE 2: It is assumed that the ITS service requesting the use of a secure message transfer service only reveals PII
in the payload if the release of that PII has been consented by the sending party.
NOTE 3: The ITS-S in state Authorized for Service may still have the possibility to obtain or update its pool of
Authorization Tickets by sending Authorization requests (not representing on the Figure 3).
When the complete set of authorization tickets is exhausted, the ITS-S cannot sign transmission of messages to others
ITS-S and is back to the state Enrolled.
NOTE 4: In this state diagram, it is assumed that revocation of authorization tickets is not possible as passive
revocation is preferred (the ITS-S receives ATs of limited validity period and of limited allowed
preloading period, renewing them frequently so that compromised ITS-S can be evicted from the ITS
network by not reissuing them new ATs).
6.1.5 Maintenance
If an EA or AA is added to or removed from the system, the Root CA shall inform enrolled ITS-Ss of this change.
When multiple Root CAs are used in the same Trust Domain (as specified in ETSI TS 102 940 [5]), the trust
relationship between the different PKIs may be managed by a Trusted Third Party (Trust List Manager). If a Root CA is
added or removed from the system, the TLM should inform enrolled ITS-Ss of this change.
The process for updating the trust information lists such as the CTL and the CRL and for publishing these lists by the
associated trust authority is specified in clause 6.3 and include different possible methods for updating the enrolled
ITS-Ss:
• requesting CRL and CTL from the distribution centre associated to the root CA;
• sending a trust information list (CRL or CTL) across a wireless interface e.g. using a RSU able to transmit the
CRL/CTL on ITS G5; or
• providing information to a trusted maintenance entity to enable it to update an individual ITS-S in a controlled
environment.
6.1.6 End of life
In case of the device's end of life or following a compromise (revocation decided by its issuing EA), the ITS Station
should be revoked and removed from operation in the ITS G5 communication network by means of a passive
revocation mechanism, i.e. the EA shall reject the authorization of all the next Authorization Ticket requests for this
specific ITS-S.
6.2 Public Key Infrastructure
6.2.0 General
6.2.0.1 Messages format
All the security management messages (SM_PDU) specified in the present document shall follow the message format
shown in Figure 5.
ETSI
15 ETSI TS 102 941 V1.3.1 (2019-02)
Each SM-PDU message shall be encoded into an EtsiTs103097Data-Encrypted, EtsiTs103097Data-
Signed or an EtsiTs103097Data-SignedAndEncrypted structure, depending on the specific message. This
outermost structure shall contain an EtsiTS102941Data which in turn contains the content of the specific message.
Figure 4 shows an example of the use of above structures to provide enrolment/authorization requests and responses
between an ITS-S and a Certification Authority. The same diagram applies for authorization validation requests and
responses exchanged between Certification Authorities (EA and AA) as specified in clause 6.2.3.4.

Figure 4: Illustration of using Security Management PDU structure
This outermost data structure EtsiTs103097Data-Encrypted, EtsiTs103097Data-Signed or
EtsiTs103097Data-SignedAndEncrypted structure shall encapsulate an EtsiTS102941Data as shown in
Figure 5. Specification of all containers and enclosed data structures are given in annex A.

Figure 5: Generic Security Management PDU structure
Each of the SM_PDU is containing an EtsiTS102941Data as specified in clause A.2.1:

EtsiTS102941Data::= SEQUENCE {
version Version (v1),
content EtsiTS102941DataContent
}
EtsiTS102941DataContent ::= CHOICE {
…}
In the present document, the version of EtsiTS102941Data structure shall be set to version v1 (integer value 1).
ETSI
16 ETSI TS 102 941 V1.3.1 (2019-02)
Data structures in the present document are defined using Abstract Syntax Notation 1 (ASN.1) and shall be encoded
using the Canonical Octet Encoding Rules (COER) as defined in Recommendation ITU-T X.696 [7].
The ASN.1 representation of Security Management PDUs shall be as specified in the annex A of the present document.
6.2.0.2 Signed and encrypted data structures
The present document assumes the definition of the data structures specified in ETSI TS 103 097 [3].
Especially the following TS103097 data structures shall be used for encrypted/signed messages specified in the present
document:
• EtsiTs103097Data-Signed;
• EtsiTs103097Data-Encrypted;
• EtsiTs103097Data-SignedAndEncrypted;
• EtsiTs103097Data-SignedExternalPayload.
All signed data structures contain a headerinfo which itself includes a PSID/ ITS-AID. This PSID/ITS-AID is
mandatory and shall be used for certificate management with value as assigned in ETSI TS 102 965 [19].
For all messages that are using the EtsiTs103097Data-SignedAndEncrypted structure as outermost message
format, the EtsiTs1030971Data-SignedAndEncrypted structure shall be built using the security profile for
signed and encrypted messages defined in [3] and shall be composed of an EtsiTs103097Data-Encrypted
structure containing an encrypted EtsiTs103097Data-Signed structure, containing a EtsiTs102941 Data
structure, containing a version and an EtsiTs102941DataContent structure corresponding to the specific
message (see clauses 6.2.3.2 to 6.2.3.4).
For all request and responses messages used for the provisioning of EC or ATs to an ITS-S, the following generic
request and responses messages are used as depicted in Figure 6 and Figure 7.
For each generation of a REQUEST message, the request initiator shall generate a new AES symmetric key k which is
used to encrypt the inner message as shown in Figure 6.
The EtsiTs103097Data-Encrypted structure shall be used to encapsulate all this message data using encryption
option 1: encryption is done using the recipient public encryption key corresponding to the recipient's certificate. The
field recipients shall contain one single RecipientInfo of type certRecipInfo.
The request initiator shall store the encryption symmetric key (k) in memory until it receives and processes the
corresponding RESPONSE message as this key is to be used to decrypt the response (session encryption key). See
clause 7.3.
ETSI
17 ETSI TS 102 941 V1.3.1 (
...