Section header update + moving key exporte req to Confidentiality

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

### 5.6.1 General

### 5.6.1 CON - General

- REFERENCE: 	REQ-PKI-CON-01

  - REQUIREMENT: The product shall provide capabilities to ensure that the private key generated by the product cannot be removed or copied from the product.

  - NOTE: If the product is intended for a specific environment with a defined set of agreed cryptographic mechanisms, the product has to be able to be used in accordance with those cryptographic requirements.

  - APPLICABILITY: UC1, UC2, UC3 and UC5

- REFERENCE: 	REQ-PKI-CON-08

  - REQUIREMENT: The product shall be able to maintain multiple key pairs.

   - RATIONALE: A PKI product requires multiple key pairs to provide essential services, including: support for different authorities (e.g., root CA, intermediate CAs, end-entities), use of various cryptographic mechanisms (e.g., separate key pairs for signing and encryption), facilitation of key rotation and lifecycle management (e.g., active and backup keys), etc.

  - APPLICABILITY: All use cases.

### 5.6.2 CON - Secure storage and communications

### 5.6.2 Secure storage and communications

- REFERENCE: REQ-PKI-INT-06

- REFERENCE: REQ-PKI-CON-08

  - REQUIREMENT: The cryptographic mechanisms used to encrypt and decrypt content shall conform to the general state of the art, as defined in Annex K.

  - RATIONALE:

  - RATIONALE: Cf. Annex K rational.

  - APPLICABILITY: All use cases where the product implements encryption mechanisms either for data storage or external communications.

  - NOTE:	If the product is intended for a specific environment with a defined set of agreed cryptographic mechanisms, the product has to be able to be used in accordance with those cryptographic requirements.

### 5.6.2 CON - Key management

- REFERENCE: REQ-PKI-CON-09

  - REQUIREMENT: If the product exports private or symmetric keys it shall use state of the art techniques for guaranteeing its confidentiality as defined in Annex K.

  - RATIONALE: A secret key should not be compromised if its exported form is intercepted.

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

  - APPLICABILITY: All use cases

## 5.7 Integrity

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

### 5.7.1 Monitoring

### 5.7.1 INT - Monitoring

- REFERENCE: REQ-PKI-INT-01

  - REQUIREMENT: The product shall be able to detect unauthorised modifications to the stored audit records during the audit.

  - RATIONALE: The audit record intergrity ensure that all auditable events are traceable and misuse of the product functions can be traced.

  - APPLICABILITY: All use cases.

### 5.7.2 Certificate signing

### 5.7.2 INT - Certificate signing

- REFERENCE: REQ-PKI-INT-06

  - REQUIREMENT: The product shall create certificate signature only by means of a Secure Cryptographic Device (SCD).

  - RATIONALE: The use of recognized and validated cryptographic algorithms is mandatory for a PKI and thus a PKI product to ensure trust. Known weak or insufficiently validated algorithms are not allowed.

  - APPLICABILITY: All use cases.

### 5.7.2 CRL signing

### 5.7.3 INT- CRL signing

- REFERENCE: REQ-PKI-INT-08

  - REQUIREMENT: The product shall create CRL signature only by means of a Secure Cryptographic Device (SCD).

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

### 5.8.1 General

### 5.8.1 DM - General

- REFERENCE: 	REQ-PKI-DM-01

  - REQUIREMENT: The product shall only maintain configuration data sufficient to connect to other elements of the PKI system that the product serves.

  - RATIONALE: For each use case, only user data necessary for the certificate management functions identified in Annex U are required.

  - APPLICABILITY: All use cases.

### 5.8.2 Secret management

### 5.8.2 DM - Secret management

- REFERENCE: REQ-PKI-DM-03

  - REQUIREMENT: The product shall only create keys by means of a Secure Cryptographic Device (SCD) or remote Key Management System providing cryptographic mechanisms conform to the general state of the art as defined in Annex K.

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

### 5.9.1 Certificate suspension and revocation

### 5.9.1 AP - Certificate suspension and revocation

- REFERENCE: REQ-PKI-AP-01

  - REQUIREMENT: Once a certificate is revoked, it shall not be reinstated.

  - RATIONALE: Revocation is intended to be a definitive action, from which this requirement stems. Tampering certificates status can enable distrust when it becomes unclear if certificates are valid or not, thus it also tampers the availability of the service which consits is providing trust.

    - 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 AP - Certificate status services

- REFERENCE: REQ-PKI-AP-06

  - REQUIREMENT: Revocation status information shall include information on the status of certificates at least until the certificate expires.

  - NOTE: This Requirement correspond to CSS-6.3.10-04 contained in ETSI EN 319 411-1  [\[6\]](#_ref_5) 

  - APPLICABILITY: UC1, UC2 and UC3.

  - NOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1  [\[6\]](#_ref_5)

### 5.9.3 AP - Key management 

- REFERENCE: 	REQ-PKI-AP-09

  - REQUIREMENT: The product shall be able to maintain multiple key pairs.

   - RATIONALE: A PKI product requires multiple key pairs to provide essential services, including: support for different authorities (e.g., root CA, intermediate CAs, end-entities), use of various cryptographic mechanisms (e.g., separate key pairs for signing and encryption), facilitation of key rotation and lifecycle management (e.g., active and backup keys), etc.

  - APPLICABILITY: All use cases.

## 5.10 Impact minimisation

_Proposed ESR code: IM_

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

### 5.12.1 Certificate issuance

### 5.12.1 EMM - Certificate issuance

To limit certificate forgery or misuse of certificate content, this section defines requirements for the PKI to enforce the use of standardized certificate formats and recognized cryptographic signature mechanisms.

  - APPLICABILITY: All use cases.

### 5.12.2 Certificate status

### 5.12.2 EMM - Certificate status

- REFERENCE: REQ-PKI-EMM-08

  - REQUIREMENT: The certificate status service shall provide certificate revocation statuses as either or both of:

  - APPLICABILITY: Where the product has a certificate status service, issuing OCSP responses of the basic response type: UC1 and UC2.

  - NOTE: An OCSP responder is required to be capable to emit OCSP responses of the basic type by RFC 6960 [\[i.3\]](#_ref_i.3).

### 5.12.4 Certificate re-key

### 5.12.4 EMM - Certificate re-key

- REFERENCE: REQ-PKI-EMM-14

  - REQUIREMENT: In case of certificate re-key, any modified certified names or attributes shall be validated and updated registration information shall be recorded.

  - RATIONALE: The product should never issue a certificate without having validated all its certified names and attributes at some point in time. The product should possess accurate registration information regarding certificates it re-keys.

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

### 5.12.5 Certificate modification

### 5.12.5 EMM - Certificate modification

  - REFERENCE: REQ-PKI-EMM-16

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

### 5.14.1 Secret management

### 5.14.1 DRT - Secret management

- REFERENCE: REQ-PKI-DRT-01

  - REQUIREMENT: Public keys stored within the product, but not within a secure cryptographic device, shall be protected against undetected modification. If verification fails, the product shall not:

  - RATIONALE: Zeroizing secrets reduces the compromission of secrets during the temporary compromission of a product component, to only secrets used while the compromission is in effect. This enables better tracing of what secrets were likely compromised.

  - APPLICABILITY: Where the product temporarily manipulates secrets in plaintext form.

- REFERENCE: REQ-PKI-DRT-03

  - REQUIREMENT: If the product exports private or symmetric keys it shall use state of the art techniques for guaranteeing its confidentiality as defined in Annex K.

  - RATIONALE: A secret key should not be compromised if its exported form is intercepted.

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