ANNEX

Functional requirements: use cases

USE CASE SERMI 1. Requests for changes to the accreditation process and monitoring the implementation across Member States:

Actor ‘Forum for Access to Security-Related Vehicle RMI’ or ‘SERMI’ members and the Commission Goal Actors may make a request to change the scheme. Use Case Input A request for changing the scheme to receive security-related Repair and Maintenance Information (RMI) Use Case Output Updated scheme to receive security-related RMI where appropriate Description SERMI handles requests for scheme changes. Its members evaluate and update the scheme. SERMI advises the Commission on requests for changes to the accreditation process

USE CASE SERMI 2. Selection of trust center(s)

Actor Trust Center (TC) Goal To designate a TC. Use Case Input TC’s application to SERMI which assesses whether the TC fulfills all functional and technical requirements. Use Case Output Accepted or rejected TC application. Updated selected TC list. Description SERMI processes requests from TCs applying for selection according to the criteria in point 4.1.2. of Appendix 3 of Annex X to Regulation (EU) 2018/858, SERMI creates and updates the selected TC list. The Commission is notified.

USE CASE SERMI 3. Setting out the implementation guide for interaction between the entities involved

Actor SERMI and Commission Goal Use of the implementation guide by vehicle manufacturers and TC to achieve correct implementation of the required communication standards Online Certificate Status Protocol (OCSP) and Simple Object Access Protocol (SOAP). Use Case Input Information and known standards. Use Case Output Implementation guide providing all required information for the communication interfaces. Description SERMI provides input to the Commission on the possibility to create and maintain the implementation considering enhancing security requirements and improving technologies over time.

USE CASE NAB 1. Accreditation of a Conformity Assessment Body

Actor Conformity Assessment Body (CAB) Goal Accredited CAB. Use Case Input Application form provided by a CAB to be processed by the National Accredidation Body (NAB). Use Case Output CAB is either accredited or not accredited. NAB accreditation report of CAB. Description Accreditation form provided by the NAB for completion by a CAB. The accreditation form is completed by the organisation applying to be a CAB. The NAB assesses that the organisation fulfills all requirements specified. The accreditation is to ensure that the CAB is assessed for compliance with the standard ‘Conformity assessment – Requirements for the operation of various types of bodies performing inspection’ (ISO/IEC 17020:2012) as inspection body type A. The CAB requests accreditation in accordance with Article 7 of Regulation (EC) No 765/2008.

USE CASE NAB 2. Processing of complaints against CABs

In accordance with Article 9(4) of Regulation (EC) No 765/2008, National accreditation bodies put in place the necessary procedures to deal with complaints against the conformity assessment bodies they have accredited.

The repsonsibilities of the NAB include:

(a) decide on the admissibility of the complaint,

(b) ensure that a complaint concerning an accredited CAB is first addressed by the CAB

(c) take appropriate corrective measures within a reasonable timeframe where necessary,

(d) record all complaints and actions taken, and

(e) respond to the complainant.

During the complaint process through the NAB, all existing Independent Operator (IO) approvals, all employee authorisations, inspection certificates and corrective measures that have been issued by this CAB remain valid.

In case the NAB decides to withdraw the CAB accreditation all IO approvals and related approval inspection certificates and all employee authorisations inspection certificates that have been issued by this CAB ceases to be valid. The CAB subsequently informs the approved IO of that decision. The NAB informs SERMI and the Commission of that decision.

Actor IO, TC, vehicle manufacturer, relevant authorities. Goal To deal with complaints. Use Case Input Complaint against a CAB. Use Case Output Resolution of a complaint against a CAB. Description Complaints are resolved at local level between the CAB and the complainant. Complaints that are not resolved at the local level may be referred to the NAB for further consideration in accordance with Article 9(4) of Regulation (EC) No 765/2008.

USE CASE NAB 3. NAB listing of accredited CABs

Actor NAB Goal NAB maintaining an updated list of all accredited CABs. Use Case Input Accredited CABs. Use Case Output A country-specific list of accredited CABs Description NAB creates, maintains and publishes a country-specific list of all accredited CABs.

USE CASE CAB 1. CAB setting up of a business relationship with Trust Center

Actor CAB Goal CAB sets up a contractual agreement with a selected TC published in the SERMI selected TC list. Use Case Input Contract between the CAB and a selected TC chosen from the list of accepted TCs published by SERMI (see USE CASE SE2). Use Case Output A signed contract between CAB and TC is issued. Description CAB contracts a business relationship with one selected TC according to the published SERMI list in order to: a) Create digital certificates and authorisation records. b) Maintain approval and authorisation status (send out ‘new’ certificates if necessary). c) Send the digital certificate and the PIN letter to be forwarded to the IO employee by the CAB. A CAB sets up only one contractual agreement with one TC.

USE CASE CAB 2. CAB inspects IO for approval

