Update file EN-304-624.md

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.

<br />

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

All rights reserved.<br />

- <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_7"></span><a name="_ref_7">[7]</a> "ETSI TS 103 525-2 V2.1.1" "(2024-09)": "Intelligent Transport Systems (ITS); Testing; Conformance test specifications for ITS PKI management; Part 2: Test Suite Structure and Test Purposes (TSS & TP); Release 2"

- <span id="_ref_8"></span><a name="_ref_8">[8]</a> "ETSI TR 119 411-4 V1.2.1" "(2024-06)": "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 4: Checklist supporting audit of TSP against ETSI EN 319 411-1 or ETSI EN 319 411-2"

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

 ## 5.11 Secure communication with external entities

  - REFERENCE: REQ-5.10-02

  - REFERENCE: REQ-5.11-01

  - REQUIREMENT:

The PKI shall permit an communication between a and the PKI if the following rules hold:

    - The certificates are valid as defined by (6) section 5.1

    - The certificates are valid as defined by [\[4\]](#_ref_4) section 5.1

    - Sending

        ◦ The requests are encrypted and signed as defined by (1) section 6.2.3.4.1 using EA and AA Certificates

        ◦ The Message format is conformant to (1)section 6.2.3.4.1

        ◦ The requests are encrypted and signed as defined by [\[5\]](#_ref_5) section 6.2.3.4.1 using EA and AA Certificates

        ◦ The Message format is conformant to [\[5\]](#_ref_5) section 6.2.3.4.1

    - Reception

        ◦ The requests can be correctly decrypted and the signature is valid with respect to the validated EA and AA Certificates

        ◦ The Message format is conformant to (1) section 6.2.3.4.1

        ◦ The Message format is conformant to [\[5\]](#_ref_5)  section 6.2.3.4.1

].

   - RATIONALE: Only authorised, identicated and authenticated user should be able to access the PKI services and stored data. This covers threats all threats. 

  - APPLICABILITY: All use cases. 

   - RATIONALE: The PKI shall provide protected communication channels for remote administrators, IT entities such as car manufacturer servers (confidentiality and integrity) and other parts of a distributed TOE (confidentiality, integrity and authenticity). This covers threats: T.MITM  and T.DOS. 

  - APPLICABILITY: UC4. 

# 6 Conformity Assessment

  - PREPARATION: Ability to trigger auditable events, and ability to audit events.

  - ACTIVITIES:

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

  - ACTIVITIES: Trigger an auditable event. Access the corresponding audit record.

     - Verify the audit record contains at least:

        a) the date and time of the event;

        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 by the developper.

    - Perform the above for each audit event type, and verify that the audit record additionally contains the additional information specified by the developper.

For each information verified to be present, verify it matches the expected value given when and how the event was triggered.

    - For each information verified to be present, verify it matches the expected value given when and how the event was triggered.

For each of the generated audit record, verify that no private or symmetric key, as well as no other secret parameter is present in plaintext form.

    - For each of the generated audit record, verify that no private or symmetric key, as well as no other secret parameter is present in plaintext form.

  - VERDICT: SUCCESS if all the verifications pass; else FAIL.

  - ACTIVITIES: Trigger an auditable event. Access the corresponding audit record. Verify the date and time of the event to match the trusted time stamp origin.

Repeat the above several times from different accesses to the PKI in parallel and verify the produced time stamps from the PKI to be monotonic.

    - Repeat the above several times from different accesses to the PKI in parallel and verify the produced time stamps from the PKI to be monotonic.

If the PKI may determine its time stamps by querying time information from a source it trusts, verify that it authenticates that source messages using state of the art mechanisms.

    - If the PKI may determine its time stamps by querying time information from a source it trusts, verify that it authenticates that source messages using state of the art mechanisms.

If the PKI may increment temporary or long-term time information stored locally, verify that the time information may not be used in data issued by the PKI until it has been properly been incremented, or alternatively that the service responsible for it cannot fail.

    - If the PKI may increment temporary or long-term time information stored locally, verify that the time information may not be used in data issued by the PKI until it has been properly been incremented, or alternatively that the service responsible for it cannot fail.

  - VERDICT: SUCCESS if all the verifications pass; else FAIL.

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

- REFERENCE: ASS-REQ-6.2-03

  - OBJECTIVE: Verify that the PKI records within each audit record resulting from actions of identified users the corresponding user information.

  - ACTIVITIES: Identify to the PKI as the given user. Trigger an auditable event as the given user. Access the corresponding audit record.

Verify the audit record contains the identity of the user that caused the event. Verify this identity to match that of the given user.

    - Verify the audit record contains the identity of the user that caused the event.

    - Verify this identity to match that of the given user.

  - VERDICT: SUCCESS if all the verifications pass; else FAIL.

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

- REFERENCE: ASS-REQ-6.2-04

  - OBJECTIVE: Verify PKI protections from unauthorised deletion to be active and functional.

  - ACTIVITIES: Identify to the PKI as the given user. Trigger an auditable event as the given user. Access and copy audit records separately.

Attempt to perform all actions identified as possibly resulting in an audit record deletion; re-identifying to the PKI as necessary.

    - Attempt to perform all actions identified as possibly resulting in an audit record deletion; re-identifying to the PKI as necessary.

Access audit records and verify they match the copy performed previously.

    - Access audit records and verify they match the copy performed previously.

  - VERDICT: SUCCESS if the verification passes; else FAIL.

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

- REFERENCE: ASS-REQ-6.2-05

  - OBJECTIVE: Verify the PKI's ability to detect unauthorised modifications to the stored audit records during the audit.

  - ACTIVITIES: Trigger an auditable event. Access and copy the corresponding audit record separately.

Directly modify the contents of the stored audit record in the PKI.

    - Directly modify the contents of the stored audit record in the PKI.

Attempt to access the audit record.

    - Attempt to access the audit record.

  - VERDICT: SUCCESS if the last audit fails; else FAIL.

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

- REFERENCE: ASS-REQ-6.2-06

  - OBJECTIVE: Verify the PKI's prevention of auditable events, except those taken by the auditor, if the audit log is full.

  - ACTIVITIES: Do not identify as an auditor to the PKI. Trigger auditable events until the audit log is full, or nearly so.

Verify that a given additional auditable event cannot be performed.

    - Verify that a given additional auditable event cannot be performed.

  - VERDICT: SUCCESS if the verification passes; else FAIL.

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

- REFERENCE: ASS-REQ-6.2-07

  - OBJECTIVE: Verify the use of an audit log signing event by the PKI.

  - PREPARATION: Ability to trigger auditable events, and ability to audit events.

Determine the configured frequency of the audit log signing event and date of the audit log signing event. The frequency of the audit log signing event may be reduced; the event shall not be triggered manually.

    - Determine the configured frequency of the audit log signing event and date of the audit log signing event. The frequency of the audit log signing event may be reduced; the event shall not be triggered manually.

The list of auditable events may be reduced.

    - The list of auditable events may be reduced.

Ability to verify the digital signatures, keyed hashes, or authentication codes used for the audit log signing event.

    - Ability to verify the digital signatures, keyed hashes, or authentication codes used for the audit log signing event.

Ability to modify audit records before verifying or re-verifying their digital signatures, keyed hashes, or authentication codes.

    - Ability to modify audit records before verifying or re-verifying their digital signatures, keyed hashes, or authentication codes.

  - ACTIVITIES: Trigger an auditable event.

Wait until the next audit log signing event happens.

Verify the signature, keyed hash or authentication code over the last entries, including the audit record of the triggered event, is present in the audit log.

Verify the signature, keyed hash or authentication code over the last entries, including the audit record of the triggered event, is correct.

    - Wait until the next audit log signing event happens.

Modify the audit record of the triggered event, and verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.

    - Verify the signature, keyed hash or authentication code over the last entries, including the audit record of the triggered event, is present in the audit log.

Verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.

    - Verify the signature, keyed hash or authentication code over the last entries, including the audit record of the triggered event, is correct.

    - Modify the audit record of the triggered event, and verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.

    - Verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.

Restore the audit record of the triggered event, if necessary.

    - Restore the audit record of the triggered event, if necessary.

Modify the second-to-last signature, keyed hash or authentication code.

    - Modify the second-to-last signature, keyed hash or authentication code.

Verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.

    - Verify the signature, keyed hash or authentication code to fail over the last entries, including the triggered event.

    - Restore the second-to-last signature, keyed hash or authentication code, if necessary.

    - Wait until the next audit log signing event happens, ensuring no auditable event happens in the meantime.

Restore the second-to-last signature, keyed hash or authentication code, if necessary.

Wait until the next audit log signing event happens, ensuring no auditable event happens in the meantime.

Verify a new signature, keyed hash or authentication code, including at least the previous signature, keyed hash or authentication code, is present in the audit log.

    - Verify a new signature, keyed hash or authentication code, including at least the previous signature, keyed hash or authentication code, is present in the audit log.

  - VERDICT: SUCCESS if all the verifications pass; else FAIL.

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

- REFERENCE: ASS-REQ-6.2-08

  - OBJECTIVE: Verify the frequency of the audit log signing event by the PKI to be configurable.

  - ACTIVITIES: Modify the frequency of the audit log signing event.

Wait sufficiently such that 2 audit log signing events occur.

    - Wait sufficiently such that 2 audit log signing events occur.

Access audit records, and verify the time between the last 2 audit log signing events corresponds to the newly configured frequency.

    - Access audit records, and verify the time between the last 2 audit log signing events corresponds to the newly configured frequency.

  - VERDICT: SUCCESS if the verification passes; else FAIL.

  - PREPARATION: Document public keys manipulated by the PKI outside a secure cryptographic device, and how they are manipulated by the PKI.

Ability to directly modify such a stored public key. Ability to directly modify digital signatures, keyed hashes, or authentication codes associated to such stored public keys.

    - Ability to directly modify such a stored public key. Ability to directly modify digital signatures, keyed hashes, or authentication codes associated to such stored public keys.

Ability to request the public key (if applicable). Ability to trigger an action of the PKI making it use the public key (if applicable).

    - Ability to request the public key (if applicable). Ability to trigger an action of the PKI making it use the public key (if applicable).

  - ACTIVITIES: For every public key stored within the PKI outside a secure cryptographic device:

    e) verify the operation fails because of the state of the public key;

    f) restore the stored public key;

    g) directly modify the digital signature, keyed hash, or authentication code associated to the stored public key;

  - OBJECTIVE: Verify the PKI implements and follows a certificate profile for issued certificates.

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

