Update file EN-304-624.md

#### 4.5.1.2.1 Services

The product supports one or more of the following component services (see ETSI EN 319 411-1):

    • Registration service: registers and receives certificate requests from subscribers; verifies the identity and, if applicable, attributes of a subject; and passes verified certificate requests to the certificate generation service.

- Registration service: registers and receives certificate requests from subscribers; verifies the identity and, if applicable, attributes of a subject; and passes verified certificate requests to the certificate generation service.

EXAMPLE 1:	This service verifies ownership of the domain in requests for public web site certificates. 

NOTE 3:	Registration and verification of subject identities can involve personal data such as contact details and passport information.

    • Certificate generation service: generates and manages the CA keys; creates and signs subject certificates based on the identity and other attributes verified by the registration service; and passes the signed subject certificates to the dissemination service.

- Certificate generation service: generates and manages the CA keys; creates and signs subject certificates based on the identity and other attributes verified by the registration service; and passes the signed subject certificates to the dissemination service.

NOTE 4:	The certificate profile used in certificate creation, including the signature algorithm, certificate lifetime and key usage restrictions, is determined by the CA's Certificate Policy (CP) or an equivalent document.

NOTE 6:	This service can include generation of subject keys and, if used for decryption, storage of subject private keys to allow key recovery.

    • Dissemination service: disseminates signed certificates to subscribers; and, if the subscriber consents, stores and makes them available to relying parties.

- Dissemination service: disseminates signed certificates to subscribers; and, if the subscriber consents, stores and makes them available to relying parties.

NOTE 7:	This service can make available the CA's terms and conditions, policy and practice information to subscribers and relying parties.

NOTE 8:	This service can disseminate subject private keys to subscribers if the subject keys are generated by the certificate generation service.

    • Revocation management service: processes requests and reports relating to revocation to determine the necessary action to be taken; and provides updates to the certificate status service.

- Revocation management service: processes requests and reports relating to revocation to determine the necessary action to be taken; and provides updates to the certificate status service.

EXAMPLE 4:	This service verifies that revocation requests are submitted by authorised parties.

EXAMPLE 5:	This service obtains confirmation from the subscriber if a compromise is reported by a third party.

    • Certificate status service: provides certificate revocation status information to relying parties.

- Certificate status service: provides certificate revocation status information to relying parties.

EXAMPLE 6:	This service publishes Certificate Revocation Lists (CRLs) and responds to Online Certificate Status Protocol (OCSP) queries.

The product will typically support some logging of events relevant to each of the component service it provides:

    • Registration service events such as certificate requests and approvals.

- Registration service events such as certificate requests and approvals.

    • Certificate generation service events such as subject key generation and certificate signing operations.

- Certificate generation service events such as subject key generation and certificate signing operations.

    • Revocation management service events such as revocation requests and results.

- Revocation management service events such as revocation requests and results.

#### 4.5.1.2.2 Accounts

In both contexts, the product will support one or more of the following user accounts:

    • System administrator account: authorized to install, configure and update the product.

- System administrator account: authorized to install, configure and update the product.

    • System operator account: authorized to operate the PKI services and perform system backups. 

- System operator account: authorized to operate the PKI services and perform system backups. 

NOTE:	This might consist of separate registration service operator, certificate generation service operator and revocation service operator accounts.

    • System auditor account: authorized to view audit logs and other system data.

- System auditor account: authorized to view audit logs and other system data.

#### 4.5.1.3  SP1 - Operationnal environment requirements

#### 4.5.1.4  SP1 - Users

| User Role | Description |

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

| Administrator | Personnel authorized to install, configure, and maintain the CIMC; establish and maintain user accounts; configure profiles and audit parameters; and generate Component keys.|

| Operator | Personnel authorized to perform system backup and recovery. |

| Officer | Personnel authorized to request or approve certificates or certificate revocations.

| Auditor | Personnel authorized to view and maintain audit logs.| 

||

#### 4.5.1.5  SP1 - Threats

From Certificate Issuing and Management Components Protection Profile Version 1.5  11 August, 2011

T.Critical system component fails - Failure of one or more system components results in the loss of system critical functionality. Threat agent in this case is the CIMC hardware. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Flawed code  A system or applications developer delivers code that does not perform according to specifications or contains security flaws. Threat agent in this case is the TOE developer. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Flawed code  A system or applications developer delivers code that does not perform according to specifications or contains security flaws. Threat agent in this case is the PKI developer. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Malicious code exploitation -An authorized user, IT system, or hacker downloads and executes malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality of the system assets. Threat agent could be an authorized user, TOE itself, or an unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying

T.Malicious code exploitation -An authorized user, IT system, or hacker downloads and executes malicious code, which causes abnormal processes that violate the integrity, availability, or confidentiality of the system assets. Threat agent could be an authorized user, PKI itself, or an unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying

party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

T.Message content modification - A hacker modifies information that is intercepted from a communications link between two unsuspecting entities before passing it on to the intended recipient. Threat agent is an unauthorized user. Adverse action can be compromise of the security of the CIMC and/or relying party systems that rely on the PKI objects such as certificates, CRLs, or OCSP Responses.

### 4.5.3 Security Profile 3 (SP3) - C-ITS PKI

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 TOE 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 TOE 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. 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.

#### 4.5.3.1  SP3 - Assets

#### 4.5.3.2  SP3 - Essential Functions

