Meeting follow up update

- <span id="_ref_2"></span><a name="_ref_2">[2]</a> \"ITU-T X.509\" \"(10/2019)\": \"Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks\"

  - NOTE:	Identical text in the defining of public-key and attribute certificates is also available in ISO/IEC 9594‑8 (paywall).

- <span id="_ref_3"></span><a name="_ref_3">[3]</a> \"ENISA Report 1747792503\": “European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms - version 2” – April 2025

- <span id="_ref_3"></span><a name="_ref_3">[4]</a> "IEEE Std 1609.2™-2022" "(2022)": "Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages"

- <span id="_ref_4"></span><a name="_ref_4">[4]</a> "IEEE Std 1609.2™-2022" "(2022)": "Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages"

- <span id="_ref_4"></span><a name="_ref_4">[5]</a> "ETSI TS 102 941 V1.4.1" "(2021-01)": "Intelligent Transport Systems (ITS); Security; Trust and Privacy Management"

- <span id="_ref_5"></span><a name="_ref_5">[5]</a> "ETSI TS 102 941 V1.4.1" "(2021-01)": "Intelligent Transport Systems (ITS); Security; Trust and Privacy Management"

- <span id="_ref_6"></span><a name="_ref_6">[6]</a> "ETSI EN 319 411-1 V1.5.1" "(2025-04)": "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements"

- <span id="_ref_5"></span><a name="_ref_5">[6]</a> "ETSI EN 319 411-1 V1.5.1" "(2025-04)": "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements"

## 2.2 Informative references

References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.

- <span id="_ref_i.8"></span><a name="_ref_i.8">[i.8]</a> ETSI TS 102 165-2: “Telecommunications and Internet Protocol Harmonization Over Networks (TIPHON); Protocol Framework Definition; Methods” — V4.2.1, February 2007.

- <span id="_ref_i.9"></span><a name="_ref_i.9">[i.9]</a> ETSI EN 304 645:“Cyber Security for Consumer Internet of Things: Baseline Requirements” — V2.1.1, June 2020.

- <span id="_ref_i.9"></span><a name="_ref_i.9">[i.9]</a> \"ENISA Report 1747792503\": “European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms - version 2” – April 2025

- <span id="_ref_i.10"></span><a name="_ref_i.10">[i.10]</a> ETSI EN 319 411-1: “Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements” — V1.5.1, April 2025.

  - APPLICABILITY: All use cases where the product has a certificate generation service, issuing public-key certificates.

