Certificate Issuance requirements update

  </td>

  </tr>

</table>

## 3.2 Symbols

`URL     Uniform Resource Locator`

`VCS     Version Control System`

# 4 Product context

## 4.0 Introduction

## 4.1 Product Functions

Products with digital elements used as part of a public key cryptography scheme to manage asymmetric cryptographic keys and digital certificates, including their creation, issuance, distribution, validation, renewal, storage or revocation, support the functions outlined in this clause.

- **F.PublicPrivateKeyPair_generation**: Generates a public-private key pair.

>   - **NOTE 1**: This function may be specialized to address use cases for generation using a Secure Cryptographic Device (SCD) or without using an SCD.

- **F.SCD_Based_KeyPair_generation**: Request the generation of a public-private key pair from an external SCD.

## 4.5 Users

The product contains a number of assets that need privileged access to use. The following user classes are identified from consideration of the least privilege paradigm to the product assets as identified in the product architecture of clause [4.2](#42-product-architecture).

- **U.ProductAdministrator**: Install, configure, and maintain the product, ensuring its proper operation and security.

## 5.6 Confidentiality

_Proposed ESR code: CON_

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

## 5.6.1 General

- REFERENCE: 	REQ-PKI-CON-001

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

## 5.8 Data minimisation

_Proposed ESR code: DM_

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

### 5.8.1 General

- REFERENCE: 	REQ-PKI-DM-001

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

  - RATIONALE: XXX

  - NOTE:XXX

  - APPLICABILITY: XXXX

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

  - 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 

- REFERENCE: REQ-PKI-DM-004

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

  - APPLICABILITY: All use cases.

## 5.9 Availability protection

  - NOTE:XXX

  - APPLICABILITY: XXX

## 5.12 Exploitation mitigation mechanisms

_Proposed ESR code: EMM_

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

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

- REFERENCE: REQ-PKI-EMM-001

  - REQUIREMENT: The certificates issued by the certificate generation service shall comply with the X.509 standard ITU-T X.509 [\[3\]](#_ref_3) or with the IETF RFC 5280 standard or with the IEEE 1609.2 standard, and if known, to any extension or profile identified by the target systems' policy.

  - RATIONALE: This extends what is mandated by ETSI EN 319 411-1  [\[7\]](#_ref_7) and takes into account the C-ITS PKI use case. Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only the normalised and necessary information. 

  - APPLICABILITY:  TODO All use cases where the product has a certificate generation service.

- REFERENCE: REQ-PKI-EMM-002

  - REQUIREMENT: The product shall implement a certificate profile and shall ensure that issued certificates are consistent with that profile.

  - RATIONALE: To generate valid certificates, a product shall fallow a specific format and enforce mandatory content for the created certificates, corresponding to the implementation of a certificate policy. 

  - APPLICABILITY: TODO All use cases where the product has a certificate generation service.

- REFERENCE: REQ-PKI-EMM-003

  - REQUIREMENT: The product shall enable privileged user to specify the set of acceptable values for the following fields and extensions:

    - the authority key identifier;

    - the algorithm identifier for the subject’s public/private key pair;

    - the identifier of the certificate issuer;

    - the length of time for which the certificate is valid.

  - RATIONALE: Only valid certificates, as defined by privileged users in conformity with the PKI certificate policy, shall be generated by the product.

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

- REFERENCE: REQ-PKI-EMM-004

  - REQUIREMENT: The product shall require priviledged users to specify the set of acceptable values for the following fields and extensions:

    - keyUsage;

    - basicConstraints;

    - certificatePolicies.

  - RATIONALE:

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

- REFERENCE: REQ-PKI-EMM-005

  - REQUIREMENT: The product shall mark the following extensions as critical:

    - keyUsage;

    - basicConstraints;

    - certificatePolicies.

  - RATIONALE: Only valid certifcates as defined by the product service provider policies shall be generated by the product. 

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

- REFERENCE: REQ-PKI-EMM-006

  - REQUIREMENT: The product shall disallow the keyUsage extension to simultaneously include values from both of:

    - digitalSignature, contentCommitment, keyCertSign, cRLSign; and

    - keyEncipherment, dataEncipherment, keyAgreement.

  - RATIONALE: The same public key may not be used for signature verification, and encryption or key agreement. Only valid certifcates as defined by the PKI service provider policies shall be generated by the product. 

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

- REFERENCE: REQ-PKI-EMM-007

  - REQUIREMENT: The product shall verify that the prospective certificate subject possesses the private key that corresponds to the public key in the certificate request before issuing a certificate, unless the public/private key pair was generated by the product and never left the certificate issuance service.

  - RATIONALE: A subject bringing forth his own public key should prove ownership of the corresponding private key. The product may generate a key pair and associated public key, and later communicate the private key to the correct subject in a secure manner. This may notably be done for other components of the product itself needing public-key certificates. The same private key should not be owned by distinct subjects, including other services of the product; if the private key was generated by the product but already provided to the subject once, the subject can and should prove its ownership. 

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

## 5.13 Logging and monitoring

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

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

### 5.14.1 Secret management

- REFERENCE: REQ-PKI-DRT-001

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

    - release the accessed public key to the caller; or

    - use the accessed public key.

  - RATIONALE: Unauthorized modifications of public keys stored by the product should not go undetected. Public keys modified without authorization should not be considered safe for use and not be disseminated throughout or outside the product. This requirement covers key tampering and disclosure threats: T_GEN01 to T_GEN08, T.Stored_Certificates_Tampering.

  - APPLICABILITY: All use cases

- REFERENCE: REQ-PKI-DRT-002

  - REQUIREMENT: The product shall zeroize secrets in plaintext form.

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

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