Commit 9ba14e75 authored by Sammy Haddad's avatar Sammy Haddad
Browse files

Merge branch 'unstable-develop' into 'main' 

v0.0.6

See merge request cyber/stan4cr2/en-304-624!13
parents 30b21fab 842bb9c0

EN-304-624.md

+90 −64
Original line number Diff line number Diff line
@@ -871,7 +871,7 @@ The CA shall enforce separation between trusted roles with conflicting responsib 


A Public Key Infrastructure (PKI) dedicated to Communicating Intelligent Transport Systems (C-ITS) is used to manage ITS related certificates  to enable deployment of security functions over the different components of ITS systems, mainly signature and encryption of ITS messages. The PKI is responsible for the issuance, revocation, and overall management of certificates and certificate status information.

The PKI architecture and its functionalities considered here are the one standardized by the ETSI in ETSI TS 102 940 and ETSI TS 102 941.

The C-ITS PKI shall provide the different services required by the RCA, EC and AA roles defined by the European C-ITS trust model. In the figure we also identify the role of a Misbehaviour Authority (MA): entity responsible to receive misbehaviour reports coming from ITS-S identifying other misbehaving ITS and emits action requests to the other C-ITS PKI authorities to react to misbehaving behaviour of ITS-S. The current PP does not define requirement for the MA services since the MA communication and services are not yet fully define and standardized. However the PP should be updated when it is.

The C-ITS PKI shall provide the different services required by the RCA, EC and AA roles defined by the European C-ITS trust model. In the figure we also identify the role of a Misbehaviour Authority (MA): entity responsible to receive misbehaviour reports coming from ITS-S identifying other misbehaving ITS and emits action requests to the other C-ITS PKI authorities to react to misbehaving behaviour of ITS-S. 





![Figure 4.7.3-1: C-ITS_PKI_Architecture](media/C-ITS_PKI_Architecture.png)
@@ -1090,14 +1090,14 @@ TODO: (cannot apply to ALL created keys) 
	  - EXAMPLES:

	  - APPLICABILITY:



- REFERENCE: REQ-5.1.5.2-02

- REFERENCE: REQ-5.2-02

  - REQUIREMENT: The PKI shall not persistently store private or symmetric keys in plaintext form.

  - RATIONALE:

  - NOTE: The PKI may store private keys in a secure cryptograhic device.

  - EXAMPLES:

  - APPLICABILITY:



- REFERENCE: REQ-5.1.5.2-03

- REFERENCE: REQ-5.2-03

  - REQUIREMENT: Public keys stored within the PKI, but not within a secure cryptographic device, shall be protected against undetected modification through the use of digital signatures, keyed hashes, or authentication codes.

The digital signature, keyed hash, or authentication code used to protect a public key shall be verified upon each access to the key. If verification fails, the PKI shall not:
@@ -1111,14 +1111,14 @@ Public keys modified without authorization should not be considered safe for use 
  - EXAMPLES:

  - APPLICABILITY:



- REFERENCE: REQ-5.1.5.2-04

- REFERENCE: REQ-5.2-04

  - REQUIREMENT: The PKI shall zeroize secrets in plaintext form.

  - RATIONALE:

  - NOTE:

  - EXAMPLES:

  - APPLICABILITY: Where the PKI temporarily manipulates secrets in plaintext form.



- REFERENCE: REQ-5.1.5.2-05

- REFERENCE: REQ-5.2-05

  - REQUIREMENT: The PKI shall not export private or symmetric keys in plaintext form.

  - RATIONALE: A secret key should not be compromised if its exported form is intercepted.

  - NOTE: The form of the exported private or symmetric key shall follow state of the art techniques guaranteeing its confidentiality.
@@ -1127,7 +1127,7 @@ Public keys modified without authorization should not be considered safe for use 


## 5.3 Certificate issuance



- REFERENCE: REQ-5.1.5.3-01

