Update file EN-304-624.md

- **F.None_SCD_Based_KeyManagement**: Suppress, export, or renew software keys.

- **F.UserAccountManagement**: Create, modify, assign rights to, and modify the different user accounts.

- **F.PrivateKeyExport**: Private keys, secret keys, or critical data can be encrypted and then exported in the form of an encrypted file.

- **F.OfficerCertificateGenerationApproval**: Privileged users can approve and execute this issuance when certificates are issued.

- **F.OfficerCertificateGenerationApproval**: Authorized users can approve and execute this issuance when certificates are issued.

- **F.CertificateProfileManagement**: Administration functions to define the format and default values of certificates to be signed.

- **F.PseudonymCertificateIssuance**: Issue pseudonym certificates derived from long-term certificates. These certificates shall not include user identification data.

- **F.SubjectCertificate_signatureCreation**: Creates and signs subject certificates using the product's private key.

The product contains the following elements:

<!-- Add definition of below elements -->

Here are the definitions for the requested PKI-related terms:

- **Private Key Store**:

   - Source: ETSI TS 119 495 (C-ITS Security; Trusted Security Entities)

In addition the elements can be configured in multiple ways:

 - **ARC.Monolithic**: All components are integrated and run on a single machine or platform.

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

## 5.6.1 General

### 5.6.1 General

- REFERENCE: 	REQ-PKI-CON-001

  - REQUIREMENT: The product shall provide capabilities to ensure that the private key generated by the product cannot be removed or copied from the product.

  - NOTE: Any PKCs stored in the product are intended for public dissemination and have, depending on the particular certificate specification, explicit means of protecting the content, thus no requirements are placed on the product that define the format and protections inherent to the PKC.

  - APPLICABILITY: XXXX

