reference update

The product contains the following elements:

<!-- Add definition of below elements -->

Product audit & administration

- F.UserAccountManagement

- F.Network_Configuration

- F.RevocationManagement

- F.OfficerRevocationApproval

In addition the elements can be configured in multiple ways:

 - **ARC.Monolithic**: All components are integrated and run on a single machine or platform.

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.

Each component defining the Product is accessible through the interfaces defined below.

- **I.LocalInterface**	- Local user interface used by the different privileged users to access the product functionalities and data.

<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>

## 4.3 Operational Environment

### 4.3.1	General description

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.

- REFERENCE: REQ-PKI-SBDC-001

  - REQUIREMENT: All assets of the system shall be defined as protected assets with default access condition of DENY.

  - NOTE 1:	See also clause 5.5.

  - EXAMPLE:	The role of the access control countermeasure is described in ETSI TS 102 165-2 [] (clause 6) where permission to access a resource is only ever true (PERMIT) or false (DENY) and where the decision to give permission is always deterministic.

  - EXAMPLE:	The role of the access control countermeasure is described in ETSI TS 102 165-2 [\[i.8\]](#_ref_i.8) (clause 6) where permission to access a resource is only ever true (PERMIT) or false (DENY) and where the decision to give permission is always deterministic.

  - APPLICABILITY: All use cases.

TODO

- REFERENCE: REQ-PKI-DM-004

  - REQUIREMENT: The product shall be able to establish and maintain a secure and link with the SCD or KMS, and that the SCD or KMS interfaces are properly called.

    - RATIONALE: To ensure trust the product software must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices.

  - RATIONALE: To ensure the secure key managment, the proper and secure used of exteranl SCD or KMS is required.

  - APPLICABILITY: UC2, UC3, UC4, UC5

- REFERENCE: REQ-PKI-DM-005

  - REQUIREMENT: Secret keys shall not be stored persistently in plaintext form. They shall be stored within a secure cryptographic device or encrypted using approved algorithms as defined in Annex K using independently managed keys. They may only be accessed in plaintext form temporarily for a single operation or batch of operations.

  - RATIONALE: To ensure trust the product must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices. It covers key tampering and disclosure threats: T_GEN01 to T_GEN08, T.Stored_Certificates_Tampering.

  - RATIONALE: To ensure trust the product must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices.

  - APPLICABILITY: All use cases.

## 5.9 Availability protection