Merge branch 'editorials' into 'main'

The following referenced documents may be useful in implementing an ETSI deliverable or add to the reader's understanding but are not required for conformance to the present document.

- <span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> [C(2025) 618 final: ](\"COMMISSION IMPLEMENTING DECISION on a standardisation request to the European Committee for Standardisation (CEN), the European Committee for Electrotechnical Standardisation (Cenelec) and the European Telecommunications Standards Institute (ETSI) as regards products with digital elements in support of Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)\")

- <span id="_ref_i.1"></span><a name="_ref_i.1">[i.1]</a> C(2025) 618 final: \"COMMISSION IMPLEMENTING DECISION on a standardisation request to the European Committee for Standardisation (CEN), the European Committee for Electrotechnical Standardisation (Cenelec) and the European Telecommunications Standards Institute (ETSI) as regards products with digital elements in support of Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)\"

- <span id="_ref_i.2"></span><a name="_ref_i.1">[i.2]</a> Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)\"

- <span id="_ref_i.2"></span><a name="_ref_i.2">[i.2]</a> Regulation (EU) 2024/2847 of the European Parliament and of the Council of 23 October 2024 on horizontal cybersecurity requirements for products with digital elements and amending Regulations (EU) No 168/2013 and (EU) 2019/1020 and Directive (EU) 2020/1828 (Cyber Resilience Act)\"

# 3 Definition of terms, symbols and abbreviations

| SYS21: Remote administration interface    | E.g., remotely accessible web portal |

| SYS22: Local administration interface     | E.g., locally accessible command line interface |

<br />

</div>

| REG21.Registration user interface | E.g., remotely accessible web portal |

| REG22.Certificate request API | E.g., remotely accessible logical interface |

<br />

</div>

| GEN21.Certificate generation user interface | E.g., remotely accessible web portal or locally accessible command <br> line interface |

| GEN22.Secure cryptographic device interface | Logical interface for the secure cryptographic device |

<br />

</div>

| DIS22.Subscriber dissemination interface     | E.g., email client interface |

| DIS23.Relying party look-up interface  | E.g., remotely accessible logical interface | 

<br />

</div>

| REV11.Revocation management function           | Used to approve or reject revocation requests | 

| REV21.Revocation management user interface     | E.g., remotely accessible web portal          |

<br />

</div>

| STA21.Certificate status user interface             | E.g., remotely accessible web portal          |

| STA22.Relying party certificate status interface    | E.g., remotely accessible logical interface   |

<br />

</div>

| T_SYS16.Accessing system administration functions via an unprotected <br> local administration interface | SYS22 | Authentication |

<br />

</div>

 | T_REG10.Denying subscriber access via an unprotected certificate request API | REG22 | Availability |

<br />

</div>

 | T_GEN13.Disrupting the operation of a secure cryptographic device via <br> requests from the product over the secure cryptographic device API | GEN22 | Impact |

<br />

</div>

 | T_DIS07.Modifying certificate look-up responses via an unprotected relying <br> party look-up interface | DIS23 | Integrity |

 | T_DIS08.Denying relying party access to an unprotected relying party <br> look-up interface | DIS23 | Availability | 

<br />

</div>

| T_REV07.Denying system operator access to an unprotected revocation <br> management user interface | REV21 | Availability |

<br />

</div>

| T_STA06.Denyin relying party access to an unprotected relying party certificate <br> status interface | STA22 | Availability |

<br />

</div>

| Misbehavior detection |     |     |     |

| A\_Misbehaviour Report (MR) | Reports sent by the ITS-S to the MA to provide information regarding a possible misbehaving ITS-S (8). | Integrity, availability |

<br />

#### 4.7.3.2 Essential Functions

|Function | description | Associated user/role |

| Creation, deletion, management of user accounts | Users account can be created or deleted and the different account privileges can be set up according to the role | Configuration and management administrator|

| Verification of the  C-ITS PKI secure state | Verification of the current state of the  C-ITS PKI to verify that it is in a secure state (e.g. Code integrity validation regarding its signature, verification of the keys integrity, verification of the certificates validity) |Configuration and management administrator, Officer|

<br />

#### 4.7.3.3 Operationnal environment

| Name | Description |

| AE.Trusted\_Time\_Source | The runtime environment provides the TOE with exact date and time to ensure time stamp functions (audit traces generation request validity verification). |

| AE.Deployment | The TOE can be used to provide services to different kind of authorities. For each of those authority’s type the TOE shall be correctly configured and shall only provide services corresponding to the entity e.g. a RCA should not be able to deliver ATs an AA should not respond to EC requests etc. |

<br />

##### 4.7.3.3.4  Users

| Level 1 | Level 2 | Level 3 |

| Officer EA |

| Officer AA |

| Other IT entities | Manufacturer/operator servers | NA  |

<br />

##### 4.7.3.3.5  Threats

The considered threats for the C-ITS PKI are illustrated in the following figure.

**Figure 4.7.3.3.5-1: ITS_PKI_Threats_200108**

<br />

| Name | Description | Related assets |

| --- | --- | --- |

| Remote attacker |

