Beschluss (EU) 2018/1926 des Rates vom 19. November 2018 zur Festlegung des Standpunkts, der im Namen der Europäischen Union in der Sachverständigengruppe der Wirtschaftskommission für Europa der Vereinten Nationen zum Europäischen Übereinkommen über die Arbeit des im internationalen Straßenverkehr beschäftigten Fahrpersonals zu vertreten ist

Durchsuchbarer Text in vereinfachter Darstellung. Tabellen, Abbildungen und verbindliche Gestaltung bitte anhand der Originaldateien prüfen.

at den Antrag auf Ausstellung einer Fahrtenschreiberkarte genehmigt. „Rejected“ (abgelehnt) Die CIA hat den Antrag nicht genehmigt. „Personalised“ (personalisiert) Die Fahrtenschreiberkarte wurde personalisiert. „Dispatched“ (versandt) Die nationale Behörde hat die Fahrerkarte an den betreffenden Fahrer oder an die Ausgabestelle versandt. „Handed Over“ (ausgehändigt) Die nationale Behörde hat die Fahrerkarte an den betreffenden Fahrer ausgehändigt. „Confiscated“ (eingezogen) Die Fahrerkarte wurde von der zuständigen Behörde eingezogen. „Suspended“ (ausgesetzt) Die Fahrerkarte wurde vorübergehend eingezogen. „Withdrawn“ (entzogen) Die CIA hat entschieden, dem Fahrer die Fahrerkarte zu entziehen. Die Karte wurde endgültig für ungültig erklärt. „Surrendered“ (zurückgegeben) Die Fahrtenschreiberkarte wurde mit der Erklärung an die CIA zurückgegeben, dass sie nicht mehr benötigt wird. „Lost“ (verloren) Die Fahrtenschreiberkarte wurde von der CIA als verloren gemeldet. „Stolen“ (gestohlen) Die Fahrtenschreiberkarte wurde von der CIA als gestohlen gemeldet. Eine gestohlene Karte gilt als verloren. „Malfunctioning“ (schlecht funktionierend) Die Fahrtenschreiberkarte wurde von der CIA als schlecht funktionierend gemeldet. „Expired“ (abgelaufen) Die Gültigkeitsdauer der Fahrtenschreiberkarte ist abgelaufen. „Replaced“ (ersetzt) Die Fahrtenschreiberkarte, die als verloren, gestohlen oder schlecht funktionierend gemeldet ist, wurde durch eine neue Karte ersetzt. Die Daten der neuen Karte sind mit denen der alten Karte bis auf die Kartennummer identisch, deren Ersatzindex um eine Stelle erhöht ist. „Renewed“ (erneuert) Die Fahrtenschreiberkarte wurde erneuert, da sich Verwaltungsdaten geändert haben oder die Gültigkeitsdauer abgelaufen war. Die Daten der neuen Karte sind mit denen der alten Karte bis auf die Kartennummer identisch, deren Erneuerungsindex um eine Stelle erhöht ist. „In Exchange“ (im Austausch) Die CIA, die eine Fahrerkarte ausgestellt hat, hat eine Mitteilung erhalten, dass ein Verfahren eingeleitet wurde, diese Karte gegen eine von der CIA einer anderen Partei ausgestellte Karte auszutauschen. „Exchanged“ (ausgetauscht) Die CIA, die eine Fahrerkarte ausgestellt hat, hat eine Mitteilung über den Abschluss des Verfahrens erhalten, mit dem diese Karte gegen eine von der CIA einer anderen Partei ausgestellte Karte ausgetauscht wurde. Unteranlage 4.3 TACHOnet-Benachrichtigungen 1. Allgemeine technische Anforderungen 1.1. Die Zentralstelle verfügt sowohl über synchrone als auch asynchrone Schnittstellen für den Austausch von Benachrichtigungen. Die Parteien können die für ihre eigenen Anwendungen am besten geeignete Technologie einsetzen. 1.2. Alle zwischen der Zentralstelle und den nationalen Systemen ausgetauschten Benachrichtigungen müssen UTF-8 verschlüsselt sein. 1.3. Die nationalen Systeme müssen in der Lage sein, Benachrichtigungen mit griechischen oder kyrillischen Zeichen entgegenzunehmen und zu verarbeiten. 2. XML-Schema der Benachrichtigungen und Schemadefinition (XSD) 2.1. Das allgemeine XML-Schema der Benachrichtigungen folgt dem Format der XSD-Schemadefinition der Zentralstelle. 2.2. Die Zentralstelle und die nationalen Systeme senden und empfangen Benachrichtigungen, die dem XSD-Schema entsprechen. 2.3. Die nationalen Systeme müssen in der Lage sein, alle Benachrichtigungen im Zusammenhang mit einer der in Unteranlage 4.2 genannten Funktionen zu senden, zu empfangen und zu verarbeiten. 2.4. Die XML-Benachrichtigungen müssen den in Tabelle 2 festgelegten Mindestanforderungen genügen. Tabelle 2 Mindestanforderungen an den Inhalt von XML-Benachrichtigungen „Common Header“ (Gemeinsamer Header) Pflichtfelder „Version“ (Version) Die offizielle Version der XML-Spezifikationen wird durch den Namensraum spezifiziert, der in der XSD-Benachrichtigung und in dem Attribut Version des Header-Elements jeder XML-Benachrichtigung definiert ist. Die Versionsnummer („n.m“) wird in jeder Freigabe der Datei mit der XML-Schemadefinition (xsd) als fester Wert definiert. Ja „Test Identifier“ (Testkennung) Fakultative Kennung für Tests. Der Veranlasser des Tests vervollständigt die Kennung, und alle am Workflow Beteiligten müssen dieselbe Kennung weitergeben bzw. zurücksenden. Bei der Erzeugung sollte sie ignoriert und, soweit angegeben, nicht verwendet werden. Nein „Technical Identifier“ (Technische Kennung) Eine UUID dient der eindeutigen Identifizierung jeder einzelnen Benachrichtigung. Der Sender generiert eine UUID und vervollständigt dieses Attribut. Diese Daten werden in keiner Betriebssituation verwendet. Ja „Workflow Identifier“ (Workflowkennung) Die Workflowkennung ist eine UUID und sollte von dem anfragenden Mitgliedstaat generiert werden. Diese Kennung wird dann in allen Benachrichtigungen benutzt, die mit diesem Workflow zusammenhängen. Ja „Sent At“ (Versendet am) Datum und Uhrzeit (UTC) des Versands der Benachrichtigung Ja „Timeout“ (Zeit abgelaufen) Dieses Datums- und Zeitattribut (im UTC-Format) ist fakultativ. Der Wert wird nur von der Zentralstelle für weitergeleitete Anfragen festgelegt. Die antwortende Partei kann daran ablesen, wann die Zeit für die Anfrage abgelaufen sein wird. Für MS2TCN_<x>_Req und alle Antwort-Benachrichtigungen wird dieser Wert nicht benötigt. Er ist fakultativ, sodass dieselbe Headerdefinition für alle Arten von Benachrichtigungen verwendet werden kann, unabhängig davon, ob das Attribut für den Timeoutwert benötigt wird. Nein Von Der ISO 3166-1 Alpha 2-Code der Partei, die die Benachrichtigung sendet, oder „EU“. Ja An Der ISO 3166-1 Alpha 2-Code der Partei, an die die Benachrichtigung gesendet wird, oder „EU“. Ja Unteranlage 4.4 Transliterations- und NYSIIS-Dienste (New York State Identification and Intelligence System) 1. Für die Codierung der Namen aller Fahrer in den nationalen Registern ist der NYSIIS-Algorithmus der Zentralstelle zu verwenden. 2. Bei der Suche nach einer Karte mit Hilfe der CIC-Funktion sind die NYSIIS-Schlüssel als primärer Suchmechanismus zu verwenden. 3. Darüber hinaus können die Parteien einen eigenen Algorithmus verwenden, um zusätzliche Ergebnisse zu erhalten. 4. Die Suchergebnisse müssen Angaben dazu enthalten, ob für die Suche nach einem Datensatz der NYSIIS-Suchmechanismus oder ein eigener Suchmechanismus verwendet wurde. 5. Entscheidet sich eine Partei, die ICDL-Mitteilungen aufzuzeichnen, dann sind die in der Mitteilung enthaltenen NYSIIS-Schlüssel als Teil der ICDL-Daten zu speichern. Bei der Suche in den ICDL-Daten verwendet die Partei die NYSIIS-Schlüssel des Namens des Antragstellers. Unteranlage 4.5 Sicherheitsanforderungen 1. Für den Austausch von Benachrichtigungen zwischen der Zentralstelle und den nationalen Systemen ist das Protokoll HTTPS zu verwenden. 2. Die nationalen Systeme verwenden die digitalen Zertifikate, die in den Unteranlagen 4.8 und 4.9 für die sichere Übertragung der Benachrichtigungen zwischen den nationalen Systemen und der Zentralstelle genannt werden. 3. Die nationalen Systeme haben als Mindestvorgabe Zertifikate zu implementieren, die den SHA-2 (SHA-256)-Signatur-Hash-Algorithmus nutzen und einen öffentlichen Schlüssel mit einer Länge von 2 048 Bit haben. Unteranlage 4.6 Leistungsanforderungen 1. Die nationalen Systeme müssen die folgenden Mindestleistungen erbringen: 1.1. Sie müssen täglich rund um die Uhr zur Verfügung stehen. 1.2. Ihre Verfügbarkeit wird über eine von der Zentralstelle ausgehende Heartbeat-Nachricht überwacht. 1.3. Ihre Verfügbarkeitsquote muss entsprechend folgender Tabelle bei 98 % liegen (die Zahlen sind auf die nächste Einerstelle gerundet): Eine Verfügbarkeit von bedeutet eine Nichtverfügbarkeit von täglich monatlich jährlich 98 % 0,5 Stunden 15 Stunden 7,5 Tagen Die Parteien sind aufgefordert, die tägliche Verfügbarkeitsquote einzuhalten, wenngleich eingeräumt wird, dass bestimmte unerlässliche Tätigkeiten, wie beispielsweise eine Systemwartung, eine Abschaltung von über 30 Minuten erfordern. Dennoch sind die monatlichen und jährlichen Verfügbarkeitsquoten nach wie vor verbindlich. 1.4. Sie müssen auf mindestens 98 % der Anfragen reagieren, die bei ihnen in einem Kalendermonat eingehen. 1.5. Sie müssen auf die Anfragen innerhalb von 10 Sekunden reagieren. 1.6. Generell darf bei Anfragen die Dauer bis zum Zeitablauf (die Wartezeit des Anfragenden auf eine Antwort) 20 Sekunden nicht überschreiten. 1.7. Sie müssen in der Lage sein, eine Anfragequote von 6 Benachrichtigungen pro Sekunde zu bearbeiten. 1.8. Nationale Systeme dürfen bei der Übermittlung von Anfragen an die Zentralstelle des TACHOnet eine Anfragequote von 2 Anfragen pro Sekunde nicht überschreiten. 1.9. Jedes nationale System muss in der Lage sein, mit technischen Problemen der Zentralstelle oder der nationalen Systeme anderer Parteien umzugehen. Hierzu zählen unter anderem: a) Unterbrechung der Verbindung zur Zentralstelle, b) keine Antwort auf eine Anfrage, c) Eingang von Antworten nach Zeitablauf, d) Eingang nicht angeforderter Benachrichtigungen, e) Eingang ungültiger Benachrichtigungen. 2. Die Zentralstelle muss: 2.1. eine Verfügbarkeitsquote von 98 % gewährleisten; 2.2. den nationalen Systemen Fehlermeldungen übermitteln — entweder über eine Antwort-Benachrichtigung oder über eine spezielle Fehler-Benachrichtigung. Die nationalen Systeme, die diese speziellen Fehler-Benachrichtigungen erhalten, verfügen ihrerseits über einen abgestuften Reaktionsablauf, um die geeigneten Maßnahmen zur Behebung des gemeldeten Fehlers zu ergreifen. 3. Instandhaltung Die Parteien teilen den anderen Parteien und der Europäischen Kommission, sofern technisch möglich, mindestens eine Woche im Voraus etwaige Routine-Instandhaltungstätigkeiten über die Internet-Anwendung mit. Unteranlage 4.7 Protokollierung und Statistik der in der Zentralstelle erfassten Daten 1. Aus Datenschutzgründen müssen die für statistische Zwecke erhobenen Daten anonymisiert sein. Daten, die Rückschlüsse auf bestimmte Karten, Fahrer oder Fahrerlaubnisse zulassen, dürfen nicht zu statistischen Zwecken genutzt werden. 2. Für die Zwecke der Überwachung und Fehlerbehebung müssen die Protokolle alle Transaktionen erfassen und es ermöglichen, Statistiken über diese Transaktionen anzufertigen. 3. In den Protokollen dürfen personenbezogene Daten nicht länger als sechs Monate gespeichert werden. Statistische Informationen sind unbefristet aufzubewahren. 4. Die statistischen Daten für die Berichterstattung umfassen: a) die anfragende Partei; b) die antwortende Partei; c) die Art der Benachrichtigung; d) den Status-Code der Antwort; e) Datum und Uhrzeit der Benachrichtigungen; f) die Antwortzeit. Unteranlage 4.8 Allgemeine Bestimmungen für digitale Schlüssel und Zertifikate für TACHOnet 1. Der Generaldirektor der Generaldirektion Informatik der Europäischen Kommission (DIGIT) stellt den AETR-Vertragsparteien, die sich mit TACHOnet über eDelivery vernetzen (im Folgenden die „nationalen Behörden“) einen PKI-Dienst (1) zur Verfügung (der PKI-Dienst der Fazilität „Connecting Europe“ im Folgenden „CEF-PKI-Dienst“). 2. Das Verfahren für die Beantragung und Sperrung digitaler Zertifikate sowie die einzelnen Bedingungen für deren Verwendung sind in dieser Anlage erläutert. 3. Verwendung von Zertifikaten: 3.1. Sobald das Zertifikat ausgestellt wurde, darf die nationale Behörde (2) das Zertifikat nur im Zusammenhang mit TACHOnet verwenden. Das Zertifikat kann verwendet werden, um a) die Herkunft der Daten zu authentifizieren; b) Daten zu verschlüsseln; c) sicherzustellen, dass eine Verletzung der Integrität der Daten erkannt wird. 3.2. Jede Verwendung, die im Rahmen der erlaubten Verwendungen des Zertifikats nicht ausdrücklich genehmigt wird, ist untersagt. 4. Die Vertragsparteien a) schützen ihren privaten Schlüssel vor unbefugter Nutzung; b) geben ihren privaten Schlüssel auch nicht als Vertreter an Dritte weiter oder legen diesen privaten Schlüssel gegenüber Dritten offen; c) gewährleisten die Vertraulichkeit, Integrität und Verfügbarkeit der privaten Schlüssel, die für TACHOnet generiert, gespeichert und verwendet werden; d) verwenden den privaten Schlüssel nach Ablauf der Gültigkeit oder nach einer Sperrung des Zertifikats nicht weiter, ausgenommen ist die Sichtbarmachung verschlüsselter Daten (z. B. das Lesen verschlüsselter E-Mails). Abgelaufene Schlüssel müssen entweder vernichtet oder so aufbewahrt werden, dass sie nicht mehr verwendet werden können; e) identifizieren gegenüber der Registrierungsbehörde die autorisierten Vertreter, die befugt sind, die Sperrung von Zertifikaten zu beantragen, die von der Organisation ausgestellt wurden (Anträge auf Sperrung müssen ein Sperrbeantragungspasswort sowie Angaben zu den Vorkommnissen enthalten, die zu der Sperrung geführt haben); f) verhindern die missbräuchliche Nutzung des privaten Schlüssels, indem sie die Sperrung des entsprechenden Public-Key-Zertifikats beantragen, sofern der private Schlüssel oder die Aktivierungsdaten des privaten Schlüssels gefährdet wurden; g) sind dafür verantwortlich und verpflichtet, die Sperrung eines Zertifikats zu beantragen, wenn die in dem Dokument „Zertifizierungsrichtlinie (Certificate Policy, CP) und Erklärung zum Zertifizierungsbetrieb (Certification Practice Statement, CPS)“ der Zertifizierungsbehörde genannten Umstände vorliegen; h) melden der Registrierungsbehörde unverzüglich jeden Verlust, Diebstahl oder jede potenzielle Gefährdung von AETR-Schlüsseln, die im Zusammenhang mit TACHOnet verwendet werden. 5. Haftung Unbeschadet der Haftung der Kommission bei einem Verstoß gegen einschlägige einzelstaatliche Rechtsvorschriften oder in Fällen, in denen ein Ausschluss nach diesen Rechtsvorschriften nicht möglich ist, übernimmt die Europäische Kommission keine Verantwortung oder Haftung für a) den Inhalt des Zertifikats, die ausschließlich beim Inhaber des Zertifikats liegt. Es liegt in der Verantwortung des Zertifikatinhabers, die Richtigkeit des Zertifikatinhalts zu prüfen; b) die Verwendung des Zertifikats durch seinen Inhaber. Unteranlage 4.9 Beschreibung des PKI-Dienstes für TACHOnet 1. Einführung Eine PKI (Public Key Infrastruktur) besteht aus Rollen, Richtlinien, Verfahren und Systemen für die Schaffung, Verwaltung und Sperrung digitaler Zertifikate (3). Der CEF-PKI-Dienst „eDelivery“ ermöglicht die Ausstellung und Verwaltung digitaler Zertifikate, die zur Gewährleistung der Vertraulichkeit, Integrität und Nichtabstreitbarkeit des Informationsaustauschs zwischen den Zugangspunkten (AP) verwendet werden. Der PKI-Dienst „eDelivery“ stützt sich auf den Dienst „TeleSec Shared Business CA“, für den das Dokument „Zertifizierungsrichtlinie (Certificate Policy, CP) und Erklärung zum Zertifizierungsbetrieb (Certification Practice Statement, CPS)“ des Trust-Center-Dienstes „TeleSec Shared-Business-CA“ der T-Systems International GmbH (4) gilt. Mit dem PKI-Dienst werden Zertifikate ausgestellt, die für die Absicherung verschiedener Geschäftsabläufe innerhalb und außerhalb von Unternehmen, Organisationen, öffentlichen Behörden und Institutionen geeignet sind und die ein mittleres Sicherheitsniveau benötigen, mit dem sich die Authentizität, Integrität und Vertrauenswürdigkeit der Endteilnehmer nachweisen lässt. 2. Verfahren zur Beantragung eines Zertifikats 2.1. Rollen und Zuständigkeiten 2.1.1. „Organisation“ oder „nationale Behörde“, die das Zertifikat beantragt 2.1.1.1. Die nationale Behörde beantragt Zertifikate im Zusammenhang mit dem TACHOnet-Projekt. 2.1.1.2. Die nationale Behörde a) beantragt die Zertifikate beim CEF-PKI-Dienst; b) generiert private Schlüssel und die entsprechenden öffentlichen Schlüssel, die in die von der Zertifizierungsbehörde ausgestellten Zertifikate eingetragen werden; c) lädt das Zertifikat nach Genehmigung herunter; d) unterzeichnet und sendet an die Registrierungsbehörde zurück: i) das Identifizierungsformular der Kontaktpersonen und des vertrauenswürdigen Kuriers, ii) die unterzeichnete Einzelvollmacht (5). 2.1.2. Vertrauenswürdiger Kurier 2.1.2.1. Die nationale Behörde benennt einen vertrauenswürdigen Kurier. 2.1.2.2. Dieser a) übergibt den öffentlichen Schlüssel der Registrierungsbehörde während des Verfahrens der persönlichen Identifizierung und Registrierung; b) nimmt das entsprechende Zertifikat von der Registrierungsbehörde entgegen. 2.1.3. Domain-Inhaber 2.1.3.1. Domain-Inhaber ist die GD MOVE. 2.1.3.2. Der Domain-Inhaber a) validiert und koordiniert das TACHOnet-Netz und die TACHOnet-Vertrauensarchitektur, einschließlich der Validierung der Verfahren für die Ausstellung von Zertifikaten; b) betreibt die TACHOnet-Zentralstelle und koordiniert die Tätigkeiten der Parteien hinsichtlich der Funktionsweise des TACHOnet; c) führt zusammen mit nationalen Behörden Tests zur Vernetzung mit TACHOnet durch. 2.1.4. Registrierungsbehörde 2.1.4.1. Registrierungsbehörde ist die Gemeinsame Forschungsstelle (JRC). 2.1.4.2. Die Registrierungsbehörde ist für die Überprüfung der Identität des vertrauenswürdigen Kuriers sowie für die Registrierung und Genehmigung der Anträge auf Ausstellung, Sperrung und Erneuerung digitaler Zertifikate zuständig. 2.1.4.3. Die Registrierungsbehörde muss a) der nationalen Behörde die eindeutige Kennung zuweisen; b) die Identität der nationalen Behörde, ihrer Ansprechpartner und vertrauenswürdigen Kuriere authentifizieren; c) mit dem CEF-Support hinsichtlich der Authentizität der nationalen Behörde, ihrer Ansprechpartner und vertrauenswürdigen Kuriere kommunizieren; d) die nationale Behörde über die Genehmigung oder Ablehnung eines Zertifikats unterrichten. 2.1.5. Zertifizierungsbehörde (Certification Authority) 2.1.5.1. Die Zertifizierungsbehörde ist für die Bereitstellung der technischen Infrastruktur für die Beantragung, Ausstellung und Sperrung digitaler Zertifikate zuständig. 2.1.5.2. Die Zertifizierungsbehörde muss a) die technische Infrastruktur für die Beantragung von Zertifikaten durch nationale Behörden bereitstellen; b) Zertifikatanträge validieren oder ablehnen; c) mit der Registrierungsbehörde kommunizieren, um bei Bedarf die Identität einer anfragenden Organisation zu überprüfen. 2.2. Ausstellung von Zertifikaten 2.2.1. Zertifikate werden in der Reihenfolge der in Abbildung 1 dargestellten Schritte ausgestellt: a) Schritt 1: Identifizierung des vertrauenswürdigen Kuriers; b) Schritt 2: Beantragung eines Zertifikats; c) Schritt 3: Registrierung bei der Registrierungsbehörde; d) Schritt 4: Generierung des Zertifikats; e) Schritt 5: Veröffentlichung des Zertifikats; f) Schritt 6: Zertifikat wird akzeptiert. Abbildung1 — Ablaufschema der Zertifikatausstellung 2.2.2. Schritt 1: Identifizierung des vertrauenswürdigen Kuriers Zur Identifizierung des vertrauenswürdigen Kuriers ist wie folgt zu verfahren: a) Die Registrierungsbehörde sendet der nationalen Behörde das Identifizierungsformular zu den Ansprechpartnern und zum vertrauenswürdigen Kurier (6). Dieses Formular enthält auch eine Vollmacht, die die Organisation (AETR-Behörde) unterzeichnet. b) Die nationale Behörde sendet der Registrierungsbehörde das ausgefüllte Formular und die unterzeichnete Vollmacht zurück. c) Die Registrierungsbehörde bestätigt den Empfang und die Vollständigkeit des Formulars. d) Die Registrierungsbehörde stellt dem Domain-Inhaber eine aktuelle Liste der Ansprechpartner und vertrauenswürdigen Kuriere zur Verfügung. 2.2.3. Schritt 2: Beantragung eines Zertifikats 2.2.3.1. Die Beantragung und Entgegennahme des Zertifikats erfolgt auf demselben Computer und mit demselben Browser. 2.2.3.2. Für die Beantragung eines Zertifikats ist wie folgt zu verfahren: a) Die Organisation beantragt das Zertifikat über die URL https://sbca.telesec.de/sbca/ee/login/displayLogin.html?locale=en und gibt als Login „sbca/CEF_eDelivery.europa.eu“ und als Passwort „digit.333“ ein. Abbildung 2 b) Die Organisation klickt auf der linken Seite „request“ an und wählt dann „CEF_TACHOnet“ in der Dropdown-Liste aus. Abbildung 3 c) Die Organisation füllt das Formular zur Beantragung des Zertifikats (Abbildung 4) mit den Angaben von Tabelle 3 aus und klickt dann auf „Next (soft-PSE)“, um den Prozess abzuschließen. Abbildung 4 Auszufüllende Felder Beschreibung Land C = Country Code, Sitz des Inhabers des Zertifikats, überprüft anhand eines öffentlichen Verzeichnisses; Beschränkungen: 2 Zeichen nach ISO 3166-1, Alpha-2, Groß- und Kleinschreibung Beispiele: DE, BE, NL, Besondere Fälle: UK (für Großbritannien), EL (für Griechenland) Organisation/Unternehmen (O) O = Name der Organisation des Zertifikatinhabers Master Domain (OU1) OU = CEF_eDelivery.europa.eu „Area of responsibility“ (OU2) (Zuständigkeitsbereich) OU = CEF_TACHOnet „Department“ (OU3) (Abteilung) Obligatorischer Wert je „AREA OF RESPONSIBILITY“ Der Inhalt ist mit Hilfe einer Positivliste (weißen Liste) bei Antragstellung zu prüfen. Stimmen die Angaben mit der Liste nicht überein, wird die Beantragung verhindert. Format: OU=<TYPE>-<GTC_NUMBER> Dabei wird „<TYPE>“ durch AP_PROD ersetzt: Zugangspunkt in Produktionsumgebung. und <GTC_NUMBER> ist GTC_OID-1.3.130.0.2018.xxxxxx, dabei ist Ares(2018)xxxxxx die GTC-Nummer für das TACHOnet-Projekt. z. B.: AP_PROD-GTC_OID-1.3.130.0.2018.xxxxxx „First name (CN)“ (Vorname) Nicht ausfüllen „Last name (CN)“ (Nachname) Muss mit „GRP“ anfangen, gefolgt von einer Trivialbezeichnung Format: CN = GRP:<AREA OF RESPONSIBILITY>_<TYPE>_<COUNTRY CODE>_<UNIQUE IDENTIFIER> z. B.: GRP:CEF_TACHOnet_AP_PROD_BE_001 „E-Mail“ (E-Mail) E = CEF-EDELIVERY-SUPPORT@ec.europa.eu „E-mail 1 (SAN)“ Nicht ausfüllen „E-mail 2 (SAN)“ Nicht ausfüllen „E-mail 3 (SAN)“ Nicht ausfüllen „Address“ (Anschrift) Nicht ausfüllen „Street“ (Straße) Offizielle Anschrift der Organisation des Zertifikatinhabers. (Verwendet für die Vollmacht) „Street no.“ (Hausnr.) Offizielle Anschrift der Organisation des Zertifikatinhabers. (Verwendet für die Vollmacht) „Zip Code“ (PLZ) Offizielle Anschrift der Organisation des Zertifikatinhabers. (Verwendet für die Vollmacht) Achtung : Ist die Postleitzahl nicht fünfstellig, das PLZ-Feld frei lassen und die PLZ in das „City“-Feld eintragen. „City“ (Ort) Offizielle Anschrift der Organisation des Zertifikatinhabers. (Verwendet für die Vollmacht) Achtung : Ist die Postleitzahl nicht fünfstellig, das PLZ-Feld frei lassen und die PLZ in das „Cit