@@ -1075,28 +1075,26 @@ In this section we consider that certificates status availability and trust are
- APPLICABILITY: Where the product has a certificate status service, issuing CARLs.
- REFERENCE: REQ-PKI-AP-04
- REQUIREMENT:
- [CONDITIONAL]: If CARL is used, a new CARL shall be generated once a CA certificate has been revoked.
- REQUIREMENT - [CONDITIONAL]: If CARL is used, a new CARL shall be generated once a CA certificate has been revoked.
- NOTE: This Requirement correspond to CSS-6.3.9-13 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.
- 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.
### 5.9.2 AP - Certificate status services
- REFERENCE: REQ-PKI-AP-06
- REFERENCE: REQ-PKI-AP-05
- REQUIREMENT: Revocation status information shall include information on the status of certificates at least until the certificate expires.
- NOTE: This Requirement correspond to 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
- REFERENCE: REQ-PKI-AP-06
- REQUIREMENT: OCSP or CRL shall be supported.
- NOTE: This Requirement correspond to CSS-6.3.10-05 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: UC2, UC3, UC4 and UC5.
- REFERENCE: REQ-PKI-AP-08
- 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).
- APPLICABILITY: UC1, UC2 and UC3.
@@ -1104,12 +1102,12 @@ In this section we consider that certificates status availability and trust are
### 5.9.3 AP - Key management
- REFERENCE: REQ-PKI-AP-09
- REFERENCE: REQ-PKI-AP-08
- REQUIREMENT: The product shall be able to maintain multiple key pairs.
- RATIONALE: A PKI product requires multiple key pairs to provide essential services, including: support for different authorities (e.g., root CA, intermediate CAs, end-entities), use of various cryptographic mechanisms (e.g., separate key pairs for signing and encryption), facilitation of key rotation and lifecycle management (e.g., active and backup keys), etc.
- APPLICABILITY: All use cases.
- REFERENCE: REQ-PKI-AP-10
- REFERENCE: REQ-PKI-AP-09
- REQUIREMENT: The product shall provide the capability for authorized users to delete keys.
- RATIONALE: Proper key management includes the capability for authorized users to delete key when necessary (as defined by the Certificate Policy).