Actor IO Goal Approval of IO, so that an IO can name employee(s) for authorisation to be given to access to security-related RMI. Use Case Input Completed application form as required by the CAB. The application form contains the criteria listed in point 4.3.3. of Appendix 3 of Annex X to Regulation (EU) 2018/858 Use Case Output Paper certificate with the IO approval inspection result. Description IO sends the application form and all necessary documents to the CAB by auditable means. CAB verifies the documents and checks if the IO has already been inspected by another CAB. If the criteria for IO approval (point 4.3.3 of Appendix 3 of Annex X to Regulation (EU) 2018/858) are met the CAB sends the paper approval inspection certificate to the IO. The CAB notifies by auditable means the other CABs in the respective country if the IO does not pass the CAB inspection. CAB verifies that the data provided by the IO is consistent throughout the process. Every IO employee of an IO who becomes authorised for access to security information is registered at the same CAB and TC. Every approved IO can be subject to unannounced random on-site inspections. This will occur once during the IO’s approval validity period.

USE CASE CAB 3. CAB inspections on-site

Actor CAB Goal Minimum of one random and unannounced on-site inspection of every approved IO during the validity period and an IO requested on-site inspection in the last six months of the validity period to ensure that the information given during the application is correct and that the procedural requirements are implemented and practiced in daily operations as stated by the IO in the application for approval. The inspection carried out in the last 6 months will also be used to determine the renewal of an IO approval. On the basis of a complaint against an approved IO or an authorised IO employee, determines whether an on-site inspection is required. Use Case Input Unannounced visit to IO premises. Visit to IO premises on IO request in the last 6 months of the IO approval validity On the basis of a complaint. Use Case Output IO approval is confirmed or revoked. In case the IO approval is revoked, the IO employee authorisations are revoked and the TC is instructed to revoke the corresponding digital certificates. IO approval is renewed (USE CASE CAB 4). Description CAB visits the IO and carries out an on-site inspection by verifying compliance with the criteria in point 4.3.3 of Appendix 3 of Annex X to Regulation (EU) 2018/858. CAB may request the assistance of market surveillance authorities from the Member State they are established for the purposes of an on-site inspection. According to the findings during the inspection the IO approval is confirmed or revoked. The CAB allows the IO to correct minor deficiencies following the negative result of an on-site inspection in accordance point 4.3.1. of Appendix 3 of Annex X to Regulation (EU) 2018/858. A final negative inspection result has for consequence the revocation of the IO approval, the IO employee authorisations and the IO employee digital certificates by the TC.

USE CASE CAB 4. CAB inspects IO for approval’s renewal

Actor IO Goal Renewal of IO approval. Use Case Input Completed application as required by the CAB. The application form contains the criteria listed in point 4.3.2. of Appendix 3 of Annex X to Regulation (EU) 2018/858. Positive result of an IO requested on-site inspection by the CAB in the 6 months prior to the approval expiration deadline. Use Case Output Paper certificate with the inspection result for renewal of an IO approval. Expiration of IO approval, IO employee authorisation and revocation of the digital certificates in case of a negative inspection result or of a denial of the renewal request. Description After a time period of 60 months the approval is to be renewed. Prior to expiry of the approval the IO is notified by the CAB of the pending expiry. This period of notification is of six months before the approval ends. IO requests an on-site inspection by the CAB. The CAB performs the on-site inspection. If the inspection result is negative the CAB revokes the IO approval and the IO employee authorisation(s). The CAB instructs the TC to revoke the IO employee certificate(s). IO sends all documents by auditable means to the CAB two months before the approval expires. CAB verifies the documents and checks if the IO has already been approved or rejected by another CAB. CAB verifies compliance with the concept of legitimate business activity set out in the second paragraph of point 6.3. of Annex X to Regulation (EU) 2018/858. CAB may be assisted by the market surveillance authority from the Member State it is established. If the criteria for IO approval (see point 4.3.3 of Appendix 3 of Annex X to Regulation (EU) 2018/858) are met the CAB sends the approval inspection paper certificate to the IO. The CAB notifies by auditable means, the other CABs in the respective country if the IO does not pass the CAB inspection. CAB verifies that the data provided by the IO is consistent throughout the process. Every employee of an IO who becomes authorised for access to security information following the authorisation inspection described in use case CA6 is registered at the same CAB and TC.

USE CASE CAB 5.CAB handling of IO data

Actor IO Goal IO data to be corrected. Use Case Input IO requests the respective CAB to amend the IO data. IO provides appropriate justification for this amendment and submits it to the CAB. Use Case Output Updated IO data. Description IO sends all necessary documents to the CAB by auditable means. CAB checks the documents. If the CAB determines that the request is justified, the data is amended and the CAB issues the modified paper certificate to the IO.

USE CASE CAB 6. CAB inspects IO employee for authorisation

Actor IO employee Goal Authorisation of an IO employee(s). Use Case Input Completed inspection application form as required by the CAB. The application form complies with the criteria listed in point 4.3.4. of Appendix 3 of Annex X to Regulation (EU) 2018/858 Use Case Output Inspection result sent by CAB to TC in order fot the TC to: (1) issue an electronic certificate for the IO employee, (2) create the IO employee’s authorisation record in the database. Description The IO employee sends the application and all necessary documents to the CAB by auditable means. The CAB checks whether the IO employee had made a previous demand that had been rejected by the CAB itself or any other CAB at Union level. The CAB checks the documents. If the criteria for IO employee authorisation (see point 4.3.4. of Appendix 3 of Annex X to Regulation (EU) 2018/858 ) are met the CAB informs the TC in order to issue an electronic certificate (use case TC1). Every IO employee seeks authorisation with the CAB that its IO is registered with the CAB. Verification of the accuracy and completeness of information submitted by the IO on behalf of its employees is covered by ISO 17020:2012 clause 7.1.6