|Function | description | Associated user/role |

|-|-|-|

|Access audit records | The  C-ITS PKI shall provide the Auditors the capability to access the audit traces generated by the  C-ITS PKI. | Auditor |

|Configure the audit mechanism | The C-ITS PKI shall provide the following audit mechanisms configuration mechanisms: Define/modify audit records format, Definition of event types generating audit traces, Setting of retention period parameter for audit records requiring extended retention |Configuration and management administrator|

|Configure and manage certificate profiles | The  C-ITS PKI shall provide the following configuration capabilities for all certificates profiles: Define 'cracaId' value to be defined by default to 000000'H, Define crlSeries value to be set by default to 0'D, Define the component 'assuranceLevel' of type SubjectAssurance as defined in (IEEE, 2016-03-01), present or absent according to the specification of certificate profiles defined in section 7.2 of (ETSI) (set default value) | Configuration and management administrator |

| | The  C-ITS PKI shall provide the following configuration capabilities for Root CA certificate profiles: Define validity period, Define 'region' of type GeographicRegion as defined in (IEEE, 2016-03-01), including ‘present’ or ‘absence’ parameter, Define 'appPermissions' which contains the ITS-AID for the CRL, CTLs and contain the ITS-AID for the CTL as assigned in (ETSI) | Officer |

| | The  C-ITS PKI shall provide the following configuration capabilities for EC profiles: 'region' of type GeographicRegion as defined in (IEEE, 2016-03-01), present or absence, The 'toBeSigned' component CertificateId shall be set to the choice name and shall contain a unique name associated to the enrolment credential -> default value, 'appPermissions' shall be used to indicate message signing permissions, i.e. permissions to sign a certificate request message contained in a EtsiTs103097Data as defined in (ETSI) | Configuration and management administrator| 

| |The  C-ITS PKI shall provide the following configuration capabilities to Subordinate certification authority certificates (EA / AA) for certificates profiles: 'region' of type GeographicRegion as defined by (IEEE, 2016-03-01), present or absence, 'appPermissions' indicate message signing permissions, i.e. permissions to sign certificate response messages contained in a EtsiTs103097Data, 'certIssuePermissions': this component shall be used to indicate issuing permissions, i.e. permissions to sign an enrolment credential / authorization ticket with certain permissions. as defined in (ETSI) | Officer |

| | The C-ITS PKI shall provide the following configuration capabilities to AT for certificate profiles: 'region' of type GeographicRegion as defined in IEEE Std 1609.2, present or absence, 'appPermissions' shall be used to indicate message signing permissions, i.e. permissions to sign a EtsiTs103097Data. | Configuration and management administrator|

| CRL, CTL and ECTL update | The RCA shall be capable of performing CA certificate revocation: Creation of a new CRL containing a newly revoked CA certificate and the associated updates of the CTL (creation of the new CTL without the revoked CA certificate). The RCA shall be capable of performing addition of a new CA certificate: generation of a new CTL containing the new CA certificate. The SubCA shall be capable of performing CA certificate revocation: Replacement of the CRL by a new CRL provided by the RCA containing a newly revoked CA certificate and associated updates of the CTL (creation of the new CTL without the revoked CA certificate). The SubCA shall be capable of performing addition of a new CA certificate: replacement of the CTL by the new CTL provided by the RCA containing the new CA certificate. The  C-ITS PKI shall be able to download new ECTL. The  C-ITS PKI shall be able to remove of an expired CA certificate from the CTL | Configuration and management administrator |

| Configuration of the DC |  The  C-ITS PKI shall allow to set up of network addresses for the CA, DC and CPOC |Configuration and management administrator |

| Set cryptographic algorithms | The  C-ITS PKI shall allow privileged users to choose algorithms to be used for: Signature, Encryption. |Configuration and management administrator |

| Accept certificates whose validity cannot be determined | There can be cases where open field (e.g. permissions) or standard interpretation can lead to unknown cases for the PKI. In that case the administrator can validate manually the certificate. Only for CA certificates. The acceptance is required when a new CA has to be added to the CTL.| Officer |

| Approve and execute the issuance of CA certificates | Every time an official CA certificates has to be issued, the  C-ITS PKI shall request an Officer to approve and execute this issuance. | Officer |

| Export CA request | Storage of generated CA request on parameterized media. | Officer |

| Perform destruction of sensitive data when no longer needed | E.g. private keys (CA privates keys cf CP sec 6.1.7), repositories (DC or CPOC repo, CP sec. 2.3, but CPOC not managed by the PKI), Records Archival (configuration files, audit logs, PKI documentation, CP sec. 5.5),  | Configuration and management administrator, Officer|

| Perform encrypted export of private key, secret key or critical data |Private key, secret key or critical data can be encrypted and then exported in the form of an encrypted file. | Officer |

| Creation, deletion, management of user accounts | Users account can be created or deleted and the different account privileges can be set up according to the role | Configuration and management administrator|

| Verification of the  C-ITS PKI secure state | Verification of the current state of the  C-ITS PKI to verify that it is in a secure state (e.g. Code integrity validation regarding its signature, verification of the keys integrity, verification of the certificates validity) |Configuration and management administrator, Officer|

#### 4.5.3.3  SP3 - Operationnal environment requirements

#### 4.5.3.4  SP3 - Users

#### 4.5.3.5  SP3 - Threats