@@ -177,11 +177,11 @@ The following referenced documents are necessary for the application of the pres
-<spanid="_ref_2"></span><aname="_ref_2">[2]</a>\"ITU-T X.509\"\"(10/2019)\": \"Information technology - Open Systems Interconnection - The Directory: Public-key and attribute certificate frameworks\"
- NOTE: Identical text in the defining of public-key and attribute certificates is also available in ISO/IEC 9594‑8 (paywall).
-<spanid="_ref_3"></span><aname="_ref_3">[4]</a> "IEEE Std 1609.2™-2022" "(2022)": "Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages"
-<spanid="_ref_3"></span><aname="_ref_3">[3]</a> "IEEE Std 1609.2™-2022" "(2022)": "Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages"
-<spanid="_ref_4"></span><aname="_ref_4">[5]</a> "ETSI TS 102 941 V1.4.1" "(2021-01)": "Intelligent Transport Systems (ITS); Security; Trust and Privacy Management"
-<spanid="_ref_4"></span><aname="_ref_4">[4]</a> "ETSI TS 102 941 V1.4.1" "(2021-01)": "Intelligent Transport Systems (ITS); Security; Trust and Privacy Management"
-<spanid="_ref_5"></span><aname="_ref_5">[6]</a> "ETSI EN 319 411-1 V1.5.1" "(2025-04)": "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements"
-<spanid="_ref_5"></span><aname="_ref_5">[5]</a> "ETSI EN 319 411-1 V1.5.1" "(2025-04)": "Electronic Signatures and Infrastructures (ESI); Policy and security requirements for Trust Service Providers issuing certificates; Part 1: General requirements"
## 2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or nonspecific. For specific references, only the cited version applies. For non-specific references, the latest version of the referenced document (including any amendments) applies.
@@ -745,7 +745,7 @@ PKI product used to support certification management services (registration, cer
Such PKIs are deployed in highly controlled environments, including robust physical and logical security measures, along with strict policies and processes.
- EXAMPLE 1: Products deployed for a PKI used in large enterprise or critical entities (e.g, eIDAS where in the context of the present document ETSI EN 319 411-1 [] defines requirements on security hardware elements of the PKI and requirement of software elements of the PKI for use in eIDAS).
- EXAMPLE 1: Products deployed for a PKI used in large enterprise or critical entities (e.g, eIDAS where in the context of the present document ETSI EN 319 411-1 [\[i.10\]](#_ref_i.10) defines requirements on security hardware elements of the PKI and requirement of software elements of the PKI for use in eIDAS).
### 4.6.4 Public basic PKI for critical entities. (UC4)
@@ -1050,21 +1050,52 @@ 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: 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_5) shall apply.
- 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)
- 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.
- 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)
- 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.
- 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)
- 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.
- 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)
- 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.
- 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 Certificate status services
- REFERENCE: REQ-PKI-AP-02
- REQUIREMENT: Requirements CSS-6.3.10-03, CSS-6.3.10-04 and CSS-6.3.10-05 contained in ETSI EN 319 411-1 [\[6\]](#_ref_5) shall apply.
- 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.
- 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)
- 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-03
- 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)
- 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
- 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).
<td> REG02.Certificate request <br> REG01.Subscriber data <br> KEY01.Public Keys
</td>
</tr>
<tr>
<td> F.OfficerCertGenApproval </td>
<td> SYS03.Authorized user data <br> REG02.Certificate request <br> REG01.Subscriber data <br> KEY01.Public Keys </td>
</tr>
<tr>
<td> F.CertificateStatus </td>
<td> STA01.Certificate status data </td>
</tr>
<tr>
<td> F.RevocationManagement </td>
<td> STA01.Certificate status data </td>
</tr>
<tr>
<td> F.OfficerRevocationApproval </td>
<td> STA01.Certificate status data <br> SYS03.Authorized user data </td>
@@ -4763,34 +4777,25 @@ Revocation management
</table>
</div>
### U.4.4 UC4 - Operational Environment
Physical/Hardware
- POE.PartiallyControlled
- POE.SCD
Logical Software
- SOE.FullyControlled
- SOE.PartiallyControlled
- EC.Audit records secure storage
- EC.Timesource
- EC.UserDirectory
Connectivity
- COM.Public
- COM.Local
### U.4.5 UC4 - Distribution of Security Functions
Distribution
@@ -4820,13 +4825,9 @@ The multi-authority PKI is intended to combine multiple authorities in a single
- NOTE 2: In the C-ITS model the product uses pseudonymous key pairs and cycles them rapidly and the product may need to have multiple key pairs maintained at any one time, this may place constraints on the number of private keys that have to be maintained in the product.
- EXAMPLE 2: In a smart contract environment, such as that outlined in ETSI TR 119 540 [[i.15](#_ref_i_15)], the chain of trust requires that a device operates within multiple trust domains across and evidenced in the use of a distributed ledger wherein some entries may be signed as proof of an attribute attestation (e.g. a contractual state transition), or signed as proof of an identity attestation (e.g. identifying the legal entity that is a smart contract stakeholder).
