ETSI TS 103 600 V1.2.1 (2022-02)

Intelligent Transport Systems (ITS); Testing; Interoperability test specifications for security

RTS/ITS-00565

General Information

• Status: Not Published
• Technical Committee: ITS WG5 - Security
• Current Stage: 12 - Completion
• Due Date: 03-Mar-2022
• Completion Date: 28-Feb-2022

Standards Content (Sample)

TECHNICAL SPECIFICATION
Intelligent Transport Systems (ITS);
Testing;
Interoperability test specifications for security

2 ETSI TS 103 600 V1.2.1 (2022-02)

Reference
RTS/ITS-00565
Keywords
interoperability, ITS, security, testing
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

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
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
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 2022.
All rights reserved.
ETSI
3 ETSI TS 103 600 V1.2.1 (2022-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 . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 7
4 Requirements and configuration . 7
4.1 Requirements . 7
4.1.1 Overview . 7
4.1.2 ITS stations . 7
4.1.3 PKI . 8
4.1.4 TLM . 8
4.2 Configurations . 8
4.2.1 CFG_SEC - ITS-S secured communication . 8
4.2.2 CFG_PKI - PKI communication . 9
5 Requirements to be tested. 10
5.1 Overview . 10
5.2 ITS-S communication messages . 10
5.3 ECTL Handling . 11
5.4 RCA CTL Handling . 12
5.5 RCA CRL Handling . 12
5.6 PKI communication - Enrolment Management . 12
5.7 PKI communication - Authorization Management . 13
5.8 PKI interoperability . 13
6 Interoperability test descriptions . 14
6.1 Overview . 14
6.2 ITS-S secured communication . 14
6.2.1 Successful basic communication . 14
6.2.1.1 Use-case 1-1 - Both ITS-S authorized by the same AA . 14
6.2.1.2 Use-case 1-2 - Different AAs of the same PKI . 15
6.2.1.3 Use-case 1-3 - Peer-to-peer distribution of AA certificate . 16
6.2.1.4 Use-case 1-4 - Participating ITS-S are registered in different RCAs . 18
6.2.1.5 Use-case 1-5 - Pseudonym changing . 19
6.2.2 Exceptional behaviour basic communication. 20
6.2.2.1 Use-case 2-1 - Invalid certificate region . 20
6.2.2.2 Use-case 2-2 - Invalid ValidityPeriod of ATs . 21
6.2.2.3 Use-case 2-3 - PSID exceptional behaviour . 22
6.2.2.3.1 Use-case 2-3a - CAM PSID missing in ATs - rejected sending . 22
6.2.2.3.2 Use-case 2-3b - DENM PSID missing in ATs - rejected sending . 22
6.2.2.4 Use-case 2-4 - Using of AT issued by AA included in the CRL . 23
6.2.2.5 Use-case 2-5 - Unknown RCA . 24
6.3 PKI communication . 26
6.3.0 Overview . 26
6.3.1 Enrolment behaviour. 26
6.3.1.1 Use-case 3-1 - Valid enrolment behaviour . 26
6.3.1.2 Use-case 3-2 - Enrolment behaviour with already enrolled station . 26
6.3.1.3 Use-case 3-3 - Enrolment behaviour when ITS-S is not registered on the EA . 27
6.3.1.4 Use-case 3-4 - Enrolment behaviour when EA is on the CRL . 28
ETSI
4 ETSI TS 103 600 V1.2.1 (2022-02)
6.3.2 Authorization behaviour . 29
6.3.2.1 Use-case 4-1 - Valid authorization behaviour . 29
6.3.2.2 Use-case 4-2 - Authorization behaviour with optional privacy requirements . 30
6.3.2.3 Use-case 4-3 - Authorization behaviour when AA and EA are from different PKI . 31
6.3.2.4 Use-case 4-4 - Authorization behaviour when AA is on the CRL . 32
6.3.2.5 Use-case 4-5 - Check renewal of expired AT certificates . 35
6.3.3 CA certificate request and distribution . 36
6.3.3.1 Use-case 5-1 - Initial CA certificate request . 36
6.3.3.2 Use-case 5-2 - Re-keying of CA certificate . 37
6.4 Comprehensive scenarios . 38
Annex A (informative): Bibliography . 39
History . 40

ETSI
5 ETSI TS 103 600 V1.2.1 (2022-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are 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 Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
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.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its

Members. 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.
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 103 600 V1.2.1 (2022-02)
1 Scope
The present document contains specification of interoperability test descriptions to validate implementations of ETSI
TS 103 097 [1], ETSI TS 102 941 [3] and ETSI TS 102 940 [i.1].
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 103 097 (V1.4.1): "Intelligent Transport Systems (ITS); Security; Security header and
certificate formats".
[2] IEEE Std 1609.2™-2016: "IEEE Standard for Wireless Access in Vehicular Environments -
Security Services for Applications and Management Messages", as amended by IEEE
Std 1609.2a™-2017 and EEE Std 1609.2b™-2019.
[3] ETSI TS 102 941 (V1.4.1): "Intelligent Transport Systems (ITS); Security; Trust and Privacy
Management".
[4] Certificate Policy for Deployment and Operation of European Cooperative Intelligent Transport
Systems (C-ITS), (Release 1.1).
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] ETSI TS 102 940 (V1.3.1): "Intelligent Transport Systems (ITS); Security; ITS communications
security architecture and security management".
[i.2] ISO/IEC 15408-2: "Information technology - Security techniques - Evaluation criteria for IT
security; Part 2: Security functional components".
[i.3] ETSI TR 103 415 (V1.1.1): "Intelligent Transport Systems (ITS); Security; Pre-standardization
study on pseudonym change management".
[i.4] ETSI TS 102 731 (V1.1.1): "Intelligent Transport Systems (ITS); Security; Security Services and
Architecture".
ETSI
7 ETSI TS 103 600 V1.2.1 (2022-02)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the terms given in ETSI TS 103 097 [1], ETSI TS 102 940 [i.1],
ETSI TS 102 941 [3], ISO/IEC 15408-2 [i.2] and the following apply:
current CA: CA possessing the certificate containing in the trusted chain for at least one of certificate currently used by
the SUT
foreign CA: any CAs possessing the certificate, been never used in the trusted chain for any end entity certificates used
by the SUT
3.2 Symbols
For the purposes of the present document, the symbols given in ETSI TS 103 097 [1], ETSI TS 102 940 [i.1], ETSI
TS 102 941 [3], ISO/IEC 15408-2 [i.2] apply.
3.3 Abbreviations
For the purposes of the present document, the abbreviations given in ETSI TS 103 097 [1], ETSI TS 102 941 [3], ETSI
TS 102 940 [i.1], ISO/IEC 15408-2 [i.2] apply.
4 Requirements and configuration
4.1 Requirements
4.1.1 Overview
Clauses 4.1.2, 4.1.3 and 4.1.4 define mandatory and optional requirements for the implementation of ITS station, PKI or
TLM. All EUT shall support mandatory requirements. Essential optional requirements defined in clause 5 and in
use-case descriptions.
NOTE: Interoperability testing between two IUTs cover mandatory requirements and optional requirements
supported by the IUTs.
4.1.2 ITS stations
Mandatory requirements:
• The ITS-S shall support data communication using security mechanisms described in ETSI TS 103 097 [1] and
PKI communication described in ETSI TS 102 941 [3].
• The ITS-S shall support algorithms and key length according to the Certificate Policy [4].
• In order to participate in secured communication tests, the ITS-S shall be able to send CAMs and DENMs
using V2X communication.
ETSI
8 ETSI TS 103 600 V1.2.1 (2022-02)
Optional requirements:
PICS Description
PICS_ITSS_REGION_SUPPORT The ITS-S supports region validity restrictions in AT certificates. The
ITS-S shall support at least Circular and Identified region types in order
to participate to use-cases dependent of the present PICS value. See
IEEE Std 1609.2 [2], clause 6.4.17.
PICS_ITSS_REQUEST_AA ITS-S is able to request unknown AA certificate using peer-2-peer
certificate distribution mechanism without infrastructure involved.
PICS_ITSS_RESPOND_AA ITS-S is able to answer for the request for unknown AA certificate using
peer-2-peer certificate distribution mechanism without infrastructure
involved.
PICS_ECTL_SUPPORT ITS-S can handle information provided in ECTL.
PICS_CRL_SUPPORT_CURRENT ITS-S can handle information provided in CRL of the currently active
RootCA.
PICS_CRL_SUPPORT_FOREIGN ITS-S can handle information provided in CRL from other RootCAs.
PICS_CTL_SUPPORT ITS-S can handle information provided in CTL.
PICS_ITSS_PKI_COMMUNICATION ITS-S supports the PKI communication protocol (ETSI TS 102 941 [3]).
Otherwise, the ITS-S is unable to participate in PKI test scenarios
(clause 6.3).
PICS_ITSS_PKI_ENROLMENT ITS-S supports the enrolment procedure described in PKI
communication protocol (ETSI TS 102 941 [3]). Otherwise, the EC
certificate shall be installed on the ITS-S manually.
PICS_ITSS_PKI_RE_ENROLMENT ITS-S supports the re-enrolment procedure described in PKI
communication protocol (ETSI TS 102 941 [3]).

4.1.3 PKI
Mandatory requirements:
• The CAs (RCA, EA, AA) shall support algorithms and key length according to the Certificate Policy [4].
Optional requirements:
PICS Description
PICS_PKI_ITSS_NO_PRIVACY_REQ ITS-S supports optional privacy requirement, e.g. RSU. The present
PICS does not apply to most vehicular ITS-S.
PICS_PKI_ITSS_RENEW_AT ITS-S is able to start the AT renewal procedure when all ATs in the
pool are expired or about to be expired.
PICS_PKI_CA_MANAGEMENT The CA (EA, AA) supports CA certificate request procedure.
The RootCA supports certificate generation base on CA certificate
request procedure.
4.1.4 TLM
Mandatory requirements:
• The TLM shall support algorithms and key length according to the Certificate Policy [4].
4.2 Configurations
4.2.1 CFG_SEC - ITS-S secured communication
This clause describes the configuration used to execute secure communication test scenarios. The configuration contains
the following entities:
• Sender - The ITS-S playing a sender role.
• Receiver - The ITS-S playing a receiver role.
• Sender AA - The authorization authority that issued the sender's AT.
ETSI
9 ETSI TS 103 600 V1.2.1 (2022-02)
• Receiver AA - The authorization authority that issued the receiver's AT.
NOTE: The AA is involved to pre-test conditions only. The way how ATs are installed on the SUT are out of
scope of this configuration. The same AA can issue ATs for both sender and receiver if not defined
otherwise in the use-case description.
In order to participate in the test with the present configuration, ITS-S shall be configured as following if it is not
explicitly defined in the use-case description:
• The ITS-S shall be configured to send CAMs in high frequency (more than one CAMs/second) so that the
ITS-S sends some of the CAMs with digest instead of ATs.
• All participating ITS-Ss are in the "authorized" state (equipped with valid ATs).
• All ATs of participating ITS-Ss allow the transmission of CAMs and DENMs in the time and place of UC
execution.
• All ATs of participating ITS-Ss shall be signed using a valid AA certificate issued by a trusted root certificate
authority (RCA).
• All AA certificates used for signing ATs participating ITS-Ss shall be valid for the time and location of the UC
execution.
• All RCA certificates used for signing AA certificates shall be valid for the time and location of the UC
execution.
• All AA and RCA certificates shall permit issuing of AT certificates containing CAM and DENM PSID.
• No EA, AA or RCA certificates shall be revoked.
• All RCA certificates shall be included in the ECTL.
• All involved CA certificates shall be known and trusted by all participating ITS-S.
4.2.2 CFG_PKI - PKI communication
This clause describes the configuration used to execute PKI communication scenarios. The configuration contains the
following entities:
• ITS-S - the ITS station triggering the scenario execution.
• EA - enrolment authority by which the ITS-S is enrolled.
• AA - authorization authority by which the ITS-S is authorized.
• RCA - root certificate authority issuing the EA and AA certificates.
• DC - distribution centres to provide RCA CTL and CRL.
• TLM/CPOC - trust list manager and central point of contacts.
• Observer - the ITS-S (or a network sniffer) allowing to detect that ITS-S is starting to send CAM messages.
NOTE 1: The RCA can be the issuer of both EA and AA.
The ITS-S shall be configured as following if another is not specified in the use-case description:
• The ITS-S shall be configured to send and receive CAMs using V2X communication.
• The ITS-S shall support the PKI communication protocol (see PICS_PKI_COMMUNICATION) defined in
ETSI TS 102 941 [3].
The CAs (RCA, AA and EA) shall be configured as following if another is not specified in the use-case description:
• All participating RCA shall have RCA certificates included in the ECTL.
ETSI
10 ETSI TS 103 600 V1.2.1 (2022-02)
• All AA and EA shall have CA certificates signed by trusted RCA certificate.
• All CA certificates shall be valid for the time and location of the UC execution.
• All CA certificates shall permit issuing of certificates containing CAM and DENM PSID.
• No EA, AA or RCA certificates shall be revoked.
• All sub-CAs certificates shall be included in the CTL.
The TLM/CPOC shall be configured as following:
• TLM shall issue the ECTL containing all participating RCA.
The above configurations can be organized into three groups depending on the participants involved:
Configuration group Participants involved
CFG_PKI_ENROLMENT ITS-S, EA, Observer, [DC, TLM/CPOC]
CFG_PKI_AUTHORIZATION ITS-S, EA, AA, Observer, [DC, TLM/CPOC]
CFG_PKI_CAs EA, AA, RCA, [DC, TLM/CPOC]

NOTE 2: Connections to DCs and TLM/CPOC are optional in the scope of these tests. Information from ECTL and
CTLs/CRLs can be delivered to participating devices using some other particular way.
5 Requirements to be tested
5.1 Overview
The clauses below collect and enumerate the requirements that can be tested with the present interoperability test
specification.
5.2 ITS-S communication messages
NN Requirement References UCs
A sending ITS-S shall be able to correctly sign CAMs using ETSI TS 102 941 [3] UC-1-1
1.1.
valid AT certificates UC-1-2
UC-1-3
UC-1-4
UC-1-5
UC-2-4
UC-2-5
A receiving ITS-S shall be able to verify CAMs signed using ETSI TS 102 941 [3] UC-1-1
1.2.
valid AT certificates UC-1-2
UC-1-3
UC-1-4
UC-1-5
ITS-S shall be able to correctly handle (send and receive) ETSI TS 102 941 [3] UC-1-1
1.3.
CAMs signed with digests before and after transmission of the UC-1-2
AT certificate UC-1-3
UC-1-4
UC-1-5
ITS-S shall be able to check the timestamp of messages ETSI TS 102 941 [3] UC-1-1
1.4.
including the validity period of the used ATs UC-1-2
UC-1-3
UC-1-4
UC-1-5
UC-2-2
UC-2-4
UC-2-5
ETSI
11 ETSI TS 103 600 V1.2.1 (2022-02)
NN Requirement References UCs
ITS-S shall be able to support peer-2-peer AA certificate ETSI TS 102 941 [3] UC-1-3
1.5.
distribution: UC-2-5
IEEE 1609.2a [2],
• P2P request of AA certificate
clause 8
• P2P distribution of the requested AA certificate
• Accepting of AA certificate received using P2P
distribution
ITS-Ss shall not transmit certificates using P2P distribution if ETSI TS 102 941 [3] UC-1-3
1.6.
another ITS-S already answered the request (discoverable by UC-2-5
IEEE 1609.2a [2],
the sender)
clause 8
ITS-Ss shall be able to handle and verify DENMs signed with ETSI TS 102 941 [3] UC-2-1
1.7.
ATs containing certificate regional restrictions: id and circular
ITS-Ss shall consider PSIDs and correspondent SSPs ETSI TS 102 941 [3] UC-1-1
1.8.
UC-1-2
UC-1-3
UC-1-4
UC-1-5
UC-2-2
UC-2-5
The ITS-S shall support algorithms and key length according to EU CP [4], clause 6.1.4 UC-1-1
1.9.
the EU Certificate Policy. This includes signing, verification, UC-1-2
encryption and decryption UC-1-3
UC-1-4
UC-1-5
UC-2-4
UC-2-5
ITS-Ss shall consider CRLs ETSI TS 102 941 [3] UC-2-4
1.10.
ITS-Ss shall consider the whole certificate chain when verifying ETSI TS 102 941 [3] UC-1-3
1.11.
certificates UC-2-5
Correct change of pseudonyms, with respect to procedure, ETSI TR 103 415 [i.3] UC-1-5
1.12.
parameters, place and time Table 4, EC CP/SP

5.3 ECTL Handling
NN Requirement References UCs
Check the existence of the ECTL ETSI TS 102 941 [3] UC-1-4
2.1.
EU Certificate Policy [4] UC-2-5
UC-2-3
Check the expiration of the ECTL ETSI TS 102 941 [3] UC-1-4
2.2.
EU Certificate Policy [4] UC-2-5
UC-2-3
Check the delta ECTL handling ETSI TS 102 941 [3]
2.3.
EU Certificate Policy [4]
Check the presence of the current root CA certificate in the ETSI TS 102 941 [3] UC-1-4
2.4.
ECTL EU Certificate Policy [4] UC-2-5
UC-2-3
Check the presence of foreign root CA certificate in the ECTL ETSI TS 102 941 [3] UC-1-4
2.5.
EU Certificate Policy [4] UC-2-5
UC-2-3
Handling ECTL signed using Brainpool P384r1 curve ETSI TS 102 941 [3] UC-1-4
2.6.
EU Certificate Policy [4], UC-2-5
clause 6.1.4 UC-2-3
NOTE: The meaning of current and foreign CA is defined in clause 3.1.

ETSI
12 ETSI TS 103 600 V1.2.1 (2022-02)
5.4 RCA CTL Handling
NN Requirement References UCs
The ITS-S checks the RCA CTL for the Access Point of the EA ETSI TS 102 941 [3] UC-3-1
3.1.
UC-3-2
UC-3-3
UC-3-4
Handling CTL signed using any present crypto domain ETSI TS 102 941 [3] UC-3-1
3.2.
(NIST-P256, Brainpool P256r1, Brainpool P384r1) UC-3-2
UC-3-3
UC-3-4
UC-4-1
UC-4-2
UC-4-3
UC-4-4
UC-4-5
Check the RCA CTL for the Access Point of the AA ETSI TS 102 941 [3] UC-4-1
3.3.
UC-4-2
UC-4-3
UC-4-4
UC-4-5
5.5 RCA CRL Handling
NN Requirement References UCs
Check the presence of the CRL from the current root CA ETSI TS 102 941 [3] UC-3-4
4.1.
UC-4-4
Check the presence of the CRL from the foreign root CA ETSI TS 102 941 [3] UC-1-4
4.2.
(different RCA case) UC-3-4
UC-4-4
Check the presence of the currently used AA certificate in the ETSI TS 102 941 [3] UC-4-4
4.3.
CRL from the current root CA
Check the presence of the AA from remote ITS-S in the CRL of UC-4-4
4.4.
foreign root CA
Check the expiration of CRLs of current and foreign root CA
4.5.
Check the presence of the current EA in the CRL of the EA's UC-3-4
4.6.
RCA
Handling CRL signed using any present crypto domain ETSI TS 102 941 [3] UC-1-4
4.7.
(NIST-P256, Brainpool P256r1, Brainpool 384r1) UC-3-4
UC-4-4
5.6 PKI communication - Enrolment Management
NN Requirement References UCs
The EA shall be able to track the ITS-S lifecycle ETSI TS 102 941 [3]
5.1.
The EA shall be able to verify the presence of the ITS-S technical ETSI TS 102 941 [3] UC-3-1
5.2.
key in the local database UC-3-2
The EA shall be able to handle a correct Enrolment Request ETSI TS 102 941 [3] UC-3-1
5.3.
(valid enrolment behaviour) UC-3-2
The EA shall be able to handle an incorrect Enrolment Request ETSI TS 102 941 [3] UC-3-3
5.4.
(Canonical identity unknown - User not permitted to enrol - User ETSI TS 102 731 [i.4]
authentication failed)
The ITS-S is able to handle the CTL EA parameters in order to ETSI TS 102 941 [3] UC-3-1
5.5.
send requests to the itsAccessPoint URL if it is defined in the CTL UC-3-2
The ITS-S shall be able to do an initial Enrolment Request at the ETSI TS 102 941 [3]
5.6.
initialization of the ITS-S or after expiration of the previous EC
The ITS-S shall be able to do a Re-enrolment Request using its ETSI TS 102 941 [3]; UC-3-2
5.7.
current EC EU Certificate Policy [4]
clause 7.2, Table 11
ETSI
13 ETSI TS 103 600 V1.2.1 (2022-02)
5.7 PKI communication - Authorization Management
NN Requirement References UCs
The AA shall be able to handle the authorization request sent ETSI TS 102 941 [3] UC-4-1
6.1.
by an ITS-S UC-4-2
UC-4-3
UC-4-5
The AA shall only accept authorization requests with pop ETSI TS 102 941 [3] UC-4-1
6.2.
(proof of possession) signature in case of ITS-S with privacy UC-4-3
requirements UC-4-5
The AA shall be able to build and send the authorization ETSI TS 102 941 [3] UC-4-1
6.3.
validation request to the EA UC-4-2
UC-4-3
UC-4-5
The EA shall be able to validate the authorization validation ETSI TS 102 941 [3] UC-4-1
6.4.
request received from the AA: UC-4-2
• Accept successful authorization validation request UC-4-3
UC-4-5
• Check that encrypted signature is used for AT
requests from ITS-S with privacy requirements
• Check the desired subject attributes in the certificate
request
• Check and update if necessary the validation period
for the certificate
The EA shall be able to build and send an authorization ETSI TS 102 941 [3] UC-4-1
6.5.
validation response to the AA UC-4-2
UC-4-3
UC-4-5
The AA shall be able to build and send an authorization ETSI TS 102 941 [3] UC-4-1
6.6.
response to the ITS-S UC-4-2
UC-4-3
UC-4-5
The authorization response sent by AA shall follow the ETSI TS 102 941 [3] UC-4-1
6.7.
decision of the EA with respect to the authorization validation UC-4-2
response UC-4-3
UC-4-5
The ITS-S shall be able to build and send the authorization ETSI TS 102 941 [3] UC-4-1
6.8.
request UC-4-2
UC-4-3
UC-4-5
The ITS-S shall be able to build and send the authorization ETSI TS 102 941 [3] UC-4-1 (optional)
6.9.
request containing region restriction certificate attribute UC-4-2 (optional)
UC-4-3 (optional)
UC-4-5 (optional)
The ITS-S shall be able to request several authorization ETSI TS 102 941 [3] UC-4-5
6.10.
tickets
The AA shall accept authorization requests without encrypted ETSI TS 102 941 [3] UC-4-2
6.11.
EC signature in case of ITS-S without privacy requirements

5.8 PKI interoperability
NN Requirement References UCs
7.1. AA shall be able to communicate with EAs belonging to ETSI TS 102 941 [3] UC-4-3
different RCAs when their corresponding Root CAs are
trusted by ECTL and AA and EA both know the certificates
and access points of each other.
7.2. If the EA has two Access Points in the CTL, the AA shall ETSI TS 102 941 [3] UC-4-1
choose the aaAccessPoint for its authorization validation UC-4-2
request.
ETSI
14 ETSI TS 103 600 V1.2.1 (2022-02)
6 Interoperability test descriptions
6.1 Overview
Interoperability test descriptions consist of three groups:
• ITS-S secured communication
• PKI communication
• CA certificate requests
These groups are described in the clauses below.
6.2 ITS-S secured communication
6.2.1 Successful basic communication
6.2.1.1 Use-case 1-1 - Both ITS-S authorized by the same AA
Interoperability Test Description
Identifier TD_ITS_SEC_UC1-1
Objective Secure communication between ITS-S authorized by the same AA
Description Two ITS-S, authorized by the same AA, are sending CAMs and both accept these CAMs
Configuration The CFG_SEC configuration shall be used with additional requirements:
• The ATs of all participating ITS-S are issued by the same AA

Pre-test
conditions
REQ / PICS Tested Requirements PICS
1.1, 1.2, 1.3, 1.4, 1.8, 1.9
Step Type Description Result
1 Stimulus The sender is triggered to send valid CAMs
(by Sender)
2 Verify The receiver validates received CAMs All received CAMs are accepted
(by Receiver) by the receiving ITS-S
ETSI
15 ETSI TS 103 600 V1.2.1 (2022-02)
RCA 1
AA 1a
ATs
ATs
CAM
Sender: ITS-S Receiver: ITS-S
Trusted AAs: 1a Trusted AAs: 1a
Trusted RCA: 1 Trusted RCA: 1
Figure 1: Secured communication when both ITS-S authorized by the same AA
6.2.1.2 Use-case 1-2 - Different AAs of the same PKI
Interoperability Test Description
Identifier TD_ITS_SEC_UC1-2
Objective Secure communication between ITS-S authorized by different but commonly trusted AAs
Description Two ITS-S, authorized by different AA (belonging to the same RCA), are sending CAMs and
both accept these CAMs
Configuration The CFG_SEC configuration shall be used with additional requirements:
• Sender and receiver are authorized with ATs issued by different AAs belonging to the
same RCA.
Pre-test
conditions
REQ / PICS Tested Requirements PICS
1.1, 1.2, 1.3, 1.4, 1.8, 1.9
Step Type Description Result
1 Stimulus The sender is triggered to send valid CAMs
(by Sender)
2 Verify The receiver validates the CAMs All received CAMs are accepted by
(by Receiver) the receiving ITS-S

ETSI
16 ETSI TS 103 600 V1.2.1 (2022-02)
RCA 1
AA 1a
AA 1b
ATs
ATs
CAM
Sender: ITS-S Receiver: ITS-S
Trusted AAs: 1a,1b Trusted AAs: 1a,1b
Trusted RCAs: 1 Trusted RCAs: 1

Figure 2: Secured communication when ITS-Ss was authorized by the different AAs of the same PKI
6.2.1.3 Use-case 1-3 - Peer-to-peer distribution of AA certificate
Interoperability Test Description
Identifier TD_ITS_SEC_UC1-3
Objective Secure communication between ITS-S authorized by different and initially partially unknown
AAs
Description Two ITS-S, authorized by different AA, are sending CAMs. The AA authorizing the sender is
initially unknown from the receiver's perspective. The receiver therefore needs to request the AA
certificate before trusting the received CAMs
Configuration The CFG_SEC configuration shall be used with the following additions:
• The ATs of the participating ITS-S are issued by different AAs.
• Both AA certificates are issued by the same commonly trusted RCA.
• The AA authorizing the sender is initially unknown from the receiver's perspective.
• The AA authorizing the receiver is known from the sender's perspective.

Pre-test • Ensure that no other ITS-S (beside the sender) in the surrounding will answered the
conditions
AA certificate request (see note).
REQ / PICS Tested Requirements PICS
1.1, 1.2, 1.4, 1.5, Receiver: PICS_ITSS_REQUEST_AA
1.6 (see note), Sender: PICS_ITSS_RESPOND_AA
1.8, 1.9, 1.11
ETSI
17 ETSI TS 103 600 V1.2.1 (2022-02)
Interoperability Test Description
Step Type Description Result
1 Stimulus
• The sender is triggered to send valid CAMs.
(by Sender)
2 Verify The receiver validates the CAMs of
• The CAM is not accepted
(by Receiver) the sender by the receiving ITS-S (yet)
because of the inability to
verify the certificate chain of
the signer due to the
missing AA certificate.
3 Action
• The receiver is adding a request for the missing AA certificate to its
(by Receiver) next CAM.
4 Verify The sender validates the CAMs of
• The CAM containing the
(by Sender) the receiver request for the AA
certificate is accepted by
the receiving ITS-S.
5 Action • The sender is appending the AA certificate to its next CAM.
(by Sender)
6 Verify The receiver validates the CAM of • The CAM is accepted by the
(by Receiver) the sender containing the appended
receiving ITS-S (which is
AA certificate now able to verify the
certificate chain).
NOTE: Depending on the circumstances of the test setup there might be multiple ITS-S listening to the
channel and reacting on AA certificate requests. As the sender's devices will not append the AA
certificate if another ITS-S already answered the request, the pre-condition needs to be fulfilled in
order to complete the test sequence of the use case.

RCA 1
AA 1a AA 1b
ATs
ATs
CAM
Sender: ITS-S Receiver: ITS-S
Trusted AAs: 1a,1b Trusted AAs: 1b
Trusted RCAs: 1 Trusted RCAs: 1

Figure 3: Peer-to-peer certificate distribution
ETSI
18 ETSI TS 103 600 V1.2.1 (2022-02)
6.2.1.4 Use-case 1-4 - Participating ITS-S are registered in different RCAs
Interoperability Test Description
Identifier TD_ITS_SEC_UC1-4
Objective Secure communication between ITS-S authorized by AAs of different RCAs
Description Two ITS-S, authorized by AAs belonging to different RCAs, are sending CAMs and both accept
these CAMs
Configuration The CFG_SEC configuration shall be used with the following additions:
• The ATs of the participating ITS-S are issued by different AAs.
• The sender AA certificate and the receiver AA certificate are issued by different, but
commonly known and trusted RCAs.

Pre-test
conditions
REQ / PICS Tested Requirements PICS
1.1, 1.2, 1.3, 1.4, 1.8, 1.9, 2.1,
2.2, 2.4, 2.5, 2.6
Step Type Description Result
1 Stimulus • The sender is triggered to send valid CAMs.
(by Sender)
2 Verify The receiver validates the CAMs
• The CAM is accepted by the
(by Receiver)
receiving ITS-S.
RCA 1
RCA 2
AA 2a
AA 1a
ATs
ATs
CAM
Sender: ITS-S
Receiver: ITS-S
Trusted AAs: 1a,2a
Trusted AAs: 1a,2b
Trusted RCAs: 1,2
Trusted RCAs: 1,2
Figure 4: Secured communication using certificates from different PKIs
ETSI
19 ETSI TS 103 600 V1.2.1 (2022-02)
6.2.1.5 Use-case 1-5 - Pseudonym changing
Interoperability Test Description
Identifier TD_ITS_SEC_UC1-5
Objective ITS-S are changing the ATs and related identifiers (pseudonym change) as expected
Description Two ITS-S, authorized by the same AA, are sending CAMs and both accept these CAMs. The
two ITS-Stations are running the same GNSS simulation. The ITS-S shall perform pseudonym
changes according to the EC CP/SP strategy. See ETSI TR 103 415 [i.3], Table 4
Configuration The CFG_SEC configuration shall be used with the following additions:
• The ATs of all participating ITS-S are issued by the same AA.
• The ITS-S are configured to use the GNSS simulation correspondent to selected
certificate changing strategy.

Pre-test Both GNSS simulations, of sender and receiver, shall be set to the same starting point. It
conditions needs to be ensured that both ITS-Ss stay within communication range throughout the test
REQ / PICS Tested Requirements PICS
1.1, 1.2, 1.3, 1.4, 1.8, 1.9,
1.11, 1.12
Step Type Description Result
1 Stimulus
• The sender is triggered to send valid CAMs.
(by Sender)
• The GNSS simulation is started.
Stimulus • The GNSS simulation is started (about the same time as the
(by Receiver) sender's simulation).
2 Verify The receiver validates the CAMs
• The CAMs are accepted by
(by Receiver) throughout the whole GNSS the receiving ITS-S
simulation
Action The sender will perform pseudonym changes according to the change
(by Sender) strategy
Verify The receiver identifies
• Pseudonym changes of the
(by Receiver) pseudonym changes OR the
sender are identified.
receiver identifies the
• The pseudonym changes
disappearance of the old sender
happen according to the
and the subsequent appearance
expected change strategy
of a new sender
(e.g. within the expected
time frame and section of
the GNSS trace).
ETSI
20 ETSI TS 103 600 V1.2.1 (2022-02)
RCA 1
AA 1a
ATs
ATs
CAM
Receiver: ITS-S
Sender: ITS-S
Trusted AAs: 1a Trusted AAs: 1a
Trusted RCAs: 1
Trusted RCAs: 1
Start AT1 AT2 AT3 AT …
Time // Distance
Figure 5: Pseudonym changing
6.2.2 Exceptional behaviour basic communication
6.2.2.1 Use-case 2-1 - Invalid certificate region
Interoperability Test Description
Identifier TD_ITS_SEC_UC2-1
Objective No communication between ITS-S within unauthorized regions
Description The sending ITS-S is triggered to send DENMs. The regional restrictions of the available ATs do
not include the pla
...