@@ -1057,29 +1057,22 @@ In this section we consider that certificates status availability and trust are
- APPLICABILITY: All use cases where the product has a certificate generation service, issuing public-key certificates.
- REFERENCE: REQ-PKI-AP-02
- REQUIREMENT:
- [CONDITIONAL]: If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants (e.g. Delta CRLs) are used, 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 defined in IETF RFC 5280 [8], shall be set to "99991231235959Z".
- 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 correspond to 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 or CARLs.
- 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.
- REFERENCE: REQ-PKI-AP-03
- REQUIREMENT:
- [CONDITIONAL]: If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants (e.g. Delta CRLs) are used, the CRL shall be signed by the CA or an entity designated by the TSP.
- REQUIREMENT - [CONDITIONAL]: If Certificate Revocation Lists (CRLs) concerning end users certificates including any variants (e.g. Delta CRLs) are used, the CRL shall be signed by the CA or an entity designated by the TSP.
- NOTE: This Requirement correspond to CSS-6.3.9-08 contained in ETSI EN 319 411-1 [\[i.10\]](#_ref_i.10)
- RATIONALE:
- 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.
- APPLICABILITY: Where the product has a certificate status service, issuing CRLs or CARLs.
- RATIONALE: 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.
- APPLICABILITY: Where the product has a certificate status service, issuing CRLs.
- REFERENCE: REQ-PKI-AP-04
- 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.
- 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 correspond to 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 CRLs or CARLs.
- 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.
