Editing Use cases and Security profile based on existing CC PPs and WI...

<div align="center">

**ETSI EN 304 624 DDD Vm.t.e (yyyy-mm)**

**ETSI EN 304 624 DDD Vm.t.e (2025-08)**

![~~CAPTION~~](media/etsi-coverpage-logo.png)

CRA;<br />

Essential cybersecurity requirements for Public key infrastructure and digital certificate issuance software<br />

Essential cybersecurity requirements for Public key infrastructure and digital certificate issuance software;<br />

Release #

0.0.1

</div>

© ETSI yyyy.

© ETSI 2025.

All rights reserved.<br />

# 1 Scope

## 1.1 General

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 and digital certificate issuance software.

The present document covers the ………. (add the scope of the standard) to demonstrate compliance with requirements in the EU Regulation 2024/2847 under the conditions identified in annex <L>.

## 1.2 Products in scope

## 1.3 Products not in scope

# 2 References

For the purposes of the present document, the [following] abbreviations [given in ... and the following] apply:

# 4 Product context

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

# 4 User defined clause(s) from here onwards

The present clause describes general and higher assurance product contexts for software products with digital elements used as part of Public Key Infrastructure (PKI) to manage the validation, creation, issuance, distribution, status publication, renewal or revocation of digital certificates.  

## 4.1 User defined subdivisions of clause(s) from here onwards

## 4.1 Use

The present clause describes general and higher assurance product contexts for software products with digital elements used as part of Public Key Infrastructure (PKI) to manage the validation, creation, issuance, distribution, status publication, renewal or revocation of digital certificates.  

<br />

## 4.1.1 General

# Annex A: <br>Title of annex

## 4.2 Out of scope use/environments

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

<mark> FIXME </mark>

## 4.3 Product overview and architecture

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

## 4.3 Use cases

## 4.4 Essential functions

## 4.5 Security Profiles

The reasonably foreseeable use of the product is to support certification services provided by a Certification Authority (CA) to the public or to organisations in a critical sector, 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 1:	Software used to issue certificates for public web sites.

NOTE 1:	Critical sectors include those listed in Annex I or II of Directive (EU) 2022/2555.

EXAMPLE 2: 	Software used to issue certificates for the energy sector. 

### 4.5.1 Security Profile 1 (SP1) - Enterprise PKI

#### 4.5.1.1  SP1 - Assets

#### 4.5.1.2  SP1 - Essential Functions

#### 4.5.1.2.1 Services

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

    • Registration service: registers and receives certificate requests from subscribers; verifies the identity and, if applicable, attributes of a subject; and passes verified certificate requests to the certificate generation service.

EXAMPLE 1:	This service verifies ownership of the domain in requests for public web site certificates. 

EXAMPLE 2:	This service verifies ownership of the email account in requests for email encryption and signing certificates.

NOTE 1:	This service includes proof of possession of, or control over, subject private keys when these are not generated by the certificate generation service.

NOTE 2:	If subject private keys are generated and stored by the certificate generation service to allow key recovery, this service receives and verifies key recovery requests from subscribers. 

NOTE 3:	Registration and verification of subject identities can involve personal data such as contact details and passport information.

    • Certificate generation service: generates and manages the CA keys; creates and signs subject certificates based on the identity and other attributes verified by the registration service; and passes the signed subject certificates to the dissemination service.

NOTE 4:	The certificate profile used in certificate creation, including the signature algorithm, certificate lifetime and key usage restrictions, is determined by the CA's Certificate Policy (CP) or an equivalent document.

NOTE 5:	This service will typically use a secure cryptographic device to generate, store and use the CA keys.

NOTE 6:	This service can include generation of subject keys and, if used for decryption, storage of subject private keys to allow key recovery.

    • Dissemination service: disseminates signed certificates to subscribers; and, if the subscriber consents, stores and makes them available to relying parties.

NOTE 7:	This service can make available the CA's terms and conditions, policy and practice information to subscribers and relying parties.

NOTE 8:	This service can disseminate subject private keys to subscribers if the subject keys are generated by the certificate generation service.

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

EXAMPLE 4:	This service verifies that revocation requests are submitted by authorised parties.

EXAMPLE 5:	This service obtains confirmation from the subscriber if a compromise is reported by a third party.

    • Certificate status service: provides certificate revocation status information to relying parties.

