Put prEN 40000-1-3 as Informative Reference / Removed StrictLocal

- <span id="_ref_1"></span><a name="_ref_1">[1]</a> ENISA Report 1747792503: “[European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms](https://certification.enisa.europa.eu/document/download/a845662b-aee0-484e-9191-890c4cfa7aaa_en?filename=ECCG%20Agreed%20Cryptographic%20Mechanisms%20version%202.pdf) - version 2” – April 2025

- <span id="_ref_2"></span><a name="_ref_2">[2]</a> \"prEN 40000-1-3\": \"Cybersecurity requirements for products with digital elements – Vulnerability Handling \" [Version and date to be added upon its publication by CEN CENELEC]

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

- <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_4"></span><a name="_ref_4">[4]</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">[3]</a> \"ENISA Report 1747792503\": “European Cybersecurity Certification Group Sub-group on Cryptography Agreed Cryptographic Mechanisms - version 2” – April 2025

- <span id="_ref_5"></span><a name="_ref_5">[5]</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_6"></span><a name="_ref_6">[6]</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_7"></span><a name="_ref_7">[7]</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_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"

## 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.16"></span><a name="_ref_i.16">[i.16]</a> ETSI TS 102 940: “Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management; Release 2” — V2.1.1, July 2021.

- <span id="_ref_i.17"></span><a name="_ref_i.17">[i.17]</a> \"prEN 40000-1-3\": \"Cybersecurity requirements for products with digital elements – Vulnerability Handling \" [Version and date to be added upon its publication by CEN CENELEC]

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

<mark>I suggest to move the Interfaces in a dedicated chapter in operation environment. 4.3.5 Interfaces</mark>

<mark>Interfaces are accessible through logical environment (COM.Local, COM.StrictLocal...), Therefore, I.LocalInterface becomes useless as it is a combination of COM.StrictLocal and I.AuditAndAdministration. I suggest then, to remove I.LocalInterface.</mark>

<mark>Interfaces are accessible through logical environment (COM.Local, ...), Therefore, I.LocalInterface becomes useless as it is a combination of COM.Local and I.AuditAndAdministration. I suggest then, to remove I.LocalInterface.</mark>

## 4.3 Operational Environment

- **COM.Public** - ingoing/outgoing communication from/to public networks

- **COM.Adjacent** - ingoing/outgoing communication from/to private networks which does not require physical proximity to the communication partner

- **COM.Local** - ingoing/outgoing communication which requires physical proximity to but not physical presence at the communication partner

- **COM.StrictLocal** - ingoing/outgoing communication which requires physical presence at the communication partner

## 4.4 Distribution of Security Functions

  - REQUIREMENT: The product shall not contain known exploitable vulnerabilities, unless vulnerability assessment demonstrates that:

    - the vulnerability is not exploitable in the product; or

    - specific user guidance is provided to prevent exploitation.

  - NOTE: Details of the vulnerability assessment are provided in the vulnerability handling process defined in prEN 40000-1-3 [\[2\]](#_ref_2).

  - NOTE: Details of the vulnerability assessment are provided in the vulnerability handling process defined in prEN 40000-1-3 [\[i.17\]](#_ref_i.17).

  - APPLICABILITY: All use cases.

## 5.3 Secure by default configuration

  - 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  [\[7\]](#_ref_7) 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_6) 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  [\[7\]](#_ref_7) 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_6) 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  [\[7\]](#_ref_7)

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

## 5.10 Impact minimisation

To limit certificate forgery or misuse of certificate content, this section defines requirements for the PKI to enforce the use of standardized certificate formats and recognized cryptographic signature mechanisms.

- 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 [\[3\]](#_ref_3) 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  [\[7\]](#_ref_7) 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.

  - 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.

  - APPLICABILITY:  All use cases.

- REFERENCE: REQ-PKI-EMM-02

- REFERENCE: REQ-PKI-EMM-08

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

    - CRLs as defined by and subject to the requirements of ITU-T X.509 [\[3\]](#_ref_3); or

    - CRLs as defined by and subject to the requirements of ITU-T X.509 [\[2\]](#_ref_2); or

    - OCSP responses to OCSP requests as defined by and subject to the requirements of RFC 6960 [\[i.3\]](#_ref_i.3).

  - 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.

### 5.12.3 Certificate renewal

- REFERENCE: REQ-PKI-EMM-14

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

- REFERENCE: REQ-PKI-EMM-014

  - REQUIREMENT: Requirement GEN-6.3.6-10 contained in ETSI EN 319 411-1  [\[6\]](#_ref_6) 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.

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 2.

The requirements specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be fulfilled for the product.

The requirements specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[i.17\]](#_ref_i.17) shall be fulfilled for the product.

# 6 Assessment criteria for compliance with technical requirements

- REFERENCE: ACC_PKI_EMM_01

  - OBJECTIVE: Verify the certificates issued by the certificate generation service are public-key certificates or attribute certificates whose format complies with the X.509 standard ITU-T X.509 [\[3\]](#_ref_3).

  - OBJECTIVE: Verify the certificates issued by the certificate generation service are public-key certificates or attribute certificates whose format complies with the X.509 standard ITU-T X.509 [\[2\]](#_ref_2).

  - PREPARATION:

    - Certificate request interface accessible.

- REFERENCE: ACC_PKI_EMM_02

  - OBJECTIVE: Verify the format of public-key certificates issued by the certificate generation service complies with ITU-T X.509 [\[3\]](#_ref_3).

  - OBJECTIVE: Verify the format of public-key certificates issued by the certificate generation service complies with ITU-T X.509 [\[2\]](#_ref_2).

  - PREPARATION: Document the circumstances in which the certificate generation service may issue a certificate. Ability to request a certificate issuance for the different identified circumstances.

### 6.12.2 Certificate status

- REFERENCE: ACC_PKI_EMM_09

  - OBJECTIVE: Verify the certificate revocation statuses to be either or both of CRLs as defined by and subject to the requirements of ITU-T X.509 [\[3\]](#_ref_3), or OCSP responses as defined by and subject to the requirements of RFC 6960 [\[i.3\]](#_ref_i.3).

  - OBJECTIVE: Verify the certificate revocation statuses to be either or both of CRLs as defined by and subject to the requirements of ITU-T X.509 [\[2\]](#_ref_2), or OCSP responses as defined by and subject to the requirements of RFC 6960 [\[i.3\]](#_ref_i.3).

  - PREPARATION: Document the circumstances in which the certificate generation service may issue a public-key certificate. Ability to request a certificate issuance. Ability to configure revocation aspects of the certificate profile if supported.

## 6.15 Vulnerability handling

The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) shall be met for the product

The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[i.17\]](#_ref_i.17) shall be met for the product

# Annex A (informative): Relationship between the present document and the requirements of EU Regulation (EU) 2024/2847 – the Cyber Resilience Act

Connectivity

- COM.Local

- COM.StrictLocal

### U.2.5 UC2 - Distribution of Security Functions

Connectivity

- COM.Public

- COM.Local

- COM.StrictLocal

### U.3.5 UC3 - Distribution of Security Functions

Connectivity

- COM.Public

- COM.Local

- COM.StrictLocal

### U.4.5 UC4 - Distribution of Security Functions

Connectivity

- COM.Public

- COM.Local

- COM.StrictLocal

### U.5.5 UC5 - Distribution of Security Functions