- REFERENCE: REQ-5.3-01

  - REQUIREMENT: The certificates issued by the certificate generation service shall comply with the X.509 standard [ITU-T X.509] or with the IETF RFC 5280 standard or with the IEEE 1609.2 standard.

  - RATIONALE: This extends what is mandated by ETSI EN 319 411-1 and takes into account the C-ITS PKI use case.

  - NOTE:
@@ -1135,7 +1135,7 @@ Public keys modified without authorization should not be considered safe for use 
  - APPLICABILITY: Where the PKI has a certificate generation service.

 



- REFERENCE: REQ-5.1.5.3-02

- REFERENCE: REQ-5.3-02

  - REQUIREMENT: The certificates issued by the certificate generation service shall be public-key certificates or attribute certificates whose format complies with the X.509 standard [ITU-T X.509].

  - RATIONALE: Public-key certificates shall use version 3 certificates since this standard requires the use of certificates extensions.

  - NOTE: At a minimum, the PKI shall ensure that:
@@ -1158,14 +1158,14 @@ f) the signature field and the algorithm in the subjectPublicKeyInfo field shall 
  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.



- REFERENCE: REQ-5.1.5.3-03

- REFERENCE: REQ-5.3-03

  - REQUIREMENT: The PKI shall implement a certificate profile and shall ensure that issued certificates are consistent with that profile.

  - RATIONALE:

  - NOTE:

  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate generation service.



- REFERENCE: REQ-5.1.5.3-04

- REFERENCE: REQ-5.3-04

  - REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:



a) the authority key identifier;
@@ -1181,7 +1181,7 @@ d) the length of time for which the certificate is valid. 
  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.



- REFERENCE: REQ-5.1.5.3-05

- REFERENCE: REQ-5.3-05

  - REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:



a) keyUsage;
@@ -1195,7 +1195,7 @@ c) certificatePolicies. 
  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.



- REFERENCE: REQ-5.1.5.3-06

- REFERENCE: REQ-5.3-06

  - REQUIREMENT: The PKI shall mark the following extensions as critical:



a) keyUsage;
@@ -1209,7 +1209,7 @@ c) certificatePolicies. 
  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.



- REFERENCE: REQ-5.1.5.3-07

- REFERENCE: REQ-5.3-07

  - REQUIREMENT: The PKI shall disallow the keyUsage extension to simultaneously include values from both of:



a) digitalSignature, contentCommitment, keyCertSign, cRLSign; and
@@ -1221,7 +1221,7 @@ b) keyEncipherment, dataEncipherment, keyAgreement. 
  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.



- REFERENCE: REQ-5.1.5.3-08

- REFERENCE: REQ-5.3-08

  - REQUIREMENT: The PKI shall verify that the prospective certificate subject possesses the private key that

corresponds to the public key in the certificate request before issuing a certificate, unless the public/private key pair

was generated by the PKI and never left the certificate issuance service.
@@ -1235,7 +1235,7 @@ The same private key should not be owned by distinct subjects, including other s 


## 5.4 Certificate status



- REFERENCE: REQ-5.1.5.4-01

- REFERENCE: REQ-5.4-01

  - REQUIREMENT: The certificate status service shall provide certificate revocation statuses as either or both of:



a) CRLs as defined by and subject to the requirements of [ITU-T X.509]; or
@@ -1247,14 +1247,14 @@ b) OCSP responses to OCSP requests as defined by and subject to the requirements 
  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate status service.



- REFERENCE: REQ-5.1.5.4-02

- REFERENCE: REQ-5.4-02

  - REQUIREMENT: The PKI shall implement a CRL profile and shall ensure that issued CRls are consistent with that profile.

  - RATIONALE:

  - NOTE:

  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate status service, issuing CRLs.



- REFERENCE: REQ-5.1.5.4-03

- REFERENCE: REQ-5.4-03

  - REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the following fields and extensions:



