Completed clause 4. 4.7 must be move to annexe

Standardization requirements for Smart Contracts

based on Electronic Ledgers" - V1.1.1, October 2025

- <span id="_ref_i.16"></span><a name="_ref_i.16">[i.16]</a> ETSI TS 102 940: “Intelligent Transport Systems (ITS); Security; ITS communications security architecture and security management; Release 2” — V2.1.1, July 2021.

# 3 Definition of terms, symbols and abbreviations

- **U.Auditor**: Authorized to monitor and review product operations logs to ensure compliance and security.

- **U.End_User**: Individuals or systems that request certificates or check certificate status for authentication, encryption, or digital signing purposes.

## 4.7 Use cases

## 4.6 Use cases

The use cases considered are:

- UC1: Private PKI for non-critical entities

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

- UC3: Open or public PKI for Certficate Authorities (CA)

- UC4: C-ITS PKI

- UC5: Machine to machine

PKIs can take many forms and the present document does not aim to cover all possible services and their implementations but uses the use cases to assist in identifying the product requirements for these implementations. The uses cases considered are:

- **UC1**: Private PKI for non critical sectors small or medium enterprise.

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

- **UC3**: Open or public PKI for Certificate Authorities (CA).

- **UC4**: Multi-authority PKI.

<mark>Each use case should clearly specify the users and privileges associated to each user. Details of these rights and privileges for each use case are given in Annex … In addition each use case should specify any constraints on the persistence of relationships, access or use of assets.</mark>

### 4.6.1 Product for use in Private PKI

A private enterprise using public-key cryptography that manages a PKI internally to the enterprise. The enterprise therefore manages the policy framework, the generation of key pairs, the certification of key pairs and the purposes of keys.

In such organisations the PKI may be organised on department centric hierarchies, or on location centric hierarchies, or on organisation role hierarchies or some combination of these. Whilst the set of services to be enabled by the PKI in this use case are large they may include VPN access and management, timestamp services, disk or message encryption, email. and document access and distribution and so on. The deployment of such a private Public Key Infrastructure (PKI) is not driven by regulatory or standardized requirements but rather by the need to align with the entity’s internal policies and security practices.

Additionally, users of these PKI solutions often prioritize flexibility and ease of use over highly secure but restrictive technologies. For instance, they will not rely on secure cryptographic devices but rather have private keys stored using operating system or platform key management facilities that provide protection against unauthorised access at rest. The manufacturer shall document the protection mechanisms relied upon and their limitations. Where the platform facility supports hardware-backed protection (e.g. TPM), this should be the preferred configuration.

### 4.6.2 Product for use in Critical entity PKI

> - EXAMPLE: eIDAS

Security Profiles are defined for those specific use cases. Those profiles are the combination of the security and assessment requirements applicable to each use cases. In section 5 requirements are associated to an applicability condition which depends on the use cases risks analysis as defined in Annex C.

Critical entities often need to produce their own certificates to manage sensitive IT and network services. These services include VPNs, remote SSH connections, timestamp services, disk or message encryption, and PDF signatures. The deployment of such a private Public Key Infrastructure (PKI) is governed by regulatory or standardized requirements, which impose strict constraints, such as:

- Network and physical security,

- Encryption and access control of digital data,

- Incident reporting obligations,

- Compliance with secure operational practices.

As a result, users of these PKI solutions do not have the same deployment flexibility as in less regulated use cases (e.g., UC1). However, they are still permitted to use PKI products that offer diverse functionalities.

Products not directly matching those use cases have to refine one of those profile to adapt them to their own risk analaysis.

In the **Private PKI product context**, a single instance of a self-contained PKI product should typically support all of the required PKI functionality.

### 4.6.3 Product for use in Public CA PKI

PKI product used to support certification services provided within very large multi-site company or provided by a CA to the public, and where a compromise carries a significant risk of impact to the security of remote or unknown users, other products, networks or services, or to the health, security or safety of the public.

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.

### 4.6.4 Product for use in multi-authority PKI

In general terms the multi-authority model separates the entity responsible for authentication from the entity responsible for authorisation of specific services, in like manner to the model of Kerberos [[i.5](#_ref_i_5)] but applied to a public key system.

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

The multi-authority PKI is intended to combine multiple authorities in a single (extended) domain, sharing resources, and enforcing minimisation of identifying data. In like manner to Kerberos the certificate model in multi-authority PKI enables anonymous or pseudonymous proof of authority. The product in multi-authority PKIs is expected to be able to generate and distribute signed attestations of authority, to verify any received attestation of authority, and to maintain the status of stored public keys.

EXAMPLE 1:	The PKI dedicated to Co-operative Intelligent Transport Systems (C-ITS) is used to manage proofs of authorisation and identity to enable access to services on different components of ITS systems standardized in ETSI TS 102 940 [[i.16](#_ref_i_16)] and ETSI TS 102 941 [[i.7](#_ref_i_7)]. The PKI product is responsible for the issuance, revocation, and overall management of certificates and certificate status information. The PKI service architecture and its functionalities considered here are the one .The C-ITS PKI standards provide the basis for the European C-ITS trust model [].

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

NOTE 1:	For the C-ITS example within this use case the product requirements for the ITS-Station acting as a signature creation and verification element the European C-ITS trust model specifies that the ITS-S conforms to a specific protection profile.

NOTE 2:	In the C-ITS model the product uses pseudonymous key pairs and cycles them rapidly and the product may need to have multiple key pairs maintained at any one time, this may place constraints on the number of private keys that have to be maintained in the product.

EXAMPLE 2:	In a smart contract environment, such as that outlined in ETSI TR 119 540 [[i.15](#_ref_i_15)], the chain of trust requires that a device operates within multiple trust domains across and evidenced in the use of a distributed ledger wherein some entries may be signed as proof of an attribute attestation (e.g. a contractual state transition), or signed as proof of an identity attestation (e.g. identifying the legal entity that is a smart contract stakeholder).

<mark>The use cases may be defined by a combination of the product context elements described in clauses 4.1 to 4.5.</mark>

### 4.7.1 Private PKI for non-critical entities