Commit dbf040b7 authored by Sammy Haddad's avatar Sammy Haddad
Browse files

Removal of NIS2 and eIADS references and applicability examples.

parent adb0faa5
Loading
Loading
Loading
Loading
+11 −40
Original line number Diff line number Diff line
@@ -82,8 +82,6 @@ The following referenced documents are necessary for the application of the pres

<span id="_ref_3"></span><a name="_ref_3">[3]</a> "IEEE Std 1609.2™-2025" "(2025)": "Standard for Wireless Access in Vehicular Environments—Security Services for Applications and Management Messages"



## 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.
@@ -116,9 +114,9 @@ The following referenced documents are not necessary for the application of the

<span id="_ref_i.12"></span><a name="_ref_i.12">[i.12]</a> EU C-ITS Security Policy <(https://cpoc.jrc.ec.europa.eu/Documentation.html)

<span id="_ref_i.13"></span><a name="_ref_i.13">[i.13]</a> [European commission's eIDAS Dashboard](https://eidas.ec.europa.eu/efda/home)
<span id="_ref_i.13"></span><a name="_ref_i.13">[i.13]</a> "Directive (EU) 2023/2661 of the European Parliament and of the Council of 22 November 2023 amending Directive 2010/40/EU": " on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport " 

<span id="_ref_i.14"></span><a name="_ref_i.14">[i.14]</a> [Qualified Signature/Seal Creation Devices and Secure Signature Creation Devices](https://eidas.ec.europa.eu/efda/browse/notification/qscd-sscd ).
<span id="_ref_i.14"></span><a name="_ref_i.14">[i.14]</a> "ETSI TS 103 097": " Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile " 

<span id="_ref_i.15"></span><a name="_ref_i.15">[i.15]</a> ETSI TR 119 540: "Electronic Signatures and Trust Infrastructures (ESI);
Standardization requirements for Smart Contracts
@@ -130,10 +128,6 @@ based on Electronic Ledgers" - V1.1.1, October 2025

<span id="_ref_i.18"></span><a name="_ref_i.18">[i.18]</a> "IETF RC 5280": "Intelligent Transport Systems (ITS); Security; Security header and certificate formats; Release 2" 

<span id="_ref_i.19"></span><a name="_ref_i.19">[i.19]</a> "ETSI TS 103 097": " Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile " 

<span id="_ref_i.20"></span><a name="_ref_i.19">[i.20]</a> "Directive (EU) 2023/2661 of the European Parliament and of the Council of 22 November 2023 amending Directive 2010/40/EU": " on the framework for the deployment of Intelligent Transport Systems in the field of road transport and for interfaces with other modes of transport " 

# 3 Definition of terms, symbols and abbreviations

## 3.1 Terms
@@ -284,7 +278,6 @@ For the purposes of the present document, the following abbreviations apply:
`EA     Enrolment Authority (similar to LTCA)`  
`EC     Enrolment Credential (similar to LTC)`  
`ECTL   Extended Certificate Trust List`   
`eIDAS  Electronic Identification, Authentication and Trust Services`  
`HMAC   Hash-based Message Authentication Code`  
`HSM    Hardware Security Module`  
`IEEE   Institute of Electrical and Electronics Engineers`  
@@ -293,7 +286,6 @@ For the purposes of the present document, the following abbreviations apply:
`ITS    Intelligent Transport System`  
`MA     Misbehaviour Authority`  
`NA     National Accreditation`   
`NIS2   Network and Information Security Directive 2`  
`OCSP   Online Certificate Status Protocol`  
`PKC    Public Key Certificate`  
`PKI    Public Key Infrastructure`  
@@ -328,15 +320,11 @@ The present document describes product contexts for products with digital elemen

The reasonably foreseeable use of the product is to support certification services where a compromise carries a significant risk of impact to the security of other products, networks or services, or to the health, security or safety of the public.

> EXAMPLE 1: eIDAS. 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.

> EXAMPLE 2: C-ITS. In the context of the present document ETSI TS 102 941 [[i.7](#_ref_i_7)] and the EU C-ITS Certificate Management System policy [[i.11](#_ref_i_11)] and security profile [[i.12](#_ref_i_12)] documents  identify specific requirements on hardware elements and their certification.
> EXAMPLE 1: C-ITS. In the context of the present document ETSI TS 102 941 [[i.7](#_ref_i_7)] and the EU C-ITS Certificate Management System policy [[i.11](#_ref_i_11)] and security profile [[i.12](#_ref_i_12)] documents  identify specific requirements on hardware elements and their certification.

> EXAMPLE 3: Software used to issue certificates for public web sites and to validate the identity of web sites (these capabilities are often built into web-browsers).
> EXAMPLE 2: Software used to issue certificates for public web sites and to validate the identity of web sites (these capabilities are often built into web-browsers).

> EXAMPLE 4: Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.

> EXAMPLE 5: Online Certificate Status Protocol support. Software used to verify the status of PKCs.
> EXAMPLE 3: Online Certificate Status Protocol support. Software used to verify the status of PKCs.

A single box PKI solution wherein one or more of the examples above are deployed in a single device and interfacing to other client devices within a closed environment.

@@ -358,9 +346,6 @@ Products with digital elements used as part of a public key cryptography scheme
- **F.CertificateProfileManagement**: Administration functions to define the format and default values of certificates to be signed.
- **F.PseudonymCertIssuance**: Issues 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.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.
@@ -488,9 +473,7 @@ Critical entities often need to produce their own certificates to manage sensiti

As a result, users of these PKI solutions do not have the same deployment flexibility as in less regulated use cases (e.g., UC1). However, they are still permitted to use products that offer diverse functionalities.

> EXAMPLE 1: Products deployed for Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.

> EXAMPLE 2: Products deployed by telecommunications service providers used to manage proofs of identity, authorization, and encryption to enable secure access to internal services and customer-facing networks, including e.g. 5G core and edge systems, as standardized in 3GPP TS 33.501 and ETSI GS NFV 003. The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information (e.g., via CRLs or OCSP).
> EXAMPLE 1: Products deployed by telecommunications service providers used to manage proofs of identity, authorization, and encryption to enable secure access to internal services and customer-facing networks, including e.g. 5G core and edge systems, as standardized in 3GPP TS 33.501 and ETSI GS NFV 003. The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information (e.g., via CRLs or OCSP).

### 4.6.3  Public PKI for critical entities (UC3)

@@ -498,23 +481,19 @@ Product used to support certification management services (registration, certifi

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  [\[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)

Product used to support certification services (certificate generation, revocation and status management) provided within very large multi-site company or provided by a CA to the public, and where a compromise carries a significant risk of impact to the security of remote or unknown users, other products, networks or services, or to the health, security or safety of the public.

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 Trust services. Software used to issue certificates for trust services including those used in electronic attribute attestation.

### 4.6.5 Multi-authority PKI for critical entities (UC5)

In general terms the multi-authority model separates the entity responsible for authentication from the entity responsible for authorisation of specific services, in like manner to the model of Kerberos [\[i.5\]](#_ref_i_5) but applied to a public key system.

The multi-authority PKI is intended to combine multiple authorities in a single (extended) domain, sharing resources, and enforcing minimisation of identifying data. In like manner to Kerberos the certificate model in multi-authority PKI enables anonymous or pseudonymous proof of authority. The product in multi-authority PKIs is expected to be able to generate and distribute signed attestations of authority, to verify any received attestation of authority, and to maintain the status of stored public keys.

> EXAMPLE 1: The PKI dedicated to Co-operative Intelligent Transport Systems (C-ITS) is used to manage proofs of authorisation and identity to enable access to services on different components of ITS systems standardized in ETSI TS 102 940 [\[i.16\]](#_ref_i_16) and ETSI TS 102 941 [\[i.7\]](#_ref_i_7). The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information. The PKI service architecture and its functionalities considered here are the one .The C-ITS PKI standards provide the basis for the EU C-ITS security credential management system [\[i.20\]](#_ref_i.20).
> EXAMPLE 1: The PKI dedicated to Co-operative Intelligent Transport Systems (C-ITS) is used to manage proofs of authorisation and identity to enable access to services on different components of ITS systems standardized in ETSI TS 102 940 [\[i.16\]](#_ref_i_16) and ETSI TS 102 941 [\[i.7\]](#_ref_i_7). The product is responsible for the issuance, revocation, and overall management of certificates and certificate status information. The PKI service architecture and its functionalities considered here are the one .The C-ITS PKI standards provide the basis for the EU C-ITS security credential management system [\[i.13\]](#_ref_i.13).
  
> NOTE 1: For the C-ITS example within this use case the product requirements for the ITS-Station acting as a signature creation and verification element the European C-ITS trust model specifies that the ITS-S conforms to a specific protection profile.

@@ -629,27 +608,22 @@ This clause addresses the requirements in the CRA [\[i.1\]](#_ref_i.1) Annex 1 P
        - F.AuditEventManagement 
        - F.LoggingOfSecurityEvents  
        - F.CertificateProfileManagement    
     
     - Registration 
        - F.OnlineRegService 
        - F.CertificateDissemination 
        - F.PrivateKeyImportExport 
        - F.OfficerRegistrationApproval  
     
     - Certificate generation 
        - F.SCD_BasedKeyPairGen 
        - F.NoneSCD_BasedKeyPairGen 
        - F.SubjectCertSignCreation 
        - F.OfficerCertGenApproval 
        - F.PseudonymCertIssuance  
     
     - Certificate status 
        - F.CertificateStatus   
     
     - Revocation management 
        - F.RevocationManagement  
        - F.OfficerRevocationApproval 

  - APPLICABILITY: UC2, UC3, UC4 and UC5.

## 5.6 Confidentiality
@@ -920,7 +894,7 @@ To limit certificate forgery or misuse of certificate content, this section defi

- REFERENCE: REQ-PKI-EMM-02
  - REQUIREMENT: The product shall implement a certificate profile compliant to the base standard of REQ-PKI-EMM-01 (a or b) and appropriate to its scope/context  and shall ensure that issued certificates are consistent with that profile.
  - RATIONALE: The specification of a specific certificate profile (e.g. by reference to applicable standards such as IETF RFC 5280  [\[i.18\]](#_ref_i.18)  or ETSI TS 103 097  [\[i.19\]](#_ref_i.19) ) is in scope of a Certificate Policy and out of the scope of the present document. However, requiring the implementation of a certificate profile ensures that authorized users can ensure interoperability of PKIs and that certificate content contains only normalised and necessary information to minimize attack surface.
  - RATIONALE: The specification of a specific certificate profile (e.g. by reference to applicable standards such as IETF RFC 5280  [\[i.18\]](#_ref_i.18)  or ETSI TS 103 097  [\[i.14\]](#_ref_i.14) ) is in scope of a Certificate Policy and out of the scope of the present document. However, requiring the implementation of a certificate profile ensures that authorized users can ensure interoperability of PKIs and that certificate content contains only normalised and necessary information to minimize attack surface.
  - APPLICABILITY: All use cases.

- REFERENCE: REQ-PKI-EMM-03
@@ -1023,7 +997,6 @@ These requirements are about the collection and handling of auditable events, th

- REFERENCE: 	REQ-PKI-MON-01
  - REQUIREMENT: The product shall record events related to all product functions identified for each use case (as defined in Annex U), as well as all privileged user login attempts and product updates.

  - RATIONALE: All management functions of the PKI can impact the overall confidence in the system. Therefore, events related to Registration, Certificate Generation, Certificate Status, and Revocation Management must be recorded. Additionally, the management of privileged user accounts and their login activities must be logged to ensure accountability, which is critical for maintaining trust in the produced and managed PKI certificates.
  - APPLICABILITY: All use cases.

@@ -3751,8 +3724,6 @@ Product used to support certification management services (registration, certifi

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 [\[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).

![Figure U.3.2: UC3 functional architecture](media/Figures/UC_Architecture/UC3.png)

**Figure U.3.2: UC3 functional architecture**