- REFERENCE: REQ-PKI-AP-02

  - REQUIREMENT: Requirements CSS-6.3.9-06, CSS-6.3.9-08, CSS-6.3.9-12 and CSS-6.3.9-13 contained in ETSI EN 319 411-1  [\[6\]](#_ref_6) shall apply.

  - REQUIREMENT: Requirements CSS-6.3.9-06, CSS-6.3.9-08, CSS-6.3.9-12 and CSS-6.3.9-13 contained in ETSI EN 319 411-1  [\[6\]](#_ref_5) shall apply.

  - RATIONALE:

    - CSS-6.3.9-06: The inclusion of an expiry of the CRL's validity reduces the ability of an attacker to replay the CRL to its users, and enables caching for end-users. The special value of that field in the event the next update would be the CRL issuer expires ensures the status information is valid until that expiry.

    - CSS-6.3.9-08: If the CRL is not signed by the CA or a TSP-appointed entity, it may be usurped to mislead end-users regarding a certificate's status.

### 5.9.2 Certificate status services

- REFERENCE: REQ-PKI-AP-02

  - REQUIREMENT: Requirements CSS-6.3.10-03, CSS-6.3.10-04 and CSS-6.3.10-05 contained in ETSI EN 319 411-1  [\[6\]](#_ref_6) shall apply.

  - REQUIREMENT: Requirements CSS-6.3.10-03, CSS-6.3.10-04 and CSS-6.3.10-05 contained in ETSI EN 319 411-1  [\[6\]](#_ref_5) shall apply.

   - RATIONALE: The product shall provide accurate and integrity protected certificates statues either using the standardised CRL format ensuring integrity of revocation list or protected OCSP services as defined by RFC 6960 [\[i.3\]](#_ref_i.3).

  - APPLICABILITY: UC1, UC2 and UC3.

  - REQUIREMENT: If a product supports multiple methods to provide revocation status, the information provided by all services shall be consistent over time taking into account different delays in updating the status information for all the methods.

   - RATIONALE: The product shall provide accurate and integrity protected certificates statues either using the standardised CRL format ensuring integrity of revocation list or protected OCSP services as defined by RFC 6960 [\[i.3\]](#_ref_i.3).

  - APPLICABILITY: UC1, UC2 and UC3.

  - NOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1  [\[6\]](#_ref_6)

  - NOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1  [\[6\]](#_ref_5)

## 5.10 Impact minimisation

- REFERENCE: REQ-PKI-EMM-01

  - REQUIREMENT: The certificates issued by the certificate generation service shall comply with the X.509 standard ITU-T X.509 [\[2\]](#_ref_2) or with the IETF RFC 5280 standard or with the IEEE 1609.2 standard, and if known, to any extension or profile identified by the target systems' policy.

  - RATIONALE: This extends what is mandated by ETSI EN 319 411-1  [\[6\]](#_ref_6) and takes into account the C-ITS PKI use case. Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.

  - RATIONALE: This extends what is mandated by ETSI EN 319 411-1  [\[6\]](#_ref_5) and takes into account the C-ITS PKI use case. Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.

  - APPLICABILITY:  All use cases.

- REFERENCE: REQ-PKI-EMM-02

### 5.12.3 Certificate renewal

- REFERENCE: REQ-PKI-EMM-014

  - REQUIREMENT: Requirement GEN-6.3.6-10 contained in ETSI EN 319 411-1  [\[6\]](#_ref_6) shall apply.

  - REQUIREMENT: Requirement GEN-6.3.6-10 contained in ETSI EN 319 411-1  [\[6\]](#_ref_5) shall apply.

  - NOTE: (TODO Remove note and provide the definition directly in the document) The term "sufficient" in the requirement means that the security is to be evaluated according to the current state of the art.

  - RATIONALE: The product should never issue a certificate with foreseeable insufficient cryptographic security. The product should never issue a certificate for a key associated to any kind of security compromission.

  - APPLICABILITY: All use cases where the product has a certificate generation service, issuing public-key certificates and supporting certificate renewal.

    <td>UC1, UC2, UC3</td>

  </tr>

  <tr>

    <td>T_SYS10</td>

    <td>Accessing event logs via an unprotected event log management function </td>

    <td>UC1, UC2, UC3</td>

  </tr>

  <tr>

    <td>T_SYS11</td>

    <td>Disabling or rolling back software updates via an unprotected software update function </td>

    <td>UC1, UC2, UC3</td>

  </tr>

  <tr>

    <td>T_REG01</td>

    <td>Modifying information in unprotected subscriber data </td>

    <td>UC2, UC3</td>

  </tr>

  <tr>

    <td>T_REG02</td>

    <td>Disclosing sensitive information in unprotected subscriber data </td>

    <td>UC2, UC3</td>

  </tr>

  <tr>

    <td>T_REG03</td>

    <td>Modifying an unprotected certificate request </td>

    <td>NA</td>

    <td>UC1, UC2, UC3</td>

  </tr>

</table>

</div>

    <td>UC1, UC2, UC3</td>

  </tr>

  <tr>

    <td>T_GEN02</td>

    <td>Disclosing CA private keys in unprotected CA key data </td>

    <td>UC1, UC2, UC3</td>

  </tr>

  <tr>

    <td>T_GEN03</td>

    <td>Deleting CA private keys in unprotected CA key data </td>

    <td>UC1, UC2, UC3</td>

  </tr>

  <tr>

    <td>T_GEN04</td>

    <td>Modifying subject private keys in unprotected subject key data </td>

    <td> UC2, UC3</td>

  </tr>

  <tr>

    <td>T_GEN05</td>

    <td>Disclosing subject private keys in unprotected subject key data </td>

    <td> UC2, UC3</td>

  </tr>

  <tr>

    <td>T_GEN06</td>

    <td>Deleting subject private keys in unprotected subject key data </td>

    <td>NA</td>

    <td>UC1, UC2, UC3</td>

  </tr>

</table>

</div>

    <td>NA</td>

    <td>UC1, UC2, UC3</td>

  </tr>

  <tr>

    <td>T.MITM</td>

    <td>A Remote attacker may exploit interactions between the Product and the ITS-S to expose or tamper sensitive product or user data</td>

    <td>Keys <br> Certificates <br> Station registration data <br> Trust lists <br> Misbehaviour detection </td>

    <td>Integrity, Availability, Confidentiality</td>

    <td>NA</td>

    <td>NA</td>

    <td>NA</td>

    <td>AVA-0, INT-0, CON-0</td>

    <td></td>

    <td>NA</td>

    <td>NA</td>

    <td>NA</td>

    <td>DEP-1, NET-2, USR-2, OPS-2, IF-0/td>

    <td>NA</td>

    <td>NA</td>

    <td>NA</td>

    <td>High</td>

    <td>UC4</td>

  </tr>

</Table>

</div>

> NOTE 1:	The use of security mechanism e.g. authentication, access control, secure communication, secure storage and secure update are described in the main text of this standard.

> NOTE 2:	Cryptographic algorithm primitives (in short, algorithms e.g. public- and private-key encryption algorithms, hash functions, authentication codes, digital signatures) are classified as CRY-SOTA if they are listed in the [ACM]  document and are suitable for the implementation of supported security mechanisms of the product.

> NOTE 2:	Cryptographic algorithm primitives (in short, algorithms e.g. public- and private-key encryption algorithms, hash functions, authentication codes, digital signatures) are classified as CRY-SOTA if they are listed in the _ref_i.9  document and are suitable for the implementation of supported security mechanisms of the product.

> NOTE 3	Supporting evidence options that an algorithm, which is not included in CRY-SOTA, is applicable and suitable for the respective use case, are listed in the related assessment criteria ( K.1.2.1) clause.

> NOTE 5: Formal verification can use mathematical proofs and /or rigorous methods to prove an algorithm's correctness, ensuring it meets its formal specification for all valid inputs, unlike testing which only samples cases. This process involves creating formal models, using techniques like theorem proving or model checking, and is crucial for critical systems like cryptography finding hard-to-spot bugs and guaranteeing security/reliability.

> NOTE 6: The [ACM] listing has two classes of SOTA algorithms; Legacy mechanisms with an expiry date as defined in ACM, and Recommended mechanisms with no set expiry date.

> NOTE 6: The _ref_i.9 listing has two classes of SOTA algorithms; Legacy mechanisms with an expiry date as defined in ACM, and Recommended mechanisms with no set expiry date.

> NOTE 7: For products or components of products that cannot have their cryptographic algorithms updated for example if the implementation or part uses a hardware-based root of trust, it is important that the intended lifetime of the equipment does not exceed the recommended usage lifetime of the cryptographic algorithms used by the product. Thereby the implementation of an algorithm can include the specific implementation of their parameters