Update file EN-304-624.md

# 1 Scope

The present document specifies requirements and assessment criteria covering all elements defined in CRA Annex I Part 1 and Part 2 for Public key infrastructure (PKI) and digital certificate issuance software.

The present document covers the specification of Security Profiles (SP) for the main PKI use cases to demonstrate compliance with requirements in the EU Regulation 2024/2847 under the conditions identified in annex. 

|C-ITS|Cooperative ITS|

|C-ITS|Cooperative ITS|

|CP|Certificate Policy|

|CPOC|C-ITSÊPoint of Contact|

|CPOC|C-ITS-Point of Contact|

|CPS|Certification Practice Statement|

|CRL|Certificate Revocation List|

|DC|Distribution Center|

|TSP|Trust Service Provider|

# 4 Product contexts

# 4 PKI software contexts

> NOTE: This section's structure is built upon CEN/CLC JTC13 PT01's deliverable and might require restructuring based on its progress. 

## 4.1 General

### 4.1.1 PKI products

## 4.1 Intended purpose of use

### 4.1.1 In scope

The present clause describes product contexts for products with digital elements used as part of a public key infrastructure (PKI) that manage the validation, creation, issuance, distribution, status publication, renewal or revocation of digital certificates, or the generation, storage, escrow, exchange, destruction or rotation of cryptographic keys associated with such digital certificates.  

<mark>

PSC: The existing structure implies there is a single product with different security profiles.  In practice, there will be different products for different contexts.  It is clearer to present these separately with any general comments collected in 4.1.

</mark>

Those products can be used in diffe

### 4.1.2 Out of scope use/environments

### 4.1.2 Out of scope 

_List uses/environments covered by other legislation or standards, such as industrial operations, automotive, transport, marine, airplane, medical, military, national security, etc. Hoping to have a reusable generic list of these soon._

PKI-as-a-service and software-as-a-service are out of scope of the present document.

PKI-as-a-service and software-as-a-service are out of scope of the present document. Also, security requirements for secure cryptographic devices are out of scope of the present document.

Security requirements for secure cryptographic devices are out of scope of the present document.

<mark> FIXME </mark>

Commission Implementing Regulation (EU) 2024/2690 for the application Directive (EU) 2022/2555 (NIS2) on cybersecurity measures applies to managed security service providers which use PKI techniques.  The software components of a managed security service provider compliant to standardised PKI certificate policies, which incorporate the requirements of Commission Implementing Regulation (EU) 2024/2690, can be assumed to meet the requirements of the CRA and hence need not apply the requirements specified in the present document.

### 4.1.3 Product overview and architecture

### 4.2 Main functionalities

_Explain the overall architecture and relationship among the parts of the products. Use diagrams if that is helpful._

<mark> FIXME include the current vertical definition supplied by the EC, use that as a starting point.

<mark> FIXME include the relation graphic between verticals here to explain the outside relationship.

<mark> FIXME: Use generic architectural descriptions (monolithic, microkernel, ...) or create a list of orthogonal properties (hardware access control for drivers, address space separation, ...) and differentiate based on that? 

<mark> PSC: This could be used for a generic architecture description.</mark>

### 4.1.3.1 PKIs main and reference fonctionnalities

PKI products support one or more of the following component services (see ETSI EN 319 411-1):

  - <strong>System operator account:</strong> authorised to operate the PKI services. 

### 4.1.3.2 Architecture

## 4.3 Architecture

Figure 4.1 gives a high-level overview of a PKI architecture.

</div>

### 4.1.3.3 Main use cases

PKIs can take many forms and this standard doesn't aim to cover all possible PKI's service implementations and the associated PKI product required for these implementations. The uses cases concidered are:

<mark> FIXME: to be validated / taken in charge.</mark>

- Private PKI for small or medium enterprise

- Private PKI for large enterprise

- Open or public PKI 

- C-ITS PKI

- Machine-2-Machine

<mark> FIXME: to be validated.</mark>

Security Profiles are defined for those specific use cases. Products not directly matching those use cases have to refine one of those profile to adapt them to there own risk analaysis.

In the <strong>SME product context</strong>, a single instance of a self-contained PKI product will typically support all of the required PKI functionality.

However, some component PKI services might not be necessary or could be supported through generic enterprise products and services.

EXAMPLE 1: The registration service is not needed as subscriber enrollment and certificate request approvals are handled through normal enterprise on-boarding and account management processes.

