Update after weekly meeting

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

Different uses cases represent different deployment with different sets of architectures, functionalities and thus associated threats and risk. The document specifies requirements to cover or mitigate those risks in conformity with the CRA.

Different use cases represent different deployment with different sets of architectures, functionalities and thus associated threats and risks. The document specifies requirements to cover or mitigate those risks in conformity with the CRA.

It covers main PKI able to support the management of public keys able to support authentication, encryption, integrity or Traceability services including public/open, private, C-ITS and machine-to-machine PKIs.

- <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.4"></span><a name="_ref_i.4">[i.4]</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_i.5"></span><a name="_ref_i.5">[i.5]</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"

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms

| Term  | Definition             |

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

|PKI Software| Software implementing the PKI services: Registration, Certificate generation, Dissemination, Revocation management, Certificate status, Logging of security events, User accounts management, etc.|

|PKI Software| Software implementing the PKI services, including, Registration, Certificate generation, Dissemination, Revocation management, Certificate status, Logging of security events, User accounts management.|

|Certificate| Public key of a user, together with some other information, rendered un-forgeable by encipherment with the private key of the certification authority which issued it. |

|Certificate Policy (CP) | Named set of rules that indicates the applicability of a certificate to a particular community and/or class of application with common security requirements. |

|Certificate Revocation List (CRL) | signed list indicating a set of certificates that have been revoked by the certificate issuer.|

For the purposes of the present document, the [following] abbreviations  apply:

`AA     Authorization Authority (synonym to PCA)`  

`AA     Authorization Authority`  

`AP     Access Point`  

`AT     Authorization Ticket (synonym to PC`  

`AT     Authorization Ticket`  

`CA     Certification Authority`

`CARL   Certification Authority Revocation List`

`C-ITS  Cooperative ITS`   

`SOTA    State of the Art`

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

-	**F.Revocation management service:** processes revocation requests and reports to determine the necessary action to be taken; and provides updates to the certificate status service.

-	**F.Certificate status service:** provides certificate revocation status information to relying parties.

-	**F.Certificate status service:** provides certificate validity and revocation status information to relying parties.

Each component service should ensure that configuration and maintenance is only performed by system administrators.

## 4.3 Architecture

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

Figure 4.3 gives a high-level overview of a generic and illustrative PKI architecture.

![Figure 4.1-1: PKI diagram](media/PKI-diagram.png)

![Figure 4.3-1: PKI diagram](media/PKI-diagram.png)

**Figure 4.1-1: PKI diagram**

**Figure 4.3-1: PKI diagram**

## 4.4 Operationnal Environment

The enterprise should 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. 

The enterprise should have a production system for issuing certificates and should have a separate test system for checking configuration changes and software updates before they are deployed. 

The PKI software should be deployed on servers within the enterprise's server rooms or data centre, or on a platform hosted by the enterprise's cloud service provider.   

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

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 use cases concidered are:

- UC1: Private PKI for none critical sectors small or medium enterprise

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

#### 4.7.2.3 Architecture

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

Figure 4.3-1 in clause 4.3 gives a high-level example of a PKI architecture.

A large enterprise or public PKI might include multiple instances of some component services.

##### 4.7.2.4.1	Deployment

The large enterprise or public CA should 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.

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

The PKI software should typically be deployed on servers within the CA's data centre, but less critical component services can be deployed on a platform hosted by a cloud service provider.