Update file EN-304-624.md

- 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  [\[i.10\]](#_ref_i.10) defines requirements on security hardware elements of the PKI and requirement of software elements of the PKI for use in eIDAS).

### 4.6.4 Public basic PKI for critical entities. (UC4)

### 4.6.4 Public basic PKI for critical entities (UC4)

Product used to support certification services (certificate generation, revocation and status management) 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.

### 4.6.5 Multi-authority PKI for critical entities.

### 4.6.5 Multi-authority PKI for critical entities (UC5)

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.

The multi-authority PKI is intended to combine multiple authorities in a single (extended) domain, sharing resources, and enforcing minimisation of identifying data. In like manner to Kerberos the certificate model in multi-authority PKI enables anonymous or pseudonymous proof of authority. The product in multi-authority PKIs is expected to be able to generate and distribute signed attestations of authority, to verify any received attestation of authority, and to maintain the status of stored public keys.

- EXAMPLE 1:	The PKI dedicated to Co-operative Intelligent Transport Systems (C-ITS) is used to manage proofs of authorisation and identity to enable access to services on different components of ITS systems standardized in ETSI TS 102 940 [[i.16](#_ref_i_16)] and ETSI TS 102 941 [[i.7](#_ref_i_7)]. The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information. The PKI service architecture and its functionalities considered here are the one .The C-ITS PKI standards provide the basis for the European C-ITS trust model [\[i.11\]](#_ref_i.11).

- EXAMPLE 1:	The PKI dedicated to Co-operative Intelligent Transport Systems (C-ITS) is used to manage proofs of authorisation and identity to enable access to services on different components of ITS systems standardized in ETSI TS 102 940 [[i.16](#_ref_i_16)] and ETSI TS 102 941 [[i.7](#_ref_i_7)]. The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information. The PKI service architecture and its functionalities considered here are the one .The C-ITS PKI standards provide the basis for the EU C-ITS security credential management system [\[i.20\]](#_ref_i.20).

  - NOTE 1:	For the C-ITS example within this use case the product requirements for the ITS-Station acting as a signature creation and verification element the European C-ITS trust model specifies that the ITS-S conforms to a specific protection profile.

  - NOTE 2:	In the C-ITS model the product uses pseudonymous key pairs and cycles them rapidly and the product may need to have multiple key pairs maintained at any one time, this may place constraints on the number of private keys that have to be maintained in the product.

### 5.9.1 AP - Certificate suspension and revocation

- REFERENCE: REQ-PKI-AP-01

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

  - REQUIREMENT: Once a certificate has been revoked by means of REQ-PKI-EMM-08, 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.

  - REQUIREMENT - [CONDITIONAL]: If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants (e.g. Delta CRLs) are used as defined and provide a nextUpdate field, every CRL shall state a time for next scheduled CRL issue, unless it is the last CRL issued for those certificates in the scope of the CRL, in which case the nextUpdate field in the CRL, shall be set to "99991231235959Z".

  - NOTE: This requirement is derived from CSS-6.3.9-06 contained in ETSI EN 319 411-1 [\[i.10\]](#_ref_i.10)

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

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

  - APPLICABILITY: Where the product has a certificate status service, issuing CRLs according to REQ-PKI-EMM-08 and REQ-PKI-EMM-09.

- REFERENCE: REQ-PKI-AP-03

  - REQUIREMENT - [CONDITIONAL]: If CARL is used, a new CARL shall be generated at least once a year with a nextUpdate of at most 1 year after the issuing date.    

  - NOTE: This requirement is derived from CSS-6.3.9-12 contained in ETSI EN 319 411-1  [\[i.10\]](#_ref_i.10) 

  - RATIONALE: 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 CARLs.

  - APPLICABILITY: Where the product has a certificate status service issuing CARLs according.

- REFERENCE: REQ-PKI-AP-04

  - REQUIREMENT - [CONDITIONAL]: If CARL is used, a new CARL shall be generated once a CA certificate has been revoked.

### 5.9.2 AP - Certificate status services

- REFERENCE: REQ-PKI-AP-05

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

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

  - NOTE: This requirement is derived from CSS-6.3.10-04 contained in ETSI EN 319 411-1  [\[i.10\]](#_ref_i.10)

  - RATIONALE: If no revocation information status is avaible before the end of the validity of a certificate, its status becomes unknown and it cannot be trusted anymore.

  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-AP-07

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

  - RATIONALE: The product shall provide accurate and integrity protected certificates statues.

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

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

  - REQUIREMENT: The certificates format issued by the certificate generation service shall comply with the X.509 standard ITU-T X.509 [\[2\]](#_ref_2) 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 [\[i.10\]](#_ref_i.10)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 normalised and necessary information.

  - APPLICABILITY:  All use cases.

- REFERENCE: REQ-PKI-EMM-01a

  - REQUIREMENT: The format of the certificates issued by the certificate generation service shall comply with the X.509 standard ITU-T X.509 \[2\](#_ref_2) or functionally-equivalent standard.

  - RATIONALE: Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.

  - APPLICABILITY: All use cases, not applicable if REQ-PKI-EMM-01b is used.

- REFERENCE: REQ-PKI-EMM-01b

  - REQUIREMENT: The format of the certificates issued by the certificate generation service shall comply with the IEEE 1609.2 standard, 

  - RATIONALE: Using normative formats ensures the interoperability of PKIs and enforces that certificate content contains only normalised and necessary information.

  - APPLICABILITY: UC5 for C-ITS

- REFERENCE: REQ-PKI-EMM-02

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

  - RATIONALE: Enforcing the implementation of a certificate policy ensures that authorized user can enforce interoperability of PKIs and that certificate content contains only normalised and necessary information to minimize attack surface.

  - REQUIREMENT: The product shall implement a certificate profile compliant to the base standard of REQ-PKI-EMM-01 (a or b) and appropriate to its scope/context  and shall ensure that issued certificates are consistent with that profile.

  - RATIONALE: EThe specification of a specific certificate profile (e.g. by reference to applicable standards such as IETF RFC 5280  [\[i.18\]](#_ref_i.18)  or ETSI TS 103 097  [\[i.19\]](#_ref_i.19) ) is in scope of a Certificate Policy and out of the scope of the present document. However, requiring the implementation of a certificate profile ensures that authorized users can ensure interoperability of PKIs and that certificate content contains only normalised and necessary information to minimize attack surface.

  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-EMM-03

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

    - the authority key identifier;

    - the authority key identifier (if applicable);

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

    - the identifier of the certificate issuer or of the issuing certificate;

    - the duration for which the certificate is valid.

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

  - APPLICABILITY: All use cases.

    - basicConstraints;

    - certificatePolicies.

  - RATIONALE: TODO

  - APPLICABILITY: All use cases.

  - APPLICABILITY: All use cases, applicable only if REQ-PKI-EMM-01a is used.

- REFERENCE: REQ-PKI-EMM-05

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

    - basicConstraints;

    - certificatePolicies.

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

  - APPLICABILITY: All use cases.

  - APPLICABILITY: All use cases, applicable only if REQ-PKI-EMM-01a is used.

- REFERENCE: REQ-PKI-EMM-06

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

    - 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: U2, UC3, UC4, UC5.

  - APPLICABILITY: U2, UC3, UC4, UC5, applicable only if REQ-PKI-EMM-01a is used.

- REFERENCE: REQ-PKI-EMM-07

  - REQUIREMENT: The product shall verify that the prospective certificate subject possesses the private key corresponding to the public key contained in the certificate request by means of a cryptographic challenge (e.g., signature generation or decryption) before issuing a certificate, unless the public/private key pair was generated by the product and has never left the certificate issuance service.