USE CASE CAB 7. Pseudonymisation of Personal Data in CAB

Actor CAB Goal Pseudonymisation of the personal data from IO employee(s). Use Case Input First name, last name of the IO employee. Use Case Output IO employee unique identifier to be used as in the digital certificate. Description First name, last name of the IO employee is transferred to an IO employee unique identifier that will be used throughout the process for access to security relevant RMI. The use case ensures that the processing of personal data complies with EU-rules on the protection of fundamental rights and freedoms of individuals, as provided in Regulation (EU) 2016/679 and Directive 2002/58/EC.

USE CASE CAB 8. CAB informs TC in order to issue a digital certificate

Actor CAB Goal To provide the IO employee with a digital certificate. Use Case Input CAB inspection result to TC for an authorised employee. Use Case Output Secure token with a digital certificate and a separate PIN for the IO employee sent to CAB. The IO employee receives the PIN associated with the digital certificate forwarded by the CAB by auditable means. Description The CAB sends all necessary data to the TC so that the TC can produce the digital certificate, the secure token and the PIN.

USE CASE CAB 9. CAB inspection of an IO employee for authorisation renewal

Actor IO employee Goal Renewal of an employee authorisation Use Case Input Completed inspection application form as required by the CAB. The application form contains the criteria listed in point 4.3.4. of Appendix 3 of Annex X to Regulation (EU) 2018/858 Use Case Output Renewal inspection result of an IO employee authorisation. Description The CAB informs the IO of the date expiry of the employees’ authorisation, 6 months prior to the actual date of the expiration of the authorisation. IO employee sends all documents by auditable means to the CAB 2 months before the authorisation expires. The authorisation inspection process described in USE CASE CAB 6 is carried out.

USE CASE CAB 10. CABs handling of employee’s data

Actor IO employee Goal The IO employee data is correct. Use Case Input Request to the respective CAB to update the IO employee data. The appropriate form is completed and signed by the IO employee prior to submission to the CAB. Use Case Output Updated IO employee data. Description IO employee sends all necessary documents to the CAB by auditable means. The CAB checks the documents. If the update request affects the data stored in the digital certificate, the CAB informs the TC in order to issue a new digital certificate (USE CASE TC 1).

USE CASE CAB 11. CAB procedure for complaint process

Actor CAB Goal The CAB has a documented process to receive, evaluate and make decisions on complaints; this process complies with the respective national laws. Use Case Input Regulations, standards and SERMI scheme. Use Case Output Documented process for complaints. Description The CAB develops and documents a process for handling complaints. Complaints are resolved at local level between the CAB and the complainant. Parties wishing to make representation with regard to a perceived scheme issue should be able to contact the respective CAB with all necessary information. CAB puts in place the necessary procedures and ressources to carry out an on-site inspection where it determines that is appropriate to assess a complaint. Complaints that are not resolved at the local level may be referred to the NAB for further consideration in accordance with Article 9(4) of Regulation (EC) No 765/2008.

USE CASE CAB 12. CAB processes a complaint concerning an IO approval

Actor Vehicle manufacturer, TC, relevant authority Goal CAB processes complaints regarding an IO approval. IO approval is revoked or confirmed following the process outcome. Approval database is kept up to date. Use Case Input Complaint with the required information according to the process in USE CASE CAB 11. Use Case Output Rejection of the complaint. Or Decision to revoke an IO approval as result of a complaint process: 1) IO approval revocation documented and IO approval classified as revoked in the approval database. 2) IO employee authorisations revoked. Description The CAB investigates the complaint by notably assessing whether the IO has remained compliant with the criteria of point 4.3.3. of Appendix 3 of Annex X to Regulation (EU) 2018/858 and with the concept of legitimate business activity set out in the second paragraph of point 6.3. of Annex X to Regulation (EU) 2018/858. CAB may be assisted by the market surveillance authority from the Member State where it is established. If the reasons for the complaint cannot not be confirmed the complaint is rejected. CAB determines whether an on-site inspection is required. The CAB notably assesses whether the IO has remained compliant with the above points. In case the reasons are confirmed the IO approval is revoked. In the event of a revocation the CAB: 1) informs the IO that the approval is revoked, 2) informs the respective TC in order to immediately document the approval as revoked and to revoke all digital certificates and authorisations from the IO employees of the respective IO, 3) inform all CABs in its Member State about the revocation.

USE CASE CAB 13. CAB processes a complaint concerning an IO employee’s authorisation

Actor Vehicle manufacturer, IO, TC, relevant authority Goal CAB processes complaints regarding an IO employee’s authorisation. IO employee’s authorisation is revoked or confirmed by the TC following the process outcome. Digital certificate revocation list and authorisation database is updated. Use Case Input Complaint with the required information according to the process in USE CASE CA11. Use Case Output Rejection of the complaint. Or Information of the TC in order to revoke IO employee authorisation after a complaint process: 1) IO employee’s digital certificate registered as invalid. 2) IO employee’s authorisation status updated as invalid. Description The CAB investigates the complaint. The CAB notably assesses whether the IO employee still meets the criteria of point 4.3.4 of Appendix 3 of Annex X to Regulation (EU) 2018/858 or has participated in activities that would not be compliant with the concept of legitimate business activity set out in the second paragraph of point 6.3. of Annex X to Regulation (EU) 2018/858. CAB determines whether an on-site inspection is required. CAB may be assisted by the market surveillance authority from the Member State it is established. If the reasons for the complaint cannot not be confirmed the complaint is rejected. In case the reasons are confirmed the IO employee authorisation is revoked. CAB informs the respective TC in order to immediately revoke the employee’s digital certificate and the employee’s authorisation. The CAB informs the IO about the IO employee revocation.