a) issuer;
@@ -1268,21 +1268,21 @@ c) nextUpdate. 
  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate status service, issuing CRLs.



- REFERENCE: REQ-5.1.5.4-04

- REFERENCE: REQ-5.4-04

  - REQUIREMENT: The PKI shall implement an OCSP response profile and shall ensure that issued OCSP responses are consistent with that profile.

  - RATIONALE:

  - NOTE:

  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate status service, issuing OCSP responses.



- REFERENCE: REQ-5.1.5.4-05

- REFERENCE: REQ-5.4-05

  - REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the responseType field.

  - RATIONALE:

  - NOTE:

  - EXAMPLES:

  - APPLICABILITY: Where the PKI has a certificate status service, issuing OCSP responses, not restricted to the basic response type.



- REFERENCE: REQ-5.1.5.4-06

- REFERENCE: REQ-5.4-06

  - REQUIREMENT: The PKI shall require the Administrator to specify the set of acceptable values for the responderID field.

  - RATIONALE:

  - NOTE: An OCSP responder is required to be capable to emit OCSP responses of the basic type by [RFC 6960].
@@ -1298,35 +1298,35 @@ c) nextUpdate. 
  - APPLICABILITY:



## 5.5 Certificate renewal

- REFERENCE: REQ-5.1.5.5-01

- REFERENCE: REQ-5.5-01

  - REQUIREMENT: Requirement GEN-6.3.6-10 contained in ETSI EN 319 411-1 shall apply.

  - NOTE: The term "sufficient" in the requirement means that the security is to be evaluated according to the current state of the art.





## 5.6 Certificate re-key

- REFERENCE: REQ-5.1.5.6-01

- REFERENCE: REQ-5.6-01

  - REQUIREMENT: In case of certificate re-key, if any certified names or attributes have changed, the related registration

information shall be recorded, after a proper verification.



## 5.7 Certificate modification

- REFERENCE: REQ-5.1.5.7-01

- REFERENCE: REQ-5.7-01

  - REQUIREMENT: In case of certificate modification, if any certified names or attributes have changed, the related registration

information shall be recorded, after a proper verification.





## 5.8 Certificate suspension and revocation

- REFERENCE: REQ-5.1.5.8-01

- REFERENCE: REQ-5.8-01

  - REQUIREMENT: Once a certificate is revoked, it shall not be reinstated.

  - NOTE: Revocation is intended to be a definitive action, from which this requirement stems



- REFERENCE: REQ-5.1.5.8-02

- REFERENCE: REQ-5.8-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 (V1.5.1) shall apply.



## 5.9 Certificate status services

- REFERENCE: REQ-5.1.5.9-01

- REFERENCE: REQ-5.9-01

  - 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 (V1.5.1) shall apply.



- REFERENCE: REQ-5.1.5.9-02

- REFERENCE: REQ-5.9-02

  - REQUIREMENT: If a PKI 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.

  - NOTE: This is aligned with requirement CSS-6.3.10-09 contained in ETSI EN 319 411-1 (V1.5.1)
@@ -1337,13 +1337,9 @@ information shall be recorded, after a proper verification. 


## 6.1 Auditing



### 6.1.6 Conformity Assessment



#### 6.1.6.1 Auditing



 



REFERENCE: ASS-REQ-6.1.5.1-01

REFERENCE: ASS-REQ-6.1-01



  - OBJECTIVE: Verify that the PKI records within each audit record the required information, and that these records do not include any secret key or other secret parameter in plaintext form.
@@ -1373,7 +1369,7 @@ For each of the generated audit record, verify that no private or symmetric key, 


 



- REFERENCE: ASS-REQ-6.1.5.1-02

- REFERENCE: ASS-REQ-6.1-02



  - OBJECTIVE: Verify that the PKI employs reliable time stamps.
