Update file EN-304-624.md

A private enterprise using public-key cryptography that manages a PKI internally to the enterprise. The enterprise therefore manages the policy framework, the generation of key pairs, the certification of key pairs and the purposes of keys.

In such organisations the PKI may be organised on department centric hierarchies, or on location centric hierarchies, or on organisation role hierarchies or some combination of these. Whilst the set of services to be enabled by the PKI in this use case are large they may include VPN access and management, timestamp services, disk or message encryption, email, and document access and distribution and so on. The deployment of such a private Public Key Infrastructure (PKI) is not driven by regulatory or standardized requirements but rather by the need to align with the entity’s internal policies and security practices.

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

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.

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: Telecom service provider.

- 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

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

### 4.6.4 Product for use in Open or Public basic PKI (UC4)

PKI product used to support certification services 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.

- 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.5 Product for use in multi-authority PKI

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.

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

# 5 Technical requirements for the Products

## 5.1 Introduction - Applicability of the requirements

TODO

## 5.3.1 SDBC - Monitoring

### 5.3.1 SDBC - Monitoring

 - REFERENCE:  REQ-PKI-SBDC-002

  - REQUIREMENT: The audit log signing event shall be performed by default once a day.

## 5.9 Availability protection

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 1 (2) (h).

In this section we consider that certificates status availability and trust are direct part of availability protection of the PKI service, since  

    - CSS-6.3.9-13: With respect to the severity of a CA compromission, a revocation should be made known as quickly as possible by immediately issuing a new CARL, rather than waiting for the next scheduled CARL.

  - APPLICABILITY: Where the product has a certificate status service, issuing CRLs or CARLs.

## 5.9.2 Certificate status services

### 5.9.2 Certificate status services

- REFERENCE: REQ-PKI-AP-002

  - REQUIREMENT: Requirements CSS-6.3.10-03, CSS-6.3.10-04 and CSS-6.3.10-05 contained in ETSI EN 319 411-1  [\[7\]](#_ref_7) shall apply.

   - RATIONALE: The product shall provide accurate and integrity protected certificates statues either using the standardised CRL format ensuring integrity of revocation list or protected OCSP services as defined by RFC 6960 [\[i.3\]](#_ref_i.3). This covers threats T_REV01 to T_REV03 and T_STA01 to T_STA02.

  - APPLICABILITY: All use cases where the product has a certificate generation service, issuing public-key certificates and supporting certificate re-key.

### 5.12.3 Certificate modification

  - REFERENCE: REQ-5.7-01

    - REQUIREMENT: In case of a request for certificate modification, any modified certified names or attributes shall be validated and updated registration information shall be recorded.

    - NOTE: see ETSI 319 411-1 [i.3] clause 6.3.8 for the definition of certificate modification

  - EXAMPLES: The exported private or symmetric key can be encrypted such that only its designated recipient can decrypt it.

  - APPLICABILITY: All use cases

## 5.15 Vulnerability handling

This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 Part 2.