ETSI TS 103 096-2 V1.1.1 (2013-07)
Intelligent Transport Systems (ITS); Testing; Conformance test specification for TS 102 867 and TS 102 941; Part 2: Test Suite Structure and Test Purposes (TSS&TP)
Intelligent Transport Systems (ITS); Testing; Conformance test specification for TS 102 867 and TS 102 941; Part 2: Test Suite Structure and Test Purposes (TSS&TP)
DTS/ITS-0050019
General Information
Standards Content (Sample)
Technical Specification
Intelligent Transport Systems (ITS);
Testing;
Conformance test specification for TS 102 867 and TS 102 941;
Part 2: Test Suite Structure and Test Purposes (TSS&TP)
2 ETSI TS 103 096-2 V1.1.1 (2013-07)
Reference
DTS/ITS-0050019
Keywords
ITS, testing, TSS&TP
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 096-2 V1.1.1 (2013-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 7
3 Definitions and abbreviations . 7
3.1 Definitions . 7
3.2 Abbreviations . 7
4 Prerequisites and Test Configurations . 7
4.1 Test Configurations . 7
4.2 PKI Hierarchy . 9
4.3 Feature Restriction and Pre-Enrolment . 10
4.3.1 Feature Restriction . 10
4.3.2 Pre-Enrolment . 11
4.4 States in Initial Conditions . 12
4.4.1 ITS-S send side states . 12
4.4.2 ITS-S receive side states . 12
4.4.3 EA states . 12
4.4.4 AA states . 12
4.5 Validity of Signed Communication . 12
4.6 Introduction of Snippets of Data Structures . 12
4.7 Variants, Variables and Snippet Naming Convention . 13
5 Test Suite Structure (TSS) . 13
5.1 Structure for Security tests . 13
5.2 Test groups . 14
5.2.1 Root . 14
5.2.2 Groups . 14
5.2.3 Sub groups . 14
5.2.4 Categories . 14
6 Test Purposes (TP) . 14
6.1 Introduction . 14
6.1.1 TP definition conventions . 14
6.1.2 TP Identifier naming conventions . 15
6.1.3 Rules for the behaviour description . 15
6.1.4 Sources of TP definitions . 15
6.1.5 Mnemonics for PICS reference . 15
6.1.6 Message encapsulation . 17
6.1.7 Used constants . 18
6.1.8 Snippets definitions. 19
6.1.8.1 Regions . 19
6.1.8.2 Certificates . 19
6.1.8.2.1 Authorities certificates . 19
6.1.8.2.2 End-Entities certifica tes . 22
6.1.8.3 Messages . 25
6.1.8.3.1 ITS station testing . 25
6.1.8.3.2 Enrolment Authority testing . 28
6.1.8.3.3 Authorization Authority testing . 29
6.2 Test purposes for SECURITY . 31
6.2.1 ITS Station . 31
6.2.1.1 Enrolment . 31
6.2.1.1.1 Normal Behaviour . 31
6.2.1.1.2 Exceptional Behavior . 40
ETSI
4 ETSI TS 103 096-2 V1.1.1 (2013-07)
6.2.1.2 Authorization . 47
6.2.1.2.1 Normal Behavior . 47
6.2.1.2.2 Exceptional Behavior . 54
6.2.1.3 Sending Data . 66
6.2.1.4 Receiving Data . 73
6.2.1.4.1 Normal Behavior . 73
6.2.1.4.2 Exceptional behavior . 77
6.2.2 Certificate Authority . 91
6.2.2.1 Normal Behavior . 91
6.2.2.1.1 Generic message verification . 91
6.2.2.1.2 Key Compression . 94
6.2.2.1.3 Permissions . 95
6.2.2.1.4 Expiration . 97
6.2.2.1.5 Regions . 99
6.2.2.2 Exceptional Behavior . 100
6.2.2.2.1 Invalid Message Fields . 100
6.2.2.2.2 Invalid Certificate or Certificate Chain . 103
6.2.2.2.3 Invalid Certificate Fields . 107
6.2.2.2.4 Invalid Permissions . 110
6.2.2.2.5 Invalid Regions . 113
6.2.2.2.6 Expiration . 114
6.2.3 Enrolment Authority . 116
6.2.3.1 Normal Behavior . 116
6.2.3.2 Exceptional Behavior . 116
6.2.4 Authorization Authority . 118
6.2.4.1 Normal Behavior . 118
6.2.4.1.1 Scopes (Scope Kind and Scope Name) . 118
6.2.4.1.2 Expiration . 120
6.2.4.2 Exceptional Behavior . 121
6.2.4.2.1 Invalid Certificates or Certificate Chain Fields . 121
6.2.4.2.2 Invalid Scopes (Subject Type and Scope Name) . 122
History . 123
ETSI
5 ETSI TS 103 096-2 V1.1.1 (2013-07)
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).
The present document is part 2 of a multi-part deliverable covering Conformance test specification for ITS Security as
identified below:
TS 103 096-1: "Protocol Implementation Conformance Statement (PICS)";
TS 103 096-2: "Test Suite Structure and Test Purposes (TSS&TP)";
TS 103 096-3: "Abstract Test Suite (ATS) and Protocol Implementation eXtra Information for Testing (PIXIT)";
TR 103 096-4: "Validation report".
ETSI
6 ETSI TS 103 096-2 V1.1.1 (2013-07)
1 Scope
The present document provides the Test Suite Structure and Test Purposes (TSS&TP) for Security as defined in
IEEE P 1609.2 [1], TS 102 941 [2] and TS 102 867 [3] in compliance with the relevant requirements and in accordance
with the relevant guidance given in ISO/IEC 9646-7 [9].
The ISO standard for the methodology of conformance testing (ISO/IEC 9646-1 [6] and ISO/IEC 9646-2 [7]) as well as
the ETSI rules for conformance testing (ETS 300 406 [10]) are used as a basis for the test methodology.
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
reference document (including any amendments) applies.
Referenced documents which are not found to be publicly available in the expected location might be found at
http://docbox.etsi.org/Reference.
NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee
their long term validity.
2.1 Normative references
The following referenced documents are necessary for the application of the present document.
[1] IEEE P1609.2/D12 (January 2012): "IEEE Draft Standard for Wireless Access in Vehicular
Environments - Security Services for Applications and Management Messages.
[2] ETSI TS 102 941: "Intelligent Transport Systems (ITS); Security; Trust and Privacy
Management".
[3] ETSI TS 102 867: "Intelligent Transport Systems (ITS); Security; Stage 3 mapping for
IEEE 1609.2".
[4] ETSI TS 103 096-1 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for TS 102 867 and TS 102 941; Part 1: Protocol Implementation Conformance
Statement (PICS)".
[5] ETSI TS 103 096-3 (V1.1.1): "Intelligent Transport Systems (ITS); Testing; Conformance test
specification for TS 102 867 and TS 102 941; Part 3: Abstract Test Suite (ATS) and Protocol
Implementation eXtra Information for Testing (PIXIT)".
[6] ISO/IEC 9646-1 (1994): "Information technology -- Open Systems Interconnection --
Conformance testing methodology and framework -- Part 1: General concepts".
[7] ISO/IEC 9646-2 (1994): "Information technology -- Open Systems Interconnection --
Conformance testing methodology and framework -- Part 2: Abstract Test Suite specification".
[8] ISO/IEC 9646-6 (1994): "Information technology -- Open Systems Interconnection --
Conformance testing methodology and framework -- Part 6: Protocol profile test specification".
[9] ISO/IEC 9646-7 (1995): "Information technology -- Open Systems Interconnection --
Conformance testing methodology and framework -- Part 7: Implementation Conformance
Statements".
[10] ETSI ETS 300 406 (1995): "Methods for testing and Specification (MTS); Protocol and profile
conformance testing specifications; Standardization methodology".
ETSI
7 ETSI TS 103 096-2 V1.1.1 (2013-07)
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] ETSI EG 202 798: "Intelligent Transport Systems (ITS); Testing; Framework for conformance and
interoperability testing".
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the following terms and definitions apply:
• terms given in IEEE 1609.2 [1], TS 102 941 [2] and in TS 102 867 [3];
• terms given in ISO/IEC 9646-6 [8] and in ISO/IEC 9646-7 [9].
3.2 Abbreviations
For the purposes of the present document, the following abbreviations apply:
AA Authorization Authority
BV Normal behaviour
CA Certification Authority
CAM Cooperative Awareness Message
CRL Certificate Revocation List
CSR Certificate Signing Request
DENM Decentralized Environmental Notification Message
EA Enrolment Authority
EB Exceptional Behavior
ITS Intelligent Transport System
ITS-AID ITS Application ID
ITS-S ITS Station
IUT Implementation Under Test
MSEC Multicast Security
PKI Public Key Infrastructure
PSID Provider Service Identifier
SA Security Association
SSP Service Specific Permissions
TLS Transport Layer Security
TP Test Purposes
TSS Test Suite Structure
4 Prerequisites and Test Configurations
4.1 Test Configurations
The test configuration 1 as shown in figure 1 is applied for the test group of CA and EA tests.
ETSI
8 ETSI TS 103 096-2 V1.1.1 (2013-07)
Figure 1: Test Configuration 1
The test configuration 2 as shown in figure 2 is applied for the test group of CA and AA tests.
Figure 2: Test Configuration 2
The test configuration 3 as shown in figure 3 is applied for the test group of ITS-S Enrolment and Authorization tests.
EA AA
IUT(=ITS-S)
CF03
Figure 3: Test Configuration 3
The test configuration 4 as shown in figure 4 is applied for the test group of ITS-S Send and Receive Data tests.
ETSI
9 ETSI TS 103 096-2 V1.1.1 (2013-07)
EA AA
ITS-S
IUT(=ITS-S)
CF04
Figure 4: Test Configuration 4
4.2 PKI Hierarchy
The PKI Hierarchy is depicted below. Four different types of certificates are defined. They are listed hereafter.
• CERT_ROOT
• CERT_EA_x
• CERT_AA_x
• CERT_ENR_x
• CERT_AUTH_x
These names are used in the TP definitions, where _x is a placeholder for numbering different certificates.
ETSI
10 ETSI TS 103 096-2 V1.1.1 (2013-07)
Figure 5: PKI Hierarchy
4.3 Feature Restriction and Pre-Enrolment
4.3.1 Feature Restriction
In this clause all feature restrictions are listed:
• Certificate chains where subordinate certificates make use of inherited permissions are not supported
• Only circular regions
ETSI
11 ETSI TS 103 096-2 V1.1.1 (2013-07)
• Only explicit certificates
• Revocation is not tested, i.e. certificate responses contain only empty revocation list
• Update Enrolment Credentials is not tested
• Remove Enrolment Credentials is not tested
• Update Authorization Tickets is not tested
• The name which identifies the CA shall be no longer that 32 bytes
4.3.2 Pre-Enrolment
Enrolment is the process by which an ITS-S obtains an enrolment certificate, which can later be used to authenticate
requests for authorization certificates. An ITS-S undergoes initial enrolment by executing the Enrolment Request
information flow from TS 102 941 [2].
When devices enrol with an Enrolment Authority, they should be authenticated as devices that are entitled to receive
enrolment credentials of the type requested. There are two three different authentication approaches:
• Public key: Enrolment requests are authenticated by using a private key of the ITS-S. The corresponding
public key is previously registered with a unique ITS-S module ID at the EA in a secure process. Every ITS-S
has to be registered separately.
• Certificate: Enrolment requests are authenticated by a certificate or certificate chain.
• Self-signed: Enrolment requests are signed by the public key contained in the enrolment request. In this case
the signature provides proof of possession of the corresponding private key, but does not authenticate that the
private key holder is in fact authorized to receive an enrolment credential of the type requested. This
authorization is provided by other mechanisms.
None of the three authentication approaches start at the device lifecycle: in all cases, there is the question of how the
device is originally shown to be authenticated. The test system supports both the certificate and the self-signed forms of
enrolment request.
For enrolment request:
• The test system enrolment authority shall accept the following forms of authorization, certificate and self-
signed.
• The test system enrolment authority shall check that the signature on the enrolment request is
cryptographically valid.
• In the case of an enrolment request signed by a certificate:
- The test system enrolment authority shall check that the request is consistent with the permissions in the
certificate.
- The test system enrolment authority shall not carry out any other validation on the signing certificate. For
example, it shall not check the signature on the signing certificate, check that the certificate chains back
to a known CA, or check whether the signing certificate is revoked.
The test system enrolment authority shall issue the enrolment certificate if these validity tests pass.
From the perspective of the IUT, this has the following consequences:
• Certificate: The IUT shall be provisioned with a certificate to authenticate enrolment before testing begins (a
pre-enrolment certificate).
- The supplier shall provide instructions as to how to reset the IUT to a state where it has the pre-
enrolment certificate but not the enrolment certificate, to allow the enrolment flow to be run multiple
times.
ETSI
12 ETSI TS 103 096-2 V1.1.1 (2013-07)
- The supplier shall chose between two options:
The test system generates private key and public certificate for the device.
The supplier generates a private key and sends a certificate signing request to the test system.
• Self-signed: The IUT supplier shall provide instructions as to how to set the IUT into a state where it will
request enrolment with a self-signed request.
4.4 States in Initial Conditions
Each TP contains an initial condition. The initial condition defines in which initial state the IUT has to be to apply the
actual TP. In the corresponding Test Case, when the execution of the initial condition does not
succeed, it leads to the assignment of an Inconclusive verdict. This clause defines the different initial states of the IUT.
4.4.1 ITS-S send side states
• Not enrolled state: ITS-S has all info necessary to send an EnrolmentRequest but does not have any Enrolment
credentials yet
• Awaiting EnrolmentResponse state: ITS-S has sent an EnrolmentRequest and is waiting for an
EnrolmentResponse
• Enrolled, but not authorized state: ITS-S has received EnrolmentResponse and is able to send
AuthorizationRequest
• Awaiting AuthorizationResponse state: ITS-S has sent an AuthorizationRequest and is waiting for an
AuthorizationResponse
• Authorized state: ITS-S has received a successful AuthorizationResponse
4.4.2 ITS-S receive side states
• Operational state: ITS-S has the root certificate and is ready to receive messages
4.4.3 EA states
• Operational state: EA has obtained its certificate and is ready to receive and send Enrolment messages
4.4.4 AA states
• Operational state: AA has obtained its certificate and is ready to receive and send Authorization messages
4.5 Validity of Signed Communication
The check of the validity of signed communication according to clause 5.5 of IEEE P1609.2/D12 [1] (e.g. consistency
check of the certificate chain, consistency check between certificate and message etc) forms an integral part of the test
suite and is described in TS 103 096-3 [5], clause 6.
4.6 Introduction of Snippets of Data Structures
The data structures in IEEE P1609.2/D12 [1] can become quite complex. In order to allow to write a TP in a concise
form, the usage of snippets has been introduced. A snippet is a partial extract of a data structure which is assigned with
values. A snippet can be used within a TP. Please refer to clause 6.1.8 for a complete list of all defined snippets.
ETSI
13 ETSI TS 103 096-2 V1.1.1 (2013-07)
Within a TP, any element of the snippet can be overwritten or extended. In the example below the TP extends the
snippet MSG_ENRRSP_TS 'signature.ecdsa_signature' to ' signature.ecdsa_signature.R.type = = uncompressed'.
...
when {
the IUT receives a valid CertificateResponse (EnrolmentResponse) set to MSG_ENRRSP_TS
containing certificate_chain[last].signature.ecdsa_signature.R.type
set to uncompressed
...
4.7 Variants, Variables and Snippet Naming Convention
The TPs use the concept of variants, variables and snippets. Their definition, how they are used and their naming
conventions are defined in this clause.
Variants: In case where for a single field multiple values can be tested (e.g. different public key types), then a table is
appended after the TP. This table lists all the different value which need to be tested. The TP identifier is appended with
–X (e.g. TP/SEC/ITS-S/ENR/NB-02-X). If there are two fields for which multiple values can be tested then X and Y
are appended. The field itself is written as X_FIELD_NAME (e.g. X_PKT_SIGNATURE).
Variables: Variables are used in TPs in order to highlight the fact that a particular part of request message needs to re-
appear in a response message. For example for a TP where the IUT has sent an EnrolementRequest with a permission
list, and the test system needs to sent the same permission list back, then the denotation of V_PERM_LIST (see
TP/SEC/ITS-S/ENR/NB-11)
Snippets: For the definition of snippets refer to the previous clause. The naming convention for snippets is defined to
upper case and to have no specific prefix (e.g. MSG_ENRREQ_IUT). All snippets in TPs contain hyperlinks which
allows to navigate from the TP directly to the snippet definition.
5 Test Suite Structure (TSS)
5.1 Structure for Security tests
Table 1 shows the Test Suite Structure (TSS) including its subgroups defined for conformance testing.
Table 1: TSS for SECURITY
Root Group Group category
SEC CA ENR/AUTH Normal behaviour
Exceptional behaviour
EA ENR Normal behaviour
Exceptional behaviour
AA AUTH Normal behaviour
Exceptional behaviour
ITS-S ENR Normal behaviour
Exceptional behaviour
AUTH Normal behaviour
Exceptional behaviour
S-DATA Normal behaviour
Exceptional behaviour
R-DATA Normal behaviour
Exceptional behaviour
The test suite is structured as a tree with the root defined as SEC. The tree is of rank 3 with the first rank a Group, the
second rank a sub group, and the last rank a category.
ETSI
14 ETSI TS 103 096-2 V1.1.1 (2013-07)
5.2 Test groups
The test suite has a total of four levels. The first level is the root. The second level defines different IUTs. The third
level defines various functional areas. The fourth level differentiates normal and exceptional behaviour.
5.2.1 Root
The root identifies ITS G5A as defined in IEEE 1609.2 [1], TS 102 941 [2] and TS 102 867 [3].
5.2.2 Groups
There are four functional areas identified as groups:
• Certificate Authority
• Enrolment Authority
• Authorization Authority
• ITS Station
5.2.3 Sub groups
There are four functional areas identified as sub-groups:
• Enrolment
• Authorization
• Send Data
• Receive Data
5.2.4 Categories
Test categories are limited to the normal and exceptional behaviour.
6 Test Purposes (TP)
6.1 Introduction
6.1.1 TP definition conventions
The TP definition is constructed according to EG 202 798 [i.1].
ETSI
15 ETSI TS 103 096-2 V1.1.1 (2013-07)
6.1.2 TP Identifier naming conventions
The identifier of the TP is constructed according to table 2.
Table 2: TP naming convention
Identifier: TP_____
= root SEC
= group CA Certificate Authorithy
EA Enrolment Authorithy
AA Authorization Authority
ITS-S ITS Station
=sub-group ENR Enrolment
AUTH Authorization
S-DATA Send Data
R-DATA Receive Data
= type of testing NB Normal Behaviour
EB Exceptional Behaviour
= sequential number 01 to 99
st
= Variant for 1 permutation table A to Z
nd
= Variant for 2 permutation table A to Z
6.1.3 Rules for the behaviour description
The description of the TP is constructed according to EG 202 798 [i.1].
In the TP the following wordings are used:
• "The IUT is requested to send": An upper layer requests the security layer to apply processing to a packet.
• "The IUT receives": for packets coming from the network and given by the lower layer.
• "The IUT is configured to": the Security Layer on the IUT is requested to include a certain data element, e.g.
this can be manually configured or triggered by use of a application that requires this data element.
• "The IUT accepts": the Security Layer on the IUT interprets a received message as passing all the relevant
validity tests, including cryptographic validity, and passes it to a higher layer for interpretation.
• "The IUT discards": the Security Layer on the IUT interprets a received message as failing at least one validity
test and does not pass it to a higher layer (drops a received message).
6.1.4 Sources of TP definitions
All TPs specified in the present document are derived from the behaviour defined in IEEE 1609.2 [1], TS 102 941 [2]
and TS 102 867 [3].
6.1.5 Mnemonics for PICS reference
The following table lists mnemonic names and maps them to the PICS item number.
ETSI
16 ETSI TS 103 096-2 V1.1.1 (2013-07)
Table 3: Mnemonics for PICS reference
Mnemonic PICS item
PIC_Generate_SignPayload [4] Table A.5/1
PIC_Generate_SignExternalPayload [4] Table A.5/2
PIC_Generate_SignPartialPayload [4] Table A.5/3
PIC_Generate_Identified [4] Table A.5/7
PIC_Generate_GenerationTime [4] Table A.5/9
PIC_Generate_GenerationLocation [4] Table A.5/10
PIC_Generate_ExpirationTime [4] Table A.5/11
PIC_Generate_Certificate [4] Table A.5/13
PIC_Generate_Ecdsa224 [4] Table A.5/15
PIC_Generate_Ecdsa256 [4] Table A.5/16
PIC_Generate_ExplicitCertificates [4] Table A.5/17
PIC_Generate_Uncompressed [4] Table A.5/19
PIC_Generate_Compressed [4] Table A.5/20
PIC_Generate_CompressedFastVerification [4] Table A.5/21
PIC_Generate_UncompressedKey PIC_Generate_Uncompressed
PIC_Generate_CompressedKey PIC_Generate_Compressed AND
PIC_Generate_CompressedFastVerification
PIC_Generate_XCoordinateOnlyKey PIC_Generate_Compressed AND NOT
PIC_Generate_CompressedFastVerification
PIC_Generate_SelfSigned [4] Table A.34/2
PIC_Generate_StartValidity [4] Table A.34/16
PIC_Generate_LifetimeIsDuration [4] Table A.34/17
PIC_ Generate_StartValidityIsATimestamp NOT PIC_Generate_LifetimeIsDuration
PIC_Generate_VerificationKey224 [4] Table A.34/19
PIC_Generate_VerificationKey256 [4] Table A.34/20
PIC_Generate_EncryptionKey [4] Table A.34/21
PIC_Generate_PsidArrayWithMoreThan8Entries [4] Table A.37/2
PIC_Verify_Uncompressed [4] Table A.14/17
PIC_Verify_Compressed [4] Table A.14/18
PIC_Verify_CompressedFastVerification [4] Table A.14/19
PIC_Verify_UncompressedKey PIC_Verify_Uncompressed
PIC_Verify_CompressedKey PIC_Verify_Compressed AND
PIC_Verify_CompressedFastVerification
PIC_Verify_XCoordinateOnlyKey PIC_Verify_Compressed AND NOT
PIC_Verify_CompressedFastVerification
PIC_Verify_SelfSigned [4] Table A.35/1
PIC_Verify_StartValidity [4] Table A.41/9
PIC_Verify_LifetimeIsDuration [4] Table A.41/10
PIC_Verify_StartValidityIsATimestamp NOT PIC_Verify_LifetimeIsDuration
PIC_Verify_VerificationKey224 [4] Table A.41/11
PIC_Verify_VerificationKey256 [4] Table A.41/12
PIC_Verify_EncryptionKey [4] Table A.41/13
PIC_Verify_PsidArrayWithMoreThan8Entries [4] Table A.45/2
ETSI
17 ETSI TS 103 096-2 V1.1.1 (2013-07)
6.1.6 Message encapsulation
CertificateRequest message encapsulation
Structure 1609Dot2Data {
containing type
indicating encrypted
containing encrypted_data
containing symm_algorithm set to unknown
containing recipients
containing cert_id
containing enc_key
containing ciphertext
/----------------- After deciphering process ------------------/
/ containing type /
/ set to certificate_request /
/ containing request /
/ containing the CerticateRequest data /
/----------------------------------------------------------------------/
}
NOTE: When a TP refers to a CertificateRequest, then it is assumed that the CertificateRequest is received in a
1609Dot2Data as described above.
CertificateResponse message encapsulation
Structure 1609Dot2Data {
containing type
indicating encrypted
containing encrypted_data
containing symm_algorithm set to unknown
containing recipients
containing cert_id
containing enc_key
containing ciphertext
/---------------------------- After deciphering process ------------------------------/
/ containing type /
/ set to certificate_response /
/ containing request /
/ containing the CerticateResponse data /
/---------------------------------------------------------------------------------------------/
}
NOTE: When a TP refers to a CertificateResponse, then it is assumed that the CertificateResponse is received in a
1609Dot2Data as described above.
CertificateRequestError message encapsulation
Structure 1609Dot2Data {
containing type
indicating encrypted
containing encrypted_data
containing symm_algorithm set to unknown
containing recipients
containing cert_id
containing enc_key
containing ciphertext
/------------------------- After deciphering process ----------------------------/
/ containing type /
/ set to certificate_request_error /
/ containing request /
/ containing the CertificateRequestError data /
/-----------------------------------------------------------------------------------------/
}
NOTE: When a TP refers to a CertificateRequestError, then it is assumed that the CertificateRequestError is
received in a 1609Dot2Data as described above.
ETSI
18 ETSI TS 103 096-2 V1.1.1 (2013-07)
6.1.7 Used constants
NAME Value
CLT Current Local Time
ANY_VALUE_OR_NONE *
ANY_VALUE ?
ANY_SCOPE
anonymous_scope or id_scope or sec_data_exch_ca_scope
ETSI_LAT
ETSI_LON
NICE_LAT
NICE_LON
PARIS_LAT
PARIS_LON
PSID_A
PSID_B
PSID_C
PSID_D
These PSIDs shall be defined before test execution
PSID_E
PSID_F
PSID_G
PSID_H
PSID_I
PSID_J
These PSIDs shall be defined only when IUT supports more than 8
PSID_K PSID
PSID_L
ETSI
19 ETSI TS 103 096-2 V1.1.1 (2013-07)
6.1.8 Snippets definitions
6.1.8.1 Regions
Table 4: Regions definitions
REGION_LARGE :=
GeographicRegion {
containing region_type set to 'circle'
containing circular_region
containing center
containing latitude set to ETSI_LAT
containing longitude set to ETSI_LON
containing radius set to 65KM
}
REGION_MEDIUM :=
GeographicRegion {
containing region_type set to 'circle'
containing circular_region
containing center
containing latitude set to ETSI_LAT
containing longitude set to ETSI_LON
containing radius set to 32KM
}
REGION_SMALL :=
GeographicRegion {
containing region_type set to 'circle'
containing circular_region
containing center
containing latitude set to ETSI_LAT
containing longitude set to ETSI_LON
containing radius set to 1KM
}
REGION_OUTSIDE :=
GeographicRegion {
containing region_type set to 'circle'
containing circular_region
containing center
containing latitude set to PARIS_LAT
containing longitude set to PARIS_LON
containing radius set to 65KM
}
REGION_INTERSECTING :=
GeographicRegion {
containing region_type set to 'circle'
containing circular_region
containing center
containing latitude set to NICE_LAT
containing longitude set to NICE_LON
containing radius set to 65KM
}
6.1.8.2 Certificates
6.1.8.2.1 Authorities certificates
Table 5: Root certificate definition
CERT_ROOT :=
Certificate {
containing version_and_type
set to 'explicit_certificates'(2)
containing unsigned_certificate
containing subject_type
set to 'root_ca'
containing cf
set to 'use_start_validity' and 'lifetime_is_duration'
ETSI
20 ETSI TS 103 096-2 V1.1.1 (2013-07)
not containing signer_id
containing scope
containing name
set to 'ETSI Root CA'
containing permitted_subject_types
set to array[1] {
'sec_data_exch_ca'
}
containing permissions
containing type
set to 'specified'
containing permissions_list
set to array[0]
containing region
containing region_type
set to 'none'
containing expiration
set to '2020-12-31'
containing lifetime
set to '10Y'
containing crl_series
set to 0
containing verification_key
containing algorithm
set to 'ecdsa_nistp256_with_sha256'
containing public_key
containing type
set to 'uncompresed'
containing x/y
set to a valid key for ECDSA-256
not containing encryption_key
containing signature
containing ecdsa_signature
verifiable with unsigned_certificate.verification_key
containing R
containing type
set to 'x_coordinate_only'
containing x
}
Table 6: Enrolment authority certificate definition
CERT_EA :=
Certificate {
containing version_and_type
set to 'explicit_certificates'(2)
containing unsigned_certificate
containing subject_type
set to 'sec_data_exch_ca'
containing cf
set to 'use_start_validity' and 'lifetime_is_duration'
containing signer_id
set to the 8-byte hash of CERT_ROOT
containing signature_alg
set to 'ecdsa_nistp256_with_sha256'
containing scope
containing name
set to 'ETSI EA'
containing permitted_subject_types
set to array[1] {
'sec_data_exch_ca'
}
containing permissions
containing type
set to 'specified'
containing permissions_list
set to array[0]
containing region
set to REGION_LARGE
containing expiration
set to '2020-12-31'
containing lifetime
set to '10Y'
containing crl_series
set to 0
containing verification_key
ETSI
21 ETSI TS 103 096-2 V1.1.1 (2013-07)
containing algorithm
set to 'ecdsa_nistp256_with_sha256'
containing public_key
containing type
set to 'uncompresed'
containing x/y
set to a valid key for ECDSA-256
containing encryption_key
containing algorithm
set to 'ecies_nistp256'
containing supported_symm_alg
set to 'aes_128_ccm'
containing public_key
containing type
set to 'uncompresed'
containing x/y
set to a valid key for ECIES-256
containing signature
containing ecdsa_signature
verifiable with CERT_ROOT.verification_key
containing R
containing type
set to 'x_coordinate_only'
containing x
}
Table 7: Authorization authority certificate definition
CERT_AA :=
Certificate {
containing version_and_type
set to 'explicit_certificates'(2)
containing unsigned_certificate
containing subject_type
set to 'sec_data_exch_ca'
containing cf
set to 'use_start_validity' and 'lifetime_is_duration'
conta
...








Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...