WARNING! Gitlab maintenance operation scheduled for Thursday, 18 June between 19:00 and 20:00 (CET). During this time window, short service interruptions (less than 5 minutes) may occur. Thank you in advance for your understanding.
@@ -1021,47 +1021,36 @@ The considered threats for the C-ITS PKI are illustrated in the following figure
a) Date and time of the event, type of event, subject identity (if applicable), and the outcome (success or failure) of the event; and
b) For each audit event type, based on the auditable event definitions in TODO, the additional information specified in TODO.
- RATIONALE:
- RATIONALE: The audit record timestamping and subject identification ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure
- NOTE: The audit shall not include in plaintext any private or secret keys or other critical security parameters.
- EXAMPLES:
- APPLICABILITY:
- APPLICABILITY: All use cases.
- REFERENCE: REQ-5.1-02
- REQUIREMENT: The audit record shall identify the timing source used to generate the timestamp. The timestamp shall be in the scope of the integrity protection of the audit record (to prevent manipulation of the time stamp after the event).
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: The audit record intergrity and timestamping validity ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure
- APPLICABILITY: All use cases.
- REFERENCE: REQ-5.1-03
- REQUIREMENT: For audit events resulting from actions of identified users, the PKI shall be able to associate each auditable event with the identity of the user that caused the event.
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: The audit record intergrity and timestamping validity ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure
- APPLICABILITY: All use cases.
- REFERENCE: REQ-5.1-04
- REQUIREMENT: The PKI shall protect the stored audit records in the audit log from unauthorised deletion.
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: The audit record intergrity and availability ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure.
- APPLICABILITY: All use cases.
- REFERENCE: REQ-5.1-05
- REQUIREMENT: The PKI shall be able to detect unauthorised modifications to the stored audit records during the audit.
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: The audit record intergrity and availability ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure.
- APPLICABILITY: All use cases.
- REFERENCE: REQ-5.1-06
- REQUIREMENT: The PKI shall prevent auditable events, except those taken by the auditor, if the audit log is full.
- RATIONALE: If the PKI system is properly deployed—with appropriate policies, effective system management, and regular log reviews—an overload of logs should be seen as a symptom of a potentially significant security issue. In such cases, corrective actions should be taken before operations return to normal. Meanwhile, a full audit log should never result in the loss of old audit records or prevent future auditable events from being recorded.
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: If the PKI system is properly deployed—with appropriate policies, effective system management, and regular log reviews—an overload of logs should be seen as a symptom of a potentially significant security issue. In such cases, corrective actions should be taken before operations return to normal. Meanwhile, a full audit log should never result in the loss of old audit records or prevent future auditable events from being recorded. The audit record intergrity and availability ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure
- APPLICABILITY: All use cases.
- REFERENCE: REQ-5.1-07
- REQUIREMENT: The PKI shall periodically create an audit log signing event in which it computes a digital signature, keyed hash, or authentication code over the entries in the audit log. The digital signature, keyed hash, or authentication code shall be computed over, at least:
@@ -1070,35 +1059,27 @@ The considered threats for the C-ITS PKI are illustrated in the following figure
b) the digital signature, keyed hash, or authentication code from the previous audit log signed event. The digital signature, keyed hash, or authentication code from the audit log signing event shall be included in the audit log.
- RATIONALE: All entries of the audit log, and the order and exhaustivity of batches of entries should impact authenticity checks of the audit log.
- RATIONALE: All entries of the audit log, and the order and exhaustivity of batches of entries should impact authenticity checks of the audit log. The audit record intergrity ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure.
- NOTE: An audit log signing event shall be performed even if no entry was added to the audit log since the last one.
- EXAMPLES:
- APPLICABILITY:
- APPLICABILITY: All use cases
- REFERENCE: REQ-5.1-08
- REQUIREMENT: The specified frequency at which the audit log signing event occurs shall be configurable.
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: The audit record intergrity ensure that all auditable events are traceable and misuse of the PKI functions can be traced. It covers misuse of users and administrators fonction : T_SYS02, T_SYS04, T_SYS05, T_SYS07, T_SYS10, T_REG01, T_REG03, T.Logs_Tampering, T.Logs_Discolsure.
- APPLICABILITY: All use cases.
## 5.2 Secret management
TODO: (cannot apply to ALL created keys)
- REFERENCE: REQ-5.2-01
- REQUIREMENT: The PKI shall only create key pairs keys by means of a secure cryptographic device appropriate for this use.
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: To ensure trust the PKI software must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices. It covers key tampering and disclosure threats: T_GEN01 to T_GEN08, T.Stored_Certificates_Tampering.
- APPLICABILITY: All use cases
- REFERENCE: REQ-5.2-02
- REQUIREMENT: The PKI shall not persistently store private keys in plaintext form.
- RATIONALE:
- RATIONALE: To ensure trust the PKI software must rely on secure and valid key creation and management systems accessible only to authorised users provided by hardware security devices. It covers key tampering and disclosure threats: T_GEN01 to T_GEN08, T.Stored_Certificates_Tampering.
- NOTE: The PKI may store private keys in a secure cryptograhic device.
- EXAMPLES:
- APPLICABILITY:
- APPLICABILITY: All use cases.
- 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. If verification fails, the PKI shall not:
@@ -1107,17 +1088,14 @@ TODO: (cannot apply to ALL created keys)
b) use the accessed public key.
- RATIONALE: Unauthorized modifications of public keys stored by the PKI should not go undetected.
Public keys modified without authorization should not be considered safe for use and not be disseminated throughout or outside the PKI.
- NOTE:
- EXAMPLES:
- APPLICABILITY:
- RATIONALE: Unauthorized modifications of public keys stored by the PKI should not go undetected. Public keys modified without authorization should not be considered safe for use and not be disseminated throughout or outside the PKI. This requirement covers key tampering and disclosure threats: T_GEN01 to T_GEN08, T.Stored_Certificates_Tampering.
- APPLICABILITY: All use cases
- 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.2-05
@@ -1125,16 +1103,15 @@ Public keys modified without authorization should not be considered safe for use
- 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.
- EXAMPLES: The exported private or symmetric key may be encrypted such that only its designated recipient may decrypt it.
- APPLICABILITY:
- APPLICABILITY: All use cases
## 5.3 Certificate issuance
- 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, 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 and takes into account the C-ITS PKI use case.
- NOTE:
- EXAMPLES:
- APPLICABILITY: Where the PKI has a certificate generation service.
- APPLICABILITY: All use cases where the PKI has a certificate generation service.
f) the signature field and the algorithm in the subjectPublicKeyInfo field shall designate a recommended agreed signature algorithm [ETSI TS 119 312].
- EXAMPLES:
- APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.
- APPLICABILITY: All use cases where the PKI has a certificate generation service, issuing public-key certificates.
- 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.
- RATIONALE: Only valid certifcates as defined by the PKI servide provider policies shall be generated by the PKI. This covers threats: T.AuthorizationValidationProcessTampering
- APPLICABILITY: All use cases where the PKI has a certificate generation service.
- 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:
b) keyEncipherment, dataEncipherment, keyAgreement.
- RATIONALE: The same public key may not be used for signature verification, and encryption or key agreement.
- NOTE:
- EXAMPLES:
- APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.
- APPLICABILITY: All use cases where the PKI has a certificate generation service, issuing public-key certificates.
- REFERENCE: REQ-5.3-08
- REQUIREMENT: The PKI shall verify that the prospective certificate subject possesses the private key that
@@ -1230,9 +1201,8 @@ was generated by the PKI and never left the certificate issuance service.
The PKI may generate a key pair and associated public key, and later communicate the private key to the correct subject in a secure manner.
This may notably be done for other components of the PKI itself needing public-key certificates.
The same private key should not be owned by distinct subjects, including other services of the PKI; if the private key was generated by the PKI but already provided to the subject once, the subject can and should prove its ownership.
- NOTE:
- EXAMPLES:
- APPLICABILITY: Where the PKI has a certificate generation service, issuing public-key certificates.
- APPLICABILITY: All use cases where the PKI has a certificate generation service, issuing public-key certificates.
## 5.4 Certificate status
@@ -1244,15 +1214,13 @@ The same private key should not be owned by distinct subjects, including other s
b) OCSP responses to OCSP requests as defined by and subject to the requirements of [RFC 6960].
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY: Where the PKI has a certificate status service.
- 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.4-03
@@ -1272,15 +1240,13 @@ The same private key should not be owned by distinct subjects, including other s
- 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.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.4-06
@@ -1294,8 +1260,7 @@ The same private key should not be owned by distinct subjects, including other s
- REFERENCE:
- REQUIREMENT:
- RATIONALE:
- NOTE:
- EXAMPLES:
- APPLICABILITY:
## 5.5 Certificate renewal
@@ -1802,9 +1767,7 @@ verify that no certificate may be issued until acceptables values for the identi
- PREPARATION: Document the circumstances in which the certificate generation service may issue a public-key certificate. Ability to request a certificate issuance for the different identified circumstances.
- ACTIVITIES:
For each way the PKI may issue a public-key certificate:
- ACTIVITIES: For each way the PKI may issue a public-key certificate:
- OBJECTIVE: Verify the PKI ensures a prospective certificate subject possesses the private key that
corresponds to the public key in the certificate request before issuing a certificate.
- PREPARATION: Document the circumstances in which the certificate generation service may issue a public-key certificate.
Ability to request a certificate issuance.
- OBJECTIVE: Verify the PKI ensures a prospective certificate subject possesses the private key that corresponds to the public key in the certificate request before issuing a certificate.
-ACTIVITIES:
-PREPARATION: Document the circumstances in which the certificate generation service may issue a public-key certificate. Ability to request a certificate issuance.
For each way the PKI may issue a public-key certificate:
- ACTIVITIES: For each way the PKI may issue a public-key certificate:
a) attempt to issue a certificate with digital signature capabilities for a given public-key;
@@ -1872,17 +1829,7 @@ Among all the issuance attempts, verify the random value to sign or decrypt is a
- REFERENCE: ASS-REQ-6.5-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],
or OCSP responses as defined by and subject to the requirements of [RFC 6960].
- PREPARATION: TODO
- ACTIVITIES: TODO
- VERDICT: TODO
- EVIDENCE: TODO
- 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], or OCSP responses as defined by and subject to the requirements of [RFC 6960].
@@ -2109,10 +2056,30 @@ In the table we evaluate the risks for each use cases related to threats defined
The risk are then calculated and their applicability defined using the matrixes presented in Figure C.1.1-4 and Figure C.1.2-1.
**Figure C.2.2-1: Risk evaluation part 1**
**Figure C.2.2-2: Risk evaluation part 2**
**Figure C.2.2-3: Risk evaluation part 3**
**Figure C.2.2-4: Risk evaluation part 4**
**Figure C.2.2-5: Risk evaluation part 5**
**Figure C.2.2-6: Risk evaluation part 6**
# Annex K (normative) [CRY] Cryptography
V 0.3 (2025-12-07)
This normative annex is intended to provide generic requirements and assessment criteria for the use of
