@@ -606,7 +606,7 @@ Products with digital elements used as part of a public key cryptography scheme
-**F.PseudonymCertIssuance**: Issue pseudonym certificates derived from long-term certificates. These certificates shall not include user identification data.
-**F.SubjectCertSignCreation**: Creates and signs subject certificates using the product's private key.
> - **NOTE 2**: The policy frameworks of eIDAS and C-ITS identify the use of protection profiles in support of signature creation. In particular, the European Commission's eIDAS Dashboard [https://eidas.ec.europa.eu/efda/home] identifies a list of Qualified Signature/Seal Creation Devices and Secure Signature Creation Devices [https://eidas.ec.europa.eu/efda/browse/notification/qscd-sscd]. For C-ITS, the Security and Certificate policy documents [[i.11](#_ref_i_11)], [[i.12](#_ref_i_12)] identify specific Protection Profiles.
-**F.CertificateDissemination**: Distributes signed certificates to subscribers.
-**F.orertificateDissemination**: Distributes signed certificates to subscribers.
-**F.CertificateStatus**: Maintains certificate status information (e.g., active, expired, revoked).
-**F.PKC_storage_management**: Stores received PKCs and makes them available to relying parties.
-**F.SignedArtefactDissemination**: Distributes signed artefacts to subscribers.
@@ -1017,7 +1017,7 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
- REFERENCE: REQ-PKI-INT-10
- 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 using a valid certificate.
- NOTE: This Requirement correspond to CSS-6.3.9-08 contained in ETSI EN 319 411-1 [\[i.10\]](#_ref_i.10)
- NOTE: This requirement is derived from 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.
@@ -1063,19 +1063,19 @@ 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 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)
- 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.
- 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 correspond to CSS-6.3.9-12 contained in ETSI EN 319 411-1 [\[i.10\]](#_ref_i.10)
- 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.
- REFERENCE: REQ-PKI-AP-04
- 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)
- NOTE: This requirement is derived from 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.
@@ -1083,13 +1083,13 @@ In this section we consider that certificates status availability and trust are
- 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)
- 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-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)
- NOTE: This requirement is derived from 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.
