@@ -720,9 +720,7 @@ In such organisations the PKI may be organised on department centric hierarchies
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 (SCD) 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.
- 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 Private PKI for critical entities (UC2)
@@ -736,7 +734,6 @@ 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 products that offer diverse functionalities.
- 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 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 Public PKI for critical entities (UC3)
@@ -762,7 +759,6 @@ The multi-authority PKI is intended to combine multiple authorities in a single
- 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 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 EU C-ITS security credential management system [\[i.20\]](#_ref_i.20).
- 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).