EXAMPLE 2: The revocation managment and certificate status services are not needed as compromised certificates can be mitigate through normal enterprise account management and off-boarding processes.

EXAMPLE 3: The dissemination service is not needed as an enterprise directory service can be used to store and distribute certificates.

# 5 Security Profiles

## 5.1 Private PKI for SME

### 5.1.1 Operational environment

#### 5.1.1.1 Deployment

## 4.4 Operationnal Environment

The enterprise will have a production system for issuing certificates and can be expected to have a separate test system for checking configuration changes and software updates before they are deployed. 

NOTE 2:	Security requirements for secure cryptographic devices are out of scope of the present document.

#### 5.1.1.2	Physical security

### 4.4.1	Physical security

An enterprise server room or data centre will have some physical access controls.

A cloud service provider will have strong physical security measures in place, but the servers hosting the PKI software will not be physically separated from other infrastructure.

#### 5.1.1.3	Network security

### 4.4.2	Network security

The enterprise will implement security controls such as firewalls on the edge of their network.

The enterprise will deploy malware detection and removal software on their systems.

### 5.1.5 Users competences

### 4.4.3 Users competences

The enterprise will employ competent system administrators to install, configure and manage the software.

However, system operators might have limited experience running critical component services and might have only received basic training in cybersecurity or data protection.

## 4.5 Distribution of security functions

## 4.6 Users

## 4.7 Use cases

PKIs can take many forms and this standard doesn't aim to cover all possible PKI's service implementations and the associated PKI product required for these implementations. The uses cases concidered are:

- Private PKI for none critical sectors small or medium enterprise as defined by NIS2 directive

- Private PKI for large enterprise or critical sectors enterprise as defined by NIS2 directive

- Open or public PKI for Certficate Authorities (CA) 

- C-ITS PKI

Security Profiles are defined for those specific use cases. Products not directly matching those use cases have to refine one of those profile to adapt them to there own risk analaysis.

In the <strong>SME product context</strong>, a single instance of a self-contained PKI product will typically support all of the required PKI functionality.

However, some component PKI services might not be necessary or could be supported through generic enterprise products and services.

EXAMPLE 1: The registration service is not needed as subscriber enrollment and certificate request approvals are handled through normal enterprise on-boarding and account management processes.

EXAMPLE 2: The revocation managment and certificate status services are not needed as compromised certificates can be mitigate through normal enterprise account management and off-boarding processes.

EXAMPLE 3: The dissemination service is not needed as an enterprise directory service can be used to store and distribute certificates.

### 5.1.2 Assets

#### 5.1.2.1 System administration

</div>

### 5.1.4 Risks

TODO

### 5.1.5 Requirements

## 4.7.2 Critical entities and public CA PKI software

TODO

## 5.2 Large enterprise and public PKI

### 5.2.1 Use

### 4.7.2.1 Use

The reasonably foreseeable use of the PKI product is to support certification services provided within a large enterprise or provided by a CA to the public, and where a compromise carries a significant risk of impact to the security of other products, networks or services, or to the health, security or safety of the public.

EXAMPLE 3: Software used to issue certificates for central government public administration organisations. 

### 5.2.2 Functionality

#### 4.7.2.2 Functionality

#### 5.2.2.1 Services

##### 4.7.2.2.1 Services

The PKI product will support one or more of the following component services (see ETSI EN 319 411-1):

Each component service will require configuration and maintenance by system administrators.

#### 5.2.2.2 Logging

##### 4.7.2.2.2 Logging

The PKI product will support logging of security events; for example, account access attempts, product configuration changes, and system warnings or errors.

- Revocation management service events such as revocation requests and results.

#### 5.2.2.3 Accounts

##### 4.7.2.2.3 Accounts

In the large enterprise and public PKI product context, the product will support at least the following user accounts:

- <strong>System auditor account:</strong> authorised to view audit logs and other syste data.

### 5.2.3 Architecture

#### 4.7.2.3 Architecture

Figure 4.1 in clause 4.2.3 gives a high-level example of a PKI architecture.

EXAMPLE 5: A third-party logging service might be used to store and manage event logs. 

### 5.2.4 Operational environment

### 4.7.4 Operational environment

#### 5.2.4.1	Deployment

##### 4.7.2.4.1	Deployment

