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

m) any other possible elements required. 14.2 Bármely Fél kompetens hatósága kezdeményezheti egy közös művelet elindítását. A D.1. Mellékletben bármely Fél rögzítheti a beérkező kérések feldolgozására vonatkozó eljárást. Ha nincs rögzített eljárás, a D.1. Melléklet szerint kijelölt nemzeti kapcsolattartó pont nyújt segítséget a többi Félnek, hogy kérésüket a kompetens hatósághoz juttathassák el. 15. Cross-border operations in the event of imminent danger 15.1. The authorities to be notified without delay, as stipulated in article 25 paragraph 3 of the Treaty, are set out in Annex D.2. 15.2 Any modification of the contact details of these authorities is communicated as soon as possible to the contact points of the other Parties listed also in Annex D.2. 16. The carrying and use of arms, ammunition and equipment In Annex D.3, each Party lists the particular arms, ammunition and equipment which are prohibited to be carried, according to article 28 paragraph 1, 3rd phrase of the Treaty, the particular arms, ammunition and equipment which are prohibited to be used and the legal aspects according to article 28 paragraph 2 of the Treaty, as well as the practical aspects according to article 28 paragraph 5 of the Treaty. 2007/147/II. szám Section 6: General provisions 17. Evaluation of the application and the implementation of the Treaty and the Implementing Agreement 17.1 The evaluation of the administrative and technical application and implementation of the Treaty and the Implementing Agreement is executed by the Joint Working Group as provided for in article 43 paragraph 2 of the Treaty, or by any specific technical working group mandated for this purpose by the Joint Working Group. Such an evaluation may be executed at the request of any of the Parties. 17.2 The modalities of the automated searching and comparison of DNA and dactyloscopic data will be evaluated, unless otherwise decided upon by the Joint Working Group, six months after the beginning with activities on the basis of this Implementing Agreement. For vehicle registration data, this first evaluation will take place three months after the beginning with activities. Subsequently, such evaluations may take place at the request of any Party according to article 43 of the Treaty. 17.3 The bodies responsible for recording under article 39 paragraph 2 of the Treaty shall carry out random checks in such a frequency and to the extent necessary to ensure an effective evaluation of the lawfulness of automated searches carried out according to articles 3, 9 and 12 of the Treaty by the respective foreign contact points. 18. Availability of automated data exchange The Parties provide all reasonable efforts to maintain upright the automated on-line exchange of DNA, dactyloscopic and vehicle register data on the basis of a 24 hours per day and 7 days per week availability. In case of a technical failure, the relevant contact points of the Parties inform each other as soon as possible and agree upon a temporary alternative mean of communication, according to any other applicable legal instrument. The automated exchange of data has to be restored as quickly as possible. 19. Modification of the Implementing Agreement and its Annexes 19.1 Modifications to this Implementing Agreement and its Annexes may be proposed by any Party. Such proposals are communicated to all other Parties. 19.2 If the proposed modification relates to the provisions of the Implementing Agreement, it is adopted by a Decision of the Committee of Ministers according to article 43 paragraph 1 of the Treaty. 2007/147/II. szám 19.3 If the proposed modification relates to one or more of the Annexes of the Implementing Agreement, it is adopted by the Joint Working Group provided for in article 43 paragraph 2 of the Treaty. 19.4 For the purpose of the modification of this Implementing Agreement or its Annexes, unanimity is reached when the attendant and represented Parties agree on the proposed modification. Consequently, absent and not represented Parties do not prevent the adoption of a modification of the Implementing Agreement. Such a modification applies to all Parties. 20. Taking effect; Signing; Depositary 20.1 For the Parties for which the Treaty entered into force, this Implementing Agreement takes effect after its signature, as well as the adoption of the necessary Decisions provided for in article 34 paragraph 2 of the Treaty. For the other Parties, it will take effect according to article 50 paragraph 1, respectively article 51 paragraph 1, of the Treaty and after the adoption of the necessary Decisions provided for in article 34 paragraph 2 of the Treaty. 20.2 This Implementing Agreement, with its Annexes, will be signed in the German, Spanish, French, Dutch and English languages, which are all equally authentic. 20.3 The Government of the Federal Republic of Germany acts as depositary for this Implementing Agreement and its Annexes. (Signatures) 2007/147/II. szám List of Annexes Annexes A: Automated searching for DNA-profiles Annex A.1 DNA related Forensic Issues, Matching rules and Algorithms [FIMA] Annex A.2 Party Code Number Table [PCNT] Annex A.3 Functional Process and Workflow Analysis [FPWA] Annex A.4 DNA Interface Control Document [DICD] Annex A.5 Application, Security and Communication Architecture [ASCA] Annexes B: Automated searching for dactyloscopic data Annex B.1 Interface Control Document (ICD) Annex B.2 Maximum Number of candidates accepted for verification Annex B.3 Maximum research capacities per day for dactyloscopic data of identified persons Annex B.4 Maximum research capacities per day for dactyloscopic fingerprinting traces Annexes C: Automated searching for vehicle registration data Annex C.1 Common data-set for automated search of vehicle registration data Annex C.2 Data Security Annex C.3 Technical conditions of the data exchange Annex C.4 List of contact points for incoming requests Annexes D: Police cooperation Annex D.1 Procedures and contact points for the setting up of joint operations (article 24) Annex D.2 Authorities to be notified without delay in case of a cross-border operation in the event of imminent danger and contact points for the reporting of modifications in the contact details listed in this Annex (article 25) Annex D.3 Particular arms, ammunition and equipment which are prohibited to be carried according to article 28 paragraph 1, 3rd phrase of the Treaty, particular arms, ammunition and equipment which are prohibited to be used and the legal aspects according to article 28 paragraph 2 of the Treaty, practical aspects according to article 28 paragraph 5 of the Treaty 2007/147/II. szám Annexes A Automated searching for DNA profiles Annex A.1 DNA related Forensic Issues, Matching Rules and Algorithms Introduction This document contains the requirements for DNA-profiles which are to be exchanged under the terms of the Treaty as well as the rules for matching and reporting. To enhance the exchangeability, existing (European and Interpol) standards are used. Properties of DNA-profiles The DNA profile contains 24 pairs of numbers representing the alleles of 24 loci which are also used in the DNA-procedures of Interpol. The names of these loci are shown in the following table: VWA TH01 D21S11 FGA D8S117 D3S135 D18S51 Amelogenin TPOX CSF1P0 D13S31 D7S820 D5S818 D16S53 D2S1338 D19S433 Penta D Penta E FES F13A1 F13B SE33 CD4 GABA The 7 grey loci in the top row are named the European Standard Set of Loci (ESS/ISSOL). The DNA-profiles made available by the Parties for searching and comparison as well as the DNA-profiles sent out for searching and comparison must contain at least 6 of 7 ESS/ISSOL loci and may contain the 17 other loci or blanks depending on their availability. In order to raise the accuracy of matches, it is recommended that all available alleles be stored in the indexed DNA profile data pool. Mixed profiles or incomplete loci are not allowed so the allele values of each locus will consist of only 2 numbers, which may be the same in the case of homozygosity at a given locus. Wild-cards and Micro-variants are to be dealt with upon the following rules: • Any non-numerical value contained in the profile (e.g. “o”, “f”, “r”, “na”, “nr” or “un”) will be automatically converted to a wild-card and searched against all. • Only numerical values “0”, “1” or “99” contained in the profile will be automatically converted to a wild-card and searched against all. 2007/147/II. szám • If 3 alleles are provided for one locus the first allele will be accepted and the remaining 2 alleles converted to R (wild-card) and searched against all. • When wild-card values are provided for allele 1 or 2 then both permutations of the numerical value given for the locus will be searched (e.g. 12,R could match against 12,14 or 9,12). • Pentanucleotide (Penta D, Penta E & CD4) micro-variants will be matched according to the following: x.1 = x, x.1, x.2 x.2 = x.1, x.2, x.3 x.3 = x.2, x.3, x.4 x.4 = x.3, x.4, x+1 • Tetranucleotide (the rest of the Interpol database loci are tetranucleotides) micro-variants will be matched according to the following: x.1 = x, x.1, x.2 x.2 = x.1, x.2, x.3 x.3 = x.2, x.3, x+1 Matching rules The comparison of 2 DNA-profiles will be performed on the basis of the loci for which a pair of allele values is available in both DNA-profiles. At least 6 loci of the ESS/ISSOL (exclusive of amelogenin) must be available in both DNA-profiles. A full match is defined as a match, when all allele values of the compared loci commonly contained in the requesting and requested DNA-profiles are the same. A near match is defined as a match, when the value of only one of the all compared alleles is different in the 2 DNA profiles. A near match is only accepted if there are at least 6 fully matched loci in the 2 compared DNA profiles. The reason for a near match may be: • A human typing error at the point of entry of one of the DNA-profiles in the search request or the DNA-database, • an allele-determination or allele-calling error during the generation procedure of the DNA-profile. Reporting rules Both full matches and near matches will be reported. The matching report will be sent to the requesting national contact point and will also be made available to the requested national contact point (to enable it to estimate the nature and number of possible follow-up requests for case and/or personal data associated with the DNA-profile corresponding to the hit). 2007/147/II. szám Annex A.2 Party Code Number Table Within the framework of the Treaty, it is decided to adopt ISO 3166-1 alpha-2 code for setting up the domain names and other configuration parameters required in the Prüm DNA data exchange applications over a closed network. ISO 3166-1 alpha-2 codes are two-letter Party codes. They form the best known part of the standard ISO 3166-1 and (with a few changes) are used for Internet domain names. Party Names Code Belgium BE Germany DE Spain ES France FR Luxembourg LU The Netherlands NL Austria AT 2007/147/II. szám Annex A.3 Functional Process and Workflow Analysis 1. WORKFLOW This chapter contains the description of the workflow during the automated searching and comparison procedures of all the Parties databases (so called Prüm consultation), in compliance with the points 4.3 and 4.4 of the Implementing Agreement. 1.1 Data Transmission Procedure according to article 3 of the Treaty: 1.1.1 Unidentified DNA profile ¾ In case of a HIT in the national database on a reference DNA profile – no transmission. ¾ In case of a HIT in the national database with another unidentified DNA profile – no transmission. The comparison will be made in the framework of the procedure provided for in article 4 of the Treaty. ¾ In case of a NO-HIT in the national database – transmission to all databases if allowed by the Parties national legislation: - HIT on a reference DNA profile: automated notification of the HIT and transmission of profile(s) value(s). - HIT on an unidentified DNA profile: automated notification of the HIT and transmission of profile(s) value(s). - A note may be added in all national databases where a HIT was made – start of consultation process. - NO-HIT: automated NO-HIT notification. 1.1.2 Reference DNA profile ¾ In case of a HIT in the national database on a reference DNA profile – no transmission. ¾ In case of a HIT in the national database on an unidentified DNA profile – no transmission excepted if a note is added. ¾ In case of a HIT in the national database on a noted unidentified DNA profile – HIT abroad: second step of consultation process. ¾ In case of a NO-HIT in the national database – transmission to all databases if allowed by the Parties national legislation: - HIT on a reference DNA profile: automated notification of the HIT and transmission of profile(s) values. - HIT on an unidentified DNA profile: automated notification of the HIT and transmission of profile(s) value(s). - NO-HIT: automated NO-HIT notification. 2007/147/II. szám 1.2 Data Transmission Procedure according to article 4 of the Treaty: As a first step, if allowed by the Parties national legislation, a search of all unidentified DNA profiles from crime scenes against the entire data stock of the Parties is made. Mass search for control purposes is possible later on. ¾ The initial comparison shall be made with unidentified DNA profiles. ¾ The following cases can occur: - In case of a HIT in the foreign databases on a reference DNA profile: automated notification of the HIT and transmission of profile(s) value(s) – second step of consultation process. - In case of HIT in the foreign databases on an unidentified DNA profile: automated notification of the HIT and transmission of profile(s) value(s) – second step of consultation process – it will be up to each Party to decide whether a note should be added in the databases. Following each Party’s initiative, a special mention can be left in a database when a hit on an unidentified DNA profile occurred between a national DNA database and another Parties’ DNA database. - In case of NO-HIT in the foreign databases: as the Treaty allows to regularly perform the comparisons, each Party will decide on the procedure (volume and frequency) to be undertaken for the comparison foreseen in article 4. ¾ If the national databases contain several identical profiles from different crimes, the requesting Party will transmit only one of these profiles for the matching process in order to avoid unnecessary duplication of work. ¾ Further details of this matching procedure referred to in article 4 of the Treaty shall be bilaterally agreed upon between the competent authorities. 2. FUNCTIONAL ANALYSIS: FIRST STEP 2.1 Declarations made in virtue of article 2 (3) of the Treaty: AUSTRIA: Austria allows the national contact points of the other Parties access to the DNA reference data in its DNA analysis files, with the power to conduct automated searches by comparing DNA profiles, exclusively for the purpose of prosecuting criminal offences meeting the prerequisites for the issue of a European arrest warrant according to Article 2, paragraph 1 or 2, of the Council Framework Decision of 13 June 2002 on the European Arrest Warrant and the Surrender Procedures between Member States, Official Journal No. L 190 of 18 July 2002, 1. BELGIUM: Belgium will only make the DNA database of convicted offenders available to requesting Parties. 2007/147/II. szám GERMANY: Pursuant to Article 2 (3) of the Treaty, Articles 2 to 6 thereof apply to the national DNA analysis file for the Federal Republic of Germany, which as a combined application is maintained at the Federal Criminal Police Office under Sections 2, 7 and 8 of the Federal Criminal Police Office Act and in the framework of the co-operation between the Federal Government and the Länder in criminal matters. The DNA analysis file is designed to attribute scene-of-crime marks to known criminal offenders with the aim of investigating criminal offences. For the purpose of data matching in the framework of the Treaty, solely reference data pursuant to Article 2 (2) sentence 2 of the Treaty is made available. Thus it is a subset of the data recorded in the DNA analysis file. SPAIN: In accordance with article 2 (3) of the Treaty, articles 2 to 6 of the Treaty will apply to the file INT-SAIP, dependent of the Secretary of State of Security of the Ministry of the Interior of Spain. The purpose of this file is assistance to Justice Administration in investigations, by means of the genetic identification of biological traces and the identification of samples from known sources. This file stores information of criminal offences, identification and personal data. However, in accordance with article 2 (2) of the Treaty, only reference data from which the data subject cannot be directly identified will be made available to the Parties. FRANCE: The consultation of the database is not allowed for minor offences (i.e., contravention). NETHERLANDS: The Netherlands shall ensure the availability of reference data from its National DNA-analysis file for suspects, convicted offenders, deceased victims and biological stains from unsolved crimes. LUXEMBOURG: For the purposes of automated DNA searching and comparison in compliance with the Treaty, Luxembourg grants the national contact points of the other Parties access to the DNA reference data of its two DNA databases as set up by the law of 25th August 2006 concerning DNA profiling in criminal matters: the DNA criminal database (including, inter alia, unidentified DNA profiles and the DNA profiles of suspected persons implied in an ongoing criminal investigation) and the DNA database of convicted offenders. 2.2 Volume/number of consultations In order to implement efficiently the Treaty, each Party should be prepared to face the flow of requests which will occur. Therefore, each Party made an estimation of the requests to which its own system will have to answer and an estimation of the consultations that it will make in the databases of the other Parties. Estimated volume of consultations / year AT BE FR DE LU NL ES Unidentified DNA profiles 6 000 2 000 5 000 30 000 6 000 6 000 Reference DNA profiles 12 000 5 000 100 000 45 000 12 000 / 2007/147/II. szám 2.3 Availability of the system The queries should reach the targeted database in the chronological order of arrival while the answer should reach the requesting Party within 15 minutes of the arrival of the query. 3. FUNCTIONAL ANALYSIS : SECOND STEP When a Party receives a positive answer, the DNA expert undertakes a comparison between the values of the profile which was submitted in question and the values of the profile(s) which will be transmitted as an answer. The expert validates and checks the evidential value of the profile. Legal assistance procedures start after a "full match" or a "near match" is obtained during the automated consultation phase and after validation of an existing match between two profiles. 2007/147/II. szám Annex A.4 DNA Interface Control Document (ICD) 1. Introduction 1.1 Objectives The purpose of this Annex is to define the requirements for the exchange of DNA profile information between the DNA database systems of all Parties. The header fields are defined specific for the Prüm DNA exchange, the data part is based on the DNA profile data part in the XML schema defined for the Interpol DNA exchange gateway. It is agreed to exchange data by SMTP (Simple Mail Transfer Protocol), using a central relay mail server provided by the network provider. The XML file is transported as mail body. 1.2 Scope This ICD defines the content of the message (mail) only. All network-specific and mail-specific topics are defined uniformly in order to allow a common technical base for the DNA data exchange. Within this common definitions should be at least defined: • The format of the subject field in the message to make an automated processing of the messages possible, • if content encryption is necessary and if yes which methods should be chosen, • the maximum length of messages. 1.3 XML structure and principles The XML message is structured into • header part, which contains information about the transmission and • data part, which contains profile specific information + the profile itself. The same XML schema should be useable for request and response. Fore purposes of complete checks of unidentified DNA profiles (Art. 4) it should be possible to send a batch of profiles in one message. A maximum number of profiles within one message must be defined. The number is depending from the maximum allowed mail size and should be defined after selection of the mail server. 2007/147/II. szám XML example: <?version="1.0" standalone="yes"?> <PRUEMDNAx xmlns:msxsl="urn:schemas-microsoft-com:xslt" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <header> (…) </header> <datas> (…) </datas> [<datas> datas structure repeated, if multiple profiles sent by (….) a single SMTP message, only allowed for Art. 4 cases </datas> ] </PRUEMDNAx 2. XML Structure Definition The following definitions are for documentation purposes and better readability, the real binding information is provided by an XML schema file (PRUEM DNA.xsd). 2.1 Schema PRUEMDNAx It contains the following fields: Fields Type Description header PRUEM_header Occurs: 1 datas PRUEM_datas Occurs: 1 … 500 2.2 Content of Header structure 2.2.1 PRUEM_header This is a structure describing the XML file header. It contains the following fields: Fields Type Description type PRUEM_header_type Type of the XML file direction PRUEM_header_dir Direction of message flow Ref String Reference of the XML file Generator String Generator of XML file schema_version String Version number of schema to use Requesting PRUEM_header_info Requesting Party info Requested PRUEM_header_info Requested Party info 2007/147/II. szám 2.2.2 PRUEM_header_type Type of data contained in message, value can be: Value Description M Multiple Profiles (Art. 4) S Single Profile (Art. 3) 2.2.3 PRUEM_header_dir Type of data contained in message, value can be: Value Description R Request A Answer 2.2.4 PRUEM_header_info Structure to describe Party + message date/time. It contains the following fields: Fields Type Description Source_ISOCODE string ISO 3166-2 code of the Party Destination_ISOCODE String REQUEST_ID String unique Identifier for a request date date Date of creation of message time Time Time of creation of message 2.3 Content of PRUEM Profile datas 2.3.1 PRUEM_datas This is a structure describing the XML profile data part. It contains the following fields: Fields Type Description date Date Date profile stored type PRUEM_datas_type Type of profile result PRUEM_datas_result Result of query agency String Name of corresponding unit responsible for the profile PROFILE_IDENT String Unique Party profile ID Message String Error Message, if result = E Profile IPSG_DNA_profile If direction = A (Answer) AND result ≠ H (Hit) empty MATCH_ID String In case of a HIT PROFILE_ID of the requesting profile QUALITY PRUEM_hitquality_type Quality of Hit HITCOUNT Integer Count of matched Alleles 2007/147/II. szám PRUEM_hitquality_type Value Description Referring original requesting profile: Case “No Hit”: original requesting profile sent back only; Case “Hit”: original requesting profile and matched profiles sent back, in compliance with the points 4.3.7 and 4.4 of the Implementing Agreement. Equal in all available alleles without wildcards Equal in all available alleles with wildcards Hit with Deviation (Microvariant) Hit with mismatch 2.3.2 PRUEM_data_type Type of data contained in message, value can be: Value Description P Person profile S Stain 2.3.3 PRUEM_data_result Type of data contained in message, value can be: Value Description U Undefined, If direction = R (request) H Hit N No Hit E Error 2.3.4 IPSG_DNA_profile Structure describing a DNA profile. It contains the following fields: Fields Type Description ESS_ISSOL IPSG_DNA_ISSOL Group of loci corresponding to the ISSOL (standard group of Loci of Interpol) additional_loci IPSG_DNA_additional_loci Other loci Marker String Method used to generate of DNA profile_id String Unique identifier for DNA profile 2007/147/II. szám 2.3.5 IPSG_DNA_ISSOL Structure containing the loci of ISSOL (Standard Group of Interpol loci). It contains the following fields: Fields Type Description Vwa IPSG_DNA_locus Locus vwa th01 IPSG_DNA_locus Locus th01 D21s11 IPSG_DNA_locus Locus d21s11 Fga IPSG_DNA_locus Locus fga d8s1179 IPSG_DNA_locus Locus d8s1179 d3s1358 IPSG_DNA_locus Locus d3s1358 d18s51 IPSG_DNA_locus Locus d18s51 Amelogenin IPSG_DNA_locus Locus amelogin 2.3.6 IPSG_DNA_additional_loci Structure containing the other loci. It contains the following fields: Fields Type Description Tpox IPSG_DNA_locus Locus tpox csf1po IPSG_DNA_locus Locus csf1po d13s317 IPSG_DNA_locus Locus d13s317 d7s820 IPSG_DNA_locus Locus d7s820 d5s818 IPSG_DNA_locus Locus d5s818 d16s539 IPSG_DNA_locus Locus d16s539 d2s1338 IPSG_DNA_locus Locus d2s1338 d19s433 IPSG_DNA_locus Locus d19s433 penta_d IPSG_DNA_locus Locus penta_d penta_e IPSG_DNA_locus Locus penta_e Fes IPSG_DNA_locus Locus fes f13a1 IPSG_DNA_locus Locus f13a1 f13b IPSG_DNA_locus Locus f13b se33 IPSG_DNA_locus Locus se33 cd4 IPSG_DNA_locus Locus cd4 Gaba IPSG_DNA_locus Locus gaba 2.3.7 IPSG_DNA_locus Structure describing a locus. It contains the following fields: Fields Type Description low_allele String Most low value of an allele high_allele String Most high value of an allele 2007/147/II. szám Annex A.5 Application, Security and Communication Architecture 1. Overview In implementing applications for the DNA data exchange within the frame of the Treaty, it has been decided to use a common communication network, which will be logically closed among the Parties. In order to exploit this common communication infrastructure by sending requests and receiving replies in a more effective way, an asynchronous mechanism to convey DNA and dactyloscopic data requests in a wrapped SMTP e-mail message is adopted. In fulfillment of security concerns, the mechanism sMIME as extension to SMTP functionality will be used to establish a true end-to-end secure tunnel over the network. The operative TESTA II (Trans European Services for Telematics between Administrations) has been chosen as the communication network for data exchange among the Parties. TESTA II is currently under the responsibility of the European Commission. In consideration of eventual different locations, where national DNA databases and the current national access points of TESTA II reside in the Parties sites, two options may be adopted to get the access to the TESTA II: 1) using the existing national access point or establishing a new national TESTA II access point, or 2) setting up a secure local link from the site, where DNA database resides and is administered by the corresponding national agency, to the existing national TESTA II access point. Each Party will decide which option to take by itself. This access scheme should be accepted by future acceding States to the Treaty. The protocols and standards deployed in the implementation of the Treaty applications are in compliance with the Open Standards and meet the requirements imposed by national security policy makers of the Parties. 2. Upper Level Architecture Each Party of the Treaty will make its DNA data available to be exchanged with and/or searched by other Parties in conformity with the standardized common data format. There exists no central computer server with a centralized database to hold DNA profiles. 2007/147/II. szám Fig. 1: Topology of DNA Data Exchange In addition to the fulfillment of national legal constraints at Parties’ sites, each Party may decide by itself, what kind of hardware and software regarding the appropriate circumference should be deployed at its site to suit the needs of the Treaty. 3. Security Standards and Data Protection Within the framework to implement the Treaty DNA data exchange, three levels of security concerns have concurred and will be deployed. 3.1 Data Level DNA profile data provided by each Party has to be prepared in compliance with a common data protection standard, so that requesting Parties will receive an answer mainly to indicate HIT or NO- HIT along with an identification number in case of a HIT, which does not contain any personal information at all. The further investigation after the notification of a HIT will be conducted at the bilateral level upon the existing national legal and organizational regulations of the respective Parties’ sites. Indexed DNA DB Indexed DNA DB Indexed DNA DB Indexed DNA DB Indexed DNA DB Indexed DNA DB Indexed DNA DB Closed Network (VPN upon Open Standards) 2007/147/II. szám 3.2 Communication Level Messages containing DNA profile information (requesting and replying) will be encrypted upon a state-of-the-art mechanism corresponding to open standards before they are sent to other Parties’ sites. 3.3 Transmission Level All encrypted messages containing DNA profile information will be forwarded onto other Parties’ sites through a virtual private tunneling system administered by a trust network provider at the international level and the secure links to this tunneling system under the national responsibility. This virtual private tunneling system does not have a connection point with the open Internet. By exploiting advantages of these three security levels, DNA data exchange within the frame of the Treaty proves to satisfy a high security standard. By deployment of this three level security architecture the danger of the whole system being compromised to malicious attacks will be greatly mitigated. 4. Protocols and Standards to be used for encryption mechanism: sMIME and related packages In consideration of the technical requirements and available technologies, the open standard sMIME as extension to de facto e-mail standard SMTP will be deployed to encrypt messages containing DNA profile information. The current work on s/MIME (V3) is being done in the IETF's s/MIME Working Group. The protocol sMIME (V3) allows signed receipts, security labels, and secure mailing lists and layered on Cryptographic Message Syntax (CMS), an IETF specification for cryptographic protected messages. It can be used to digitally sign, digest, authenticate or encrypt any form of digital data. The underlying certificate used by sMIME mechanism has to be in compliance with X.509 standard. s/MIME functionality is built into the vast majority of modern e-mail software packages including Outlook, Mozilla Mail as well as Netscape Communicator 4.x and inter-operates among all major e-mail software packages. Because of sMIME’s easy integration into national IT infrastructure at all Parties’ sites, it is selected as a viable mechanism to implement the communication security level. For achieving the goal “Proof of Concept” in a more efficient way and reducing costs the open standard JavaMail API is however chosen for prototyping DNA data exchange. JavaMail API provides simple encryption and decryption of e-mails using s/MIME and/or OpenPGP. The intent is to provide a single, easy-to-use API for e-mail clients that want to send and received encrypted e-mail in either of the two most 2007/147/II. szám popular e-mail encryption formats. Therefore any state-of-the-art implementations to JavaMail API will suffice for the requirements set by the Treaty. For instance, the product of Bouncy Castle JCE (Java Cryptographic Extension) will be used to implement sMIME for prototyping DNA data exchange among all Parties. 5. Application Architecture Each Party will provide the other Parties with a set of standardized DNA profile data upon the common ICD. There are two ways to make Treaty conformant DNA data available to the other Parties: construct a logical view over individual national database or establish a physical exported database. The four main components: E-mail server/sMIME, Application Server, Data Structure Area for fetching/feeding data and registering incoming/outgoing messages, and Match Engine implement the whole application logic in a product independent way. In order to provide all Parties with an easy integration of the components into their respective national sites, the same functionality will be implemented by optional open standards and protocols, which could be selected by each Party upon its national IT policy and regulations. Because of the neutral features to be implemented to get access to indexed databases containing Treaty conformant DNA profiles, each Party is given free choice to select its hardware and software platform including database and operating systems. A prototype will be developed by a team consisting of the voluntary Parties with the goal to prove the concepts worked out. Other non-prototyping Parties could optionally adopt this prototype eventually with a certain amount of customization at local sites, but they are not obliged to take this product. Nonprototyping Parties may also develop their own products to get connected to the Treaty communication environment upon the specifications provided by the present Implementing Agreement. Fig. 2: Overview Application Topology Index Profile National Env. Index DBMS National Env. Case 1 a logical view Case 2 a physical DB Email Server/ sMIME Application Server Data Structure (protocol) Match Engine TESTA II 2007/147/II. szám 6. Protocols and Standards to be used for application architecture: 6.1 XML The DNA data exchange will fully exploit XML-schema as attachment to SMTP e-mail messages. The eXtensible Markup Language (XML) is a W3C-recommended general-purpose markup language for creating special-purpose markup languages, capable of describing many different kinds of data. The description of the DNA profile suitable for exchange among all Parties has been done by means of XML and XML schema in the ICD document. 6.2 ODBC Open DataBase Connectivity provides a standard software API method for accessing database management systems and making it independent of programming languages, database and operating systems. ODBC has however certain drawbacks. Administering a large number of client machines can involve a diversity of drivers and DLLs. This complexity can increase system administration overhead. 6.3 JDBC Java DataBase Connectivity (JDBC) is an API for the Java programming language that defines how a client may access a database. In contrast to ODBC, JDBC does not require to use a certain set of local DLLs at the Desktop. The business logic to process DNA profile requests and replies at each Parties’ site is described in the following diagram. Both requesting and replying flows interact with a neutral data area comprising different data pools with a common data structure. Fig. 3: Overview Application Architecture at each Parties’ site Injection-Tool SMTP- Server Match Engine Client Integrated or CODIS-MS own GUI AT/DE/NL Injection-Tool TESTA II XML SMTP- Server Index- DB XML Requesting Flow Replying Flow POP3 POP3 Index DB (mapped CODIS) Index- DB Application Server Application Server DB/Tables Protocol Profile Result HIT/No-HIT DB/Tables Protocol Profile Result HIT/No-HIT 2007/147/II. szám 7. Communication Environment 7.1 Common Communication Network: TESTA II and its follow-up infrastructure The application DNA data exchange will exploit the e-mail, an asynchronous mechanism, to send requests and to receive replies among the Parties. Upon the fact that all Parties do have at least one national access point to the TESTA II, the operation DNA data exchange will be deployed over the TESTA II network. TESTA II provides a number of added-value services through its e-mail relay. In addition to hosting TESTA II specific e-mail boxes, the infrastructure can implement mail distribution lists and routing policies. This allows TESTA II to be used as a clearing house for messages addressed to administrations connected to the Europe wide Domains. Virus check mechanisms can also be put in place. The TESTA II e-mail relay is built on a high availability hardware platform located at the central TESTA II application facilities and protected by firewall. The TESTA II Domain Name Services (DNS) will resolve resource locators to IP addresses and hide addressing issues from the user and from applications. 7.2 Security Concern The concept of a VPN (Virtual Private Network) has been implemented within the framework of TESTA II. Tag Switching Technology used to build this VPN will evolve to support Multi-Protocol Label Switching (MPLS) standard developed by the Internet Engineering Task Force (IETF). MPLS is an IETF standard technology that speeds up network traffic flow by avoiding packet analysis by intermediate routers (hops). This is done on the basis of so-called labels that are attached to packet by the edge routers of the backbone, on the basis of information stored in the forwarding information base (FIB). Labels are also used to implement virtual private networks (VPNs). MPLS combines the benefits of layer 3 routing with the advantages of layer 2 switching. Because IP addresses are not evaluated during transition through the backbone, MPLS does not impose any IP addressing limitations. Furthermore e-mail messages over the TESTA II will be protected by sMIME driven encryption mechanism. Without knowing the key and possessing the right certificate, nobody can decrypt messages over the network. IP PKT FIB Table VPN-IP route tag info IP PKT TAG TAG apply tag and select egress port Provider edge router/switch make routing decision identify destination 2007/147/II. szám 7.3 Protocols and Standards to be used over the communication network 7.3.1 SMTP Simple Mail Transfer Protocol is the de facto standard for e-mail transmission across the Internet. SMTP is a relatively simple, text-based protocol, where one or more recipients of a message are specified and then the message text is transferred. SMTP uses TCP port 25 upon the specification by the IETF. To determine the SMTP server for a given domain name, the MX (Mail eXchange) DNS (Domain Name Systems) record is used. Since this protocol started as purely ASCII text-based it did not deal well with binary files. Standards such as MIME were developed to encode binary files for transfer through SMTP. Today, most SMTP servers support the 8BITMIME and sMIME extension, permitting binary files to be transmitted almost as easily as plain text. SMTP is a "push" protocol that does not allow one to "pull" messages from a remote server on demand. To do this a mail client must use POP3 or IMAP. Within the framework of implementing DNA data exchange it is decided to use the protocol POP3. 7.3.2 POP Local e-mail clients use the Post Office Protocol version 3 (POP3), an application-layer Internet standard protocol, to retrieve e-mail from a remote server over a TCP/IP connection. By using the SMTP Submit profile of the SMTP protocol, e-mail clients send messages across the Internet or over a corporate network. MIME serves as the standard for attachments and non-ASCII text in e-mail. Although neither POP3 nor SMTP requires MIME-formatted e-mail, essentially Internet e-mail comes MIME-formatted, so POP clients must also understand and use MIME. The whole communication environment of the Treaty will therefore include the components of POP. 7.4 Network Address Scheme The address block 62.62.0.0/17 has currently been allocated by the European IP registration authority (RIPE) to TESTA II. Further address blocks may be allocated to TESTA II in the future if required (but for that, at least 80% of the 62.62.0.0/17 should be already assigned, and actually used in the TESTA II network). The address space allocated to the TESTA II network is 62.62.0.0 – 62.62.127.255. Considering the geographical approach as introduced above, for each country a dedicated block of C class sub-nets is allocated. For the current Parties, the IP address ranges are assigned to and/or reserved for by the administration of TESTA II in the following table: IP address range Parties comments 62.62.0.0/24 – 62.62.1.0/24 Central Service (TESTA II) 62.62.30.0/24 – 62.62.33.0/24 Austria 62.62.22.0/24 – 62.62.25.0/24 Belgium 62.62.50.0/24 France 62.62.38.0/24 to 62.62.40.0/24 Germany first part 2007/147/II. szám IP address range Parties comments 62.62.76.0/24 to 62.62.79.0/24 Germany second part 62.62.54.0/24 The Netherlands 62.62.26.0/24 – 62.62.29.0/24 Luxemburg 62.62.6.0/24 – 62.62.9.0/24 Spain The IP address ranges are subject to change during the further development of TESTA II. 7.5 Configuration Parameters A secure e-mail system is set up using the eu-admin.net domain. This domain with the associated addresses will not be accessible from a location not on the TESTA II Europe wide domain, because the names are only known on the TESTA II central DNS server, which is shielded from the Internet. The resolution of these TESTA II site addresses (host names) to their IP addresses is done by the TESTA II DNS service. For each Local Domain, a Mail entry will be added to this TESTA II central DNS server, making all e-mail messages sent to TESTA Local Domains being relayed to the TESTA II central Mail Relay. This TESTA II central Mail Relay will then forward them to the specific Local Domain e-mail server using the Local Domain e-mail addresses. By relaying the e-mail in this way, critical information contained in e-mails will only pass the Europe wide closed network infrastructure and not the insecure Internet. It is necessary to establish sub domains (bold italics) in all Parties’ sites upon the following syntax: “application-type.pruem.party-code.eu-admin.net”, where: “party-code” takes one of the values: AT, BE, DE, ES, FR, LU and NL; the party code is a country code; “application-type” takes one of the values: DNA and FP. By applying the above syntax, the sub domains for the current seven Parties are shown in the following table: MS/Parties Sub Domains Comments dna.pruem.at.eu-admin.net Using the existing TESTA II national access point Austria fp.pruem.at.eu-admin.net dna.pruem.be.eu-admin.net Setting up a secure local link to the existing TESTA II access point Belgium fp.pruem.be.eu-admin.net dna.pruem.de.eu-admin.net Using the existing TESTA II national access points Germany fp.pruem.de.eu-admin.net dna.pruem.es.eu-admin.net Using the existing TESTA II national access point Spain fp.pruem.es.eu-admin.net dna.pruem.fr.eu-admin.net Using the existing TESTA II national access point France fp.pruem.fr.eu-admin.net dna.pruem.lu.eu-admin.net Using the existing TESTA II national access point Luxemburg fp.pruem.lu.eu-admin.net 2007/147/II. szám MS/Parties Sub Domains Comments dna.pruem.nl.eu-admin.net Intending to establish a new TESTA II access point at the NFI The Netherlands fp.pruem.nl.eu-admin.net 8. Conclusion Upon the result of negotiations with the European Commission (EU COM), a step-by-step approach to deploy the DNA application over TESTA II will be adopted. A certain amount of customization work has to be done mainly by the EU COM in joint work with the TESTA II provider. However, each Party is in charge of the necessary modifications for the IT environment at its respective sites if requested. The first deployment step over TESTA II is planned among the prototyping Parties and the other Parties may have the deployment at a ready-to-go basis after the fulfilment of the necessary requirements from IT and organizational point of view. A requirement sheet to be filled out by nonprototyping Parties will be sent out timely before the deployment commences. 2007/147/II. szám Annexes B Automated searching for dactyloscopic data Annex B.1 Interface Control Document (Dactyloscopic data) Introduction The purpose of this document is to define the requirements for the exchange of dactyloscopic information between the Automated Fingerprint Identification Systems (AFIS) of the Parties. It is based on the Interpol-Implementation of ANSI/NIST-ITL 1-2000 (INT-I, Version 4.22b). This version shall cover all basic definitions for Logical Records Type-1, Type-2, Type-4, Type-9, Type-13 and Type-15 required for image and minutiæ based dactyloscopic processing. 1. File Content Overview A dactyloscopic file consists of several logical records. There are sixteen types of record specified in the original ANSI/NIST-ITL 1-2000 standard. Appropriate ASCII separation characters are used between each record and the fields and subfields within the records. In this version for the application of the Treaty, only 6 record types are used to exchange information between the originating and the destination agency: Type-1 -> Transaction information Type-2 -> Alphanumeric persons/case data Type-4 -> High resolution grayscale dactyloscopic images Type-9 -> Minutiæ Record Type-13 -> Variable resolution latent image Type-15 -> Variable resolution palmprint image record 1.1 Type-1 – File header This record contains routing information and information describing the structure of the rest of the file. This record type also defines the types of transaction which fall under the following broad categories: 2007/147/II. szám 1.2 Type-2 – Descriptive text This record contains textual information of interest to the sending and receiving agencies. 1.3 Type-4 – High resolution gray-scale image This record is used to exchange high resolution gray-scale (eight bit) dactyloscopic images sampled at 500 pixels/inch. The dactyloscopic images shall be compressed using the WSQ algorithm with a ratio not more than 15:1. Other compression algorithms or uncompressed images must not be used. 1.4 Type-9 – Minutiæ record Type-9 records are used to exchange ridge characteristics or minutiæ data. Their purpose is partly to avoid unnecessary duplication of AFIS encoding processes and partly to allow the transmission of AFIS codes which contain less data than the corresponding images. 1.5 Type-13 – Variable-Resolution Latent Image Record This record shall be used to exchange variable-resolution latent fingerprint and latent palmprint images together with textural alphanumerical information. The scanning resolution of the images shall be 500 pixels/inch with 256 gray-levels. If the quality of the latent image is sufficient it shall be compressed using WSQ-algorithm. If necessary the resolution of the images may be expanded to more than 500 pixels/inch and more than 256 gray-levels on bilateral agreement. 1.6 Variable-Resolution Palmprint Image Record Type-15 tagged field image records shall be used to exchange variable-resolution palmprint images together with textural alphanumerical information. The scanning resolution of the images shall be 500 pixels/inch with 256 gray-levels. To minimize the amount of data all palmprint images shall be compressed using WSQ-algorithm. If necessary the resolution of the images may be expanded to more than 500 pixels/inch and more than 256 gray-levels on bilateral agreement. 2. Record format A transaction file shall consist of one or more logical records. For each logical record contained in the file, several information fields appropriate to that record type shall be present. Each information field may contain one or more basic single-valued information items. Taken together these items are used to convey different aspects of the data contained in that field. An information field may also consist of one or more information items grouped together and repeated multiple times within a field. Such a group of information items is known as a subfield. An information field may therefore consist of one or more subfields of information items. 2007/147/II. szám 2.1 Information separators In the tagged-field logical records, mechanisms for delimiting information are implemented by use of four ASCII information separators. The delimited information may be items within a field or subfield, fields within a logical record, or multiple occurrences of subfields. These information separators are defined in the standard ANSI X3.4. These characters are used to separate and qualify information in a logical sense. Viewed in a hierarchical relationship, the File Separator “FS” character is the most inclusive followed by the Group Separator “GS”, the Record Separator “RS”, and finally the Unit Separator “US” characters. Table 1 lists these ASCII separators and a description of their use within this standard. Information separators should be functionally viewed as an indication of the type data that follows. The “US” character shall separate individual information items within a field or subfield. This is a signal that the next information item is a piece of data for that field or subfield. Multiple subfields within a field separated by the “RS” character signals the start of the next group of repeated information item(s). The “GS” separator character used between information fields signals the beginning of a new field preceding the field identifying number that shall appear. Similarly, the beginning of a new logical record shall be signalled by the appearance of the “FS” character. The four characters are only meaningful when used as separators of data items in the fields of the ASCII text records. There is no specific meaning attached to these characters occurring in binary image records and binary fields – they are just part of the exchanged data. Normally, there should be no empty fields or information items and therefore only one separator character should appear between any two data items. The exception to this rule occurs for those instances where the data in fields or information items in a transaction are unavailable, missing, or optional, and the processing of the transaction is not dependent upon the presence of that particular data. In those instances, multiple and adjacent separator characters shall appear together rather than requiring the insertion of dummy data between separator characters. Consider the definition of a field that consists of three information items. If the information for the second information item is missing, then two adjacent “US” information separator characters would occur between the first and third information items. If the second and third information items were both missing, then three separator characters should be used – two “US” characters in addition to the terminating field or subfield separator character. In general, if one or more mandatory or optional information items are unavailable for a field or subfield, then the appropriate number of separator character should be inserted. It is possible to have side-by-side combinations of two or more of the four available separator characters. When data are missing or unavailable for information items, subfields, or fields, there must be one fewer separator characters present than the number of data items, subfields, or fields required. 2007/147/II. szám Table 1: Separators Used Code Type Description Hexadecim al Value Decimal Value US Unit Separator Separates information items 1F RS Record Separator Separates subfields 1E GS Group Separator Separates fields 1D FS File Separator Separates logical records 1C 2.2 Record layout For tagged-field logical records, each information field that is used shall be numbered in accordance with this standard. The format for each field shall consist of the logical record type number followed by a period “.”, a field number followed by a colon “:”, followed by the information appropriate to that field. The tagged-field number can be any one-to nine-digit number occurring between the period “.” and the colon “:”. It shall be interpreted as an unsigned integer field number. This implies that a field number of “2.123:” is equivalent to and shall be interpreted in the same manner as a field number of “2.000000123:”. For purposes of illustration throughout this document, a three-digit number shall be used for enumerating the fields contained in each of the tagged-field logical records described herein. Field numbers will have the form of “TT.xxx:” where the “TT” represents the one- or two-character record type followed by a period. The next three characters comprise the appropriate field number followed by a colon. Descriptive ASCII information or the image data follows the colon. Logical Type-1 and Type-2 records contain only ASCII textual data fields. The entire length of the record (including field numbers, colons, and separator characters) shall be recorded as the first ASCII field within each of these record types. The ASCII File Separator “FS” control character (signifying the end of the logical record or transaction) shall follow the last byte of ASCII information and shall be included in the length of the record. In contrast to the tagged-field concept, the Type-4 record contains only binary data recorded as ordered fixed-length binary fields. The entire length of the record shall be recorded in the first four-byte binary field of each record. For this binary record, neither the record number with its period, nor the field identifier number and its following colon, shall be recorded. Furthermore, as all the field lengths of this record is either fixed or specified, none of the four separator characters (“US”, “RS”, ”GS”, or “FS”) shall be interpreted as anything other than binary data. For the binary record, the “FS” character shall not be used as a record separator or transaction terminating character. 2007/147/II. szám 3. Type-1 Logical Record: the File Header This record describes the structure of the file, the type of the file, and other important information. The character set used for Type-1 fields shall contain only the 7-bit ANSI code for information interchange. 3.1 Fields for Type-1 Logical Record 3.1.1 Field 1.001: Logical Record Length (LEN) This field contains the total count of the number of bytes in the whole Type-1 logical record. The field begins with “1.001:”, followed by the total length of the record including every character of every field and the information separators. 3.1.2 Field 1.002: Version Number (VER) To ensure that users know which version of the ANSI/NIST standard is being used, this four byte field specifies the version number of the standard being implemented by the software or system creating the file. The first two bytes specify the major version reference number, the second two the minor revision number. For example, the original 1986 Standard would be considered the first version and designated “0100” while the present ANSI/NIST-ITL 1-2000 standard is “0300”. 3.1.3 Field 1.003: File Content (CNT) This field lists each of the records in the file by record type and the order in which the records appear in the logical file. It consists of one or more subfields, each of which in turn contains two information items describing a single logical record found in the current file. The subfields are entered in the same order in which the records are recorded and transmitted. The first information item in the first subfield is "1", to refer to this Type-1 record. It is followed by a second information item which contains the number of other records contained in the file. This number is also equal to the count of the remaining subfields of field 1.003. Each of the remaining subfields is associated with one record within the file, and the sequence of subfields corresponds to the sequence of records. Each subfield contains two items of information. The first is to identify the Type of the record. The second is the record's IDC. The "US" character shall be used to separate the two information items. 3.1.4 Field 1.004: Type of Transaction (TOT) This field contains a three letter mnemonic designating the type of the transaction. These codes may be different from those used by other implementations of the ANSI/NIST standard. CPS: Criminal Print-to-Print Search. This transaction is a request for a search of a record relating to a criminal offence against a prints database. The person’s prints must be included as WSQ-compressed images in the file. 2007/147/II. szám In case of a No-HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record In case of a HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record ⇒ 1-14 Type-4 Record The CPS TOT is summarized in Table A.6.1 (Appendix 6). PMS: Print-to-Latent Search. This transaction is used when a set of prints shall to be searched against an Unidentified Latent database. The response will contain the Hit/No-Hit decision of the destination AFIS search. If multiple unidentified latents exist, multiple SRE transactions will be returned, with one latent per transaction. The person’s prints must be included as WSQ-compressed images in the file. In case of a No-HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record In case of a HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record ⇒ 1 Type-13 Record The PMS TOT is summarized in Table A.6.1 (Appendix 6). MPS: Latent-to-Print Search. This transaction is used when a latent is to be searched against a Prints database. The latent minutiæ information and the image (WSQ-compressed) must be included in the file. In case of a No-HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record In case of a HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record ⇒ 1 Type-4 or Type-15 Record The MPS TOT is summarized in Table A.6.4 (Appendix 6). MMS: Latent-to-Latent Search. In this transaction the file contains a latent which is to be searched against an Unidentified Latent database in order to establish links between various scenes of crime. The latent minutiæ information and the image (WSQ-compressed) must be included in the file. 2007/147/II. szám In case of a No-HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record In case of a HIT, the following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record ⇒ 1 Type-13 Record The MMS TOT is summarized in Table A.6.4 (Appendix 6). SRE: This transaction is returned by the destination agency in response to dactyloscopic submissions. The response will contain the Hit/No-Hit decision of the destination AFIS search. If multiple candidates exist, multiple SRE transactions will be returned, with one candidate per transaction. The SRE TOT is summarized in Table A.6.2 (Appendix 6). ERR: This transaction is returned by the destination AFIS to indicate a transaction error. It includes a message field (ERM) indicating the error detected. The following logical records will be returned: ⇒ 1 Type-1 Record ⇒ 1 Type-2 Record The ERR TOT is summarized in Table A.6.3 (Appendix 6). Table 2: Permissible Codes in Transactions Logical Record Type Transaction Type CPS M M M - - - SRE M M C - (C in case of latent hits) C C MPS M M - M (1*) M - MMS M M - M (1*) M - PMS M M M* - - M* ERR M M - - - - Key: M = Mandatory M* = Only one of both record-types may be included O = Optional C = Conditional if data is available - = Not allowed 1* = Conditional for legacy systems 2007/147/II. szám 3.1.5 Field 1.005: Date of Transaction (DAT) This field indicates the date on which the transaction was initiated and must conform to the ISO standard notation of: YYYYMMDD where YYYY is the year, MM is the month and DD is the day of the month. Leading zeros are used for single figure numbers. For example, "19931004" represents the 4 October 1993. 3.1.6 Field 1.006: Priority (PRY) This optional field defines the priority, on a level of 1 to 9, of the request. "1" is the highest priority and "9" the lowest. Accordingly to the Implementing Agreement, priority "1" transactions shall be processed immediately. 3.1.7 Field 1.007: Destination Agency Identifier (DAI) This field specifies the destination agency for the transaction. It consists of two information items in the following format: CC/agency. The first information item contains the Country Code, defined in ISO 3166, two alpha-numeric characters long. The second item, agency, is a free text identification of the agency, up to a maximum of 32 alpha-numeric characters. 3.1.8 Field 1.008: Originating Agency Identifier (ORI) This field specifies the file originator and has the same format as the DAI (Field 1.007). 3.1.9 Field 1.009: Transaction Control Number (TCN) This is a control number for reference purposes. It should be generated by the computer and have the following format: YYSSSSSSSSA where YY is the year of the transaction, SSSSSSSS is an eight-digit serial number, and A is a check character generated by following the procedure given in Appendix 2. Where a TCN is not available, the field, YYSSSSSSSS, is filled with zeros and the check character generated as above. 3.1.10 Field 1.010: Transaction Control Response (TCR) Where a request was sent out, to which this is the response, this optional field will contain the transaction control number of the request message. It therefore has the same format as TCN (Field 1.009). 3.1.11 Field 1.011: Native Scanning Resolution (NSR) This field specifies the normal scanning resolution of the system supported by the originator of the transaction. The resolution is specified as two numeric digits followed by the decimal point and then two more digits. For all transactions linked to the Treaty the sampling rate shall be 500 pixels/inch or 19.68 pixels/mm. 2007/147/II. szám 3.1.12 Field 1.012: Nominal Transmitting Resolution (NTR) This five-byte field specifies the nominal transmitting resolution for the images being transmitted. The resolution is expressed in pixels/mm in the same format as NSR (Field 1.011). 3.1.13 Field 1.013: Domain name (DOM) This mandatory field identifies the domain name for the user-defined Type-2 logical record implementation. It consists of two information items and shall be “INT-I{US}4.22{GS}”. 3.1.14 Field 1.014: Greenwich meantime (GMT) This mandatory field provides a mechanism for expressing the date and time in terms of universal Greenwich Mean Time (GMT) units. If used, the GMT field contains the universal date that will be in addition to the local date contained in Field 1.005 (DAT). Use of the GMT field eliminates local time inconsistencies encountered when a transaction and its response are transmitted between two places separated by several time zones. The GMT provides a universal date and 24-hour clock time independent of time zones. It is represented as "CCYYMMDDHHMMSSZ”, a 15-character string that is the concatenation of the date with the GMT and concludes with a “Z”. The “CCYY” characters shall represent the year of the transaction, the “MM” characters shall be the tens and units values of the month, and the “DD” characters shall be the tens and units values of the day of the month, the “HH” characters rep-resent the hour, the “MM” the minute, and the “SS” represents the second. The complete date shall not exceed the current date. 4. Type-2 Logical Record: Descriptive Text The structure of most of this record is not defined by the original ANSI/NIST standard. The record contains information of specific interest to the agencies sending or receiving the file. To ensure that communicating dactyloscopic systems are compatible this ICD requires that only the fields listed below are contained within the record. This document specifies which fields are mandatory and which optional, and also defines the structure of the individual fields. 4.1 Fields for Type-2 Logical Record 4.1.1 Field 2.001: Logical Record Length (LEN) This mandatory field contains the length of this Type-2 record, and specifies the total number of bytes including every character of every field contained in the record and the information separators. 4.1.2 Field 2.002: Image Designation Character (IDC) The IDC contained in this mandatory field is an ASCII representation of the IDC as defined in the file content field of the Type-1 record. 2007/147/II. szám 4.1.3 Field 2.003: System Information (SYS) This field is mandatory and contains four bytes which indicate which version of the INT-I this particular Type-2 record complies with. The first two bytes specify the major version number, the second two the minor revision number. For example, this implementation is based on INT-I version 4 revision 22 and would be represented as “0422”. 4.1.4 Field 2.007: Case Number (CNO) This is a number assigned by the local dactyloscopic bureau to a collection of latents found at a sceneof-crime. The following format is adopted: CC/number where CC is the Interpol Country Code, two alpha-numeric characters in length, and the number complies with the appropriate local guidelines and may be up to 32 alpha-numeric characters long. This field allows the system to identify latents associated with a particular crime. 4.1.5 Field 2.008: Sequence Number (SQN) This specifies each sequence of latents within a case. It can be up to four numeric characters long. A sequence is a latent or series of latents which are grouped together for the purposes of filing and/or searching. This definition implies that even single latents will still have to be assigned a sequence number. This field together with MID (Field 2.009) may be included to identify a particular latent within a sequence. 4.1.6 Field 2.009: Latent Identifier (MID) This specifies the individual latent within a sequence. The value is a single letter, with 'A' assigned to the first latent, 'B' to the second, and so on up to a limit of 'J'. This field is used analog to the latent sequence number discussed in the description for SQN (Field 2.008). 4.1.7 Field 2.010: Criminal Reference Number (CRN) This is a unique reference number assigned by a national agency to an individual who is charged for the first time with committing an offence. Within one country no individual ever has more than one CRN, or shares it with any other individual. However, the same individual may have Criminal Reference Numbers in several countries, which will be distinguishable by means of the country code. The following format is adopted for CRN field: CC/number where CC is the Country Code, defined in ISO 3166, two alpha-numeric characters in length, and the number complies with the appropriate national guidelines of the issuing agency, and may be up to 32 alpha-numeric characters long. 2007/147/II. szám For transactions linked to the Treaty this field will be used for the national criminal reference number of the originating agency which is linked to the images in Type-4 or Type-15 Records. 4.1.8 Field 2.012: Miscellaneous Identification Number (MN1) This fields contains the CRN (field 2.010) transmitted by an CPS or PMS transaction without the leading country code. 4.1.9 Field 2.013: Miscellaneous Identification Number (MN2) This fields contains the CNO (field 2.007) transmitted by an MPS or MMS transaction without the leading country code. 4.1.10 Field 2.014: Miscellaneous Identification Number (MN3) This fields contains the SQN (field 2.008) transmitted by an MPS or MMS transaction. 4.1.11 Field 2.015: Miscellaneous Identification Number (MN4) This fields contains the MID (field 2.009) transmitted by an MPS or MMS. 4.1.12 Field 2.063: Additional Information (INF) This optional field, consisting of up to 32 alpha-numeric characters, may give additional information about the request. 4.1.13 Field 2.064: Respondents List (RLS) This field contains at least two subfields. The first subfield describes the type of search that has been carried out, using the three-letter mnemonics which specify the transaction type in TOT (Field 1.004). The second subfield contains a single character. An “I” shall be used to indicate that a HIT has been found and an “N” shall be used to indicate that no matching cases have been found (NOHIT). The third subfield contains the sequence identifier for the candidate result and the total number of candidates separated by a slash. Multiple messages will be returned if multiple candidates exist. In case of a possible HIT the fourth subfield shall contain the score up to six digits long. If the HIT has been verified the value of this subfield is defined as "999999". Example: "CPS{RS}I{RS}001/001{RS}999999{GS}" If the remote AFIS does not assign scores, then a score of zero should be used at the appropriate point. 4.1.14 Field 2.074: Status/Error Message Field (ERM) This field contains error messages resulting from transactions, which will be sent back to the requester as part of an Error Transaction. 2007/147/II. szám Numeric Code (1-3) Meaning (5-128) ERROR: UNAUTHORISED ACCESS MANDATORY FIELD MISSING INVALID RECORD TYPE UNDEFINED FIELD EXCEED THE MAXIMUM OCCURRENCE INVALID NUMBER OF SUBFIELDS FIELD LENGTH TOO SHORT FIELD LENGTH TOO LONG FIELD IS NOT A NUMBER AS EXPECTED FIELD NUMBER VALUE TOO SMALL FIELD NUMBER VALUE TOO BIG INVALID CHARACTER INVALID DATE INVALID ITEM VALUE INVALID TYPE OF TRANSACTION INVALID RECORD DATA ERROR: INVALID TCN ERROR: INSUFFICIENT FINGERPRINT QUALITY ERROR: MISSING FINGERPRINTS ERROR: FINGERPRINT SEQUENCE CHECK FAILED ERROR: ANY OTHER ERROR. FOR FURTHER DETAILS CALL DESTINATION AGENCY. Error messages in the range between 100 and 199: These error messages are related to the validation of the ANSI/NIST records and defined as: <error_code 1>: IDC <idc_number 1> FIELD <field_id 1> <dynamic text 1> LF <error_code 2>: IDC <idc_number 2> FIELD <field_id 2> <dynamic text 2>… where - error_code is a code uniquely related to a specific reason (see table) - field_id is the ANSI/NIST field number of the incorrect field (e.g. 1.001, 2.001, ...) in the format <record_type>.<field_id>.<sub_field_id> - dynamic text is a more detailed dynamic description of the error - LF is a Line Feed separating errors if more then one error is encountered - for type-1 record the ICD is defined as "-1" 2007/147/II. szám Example: 201: IDC -1 FIELD 1.009 WRONG CONTROL CHARACTER {LF} 115: IDC 0 FIELD 2.003 INVALID SYSTEM INFORMATION This field is mandatory for error transactions. 4.1.15 Field 2.320: Expected Number of Candidates (ENC) This field contains the maximum number of candidates for verification expected by the requesting agency. The value of ENC must not exceed the values defined in Annex B.2 of this Implementing Agreement. 5. Type-4 Logical Record: High Resolution Gray-Scale Image It should be noted that Type-4 records are binary rather than ASCII in nature. Therefore each field is assigned a specific position within the record, which implies that all fields are mandatory. The standard allows both image size and resolution to be specified within the record. It requires Type-4 Logical Records to contain dactyloscopic image data that are being transmitted at a nominal pixel density of 500 to 520 pixels per inch. The preferred rate for new designs is at a pixel density of 500 pixels per inch or 19.68 pixels per mm. 500 pixels per inch is the density specified by the INT-I, except that similar systems may communicate with each other at a non-preferred rate, within the limits of 500 to 520 pixels per inch. 5.1 Fields for Type-4 Logical Record 5.1.1 Field 4.001: Logical Record Length (LEN) This four-byte field contains the length of this Type-4 record, and specifies the total number of bytes including every byte of every field contained in the record. 5.1.2 Field 4.002: Image Designation Character (IDC) This is the one-byte binary representation of the IDC number given in the header file. 5.1.3 Field 4.003: Impression Type (IMP) The impression type is a single-byte field occupying the sixth byte of the record. Table 3 : Finger Impression Type Code Description Live-scan of plain fingerprint Live-scan of rolled fingerprint Non-live scan impression of plain fingerprint captured from paper Non-live scan impression of rolled fingerprint captured from paper 2007/147/II. szám Code Description Latent impression captured directly Latent tracing Latent photo Latent lift Swipe Unknown 5.1.4 Field 4.004: Finger Position (FGP) This fixed-length field of 6 bytes occupies the seventh through twelfth byte positions of a Type-4 record. It contains possible finger positions beginning in the left most byte (byte 7 of the record). The known or most probable finger position is taken from the following table. Up to five additional fingers may be referenced by entering the alternate finger positions in the remaining five bytes using the same format. If fewer than five finger position references are to be used the unused bytes are filled with binary 255. To reference all finger positions code 0, for unknown, is used. Table 4: Finger position code and maximum size Finger position Finger code Width (mm) Length (mm) Unknown 40.0 40.0 Right thumb 45.0 40.0 Right index finger 40.0 40.0 Right middle finger 40.0 40.0 Right ring finger 40.0 40.0 Right little finger 33.0 40.0 Left thumb 45.0 40.0 Left index finger 40.0 40.0 Left middle finger 40.0 40.0 Left ring finger 40.0 40.0 Left little finger 33.0 40.0 Plain right thumb 30.0 55.0 Plain left thumb 30.0 55.0 Plain right four fingers 70.0 65.0 Plain left four fingers 70.0 65.0 For scene of crime latents only the codes 0 to 10 should be used. 5.1.5 Field 4.005: Image Scanning Resolution (ISR) This one-byte field occupies the 13th byte of a Type-4 record. If it contains “0” then the image has been sampled at the preferred scanning rate of 19.68 pixels/mm (500 pixels per inch). If it contains “1” then the image has been sampled at an alternative scanning rate as specified in the Type-1 record. 2007/147/II. szám 5.1.6 Field 4.006: Horizontal Line Length (HLL) This field is positioned at bytes 14 and 15 within the Type-4 record. It specifies the number of pixels contained in each scan line. The first byte will be the most significant. 5.1.7 Field 4.007: Vertical Line Length (VLL) This field records in bytes 16 and 17 the number of scan lines present in the image. The first byte is the most significant. 5.1.8 Field 4.008: Gray-scale Compression Algorithm (GCA) This one-byte field specifies the gray-scale compression algorithm used to encode the image data. A binary zero indicates that no compression algorithm has been used. In this case pixels are recorded in left to right, top to bottom fashion. The FBI will maintain a registry relating non-zero numbers to compression algorithms. This Implementation based on the INT-I will use the same allocation of numbers. 5.1.9 Field 4.009: The Image This field contains a byte stream representing the image. Its structure will obviously depend on the compression algorithm used. 6. Type-9 Logical Record: Minutiæ Record Type-9 records shall contain ASCII text describing minutiæ and related information encoded from a latent. For latent search transaction, there no limit for these Type-9 records in a file, each of which shall be for a different view or latent. 6.1 Minutiæ extraction 6.1.1 Minutia type identification This standard defines three identifier numbers that are used to describe the minutia type. These are listed in Table 4.1. A ridge ending shall be designated Type 1. A bifurcation shall be designated Type

Source: https://magyarkozlony.hu/hivatalos-lapok/71af3e8e7bfe6152ccbeed7866689568011b12ee/dokumentumok/7cdcb15e2f95425a0ab307ff955c4e3b437fa08c/letoltes