@@ -516,20 +516,27 @@ The product contains a number of assets that need privileged access to use. The
The use cases considered are:
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.
-**UC1**: Private PKI for non critical entities.
-**UC2**: Private PKI for critical entities.
-**UC3**: Open or public PKI for critical entities.
-**UC4**: Open or Public basic PKI.
-**UC5**: 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
### 4.6.1 Product for use in Private PKI for non critical sectors (UC1)
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.
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 1: Products deployed to support software maintenance.
- EXAMPLE 2: Products deployed to support internal IT service for network security deployments (e.g. VPN, ssh, TLS servers).
- EXAMPLE 3: User management (identification and authentication) for services like User & Device Authentication, Single Sign-On (SSO).
### 4.6.2 Product for use in Private PKI for critical entities (UC2)
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,
@@ -539,22 +546,31 @@ Critical entities often need to produce their own certificates to manage sensiti
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.
> - EXAMPLE: eIDAS
- EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.
- EXAMPLE 2: Telecom service provider.
### 4.6.3 Product for use in Public CA PKI
### 4.6.3 Open or public PKI for critical entities
- EXAMPLE 1: Products deployed for a PKI used in large enterprise or critical entities (e.g, eIDAS where in the context of the present document ETSI EN 319 411-1 [] defines requirements on security hardware elements of the PKI and requirement of software elements of the PKI for use in eIDAS).
### 4.6.4 Product for use in Open or Public basic PKI (UC4)
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.
### 4.6.4 Product for use in multi-authority PKI
- EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.
- EXAMPLE 2: Products deployed by telecommunications service providers used to manage proofs of identity, authorization, and encryption to enable secure access to internal services and customer-facing networks, including e.g. 5G core and edge systems, as standardized in 3GPP TS 33.501 and ETSI GS NFV 003. The PKI product is responsible for the issuance, revocation, and overall management of certificates and certificate status information (e.g., via CRLs or OCSP).
### 4.6.5 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.
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 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 [].
- 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.
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).
- 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>
