The reasonably foreseeable use of the product is to support certification services provided within a large enterprise or provided by a CA to the public, and where a compromise carries a significant risk of impact to the security of other products, networks or services, or to the health, security or safety of the public.
EXAMPLE 1: Software used to issue certificates for public web sites.
EXAMPLE 2: Software used to issue certificates for mobile network infrastructure.
EXAMPLE 3: Software used to issue certificates for central government public administration organisations.
### 4.3.2 Functionality
#### 4.3.2.1 Services
The PKI product will support one or more of the following component services (see ETSI EN 319 411-1):
-<strong>Registration service:</strong> as described in clause 4.2.2.1.
EXAMPLE 1: This service verifies ownership of the domain in requests for public web site certificates
-<strong>Certificate generation service:</strong> as described in clause 4.2.2.1.
NOTE 1: The certificate profile used in certificate creation, including the signature algorithm, certificate lifetime and key usage restrictions, is determined by the CA's Certificate Policy (CP) or an equivalent document.
NOTE 2: This service will typically use a secure cryptographic device to generate, store and use the CA keys.
-<strong>Dissemination service:</strong> as described in clause 4.2.2.1.
NOTE 3: This service can also make the CA's terms and conditions, policy and practice information available to subscribers and relying parties.
-<strong>Revocation management service:</strong> as described in clause 4.2.2.1.
EXAMPLE 2: THis service verifies that revocation requests are submitted by authorised parties.
EXAMPLE 3: This service obtains confirmation from the subscriber if a compromise is reported by a third party.
-<strong>Certificate status service:</strong> as described in clause 4.2.2.1.
EXAMPLE 4: This service publishes CRLs and responds to OCSP queries.
Each component service will require configuration and maintenance by system administrators.
#### 4.3.2.2 Logging
The PKI product will support logging of security events; for example, account access attempts, product configuration changes, and system warnings or errors.
The PKI product will support logging of events relevant to each of the component service it provides. For example:
- Registration service events such as certificate requests and approvals.
- Certificate generation service events such as subject key generation and certificate signing operations.
- Revocation management service events such as revocation requests and results.
#### 4.3.2.3 Accounts
In the public PKI product context, the product will support one or more of the following user accounts:
-<strong>System administrator account:</strong> authorised to install, configure and update the product.
-<strong>System operator account:</strong> authorised to operate the PKI services.
NOTE: This might consist of separate registration service operator, certificate generation service operator and revocation service operator accounts.
-<strong>System auditor account:</strong> authorised to view audit logs and other syste data.
### 4.3.3 Architecture
Figure 4.1 in clause 4.2.3 gives a high-level example of a PKI architecture.
A large enterprise or public PKI might include multiple instances of some component services.
EXAMPLE 1: Mutliple registration services connected to a single certificate generation service for scalability.
EXAMPLE 2: Multiple certificate generation services for availability and disaster recovery.
In some use cases, the PKI might not include some component services
EXAMPLE 3: Revocation management and certificate status services might not needed if the CA only issues short-lived certificates that are not intended to be revoked.
PKI products intended for large enterprise or public PKI use can be designed so that each instance of the product provides a single component service with multiple instances of the product networked together to provide the full CA functionality.
The PKI can also be designed to use generic enterprise products to support the functionality of some component services.
EXAMPLE 4: A third-party database might be used to store and manage subscriber and certificate data.
EXAMPLE 5: A third-party logging service might be used to store and manage event logs.
### 4.3.4
#### 4.3.4.1 Deployment
The large enterprise or public CA will have a production system for issuing certificates and can be expected to have separate development or test systems for checking configuration changes and software updates before they are deployed.
The PKI software will typically be deployed on servers within the CA's data centre, but less critical component services can be deployed on a platform hosted by a cloud service provider.
NOTE 1: PKI-as-a-service and software-as-a-service are out of scope of the present document.
The certificate generation service in the production system will use a secure cryptographic device to manage the CA keys and, if required, generate subject keys. This will likely be a physical device located in the enterprise's data centre.
NOTE 2: Security requirements for secure cryptographic devices are out of scope of the present document.
#### 4.3.4.2 Physical security
The CA will locate production infrastructure supporting security critical component services such as certificate generation in a secure perimeter with physical protection against intrusion and physical controls limiting access to authorised personnel.
The CA will implement controls to prevent the loss, theft or compromise of its equipment, media, and data.
The CA will implement measures to prevent a compromise or interruption of its services due to an electricity, network, or other utility failure.
#### 4.3.4.3 Network security
The CA will implement change control procedures for any software updates and configuration changes.
The CA will deploy security updates in a reasonable time, unless they introduce additional vulnerabilities or system instabilities, and review and verify configuration settings regularly.
The CA will implement security controls such as firewalls and intrusion detection and prevention systems on its networks, deploy malware detection and removal software on its infrastructure, and undergo regular vulnerability scans and penetration tests.
The CA will locate security-critical component services such as certificate generation in one or more secure network zones, and restrict access and communication between zones.
The CA will have a dedicated network for the administration and operation of its production system that is logically separated from its other systems.
The CA will block protocols and disable accesses that are not needed for PKI operations.
### 4.3.5 User description
In the large enterprise and public PKI context, the CA will employ staff who have the necessary expertise and experience for their roles, including an understanding of cybersecurity and data protection where relevant.
The CA will provide staff with regular training on current security practices and apply appropriate disciplinary sanctions to staff who violate the CA's policies or procedures.
The CA will perform additional checks on staff employed in trusted roles such as system administrators, system operators and system auditors, and wait for the checks to be completed before giving access to the trusted service.
The CA will enforce separation between trusted roles with conflicting responsibilities such as system operators and system auditors.
### 4.3.6 Assets
### 4.3.7 Threats
### 4.3.8 Risks
## 4.4 Security Profile 3 (SP3) - C-ITS PKI
A Public Key Infrastructure (PKI) dedicated to Communicating Intelligent Transport Systems (C-ITS) is used to manage ITS related certificates to enable deployment of security functions over the different components of ITS systems, mainly signature and encryption of ITS messages. The PKI is responsible for the issuance, revocation, and overall management of certificates and certificate status information.