EXAMPLE 6:	This service publishes Certificate Revocation Lists (CRLs) and responds to Online Certificate Status Protocol (OCSP) queries.

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

#### 4.5.1.2.2 Logging

In both contexts, the product will support logging of security events such as account access attempts, product configuration changes, and system warnings or errors.

The product will typically support some logging of events relevant to each of the component service it provides:

    • Registration service events such as certificate requests and approvals.

    • Certificate generation service events such as subject key generation and certificate signing operations.

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

#### 4.5.1.2.2 Accounts

In both contexts, the product will support one or more of the following user accounts:

    • System administrator account: authorized to install, configure and update the product.

    • System operator account: authorized to operate the PKI services and perform system backups. 

NOTE:	This might consist of separate registration service operator, certificate generation service operator and revocation service operator accounts.

    • System auditor account: authorized to view audit logs and other system data.

#### 4.5.1.3  SP1 - Operationnal environment requirements

#### 4.5.1.4  SP1 - Users

#### 4.5.1.5  SP1 - Threats

From Certificate Issuing and Management Components Protection Profile Version 1.5  11 August, 2011

Threats - Authorized Users

T.Administrative errors of omission - Administrators, Operators, Officers or Auditors fail to perform some function essential to security.

T.Administrators, Operators, Officers and Auditors commit errors or hostile actions – An Administrator, Operator, Officer or Auditor commits errors that change the intended security policy of the system or application or maliciously modify the system’s configuration to allow security violations to occur.

T.User abuses authorization to collect and/or send data - User abuses granted authorizations to improperly collect and/or send sensitive or security-critical data.

T.User error makes data inaccessible -  User accidentally deletes user data rendering user data inaccessible.

Threats - System

T.Critical system component fails - Failure of one or more system components results in the loss of system critical functionality. Threat agent in this case is the CIMC hardware. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Flawed code  A system or applications developer delivers code that does not perform according to specifications or contains security flaws. Threat agent in this case is the TOE developer. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Malicious code exploitation -An authorized user, IT system, or hacker downloads and executes malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality of the system assets. Threat agent could be an authorized user, TOE itself, or an unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying

party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Message content modification - A hacker modifies information that is intercepted from a communications link between two unsuspecting entities before passing it on to the intended recipient. Threat agent is an unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

Threats – Cryptography

T.Disclosure of private and secret keys - A private or secret key is improperly disclosed. Threat agent is the authorized user or erroneous protocol. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Modification of private/secret keys - A secret/private key is modified. Threat agent is the authorized user or erroneous protocol. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP

Responses.

T.Sender denies sending information - The sender of a message denies sending the message to avoid accountability for sending the message and for subsequent action or inaction. Threat agent is a subscriber to CIMC. Adverse action can be reduced trust in CIMC.

Threats – External Attacks

T.Hacker gains access - A hacker masquerades as an authorized user to perform operations that will be attributed to the authorized user or a system process or gains undetected access to a system due to missing, weak and/or incorrectly implemented access control causing potential violations of integrity, confidentiality, or availability. Threat agent is the unauthorized user.

T.Hacker physical access - Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses. A hacker physically interacts with the system to exploit vulnerabilities in the physical environment, resulting in arbitrary security compromises. Threat agent is the unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Social engineering - A hacker uses social engineering techniques to gain information about system entry, system use, system design, or system operation. Threat agent is the unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

#### 4.5.1.6  SP1 - Risks

#### 4.5.1.7  SP1 - Requirements

### 4.5.2 Security Profile 2 (SP2) - Web PKI

#### 4.5.2.1  SP2 - Assets

#### 4.5.2.2  SP2 - Essential Functions

#### 4.5.2.3  SP2 - Operationnal environment requirements

#### 4.5.2.4  SP2 - Users

#### 4.5.2.5  SP2 - Threats

#### 4.5.2.6  SP2 - Risks

#### 4.5.2.7  SP2 - Requirements

### 4.5.3 Security Profile 3 (SP3) - 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 TOE 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 TOE 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.

#### 4.5.3.1  SP3 - Assets

#### 4.5.3.2  SP3 - Essential Functions

#### 4.5.3.3  SP3 - Operationnal environment requirements

#### 4.5.3.4  SP3 - Users

#### 4.5.3.5  SP3 - Threats

#### 4.5.3.6  SP3 - Risks

#### 4.5.3.7  SP3 - Requirements

<br />

# Annex B: <br>Title of annex