Publication: Magyar Közlöny
Issue: MK-2007-147 (Year: 2007, Number: 147)
Era: 2004-2010
Section: 
Paragraph Index: 27

2. By License Number, Nature of the vehicle/EU Category Code (optional), Reference Date and Time (optional); in Luxembourg more than one vehicle can be returned when the inquiry is done by Licence Number. By means of these search criteria, information related to one and sometimes more vehicles will be returned. If information for only one vehicle has to be returned, all the items are returned in one response. If more than one vehicle is found, the Party itself can determine which items will be returned; all items or only the items to refine the inquiry (e.g. because of privacy reasons as in UK and Germany, or because of performance reasons). The items, necessary to refine the inquiry are pictured in paragraph 2.2.1. In paragraph 2.2.2 the complete information set is described. When the inquiry is done by Chassis Number, Reference Date and Time, the inquiry can be done in one or all of the participating countries. When the inquiry is done by License Number, Reference Data and Time, the inquiry has to be done in one specific Party. Normally the actual Date and Time is used to make an inquiry, but it’s possible to do an inquiry with a Reference Date and Time in the past. When an inquiry is made with a Reference Date and Time in the past and historical information is not available in the register of the specific Party, the actual information can be returned with an indication that the information is actual information. 2007/147/II. szám 2.2 Data set 2.2.1 Items to be returned necessary for the refinement of the inquiry Item M/O2 Remarks Prüm Y/N3 Data relating to vehicles Licence number M Y Chassis number / VIN M Y Party of registration M Y Make M (D.14) e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y Nature of the vehicle / EU Category Code M (J) mopeds, motorbikes, cars etc. Y 2.2.2 Complete data set Item M/O5 Remarks Prüm Y/N Data relating to holders of the vehicle (C.16) Registration holders’ (company) name M (C.1.1.) separate fields will be used for first name(s), surname, infixes, titles etc., and the name in printable format will be communicated Y First name M (C.1.2) separate fields for first name(s) and initials will be used, and the name in printable format will be communicated Y Address M (C.1.3) separate fields will be used for Street, House number and Annex, Zip code, Place of residence, Party of residence etc., and the Address in printable format will be communicated Y Gender M Male, female Y Date of birth M Y Legal entity M individual, association, company, firm etc. Y ID Number O An identifier that uniquely identifies the person or the company. N Data relating to owners of the vehicle (C.2) Owners’ (company) name M (C.2.1) Y First name M (C.2.2) Y Address M (C.2.3) Y 2 M = mandatory when available in national register, O = optional 3 All the attributes specifically allocated by the Parties are indicated with Y. 4 Harmonised document abbreviation, see Council Directive 1999/37/EC, 29-04-1999 5 M = mandatory when available in national register, O = optional 6 Harmonised document abbreviation, see Council Directive 1999/37/EC, 29-04-1999 2007/147/II. szám Item M/O5 Remarks Prüm Y/N Gender M male, female Y Date of birth M Y Legal entity M individual, association, company, firm etc. Y ID Number O An identifier that uniquely identifies the person or the company. N Data relating to vehicles Licence number M Y Chassis number / VIN M Y Party of registration M Y Make M (D.1) e.g. Ford, Opel, Renault etc. Y Commercial type of the vehicle M (D.3) e.g. Focus, Astra, Megane Y Nature of the vehicle / EU Category Code M (J) mopeds, motorbikes, cars etc. Y Date of first registration M (B) date of first registration of the vehicle somewhere in the world Y Start date (actual) registration M (I) vehicle document date Y End date registration M Y Status M scrapped, stolen, exported, error notification Y Status date M Y kW O (P.2) Y Capacity O (P.1) Y Type of licence number O regular, transito etc. Y Vehicle document id 1 O The first unique document ID as printed on the vehicle document. Y Vehicle document id 2. In Luxembourg two separate vehicle registration document ID’s are used. O A second document ID as printed on the vehicle document. Y Data relating to insurances Insurance company name O Y Begin date insurance O Y End date insurance O Y Address O Y Insurance number O Y 2007/147/II. szám Annex C.2 Data Security 1. Overview The Eucaris software application connects all Parties in a mesh network where each Party communicates directly to another Party. There is no central component needed for the communication to be established. The application handles secure communication to the other Parties and communicates to the back-end legacy systems of Parties using XML. Parties exchange messages by directly sending them to the recipient. The data center of a Party is connected to the Testa II network of EU. The XML-messages sent over the network are encrypted. The technique to encrypt these messages is SSL. The messages sent to the back-end are plain text XML-messages since it is assumed the connection between the application and the back-end is in a protected environment. Finally, a client application is provided which can be used within a Party to query their own register or other Parties. The clients will be identified by means of user-id/password or a client certificate. The connection to a user may be encrypted. However, this is the responsibility of each individual Party. 2. Security Features related to message exchange The security design is based on a combination of HTTPS and XML signature. This alternative uses XML-signature to sign all messages sent so the server and can authenticate the sender of the message by checking the signature. 1-sided SSL (only a server certificate) is used to protect the confidentiality and integrity of the message in transit and provides protection against deletion and insertion attacks. The XML-signature can be implemented in several ways. The chosen approach is to use XML Signature as part of the Web Services Security (WSS). WSS specifies how to use XML-signature. Since WSS builds upon the SOAP standard, it is logical to adhere to the SOAP standard as much as possible. This requires changes to the XML-messages specified with respect to addressing, error handling etc. The use of XML-signature and HTTPS with server certificate (1-sided SSL) combines the best properties of XML-signature on one side and HTTPS on the other side. No additional measures are needed to protect against deletion/replay attacks. Instead of bespoke software development to implement 2-sided SSL, XML-signature is implemented. Using XML-signature is closer to the web services roadmap than 2-sided SSL and therefore more strategic. 2007/147/II. szám 3. Security features not related to message exchange 3.1 Authentication of users The users of the Eucaris web application authenticate themselves using a username and password. Since standard Windows authentication is used, Parties can enhance the level of authentication of users if needed by using client certificates. 3.2 User roles The Eucaris software application supports different user roles. Each cluster of services has its own authorization. E.g. (exclusive) users of the “Treaty of Eucaris”- functionality” may not use the “Treaty of Prüm”- functionality”. Administrator services are separated from the regular end-user roles. 3.3 Logging and tracing of message exchange Logging of all message types is facilitated by the Eucaris software application. An administrator function allows the national administrator to determine which messages are logged: requests from endusers, incoming requests from other Parties, provided information from the national registers, etc. The application can be configured to use an internal database for this logging, or an external (Oracle) database. The decision on what messages have to be logged clearly depends on logging facilities elsewhere in the legacy systems and connected client applications. The header of each message contains information on the requesting Party, the requesting organization within that Party and the user involved. Also the reason of the request is indicated. By means of the combined logging in the requesting and responding Party complete tracing of any message exchange is possible (e.g. on request of a citizen involved). Logging is configured through the Eucaris web client (menu Administration, Logging configuration). The logging functionality is performed by the Core System. When logging is enabled, the complete message (header and body) is stored in one logging record. Per defined service, and per message type that passes along the Core System, the logging level can be set. Logging Levels The following logging levels are possible: Private – Message is logged: The logging is NOT available to the extract logging service run by the Secretary State but is available on a national level only, for audits and problem solving. None – Message is not logged at all. 2007/147/II. szám Message Types Information exchange between Parties consists of several messages, of which a schematic representation is given in the figure below. The possible message types (in the figure shown for the Eucaris Core System of Party X) are the following: 1. Request to Core System_Request message by Client 2. Request to Other Party Request message by Core System of this Party 3. Request to Core System of this Party_Request message by Core System of other Party 4. Request to Legacy Register_Request message by Core System 5. Request to Core System_Request message by Legacy Register 6. Response from Core System_Request message by Client 7. Response from Other Party_Request message by Core System of this Party 8. Response from Core System of this Party_Request message by other Party 9. Response from Legacy Register_Request message by Core System 10. Response from Core System_Request message by Legacy Register The following information exchanges are shown in the figure: • Information request from this Party (X) to another Party (Y) – blue arrows. This request and response consists of message types 1, 2, 7 and 6, respectively. • Information request from another Party (Z) to this Party (X) – red arrows. This request and response consists of message types 3, 4, 9 and 8, respectively. • Information request from the legacy register to its core system (this route also includes a request from a custom client behind the legacy register) – green arrows. This kind of request consists of message types 5 and 10. Legacy register Member State Y Eucaris Web client Member State X Legacy register Member State X Eucaris Web client Member State Z Eucaris Core System Member State Z Eucaris Core System Member State X Eucaris Core System Member State Y Figure : Message types for logging 2007/147/II. szám 3.4 Hardware Security Module A Hardware Security Module is not used. A Hardware Security Module (HSM) provides good protection for the key used to sign messages and to identify servers. This adds to the overall level of security but an HSM is expensive to buy/maintain and there are no requirements to decide for a FIPS 140-2 level 2 or level 3 HSM. Since a closed network is used that mitigates threats effectively, it is decided not to use an HSM initially. If an HSM is necessary e.g. to obtain accreditation, it can be added to the architecture. Annex C.3 Technical conditions of the data exchange 1. General description of the EUCARIS application 1.1 An overview The Eucaris application connects all participating Parties in a mesh network where each Party communicates directly to another Party. There is no central component needed for the communication to be established. The Eucaris application handles secure communication to the other Parties and communicates to the back-end legacy systems of Parties using XML. The following picture visualizes this architecture. Parties exchange messages by directly sending them to the recipient. The data center of a Party is connected to the network used for the message exchange (Testa). To access the Testa network, Parties connect to Testa via their national gate. It is assumed that a firewall is used to connect to the network back-end Member State Member State Member State Data Center Eucaris-II core router firewall Member State external organization client application client application TCP/IP network TCP/IP network signed XML-message 1-sided SSL-tunnel plain text messages the server: - terminates the SSL-tunnel - checks the signature the client: - checks the server certificate - signs the message and/or customized client signed XML-message back-end Member State Member State Member State Data Center Eucaris-II core router firewall Member State external organization client application client application TCP/IP network TCP/IP network signed XML-message 1-sided SSL-tunnel plain text messages the server: - terminates the SSL-tunnel - checks the signature the client: - checks the server certificate - signs the message and/or customized client signed XML-message 2007/147/II. szám and that a router connects the Eucaris application to the firewall. Depending on the alternative chosen to protect the messages, a certificate is used either by the router or by the Eucaris application. The XML-messages sent over the network are encrypted. The technique to encrypt these messages is SSL. The messages sent to the back-end are plain text XML-messages since it is assumed the connection between Eucaris and the back-end is in a protected environment. Finally, a client application is provided which can be used within a Party to query its own register or other Parties. The client application connects to Eucaris. The clients will be identified by means of user-id/password or a client certificate. The connection to a user in an external organization (e.g. police) may be encrypted. However, this is the responsibility of each individual Party. 1.2 Scope of the system The scope of the Eucaris system is limited to the processes involved in the exchange of information between the Registration Authorities in the Parties and a basic presentation of this information. Procedures and automated processes in which the information is to be used (e.g. administrative or enforcement processes), are outside the scope of the system. Parties can choose either to use the Eucaris client functionality or to realise their own customized client application. In the table below, it is described which aspects of the Eucaris system are mandatory to use and/or prescribed and which are optional to use and/or free to determine by the Parties. EUCARIS aspects M/O7 Remark Network concept M The concept is an “any-to-any” communication. Physical network M TESTA Core application M The core application of EUCARIS has to be used to connect to the other Parties. The following functionality is offered by the core:  Encrypting and signing of the messages;  Checking of the identity of the sender;  Authorization of Parties and local users;  Routing of messages;  Queuing of asynchronous messages if the recipient service is temporally unavailable;  Multiple country inquiry functionality;  Logging of the exchange of messages;  Storage of incoming messages Client application O In addition to the core application the EUCARIS II client application can be used by a Party. When applicable, the core and client application is modified under auspices of the EUCARIS organisation. Security concept M The concept is based on XML-signing by means of client certificates and SSL-encryption by means of service certificates. 7 M = mandatory to use or to comply with O = optional to use or to comply with 2007/147/II. szám EUCARIS aspects M/O7 Remark Message specifications M Every Party has to comply with the message specifications as set by the EUCARIS organisation and the present Implementing Agreement and its Annexes c. The specifications can only be changed by the EUCARIS organisation in consultation with the Parties. Operation and Support M The acceptation of new Parties or new functionality is under auspices of the EUCARIS organisation. Monitoring and help desk functions are managed centrally by an appointed Party. 2. Non Functional Requirements 2.1 Generic functionality In this section the main generic functions have been described in general terms. Nr. Description

Source: https://magyarkozlony.hu/hivatalos-lapok/88f4b71203e560b8dbaa15136351c7dfe188776c/dokumentumok/48b7c45847440d497b8eccef756edae7b80ff74c/letoltes