| T.Adminstrators\_Impersonation | An attacker (Remote attacker Local attacker or Rogue user) may gain access to TOE information by impersonating an authorized user or via privilege escalation of the TOE and thus disclose or manipulate TOE assets. | Canonical Public Key CA Certificates Enrolment Credential (EC) Authorization Ticket (AT) TLM certificate Canonical ID Tag HMAC key Certificate Policy configuration CRL CTL ITS-S Profile ECTL. |

| T.Software\_Tampering | A Local or Remote attacker tries to modify the TOE’s software and therefore compromise the integrity of the TOE’s applications. | Software |

<br />

# 5  Requirements for PKI products

## 5.1 Auditing

REQUIREMENT: The PKI shall record within each audit record at least the following information:

a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and

b) For each audit event type, based on the auditable event definitions in TODO, the additional information specified in TODO.

RATIONALE:

keyed hash, or authentication code shall be computed over, at least:

a) every entry that has been added to the audit log since the previous audit log signing event;

b) the digital signature, keyed hash, or authentication code from the previous audit log signed event.

The digital signature, keyed hash, or authentication code from the audit log signing event shall be included in the audit log.

The digital signature, keyed hash, or authentication code used to protect a public key shall be verified upon each access to the key. If verification fails, the PKI shall not:

a) release the accessed public key to the caller; or

b) use the accessed public key.

RATIONALE: Unauthorized modifications of public keys stored by the PKI should not go undetected.

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:

a) the authority key identifier;

b) the algorithm identifier for the subject’s public/private key pair;

c) the identifier of the certificate issuer;

d) the length of time for which the certificate is valid.

RATIONALE:

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:

a) keyUsage;

b) basicConstraints;

c) certificatePolicies.

RATIONALE:

REQUIREMENT: The PKI shall mark the following extensions as critical:

a) keyUsage;

b) basicConstraints;

c) certificatePolicies.

RATIONALE:

REQUIREMENT: The PKI shall disallow the keyUsage extension to simultaneously include values from both of:

a) digitalSignature, contentCommitment, keyCertSign, cRLSign; and

b) keyEncipherment, dataEncipherment, keyAgreement.

RATIONALE: The same public key may not be used for signature verification, and encryption or key agreement.

REQUIREMENT: The certificate status service shall provide certificate revocation statuses as either or both of:

a) CRLs as defined by and subject to the requirements of [ITU-T X.509]; or

b) OCSP responses to OCSP requests as defined by and subject to the requirements of [RFC 6960].

RATIONALE:

REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:

a) issuer;

b) issuerAltName;

c) nextUpdate.

RATIONALE:

Trigger an auditable event. Access the corresponding audit record. Verify the audit record contains at least:

a) the date and time of the event;

b) the type of the event;

c) the subject identity (if applicable);

d) the outcome of the event.

Perform the above for each audit event type, and verify that the audit record additionally contains the additional information specified in TODO.

EVIDENCE:

a) The way the events were triggered and at what time, and the corresponding audit records;

b) arguments relating to the authentication of a trusted source (if applicable);

c) arguments relating to the monotonicity of local time information (if applicable).

- REFERENCE: ASS-REQ-6.1-03

EVIDENCE:

a) The identity of the given user used for the test;

b) the way the event was triggered and at what time, and the corresponding audit record.

- REFERENCE: ASS-REQ-6.1-04

EVIDENCE:

a) The identity of the given user(s) used for the test;

b) the list of identified actions that may result in deletion of an audit records;

c) the way the actions were attempted, including the corresponding user identity;

d) the copies of existing audit records, before and after attempts.

- REFERENCE: ASS-REQ-6.1-05

EVIDENCE:

a) the way the event was triggered, and the corresponding audit record which was copied;

b) the way the audit record was directly modified;

c) the way the last audit was attempted, and the corresponding response from the PKI.

- REFERENCE: ASS-REQ-6.1-06

EVIDENCE:

a) The configured maximum size of the audit log;

b) The size of the audit when full, or nearly so;

c) the way the additional event was attempted to be triggered, and the corresponding response from the PKI.

- REFERENCE: ASS-REQ-6.1-07

EVIDENCE:

a) The way the auditable event was triggered;

b) the last entries of the audit log, including all the entries impacting the third-to-last audit log signing event and its signature, keyed hash or authentication code;

c) the way the signatures, keyed hashes or authentication codes were verified, and the corresponding responses from the PKI;

d) the way the audit record of the triggered event was modified;

e) the way the second-to-last signature, keyed hash or authentication code was modified.

- REFERENCE: ASS-REQ-6.1-08

EVIDENCE:

a) The new frequency which was configured;

b) the 2 last audit log signing events as they appear in the audit log, and their corresponding date and time.

- REFERENCE: 

# History

+-------------------------------------------------+

+-----------------------------------------------------+

|Document History                                     |

+:==============+:==============+:================+

+:================+:==============+:==================+

|Version          |Date           |Milestone          |

+---------------+---------------+-----------------+

|<Month year>   | <#>           |<Changes made>   |

+---------------+---------------+-----------------+

+-----------------+---------------+-------------------+

|<Month year>  |<#>         |<Changes made>  |

+-----------------+---------------+-------------------+

|                 |               |                   |

+---------------+---------------+-----------------+

+-----------------+---------------+-------------------+

|                 |               |                   |

+---------------+---------------+-----------------+

+-----------------+---------------+-------------------+