Certificate status requirement integration

  - REQUIREMENT: If a pseudonymous certificate is used to exchange a public key related to an ephemeral identity the product shall ensure that no data is contained in the cert that can be used to break the pseudonymity of the sender.

  - RATIONALE: XXX

  - NOTE:XXX

  - APPLICABILITY: XXXX

  - APPLICABILITY: UC5

- REFERENCE: 	REQ-PKI-CON-04

  - REQUIREMENT: TODO If the product sends data intended/labelled as personal or sensitive to another entity the product shall ensure that such data is protected from eavesdropping.

  - NOTE: Any PKCs stored in the product are intended for public dissemination and have, depending on the particular certificate specification, explicit means of protecting the content, thus no requirements are placed on the product that define the format and protections inherent to the PKC.

  - APPLICABILITY: XXXX

### 5.6.2 Secure communication with external entities

### 5.6.2 Secure storage and communications

  - REFERENCE: REQ-5.11-01

  - REQUIREMENT: (TODO - Not to address only C-ITS) The product shall permit secured certificate requests between an external entity and itself if the following rules hold:

    - Sending

        - The requests are encrypted and signed as defined by [\[6\]](#_ref_6) section 6.2.3.4.1 using EA and AA Certificates

        - The Message format is conformant to [\[6\]](#_ref_6) section 6.2.3.4.1

    - Reception

        - The requests can be correctly decrypted and the signature is valid with respect to the validated EA and AA Certificates

        - The Message format is conformant to [\[6\]](#_ref_6)  section 6.2.3.4.1

].

   - RATIONALE: The product shall provide protected communication channels for remote administrators, IT entities such as car manufacturer servers (confidentiality and integrity) and other parts of a distributed product (confidentiality, integrity and authenticity).

  - APPLICABILITY: UC4.  

- REFERENCE: REQ-PKI-INT-006

  - REQUIREMENT: The product shall implement cryptographic primitives as defined in Annex K and L to encrypt and decrypt content.

  - RATIONALE: 

  - 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 primitives, the product has to be able to be used in accordance with those cryptographic requirements. 

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

(TODO cf HAS comment - not to be enforce to less critical use cases - UC1?)

  - 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

- REFERENCE: REQ-PKI-INT-006

  - REQUIREMENT: The product shall only create certificate siganture by means of a Secure Cryptographic Device (SCD) appropriate for this use.

  - 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. It covers key tampering and disclosure threats: T_GEN01 to T_GEN08, T.Stored_Certificates_Tampering.

  - APPLICABILITY: UC2, UC3, UC4, UC5 

## 5.8 Data minimisation

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

### 5.8.2 Secret management 

- REFERENCE: REQ-PKI-DM-003

  - REQUIREMENT: The product shall only create keys by means of a Secure Cryptographic Device (SDC) or remote Key Management System appropriate for this use.

  - REQUIREMENT: The product shall only create keys by means of a Secure Cryptographic Device (SCD) or remote Key Management System appropriate for this use.

  - 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. It covers key tampering and disclosure threats: T_GEN01 to T_GEN08, T.Stored_Certificates_Tampering.

  - APPLICABILITY: UC2, UC3, UC4, UC5 

## 5.9 Availability protection

_Proposed ESR code: AP_

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  

### 5.9.1 Certificate suspension and revocation

- REFERENCE: REQ-PKI-AP-001

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

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

- REFERENCE: REQ-PKI-AP-002

  - REQUIREMENT: Requirements CSS-6.3.9-06, CSS-6.3.9-08, CSS-6.3.9-12 and CSS-6.3.9-13 contained in ETSI EN 319 411-1  [\[7\]](#_ref_7) shall apply.

  - RATIONALE:

    - CSS-6.3.9-06: The inclusion of an expiry of the CRL's validity reduces the ability of an attacker to replay the CRL to its users, and enables caching for end-users. The special value of that field in the event the next update would be the CRL issuer expires ensures the status information is valid until that expiry.

    - CSS-6.3.9-08: If the CRL is not signed by the CA or a TSP-appointed entity, it may be usurped to mislead end-users regarding a certificate's status.

    - CSS-6.3.9-12: See rationale for CSS-6.3.9-06. Contrary to the previous, an upper bound on the duration is fixed given the severity of a CA compromission.

    - 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

- 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: UC1, UC2 and UC3.

- REFERENCE: REQ-PKI-AP-003

  - REQUIREMENT: If a product supports multiple methods to provide revocation status, the information provided by all services shall be consistent over time taking into account different delays in updating the status information for all the methods.

   - 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: UC1, UC2 and UC3.

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

## 5.10 Impact minimisation

_Proposed ESR code: IM_

  - 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.3 Certificate renewal

- REFERENCE: REQ-PKI-EMM-014

  - REQUIREMENT: Requirement GEN-6.3.6-10 contained in ETSI EN 319 411-1  [\[7\]](#_ref_7) shall apply.

  - NOTE: (TODO Remove note and provide the definition directly in the document) The term "sufficient" in the requirement means that the security is to be evaluated according to the current state of the art.

  - RATIONALE: The product should never issue a certificate with foreseeable insufficient cryptographic security. The product should never issue a certificate for a key associated to any kind of security compromission.

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

### 5.12.3 Certificate re-key

- REFERENCE: REQ-PKI-EMM-015

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

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

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

## 5.13 Logging and monitoring

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