               KOMISJA EUROPEJSKA
            Bruksela, dnia 2.10.2018
            COM(2018) 664 final
            2018/0339(NLE)
            Wniosek
            DECYZJA RADY
            dotycząca stanowiska, jakie ma zostać zajęte w imieniu Unii Europejskiej w grupie ekspertów ds. Umowy europejskiej dotyczącej pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe Europejskiej Komisji Gospodarczej ONZ

               UZASADNIENIE

               1.Przedmiot wniosku

               Niniejszy wniosek dotyczy decyzji w sprawie stanowiska, jakie ma zostać zajęte w imieniu Unii Europejskiej w ramach grupy ekspertów ds. AETR Europejskiej Komisji Gospodarczej ONZ (EKG ONZ) w związku z przewidywaną zmianą Umowy europejskiej dotyczącej pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe (AETR) odnośnie do połączenia z systemem Tachonet Umawiających się Stron AETR spoza UE.

               2.Kontekst wniosku

               2.1.AETR

               Umowa europejska dotycząca pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe (zwana dalej „umową”) ma na celu harmonizację ram prawnych Umawiających się Stron umowy w zakresie czasu prowadzenia pojazdu i okresów odpoczynku dla kierowców zawodowych, a także odpowiednich wymagań technicznych dotyczących budowy i instalacji tachografu. Przedmiotowa umowa weszła w życie w dniu 5 stycznia 1976 r.

               Wszystkie państwa członkowskie są stronami tej umowy
                  1
               .

               2.2.Grupa ekspertów ds. AETR

               Grupa ekspertów ds. AETR jest grupą techniczną utworzoną przez Komitet ds. Transportu Lądowego EKG ONZ w celu opracowania propozycji zmian do umowy. Propozycje zmian do umowy są przyjmowane jednomyślnie przez ekspertów z grupy, a następnie przedkładane SC.1 (Grupie Roboczej EKG ONZ ds. Transportu Drogowego) do przyjęcia zwykłą większością głosów Umawiających się Stron obecnych i głosujących.

               2.3.Planowany akt grupy ekspertów ds. AETR

               W dniu 15 października 2018 r., na swoim 19. posiedzeniu, grupa ekspertów ds. AETR podejmie decyzję w sprawie przedłożenia SC.1 propozycji zmiany AETR dotyczącej połączenia z systemem Tachonet Umawiających się Stron AETR spoza UE („planowany akt”).

               Celem planowanego aktu jest określenie wymogów technicznych dotyczących połączenia Umawiających się Stron AETR spoza UE z systemem Tachonet za pośrednictwem platformy eDelivery opracowanej przez Komisję Europejską.

               Planowany akt stanie się wiążący dla stron zgodnie z art. 13 ust. 1 umowy, który przewiduje: „Wszystkie nowe postanowienia niniejszej umowy, w tym jej załącznika oraz jego suplementów1B i 2 odnoszące się do wprowadzenia cyfrowego przyrządu kontrolnego, staną się obowiązkowe dla krajów będących Umawiającymi się Stronami niniejszej umowy najpóźniej po czterech latach od wejścia w życie odpowiednich zmian wynikających z procedury określonej w art. 21”.

               3.Stanowisko, jakie ma zostać zajęte w imieniu Unii

               Tachonet jest europejskim systemem elektronicznej wymiany informacji dotyczących kart do tachografów między państwami członkowskimi. Jest to podstawowe narzędzie służące egzekwowaniu przepisów dotyczących czasu prowadzenia pojazdów i odpoczynku w transporcie drogowym określonych w rozporządzeniu (UE) nr 561/2006
                  2
               . Tachonet służy przede wszystkim do sprawdzania, czy różne państwa członkowskie nie wydały temu samemu kierowcy więcej niż jednej karty.

               Państwa członkowskie są zobowiązane do zapewnienia połączenia z systemem Tachonet zgodnie z art. 31 ust. 2 rozporządzenia (UE) nr 165/2014
                  3
                oraz wymogami technicznymi określonymi w rozporządzeniu (UE) nr 2016/68
                  4
               .

               Przepisy dotyczące czasu prowadzenia pojazdu i odpoczynku mają zastosowanie również do Umawiających się Stron AETR (Umowy europejskiej dotyczącej pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe) spoza UE. W celu zapewnienia egzekwowania przepisów dotyczących czasu prowadzenia pojazdu i odpoczynku w tych krajach konieczne jest zatem, aby one również połączyły się z systemem Tachonet. Umawiające się Strony AETR spoza UE nie mogą jednak bezpośrednio łączyć się z systemem Tachonet. Bezpośrednie połączenia tworzone są za pośrednictwem sieci TESTA (transeuropejska telematyczna sieć komunikacyjna między administracjami), do której dostęp jest zarezerwowany dla organów i instytucji UE, państw członkowskich UE, państw EOG, Szwajcarii oraz państw przystępujących do UE. Państwa trzecie, które nie przystępują do UE lub które nie należą do EOG, muszą być połączone z systemem Tachonet za pośrednictwem państwa już połączonego z TESTA, tj. za pośrednictwem połączenia pośredniego. Takie pośrednie połączenia opierają się na umowach dwustronnych zawartych między Umawiającymi się Stronami AETR spoza UE a państwem, które zapewnia połączenie.

               Andora, Armenia, Azerbejdżan, Bośnia i Hercegowina, Gruzja, Liechtenstein, Mołdawia, Serbia i Ukraina są 9 Umawiającymi się Stronami AETR spoza UE, które obecnie są pośrednio połączone z Tachonet za pośrednictwem węzłów udostępnionych przez Francję, Chorwację, Polskę, Rumunię i Szwajcarię.

               Problem techniczny, który należy rozwiązać oraz proponowane rozwiązanie

               Dyrekcja Generalna ds. Informatyki Komisji Europejskiej (DIGIT) uznała niedawno, że połączenia pośrednie nie spełniają minimalnych norm bezpieczeństwa wymaganych przez Komisję. Wynika to z faktu, że odcinek sieci między państwem członkowskim a stroną trzecią nie musi być zabezpieczony. Ponadto wystąpienie jakiegokolwiek rodzaju ataku na tę część sieci potencjalnie nie jest widoczne dla Komisji. Zwiększa to ryzyko naruszenia systemu bezpieczeństwa.

               Z tego względu połączenia pośrednie muszą zostać usunięte i zastąpione alternatywnym narzędziem umożliwiającym Umawiającym się Stronom AETR spoza UE połączenie z systemem Tachonet.

               Takie połączenie może być zapewnione poprzez eDelivery – nadrzędną platformę finansowaną z instrumentu „Łącząc Europę”. Umożliwia ona połączenie przez internet przy wykorzystaniu standardowych technologii bezpieczeństwa, takich jak infrastruktura klucza publicznego (PKI), w celu zagwarantowania autentyczności, integralności i poufności wymienianych informacji. Zapewnia ona zatem wzajemne zaufanie przy elektronicznej wymianie informacji. Usługa eDelivery świadczona jest przez DIGIT.

               Platforma eDelivery była już z powodzeniem wykorzystywana do świadczenia szeregu ogólnounijnych usług, takich jak PEPPOL (paneuropejski system publicznych zamówień online) oraz e-Codex (elektroniczne połączenie między przedstawicielami zawodów prawniczych w całej UE). System ten można dostosować do Tachonet.

               Mimo że DIGIT nie podała żadnych konkretnych terminów dotyczących zamknięcia połączeń pośrednich, szacuje się, że dostosowanie eDelivery do Tachonet może zająć około jednego roku. Konieczne jest zatem wprowadzenie zmian do AETR w jak najkrótszym czasie, aby platforma eDelivery zaczęła funkcjonować jak najszybciej.

               Obowiązki organów krajowych w zakresie stosowania Tachonet

               Korzystanie z eDelivery w celu połączenia z systemem Tachonet wymaga, aby połączone strony przyjęły na siebie pewne obowiązki w celu zagwarantowania właściwego korzystania z systemu oraz wymiany informacji z ich odpowiednikami. Obowiązki te dotyczą:

               a) bezpieczeństwa

               Organy krajowe muszą chronić prywatne klucze i odpowiadające im certyfikaty cyfrowe poprzez:

               –
                     unikanie nieuprawnionego użycia kluczy prywatnych;

               –
                     powstrzymywanie się od przekazywania lub ujawniania swoich kluczy prywatnych osobom trzecim;

               –
                     zapewnianie poufności, integralności i dostępności kluczy prywatnych wygenerowanych, przechowywanych i używanych na potrzeby systemu Tachonet;

               –
                     powstrzymywanie się od korzystania z klucza prywatnego po upływie okresu ważności lub unieważnieniu certyfikatu;

               –
                     niszczenie kluczy po wygaśnięciu ich ważności;

               –
                     zapobieganie niewłaściwemu wykorzystywaniu kluczy prywatnych, poprzez zwrócenie się o unieważnienie powiązanego certyfikatu klucza publicznego w przypadku narażenia na szwank bezpieczeństwa kluczy prywatnych lub danych dotyczących aktywacji klucza prywatnego.

               b) ochrony danych

               Należy zapewnić ochronę danych osobowych. Biorąc pod uwagę, że Umawiające się Strony AETR spoza UE nie są związane europejskimi przepisami dotyczącymi ochrony danych, konieczne jest zagwarantowanie zgodności z Konwencją o ochronie osób w związku z automatycznym przetwarzaniem danych osobowych. Konwencja ta stanowi międzynarodowe ramy odniesienia w dziedzinie ochrony danych osobowych.

               c) aspektów technicznych

               Połączone strony muszą przeprowadzić określoną serię testów przed ustanowieniem połączenia. Muszą również gwarantować minimalny poziom obsługi w taki sposób, aby system Tachonet nie został zakłócony z powodu awarii na poziomie krajowym.

               Instrument prawny

               Wymogi techniczne dotyczące połączenia Umawiających się Stron AETR spoza UE z systemem Tachonet powinny być określone we właściwych ramach międzynarodowych, tj. w umowie AETR.

               Obecnie prowadzone są negocjacje w ramach grupy ekspertów ds. AETR Europejskiej Komisji Gospodarczej ONZ w związku ze zmianą umowy, w szczególności w celu zapewnienia stosowania prawodawstwa UE dotyczącego inteligentnych tachografów przez Umawiające się Strony AETR spoza UE oraz umożliwienia UE przystąpienia do umowy AETR
                  5
               . Wymogi techniczne i prawne odnoszące się do połączenia Umawiających się Stron AETR spoza UE z systemem Tachonet powinny zostać oficjalnie przedstawione przez UE sekretariatowi AETR jako nowy dodatek do umowy. Ten nowy dodatek zostanie omówiony na następnym posiedzeniu grupy ekspertów ds. AETR i w ramach Grupy Roboczej ds. Transportu Drogowego wraz z elementami stanowiska UE, które przekazano już sekretariatowi AETR w 2016 r.

               4.Podstawa prawna

               4.1.Proceduralna podstawa prawna

               4.1.1.Zasady

               Art. 218 ust. 9 Traktatu o Funkcjonowaniu Unii Europejskiej (TFUE) przewiduje decyzje ustalające „stanowiska, które mają być zajęte w imieniu Unii w ramach organu utworzonego przez umowę, gdy organ ten ma przyjąć akty mające skutki prawne, z wyjątkiem aktów uzupełniających lub zmieniających ramy instytucjonalne umowy”.

               Art. 218 ust. 9 TFUE ma zastosowanie niezależnie od tego, czy Unia jest członkiem organu czy też stroną danej umowy
                  6
               .

               Pojęcie „akty mające skutki prawne” obejmuje akty, które mają skutki prawne na mocy przepisów prawa międzynarodowego dotyczących danego organu. Obejmuje ono ponadto instrumenty, które nie są wiążące na mocy prawa międzynarodowego, ale mogą „w sposób decydujący wywrzeć wpływ na treść przepisów przyjętych przez prawodawcę Unii”
                  7
               .

               4.1.2.Zastosowanie w niniejszej sprawie

               Grupa ekspertów ds. AETR jest organem utworzonym przez Komitet ds. Transportu Lądowego EKG ONZ.

               Akt, który grupa ekspertów ds. AETR ma przedstawić SC.1, stanowi akt mający skutki prawne. Planowany akt będzie wiążący na mocy prawa międzynarodowego zgodnie z art. 13 AETR.

               Planowany akt nie uzupełnia ani nie zmienia ram instytucjonalnych umowy.

               W związku z tym proceduralną podstawą prawną proponowanej decyzji jest art. 218 ust. 9 TFUE.

               4.2.Materialna podstawa prawna

               4.2.1.Zasady

               Materialna podstawa prawna decyzji na podstawie art. 218 ust. 9 TFUE zależy przede wszystkim od celu i treści planowanego aktu, w którego kwestii ma być zajęte stanowisko w imieniu Unii. Jeżeli planowany akt ma dwojaki cel lub dwa elementy składowe, a jeden z tych celów lub elementów da się określić jako główny, zaś drugi ma jedynie pomocniczy charakter, decyzja przyjęta na mocy art. 218 ust. 9 TFUE musi mieć jedną materialną podstawę prawną, tj. podstawę, której wymaga główny lub dominujący cel lub element składowy.

               4.2.2.Zastosowanie w niniejszej sprawie

               Główny cel i treść planowanego aktu prawnego odnoszą się do transportu.

               Materialną podstawą prawną proponowanej decyzji jest zatem art. 91 TFUE.

               4.3.Podsumowanie

               Podstawą prawną proponowanej decyzji powinien być art. 91 TFUE w związku z art. 218 ust. 9 TFUE.

               2018/0339 (NLE)

               Wniosek

               DECYZJA RADY

               dotycząca stanowiska, jakie ma zostać zajęte w imieniu Unii Europejskiej w grupie ekspertów ds. Umowy europejskiej dotyczącej pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe Europejskiej Komisji Gospodarczej ONZ

               RADA UNII EUROPEJSKIEJ,

               uwzględniając Traktat o funkcjonowaniu Unii Europejskiej, w szczególności jego art. 91 w związku z art. 218 ust. 9,

               uwzględniając wniosek Komisji Europejskiej,

               a także mając na uwadze, co następuje:

               (1)Umowa europejska dotycząca pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe (AETR) weszła w życie w dniu 5 stycznia 1976 r.

               (2)Europejska Komisja Gospodarcza Organizacji Narodów Zjednoczonych powołała w ramach AETR grupę ekspertów. Jest to organ uprawniony do opracowania i przedstawienia proponowanych zmian umowy AETR Grupie Roboczej ds. Transportu Drogowego.

               (3)Na swoim 19. posiedzeniu, które odbędzie się w dniu 15 października 2018 r., grupa ekspertów ds. AETR ma przyjąć decyzję w sprawie przedłożenia Grupie Roboczej EKG ONZ ds. Transportu Drogowego propozycji zmiany AETR.

               (4)Należy ustalić stanowisko, jakie ma zostać zajęte w imieniu Unii w ramach grupy ekspertów ds. AETR, ponieważ zmiana AETR będzie dla Unii wiążąca.

               (5)W swoim wyroku z dnia 31 marca 1971 r. (sprawa 22/70 AETR) Trybunał Sprawiedliwości Unii Europejskiej potwierdził, że dziedzina pracy załóg pojazdów w transporcie drogowym wchodzi w zakres zewnętrznych kompetencji Unii. Kompetencje te były od tego czasu realizowane za pośrednictwem szeregu aktów prawnych przyjętych przez prawodawcę Unii, w tym rozporządzenia (WE) nr 561/2006 Parlamentu Europejskiego i Rady
                  8
                oraz rozporządzenia Parlamentu Europejskiego i Rady (UE) nr 165/2014
                  9
               . Ponieważ przedmiot AETR wchodzi w zakres rozporządzenia (WE) nr 561/2006, Unia posiada wyłączną kompetencję do negocjowania i zawarcia tej umowy oraz dokonywania jej modyfikacji.

               (6)Następne posiedzenie grupy ekspertów ds. AETR odbędzie się w dniu 15 października 2018 r., a posiedzenie Grupy Roboczej ds. Transportu Drogowego odbędzie się w dniu 16 października 2018 r. Przy tej okazji grupa ekspertów i grupa robocza mają przeanalizować propozycje przedstawione przez Umawiające się Strony, które pod warunkiem akceptacji przez grupę ekspertów mogą doprowadzić do zmian w umowie AETR, po wszczęciu i sfinalizowaniu procedury rewizji umowy AETR. Po przyjęciu propozycji przez grupę ekspertów państwa członkowskie Unii jako Umawiające się Strony AETR są zobowiązane do współpracy w celu uruchomienia mechanizmu rewizji umowy AETR zgodnie z rozporządzeniem Rady (EWG) 2829/77
                  10
                oraz zgodnie z obowiązkiem lojalnej współpracy wynikającym z art. 4 ust. 3 TUE, z zastrzeżeniem odpowiednio decyzji Rady zgodnie z art. 218 ust. 6. Proponowane zmiany w AETR staną się skuteczne dopiero po zakończeniu procedury rewizji AETR.

               (7)Na mocy rozporządzenia (UE) nr 165/2014 państwa członkowskie są zobowiązane do wzajemnego połączenia swoich elektronicznych rejestrów kart kierowcy za pomocą systemu informacyjnego Tachonet lub, w przypadku korzystania z systemu kompatybilnego, do zapewnienia możliwości wymiany danych elektronicznych ze wszystkimi pozostałymi państwami członkowskimi za pomocą systemu informacyjnego Tachonet. System Tachonet stanowi platformę wymiany informacji na temat kart kierowcy między państwami członkowskimi, aby zagwarantować, że kierowcy nie posiadają więcej niż jednej karty kierowcy.

               (8)W celu osiągnięcia ogólnoeuropejskiej harmonizacji w dziedzinie elektronicznej wymiany informacji dotyczących kart kierowcy konieczne jest wykorzystanie systemu Tachonet jako jednej platformy przez wszystkie Umawiające się Strony AETR.

               (9)Podłączenie do systemu informacyjnego Tachonet jest obecnie możliwe albo bezpośrednio poprzez transeuropejską telematyczną sieć komunikacyjną między administracjami („TESTA”) albo pośrednio przez państwo członkowskie już podłączone do sieci TESTA. Zważywszy, że TESTA jest usługą, która jest ograniczona do państw członkowskich i instytucji Unii, Umawiające się Strony AETR spoza UE są zobowiązane do korzystania z systemu TACHOnet w sposób pośredni.

               (10)Komisja dokonała ostatnio oceny pośrednich połączeń z systemem informacyjnym Tachonet i stwierdziła, że nie zapewniają one takiego samego poziomu bezpieczeństwa jak TESTA. W szczególności nie ma wystarczającej gwarancji autentyczności, integralności i poufności informacji wymienianych za pomocą połączeń pośrednich. Pośrednie połączenia z systemem Tachonet powinny zatem zostać zastąpione bezpiecznym połączeniem.

               (11)Platforma eDelivery to sieć węzłów przyłączeniowych na potrzeby łączności cyfrowej opracowana przez Komisję, w której każdy uczestnik na poziomie krajowym staje się węzłem przy użyciu standardowych protokołów komunikacyjnych i polityki bezpieczeństwa. Platforma eDelivery jest elastycznym narzędziem, które może zostać dostosowane do poszczególnych usług.

               (12)W ramach platformy eDelivery wykorzystuje się powszechnie stosowane technologie bezpieczeństwa, takie jak infrastruktura klucza publicznego (PKI), w celu zapewnienia autentyczności, integralności i poufności wymienianych informacji. Dostęp Umawiających się Stron AETR spoza UE do systemu Tachonet powinien odbywać się za pośrednictwem eDelivery.

               (13)Umawiające się Strony AETR powinny stosować konkretną procedurę w celu otrzymania certyfikatów elektronicznych oraz odpowiednich kluczy elektronicznych umożliwiających dostęp do systemu Tachonet.

               (14)Połączenie z systemem Tachonet za pośrednictwem eDelivery oznacza, że Umawiające się Strony AETR są zobowiązane do zapewnienia ochrony kluczy elektronicznych i certyfikatów umożliwiających dostęp do systemu oraz tego, że nie zostaną one wykorzystane przez nieuprawnione osoby. Powinny one również zagwarantować, że klucze objęte certyfikatami, które utraciły ważność, nie będą dalej wykorzystywane.

               (15)Konieczne jest zagwarantowanie stronom ochrony danych osobowych za pośrednictwem Tachonet zgodnie z Konwencją o ochronie osób w związku z automatycznym przetwarzaniem danych osobowych (Strasburg, 21 stycznia 1981 r.).

               (16)Organy krajowe połączone z systemem Tachonet mają obowiązek przeprowadzenia odpowiednich wdrożeń technicznych w celu zapewnienia, aby system Tachonet funkcjonował zgodnie z wysokimi poziomami skuteczności działania. Zadaniem Komisji jest przygotowanie testów potwierdzających osiągnięcie tych poziomów skuteczności działania i ich wdrożenie we współpracy z właściwymi organami krajowymi.

               (17)Ponieważ Unia Europejska nie jest umawiającą się stroną umowy AETR i jej status nie pozwala jej na przedstawienie proponowanych zmian, państwa członkowskie, działając w interesie Unii, powinny przekazać proponowane zmiany grupie ekspertów w duchu lojalnej współpracy, aby promować osiągnięcie celów Unii.

               (18)Stanowisko Unii ma być wyrażone przez państwa członkowskie Unii będące członkami grupy ekspertów ds. AETR oraz Grupy Roboczej ds. Transportu Drogowego, działające wspólnie,

               PRZYJMUJE NINIEJSZĄ DECYZJĘ:

               Artykuł 1

               Stanowisko, jakie ma zostać zajęte w imieniu Unii w trakcie 15. posiedzenia grupy ekspertów ds. Umowy europejskiej dotyczącej pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe (AETR), powinno wyrażać poparcie dla proponowanych zmian umowy AETR określonych w dokumencie załączonym do niniejszej decyzji.

               Artykuł 2

               Stanowisko, o którym mowa w art. 1, ma zostać wyrażone przez państwa członkowskie Unii będące członkami AETR, działające wspólnie.

               Formalne i drobne modyfikacje stanowiska, o którym mowa w art. 1, mogą być uzgadniane bez konieczności zmiany tego stanowiska.

               Artykuł 3

               Niniejsza decyzja skierowana jest do państw członkowskich.

               Sporządzono w Brukseli dnia […] r.

                     W imieniu Rady

                     Przewodniczący

                     (1)

                        Austria (ratyfikowała ją w dniu 11/6/1975), Belgia (ratyfikowała ją w dniu 30/12/1977), Bułgaria (ratyfikowała ją w dniu 12/5/1995), Chorwacja (ratyfikowała ją w dniu 3/8/1992), Cypr (ratyfikował ją w dniu 5/9/2003), Dania (ratyfikowała ją w dniu 30/12/1977), Estonia (ratyfikowała ją w dniu 3/5/1993), Finlandia (ratyfikowała ją w dniu 16/2/1999), Francja (ratyfikowała ją w dniu 9/1/1978), Grecja (ratyfikowała ją w dniu 11/1/1974), Hiszpania (ratyfikowała ją w dniu 3/1/1993), Irlandia (ratyfikowała ją w dniu 28/8/1979), Litwa (ratyfikowała ją w dniu 3/6/1998), Luksemburg (ratyfikował ją w dniu 30/12/1977), Łotwa (ratyfikowała ją w dniu 14/1/1994), Malta (ratyfikowała ją w dniu 24/9/2004), Niderlandy (ratyfikowały ją w dniu 30/12/1977), Niemcy (ratyfikowały ją w dniu 9/7/1975), Polska (ratyfikowała ją w dniu 14/7/1992), Portugalia (ratyfikowała ją w dniu 20/9/1973), Republika Czeska (ratyfikowała ją w dniu 22/6/1993), Rumunia (ratyfikowała ją w dniu 8/12/1994), Słowacja (ratyfikowała ją w dniu 28/5/1993), Słowenia (ratyfikowała ją w dniu 6/8/1993), Szwecja (ratyfikowała ją w dniu 24/8/1973), Węgry ratyfikowały ją w dniu 22/10/1999), Włochy (ratyfikowały ją w dniu 28/12/1978), Zjednoczone Królestwo (ratyfikowało ją w dniu 4/1/1978).

                     (2)

                        Rozporządzenie (UE) nr 561/2006 Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do transportu drogowego oraz zmieniające rozporządzenia Rady (EWG) nr 3821/85 i (WE) 2135/98, jak również uchylające rozporządzenie Rady (EWG) nr 3820/85 (Dz.U. L 102 z 11.4.2006, s. 1).

                     (3)

                        Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w transporcie drogowym i uchylające rozporządzenie Rady (EWG) nr 3821/85 w sprawie urządzeń rejestrujących stosowanych w transporcie drogowym oraz zmieniające rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do transportu drogowego (Dz.U. L 60 z 28.2.2014, s. 1).

                     (4)

                        Rozporządzenie wykonawcze Komisji (UE) 2016/68 z dnia 21 stycznia 2016 r. w sprawie wspólnych procedur i specyfikacji koniecznych do wzajemnego połączenia elektronicznych rejestrów kart kierowcy (Dz.U. L 15 z 22.1.2016, s. 51).

                     (5)

                        Stanowisko UE przyjęte decyzją Rady (UE) 2016/1877 z dnia 17 października 2016 r., przedłożone sekretariatowi AETR przez Republikę Słowacką.

                     (6)

                        Wyrok Trybunału Sprawiedliwości z dnia 7 października 2014 r., C-399/12, Niemcy przeciwko Radzie, ECLI:EU:C:2014:2258, pkt 64.

                     (7)

                        Wyrok Trybunału Sprawiedliwości z dnia 7 października 2014 r. w sprawie C-399/12 Niemcy przeciwko Radzie, ECLI:EU:C 2014, 2258, pkt 61–64.

                     (8)

                        Rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady z dnia 15 marca 2006 r. w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do transportu drogowego oraz zmieniające rozporządzenia Rady (EWG) nr 3821/85 i (WE) 2135/98, jak również uchylające rozporządzenie Rady (EWG) nr 3820/85 (Dz.U. L 102 z 11.4.2006, s. 1).

                     (9)

                        Rozporządzenie Parlamentu Europejskiego i Rady (UE) nr 165/2014 z dnia 4 lutego 2014 r. w sprawie tachografów stosowanych w transporcie drogowym oraz zmieniające rozporządzenie (WE) nr 561/2006 Parlamentu Europejskiego i Rady w sprawie harmonizacji niektórych przepisów socjalnych odnoszących się do transportu drogowego (Dz.U. L 60 z 28.2.2014, s. 1).

                     (10)

                        Rozporządzenie Rady (EWG) nr 2829/77 z dnia 12 grudnia 1977 r. w sprawie wprowadzenia w życie Umowy europejskiej dotyczącej pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe (AETR), (Dz.U. L 334 z 24.12.1977, s. 11).

    ---documentbreak---

               KOMISJA EUROPEJSKA
            Bruksela, dnia 2.10.2018
            COM(2018) 664 final
            ZAŁĄCZNIK
            do wniosku dotyczącego
            DECYZJI RADY
            dotyczącej stanowiska, jakie ma zostać zajęte w imieniu Unii Europejskiej w grupie ekspertów ds. Umowy europejskiej dotyczącej pracy załóg pojazdów wykonujących międzynarodowe przewozy drogowe Europejskiej Komisji Gospodarczej ONZ

               Dodatek 4

               Specyfikacje Tachonet

               1.Zakres i cel

               1.1.Niniejszy dodatek określa warunki dotyczące połączenia umawiających się stron AETR z systemem Tachonet za pośrednictwem platformy eDelivery.

               1.2.Umawiające się Strony łączące się z systemem Tachonet za pośrednictwem eDelivery przestrzegają przepisów określonych w niniejszym dodatku.

               2.Definicje

               a)„Umawiająca się Strona” lub „Strona” oznacza Umawiającą się Stronę AETR;

               b)„eDelivery” oznacza opracowaną przez Komisję usługę umożliwiającą przesyłanie danych między stronami trzecimi drogą elektroniczną, zapewniającą dowody związane z posługiwaniem się przesyłanymi danymi, w tym dowód wysłania i otrzymania danych, oraz chroniącą przesyłane dane przed ryzykiem jakiejkolwiek nieupoważnionej zmiany;

               c)„Tachonet” oznacza system elektronicznej wymiany informacji dotyczących kart kierowcy między |Umawiającymi się Stronami, o którym mowa w art. 31 ust. 2 rozporządzenia (UE) nr 165/2014;

               d)„węzeł centralny” oznacza system informacyjny umożliwiający przekazywanie komunikatów Tachonet między Stronami zgłaszającymi zapytanie i Stronami udzielającymi odpowiedzi na zapytanie;

               e)„Strona zgłaszająca zapytanie” oznacza Umawiającą się Stronę wysyłającą zapytanie lub zgłoszenie Tachonet, które są następnie kierowane do odpowiedniej Strony udzielającej odpowiedzi na zapytanie za pośrednictwem węzła centralnego;

               f)„Strona udzielająca odpowiedzi na zapytanie” oznacza Stronę, do której skierowane jest zapytanie lub zgłoszenie Tachonet;

               g)„organ wydający karty” lub „CIA” oznacza podmiot upoważniony przez Umawiającą się Stronę do wydawania kart do tachografu i zarządzania nimi.

               3.Obowiązki ogólne

               3.1.Żadna z Umawiających się Stron nie może zawierać umów na dostęp do systemu Tachonet w imieniu innej Strony lub w jakikolwiek inny sposób reprezentować drugiej Umawiającej się Strony na podstawie niniejszego dodatku. Żadna z Umawiających się Stron nie może działać jako podwykonawca drugiej Umawiającej się Strony przy prowadzeniu działań, o których mowa w niniejszym dodatku.

               3.2.Umawiające się Strony zapewniają dostęp do swoich krajowych rejestrów kart kierowcy za pośrednictwem Tachonet, w sposób i na poziomie usług określonych w poddodatku 4.6.

               3.3.Umawiające się Strony niezwłocznie informują się nawzajem, jeśli zauważą w swoim obszarze odpowiedzialności zakłócenia lub błędy, które mogą zagrozić realizacji normalnego działania systemu Tachonet.

               3.4.Każda ze Stron wyznacza osoby do kontaktów w sprawie Tachonet dla sekretariatu AETR. Każda zmiana punktów kontaktowych musi zostać zgłoszona na piśmie sekretariatowi AETR.

               4.Testy dotyczące połączenia z systemem Tachonet

               4.1.Połączenie Umawiającej się Strony z systemem Tachonet uznaje się za ustanowione po wykonaniu z wynikiem pozytywnym testów połączenia, integracji i funkcjonowania zgodnie z instrukcjami Komisji Europejskiej i pod jej nadzorem.

               4.2.W przypadku niepowodzenia testów wstępnych Komisja Europejska może czasowo wstrzymać etap testowania. Testy wznawia się po poinformowaniu Komisji Europejskiej przez Umawiającą się Stronę o przyjęciu koniecznych udoskonaleń technicznych na szczeblu krajowym, pozwalających na pomyślne przeprowadzenie testów wstępnych.

               4.3.Maksymalny czas trwania tych testów wstępnych wynosi sześć miesięcy.

               5.Architektura zaufania

               5.1.Architektura zaufania systemu Tachonet musi zapewniać poufność, integralność i niezaprzeczalność komunikatów Tachonet.

               5.2.Architektura zaufania systemu Tachonet musi opierać się na usłudze infrastruktury klucza publicznego (PKI) utworzonej przez Komisję Europejską, której wymogi są określone w poddodatkach 4.8 i 4.9.

               5.3.Następujące podmioty tworzą architekturę zaufania systemu Tachonet:

               a)centrum certyfikacji odpowiedzialne za generowanie certyfikatów elektronicznych wydawanych organom krajowym Umawiających się Stron przez organ rejestrujący (za pośrednictwem zaufanych kurierów wyznaczonych przez te organy), a także za utworzenie infrastruktury technicznej w zakresie wydawania, unieważniania i odnawiania certyfikatów elektronicznych;

               b)właściciel domeny odpowiedzialny za funkcjonowanie węzła centralnego, o którym mowa w poddodatku 4.1, oraz zatwierdzanie i koordynację architektury zaufania systemu Tachonet;

               c)organ rejestrujący odpowiedzialny za rejestrację i zatwierdzanie wniosków o wydanie, unieważnienie i odnowienie certyfikatów elektronicznych oraz weryfikację tożsamości zaufanych kurierów;

               d)zaufany kurier, wyznaczony przez organy krajowe, odpowiedzialny za przekazanie klucza publicznego organowi rejestrującemu i uzyskanie odpowiedniego certyfikatu generowanego przez centrum certyfikacji;

               e)organ krajowy Umawiającej się Strony, który:

               (i)generuje klucze prywatne i odpowiadające im klucze publiczne, które mają być zawarte w certyfikatach generowanych przez centrum certyfikacji;

               (ii)
                     zgłasza centrum certyfikacji zapotrzebowanie na wydanie certyfikatów elektronicznych;

               (iii)
                     wyznacza zaufanego kuriera.

               5.4.Centrum certyfikacji oraz organ rejestrujący wyznaczane są przez Komisję Europejską.

               5.5.Każda z Umawiających się Stron łączących się z systemem Tachonet musi poprosić o wydanie certyfikatu elektronicznego zgodnie z poddodatkiem 4.9, aby podpisywać i szyfrować komunikaty Tachonet.

               5.6.Certyfikat może zostać cofnięty zgodnie z poddodatkiem 4.9.

               6.Ochrona i poufność danych

               6.1.Strony, zgodnie z przepisami o ochronie danych na szczeblu międzynarodowym i krajowym, w szczególności z Konwencją o ochronie osób w związku z automatycznym przetwarzaniem danych osobowych, przyjmują wszelkie niezbędne środki techniczne i organizacyjne w celu zapewnienia bezpieczeństwa danych w systemie Tachonet i zapobieżenia zmianie bądź utracie lub nieuprawnionemu przetwarzaniu lub dostępowi do tych danych (w szczególności gwarantując autentyczność, poufność, identyfikowalność, integralność, dostępność, niezaprzeczalność i bezpieczeństwo komunikatów).

               6.2.Każda ze stron chroni swoje własne krajowe systemy przed nielegalnym używaniem, kodami złośliwymi, wirusami komputerowymi, zainfekowaniem komputera, naruszeniami i nielegalną ingerencją w dane oraz innymi podobnymi działaniami przez osoby trzecie. Strony zgadzają się wykorzystywać komercyjnie uzasadnione rozwiązania w celu uniknięcia przekazywania wszelkich wirusów, bomb zegarowych, robaków komputerowych lub podobnych zagrożeń czy też procedur programowania komputerowego, które mogą kolidować z systemami komputerowymi drugiej Strony.

               7.Koszty

               7.1.Umawiające się Strony ponoszą swoje własne koszty rozwoju i eksploatacji w związku ze swoimi własnymi systemami danych i procedurami, stosownie do wymogów, w celu wypełnienia zobowiązań wynikających z niniejszego dodatku.

               7.2.Usługi wyszczególnione w poddodatku 4.1, świadczone przez węzeł centralny, są bezpłatne.

               8.Podwykonawstwo

               8.1.Strony mogą podzlecać świadczenie wszelkich usług, za które są odpowiedzialne zgodnie z niniejszym dodatkiem.

               8.2.Takie podwykonawstwo nie zwalnia Strony z odpowiedzialności wynikającej z niniejszego dodatku, w tym odpowiedzialności za odpowiedni poziom usług zgodnie z poddodatkiem 4.6.

               Poddodatek 4.1

               Ogólne aspekty systemu Tachonet

               1.Ogólny opis

               Tachonet jest systemem elektronicznej wymiany informacji dotyczących kart kierowcy między Umawiającymi się Stronami AETR. Tachonet przekierowuje zapytania Stron zgłaszających zapytanie Stronom udzielającym odpowiedzi, jak również odpowiedzi tych ostatnich tym pierwszym. Umawiające się Strony uczestniczące w systemie Tachonet muszą podłączyć do niego swoje krajowe rejestry kart kierowcy.

               2.Architektura

               System informacyjny Tachonet obejmuje następujące części:

               2.1.Węzeł centralny, który umożliwia przyjęcie zapytania od Strony zgłaszającej zapytanie, dokonania jego zatwierdzenia i przetworzenia poprzez przekazanie go Stronom udzielającym odpowiedzi na zapytanie. Węzeł centralny czeka na odpowiedź poszczególnych Stron udzielających odpowiedzi na zapytanie, dokonuje konsolidacji wszystkich odpowiedzi i przekazuje skonsolidowaną odpowiedź Stronie zgłaszającej zapytanie.

               2.2.Systemy krajowe Stron, które muszą być wyposażone w interfejs umożliwiający zarówno wysyłanie zapytań, jak i odbieranie odnośnych odpowiedzi. Systemy krajowe mogą wykorzystywać oprogramowanie zamknięte lub komercyjne do przekazywania i odbierania komunikatów z węzła centralnego.

               3.Zarządzanie

               3.1.Węzłem centralnym zarządza Komisja Europejska, która jest odpowiedzialna za eksploatację techniczną i utrzymanie węzła centralnego.

               3.2.W węźle centralnym nie można przechowywać przez okres przekraczający sześć miesięcy danych innych niż dane dotyczące logowania i dane statystyczne określone w poddodatku 4.7.

               3.3.Węzeł centralny nie może umożliwiać dostępu do danych osobowych, z wyjątkiem dostępu dla upoważnionych pracowników Komisji Europejskiej, jeżeli jest to konieczne do celów monitorowania, utrzymania i usuwania usterek.

               3.4.Każda z Umawiających się Stron jest odpowiedzialna za:

               3.4.1.utworzenie swoich systemów krajowych i zarządzanie nimi, z uwzględnieniem interfejsu z węzłem centralnym;

               3.4.2.instalację i utrzymanie swoich systemów krajowych, zarówno sprzętu, jak i oprogramowania zamkniętego lub komercyjnego;

               3.4.3.prawidłowo funkcjonującą interoperacyjność swoich systemów krajowych i węzła centralnego, w tym za zarządzanie komunikatami o błędach otrzymywanymi z węzła centralnego;

               3.4.4.wprowadzanie wszelkich środków w celu zapewnienia poufności, integralności i dostępności informacji;

               3.4.5.działanie systemów krajowych zgodnie z poziomami obsługi określonymi w poddodatku 4.6.

               Poddodatek 4.2

               Funkcje systemu Tachonet

               1.Za pomocą systemu informacyjnego Tachonet zapewnia się następujące funkcje:

               1.1.Check Issued Cards (CIC) (kontrola wydanych kart): umożliwia Stronie zgłaszającej zapytanie wysłanie zapytania w sprawie kontroli wydanych kart (Check Issued Cards Request) do jednej lub wszystkich Stron udzielających odpowiedzi na zapytanie w celu ustalenia, czy osoba ubiegająca się o kartę posiada już kartę kierowcy wydaną przez Strony udzielające odpowiedzi na zapytanie. Strony udzielające odpowiedzi na zapytanie muszą odpowiedzieć, przesyłając odpowiedź w sprawie kontroli wydanych kart (Check Issued Cards Response).

               1.2.Check Card Status (CCS) (kontrola statusu karty): umożliwia Stronie zgłaszającej zapytanie zwrócenie się do Strony udzielającej odpowiedzi o podanie szczegółowych informacji dotyczących karty wydanej przez tę ostatnią poprzez wysłanie zapytania w sprawie kontroli statusu karty (Check Card Status Request). Strona udzielająca odpowiedzi odpowiada na zapytanie, przesyłając odpowiedź w sprawie kontroli statusu karty (Check Card Status Response).

               1.3.Modify Card Status (MCS) (modyfikacja statusu karty): umożliwia Stronie zgłaszającej zapytanie – za pośrednictwem zapytania w sprawie modyfikacji statusu karty (Modify Card Status Request) – powiadomienie Strony udzielającej odpowiedzi, że status karty wydanej przez to drugie państwo uległ modyfikacji. Strona udzielająca odpowiedzi musi odpowiedzieć za pomocą potwierdzenia modyfikacji statusu karty (Modify Card Status Acknowledgement).

               1.4.Issued Card Driving License (ICDL) (wydanie karty na podstawie prawa jazdy): umożliwia Stronie zgłaszającej zapytanie – za pośrednictwem zapytania w sprawie wydania karty na podstawie prawa jazdy (Issued Card Driving Licence Request) – zawiadomienie Strony udzielającej odpowiedzi na zapytanie, że karta została wydana przez to pierwsze państwo na podstawie prawa jazdy wydanego przez to drugie państwo. Strona udzielająca odpowiedzi na zapytanie musi odpowiedzieć za pomocą odpowiedzi w sprawie wydania karty na podstawie prawa jazdy (Issued Card Driving Licence Response).

               2.Należy uwzględnić inne rodzaje komunikatów uznanych za właściwe dla sprawnego funkcjonowania systemu Tachonet, np. powiadomienia o błędach.

               3.Systemy krajowe muszą rozpoznawać statusy kart wymienione w tabeli 1 w przypadku użycia którejkolwiek z funkcji opisanych w pkt 1. Jednakże Strony nie są zobowiązane do wdrożenia procedury administracyjnej, w której wykorzystuje się wszystkie wymienione statusy.

               4.W przypadku gdy Strona otrzyma odpowiedź lub powiadomienie o statusie, który nie jest stosowany w jego procedurach administracyjnych, system krajowy przekłada status odebranego komunikatu na odpowiednią wartość w danej procedurze. Komunikat nie może zostać odrzucony przez Stronę udzielającą odpowiedzi na zapytanie, jeżeli status komunikatu jest wymieniony w tabeli 1.

               5.Statusu karty wymienionego w tabeli 1 nie można wykorzystywać w celu ustalenia, czy karta kierowcy uprawnia do prowadzenia pojazdu. W przypadku gdy Strona zgłasza zapytanie do rejestru organu krajowego wydającego kartę za pośrednictwem funkcji CCS, odpowiedź musi zawierać specjalne pole „uprawnia do prowadzenia pojazdu” (valid for driving). Krajowe procedury administracyjne muszą być takie, aby odpowiedzi przy użyciu CCS zawsze obejmowały odpowiednią wartość pola „uprawnia do prowadzenia pojazdu” (valid for driving).

               Tabela 1

               Statusy kart

                        Card Status (Status karty)

                        Definicja

                        Application (wniosek)

                        CIA otrzymał wniosek o wydanie karty kierowcy. Przedmiotowe informacje zostały zarejestrowane i zachowane w bazie danych, a także wygenerowano klucze wyszukiwania.

                        Approved (zatwierdzony)

                        CIA zatwierdził wniosek dotyczący karty do tachografu.

                        Rejected (odrzucony)

                        CIA nie zatwierdził wniosku.

                        Personalised (spersonalizowana)

                        Karta do tachografu została spersonalizowana.

                        Dispatched (wysłana)

                        Organ krajowy wysłał kartę kierowcy do odpowiedniego kierowcy lub do odpowiedniej agencji dostarczającej.

                        Handed Over (przekazana)

                        Organ krajowy przekazał kartę kierowcy odpowiedniemu kierowcy.

                        Confiscated (skonfiskowana)

                        Karta kierowcy została odebrana kierowcy przez właściwy organ.

                        Suspended (zawieszona)

                        Karta kierowcy została tymczasowo odebrana kierowcy.

                        Withdrawn (wycofana)

                        CIA podjął decyzję o wycofaniu karty kierowcy. Karta została ostatecznie unieważniona.

                        Surrendered (zwrócona)

                        Karta do tachografu została zwrócona CIA i uznana za niepotrzebną.

                        Lost (zagubiona)

                        CIA zgłoszono zaginięcie karty do tachografu.

                        Stolen (skradziona)

                        CIA zgłoszono kradzież karty do tachografu. Skradzioną kartę uznaje się za zagubioną.

                        Malfunctioning (niesprawna)

                        CIA zgłoszono niesprawność karty do tachografu.

                        Expired (wygasła)

                        Wygasł okres ważności karty do tachografu.

                        Replaced (zastąpiona)

                        Karta do tachografu zgłoszona jako zagubiona, skradziona lub niesprawna została zastąpiona nową kartą. Dane na nowej karcie są takie same, z wyjątkiem indeksu zastąpienia numeru karty, który został zwiększony o jeden.

                        Renewed (odświeżona)

                        Karta do tachografu została odświeżona z powodu zmiany danych administracyjnych lub zbliżającego się końca okresu ważności karty. Numer nowej karty jest taki sam, z wyjątkiem indeksu odświeżenia numeru karty, który został zwiększony o jeden.

                        In Exchange (w trakcie wymiany)

                        CIA, który wydał kartę kierowcy, otrzymał powiadomienie, że rozpoczęła się procedura wymiany danej karty kierowcy na kartę kierowcy wydaną przez CIA innej Strony.

                        Exchanged (wymieniona)

                        CIA, który wydał kartę kierowcy, otrzymał powiadomienie, że zakończyła się procedura wymiany danej karty kierowcy na kartę kierowcy wydaną przez CIA innej Strony.

               Poddodatek 4.3

               Przepisy dotyczące komunikatów Tachonet

               1.Ogólne wymogi techniczne

               1.1.Węzeł centralny zapewnia zarówno interfejsy synchroniczne, jak i asynchroniczne na potrzeby wymiany komunikatów. Strony mogą wybrać najodpowiedniejszą technologię interfejsu na potrzeby połączenia z własnymi aplikacjami.

               1.2.Wszystkie komunikaty wymieniane między węzłem centralnym a systemami krajowymi muszą być zakodowane w UTF-8.

               1.3.Systemy krajowe muszą mieć zdolność do odbioru i przetwarzania komunikatów zawierających litery alfabetu greckiego i cyrylicy.

               2.Struktura komunikatów XML i definicja schematu (XSD)

               2.1.Ogólna struktura komunikatów XML musi odpowiadać formatowi zdefiniowanemu w schematach XSD zainstalowanych w węźle centralnym.

               2.2.Węzeł centralny i systemy krajowe muszą przesyłać i odbierać komunikaty zgodne ze schematem XSD komunikatu.

               2.3.Systemy krajowe muszą mieć zdolność do wysyłania, odbierania i przetwarzania wszystkich komunikatów odnoszących się do którejkolwiek z funkcji określonych w poddodatku 4.2.

               2.4.Komunikaty XML muszą spełniać co najmniej minimalne wymogi określone w tabeli 2.

               Tabela 2

               Minimalne wymogi dotyczące treści komunikatów XML

                        Wspólny nagłówek

                        Informacje obowiązkowe

                        Version (Wersja)

                        Oficjalna wersja specyfikacji XML jest określana poprzez przestrzeń nazw określoną w komunikacie XSD i w atrybucie version elementu nagłówka każdego komunikatu XML. Numer wersji („n.m”) definiuje się jako ustaloną wartość dla każdej wersji pliku definicji schematu XML (xsd).

                        Tak

                        Test Identifier (Identyfikator testowy)

                        Nieobowiązkowy identyfikator dla testu. Inicjator testu uzupełnia identyfikator, a wszyscy uczestnicy przepływu pracy przesyłają/odsyłają ten sam identyfikator. W produkcji należy go pominąć i nie wykorzystywać go, jeżeli zostanie dostarczony.

                        Nie

                        Technical identifier (Identyfikator techniczny)

                        UUID jednoznacznie identyfikujący każdy indywidualny komunikat. Nadawca generuje UUID i uzupełnia ten atrybut. Dane te nie są wykorzystywane w funkcjach użytkowych.

                        Tak

                        Workflow Identifier (Identyfikator przepływu pracy)

                        Identyfikator przepływu pracy jest UUID i powinien zostać wygenerowany przez Stronę zgłaszającą zapytanie. Identyfikator ten jest następnie wykorzystywany we wszystkich komunikatach do celów korelacji przepływu pracy.

                        Tak

                        Sent At (Czas wysłania)

                        Data i godzina (UTC) wysłania komunikatu.

                        Tak

                        Timeout (Czas oczekiwania)

                        Jest to opcjonalny atrybut daty i godziny (w formacie UTC). Wartość ta będzie ustalona jedynie przez węzeł centralny na potrzeby przekazywanych zapytań. Umożliwi to powiadomienie Strony udzielającej odpowiedzi na zapytanie o tym, kiedy nastąpi przekroczenie czasu oczekiwania dla zapytania. Wartość ta nie jest konieczna w MS2TCN_<x>_Req i wszystkich komunikatach odpowiedzi. Wartość ta nie jest obowiązkowa, dzięki czemu ta sama definicja nagłówka może być używana dla wszystkich typów komunikatów bez względu na to, czy wymagany jest atrybut timeoutValue.

                        Nie

                        From (Od)

                        Kod ISO 3166-1 Alpha 2 Strony wysyłającej komunikat lub „UE”.

                        Tak

                        To (Do)

                        Kod ISO 3166-1 Alpha 2 Strony, do której komunikat jest wysyłany, lub „UE”.

                        Tak

               Poddodatek 4.4

               Transliteracja i usługi NYSIIS (system identyfikacyjno-informacyjny stanu Nowy Jork)

               1.Algorytm NYSIIS wdrożony w węźle centralnym jest wykorzystywany do kodowania nazwisk wszystkich kierowców w rejestrze krajowym.

               2.Przy wyszukiwaniu karty za pomocą funkcji CIC należy używać kluczy NYSIIS jako podstawowego mechanizmu wyszukiwania.

               3.Ponadto Strony mogą stosować algorytm niestandardowy w celu uzyskania dodatkowych wyników.

               4.Wyniki wyszukiwania muszą wskazywać mechanizm wyszukiwania, który został użyty do znalezienia zapisu – NYSIIS albo niestandardowy.

               5.Jeżeli Strona zdecyduje się na rejestrowanie powiadomień ICDL, wówczas klucze NYSIIS zawarte w powiadomieniu muszą zostać zapisane jako część danych ICDL. Przy wyszukiwaniu danych ICDL Strona musi korzystać z kluczy NYSIIS dla nazwy/nazwiska wnioskodawcy.

               Poddodatek 4.5

               Wymogi w zakresie bezpieczeństwa

               1.HTTPS wykorzystuje się do wymiany komunikatów między węzłem centralnym a systemami krajowymi.

               2.Systemy krajowe używają certyfikatów elektronicznych, o których mowa w poddodatkach 4.8 i 4.9, na potrzeby zabezpieczenia przesyłania komunikatów między systemem krajowym a węzłem centralnym.

               3.W systemach krajowych należy wdrożyć jako minimum certyfikaty wykorzystujące algorytm skrótu podpisu SHA-2 (SHA-256) oraz klucz publiczny o długości 2048 bitów.

               Poddodatek 4.6

               Poziomy usług

               1.Systemy krajowe muszą zapewniać następujące minimalne poziomy usług:

               1.1.Muszą być dostępne 24 godziny na dobę, 7 dni w tygodniu.

               1.2.Ich dostępność musi być monitorowana za pomocą komunikatu typu HEARTBEAT wysyłanego z węzła centralnego.

               1.3.Ich wskaźnik dostępności musi wynosić 98 % zgodnie z poniższą tabelą (dane liczbowe zaokrąglono do najbliższej jednostki):

                        Dostępność na poziomie

                        oznacza niedostępność

                        dziennie

                        miesięcznie

                        rocznie

                        98 %

                        0,5 godz.

                        15 godz.

                        7,5 dnia

               Zachęcając Strony do przestrzegania wskaźnika dostępności dziennej, uznaje się jednak, że pewne niezbędne działania, takie jak utrzymanie systemu, wymagają wyłączenia systemu na czas dłuższy niż 30 minut. Jednakże miesięczne i roczne wskaźniki dostępności pozostają obowiązkowe.

               1.4.Systemy krajowe muszą odpowiadać na minimum 98 % zapytań przesyłanych im w ciągu jednego miesiąca kalendarzowego.

               1.5.Systemy krajowe muszą dostarczać odpowiedź na zapytania w ciągu 10 sekund.

               1.6.Globalny czas oczekiwania dla zapytania (czas, w którym osoba przedstawiająca zapytanie może czekać na odpowiedź) nie może przekraczać 20 sekund.

               1.7.Systemy krajowe muszą być w stanie obsługiwać 6 komunikatów na sekundę.

               1.8.Systemy krajowe nie mogą przesyłać zapytań do węzła sieci Tachonet z prędkością przekraczającą 2 zapytania na sekundę.

               1.9.Każdy system krajowy musi być w stanie poradzić sobie z potencjalnymi problemami technicznymi węzła centralnego lub systemów krajowych innych Stron. Problemy te obejmują między innymi:

               a)utratę połączenia z węzłem centralnym;

               b)brak odpowiedzi na zapytanie;

               c)otrzymanie odpowiedzi po upływie czasu oczekiwania na komunikat;

               d)otrzymanie niezamówionych komunikatów;

               e)otrzymanie nieważnych komunikatów.

               2.Węzeł centralny musi:

               2.1.Osiągać wskaźnik dostępności na poziomie 98 %.

               2.2.Zapewniać krajowym systemom powiadamianie o wszelkich błędach za pośrednictwem komunikatu odpowiedzi albo za pośrednictwem specjalnego komunikatu o błędzie. Systemy krajowe muszą natomiast odbierać takie specjalne komunikaty o błędach i posiadać eskalacyjny przepływ pracy w celu podjęcia wszelkich właściwych działań, aby skorygować zgłoszony błąd.

               3.Utrzymanie

               Strony powiadamiają za pośrednictwem aplikacji internetowej pozostałe Strony oraz Komisję Europejską o wszelkich rutynowych czynnościach serwisowych, najpóźniej na tydzień przed rozpoczęciem tych czynności, jeżeli jest to technicznie możliwe.

               Poddodatek 4.7

               Rejestr zdarzeń i statystyki dotyczące danych gromadzonych w węźle centralnym

               1.W celu zapewnienia prywatności dane przekazywane do celów statystycznych mają charakter anonimowy. Dane identyfikujące konkretną kartę, konkretnego kierowcę lub konkretne prawo jazdy nie mogą być dostępne do celów statystycznych.

               2.Rejestr zdarzeń stanowi zapis wszystkich operacji na potrzeby monitorowania i diagnostyki oraz umożliwia wygenerowanie statystyk dotyczących tych operacji.

               3.Dane osobowe nie mogą być przechowywane w dziennikach dłużej niż 6 miesięcy. Informacje statystyczne są przechowywane bezterminowo.

               4.Dane statystyczne wykorzystywane do celów sprawozdawczości obejmują:

               a)Stronę zgłaszającą zapytanie;

               b)Stronę udzielającą odpowiedzi na zapytanie;

               c)rodzaj komunikatu;

               d)kod statusu odpowiedzi;

               e)daty i godziny komunikatów;

               f)czas odpowiedzi.

               Poddodatek 4.8

               Przepisy ogólne dotyczące elektronicznych kluczy i certyfikatów związanych z systemem Tachonet

               1.Dyrekcja Generalna ds. Informatyki Komisji Europejskiej (DIGIT) udostępnia usługę PKI
                  1
                (zwaną dalej „usługą infrastruktury klucza publicznego CEF”) Umawiającym się Stronom AETR łączącym się z systemem Tachonet (zwanym dalej „organami krajowymi”) poprzez platformę eDelivery.

               2.Procedura wnioskowania o wydanie i unieważnienie certyfikatów elektronicznych oraz szczegółowe warunki ich stosowania określone są w dodatku.

               3.Wykorzystanie certyfikatów:

               3.1.Po wydaniu certyfikatu organ krajowy
                  2
                korzysta z niego wyłącznie w ramach systemu Tachonet. Certyfikat może być stosowany do:

               a)uwierzytelnienia pochodzenia danych;

               b)zaszyfrowania danych;

               c)zapewnienia wykrywania naruszeń integralności danych.

               3.2.Zabrania się jakiegokolwiek wykorzystania bez wyraźnego zezwolenia w ramach dozwolonych zastosowań certyfikatu.

               4.Umawiające się Strony:

               a)chronią swoje klucze prywatne przed nieuprawnionym użyciem;

               b)powstrzymują się od przekazywania lub ujawniania swoich kluczy prywatnych osobom trzecim nawet jako przedstawicielom;

               c)zapewniają poufność, integralność i dostępność kluczy prywatnych wygenerowanych, przechowywanych i używanych na potrzeby systemu Tachonet;

               d)powstrzymują się od dalszego korzystania z klucza prywatnego po upływie okresu ważności lub unieważnieniu certyfikatu, z wyjątkiem w celu przeglądania zaszyfrowanych danych (np. odszyfrowywania wiadomości przekazywanych drogą elektroniczną). Klucze, których ważność wygasła, są niszczone lub przechowywane w sposób uniemożliwiający ich używanie;

               e)dostarczają organowi rejestrującemu dane identyfikacyjne upoważnionych przedstawicieli, którzy są uprawnieni do występowania o unieważnienie certyfikatów wydanych danej organizacji (wnioski o unieważnienie rejestracji zawierają również wniosek o stwierdzenie wygaśnięcia hasła oraz szczegółowe informacje na temat zdarzeń, które prowadzą do unieważnienia certyfikatów);

               f)zapobiegają niewłaściwemu wykorzystywaniu kluczy prywatnych, poprzez zwrócenie się o unieważnienie powiązanego certyfikatu klucza publicznego w przypadku narażenia na szwank bezpieczeństwa klucza prywatnego lub danych dotyczących aktywacji klucza prywatnego;

               g)ponoszą odpowiedzialność i są zobowiązane do złożenia wniosku o unieważnienie certyfikatu w sytuacjach określonych w polityce certyfikacji i w oświadczeniu na temat praktyk dotyczących certyfikacji (CPS) centrum certyfikacji;

               h)bezzwłocznie powiadamiają organ rejestrujący o utracie, kradzieży lub potencjalnym narażeniu na szwank jakichkolwiek kluczy AETR stosowanych w ramach systemu Tachonet.

               5.Zobowiązania

               Bez uszczerbku dla odpowiedzialności Komisji Europejskiej w przypadku naruszenia jakichkolwiek wymogów ustanowionych w mającym zastosowanie prawie krajowym lub w odniesieniu do odpowiedzialności za kwestie, które na mocy tego prawa nie mogą zostać wyłączone, Komisja Europejska nie ponosi odpowiedzialności w odniesieniu do:

               a)treści certyfikatu, za którą jest odpowiedzialny wyłącznie właściciel certyfikatu. Sprawdzenie prawidłowości treści certyfikatu jest obowiązkiem właściciela certyfikatu;

               b)wykorzystania certyfikatu przez jego właściciela.

               Poddodatek 4.9

               Opis usługi PKI dla systemu Tachonet

               1.Wprowadzenie

               Infrastruktura klucza publicznego (PKI) jest zbiorem ról, polityk, procedur i systemów niezbędnych do tworzenia certyfikatów elektronicznych, zarządzania nimi, ich dystrybucji i unieważniania
                  3
               . Usługa infrastruktury klucza publicznego CEF platformy eDelivery umożliwia wydawanie certyfikatów elektronicznych i zarządzanie nimi w celu zapewnienia poufności, integralności i niezaprzeczalności informacji wymienianych między punktami dostępu.

               Usługa PKI platformy eDelivery opiera się na Trust Center Services TeleSec Shared Business CA (centrum certyfikacji), do którego zastosowanie ma polityka certyfikacji (CP) / oświadczenie na temat praktyk dotyczących certyfikacji (CPS) TeleSec Shared-Business-CA T-Systems International GmbH
                  4
               .

               Usługa infrastruktury klucza publicznego wydaje certyfikaty odpowiednie do zabezpieczenia różnych procesów biznesowych wewnątrz i na zewnątrz przedsiębiorstw, organizacji, organów publicznych i instytucji, którym są one potrzebne do zapewnienia średniego poziomu ochrony w celu udowodnienia autentyczności, integralności i wiarygodności podmiotu końcowego.

               2.Proces wnioskowania o wydanie certyfikatu

               2.1.Role i obowiązki

               2.1.1.„Organizacja” lub „organ krajowy” występujący o certyfikat

               2.1.1.1.Organ krajowy zwraca się o wydanie certyfikatów w ramach Tachonet.

               2.1.1.2.Organ krajowy:

               a)zwraca się o wydanie certyfikatów przy użyciu usługi infrastruktury klucza publicznego CEF;

               b)generuje klucze prywatne i odpowiadające im klucze publiczne, które mają być zawarte w certyfikatach wydanych przez centrum certyfikacji;

               c)pobiera certyfikat po jego zatwierdzeniu;

               d)podpisuje i odsyła do organu rejestrującego:

               (i)formularz identyfikacyjny z danymi osób wyznaczonych do kontaktów i zaufanych kurierów,

               (ii)podpisane indywidualne pełnomocnictwo
                  5
               .

               2.1.2.Zaufany kurier

               2.1.2.1.Organ krajowy wyznacza zaufanego kuriera.

               2.1.2.2.Zaufany kurier:

               a)przekazuje klucz publiczny organowi rejestrującemu w trakcie bezpośredniej identyfikacji i procesu rejestracji;

               b)uzyskuje odpowiedni certyfikat od organu rejestrującego.

               2.1.3.Właściciel domeny

               2.1.3.1.Właścicielem domeny jest DG MOVE.

               2.1.3.2.Właściciel domeny:

               a)zatwierdza i koordynuje sieć Tachonet i architekturę zaufania systemu Tachonet, w tym zatwierdzanie procedur wydawania certyfikatów;

               b)obsługuje węzeł centralny Tachonet oraz koordynuje działania Stron dotyczące funkcjonowania systemu Tachonet;

               c)przeprowadza, wraz z organami krajowymi, testy łączenia się z systemem Tachonet.

               2.1.4.Organ rejestrujący

               2.1.4.1.Organem rejestrującym jest Wspólne Centrum Badawcze (JRC).

               2.1.4.2.Organ rejestrujący jest odpowiedzialny za weryfikację tożsamości zaufanych kurierów w celu rejestracji i zatwierdzania wniosków o wydanie, unieważnienie i odnowienie certyfikatów elektronicznych.

               2.1.4.3.Organ rejestrujący:

               a)nadaje organowi krajowemu niepowtarzalny identyfikator;

               b)uwierzytelnia tożsamość organu krajowego, jego punktów kontaktowych i zaufanych kurierów;

               c)kontaktuje się z zespołem wsparcia w ramach CEF odnośnie do autentyczności organu krajowego, jego punktów kontaktowych i zaufanych kurierów;

               d)informuje organ krajowy o zatwierdzeniu lub odrzuceniu certyfikatu.

               2.1.5.Centrum certyfikacji

               2.1.5.1.Centrum certyfikacji jest odpowiedzialne za zapewnienie infrastruktury technicznej do celów wnioskowania o wydanie, wydawania i unieważniania certyfikatów elektronicznych.

               2.1.5.2.Centrum certyfikacji:

               a)zapewnia infrastrukturę techniczną do celów składania wniosków o wydanie certyfikatu przez organy krajowe;

               b)zatwierdza lub odrzuca wniosek o wydanie certyfikatu;

               c)w razie potrzeby kontaktuje się z organem rejestrującym w celu weryfikacji tożsamości organizacji składającej wniosek.

               2.2.Wydanie certyfikatu

               2.2.1.Wydanie certyfikatu odbywa się zgodnie z następującymi kolejnymi etapami przedstawionymi na rysunku 1:

               a)Etap 1: Identyfikacja zaufanych kurierów;

               b)Etap 2: Utworzenie wniosku o wydanie certyfikatu;

               c)Etap 3: Rejestracja w organie rejestrującym;

               d)Etap 4: Generowanie certyfikatu;

               e)Etap 5: Publikacja certyfikatu;

               f)Etap 6: Akceptacja certyfikatu.

               Rysunek 1 –przebieg procedury wydawania certyfikatów

               2.2.2.Etap 1: Identyfikacja zaufanego kuriera

               Na potrzeby identyfikacji zaufanego kuriera przeprowadza się następującą procedurę:

               a)Organ rejestrujący przekazuje organowi krajowemu formularz identyfikacyjny z danymi osób wyznaczonych do kontaktów oraz zaufanych kurierów
                  6
               . Formularz ten zawiera również pełnomocnictwo, które organizacja (organ AETR) podpisuje.

               b)Organ krajowy odsyła wypełniony formularz i podpisane pełnomocnictwo do organu rejestrującego.

               c)Organ rejestrujący potwierdza odbiór i kompletność formularza.

               d)Organ rejestrujący przekazuje właścicielowi domeny zaktualizowaną kopię listy osób wyznaczonych do kontaktów i zaufanych kurierów.

               2.2.3.Etap 2: Utworzenie wniosku o wydanie certyfikatu

               2.2.3.1.Wniosek o wydanie certyfikatu i jego pobranie odbywa się na tym samym komputerze i przy użyciu tej samej przeglądarki.

               2.2.3.2.Na potrzeby utworzenia wniosku o wydanie certyfikatu przeprowadza się następującą procedurę:

               a)W celu zwrócenia się o wydanie certyfikatu za pośrednictwem adresu URL organizacja przechodzi do internetowego interfejsu użytkownika

                  https://sbca.telesec.de/sbca/ee/login/displayLogin.html?locale=en

               : i wpisuje nazwę użytkownika „sbca/CEF_eDelivery.europa.eu” oraz hasło „digit.333”

               Rysunek 2

               b)Organizacja klika na „request” (wniosek) po lewej stronie panelu i wybiera „CEF_TACHOnet” na rozwijanej liście.

               Rysunek 3

               c)Organizacja uzupełnia formularz wniosku o wydanie certyfikatu przedstawiony na rysunku 4 informacjami podanymi w tabeli 3, klikając na „Next („soft-PSE”)” w celu zakończenia procesu.

               Rysunek 4

                        Wymagane pola

                        Opis

                        Country [państwo]

                        C = kod państwa, lokalizacja właściciela certyfikatu, zweryfikowana przy użyciu publicznego spisu;

                        Ograniczenia: 2 znaki, zgodnie z normą ISO 3166-1, alpha-2; rozróżnianie wielkich i małych liter;
                        przykłady: DE, BE, NL,

                        Przypadki szczególne: UK (dla Wielkiej Brytanii), EL (dla Grecji)

                        Organisation/Company (O) [organizacja/przedsiębiorstwo]

                        O = nazwa organizacji właściciela certyfikatu

                        Master domain (OU1) [główna domena]

                        OU=CEF_eDelivery.europa.eu

                        Area of responsibility (OU2) [obszar odpowiedzialności]

                        OU=CEF_TACHOnet

                        Department (OU3) [wydział]

                        Wartość obowiązkowa dla „AREA OF RESPONSIBILITY” [obszar odpowiedzialności]

                        W przypadku gdy wymagany jest certyfikat, jego treść musi zostać sprawdzona z wykorzystaniem wykazu pozytywnego (biała lista). Jeżeli informacje nie są zgodne z wykazem, wniosek zostaje zablokowany.

                        Format:
                        OU=<TYPE>-<GTC_NUMBER>

                        Gdzie „< TYPE >” zostaje zastąpiony przez AP_PROD: Punkt dostępu w środowisku produkcyjnym.

                        Oraz gdzie <GTC_NUMBER> to GTC_OID-1.3.130.0.2018.xxxxxx, gdzie Ares(2018)xxxxxx jest numerem GTC dla projektu Tachonet.

                        Np.:

                        AP_PROD-GTC_OID-1.3.130.0.2018.xxxxxx

                        First name (CN) [imię]

                        Musi pozostać puste.

                        Last name (CN) [nazwisko]

                        Musi zaczynać się od „GRP”, po czym następuje nazwa zwyczajowa.

                        Format:

                        CN=GRP:<AREA OF RESPONSIBILITY>_<TYPE>_<COUNTRY CODE>_<UNIQUE IDENTIFIER>

                        Np.:
                        GRP:CEF_TACHOnet_AP_PROD_BE_001

                        E-mail

                        E=

                           CEF-EDELIVERY-SUPPORT@ec.europa.eu

                        E-mail 1 (SAN)

                        Musi pozostać puste.

                        E-mail 2 (SAN)

                        Musi pozostać puste.

                        E-mail 3 (SAN)

                        Musi pozostać puste.

                        Address [adres]

                        Musi pozostać puste.

                        Street [ulica]

                        Musi być oficjalnym adresem organizacji właściciela certyfikatu. (Stosowane w przypadku pełnomocnictwa.)

                        Street no. [nr budynku]

                        Musi być oficjalnym adresem organizacji właściciela certyfikatu. (Stosowane w przypadku pełnomocnictwa.)

                        Zip Code [kod pocztowy]

                        Musi być oficjalnym adresem organizacji właściciela certyfikatu. (Stosowane w przypadku pełnomocnictwa.)

                        Uwaga: jeżeli kod pocztowy nie jest 5-cyfrowym kodem pocztowym, pole to należy pozostawić puste i wpisać kod pocztowy w polu dotyczącym miejscowości.

                        City [miejscowość]

                        Musi być oficjalnym adresem organizacji właściciela certyfikatu. (Stosowane w przypadku pełnomocnictwa.)

                        Uwaga: jeżeli kod pocztowy nie jest 5-cyfrowym kodem pocztowym, pole to należy pozostawić puste i wpisać kod pocztowy w polu dotyczącym miejscowości.

                        Phone no [numer telefonu]

                        Musi pozostać puste.

                        Identification data [dane identyfikacyjne]

                        Adres poczty elektronicznej musi być taki sam, jak adres stosowany do rejestracji niepowtarzalnego identyfikatora.
                           +
                           Musi być imię i nazwisko osoby reprezentującej organizację. (Stosowane w przypadku pełnomocnictwa.)

                        + Commercial Register No [numer w rejestrze handlowym] (obowiązkowe wyłącznie dla organizacji prywatnych)

                        Entered at the Local Court of [wpis w lokalnym sądzie] (wymagane tylko w przypadku niemieckich i austriackich organizacji prywatnych)

                        Revocation password [hasło unieważnienia]

                        Pole obowiązkowe wybrane przez wnioskodawcę

                        Revocation password repetition [powtórzenie hasła unieważnienia]

                        Pole obowiązkowe wybrane przez wnioskodawcę (powtórzenie)

               Tabela 3. Pełne dane o każdym wymaganym polu

               d)Wybrana długość klucza powinna wynosić 2048 (High Grade).

               Rysunek 5

               e)Organizacja rejestruje numer referencyjny w celu pobrania certyfikatu.

               Rysunek 6

               f)Zespół wsparcia CEF sprawdza nowe wnioski o wydanie certyfikatów oraz weryfikuje, czy informacje zawarte we wniosku o wydanie certyfikatu są ważne, tj. czy są zgodne z konwencją nazewnictwa określoną w dodatku 5.1 do Konwencji o nazwach certyfikatów.

               g)Zespół wsparcia CEF sprawdza, czy informacje zawarte we wniosku są w prawidłowym formacie.

               h)Jeżeli weryfikacja przewidziana w pkt 5 lub 6 powyżej nie powiedzie się zespół wsparcia CEF przesyła wiadomość e-mail na adres poczty elektronicznej podany w polu „Dane identyfikacyjne” formularza wniosku, wraz z kopią (w „cc”) do właściciela domeny, w którym organizacja proszona jest o ponowne rozpoczęcie tej procedury. Nieudany wniosek o wydanie certyfikatu zostaje unieważniony.

               i)Zespół wsparcia CEF wysyła do organu rejestrującego wiadomość e-mail dotyczącą ważności wniosku. Wiadomość e-mail zawiera:

               1)nazwę organizacji dostępną w polu „Organisation (O)” [organizacja] wniosku o wydanie certyfikatu;

               2)dane dotyczące certyfikatu, w tym nazwę podmiotu, dla którego certyfikat ma zostać wydany, dostępną w polu „Last Name (CN)” [nazwisko] wniosku o wydanie certyfikatu;

               3)numer referencyjny certyfikatu;

               4)adres organizacji, jej adres e-mail oraz imię i nazwisko osoby ją reprezentującej.

               Rysunek 7 – Procedura składania wniosku o wydanie certyfikatu

               2.2.4.Etap 3: Rejestracja w organie rejestrującym (zatwierdzenie certyfikatu)

               2.2.4.1.Zaufany kurier lub punkt kontaktowy ustala –w drodze wymiany wiadomości e-mail – termin spotkania z organem rejestrującym, podając dane zaufanego kuriera, który osobiście weźmie udział w spotkaniu.

               2.2.4.2.Organizacja przygotowuje pakiet dokumentów składający się z:

               a)wypełnionego i podpisanego pełnomocnictwa;

               b)kopii ważnego paszportu zaufanego kuriera, który weźmie udział w spotkaniu. Kopia ta musi być podpisana przez jeden z określonych na etapie 1 zidentyfikowanych punktów kontaktowych organizacji;

               c)formularza wniosku w papierowej formie o wydanie certyfikatu podpisanego przez jeden z punktów kontaktowych organizacji.

               2.2.4.3.Organ rejestrujący przyjmuje zaufanego kuriera po przeprowadzeniu kontroli tożsamości w recepcji budynku. Organ rejestrujący przeprowadza bezpośrednią rejestrację wniosku o wydanie certyfikatu, dokonując:

               a)identyfikacji i uwierzytelnienia zaufanego kuriera;

               b)weryfikacji fizycznego wyglądu zaufanego kuriera w oparciu o przedstawiony przez niego paszport;

               c)weryfikacji ważności paszportu przedstawionego przez zaufanego kuriera;

               d)weryfikacji ważnego paszportu przedstawionego przez zaufanego kuriera w porównaniu z kopią ważnego paszportu zaufanego kuriera podpisaną przez jeden ze zidentyfikowanych punktów kontaktowych organizacji. Podpis jest uwierzytelniany w oparciu o oryginalny „formularz identyfikacyjny z danymi osób wyznaczonych do kontaktów oraz zaufanych kurierów”;

               e)weryfikacji wypełnionego i podpisanego pełnomocnictwa;

               f)weryfikacji formularza wniosku w papierowej formie o wydanie certyfikatu oraz jego podpisu w oparciu o oryginalny „formularz identyfikacyjny z danymi osób wyznaczonych do kontaktów oraz zaufanych kurierów”;

               g)ponownego sprawdzenia, w drodze rozmowy telefonicznej z punktem kontaktowym, który podpisał wniosek, tożsamości zaufanego kuriera oraz treści wniosku o wydanie certyfikatu.

               2.2.4.4.Organ rejestrujący potwierdza zespołowi wsparcia CEF, że organ krajowy w istocie jest uprawniony do korzystania z elementów, w odniesieniu do których występuje o wydanie certyfikatów, oraz że odpowiedni proces rejestracji bezpośredniej był skuteczny. Potwierdzenie wysyła się pocztą elektroniczną zabezpieczoną przy użyciu certyfikatu „CommiSign”, załączając zeskanowaną kopię poświadczonego pakietu z rejestracji bezpośredniej oraz podpisaną listę kontrolną z weryfikacji przeprowadzonej przez organ rejestracyjny.

               2.2.4.5.Jeżeli organ rejestrujący potwierdzi ważność wniosku, proces przeprowadza się zgodnie z wymogami określonymi w pkt 2.2.4.6 i 2.2.4.7. W przeciwnym razie wniosek o wydanie certyfikatu zostaje odrzucony, a organizacja zostaje o tym poinformowana.

               2.2.4.6.Zespół wsparcia CEF zatwierdza wniosek o wydanie certyfikatu i powiadamia organ rejestrujący o zatwierdzeniu certyfikatu.

               2.2.4.7.Organ rejestrujący powiadamia organizację, że certyfikat można pobrać za pośrednictwem portalu użytkownika.

               Rysunek 8 – Zatwierdzenie certyfikatu

               2.2.5.Etap 4: Generowanie certyfikatu

               Po zatwierdzeniu wniosku o wydanie certyfikatu certyfikat zostaje wygenerowany.

               2.2.6.Etap 5: Publikacja i pobieranie certyfikatu

               2.2.6.1.Po zatwierdzeniu wniosku o wydanie certyfikatu organ rejestrujący pobiera certyfikat i przekazuje jego kopię zaufanemu kurierowi.

               2.2.6.2.Organizacja otrzymuje powiadomienie od organu rejestrującego, że certyfikat może zostać pobrany.

               2.2.6.3.Organizacja przechodzi do portalu użytkownika:

                  https://sbca.telesec.de/sbca/ee/login/displayLogin.html?locale=en

                i loguje się przy użyciu nazwy użytkownika „sbca/CEF_eDelivery.europa.eu” oraz hasła „digit.333”.

               Rysunek 9

               2.2.6.4.Organizacja powinna kliknąć na zakładkę „fetch” (pobierz) po lewej stronie ekranu i podać numer referencyjny zarejestrowany na etapie składania wniosku o wydanie certyfikatu;

               Rysunek 10

               2.2.6.5.Organizacja instaluje certyfikaty, klikając na zakładkę „install” (zainstaluj);

               Rysunek 11

               2.2.6.6.Certyfikat należy zainstalować w punkcie dostępu. W związku z tym, że instalacja zależy od wdrożenia, organizacja powinna zwrócić się do swojego dostawcy punktu dostępu w celu uzyskania opisu tej procedury.

               2.2.6.7.Instalację certyfikatu w punkcie dostępu przeprowadza się w następujących etapach:

               a)eksport klucza prywatnego i certyfikatu,

               b)utworzenie „keystore” i „truststore”,

               c)zainstalowanie „keystore“” i „truststore” w punkcie dostępu.

               Rysunek 12 – Pobranie certyfikatu

               3.Proces unieważnienia certyfikatu

               3.1.Organizacja przedkłada wniosek o unieważnienie certyfikatu za pośrednictwem internetowego portalu użytkownika;

               3.2.Zespół wsparcia CEF przeprowadza unieważnienie certyfikatu.

               Rysunek 13 – Unieważnienie certyfikatu

               4.Ogólne warunki korzystania z usługi infrastruktury klucza publicznego CEF

               4.1.Kontekst

               Jako dostawca rozwiązań modułu eDelivery instrumentu „Łącząc Europę”, DIGIT udostępnia usługę infrastruktury klucza publicznego
                  7
                („usługę infrastruktury klucza publicznego CEF”) Umawiającym się Stronom AETR. Usługa infrastruktury klucza publicznego CEF jest wykorzystywana przez organy krajowe („użytkowników końcowych”) uczestniczących w systemie Tachonet.

               DIGIT jest dzierżawcą PKI w ramach rozwiązania TeleSec Shared-Business-CA solution („SBCA”) wykorzystywanego w ramach Trust Center jednostki grupy T-Systems International GmbH („T-Systems”
                  8
               ). DIGIT pełni funkcję Master Registrar dla domeny „CEF_eDelivey.europa.eu” SBCA. W tej roli DIGIT tworzy poddomeny w obrębie domeny „CEF_eDelivery.europa.eu” dla każdego projektu za pośrednictwem usługi infrastruktury klucza publicznego CEF.

               Niniejszy dokument zawiera szczegółowe warunki dotyczące poddomeny Tachonet. DIGIT odgrywa rolę podrejestratora dla tej poddomeny. W tym charakterze wydaje, unieważnia i odnawia certyfikaty dla tego projektu.

               4.2.Klauzula o wyłączeniu odpowiedzialności

               Komisja Europejska nie ponosi żadnej odpowiedzialności za treść certyfikatu, która leży wyłącznie w gestii właściciela certyfikatu. Sprawdzenie prawidłowości treści certyfikatu jest obowiązkiem właściciela certyfikatu.

               Komisja Europejska nie ponosi żadnej odpowiedzialności za sposób wykorzystania certyfikatu przez jego właściciela, będącego trzecim podmiotem prawnym poza Komisją Europejską.

               Celem niniejszej klauzuli o wyłączeniu odpowiedzialności nie jest ograniczenie odpowiedzialności Komisji Europejskiej w sposób sprzeczny z wymogami ustanowionymi w obowiązującym ustawodawstwie krajowym lub wyłączenie jej odpowiedzialności w przypadkach, które nie mogą zostać objęte wyłączeniem, zgodnie ze wspomnianym ustawodawstwem.

               4.3.Dozwolone/niedozwolone sposoby korzystania z certyfikatów

               4.3.1.Dozwolone wykorzystanie certyfikatów

               Po wydaniu certyfikatu właściciel certyfikatu
                  9
                korzysta z niego wyłącznie w ramach systemu Tachonet. W tym kontekście certyfikat może być stosowany do:

               ·uwierzytelnienia pochodzenia danych;

               ·zaszyfrowania danych;

               ·zapewnienia wykrywania naruszeń integralności danych.

               4.3.2.Niedozwolone wykorzystanie certyfikatów

               Zabrania się jakiegokolwiek wykorzystania bez wyraźnego zezwolenia w ramach dozwolonych zastosowań certyfikatu.

               4.4.Dodatkowe obowiązki właściciela certyfikatu

               Szczegółowe warunki SBCA określone są przez T-Systems w polityce certyfikacji (CP)/oświadczeniu na temat praktyk dotyczących certyfikacji (CPS) usługi SBCA
                  10
               . Niniejszy dokument zawiera specyfikacje i wytyczne dotyczące bezpieczeństwa w odniesieniu do aspektów technicznych i organizacyjnych oraz opisuje działania operatora Trust Centre w rolach centrum certyfikacji i organu rejestrującego, a także delegowanej strony trzeciej organu rejestrującego.

               Jedynie podmioty uprawnione do udziału w systemie Tachonet mogą wystąpić o wydanie certyfikatu.

               Jeżeli chodzi o akceptację certyfikatu, zastosowanie ma klauzula 4.4.1 polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji SBCA; ponadto warunki użytkowania i przepisy opisane w niniejszym dokumencie są uznawane za przyjęte przez organizację, dla której wydano certyfikat („O=”), w momencie jego pierwszego użycia.

               Jeżeli chodzi o publikację certyfikatu, zastosowanie ma klauzula 2.2 polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji SBCA.

               Wszyscy właściciele certyfikatów muszą przestrzegać poniższych wymogów:

               1)chronią swoje klucze prywatne przed nieuprawnionym użyciem;

               2)powstrzymują się od przekazywania lub ujawniania swoich kluczy prywatnych osobom trzecim nawet jako przedstawicielom;

               3)powstrzymują się od dalszego korzystania z klucza prywatnego po upływie okresu ważności lub unieważnieniu certyfikatu, z wyjątkiem w celu przeglądania zaszyfrowanych danych (np. odszyfrowywania wiadomości przekazywanych drogą elektroniczną);

               4)właściciel certyfikatu jest odpowiedzialny za kopiowanie lub przekazywanie klucza podmiotowi lub podmiotom końcowym;

               5)właściciel certyfikatu musi zobowiązać podmiot końcowy/wszystkie podmioty końcowe do przestrzegania aktualnych warunków, w tym polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji SBCA w odniesieniu do klucza prywatnego;

               6)właściciel certyfikatu musi przedstawić identyfikację upoważnionych przedstawicieli, którzy są uprawnieni do występowania o unieważnienie certyfikatów wydanych organizacji, oraz szczegółowe informacje na temat zdarzeń, które prowadzą do unieważnienia, a także hasło unieważnienia;

               7)w przypadku certyfikatów związanych z grupami osób i funkcji lub osobami prawnymi, po opuszczeniu grupy przez daną osobę (np. ustanie stosunku pracy) właściciel certyfikatu musi zapobiec niewłaściwemu wykorzystywaniu klucza prywatnego poprzez unieważnienie certyfikatu.

               8)Właściciel certyfikatu jest odpowiedzialny za wystąpienie z wnioskiem o unieważnienie certyfikatu w sytuacjach, o których mowa w klauzuli 4.9.1 polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji SBCA.

               Jeżeli chodzi o odnowienie certyfikatu lub utworzenie nowego klucza dla certyfikatów, zastosowanie ma klauzula 4.6 lub 4.7 polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji SBCA.

               Jeżeli chodzi o zmianę certyfikatu, zastosowanie ma klauzula 4.8 polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji SBCA.

               Jeżeli chodzi o unieważnienie certyfikatu, zastosowanie ma klauzula 4.9 polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji SBCA.

               5.Formularz identyfikacyjny z danymi osób wyznaczonych do kontaktów i zaufanych kurierów (wzór)

                        Ja niżej podpisany, [imię i nazwisko oraz adres przedstawiciela organizacji], zaświadczam, że następujące informacje mają być wykorzystywane w kontekście wniosku, generowania i pobierania certyfikatów cyfrowych klucza publicznego dla punktów dostępu systemu Tachonet wspierających poufność, integralność i niezaprzeczalność komunikatów Tachonet:

                        Informacje na temat osób wyznaczonych do kontaktów:

                        Informacje na temat zaufanych kurierów:

                        Miejsce, data, pieczęć firmowa lub pieczęć organizacji:

                        Podpis upoważnionego przedstawiciela:

               6.Dokumenty

               6.1.Indywidualne pełnomocnictwo (wzór)

               Przykładowe indywidualne pełnomocnictwo, które musi zostać podpisane i przedstawione przez zaufanego kuriera w trakcie rejestracji bezpośredniej w organie rejestrującym, można znaleźć pod adresem:

               6.2.Formularz wniosku w papierowej formie o wydanie certyfikatu (wzór)

               Wzór formularza wniosku w papierowej formie o wydanie certyfikatu, który musi zostać podpisany i przedstawiony przez zaufanego kuriera w trakcie rejestracji bezpośredniej w siedzibie organu rejestrującego, można znaleźć pod adresem:

               7.Glosariusz

               Najważniejsze terminy stosowane w niniejszym poddodatku zdefiniowane są w sekcji „CEF Definitions” [definicje CEF] na jednolitym portalu internetowym instrumentu „Łącząc Europę”:

                  https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/CEF+Definitions

               Najważniejsze skróty stosowane w niniejszym poddodatku zdefiniowane są w sekcji „CEF Glossary” [glosariusz CEF] na jednolitym portalu internetowym instrumentu „Łącząc Europę”:

                  https://ec.europa.eu/cefdigital/wiki/pages/viewpage.action?spaceKey=CEFDIGITAL&title=CEF+Glossary

                     (1)

                        Infrastruktura klucza publicznego (PKI) jest zbiorem ról, polityk, procedur i systemów niezbędnych do tworzenia certyfikatów elektronicznych, zarządzania nimi, ich dystrybucji i unieważniania.

                     (2)

                        Identyfikowany za pomocą wartości atrybutu „O=” w podsekcji zawierającej nazwę (Subject Distinguished Name) wydanego certyfikatu.

                     (3)

                  https://pl.wikipedia.org/wiki/Infrastruktura_klucza_publicznego

                     (4)

                        Najnowszą wersję polityki certyfikacji i oświadczenia na temat praktyk dotyczących certyfikacji (CPS) można pobrać na stronie internetowej:
                  https://www.telesec.de/en/sbca-en/support/download-area/

                     (5)

                        Pełnomocnictwo jest dokumentem prawnym, na mocy którego organizacja uprawnia i upoważnia Komisję Europejską reprezentowaną przez wyznaczonego urzędnika odpowiedzialnego za usługę infrastruktury klucza publicznego CEF do zwrócenia się o wygenerowanie certyfikatu w jej imieniu przez T-Systems International GmbH TeleSec Shared Business CA. Zob. również pkt 6.

                     (6)

                        Zob. pkt 5

                     (7)

                        Infrastruktura klucza publicznego (PKI) jest zbiorem ról, polityk, procedur i systemów niezbędnych do tworzenia certyfikatów elektronicznych, zarządzania nimi, ich dystrybucji i unieważniania.

                     (8)

                        Zaufana rola operatora Trust Center umiejscowionego w Trust Center T-Systems obejmuje również zadania wewnętrznego organu rejestrującego.

                     (9)

                        Identyfikowany za pomocą wartości atrybutu „O=” w podsekcji zawierającej nazwę (Subject Distinguished Name) wydanego certyfikatu.

                     (10)

                        Najnowsza wersja polityki certyfikacji/oświadczenia na temat praktyk dotyczących certyfikacji T-Systems SBCA jest dostępna pod adresem
                  https://www.telesec.de/en/sbca-en/support/download-area/
                  .


               KOMISJA EUROPEJSKA
            Bruksela, dnia 5.11.2018
            COM(2018) 730 final
            2018/0378(NLE)
            Wniosek
            DECYZJA RADY
            w sprawie stanowiska, jakie ma być zajęte w imieniu Unii w ramach Komitetu ds. Handlu i Rozwoju ustanowionego na mocy Umowy o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami SADC objętymi umową o partnerstwie gospodarczym, z drugiej strony, w odniesieniu do przyjęcia listy arbitrów

               UZASADNIENIE

               1.Przedmiot wniosku

               Niniejszy wniosek dotyczy decyzji określającej stanowisko, jakie ma być zajęte w imieniu Unii w ramach Komitetu ds. Handlu i Rozwoju ustanowionego na mocy Umowy o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami Południowoafrykańskiej Wspólnoty Rozwoju (SADC) objętymi umową o partnerstwie gospodarczym („państwa SADC UPG)”, z drugiej strony, w związku z planowanym przyjęciem listy osób pragnących i mogących pełnić rolę arbitrów.

               2.Kontekst wniosku

               2.1.Umowa o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami SADC objętymi umową o partnerstwie gospodarczym, z drugiej strony (UPG UE-SADC)

               Umowa o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami SADC objętymi umową o partnerstwie gospodarczym, z drugiej strony („Umowa”) ma na celu:

               a)przyczynianie się do zwalczania i wyeliminowania ubóstwa poprzez ustanowienie partnerstwa w handlu spójnego z celem zrównoważonego rozwoju, milenijnymi celami rozwoju (MCR) i umową z Kotonu;

               b)wspieranie integracji regionalnej, współpracy gospodarczej oraz dobrych rządów, aby ustanowić i wdrożyć skuteczne, przewidywalne i przejrzyste regionalne ramy prawne dla handlu i inwestycji pomiędzy Stronami i państwami SADC UPG;

               c)wspieranie stopniowej integracji państw SADC UPG z gospodarką światową, zgodnie z ich wyborami politycznymi i priorytetami rozwoju;

               d)wzmacnianie potencjału państw SADC UPG w zakresie polityki handlowej i zagadnień związanych z handlem;

               e)poprawa warunków do zwiększania inwestycji i rozwoju inicjatyw sektora prywatnego oraz poprawa możliwości zaopatrzenia, konkurencyjności i wzrostu gospodarczego w państwach SADC UPG; oraz

               f)wzmacnianie istniejących więzi pomiędzy Stronami na zasadzie solidarności i obopólnego interesu.

               Umowę stosuje się tymczasowo między Unią Europejską i jej państwami członkowskimi, z jednej strony, a Botswaną, Lesotho, Namibią, Eswatini i Republiką Południowej Afryki, z drugiej strony, od dnia 10 października 2016 r. oraz między Unią Europejską i jej państwami członkowskimi, z jednej strony, a Mozambikiem, z drugiej strony, od dnia 4 lutego 2018 r.

               2.2.Komitet ds. Handlu i Rozwoju

               W art. 100 Umowy ustanawia się Wspólną Radę i postanawia się, że „nadzoruje [ona] wdrażanie niniejszej Umowy i administruje nim”. Art. 103 Umowy stanowi, że „Wspólną Radę wspiera w wykonywaniu jej obowiązków Komitet ds. Handlu i Rozwoju składający się z przedstawicieli Stron, z zasady na szczeblu wysokich urzędników”.

               Art. 94 Umowy przewiduje, że Komitet ds. Handlu i Rozwoju „sporządza listę dwudziestu jeden (21) osób pragnących i mogących pełnić rolę arbitrów”.

               2.3.Planowany akt Komitetu ds. Handlu i Rozwoju

               Na swoim pierwszym posiedzeniu po przyjęciu przez Wspólną Radę jego regulaminu wewnętrznego Komitet ds. Handlu i Rozwoju ma przyjąć decyzję w sprawie ustanowienia listy osób pragnących i mogących pełnić rolę arbitrów, zgodnie z art. 94 Umowy („planowany akt”).

               Celem planowanego aktu jest ustanowienie listy dwudziestu jeden osób, które mogą pełnić rolę arbitrów w ramach procedury rozstrzygania sporów zgodnie z częścią III Umowy. Przyjęcie tej listy jest zasadniczym elementem dopełniającym ramy operacyjne w odniesieniu do postanowień Umowy dotyczących unikania i rozstrzygania sporów

               3.Stanowisko, jakie ma być zajęte w imieniu Unii

               Niniejszy wniosek dotyczy decyzji Rady określającej stanowisko, jakie ma być zajęte w imieniu Unii w ramach Komitetu ds. Handlu i Rozwoju ustanowionego na mocy UPG UE-SADC w odniesieniu do ustanowienia listy osób pragnących i mogących pełnić rolę arbitrów, zgodnie z art. 94 Umowy

               Strony Umowy uzgodniły listę osób pragnących i mogących pełnić rolę arbitrów zgodnie z art. 94 Umowy, a projekt decyzji Komitetu ds. Handlu i Rozwoju w sprawie ustanowienia tej listy powinien zostać przyjęty, z zastrzeżeniem unijnych procedur podejmowania decyzji, na pierwszym posiedzeniu Komitetu ds. Handlu i Rozwoju, które odbędzie się po przyjęciu przez Wspólną Radę regulaminu wewnętrznego tego Komitetu, i które jest przewidziane na pierwsze półrocze 2019 r.

               Decyzja ta ma zasadnicze znaczenie dla umożliwienia wykonywania postanowień zawartych w części III Umowy dotyczących unikania i rozstrzygania sporów, a tym samym dla zapewnienia sprawnego wdrażania Umowy.

               4.Podstawa prawna

               4.1.Proceduralna podstawa prawna

               4.1.1.Zasady

               Art. 218 ust. 9 Traktatu o funkcjonowaniu Unii Europejskiej (TFUE) określa tryb przyjmowania decyzji ustalających „stanowiska, które mają być zajęte w imieniu Unii w ramach organu utworzonego przez umowę, gdy organ ten ma przyjąć akty mające skutki prawne, z wyjątkiem aktów uzupełniających lub zmieniających ramy instytucjonalne umowy”.

               Pojęcie „akty mające skutki prawne” obejmuje akty, które mają skutki prawne na mocy przepisów prawa międzynarodowego dotyczących danego organu. Obejmuje ono ponadto instrumenty, które na mocy prawa międzynarodowego nie są wiążące, ale mogą „w sposób decydujący wywrzeć wpływ na treść przepisów przyjętych przez prawodawcę Unii”
                  1
               .

               4.1.2.Zastosowanie w niniejszej sprawie

               Komitet ds. Handlu i Rozwoju jest organem ustanowionym na mocy umowy, mianowicie Umowy o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami SADC objętymi umową o partnerstwie gospodarczym, z drugiej strony.

               Akt, który ma zostać przyjęty przez Komitet ds. Handlu i Rozwoju, to akt mający skutki prawne. Planowany akt będzie wiążący na mocy prawa międzynarodowego zgodnie z art. 94 Umowy.

               Planowany akt nie uzupełnia ani nie zmienia ram instytucjonalnych Umowy.

               W związku z tym proceduralną podstawę prawną decyzji, której dotyczy wniosek, stanowi art. 218 ust. 9 TFUE.

               4.2.Materialna podstawa prawna

               4.2.1.Zasady

               Materialna podstawa prawna decyzji na mocy art. 218 ust. 9 TFUE zależy w pierwszej kolejności od celu i treści planowanego aktu, którego dotyczy stanowisko, jakie ma być zajęte w imieniu Unii. Jeżeli planowany akt ma dwojaki cel lub dwa elementy składowe, a jeden z tych celów lub elementów da się określić jako główny, zaś drugi ma jedynie charakter pomocniczy, decyzja przyjęta na mocy art. 218 ust. 9 TFUE musi mieć jedną materialną podstawę prawną, tj. podstawę, której wymaga główny lub dominujący cel lub element składowy.

               4.2.2.Zastosowanie w niniejszej sprawie

               Główny cel i treść planowanego aktu odnoszą się do wspólnej polityki handlowej.

               Materialną podstawą prawną proponowanej decyzji jest zatem art. 207 TFUE.

               4.3.Wniosek

               Podstawą prawną proponowanej decyzji powinien być art. 207 TFUE w związku z art. 218 ust. 9 TFUE.

               2018/0378 (NLE)

               Wniosek

               DECYZJA RADY

               w sprawie stanowiska, jakie ma być zajęte w imieniu Unii w ramach Komitetu ds. Handlu i Rozwoju ustanowionego na mocy Umowy o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami SADC objętymi umową o partnerstwie gospodarczym, z drugiej strony, w odniesieniu do przyjęcia listy arbitrów

               RADA UNII EUROPEJSKIEJ,

               uwzględniając Traktat o funkcjonowaniu Unii Europejskiej, w szczególności jego art. 207 w związku z jego art. 218 ust. 9,

               uwzględniając wniosek Komisji Europejskiej,

               a także mając na uwadze, co następuje:

               (1)Umowa o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami Południowoafrykańskiej Wspólnoty Rozwoju (SADC) objętymi umową o partnerstwie gospodarczym, z drugiej strony, została podpisana przez Unię Europejską i jej państwa członkowskie w dniu 10 czerwca 2016 r. („Umowa”). Umowę stosuje się tymczasowo od dnia 10 października 2016 r. między Unią Europejską i jej państwami członkowskimi, z jednej strony, a Botswaną, Lesotho, Namibią, Eswatini i Republiką Południowej Afryki, z drugiej strony, oraz od dnia 4 lutego 2018 r. między Unią Europejską i jej państwami członkowskimi, z jednej strony, a Mozambikiem, z drugiej strony.

               (2)Zgodnie z art. 94 ust. 1 Umowy Komitet ds. Handlu i Rozwoju sporządza listę osób pragnących i mogących pełnić rolę arbitrów.

               (3)Na swoim pierwszym posiedzeniu po przyjęciu przez Wspólną Radę jego regulaminu wewnętrznego Komitet ds. Handlu i Rozwoju ma przyjąć decyzję w sprawie ustanowienia listy osób pragnących i mogących pełnić rolę arbitrów.

               (4)Należy ustalić stanowisko, jakie ma być zajęte w imieniu Unii w ramach Komitetu ds. Handlu i Rozwoju, gdyż planowana decyzja będzie wiążąca dla Unii.

               (5)Ustanowienie listy osób pragnących i mogących pełnić rolę arbitrów przewiduje się w art. 94 ust. 1 Umowy,

               PRZYJMUJE NINIEJSZĄ DECYZJĘ:

               Artykuł 1

               Stanowisko, jakie ma być zajęte w imieniu Unii w ramach Komitetu ds. Handlu i Rozwoju, opiera się na projekcie decyzji Komitetu ds. Handlu i Rozwoju w sprawie listy osób pragnących i mogących pełnić rolę arbitrów, dołączonym do niniejszej decyzji.

               Artykuł 2

               Niniejsza decyzja skierowana jest do Komisji.

               Sporządzono w Brukseli dnia […] r.

                     W imieniu Rady

                     Przewodniczący

                     (1)

                        Wyrok Trybunału Sprawiedliwości z dnia 7 października 2014 r. w sprawie C-399/12 Niemcy przeciwko Radzie, ECLI:EU:C:2014:2258, pkt 61-64.

    ---documentbreak---

               KOMISJA EUROPEJSKA
            Bruksela, dnia 5.11.2018
            COM(2018) 730 final
            ZAŁĄCZNIK
            do
            wniosku dotyczącego decyzji Rady
            w sprawie stanowiska, jakie ma być zajęte w imieniu Unii w ramach Komitetu ds. Handlu i Rozwoju ustanowionego na mocy Umowy o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami SADC objętymi umową o partnerstwie gospodarczym, z drugiej strony, w odniesieniu do przyjęcia listy arbitrów

               ZAŁĄCZNIK

               DECYZJA NR 1 KOMITETU DS. HANDLU I ROZWOJU

               z dnia xxx r.

               w sprawie przyjęcia listy osób pragnących i mogących pełnić rolę arbitrów

               KOMITET DS. HANDLU I ROZWOJU,

               uwzględniając Umowę o partnerstwie gospodarczym między Unią Europejską i jej państwami członkowskimi, z jednej strony, a państwami Południowoafrykańskiej Wspólnoty Rozwoju (SADC) objętymi umową o partnerstwie gospodarczym, z drugiej strony („Umowa”), podpisaną w Kasane w dniu 10 czerwca 2016 r., a w szczególności jej art. 100, 103, 94 i 104,

               PRZYJMUJE NINIEJSZĄ DECYZJĘ:

               1.Ustanawia się listę osób pragnących i mogących pełnić rolę arbitrów, określoną w załączniku.

               2.Niniejsza decyzja wchodzi w życie z dniem jej przyjęcia.

               Sporządzono w […] dnia […] r.

                        W imieniu Komitetu ds. Handlu i Rozwoju

                        Minister Handlu [...]

                        Przedstawiciel UE

               ZAŁĄCZNIK

               Lista arbitrów, o której mowa w art. 94 Umowy

               Arbitrzy wybrani przez państwa SADC UPG:

               1.Pani Boitumelo Sendy Gofhamodimo

               2.Pan Leonard Moses Phuti

               3.Pan Makong Tsotetsi

               4.Dr Sakeus Akweenda

               5.Adwokat Faizel Ismail

               6.Pani Kholofelo Ngokoane Kugler

               7.Sędzia Nkululeko J. Hlophe

               8.Samuel Jay Levy

               Arbitrzy wybrani przez UE:

               9.Jacques BOURGEOIS

               10.Claus-Dieter EHLERMANN

               11.Pieter Jan KUIJPER

               12.Giorgio SACERDOTI

               13.Laurence BOISSON DE CHAZOURNES

               14.Ramon TORRENT

               15.Michael Johannes HAHN

               16.Helène RUIZ FABRI

               Arbitrzy wspólnie wybrani przez Strony (obywatele innych państw, którzy mogą pełnić rolę przewodniczącego):

               17.Merit Janow

               18.Ichiro Araki

               19.Christian Häberli

               20.Claus von Wobeser

               21.Daniel Moulis