Commission notice on guidelines with regard to the procedure for accreditation, approval and authorisation of independent operators to access vehicle security features laid down in Annex X to Regulation (EU) 2018/858 2022/C 288/02
Date: 2022-07-29
Institutions: Directorate-General for Internal Market, Industry, Entrepreneurship and SMEs, European Commission
Subjects: EC conformity marking, approval, exchange of information, market supervision, motor vehicle, road safety, safety device, technical specification, technical standard




C_2022288EN.01000701.xml










29.7.2022   


EN


Official Journal of the European Union


C 288/7






Commission notice on guidelines with regard to the procedure for accreditation, approval and authorisation of independent operators to access vehicle security features laid down in Annex X to Regulation (EU) 2018/858
(2022/C 288/02)
Commission Delegated Regulation (EU) 2021/1244 (1) amends Annex X to Regulation (EU) 2018/858 (2) and notably adds a new Appendix that lays down the procedure for the approval and authorisation of independent operators (IO) to access vehicle security features.
The legal obligations of the procedure regarding the role and responsibilities of the bodies involved in the approval and authorisation of independent operators and their employees to be granted access to security-related vehicle repair and maintenance information are laid down in Regulation (EU) 2018/858, Annex X, Appendix 3. In accordance with point 6.3 of Annex X functional requirements on the application of the procedure are provided in support of the legal obligations through examples and use cases in the Annex to this Commission Notice.


(1)  Commission Delegated Regulation (EU) 2021/1244 of 20 May 2021 amending Annex X to Regulation (EU) 2018/858 of the European Parliament and of the Council as regards the standardised access to vehicle on-board diagnostics information and repair and maintenance information, and the requirements and procedures for access to vehicle security information (OJ L 272, 30.7.2021, p. 16).

(2)  Regulation (EU) 2018/858 of the European Parliament and of the Council of 30 May 2018 on the approval and market surveillance of motor vehicles and their trailers, and of systems, components and separate technical units intended for such vehicles, amending Regulations (EC) No 715/2007 and (EC) No 595/2009 and repealing Directive 2007/46/EC (OJ L 151, 14.6.2018, p. 1).




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.