USE CASE CAB 14. CAB provision of statistics

Actor CAB Goal CAB monitors approvals and authorisations. Use Case Input Result of approval, authorisations and on-site inspections. Use Case Output CAB provides a report on a quarterly basis in the first year of CAB activity and then annually to SERMI and the Commission (to be published on SERMI website) Description CAB analyses the results of the approval/authorisation inspection process and provides a report with: — Number of investigations. — Quotient: approvals/applications — Quotient: authorisations/applications — Most common (3 where applicable) reasons for refusing approval — Most common (3 where applicable) reasons for refusing authorisation — Number and outcome of on-site inspections in the reporting period — Most common (3 where applicable) reasons for IO approval revocation — Additionally, the SERMI in cooperation with the Commission can add other Key Performance Indicators (KPI)

USE CASE IO 1. IO requests for approval

Actor IO Goal The IO meets all requirements set out in Appendix 3 of Annex X to Regulation (EU) 2018/858 in order to work with security-related RMI. Use Case Input All necessary documents and application form (as provided by the CAB) in auditable format. Use Case Output Approval of IO or non approval of IO. Description IO uses the NAB website to obtain a list of accredited CAB. The IO contacts the respective CAB. The IO receives the application form from the CAB. The IO fills in the application form and sends the application form and all necessary documents to the CAB by auditable means. When the CAB has inspected the IO the CAB records the approval inspection result in its database in order for the CAB to be able to check in the future whether an IO application has been previously inspected. Every employee of an IO is registered at the same CAB. Non approval of the IO will be notified by the CAB to all other CABs within their respective NAB’s jurisdiction.

USE CASE IO 2. IO registration at the vehicle manufacturer

(see EN/ISO 18541-1:2014, use case 1.1)

USE CASE IO 3. IO business ceases to trade

Actor IO Goal Approval database is updated by CAB. Use Case Input The Information about the IO and its cessation of trade or IO informs the CAB about discontinuance of business. Use Case Output An update of the approval database, together with the revocation of all related certificates and authorisations issued to the employees of that IO. Description The CAB receives information about the IO trade cessation. The CAB informs the TC in order to revoke all certificates and authorisations issued to the employees of that IO.

USE CASE IO 4. Parts ordering

Actor IO Goal Supply an ordered part to the IO. Use Case Input Authentication of IO employee. Security-related parts order. Use Case Output Security-related part. Description Vehicle manufacturer offers security-related parts ordering facility to authorised IO employees. Manufacturers offers an online ordering facility for security-related parts using the digital certificate to confirm the identity of the person requiring the part. Alternatively, they may require security-related parts to be obtained from authorised dealers where currently established authentication procedures are in place. Security parts are delivered by vehicle manufacturers or their agents/authorised dealers in a timely manner to the IOs.

USE CASE IO 5. IO receives secure token

Actor CAB Goal IO receives a secure token with a digital certificate. Use Case Input Secure token with a digital certificate forwarded by CAB. Use Case Output Secure token with a digital certificate received by IO. Description The IO receives an electronic certificate from TC. The IO delivers the electronic certificate to the respective IO employee (see USE CASE EM 6).

USE CASE IO 6. IO record keeping requirements

Actor IO Goal Auditable record of transactions kept by the IO. Use Case Input Documents/Information provided by the repair order. Use Case Output Audit trail and details of the repair job. Description The IO stores data that could be required in the event of an audit. Before issuing a repair order, the IO makes sure that the following information is gathered: 1) Identification of the customer 2) Identification of the vehicle (Vehicle in place) 3) Proof of the authority of the customer to request the work to the vehicle.

USE CASE IO 7. Cessation of employment of an IO employee at an IO

Actor IO Goal Approval/Authorisation data at the CAB is kept up-to-date Use Case Input Information about end of contract with IO employee Use Case Output Updated authorisation data base and request to TC to revoke the respective digital certificate. Description The IO informs the CAB about the change of employment within three working days. The CAB informs the TC in order to update the authorisation data base and to revoke the respective digital certificate. The IO is informed of these changes.

USE CASE IO 8. Procedural requirements for security-related operations

1. General behaviour

Only IO employees of the approved IO, who have been successfully authorised and are in possession of an authorisation inspection certificate and a valid electronic certificate issued by the corresponding trust center, will have access security-related RMI.

The IO employee is responsible for the correct use of the Certificate and PIN.

The IOs and their employees follow the procedures to deal with the end user device (PC, Laptop, etc.) as specified in ISO 18541-2:2014

2. Procedure to conduct a security-related operation

If an employee carries out a security related software update or needs other security related repair and maintenance information for a vehicle operation, the procedure described in point 3 to 5 and shown in the below figure 1 is followed.

Figure 1

Basic outline of the procedure to conduct a security-related operation

3. Customer verification

The IO employee verifies the identification of the customer that has brought in the vehicle.