@@ -1399,7 +1395,7 @@ c) arguments relating to the monotonicity of local time information (if applicab 


 



- REFERENCE: ASS-REQ-6.1.5.1-03

- REFERENCE: ASS-REQ-6.1-03



  - OBJECTIVE: Verify that the PKI records within each audit record resulting from actions of identified users the corresponding user information.
@@ -1419,7 +1415,7 @@ a) the way the event was triggered and at what time, and the corresponding audit 


 



- REFERENCE: ASS-REQ-6.1.5.1-04

- REFERENCE: ASS-REQ-6.1-04



  - OBJECTIVE: Verify PKI protections from unauthorised deletion to be active and functional.
@@ -1445,7 +1441,7 @@ d) the copies of existing audit records, before and after attempts. 


 



- REFERENCE: ASS-REQ-6.1.5.1-05

- REFERENCE: ASS-REQ-6.1-05



  - OBJECTIVE: Verify the PKI's ability to detect unauthorised modifications to the stored audit records during the audit.
@@ -1469,7 +1465,7 @@ c) the way the last audit was attempted, and the corresponding response from the 


 



- REFERENCE: ASS-REQ-6.1.5.1-06

- REFERENCE: ASS-REQ-6.1-06



  - OBJECTIVE: Verify the PKI's prevention of auditable events, except those taken by the auditor, if the audit log is full.
@@ -1491,7 +1487,7 @@ c) the way the additional event was attempted to be triggered, and the correspon 


 



- REFERENCE: ASS-REQ-6.1.5.1-07

- REFERENCE: ASS-REQ-6.1-07



  - OBJECTIVE: Verify the use of an audit log signing event by the PKI.
@@ -1551,7 +1547,7 @@ d) the way the second-to-last signature, keyed hash or authentication code was m 


 



- REFERENCE: ASS-REQ-6.1.5.1-08

- REFERENCE: ASS-REQ-6.1-08



  - OBJECTIVE: Verify the frequency of the audit log signing event by the PKI to be configurable.
@@ -1573,11 +1569,11 @@ b) the 2 last audit log signing events as they appear in the audit log, and thei 


 



#### 6.1.6.2 Secret management

#### 6.2 Secret management



 



- REFERENCE: ASS-REQ-6.1.5.2-02

- REFERENCE: ASS-REQ-6.2-02



  - OBJECTIVE: Verify the PKI does not persistently store private or symmetric keys in plaintext form.
@@ -1593,7 +1589,7 @@ a) The documentation of private and symmetric keys profiles and how these keys a 


 



- REFERENCE: ASS-REQ-6.1.5.2-03

- REFERENCE: ASS-REQ-6.2-03



  - OBJECTIVE: Verify public keys stored within the PKI outside a secure cryptographic device are protected against undetected modification, and that public keys are released or used after a detected modification.
@@ -1641,7 +1637,7 @@ c) the way operations making use of public keys were attempted to be triggered, 


 



- REFERENCE: ASS-REQ-6.1.5.2-04

- REFERENCE: ASS-REQ-6.2-04



  - OBJECTIVE: Verify the public key zeroizes secrets in plaintext form.
@@ -1663,7 +1659,7 @@ b) the documentation of zeroization methods employed. 


 



- REFERENCE: ASS-REQ-6.1.5.2-05

- REFERENCE: ASS-REQ-6.2-05



  - OBJECTIVE: Verify the PKI cannot export private or symmetric keys in plaintext form.
@@ -1677,11 +1673,11 @@ b) the documentation of zeroization methods employed. 


 



#### 6.1.6.3 Certificate issuance

#### 6.3 Certificate issuance



 



- REFERENCE: ASS-REQ-6.1.5.3-01

- REFERENCE: ASS-REQ-6.3-01



  - OBJECTIVE: Verify the certificates issued by the certificate generation service are public-key certificates or attribute certificates whose format complies with the X.509 standard [ITU-T X.509].
