@@ -546,15 +546,11 @@ 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.
Depending on more specific sectorial or regulation constraints, this use case can be subdivided in two when:
- these PKI rely on SDC (UC2a)
- or not (UC2b) if not mandatory
- 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.3 Open or public PKI for critical entities
### 4.6.3 Open or public PKI for critical entities (UC3)
- 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).