Possible sources of identification: Identity card, passport, driver’s licence, roadside member card.

The IO is responsible for recording the identity information.

The information provided in figure 2 may be used for this process.

Figure 2

Field reference for customer inspection from the vehicle registration certificate

Vehicle registration documents Data (Part I) Field (Part I) Surname(s) or business name C.1.1 Other name(s) or initial(s) (where appropriate) C.1.2 Address in the Member State of registration on the date of issue of the document C.1.3 Data (Part II) Field (Part II) Surname(s) or business name C.3.1 and C.6.1 Other name(s) or initial(s) (where appropriate) C.3.2 and C.6.2 Address in the Member State of registration on the date of issue of the document C.3.3 and C.6.3

Where possible, the IO employee notes the following data:

(1) Name and surname of the customer.

(2) Identity card/passport number and/or number of the roadside member card.

(3) Fleet management or rental car company name.

(4) Contact name of the respective company.

(5) Address of the respective company.

(6) Telephone number of the respective company.

(7) Driver’s company identification.

This additional information is requested in the circumstances where the customer will not have vehicle registration documents

(8) Fleet management.

(9) Rental Cars.

(10) Loan.

4. Vehicle verification

The IO employee makes sure that the vehicle identification number (VIN) of the vehicle is the same as the Vehicle Identification Number (VIN) on the registration documents (see figure 3).

Figure 3

Community codes from the registration documents for the vehicle inspection

Vehicle registration documents Data (Part I) Field (Part I) Vehicle identification number E

5. Issue the repair order

The next step is to issue the repair order by using a dealer management system. The repair order contains at least the data from figure 4 and the data used to identify the customer and their authority.

Figure 4

Community codes from the registration documents for issuing a repair order

Vehicle registration documents Data Field Registration number A Make D.1 Type, variant, version D.2

The current value of the odometer and the reason for the repair is noted and the repair order needs to be signed by the customer (owner and/or the person who brings the vehicle to the IO). Figure 5 describes the procedure for IO and employee.

Signed repair orders are kept for a minimum of 5 years by the IO.

Figure 5

Procedural requirements for IO

USE CASE EM 1. IO employee requests authorisation

Actor IO employee Goal IO employee receives authorisation to work with security-related RMI. Use Case Input IO employee meets all requirements specified in the Appendix. IO employee fills in the application form from the CAB. Use Case Output Authorisation of an IO employee, so that the IO employee can receive the digital certificate to access security-related RMI. Description The IO employee receives the application form from the CAB if the IO has requested the authorisation of the respective employee. The IO employee completes the application form and sends the application form and all necessary documents to the CAB by auditable means. The CAB issues an authorisation inspection certificate to the IO employee and communicates the positive inspection result to the TC in order to create an authorisation record and to issue a digital certificate for this IO employee. The CAB also keeps trace of the IO employee rejection if the inspection is not successful.

USE CASE EM 2. IO employee registration at a vehicle manufacturer

(see EN/ISO 18541-1:2014 use case 1.2)

Actor IO or IO employee Goal To register IO employee for use of the vehicle manufacturer RMI system as defined by the IO. Use Case Input - Request from the IO to register a new IO employee. User id and password of the IO are necessary. - An IO employee’s request, indicating that they are associated with an IO, and are requesting confirmation from the IO legal representative to complete registration Use Case Output IO’s employee registered as an authorised user in the VM RMI system. Description The vehicle manufacturer requests the IO to confirm the validity of the IO data. The vehicle manufacturer accepts IO’s employee as a user and informs the user accordingly. The vehicle manufacturer RMI system asks the user to choose a User ID and either assigns an initial password to the user or allows them to enter one that satisfies the vehicle manufacturer’s password security requirements. The vehicle manufacturer may charge a reasonable registration fee to the IO.

USE CASE EM 3. Employee access to security-related RMI

(see EN/ISO 18541:2014 all parts)

USE CASE EM 4. Receipt of the PIN from the CAB

Actor CAB Goal Supply to the IO employee the PIN letter for the secure token with the digital certificate. Use Case Input PIN from TC. Use Case Output PIN letter delivered to IO employee. Description The CAB prepares a PIN letter with the PIN supplied by the TC for this identity and sends it to the IO employee home address by auditable means.

USE CASE EM 5. IO employee receives the digital certificate from IO

Actor IO, IO employee Goal Supply the electronic certificate to the IO employee. Use Case Input Electronic certificate. Use Case Output IO employee receives the electronic certificate from IO. Description The IO employee receives the electronic certificate from the IO with the corresponding identity.

USE CASE TC 1. Trust Center creates and delivers certificate

Actor CAB Goal CAB receives certificates and PIN for distribution to IO employees Use Case Input Request for creation of a digital certificate. Use Case Output Digital certificate and PIN. Description The CAB contacts the TC (see USE CASE CAB 11 for procedure). The TC creates the digital certificate and provides it to the CAB for distribution to the IO employee by using the following procedure: (1) TC sends the personalised digital certificate to the CAB by auditable means. (2) The pin code is sent by auditable means to the CAB separately to the digital certificate

USE CASE TC 2. Trust Center assesses digital certificate’s validity

