@@ -1284,22 +1284,36 @@ The PKI may generate a key pair and associated public key, and later communicate
- REFERENCE: REQ-5.5-01
- REQUIREMENT: Requirement GEN-6.3.6-10 contained in ETSI EN 319 411-1 [\[6\]](#_ref_6) shall apply.
- NOTE: The term "sufficient" in the requirement means that the security is to be evaluated according to the current state of the art.
- RATIONALE: The PKI should never issue a certificate with foreseeable insufficient cryptographic security. The PKI should never issue a certificate for a key associated to any kind of security compromission.
- APPLICABILITY: All use cases where the PKI has a certificate generation service, issuing public-key certificates and supporting certificate renewal.
## 5.6 Certificate re-key
- REFERENCE: REQ-5.6-01
- 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 PKI should never issue a certificate without having validated all its certified names and attributes at some point in time. The PKI should possess accurate registration information regarding certificates it re-keys.
- APPLICABILITY: All use cases where the PKI has a certificate generation service, issuing public-key certificates and supporting certificate re-key.
## 5.7 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 PKI should never issue a certificate without having validated all its certified names and attributes at some point in time. The PKI should possess accurate registration information regarding certificates it modifies.
- APPLICABILITY: All use cases where the PKI has a certificate generation service, issuing public-key certificates and supporting certificate modification.
## 5.8 Certificate suspension and revocation
- REFERENCE: REQ-5.8-01
- REQUIREMENT: Once a certificate is revoked, it shall not be reinstated.
- NOTE: Revocation is intended to be a definitive action, from which this requirement stems.
- RATIONALE: Revocation is intended to be a definitive action, from which this requirement stems.
- APPLICABILITY: All use cases where the PKI has a certificate generation service, issuing public-key certificates.
- REFERENCE: REQ-5.8-02
- 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 [\[6\]](#_ref_6) 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 PKI has a certificate status service, issuing CRLs or CARLs.