Document the certificate profile implemented by the PKI.

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

      - Document the certificate profile implemented by the PKI.

  - ACTIVITIES: For each way the PKI may issue a certificate:

  - PREPARATION: Document the circumstances in which the certificate generation service may issue a public-key certificate.

Administrator access to not-installed or reinitialised PKI, or specifically its certificate generation service and related configuration.

    - Administrator access to not-installed or reinitialised PKI, or specifically its certificate generation service and related configuration.

  - ACTIVITIES: For each way the PKI may issue a public-key certificate:

verify that no certificate may be issued until acceptables values for the identified fields and extensions are set.

    - verify that no certificate may be issued until acceptables values for the identified fields and extensions are set.

  - VERDICT: SUCCESS if all the verifications pass; else FAIL.

  - EVIDENCE: The way the CRL was requested, and the response and CRL from the PKI.

- REFERENCE: ASS-REQ-6.5-03

  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.4-03.

  - EVIDENCE: The way CRLs were requested, and the responses from the PKI.

- REFERENCE: ASS-REQ-6.5-04

  - OBJECTIVE: Verify the PKI implements and enforces an OCSP response profile for issued OCSP responses.

  - EVIDENCE: The way the OCSP response was requested, and the response and OCSP response from the PKI.

- REFERENCE: ASS-REQ-6.5-05

  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.4-05.

    b) List of validated functionalities and data access rights for each user profile.

    c) Screenshots or logs of access attempts and rights verification.

#### 6.6 ETSI standard conformity assessment

All requirements in clause 5 including conformity requirement to ETSI 102 941 [\[5\]](#_ref_5) shall ensure conformity based on tests defined in [\[7\]](#_ref_7).

All requirements in clause 5 including conformity requirement to [\[6\]](#_ref_6) shall ensure conformity based on tests defined in [\[8\]](#_ref_8).

# Annex A Mapping with essential requirements of the CRA