@@ -1067,7 +1067,7 @@ In this section we consider that certificates status availability and trust are
- 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".
- NOTE: This Requirement correspond to CSS-6.3.9-06 contained in ETSI EN 319 411-1 [\[6\]](#_ref_5)
- 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.
@@ -1076,7 +1076,7 @@ In this section we consider that certificates status availability and trust are
- 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.
- NOTE: This Requirement correspond to CSS-6.3.9-08 contained in ETSI EN 319 411-1 [\[6\]](#_ref_5)
- 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.
@@ -1084,7 +1084,7 @@ In this section we consider that certificates status availability and trust are
- 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.
- NOTE: This Requirement correspond to CSS-6.3.9-12 contained in ETSI EN 319 411-1 [\[6\]](#_ref_5)
- 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.
@@ -1092,7 +1092,7 @@ In this section we consider that certificates status availability and trust are
- REFERENCE: REQ-PKI-AP-05
- 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 [\[6\]](#_ref_5)
- 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.
- APPLICABILITY: Where the product has a certificate status service, issuing CRLs or CARLs.
@@ -1101,13 +1101,13 @@ In this section we consider that certificates status availability and trust are
- REFERENCE: REQ-PKI-AP-06
- 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 [\[6\]](#_ref_5)
- 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
- REQUIREMENT: OCSP or CRL shall be supported.
- NOTE: This Requirement correspond to CSS-6.3.10-05 contained in ETSI EN 319 411-1 [\[6\]](#_ref_5)
- 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.
@@ -1115,10 +1115,9 @@ In this section we consider that certificates status availability and trust are
- 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.
- NOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1 [\[6\]](#_ref_5)
- NOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1 [\[6\]](#_ref_5).
### 5.9.3 AP - Key management
### 5.9.3 AP - Key management
- REFERENCE: REQ-PKI-AP-09
- REQUIREMENT: The product shall be able to maintain multiple key pairs.
@@ -1159,7 +1158,7 @@ To limit certificate forgery or misuse of certificate content, this section defi
- 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 [\[6\]](#_ref_5)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.
- 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.