@@ -1695,7 +1691,7 @@ b) the documentation of zeroization methods employed. 


 



- REFERENCE: ASS-REQ-6.1.5.3-02

- REFERENCE: ASS-REQ-6.3-02



  - OBJECTIVE: Verify the format of public-key certificates issued by the certificate generation service complies with the X.509 standard [ITU-T X.509].
@@ -1705,7 +1701,7 @@ b) the documentation of zeroization methods employed. 


a) issue a certificate;



b) verify points a,c,f of the NOTE of REQ-5.1.5.3-02;

b) verify points a,c,f of the NOTE of REQ-5.3-02;



c) attempt to issue a certificate with a null Name for the issuer field, then verify the certificate contains a critical issuerAltName extension;
@@ -1721,7 +1717,7 @@ b) the way issuances were requested, and the responses and issued certificates f 


 



- REFERENCE: ASS-REQ-6.1.5.3-03

- REFERENCE: ASS-REQ-6.3-03



  - OBJECTIVE: Verify the PKI implements and follows a certificate profile for issued certificates.
@@ -1749,9 +1745,9 @@ c) the way issuances were requested, and the responses and issued certificates f 


 



- REFERENCE: ASS-REQ-6.1.5.3-04

- REFERENCE: ASS-REQ-6.3-04



  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.1.5.3-04.

  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.3-04.



  - PREPARATION: Document the circumstances in which the certificate generation service may issue a public-key certificate.
@@ -1771,7 +1767,7 @@ b) the way issuances were requested, and the responses from the PKI. 


 



- REFERENCE: ASS-REQ-6.1.5.3-05

- REFERENCE: ASS-REQ-6.3-05



  - OBJECTIVE: Verify the PKI marks the keyUsage, basicConstraints and certificatePolicies as critical in issued certificates.
@@ -1795,7 +1791,7 @@ b) the way issuances were requested, and the responses and issued certificates f 


 



- REFERENCE: ASS-REQ-6.1.5.3-06

- REFERENCE: ASS-REQ-6.3-06



  - OBJECTIVE: Verify the PKI disallows the keyUsage extension to offer both digital signature and encryption or key agreement capabilities.
@@ -1825,7 +1821,7 @@ b) the way issuances were requested, and the responses and issued certificates f 


 



- REFERENCE: ASS-REQ-6.1.5.3-07

- REFERENCE: ASS-REQ-6.3-07



  - OBJECTIVE: Verify the PKI ensures a prospective certificate subject possesses the private key that
@@ -1865,11 +1861,11 @@ c) the random values generated by the PKI. 


 



#### 6.1.6.4 Certificate status

#### 6.4 Certificate status



 



- REFERENCE: ASS-REQ-6.1.5.4-01

- REFERENCE: ASS-REQ-6.4-01



  - OBJECTIVE: Verify the certificate revocation statuses to be either or both of CRLs as defined by and subject to the requirements of [ITU-T X.509],
@@ -1885,7 +1881,7 @@ or OCSP responses as defined by and subject to the requirements of [RFC 6960]. 


 



- REFERENCE: ASS-REQ-6.1.5.4-02

- REFERENCE: ASS-REQ-6.4-02



  - OBJECTIVE: Verify the PKI implements and enforces a CRL profile for issued CRLs.
@@ -1903,9 +1899,9 @@ b) verify the CRL to match the constraints of the CRL profile. 


 



- REFERENCE: ASS-REQ-6.1.5.4-03

- REFERENCE: ASS-REQ-6.4-03



  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.1.5.4-03.

  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.4-03.



  - PREPARATION: Administrator access to not-installed or reinitialised PKI, or specifically its certificate status service and related configuration.
@@ -1917,7 +1913,7 @@ b) verify the CRL to match the constraints of the CRL profile. 


 



- REFERENCE: ASS-REQ-6.1.5.4-04

- REFERENCE: ASS-REQ-6.4-04



  - OBJECTIVE: Verify the PKI implements and enforces an OCSP response profile for issued OCSP responses.
