The product is defined by the integration of several key elements, including **Product audit & administration**, **Registration**, **Certificate generation**, **Certificate status**, and/or **Revocation management**. Each element exposes functions that are defined in [Product Functions](#41-product-functions). The diagram below provides a high-level overview of the product architecture and the interactions between its constituent elements.
@@ -3828,10 +3829,9 @@ As a result, users of these PKI solutions do not have the same deployment flexib
- 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).
@@ -4021,10 +4021,10 @@ Such PKIs are deployed in highly controlled environments, including robust physi
- 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 [\[i.10\]](#_ref_i.10) defines requirements on security hardware elements of the PKI and requirement of software elements of the PKI for use in eIDAS).
@@ -4181,10 +4181,9 @@ Such PKIs are deployed in highly controlled environments, including robust physi
- EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.
@@ -4326,9 +4325,11 @@ The multi-authority PKI is intended to combine multiple authorities in a single
- 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).