Actor Vehicle manufacturer Goal Validation of the status of a digital certificate. Use Case Input Digital certificate serial number. Use Case Output Status supplied by TC is the following: 0 → Suspended 1 → Ok 2 → Revoked 3 → Unknown Description Vehicle manufacturer asks the TC for the status of employees’ digital certificate for authentication using the communication defined in OCSP standard. The TC responds to the OCSP-responder status. The TC maintains for this purpose a revocation database according to the OCSP standard.

USE CASE TC 3. Trust Center provision of IO employee authorisation status

Actor Vehicle manufacturer Goal Validation of authorisation status using SOAP/RESTful API. Use Case Input Digital certificate serial number and attributes. Use Case Output Status replied by TC is the following: Validity IOEUID IOUID CABUID Description Vehicle manufacturer asks for IO employees’ authorisation status. TC responds to the authorisation status.

USE CASE TC 4. Trust Center suspension of issued certificates

Actor Vehicle manufacturer, IO, CAB, relevant authority Goal Digital certificate suspension to prevent future misuse by a certificate owner in case of a detected misuse. Use Case Input Triggered by an employee of the actor with a serial number or by other means to identify the certificate. Use Case Output Suspension of certificate, status OCSP updated. TC sends information to the CAB. Information to IO employee as to the reason for the digital certificate suspension. Description Appropriate employee of the respective participant. This employee of a CAB sends a message to the TC by auditable means. The message contains: — Letterhead of the respective participant. — Serial number or other means to identify the certificate. — Transaction number from the respective participant, if necessary. The suspension processes immediately upon receipt of the suspension request. The TC inspects the origin of the message: — TC suspends the digital certificate (updated OCSP). — TC informs the CAB about the suspension to initiate the complaint process in written or electronic form.

USE CASE TC 5. Trust Center suspension of an approval of an IO

Actor Vehicle manufacturer, CAB, relevant authority Goal Suspension of the authorisation of all employees for a specific IO (plus all authorisations belonging to that IO) to prevent future misuses by the employees of an IO in case of detected misuses. Use Case Input Requested by employee representative of an authenticated actor (i.e. with an appropriate certificate) e.g. an employee of a CAB who is responsible for the suspension with the IO unique identifier or other means to identify the IO. Use Case Output Suspended authorisation(s) updated TC sends information to the CAB Description Authenticated employee of the respective actor sends a message to the TC by auditable means. The message contains: — Letterhead of the respective participant. — IO unique identifier or other means to identify the IO. — Transaction number from the respective participant, if necessary. — Reason of suspension. The suspension is processed upon receipt of the suspension request. The TC verifies the origin of the message. TC suspends all authorisations belonging to the IO. The TC informs the CAB about the suspension to initiate the complaint process in written or electronic form.

USE CASE TC 6. Trust Centers suspends IO employee’s authorisation

Actor Vehicle manufacturer, IO, CAB, relevant authorities Goal Suspension of authorisation of an IO employee to prevent future misuses in case of a detected misuse. Use Case Input Requested by a representative of an authenticated participant. Use Case Output Suspension of authorisation, updated authorisation database. Suspension notification to the CAB. Information to IO employee on the reason for the authorisation suspension. Description Authenticated employee of the respective participant e.g. an employee of a CAB who is responsible for the suspension sends information to the TC (using a common method). The information contains: — Letterhead of the respective participant. — IO unique identifier. — IO employee unique identifier. — Transaction number from the respective actor, if necessary. — Reason of suspension. The suspension is processed upon receipt of the suspension request. The TC verifies the origin of the information. TC suspends an authorisation belonging to an employee. TC informs the CAB about the suspension to initiate the complaint process in written or electronic form.

USE CASE TC 7. Trust Centers revokes IO approval

Actor CAB Goal Approval data base is kept up to date. Use Case Input CAB notifies the decision to revoke the IO approval. Use Case Output IO approval classified as revoked in database. Description The TC will update the approval data base after receipt of the CAB notification of the decision to revoke a particular IO. The IO approval is classified as revoked. The digital certificates and the authorisations of all IO employees of this IO are classified as revoked in the corresponding data bases.

USE CASE TC 8. Trust Centers revokes IO employee’s authorisation

Actor CAB Goal Digital certificate and authorisation data bases are kept up to date. Use Case Input CAB notifies the decision to revoke the IO authorisation. Use Case Output IO’s employee digital certificate is classified as revoked. IO employee’s authorisation is classified as revoked. Description The TC will update the digital certificate and the authorisation data bases after receipt of the CAB notification of the decision to revoke a particular IO employee. The digital certificate and the authorisation of the IO employees of this IO are classified as revoked in the corresponding data bases.

USE CASE TC 9. Trust Center provides an environment to test the readiness of a certificate and the TC provided Multi Factor Authentication method

Actor IO employee Goal Confirmation to the IO employee that the electronic certificate works. Use Case Input IO employee electronic certificate + PIN and Multi Factor Authentication on client device(s). Use Case Output Test ok / not ok. Message with failure details in case of not ok. Description The employee connects to the website of the TC. The IO employee logs on to the TC test website with his electronic certificate. The IO employee sees result of test (ok/not ok.) The TC logs actions for further support process (e.g. vehicle manufacturer).

USE CASE TC 10. TC provides an interface regarding the specifications of use case CA1

Actor TC Goal TC support of standard communication interface between TC and CAB (web service). Use Case Input Information and known standards to develop a communication interface (web service). Use Case Output Communication interface between TC and CAB. Description The TC develops and runs a standard communication interface for the CAB. The CAB uses this standard communication interface. It may be used for ordering the digital certificate.