@@ -1935,9 +1931,9 @@ b) verify the OCSP response to match the constraints of the OCSP response profil 


 



- REFERENCE: ASS-REQ-6.1.5.4-05

- REFERENCE: ASS-REQ-6.4-05



  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.1.5.4-05.

  - OBJECTIVE: Verify that the PKI requires the Administrator to specify the set of acceptable values for the fields and extensions identified in REQ-5.4-05.



  - PREPARATION: Administrator access to not-installed or reinitialised PKI, or specifically its certificate status service and related configuration.
@@ -1949,9 +1945,39 @@ b) verify the OCSP response to match the constraints of the OCSP response profil 


# Annex A Mapping with essential requirements of the CRA



![Figure A-1: CRA requirements coverage](media/AnnexA_CRAReqCoverageTable_p1.png)

![Figure A-2: CRA requirements coverage](media/AnnexA_CRAReqCoverageTable_p2.png)

![Figure A-3: CRA requirements coverage](media/AnnexA_CRAReqCoverageTable_p3.png)



|No |Description	| Requirements of Regulation |Clause(s) of the present document	|U/C	|Condition

|---|---|---|---|---|---|

|(1)| Identify/document vulnerabilities and components; provide SBOM				

|(2)	| Remediate vulnerabilities without delay; separate security updates from feature updates				

|(3)|	Perform regular testing and reviews of cybersecurity posture				

|(4)|	Disclose fixed vulnerabilities with public advisories				

|(5)|	Enforce coordinated vulnerability disclosure (CVD) policy				

|(6)|	Facilitate third-party vulnerability reporting (contact channels, process)				

|(7)|	Secure update delivery mechanisms				

|(8)|	Updates shall be timely, free of charge, and include user guidance





|No |Description	| Requirements of Regulation |Clause(s) of the present document	|U/C	|Condition

|---|---|---|---|---|---|

|(1) | Design, development, and production must ensure appropriate cybersecurity based on risks

|(2)(a)| No known exploitable vulnerabilities at market release

|(2)(b) | Secure-by-default configuration

|(2)(c) | Vulnerabilities can be addressed via security updates, default to automatic, with opt-out and postponement ||

|(2)(d)| Protection from unauthorised access via authentication and access control

(2)(e)|	Confidentiality of data in storage or transit (e.g., encryption) ||REQ-5.2-01, REQ-5.2-02|

|(2)(f) |Integrity of data, commands, programs, configuration; detect/report manipulation || REQ-5.2-03, REQ-5.3-01, REQ-5.3-02, REQ-5.3-04, REQ-5.3-05, REQ-5.3-06

|(2)(g)|Data minimisation — only adequate and necessary data shall be processed || REQ-5.3-01, REQ-5.3-02, REQ-5.3-03, REQ-5.3-04, REQ-5.4-01, REQ-5.4-02

|(2)(h)| Ensure availability of essential functions including resilience and DoS protection	| REQ-5.1-04, REQ-5.1-05, REQ-5.1-06	

|(2)(i) |Avoid degradation of other systems’ availability (non-interference)				

|(2)(j) |Limit attack surfaces including external interfaces | | 	REQ-5.3-07, REQ-5.3-08, REQ-5.4-01, REQ-5.4-02



|(2)(k)| Include appropriate exploitation mitigation techniques			|| REQ-5.1-07, REQ-5.2-03, REQ-5.2-04, REQ-5.2-05, REQ-5.4-01



|(2)(l) |Logging and internal monitoring of data/function access, with opt-out	| |  	REQ-5.1-01, REQ-5.1-02, REQ-5.1-03, REQ-5.1-04, REQ-5.1-05, REQ-5.1-06, REQ-5.1-07, REQ-5.1-08

			

|(2)(m) |Allow users to permanently remove data and settings securely | |







Key to columns: