Logical environments include the connected systems around the main product that shape how it operates in its environment. The trusted boundary is affected by potential third party software that runs on the product, data links to the outside world using radio interfaces, and user permissions and access control.
## 4.3 Operational Environment
### 4.3.1 General description
The physical environment of the product may include ...
<mark>Editor's note == Add in any abstracted constraints from ESI (eIDAS) and ITS and refer to the policy establishing the operational environment.</mark>
Each component defining the Product is accessible through the interfaces defined below.
For the physical operational environment, the following environments are addressed for the Main Products.
<mark>Interfaces are accessible through logical environment (COM.Local, COM.StrictLocal...), Therefore, I.LocalInterface becomes useless as it is a combination of COM.StrictLocal and I.AuditAndAdministration. I suggest then, to remove I.LocalInterface.</mark>
Logical environments include the connected systems around the main product that shape how it operates in its environment. The trusted boundary is affected by potential third party software that runs on the product, data links to the outside world using radio interfaces, and user permissions and access control.
For the logical operation environment, the following digital communication types are addressed for any architectural component of the product.
-**COM.Public** - ingoing/outgoing communication from/to public networks
-**COM.Adjacent** - ingoing/outgoing communication from/to private networks which does not require physical proximity to the communication partner
-**COM.Local** - ingoing/outgoing communication which requires physical proximity to but not physical presence at the communication partner
-**COM.StrictLocal** - ingoing/outgoing communication which requires physical presence at the communication partner
Each component defining the Product is accessible through the interfaces defined below.
-**I.UI** - Local user interface used by the different privileged users to access the product functionalities and data.
-**I.AuditAndAdministration** - Interface for remote access to for product for administration and audit purposes.
**I.NetworkServices** - Interface to local network services (secure storage, timesources, user directory
## 4.3 Operational Environment
<mark>El-Houari Suggestion :</mark>
### 4.3.1 General description
<mark>Interfaces are accessible through logical environment (COM.Local, COM.StrictLocal...), There I.UI becomes useless as it is a combination of COM.StrictLocal and I.AuditAndAdministration. Threfore, I suggest to remove I.UI.</mark>
The operational environment of the product includes the physical environment, the logical environment, and the specific connectivity environment in which the product is deployed and communicates with external elements.
### 4.3.2 Physical/Hardware environment
An enterprise server room or data centre should have some physical access controls.
For the physical operational environment, the following environments are addressed for the Main Products.
A cloud service provider should have strong physical security measures in place, but the servers hosting the PKI software should not be physically separated from other infrastructure.
For the physical operation environment, the following environments are addressed for cloud service (RDPSs):
The security aspect of Logical/Software operational environment can be either :
-**SOE.FullyControlled** - Fully controlled logical operational environment (segregation, least priviledged, network protection e.g. firewalls/IDS/IPS/etc.). Only authorised users can access the PKI product interfaces and network data.
-**SOE.PartiallyControlled** - Partially controlled software operational environment product users can access the PKI product’s interfaces and network data in transit.
Additionally, the PKI Product may include the following required external components:
-**EC.Audit** - records secure storage External hardware and software use to store audit data.
-**EC.Timesource** - A network server that synchronizes the clocks of devices within an IT infrastructure to ensure consistent and accurate timekeeping for security, logging, and operational purposes.
-**EC.KMS** - Key Management System
-**EC.UserDirectory** - A directory server that centrally stores, organizes, and provides access to user, group, and resource information (e.g., authentication credentials, contact details) for networked systems and applications.
### 4.3.4 Connectivity aspects
For the logical operation environment, the following digital communication types are addressed for any architectural component of the product.
-**COM.Public** - ingoing/outgoing communication from/to public networks
-**COM.Adjacent** - ingoing/outgoing communication from/to private networks which does not require physical proximity to the communication partner
-**COM.Local** - ingoing/outgoing communication which requires physical proximity to but not physical presence at the communication partner
-**COM.StrictLocal** - ingoing/outgoing communication which requires physical presence at the communication partner
## 4.4 Distribution of Security Functions
Security functions distribution is presented in [Product Architecture](#42-product-architecture) and is further refined use case by use case in the annexes. This distribution depends, for each use case, on the product functional (F. parameters) scope together with its distribution parameters.
@@ -4308,7 +4321,7 @@ Revocation management
TODO Giulio
### A.1.4 UC1 - Operational Environment
### U.1.4 UC1 - Operational Environment
Physical/Hardware
- POE.PartiallyControlled
@@ -4320,9 +4333,102 @@ Logical Software
- EC.Timesource
- EC.Annuary
### A.1.5 UC1 - Distribution of Security Functions
### U.1.5 UC1 - Distribution of Security Functions
Connectivity
- COM.Local
Distribution
- ARC.Monolithic or
- ARC.Distributed or
- ARC.PrivateCloud or
- ARC.PublicCloud
Interfaces
- I.AuditAndAdministration
- I.Registration
- I.CertificateGeneration
- I.ExternalKMS
- I.CertifcateStatus
- I.RevocationManagement
- I.ExternalServices
### U.1.6 UC1 - Users
In this UC the product should be able to defined user profile restriction on function associated to the following role:
- U.Administrator
## U.2 UC2 - Product for use in Private PKI for critical entities
### U.2.2 General description (?)
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.
- 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).
### U.2.5 UC2 - Distribution of Security Functions
Distribution
- ARC.Monolithic or
@@ -4339,10 +4445,270 @@ Interfaces
- I.RevocationManagement
- I.ExternalServices
### A.1.6 UC1 - Users
### U.2.6 UC2 - Users
In this UC the product should be able to defined user profile restriction on function associated to the following role:
- U.Administrator
- U.Officer (or Registration Authority Officer)
- U.Auditor
## U.3 UC3 - Open or public PKI for critical entities
### U.3.1 General description (?)
PKI product used to support certification management services (registration, certificate generation, revocation and status management) 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.
Such PKIs are deployed in highly controlled environments, including robust physical and logical security measures, along with strict policies and processes.
- 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).
### U.3.5 UC3 - Distribution of Security Functions
Distribution
- ARC.Monolithic
- ARC.Distributed
- ARC.PrivateCloud
Interfaces
- I.LocalInterface
- I.CertificateGeneration
- I.ExternalKMS
- I.CertifcateStatus
- I.RevocationManagement
- I.ExternalServices
### U.3.6 UC3 - Users
In this UC the product should be able to defined user profile restriction on function associated to the following role:
- U.Administrator
- U.Operator
- U.Officer (or Registration Authority Officer)
- U.Auditor
## U.4 UC4 - Product for use in Open or Public basic PKI
### U.4.1 General description (?)
PKI product used to support certification services (certificate generation, revocation and status management) 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.
Such PKIs are deployed in highly controlled environments, including robust physical and logical security measures, along with strict policies and processes.
- EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.
### U.4.5 UC4 - Distribution of Security Functions
Distribution
- ARC.Monolithic
Interfaces
- I.LocalInterface
### U.4.6 UC4 - Users
In this UC the product should be able to defined user profile restriction on function associated to the following role:
- U.Administrator
- U.Operator
- U.Officer (or Registration Authority Officer)
- U.Auditor
## U.5 UC5 - Product for use in multi-authority PKI
### U.5.1 General description (?)
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 [].
- 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).