USE CASE TC 11. TC provides test users with test certificates to validate the communication (OCSP & SOAP/RESTful API)

Actor Vehicle manufacturer Goal The functional communication between a vehicle manufacturer and a TC. Use Case Input Request to the TC interface. Use Case Output Test data: test users, test certificates, test authorisation database content. Description Vehicle manufacturer requests for test data in all appropriate languages for all appropriate markets. The TC sends information (test users/test certificates) which covers all possible testing outcomes to the vehicle manufacturer.

USE CASE VM 1. Investigation of an IO approval

Actor Vehicle manufacturer (VM) Goal To investigate if an existing approval should remain valid. Use Case Input Vehicle manufacturer notices possible abuse/indication of abuse. Use Case Output The possible abuse or indication of abuse is confirmed or rejected. Description In case of non-compliance with the criteria of point 4.3.3 of Appendix 3 of Annex X to Regulation (EU) 2018/858 or with the concept of legitimate business activity set out in the second paragraph of point 6.3. of Annex X to Regulation (EU) 2018/858, the vehicle manufacturer reports this non-compliance of an IO to the CAB. The vehicle manufacturer starts the complaint process by informing the respective CAB. The vehicle manufacturer is free to notify the relevant authorities, if applicable.

USE CASE VM 2. Investigation of an IO employee authorisation

Actor Vehicle manufacturer Goal To investigate if existing authorisation should remain valid. Use Case Input Vehicle manufacturer notices possible abuse/indication of abuse. Use Case Output The possible abuse or indication of abuse is confirmed or rejected. Description In case of non-compliance with the criteria of point 4.3.3 of Appendix 3 of Annex X to Regulation (EU) 2018/858 or with the concept of legitimate business activity set out in the second paragraph of point 6.3. of Annex X to Regulation (EU) 2018/858, the vehicle manufacturer reports these indications of abuse to the CAB. The vehicle manufacturer may where necessary block the IO employee internally. The vehicle manufacturer starts the complaint process by informing the respective CAB. The vehicle manufacturer is free to notify the relevant authorities.

USE CASE VM 3. Vehicle manufacturer blocks IO's access

Actor Vehicle manufacturer, CAB Goal IO (and subsequently all connected IO employees) is denied access to security-related information. Use Case Input Vehicle manufacturer registers IO non-compliance regarding the terms and conditions. Use Case Output Access to security information blocked for the IO (and all the IO employees). Description Following its investigation, the CAB has determined that the approval should be revoked The vehicle manufacturer can subsequently block the IO access internally. The vehicle manufacturer blocks the access to security information for that IO.

USE CASE VM 4. Vehicle manufacturer blocks IO employee's access

Actor vehicle manufacturer, CAB Goal Vehicle manufacturers have the opportunity to block an IO employee from access to security-related RMI. Use Case Input Vehicle manufacturer registers reason to block IO employee. Use Case Output Access to security information blocked for the IO employee. Description Following its investigation, the CAB has determined that the approval should be revoked. The vehicle manufacturer can subsequently block the employee access internally. The vehicle manufacturer blocks the access to security information for that IO employee.

USE CASE VM 5. Vehicle manufacturer inspections authorisation status of IO employee

Actor Vehicle manufacturer Goal Vehicle manufacturer verifies the authorisation status when the employee uses the certificate for authentication to access security-related RMI. Use Case Input Content information of the employee electronic certificate. Use Case Output Authorisation status Description The vehicle manufacturer verifies the validity of the certificate (TC, OCSP.) The vehicle manufacturer verifies if the employee is blocked (vehicle manufacturer internal). The vehicle manufacturer verifies the validity of the employee authorisation: — The vehicle manufacturer contacts the TC by using the content information of the employee electronic certificate. — The TC replies with the current authentication status.

USE CASE VM 6. Download of implementation guide from SERMI website by vehicle manufacturer (currently OCSP & SOAP/RESTful API)

Actor Vehicle manufacturer Goal Compliant inspection IO employee granted an authorisation electronic certificate and authorisation inspection certificate. Use Case Input Request for implementation guide. Use Case Output Downloaded implementation guide. Description Download of implementation guide from the SERMI website. The vehicle manufacturer inspects the IO employee electronic certificate and authorisation by using the implementation guide (OCSP, SOAP/RESTful API).

USE CASE VM 7. Vehicle manufacturer supplies information to local authorities

Actor Vehicle manufacturer Goal Supplying information to relevant authority. Use Case Input Customer contacts local authorities. Inquiry by relevant authorities via manual process (no additional IT service required). Use Case Output Information about the vehicle (e.g. history of actions performed on a specific VIN). Description Customer reports an offence punishable by national laws. Gives VIN or transaction information. The competent authority contacts the specific vehicle manufacturer with an inquiry regarding a specific VIN. In the case of a stolen vehicle, if the vehicle is recovered the relevant authority informs the vehicle manufacturer and the status of the vehicle is restored to normal (audit trail contains information about event).

USE CASE. Technical requirements

1.1. Secure communication requirements

Any digital communication or transfer of identification, approval and authorization data among CAB, TC and VM is done by secure means i.e. using https-ssl/tls and mutual authentication based on X.509 certificates.