The large enterprise or public CA will have a production system for issuing certificates and can be expected to have separate development or test systems for checking configuration changes and software updates before they are deployed.

NOTE 2:	Security requirements for secure cryptographic devices are out of scope of the present document.

#### 5.2.4.2	Physical security

##### 4.7.2.4.2	Physical security

The CA will locate production infrastructure supporting security critical component services such as certificate generation in a secure perimeter with physical protection against intrusion and physical controls limiting access to authorised personnel.

The CA will implement measures to prevent a compromise or interruption of its services due to an electricity, network, or other utility failure. 

#### 5.2.4.3	Network security

##### 4.7.2.4.3	Network security

The CA will implement change control procedures for any software updates and configuration changes.

The CA will block protocols and disable accesses that are not needed for PKI operations. 

### 5.2.5 User description 

##### 4.7.2.4.3 Users competences 

A large enterprise or public CA will employ staff who have the necessary expertise and experience for their roles, including an understanding of cybersecurity and data protection where relevant.

The CA will enforce separation between trusted roles with conflicting responsibilities such as system operators and system auditors.

### 5.2.6 Assets

### 5.2.7 Threats

### 5.2.8 Risks

### 5.2.9 Requirements

## 5.3 C-ITS PKI

### 4.7.3 C-ITS PKI

A Public Key Infrastructure (PKI) dedicated to Communicating Intelligent Transport Systems (C-ITS) is used to manage ITS related certificates  to enable deployment of security functions over the different components of ITS systems, mainly signature and encryption of ITS messages. The PKI is responsible for the issuance, revocation, and overall management of certificates and certificate status information.

The PKI architecture and its functionalities considered here are the one standardized by the ETSI in ETSI TS 102 940 and ETSI TS 102 941.

The C-ITS PKI shall provide the different services required by the RCA, EC and AA roles defined by the European C-ITS trust model. In the figure we also identify the role of a Misbehaviour Authority (MA): entity responsible to receive misbehaviour reports coming from ITS-S identifying other misbehaving ITS and emits action requests to the other C-ITS PKI authorities to react to misbehaving behaviour of ITS-S. The current PP does not define requirement for the MA services since the MA communication and services are not yet fully define and standardized. However the PP should be updated when it is.

![~~CAPTION~~](media/C-ITS_PKI_Architecture.png)

#### 5.3.1 Assets

#### 4.7.3.1 Assets

| Name | Description | Security needs |

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

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

### 5.3.2 Essential Functions

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

#### 5.3.3 Operationnal environment

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

#### 5.3.3.4  Users

##### 4.7.3.3.4  Users

| Level 1 | Level 2 | Level 3 |

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

| Officer EA |

| Officer AA |

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

#### 5.3.3.5  Threats

##### 4.7.3.3.5  Threats

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

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

#### 5.3.3.6  Risks

#### 5.3.3.7  Requirements

# 5  Requirements for PKI products

**R.PKI_Trust_Elements** - The C-ITS PKI shall ensure that certificates (RCA, EA, AA, EC, AT), certificate revocation lists and certificate trust list are valid (format and integrity).

**R.Protected_None_ITS_ Communications** - The C-ITS PKI will provide protected communication channels for remote administrators, IT entities such as car manufacturer servers (confidentiality and integrity) and other parts of a distributed C-ITS PKI (confidentiality, integrity and authenticity). 

**R.Secured_Authority_Request** The C-ITS PKI shall protect in confidentiality, integrity and authenticity the Authorities requests.

**R.Secured_Authority_Request** - The C-ITS PKI shall protect in confidentiality, integrity and authenticity the Authorities requests.

**R.Secured_Response** - Upon receiving requests from ITS-S or other CAs (certificate requests or Authorization validation requests), the C-ITS PKI shall verify the data confidentiality, integrity and authenticity before validating the request format and content. The C-ITS PKI shall respond to valid requests by generating requested certificates or authorization validation response. The C-ITS PKI shall send them back to the ITS-S or CAs ensuring the confidentiality, integrity and authenticity of the responses. 

# Conformity assessment

- **Reference** - 

- **Objective** - 

- **Prerequisites** - 

- **Assessment Activities** - 

- **Assessement of the verdict** -

- **Supporting Evidence** -

# Annex B: <br>Title of annex

## B.1 First clause of the annex

## B.1.1 First subdivided clause of the annex