### 5.6.2 Secure communication with external entities

  - REFERENCE: REQ-5.11-01

  - REQUIREMENT: (TODO - Not to address only C-ITS) The product shall permit secured certificate requests between an external entity and itself if the following rules hold:

    - Sending

        - The requests are encrypted and signed as defined by [\[6\]](#_ref_6) section 6.2.3.4.1 using EA and AA Certificates

        - The Message format is conformant to [\[6\]](#_ref_6) 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 [\[6\]](#_ref_6)  section 6.2.3.4.1

].

   - RATIONALE: The product shall provide protected communication channels for remote administrators, IT entities such as car manufacturer servers (confidentiality and integrity) and other parts of a distributed product (confidentiality, integrity and authenticity).

  - APPLICABILITY: UC4.  

## 5.7 Integrity

_Proposed ESR code: INT_

## 5.7.1 Monitoring 

(TODO cf HAS comment - not to be enforce to less critical use cases - UC1?)

- REFERENCE: REQ-PKI-INT-001

  - REQUIREMENT: The product shall be able to detect unauthorised modifications to the stored audit records during the audit.

  - RATIONALE: The audit record intergrity and availability ensure that all auditable events are traceable and misuse of the product functions can be traced. 

  - APPLICABILITY: TODO All use cases where the product has a certificate generation service.

- REFERENCE: REQ-PKI-EMM-003

  - REQUIREMENT: The product shall enable privileged user to specify the set of acceptable values for the following fields and extensions:

  - REQUIREMENT: The product shall enable authorized users to specify the set of acceptable values for the following fields and extensions:

    - the authority key identifier;

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

    - the identifier of the certificate issuer;

    - the length of time for which the certificate is valid.

  - RATIONALE: Only valid certificates, as defined by privileged users in conformity with the PKI certificate policy, shall be generated by the product.

  - RATIONALE: Only valid certificates, as defined by authorized users in conformity with the PKI certificate policy, shall be generated by the product.

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

- REFERENCE: REQ-PKI-EMM-004

  - REQUIREMENT: The product shall require priviledged users to specify the set of acceptable values for the following fields and extensions:

  - REQUIREMENT: The product shall require authorized users to specify the set of acceptable values for the following fields and extensions:

    - keyUsage;

    - basicConstraints;

    - certificatePolicies.

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

### 5.12.2 Certificate status

- REFERENCE: REQ-PKI-EMM-008

  - 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

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

- REFERENCE: REQ-PKI-EMM-009

  - REQUIREMENT: The product shall implement a CRL profile and shall ensure that issued CRls are consistent with that profile.

  - RATIONALE:  The product shall provide accurate and integrity protected certificates statues using the standardised CRL format ensuring integrity of revocation list and conformity to the product service provider chosen policies. 

  - APPLICABILITY: Where the product has a certificate status service, issuing CRLs: UC1 and UC2.

- REFERENCE: REQ-PKI-EMM-010

  - REQUIREMENT: TODO(Specify that it is for CRL?) The product shall require authorized users to specify the set of acceptable values for the following fields and extensions:

    - issuer;

    - issuerAltName;

    - nextUpdate.

  - RATIONALE: The product shall provide accurate and integrity protected certificates statues using the standardised CRL format ensuring integrity of revocation list and conformity to the product service provider chosen policies. 

  - APPLICABILITY: Where the product has a certificate status service, issuing CRLs: UC1 and UC2.

  - NOTE: The issuerAltName may be absent from the profile if issued certificates do not use it.

- REFERENCE: REQ-PKI-EMM-011

  - REQUIREMENT: The product shall implement an OCSP response profile and shall ensure that issued OCSP responses are consistent with that profile.

  - RATIONALE: The product shall provide accurate certificates statusas defined by the service provider chosen policies. 

  - APPLICABILITY: Where the product has a certificate status service, issuing OCSP responses.

- REFERENCE: REQ-PKI-EMM-012

  - REQUIREMENT: The product shall require authorized users to specify the set of acceptable values for the responseType field.

  - RATIONALE: The product shall provide accurate certificates statusas defined by the service provider chosen policies. 

  - APPLICABILITY: Where the product has a certificate status service, issuing OCSP responses, not restricted to the basic response type: UC1 and UC2.

- REFERENCE: REQ-PKI-EMM-013

  - REQUIREMENT: The product shall require authorized users to specify the set of acceptable values for the responderID field.

  - RATIONALE: The product shall provide accurate certificates status as defined by the service provider chosen policies. 

  - APPLICABILITY: Where the product has a certificate status service, issuing OCSP responses of the basic response type: UC1 and UC2.

  - NOTE: An OCSP responder is required to be capable to emit OCSP responses of the basic type by RFC 6960 [\[i.3\]](#_ref_i.3).

## 5.13 Logging and monitoring

The assessment criteria specified in CEN/CLC JT013090:2026 (CEN/CLC prEN 40000-1-3) [\[2\]](#_ref_2) 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

The present document has been prepared in response to the Commission's standardisation request C(2025)618 [\[i.3\]](#_ref_i.3) to provide, in additions to its other uses, one voluntary means of conforming to the essential requirements of Regulation (EU) 2024/2847 [\[i.1\]](#_ref_i.1) known as the Cyber Resilience Act (CRA).

> NOTE 3: The last two columns shall be either filled with details and the reference of the table(s) mapping the applicability of the technical cybersecurity requirements, or deleted all together.

</div>

|No |Description |Requirements of Regulation |Clause(s) of the present document |U/C |Condition |

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

|1| Annex I, Part 1, (1)|“Products with digital elements shall be designed, developed and produced in such a way that they ensure an appropriate level of cybersecurity based on the risks.” | Clause 5 | C | See mapping table on the applicability of the technical cybersecurity requirements in clause 5.1|

  **Condition**   Explains the conditions when the requirement is or is not applicable for a requirement which is classified "conditional".

Presumption of conformity stays valid only as long as a reference to the present document is maintained in the list published in the Official Journal of the European Union. Users of the present document should consult frequently the latest list published in the Official Journal of the European Union.

Other Union legislation may be applicable to the product(s) falling within the scope of the present document.

# Annex B (informative): Cybersecurity threat landscape, risk identification and assessment methodology

This Annex applies a “state of the art” risk assessment methodology to the Product in scope of the present document, to identify threats, evaluate the risks and define security profiles applicable to the different use cases of the product context.

</div>

The core technical metrics for determination of the likelihood of a particular cyber-attack are defined in clause B.6 of the Common Criteria Evaluation methodology [] and further developed in clause 6.7 of TS §102 165-1 [] and then updated as shown in table B.2 of the present document. As identified in both the Common Criteria Evaluation methodology [] and in TS 102 165-1 [] an assessment of the likelihood of an attack is assessed from evaluation of a number of attributes of the attack and attacker including Time, Expertise, Knowledge, Opportunity, Equipment and motivation.

<div align="center">

**Table B.2: likelihood metric for use in risk calculation modified from table 4 of TS 102 165-1 []**

> NOTE: Because risk is calculated as the product of likelihood and impact the values 5, 7 and 8 cannot occur.

</div>

## B.2 Risk Assessment

### Deployment