1.2. Data management description

In the SERMI-scheme only the CAB is collecting and using personal information: The following diagram describes a minimal set of attributes that are to be stored in each entity information system in order to be able to implement defined processes and use cases.

Figure 6

Example of data storage as per ISO 18541-1 Use Case Cluster 1

CAB TC Vehicle manufacturer The CAB shall collect and use for the approval inspection of the IO legal representative the data described in chapter 6.3.3 and for the authorization inspection of the IO employees the data described in chapter 6.3.5 The CAB sends the following data by using the web service: — IOEUID — IOUID — Activation password The TC receives from the CAB the following data: — IOEUID — IOUID — Activation password Additionally the TC generates and uses the following data: — CABUID — Serial number of the electronic certificate — Validity of the electronic certificate — Authorization status The VM generates and uses the following data: — Data according ISO 18541-1 use case cluster 1 — Username and password associated to an IOEUID — IOEUID — IOUID — CABUID — Serial number of the electronic certificate

Attribute description

1) IO employee unique identifier (IOEUID): The string generated by the CAB that strictly identifies the IO employee.

2) IO unique identifier (IOUID): The value generated by the CAB that strictly identifies the IO as a legal entity.

3) CAB unique identifier (UID): The value generated by the Trust Center that strictly identifies the CAB.

4) Serial Number: Contains the X509 certificate serial number, which is unique for each certificate and automatically generated during the certificate issuance.

Authorization X / Status Authorization X:

Describe the authorization(s) and the corresponding status for a user.

1.3. Certificate design

The x509.V3-certificate standard (RFC 5280 and ISO 9594-8.2017) define a list of common fields and values that are to be filled in an electronic certificate.

The digital certificate is to fulfill the security requirements of the BSI (http://www.bsi.de) regarding to key length and cryptography algorithms. The point in time to apply the BSI requirements must be established by the Forum Secure RMI.

When connecting to a server using a digital certificate, the server checks a standard field named ‘Subject DN’ allowing it to do a link with the identity of the IO in the internal VM system.

The following figure demonstrates an excerpt of content fields, required for identification by a VM system. The complete x509.V3-certificate structure defined in the RFC 5280 is not depicted here.

Figure 7

Content fields of the electronic certificate

Field Value Comments Serial Number XXX Certificate serial number. Issuer XXX Friendly name of the TC. Validity X years (From/To date) Certificate lifetime from the certificate issuance to its end of validity. Subject DN IOEUID=<UserUniqueIdentifier>, IOUID=<IOUniqueIdentifier>, CABUID=<CABUniqueIdentifier>, Information checked by the VM system after authentication step for identifying the user. Subject Public Key Info RSA encryption 4 096 bits Algorithm and value of the public key contained in the certificate. Authority Info Access http://XXX OCSP server location which will be defined by the TC.

Validity

Validity period as defined in this scheme. Each electronic certificate is valid for a maximum period of 60 months. This period cannot be longer than the remaining validity period of the employing IO approval.

Subject Distinguished Name (DN)

1) IOEUID: Contains a value generated by the CAB which represents the IO employee identity. This value is unique to an authorised user: if a user requests a new electronic certificate from the same CAB or another CAB (after a renewal or a revocation), he/she has is associated to the same UID. The IOEUID is built as follows: < ISO-3166-1-COUNTRY-CODE OF THE LOCATION OF THE CAB/NAME OF THE CAB/CHARACTER ALPHANUMERIC CODE> Example: BE/CAB-CERT/1234567890A This value has a maximum of 64bits.

2) IOUID: Contains a value generated by the CAB which represents the IO legal name, the address and the VAT number. EXAMPLE: <IO LEGALNAME: JOHNS_GARAGE/ADDRESS:MAINSTREET1BRUSSELS12345/VAT:BE12345678910

3) CABUID: Contains a value generated by the TC which is unique to an accredited CAB. This value has a maximum of 64bits. The CAB has the responsibility to manage unique identifiers for users. The TC has the responsibility to manage unique identifiers IO’s legal entities and CAB.

Subject Public Key Info

Defines the algorithm and length of the public key contained in the electronic certificate. To ensure enough confidence in the strength of the algorithm, a key length of 4 096 bits shall be used.

Authority Info Access

The Trust Center is to provide an OCSP access to the certificate revocation list in order to provide an automatic access to the revocation status of the certificate. The OCSP service is provided 24/7 days.

1.4. Authorisation check Web Service based on SOAP/RESTful API

The VM system is able to check the authorization status of the user requesting access to security information.

This check provides a standard SOAP XML service/RESTful APIbased on HTTPS protocol. Access to this service requires authentication by an electronic certificate. Request at the TC server is based on the following information:

Figure 8

Input data

Input data Field Value Comments IO Employee Unique Identifier (IOEUID) <UserUniqueIdentifier> IO Unique Identifier (IOUID) <IOUniqueIdentifier> Authorization ID <AuthorizationUniqueIdentifier>





Figure 9

Output data user information details retrieval during registration based on SOAP/RESTful API

Output data Field Value Comments User Status 0 → Suspended 1 → Ok 2 → Revoked 3 → Unknown IO employee Unique Identifier <UserUniqueIdentifier>

This check provides a standard SOAP XML service/RESTful API based on HTTPS protocol. A VM specific electronic certificate is required to authenticate access to this service.