02021D1073 — PL — 15.09.2022 — 004.001

---

Dokument ten służy wyłącznie do celów informacyjnych i nie ma mocy prawnej. Unijne instytucje nie ponoszą żadnej odpowiedzialności za jego treść. Autentyczne wersje odpowiednich aktów prawnych, włącznie z ich preambułami, zostały opublikowane w Dzienniku Urzędowym Unii Europejskiej i są dostępne na stronie EUR-Lex. Bezpośredni dostęp do tekstów urzędowych można uzyskać za pośrednictwem linków zawartych w dokumencie

►B

DECYZJA WYKONAWCZA KOMISJI (UE) 2021/1073 z dnia 28 czerwca 2021 r. ustanawiająca specyfikacje techniczne i zasady do celów wdrożenia ram zaufania unijnych cyfrowych zaświadczeń COVID ustanowionych rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2021/953 (Tekst mający znaczenie dla EOG) (Dz.U. L 230 z 30.6.2021, s. 32)

zmieniona przez:

		Dziennik Urzędowy
		nr	strona	data
►M1	DECYZJA WYKONAWCZA KOMISJI (UE) 2021/2014 z dnia 17 listopada 2021 r.	L 410	180	18.11.2021
►M2	DECYZJA WYKONAWCZA KOMISJI (UE) 2021/2301 z dnia 21 grudnia 2021 r.	L 458	536	22.12.2021
►M3	DECYZJA WYKONAWCZA KOMISJI (UE) 2022/483 z dnia 21 marca 2022 r.	L 98	84	25.3.2022
►M4	DECYZJA WYKONAWCZA KOMISJI (UE) 2022/1516 z dnia 8 września 2022 r.	L 235	61	12.9.2022

---

▼B

DECYZJA WYKONAWCZA KOMISJI (UE) 2021/1073

z dnia 28 czerwca 2021 r.

ustanawiająca specyfikacje techniczne i zasady do celów wdrożenia ram zaufania unijnych cyfrowych zaświadczeń COVID ustanowionych rozporządzeniem Parlamentu Europejskiego i Rady (UE) 2021/953

(Tekst mający znaczenie dla EOG)

Artykuł 1

Specyfikacje techniczne unijnego cyfrowego zaświadczenia COVID określające ogólną strukturę danych, mechanizmy kodowania oraz mechanizm kodowania transportowego w formacie optycznym nadającym się do odczytu maszynowego są określone w załączniku I.

Artykuł 2

Zasady dotyczące wypełnienia zaświadczeń, o których mowa w art. 3 ust. 1 rozporządzenia (UE) 2021/953, są określone w załączniku II do niniejszej decyzji.

Artykuł 3

Wymogi określające wspólną strukturę niepowtarzalnego identyfikatora zaświadczenia są określone w załączniku III.

▼M1

Artykuł 4

Zasady zarządzania mające zastosowanie do certyfikatów klucza publicznego w odniesieniu do bramy sieciowej unijnych cyfrowych zaświadczeń COVID wspierającej aspekty interoperacyjności ram zaufania określono w załączniku IV.

▼M1

Artykuł 5

Wspólną skoordynowaną strukturę danych w odniesieniu do danych, które mają być zawarte w zaświadczeniach, o których mowa w art. 3 ust. 1 rozporządzenia (UE) 2021/953, wykorzystującą schemat JSON, określono w załączniku V do niniejszej decyzji.”.

▼M3

Artykuł 5a

Wymiana list unieważnionych certyfikatów

Artykuł 5b

Przedkładanie przez państwa trzecie list unieważnionych certyfikatów

Państwa trzecie wydające zaświadczenia COVID-19, w odniesieniu do których Komisja przyjęła akt wykonawczy na podstawie art. 3 ust. 10 lub art. 8 ust. 2 rozporządzenia (UE) 2021/953, mogą przedkładać listy unieważnionych certyfikatów COVID-19 objętych takim aktem wykonawczym do przetwarzania przez Komisję w imieniu współadministratorów za pośrednictwem bramy sieciowej, jak określono w art. 5a, zgodnie ze specyfikacjami technicznymi określonymi w załączniku I.

Artykuł 5c

Zarządzanie przetwarzaniem danych osobowych w centralnej bramie sieciowej unijnych cyfrowych zaświadczeń COVID

▼M1

Artykuł 6

Niniejsza decyzja wchodzi w życie z dniem jej opublikowania w Dzienniku Urzędowym Unii Europejskiej.

▼B

Niniejsza decyzja wchodzi w życie z dniem jej opublikowania w Dzienniku Urzędowym Unii Europejskiej.

---

ZAŁĄCZNIK I

FORMAT I ZARZĄDZANIE ZAUFANIEM

Ogólna struktura danych, mechanizmy kodowania i mechanizm kodowania transportowego w formacie optycznym nadającym się do odczytu maszynowego (zwanym dalej „QR”)

1.    Wprowadzenie

Specyfikacje techniczne określone w niniejszym załączniku zawierają ogólną strukturę danych i mechanizmy kodowania unijnego cyfrowego zaświadczenia COVID („zaświadczenie COVID”). Określają one również mechanizm kodowania transportowego w formacie optycznym nadającym się do odczytu maszynowego („QR”), który można wyświetlić na ekranie urządzenia przenośnego lub wydrukować. Formaty kontenera elektronicznych świadectw zdrowia określone w tych specyfikacjach mają charakter ogólny, ale w tym kontekście wykorzystywane są do przenoszenia zaświadczenia COVID.

2.    Terminologia

Do celów niniejszego załącznika „wystawcy” oznaczają organizacje korzystające z niniejszych specyfikacji do wystawiania świadectw zdrowia, a „weryfikatorzy” oznaczają organizacje akceptujące świadectwa zdrowia jako dowód statusu zdrowotnego. „Uczestnicy” oznaczają wystawców i weryfikatorów. Niektóre aspekty wymienione w niniejszym załączniku, takie jak zarządzanie przestrzenią nazw i dystrybucja kluczy kryptograficznych, muszą być koordynowane między uczestnikami. Zakłada się, że zadania te wykonuje strona zwana dalej „Sekretariatem”.

3.    Format kontenera elektronicznego świadectwa zdrowia

Format kontenera elektronicznego świadectwa zdrowia (ang. electronic health certificate container format, „HCERT”) ma na celu zapewnienie jednolitego i znormalizowanego nośnika dla świadectw zdrowia wydawanych przez różnych wystawców („wystawcy”). Celem niniejszych specyfikacji jest harmonizacja sposobu przedstawiania, kodowania i podpisywania świadectw zdrowia, aby ułatwić interoperacyjność.

Możliwość odczytu i interpretacji zaświadczenia COVID wydanego przez dowolnego wystawcę wymaga wspólnej struktury danych i porozumienia co do znaczenia każdego pola danych w ładunku (ang. payload). Aby ułatwić taką interoperacyjność, wspólną skoordynowaną strukturę danych definiuje się za pomocą schematu JSON, który stanowi szkielet zaświadczenia COVID.

3.1.    Struktura ładunku

Ładunek jest zorganizowany i zakodowany w formacie CBOR z podpisem cyfrowym w formacie COSE. Jest to powszechnie znane jako „token sieciowy CBOR”, zdefiniowany w specyfikacji RFC 8392 ( 1 ). Ładunek zdefiniowany w poniższych sekcjach jest transportowany w oświadczeniu hcert.

Integralność i autentyczność pochodzenia danych ładunku musi być możliwa do sprawdzenia przez weryfikatora. W tym celu wystawca musi podpisać token sieciowy CBOR przy użyciu systemu podpisu elektronicznego szyfrowanego asymetrycznie określonego w specyfikacji COSE (RFC 8152 ( 2 )).

3.2.    Oświadczenia tokena sieciowego CBOR

3.2.1.    Przegląd struktury tokena sieciowego CBOR

Nagłówek chroniony

Ładunek danych

Podpis

3.2.2.    Algorytm podpisu

Parametr Algorytm podpisu (alg) wskazuje, jakiego algorytmu używa się do utworzenia podpisu. Musi on spełniać lub przewyższać aktualne wytyczne SOG-IS, które streszczono w poniższych punktach.

Zdefiniowano jeden algorytm główny i jeden algorytm dodatkowy. Algorytm dodatkowy powinien być stosowany tylko w przypadku, gdy algorytm główny jest niedopuszczalny w ramach zasad i przepisów obowiązujących wystawcę.

W celu zapewnienia bezpieczeństwa systemu wszystkie wdrożenia muszą zawierać algorytm dodatkowy. Z tego powodu wdrożony musi być zarówno algorytm główny, jak i dodatkowy.

Poziomy ustalone przez SOG-IS w odniesieniu do algorytmu głównego i dodatkowego są następujące:

Odpowiada to parametrowi algorytmu COSE ES256.

Odpowiada to parametrowi algorytmu COSE: PS256.

3.2.3.    Identyfikator klucza

Oświadczenie Identyfikator klucza (kid) wskazuje certyfikat dla podpisujących dokumenty (DSC) zawierający klucz publiczny, który ma być stosowany przez weryfikatora do sprawdzania poprawności podpisu cyfrowego. Zarządzanie certyfikatami klucza publicznego, w tym wymogi dotyczące certyfikatów dla podpisujących dokumenty, opisano w załączniku IV.

Weryfikatorzy używają oświadczenia Identyfikator klucza (kid) do wyboru właściwego klucza publicznego z listy kluczy dotyczących wystawcy zawartych w oświadczeniu Wystawca (iss). Ze względów administracyjnych i przy przerzucaniu klucza wystawca może równolegle używać kilku kluczy. Identyfikator klucza nie jest polem o krytycznym znaczeniu dla bezpieczeństwa. Z tego powodu w razie potrzeby może być również umieszczony w nagłówku niechronionym. Weryfikatorzy muszą akceptować obie opcje. Jeżeli występują obie opcje, musi być użyty identyfikator klucza w nagłówku chronionym.

Ze względu na skrócenie identyfikatora (w celu ograniczenia rozmiaru) istnieje niewielkie, ale niezerowe prawdopodobieństwo, że zbiorcza lista certyfikatów dla podpisujących dokumenty (DSC), które akceptuje weryfikator, może zawierać certyfikaty dla podpisujących dokumenty z podwójnymi kid. Z tego powodu weryfikator musi sprawdzić wszystkie certyfikaty dla podpisujących dokumenty z tym kid.

3.2.4.    Wystawca

Oświadczenie Wystawca (iss) jest wartością ciągu, która może zawierać kod ISO 3166-1 alfa-2 państwa wystawcy świadectwa zdrowia. Weryfikator może wykorzystywać to oświadczenie w celu zidentyfikowania, który zestaw certyfikatów dla podpisujących dokumenty należy stosować do weryfikacji. Do identyfikacji tego oświadczenia używa się klucza oświadczenia 1.

3.2.5.    Czas wygaśnięcia

Oświadczenie Czas wygaśnięcia (exp) musi posiadać znacznik czasu w formacie daty numerycznej (NumericDate) wyrażonej liczbami całkowitymi (jak określono w RFC 8392 ( 4 ), sekcja 2), wskazujący, przez jaki czas dany podpis dotyczący ładunku uznaje się za ważny; po upływie tego czasu weryfikator musi odrzucić ładunek z powodu jego wygaśnięcia. Celem parametru wygaśnięcia jest wymuszenie ograniczenia okresu ważności świadectwa zdrowia. Do identyfikacji tego oświadczenia używa się klucza oświadczenia 4.

Czas wygaśnięcia nie może przekraczać okresu ważności certyfikatu dla podpisujących dokumenty.

3.2.6.    Data wydania

Oświadczenie Data wydania (iat) musi posiadać znacznik czasu w formacie daty numerycznej (NumericDate) wyrażonej liczbami całkowitymi (jak określono w RFC 8392 ( 5 ), sekcja 2), wskazujący czas utworzenia świadectwa zdrowia.

Pole Data wydania nie może zawierać wartości poprzedzającej okres ważności certyfikatu dla podpisujących dokumenty.

Weryfikatorzy mogą stosować dodatkowe zasady w celu ograniczenia ważności świadectwa zdrowia na podstawie terminu jego wystawienia. Do identyfikacji tego oświadczenia używa się klucza oświadczenia 6.

3.2.7.    Oświadczenie Świadectwo zdrowia

Oświadczenie Świadectwo zdrowia (hcert) jest obiektem JSON (RFC 7159 ( 6 )) zawierającym informacje o statusie zdrowotnym. W ramach tego samego oświadczenia może istnieć kilka różnych rodzajów świadectw zdrowia, z których jednym jest zaświadczenie COVID.

JSON służy wyłącznie do celów schematu. Format odwzorowania to CBOR, zdefiniowany w RFC 7049 ( 7 ). Programiści aplikacji nie muszą w rzeczywistości nigdy dekodować ani kodować do i z formatu JSON, lecz wykorzystują strukturę w pamięci.

Do identyfikacji tego oświadczenia używa się klucza oświadczenia -260.

Ciągi w obiekcie JSON powinny być znormalizowane zgodnie z formatem Normalization Form Canonical Composition (NFC) zdefiniowanym w standardzie Unicode. Aplikacje dekodujące powinny być jednak permisywne i niezawodne w tych aspektach; zdecydowanie zachęca się do akceptacji każdej racjonalnej konwersji typu. Jeśli podczas dekodowania lub przy wykonywaniu późniejszych funkcji porównywania zostaną znalezione dane nieznormalizowane, wdrożenia powinny zachowywać się tak, jakby dane wejściowe były znormalizowane do NFC.

4.    Serializacja i tworzenie ładunku zaświadczenia COVID

Jako wzorzec serializacji stosuje się następujący schemat:

Proces rozpoczyna się od pozyskania danych, np. z repozytorium danych dotyczących zdrowia (lub jakiegoś zewnętrznego źródła danych), i uporządkowania pozyskanych danych zgodnie ze zdefiniowanymi schematami zaświadczenia COVID. W tym procesie przed rozpoczęciem serializacji do CBOR może mieć miejsce konwersja do zdefiniowanego formatu danych oraz przekształcenie do prezentacji czytelnej dla człowieka. Akronimy oświadczeń przyporządkowuje się w każdym przypadku do wyświetlanych nazw przed serializacją i po deserializacji.

Nieobowiązkowa treść danych krajowych nie jest dozwolona w zaświadczeniach wydanych zgodnie z rozporządzeniem (UE) 2021/953 ( 8 ). Treść danych jest ograniczona do zdefiniowanych elementów danych znajdujących się w minimalnym zestawie danych określonym w załączniku do rozporządzenia (UE) 2021/953.

5.    Kodowanie transportowe

5.1.    Surowe dane

W przypadku interfejsów dowolnych danych kontener HCERT i jego ładunki mogą być przekazywane w stanie niezmienionym, z wykorzystaniem dowolnego bazowego 8-bitowego transportu danych charakteryzującego się bezpieczeństwem i niezawodnością. Interfejsy te mogą obejmować komunikację zbliżeniową (ang. Near-Field Communication – NFC), Bluetooth lub transfer przez protokół warstwy aplikacji, np. transfer HCERT od wystawcy na urządzenie przenośne posiadacza.

Jeżeli transfer HCERT od wystawcy do posiadacza odbywa się na podstawie interfejsu wyłącznie prezentacyjnego (np. SMS, e-mail), kodowanie transportu surowych danych oczywiście nie ma zastosowania.

5.2.    Kod kreskowy

5.2.1.    Kompresja ładunku (tokena sieciowego CBOR)

W celu zmniejszenia rozmiaru HCERT oraz poprawy szybkości i niezawodności procesu odczytu HCERT kompresuje się token sieciowy CBOR przy użyciu ZLIB (RFC 1950 ( 9 )) i mechanizmu kompresji Deflate w formacie określonym w RFC 1951 ( 10 ).

5.2.2.    Dwuwymiarowy kod kreskowy QR

Na potrzeby lepszej obsługi starszych urządzeń przeznaczonych do pracy z ładunkami ASCII skompresowany token sieciowy CBOR przed zakodowaniem do postaci dwuwymiarowego kodu kreskowego koduje się jako ASCII przy użyciu Base45.

Do generowania dwuwymiarowego kodu kreskowego stosuje się format QR zdefiniowany w (ISO/IEC 18004:2015). Zalecany jest poziom korekcji błędów „Q” (ok. 25 %). Ponieważ stosuje się Base45, w kodzie QR musi być zastosowane kodowanie alfanumeryczne (model 2, oznaczony symbolami 0010).

Aby umożliwić weryfikatorom wykrycie rodzaju zakodowanych danych oraz wybór właściwego schematu dekodowania i przetwarzania, dane zakodowane przy użyciu Base45 (zgodnie z niniejszą specyfikacją) poprzedzone są ciągiem identyfikatora kontekstu „HC1:”. W przyszłych wersjach niniejszej specyfikacji, które mają wpływ na kompatybilność wsteczną, zdefiniowany zostanie nowy identyfikator kontekstu, przy czym znak następujący po „HC” musi pochodzić ze zbioru znaków [1-9 A-Z]. Kolejność przyrostów jest zdefiniowana w tym porządku, tj. najpierw [1-9], a następnie [A-Z].

Zaleca się, aby kod optyczny był odwzorowywany na nośniku prezentacyjnym o przekątnej wynoszącej 35–60 mm, aby uwzględnić czytniki ze stałym układem optycznym, w przypadku których wymagane jest umieszczenie nośnika prezentacji na powierzchni czytnika.

Jeżeli kod optyczny jest drukowany na papierze przy użyciu drukarek o niskiej rozdzielczości (< 300 dpi), należy zadbać o to, aby każdy symbol (punkt) kodu QR był przedstawiony jako dokładny kwadrat. Skalowanie nieproporcjonalne spowoduje, że w niektórych wierszach lub kolumnach kodu QR znajdą się symbole prostokątne, co w wielu przypadkach utrudni czytelność.

6.    Format listy zaufania (lista krajowych centrów certyfikacji dla podpisujących i certyfikatów dla podpisujących dokumenty)

Każde państwo członkowskie jest zobowiązane do dostarczenia listy zawierającej co najmniej jedno krajowe centrum certyfikacji dla podpisujących (CSCA) i listy wszystkich ważnych certyfikatów dla podpisujących dokumenty (DSC) oraz do dbania o aktualność tych list.

6.1.    Uproszczone zasady dotyczące krajowych centrów certyfikacji dla podpisujących i certyfikatów dla podpisujących dokumenty

Począwszy od niniejszej wersji specyfikacji, państwa członkowskie nie zakładają, że wykorzystywane są jakiekolwiek informacje z listy unieważnionych certyfikatów, ani że okres użytkowania klucza prywatnego jest weryfikowany przez podmioty wdrażające.

Zamiast tego podstawowym mechanizmem sprawdzania ważności jest obecność certyfikatu na najnowszej wersji tej listy certyfikatów.

6.2.    Infrastruktura klucza publicznego elektronicznych dokumentów podróży odczytywanych maszynowo ICAO oraz jej centra zaufania

Państwa członkowskie mogą korzystać z oddzielnego krajowego centrum certyfikacji dla podpisujących, ale mogą również przedkładać swoje istniejące certyfikaty krajowych centrów certyfikacji dla podpisujących elektroniczne dokumenty podróży odczytywane maszynowo lub certyfikaty dla podpisujących dokumenty; mogą nawet zdecydować się na nabycie certyfikatów od (komercyjnych) centrów zaufania i przedłożenie ich. Każdy certyfikat dla podpisujących dokumenty musi być jednak zawsze podpisany przez krajowe centrum certyfikacji dla podpisujących wskazane przez to państwo członkowskie.

7.    Względy bezpieczeństwa

Projektując system z wykorzystaniem niniejszej specyfikacji, państwa członkowskie muszą zidentyfikować, przeanalizować i monitorować określone aspekty bezpieczeństwa.

Należy uwzględnić co najmniej następujące aspekty:

7.1.    Czas ważności podpisu HCERT

Wystawca HCERT jest zobowiązany do ograniczenia okresu ważności podpisu przez określenie czasu wygaśnięcia podpisu. W rezultacie posiadacz świadectwa zdrowia musi okresowo przedłużać jego ważność.

O dopuszczalnym okresie ważności mogą decydować ograniczenia praktyczne. Na przykład podróżny może nie mieć możliwości przedłużenia ważności świadectwa zdrowia podczas podróży za granicą. Może jednak zdarzyć się, że wystawca bierze pod uwagę możliwość pewnego rodzaju naruszenia bezpieczeństwa, co wymaga od niego wycofania certyfikatu dla podpisujących dokumenty (unieważnienia wszystkich świadectw zdrowia wydanych przy użyciu tego klucza, których okres ważności jeszcze nie upłynął). Konsekwencje takiego zdarzenia można ograniczyć przez regularne przerzucanie kluczy wystawców i wymóg przedłużania ważności wszystkich świadectw zdrowia w pewnych rozsądnych odstępach czasu.

7.2.    Zarządzanie kluczami

Niniejsza specyfikacja w dużym stopniu opiera się na silnych mechanizmach kryptograficznych zabezpieczających integralność danych i uwierzytelnianie pochodzenia danych. W związku z tym konieczne jest utrzymanie poufności kluczy prywatnych.

Poufność kluczy kryptograficznych może być zagrożona na szereg różnych sposobów, na przykład:

Aby ograniczyć ryzyko, że algorytm podpisu okaże się słaby, co umożliwi naruszenie kluczy prywatnych w wyniku kryptoanalizy, w niniejszej specyfikacji zaleca się wszystkim uczestnikom wdrożenie dodatkowego, rezerwowego algorytmu podpisu opartego na innych parametrach lub innym problemie matematycznym niż algorytm główny.

Jeżeli chodzi o wspomniane ryzyko związane ze środowiskami operacyjnymi wystawców, wdraża się środki ograniczające to ryzyko w celu zapewnienia skutecznej kontroli, takie jak generowanie, przechowywanie i stosowanie kluczy prywatnych w sprzętowych modułach bezpieczeństwa (ang. hardware security module, HSM). Zdecydowanie zachęca się do stosowania HSM do podpisywania świadectw zdrowia.

Niezależnie od tego, czy wystawca zdecyduje się na stosowanie HSM, należy ustanowić harmonogram przerzucania kluczy, w którym częstotliwość przerzucania kluczy jest proporcjonalna do ekspozycji kluczy na sieci zewnętrzne, inne systemy i personel. Dobrze dobrany harmonogram przerzucania ogranicza również ryzyko związane z błędnie wydanymi świadectwami zdrowia, umożliwiając wystawcy unieważnianie w razie potrzeby takich świadectw zdrowia partiami przez wycofanie klucza.

7.3.    Walidacja danych wejściowych

Niniejsze specyfikacje można wykorzystywać w sposób zakładający wprowadzanie danych z niezaufanych źródeł do systemów, które mogą mieć krytyczne znaczenie dla misji. Aby zminimalizować ryzyko związane z tym wektorem ataku, wszystkie pola danych wejściowych muszą być odpowiednio zwalidowane pod względem poprawności rodzajów danych, długości i zawartości. Podpis wystawcy musi być również weryfikowany przed jakimkolwiek przetworzeniem zawartości formatu kontenera elektronicznego świadectwa zdrowia (HCERT). Walidacja podpisu wystawcy wymaga najpierw analizy chronionego nagłówka wystawcy, w którym potencjalny atakujący może próbować wprowadzić starannie opracowane informacje mające na celu naruszenie bezpieczeństwa systemu.

8.    Zarządzanie zaufaniem

Podpisanie HCERT wymaga klucza publicznego do weryfikacji. Państwa członkowskie udostępniają te klucze publiczne. Ostatecznie każdy weryfikator musi posiadać listę wszystkich kluczy publicznych, którym chce ufać (ponieważ klucz publiczny nie jest częścią HCERT).

System składa się z (tylko) dwóch warstw: dla każdego państwa członkowskiego istnieje co najmniej jeden certyfikat na szczeblu krajowym, a każdy z tych certyfikatów służy do podpisywania co najmniej jednego certyfikatu dla podpisujących dokumenty, który to certyfikat jest używany w codziennej działalności.

Certyfikaty państw członkowskich nazywane są krajowymi centrami certyfikacji dla podpisujących (CSCA) i są (zazwyczaj) certyfikatami z podpisem własnym. Państwa członkowskie mogą mieć więcej niż jeden taki certyfikat (np. w przypadku decentralizacji regionalnej). Te certyfikaty krajowych centrów certyfikacji dla podpisujących regularnie służą do podpisywania certyfikatów dla podpisujących dokumenty (DSC), które to certyfikaty wykorzystuje się do podpisywania HCERT.

„Sekretariat” jest rolą funkcjonalną. Regularnie gromadzi i publikuje certyfikaty dla podpisujących dokumenty państw członkowskich po zweryfikowaniu ich z listą certyfikatów krajowych centrów certyfikacji dla podpisujących (które przekazano i zweryfikowano w inny sposób).

Otrzymana w ten sposób lista certyfikatów dla podpisujących dokumenty zapewnia następnie zagregowany zbiór akceptowanych kluczy publicznych (i odpowiadających im identyfikatorów kluczy), które weryfikatorzy mogą stosować do walidacji podpisów HCERT. Weryfikatorzy muszą regularnie pobierać i aktualizować tę listę.

Takie listy dotyczące poszczególnych państw członkowskich mogą mieć format dostosowany do ich kontekstu krajowego. W związku z tym format pliku tej listy zaufania może być różny, na przykład może to być podpisany JWKS (format zestawu JWK określony w RFC 7517 ( 11 ), sekcja 5) lub dowolny inny format właściwy dla technologii używanej w danym państwie członkowskim.

Aby zapewnić prostotę, państwa członkowskie mogą zarówno przedłożyć swoje istniejące certyfikaty krajowych centrów certyfikacji dla podpisujących ze swoich systemów elektronicznych dokumentów podróży odczytywanych maszynowo ICAO, jak i – zgodnie z zaleceniem WHO – utworzyć certyfikat specjalnie dla tej dziedziny zdrowia.

8.1.    Identyfikator klucza (kid)

Identyfikator klucza (kid) oblicza się podczas tworzenia listy zaufanych kluczy publicznych z certyfikatów dla podpisujących dokumenty i składa się on z obciętego (do pierwszych 8 bajtów) cyfrowego odcisku palca SHA-256 certyfikatu dla podpisujących dokumenty zakodowanego w formacie DER (dane surowe).

Weryfikatorzy nie muszą obliczać identyfikatora klucza na podstawie certyfikatu dla podpisujących dokumenty i mogą bezpośrednio dopasować identyfikator klucza zawarty w wydanym świadectwie zdrowia do identyfikatora klucza znajdującego się na liście zaufania.

8.2.    Różnice w stosunku do modelu zaufania infrastruktury klucza publicznego elektronicznych dokumentów podróży odczytywanych maszynowo ICAO

Chociaż wzorowano się na najlepszych praktykach modelu zaufania infrastruktury klucza publicznego elektronicznych dokumentów podróży odczytywanych maszynowo ICAO, w celu zapewnienia szybkości wprowadza się szereg uproszczeń:

▼M3

9.    Rozwiązanie w zakresie unieważnienia

9.1.    Tworzenie listy unieważnionych DCC (DRL)

Brama sieciowa zapewnia punkty końcowe i funkcje umożliwiające przechowywanie list unieważnionych certyfikatów i zarządzanie nimi:

9.2.    Model zaufania

Wszystkie połączenia są ustanawiane na podstawie standardowego modelu zaufania DCCG w certyfikatach NBTLS i NBUP (zob. zarządzanie certyfikatami). Wszystkie informacje są pakowane i przesyłane za pomocą wiadomości CMS w celu zapewnienia integralności.

9.3.    Budowa partii

9.3.1.    Partia (ang. batch)

Każda lista unieważnionych certyfikatów zawiera jedną pozycję lub większą ich liczbę i jest pakowana w partie zawierające zestaw skrótów (ang. hashes) i ich metadanych. Partia jest niezmienna i określa datę wygaśnięcia, która wskazuje, kiedy daną partię można usunąć. Data wygaśnięcia wszystkich pozycji w partii musi być dokładnie taka sama – oznacza to, że partie muszą być pogrupowane według daty wygaśnięcia i podpisania DSC. Każda partia zawiera maksymalnie 1 000 pozycji. Jeżeli lista unieważnionych certyfikatów składa się z ponad 1 000 pozycji, wówczas tworzy się kilka partii. Każda pozycja może występować w co najwyżej jednej partii. Partia jest pakowana do struktury CMS i podpisywana certyfikatem NBUP kraju wysyłającego.

9.3.2.    Indeks partii (ang. Batch Index)

Po utworzeniu partii brama sieciowa nadaje jej niepowtarzalne ID i partia jest automatycznie dodawana do indeksu. Indeks partii jest uporządkowany według daty modyfikacji, w porządku chronologicznym rosnącym.

9.3.3.    Zachowanie bramy sieciowej

Brama sieciowa przetwarza partie unieważnień bez żadnych zmian: nie może ona aktualizować, usuwać ani dodawać żadnych informacji do partii. Partie są przekazywane wszystkim upoważnionym krajom (zob. rozdział 9.6).

Brama sieciowa aktywnie obserwuje daty wygaśnięcia partii i usuwa partie, które wygasły. Po usunięciu partii brama sieciowa odsyła, w odniesieniu do URL usuniętej partii, komunikat „HTTP 410 Gone”. W związku z tym partia pojawia się w indeksie partii jako „usunięta”.

9.4.    Rodzaje skrótu (ang. Hash Types)

Lista unieważnionych certyfikatów zawiera skróty, które mogą odpowiadać różnym rodzajom/atrybutom unieważnienia. Te rodzaje lub atrybuty są wskazane w tworzeniu list unieważnionych certyfikatów. Obecne rodzaje są następujące:

Tylko pierwsze 128 bitów skrótów zakodowanych jako ciągi (ang. strings) base64 umieszcza się w partiach i wykorzystuje do identyfikacji unieważnionych DCC ( 12 ).

9.4.1.    Rodzaj skrótu: SHA256(Podpis DCC)

W tym przypadku skrót oblicza się na podstawie bajtów podpisu COSE_SIGN1 z CWT. W przypadku podpisów RSA cały podpis zostanie wykorzystany jako dane wejściowe. Wzór dla podpisanych certyfikatów EC-DSA wykorzystuje wartość r jako dane wejściowe:

SHA256(r)

[wymagane w przypadku wszystkich nowych wdrożeń]

9.4.2.    Rodzaj skrótu: SHA256(UCI)

W tym przypadku skrót oblicza się dla ciągu UCI zakodowanego w UTF-8 i przekształconego na tablicę bajtów (ang. byte array).

[przestarzałe ( 13 ), ale obsługiwane ze względu na kompatybilność wsteczną]

9.4.3.    Rodzaj skrótu: SHA256(Wydawanie CountryCode+UCI)

W tym przypadku CountryCode zakodowano jako ciąg UTF-8 złączony z UCI zakodowanym ciągiem UTF-8. Następnie przekształca się go w tablicę bajtów i wykorzystuje jako dane wejściowe do funkcji skrótu.

[przestarzałe2, ale obsługiwane ze względu na kompatybilność wsteczną]

9.5.    Struktura API

9.5.1.    API dostarczająca pozycje unieważnienia

9.5.1.1.   Cel

API dostarcza pozycje listy unieważnionych certyfikatów w partiach, w tym indeks partii.

9.5.1.2.   Punkty końcowe (ang. Endpoints)

9.5.1.2.1.   Punkt końcowy pobrania listy partii

Punkty końcowe są zgodne z prostym wzorem i odsyłają listę partii z małą obwolutą (ang. wrapper) dostarczającą metadane. Partie są sortowane według daty w porządku rosnącym (chronologicznym):

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

Uwaga: Wynik jest domyślnie ograniczony do 1 000 . Jeżeli znacznik „more” jest ustawiony na „true”, odpowiedź wskazuje, że dostępna jest większa liczba partii do pobrania. Aby pobrać więcej pozycji, klient musi ustawić nagłówek (ang. header) If-Modified-Since na datę nie wcześniejszą niż ostatni otrzymany wpis.

Odpowiedź zawiera tablicę JSON o następującej strukturze:

9.5.1.2.1.1.    Kody odpowiedzi

Nagłówek żądania (ang. Request Header)

9.5.1.2.2.   Punkt końcowy pobrania partii

Partie zawierają wykaz identyfikatorów certyfikatu:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

Odpowiedź zawiera CMS z podpisem, który musi odpowiadać certyfikatowi NBUP państwa. Wszystkie elementy na tablicy JSON mają następującą strukturę:

9.5.1.2.2.1.   Pozycje

Uwaga: Obiekt wpisów zawiera obecnie tylko skrót, ale w celu zapewnienia kompatybilności ze zmianami w przyszłości wybrano obiekt, a nie tablicę json.

9.5.1.2.2.2.   Kody odpowiedzi

9.5.1.2.2.3.   Nagłówki odpowiedzi

9.5.1.2.3.   Punkt końcowy przesłania partii

Przesyłanie odbywa się w tym samym punkcie końcowym za pośrednictwem czasownika POST (ang. POST Verb):

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

Partię należy podpisać za pomocą certyfikatu NBUP. Brama sieciowa sprawdza, czy podpis został ustawiony przez NBUP dla danego państwa. Jeżeli kontrola podpisu nie powiodła się, przesłanie nie powiedzie się.

UWAGA: Każda partia jest niezmienna (ang. immutable) i nie może być zmieniana po przesłaniu. Można ją jednak usunąć. Przechowuje się ID każdej usuniętej partii, a przesłanie nowej partii o tym samym ID zostaje odrzucone.

9.5.1.2.4.   Punkt końcowy usuwania partii

Partia może zostać usunięta z tego samego punktu końcowego za pośrednictwem czasownika DELETE (ang. DELETE Verb):

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

lub, ze względu na kompatybilność, do następującego punktu końcowego z czasownikiem POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

9.6.    Ochrona API/RODO

W niniejszej sekcji określono środki służące wdrożeniu w celu zapewnienia zgodności z przepisami rozporządzenia (UE) 2021/953 w odniesieniu do przetwarzania danych osobowych.

9.6.1.    Istniejące uwierzytelnianie

Obecnie brama sieciowa wykorzystuje certyfikat NBTLS do uwierzytelniania państw łączących się z bramą sieciową. Uwierzytelnienie to można wykorzystać do określenia tożsamości państwa podłączonego do bramy sieciowej. Tożsamość tę można następnie wykorzystać do wdrożenia kontroli dostępu.

9.6.2.    Kontrola dostępu

Aby móc zgodnie z prawem przetwarzać dane osobowe, brama sieciowa musi wdrożyć mechanizm kontroli dostępu.

Brama sieciowa wdraża wykaz kontroli dostępu połączony z zabezpieczeniem opartym na rolach. W tym systemie należy zachować dwie tabele – jedną tabelę opisującą, które role mogą stosować które operacje do których zasobów, a drugą tabelę opisującą, które role są przypisane do których użytkowników.

W celu przeprowadzenia kontroli wymaganych w niniejszym dokumencie wymagane są trzy role, tj.:

Następujące punkty końcowe sprawdzają, czy użytkownik posiada rolę RevocationListReader; jeżeli tak, wówczas dostęp zostanie przyznany, jeżeli nie, wówczas zostanie zwrócony komunikat HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Następujące punkty końcowe muszą sprawdzić, czy użytkownik (ang. User) posiada rolę (ang. Role) RevocationUploader; jeżeli tak, wówczas dostęp zostanie przyznany, jeżeli nie, wówczas zostanie zwrócony komunikat HTTP 403 Forbidden:

POST/revocation-list

Następujące punkty końcowe muszą sprawdzić, czy użytkownik posiada rolę RevocationDeleter; jeżeli tak, wówczas dostęp zostanie przyznany, jeżeli nie, wówczas zostanie zwrócony komunikat HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Brama sieciowa zapewnia również wiarygodną metodę, dzięki której administratorzy mogą zarządzać rolami powiązanymi z użytkownikami w taki sposób, aby zmniejszyć prawdopodobieństwo wystąpienia błędów ludzkich, nie obciążając jednocześnie administratorów funkcjonalnych.

▼M1

---

ZAŁĄCZNIK II

ZASADY WYPEŁNIANIA UNIJNEGO CYFROWEGO ZAŚWIADCZENIA COVID

Ogólne zasady dotyczące zestawów wartości ustanowione w niniejszym załączniku mają na celu zapewnienie interoperacyjności na poziomie semantycznym i umożliwiają jednolite wdrożenie techniczne unijnego cyfrowego zaświadczenia COVID. Elementy zawarte w niniejszym załączniku można stosować w odniesieniu do trzech różnych kontekstów (szczepienie/test/powrót do zdrowia) przewidzianych w rozporządzeniu (UE) 2021/953. W niniejszym załączniku wymieniono jedynie elementy, w przypadku których konieczna jest normalizacja semantyczna za pomocą zakodowanych zestawów wartości.

Tłumaczenie zakodowanych elementów na język krajowy należy do kompetencji państw członkowskich.

W przypadku wszystkich pól danych niewymienionych w poniższych opisach zestawów wartości kodowanie opisano w załączniku V.

Jeżeli z jakiegokolwiek powodu nie można zastosować preferowanych systemów kodów wymienionych poniżej, można zastosować inne międzynarodowe systemy kodów, przy czym zapewnia się wskazówki dotyczące sposobu przyporządkowywania kodów z innego systemu kodom z systemu preferowanego. W wyjątkowych przypadkach, gdy odpowiedni kod nie jest dostępny w zdefiniowanych zestawach wartości, jako mechanizm rezerwowy można stosować tekst (wyświetlanie nazw).

Państwa członkowskie stosujące w swoich systemach inne kody przyporządkowują takie kody opisanym zestawom wartości. Państwa członkowskie są odpowiedzialne za wszelkie takie przyporządkowania.

►M4  Ponieważ niektóre zestawy wartości oparte na systemach kodowania przewidzianych w niniejszym załączniku, takie jak zestawy wartości do kodowania szczepionek i testów antygenowych, często się zmieniają, Komisja publikuje je i regularnie aktualizuje przy wsparciu sieci e-zdrowie i Komitetu ds. Bezpieczeństwa Zdrowia. ◄ Zaktualizowane zestawy wartości są publikowane na odpowiedniej stronie internetowej Komisji, jak również na stronie internetowej sieci e-zdrowie. Przedstawia się historię zmian.

1.    Choroba lub czynnik chorobotwórczy, której/którego dotyczy szczepienie/choroba lub czynnik chorobotwórczy, w kierunku której/którego wykonano test/choroba lub czynnik chorobotwórczy, po której/którym posiadacz powrócił do zdrowia: COVID-19 (SARS-CoV-2 lub jeden z jego wariantów)

Kod stosowany w zaświadczeniach 1, 2 i 3.

Stosuje się następujący kod:

2.    Szczepionka przeciwko COVID-19 lub profilaktyka COVID-19

Preferowany system kodów: SNOMED CT lub klasyfikacja anatomiczno-terapeutyczno-chemiczna (ATC).

Kod stosowany w zaświadczeniu 1.

Przykłady kodów z preferowanych systemów kodów, które należy stosować, to kod SNOMED CT 1119305005 (szczepionka zawierająca antygen SARS-CoV-2), 1119349007 (szczepionka zawierająca mRNA SARS-CoV-2) lub J07BX03 (szczepionki przeciwko COVID-19).

Komisja publikuje i regularnie aktualizuje przy wsparciu sieci e-zdrowie zestaw wartości określający kody, które należy stosować zgodnie z systemami kodów ustanowionymi w niniejszej sekcji. Zestaw wartości należy rozszerzyć, gdy nowe typy szczepionek zostaną opracowane i wprowadzone do użytku.

3.    Szczepionka przeciwko COVID-19 stanowiąca produkt leczniczy

Preferowane systemy kodów (w kolejności preferencji):

Nazwa zestawu wartości: szczepionka.

Kod stosowany w zaświadczeniu 1.

Przykładem kodu z preferowanych systemów kodów, który należy stosować, jest EU/1/20/1528 (Comirnaty). Przykład nazwy szczepionki, którą należy stosować jako kod: Sputnik-V (co oznacza Sputnik V).

Komisja publikuje i regularnie aktualizuje przy wsparciu sieci e-zdrowie zestaw wartości określający kody, które należy stosować zgodnie z systemami kodów ustanowionymi w niniejszej sekcji.

Szczepionki są kodowane przy użyciu istniejącego kodu w opublikowanym zestawie wartości, nawet jeśli ich nazwy różnią się w różnych krajach. Wynika to z faktu, że nie istnieje jeszcze światowy rejestr szczepionek obejmujący wszystkie szczepionki, które są obecnie stosowane. Przykład:

Jeżeli nie jest to możliwe lub zalecane w konkretnym przypadku, w opublikowanym zestawie wartości podany zostanie osobny kod.

▼M4

Jeżeli państwo stosujące unijne cyfrowe zaświadczenie COVID postanowi w trakcie trwających badań klinicznych wydać zaświadczenia o szczepieniu uczestnikom tych badań, szczepionkę stanowiącą produkt leczniczy koduje się zgodnie z wzorcem

CT_clinical-trial-identifier

W przypadku gdy badanie kliniczne zostało zarejestrowane w unijnym rejestrze badań klinicznych (EU-CTR), stosuje się identyfikator badania klinicznego z tego rejestru. W pozostałych przypadkach można stosować identyfikatory z innych rejestrów (takich jak clinicaltrials.gov lub rejestr badań klinicznych Australii i Nowej Zelandii).

Identyfikator badania klinicznego musi zawierać prefiks umożliwiający identyfikację rejestru badań klinicznych (np. EUCTR w przypadku unijnego rejestru badań klinicznych, NCT w przypadku rejestru clinicaltrials.gov lub ACTRN w przypadku rejestru badań klinicznych Australii i Nowej Zelandii).

W przypadku gdy Komisja otrzymała od Komitetu ds. Bezpieczeństwa Zdrowia, Europejskiego Centrum ds. Zapobiegania i Kontroli Chorób (ECDC) lub Europejskiej Agencji Leków (EMA) wytyczne dotyczące uznawania zaświadczeń wydawanych na potrzeby szczepionki przeciwko COVID-19 poddawanej badaniom klinicznym, wytyczne te publikuje się bądź jako część dokumentu zawierającego zestawy wartości, bądź oddzielnie.

▼M1

4.    Posiadacz pozwolenia na dopuszczenie do obrotu szczepionki przeciwko COVID-19 lub jej producent

Preferowany system kodów:

Kod stosowany w zaświadczeniu 1.

Przykładem kodu z preferowanych systemów kodów, który należy stosować, jest ORG-100001699 (AstraZeneca AB). Przykład nazwy organizacji, którą należy stosować jako kod: Sinovac-Biotech (co oznacza Sinovac Biotech).

Komisja publikuje i regularnie aktualizuje przy wsparciu sieci e-zdrowie zestaw wartości określający kody, które należy stosować zgodnie z systemami kodów ustanowionymi w niniejszej sekcji.

Różne oddziały tego samego posiadacza pozwolenia na dopuszczenie do obrotu lub tego samego producenta powinny używać kodu istniejącego w opublikowanym zestawie wartości.

Co do zasady w odniesieniu do tej samej szczepionki stosuje się kod odnoszący się do posiadacza pozwolenia na dopuszczenie jej do obrotu w UE, ponieważ nie istnieje jeszcze uzgodniony na szczeblu międzynarodowym rejestr producentów szczepionek ani posiadaczy pozwolenia na dopuszczenie szczepionki do obrotu. Przykłady:

Jeżeli nie jest to możliwe lub zalecane w konkretnym przypadku, w opublikowanym zestawie wartości podany zostanie osobny kod.

▼M4

Jeżeli państwo stosujące unijne cyfrowe zaświadczenie COVID postanowi w trakcie trwających badań klinicznych wydać zaświadczenia o szczepieniu uczestnikom tych badań, informacje o posiadaczu pozwolenia na dopuszczenie do obrotu szczepionki lub jej producencie koduje się przy użyciu wartości wskazanej w zestawie wartości, o ile jest dostępna. W pozostałych przypadkach posiadacz pozwolenia na dopuszczenie do obrotu lub producent kodowany jest przy użyciu zasady przedstawionej w sekcji 3 „Szczepionka przeciwko COVID-19 stanowiąca produkt leczniczy” (CT_clinical-trial-identifier).

▼M1

5.    Numer w serii dawek i łączna liczba dawek w serii;

Kod stosowany w zaświadczeniu 1.

Dwa pola:

5.1.    Seria szczepienia pierwotnego

W przypadku gdy dana osoba otrzymuje dawki w ramach szczepienia pierwotnego, tj. serii szczepień mających zapewnić wystarczającą ochronę na początkowym etapie, (C) odzwierciedla łączną liczbę dawek serii standardowego szczepienia pierwotnego (np. 1 lub 2, w zależności od rodzaju podanej szczepionki). Obejmuje to możliwość stosowania krótszej serii (C=1), w przypadku gdy protokół szczepień stosowany przez państwo członkowskie przewiduje podawanie pojedynczej dawki szczepionki 2-dawkowej osobom uprzednio zakażonym SARS-CoV-2. Zakończoną serię szczepień pierwotnych wskazuje się zatem za pomocą N/C = 1. Na przykład:

W przypadku wydłużenia cyklu szczepień pierwotnych, na przykład dla osób z poważnie osłabionym układem odpornościowymi lub gdy nie przestrzegano zalecanego odstępu między dawkami szczepienia pierwotnego, wszelkie takie dawki należy zakodować jako dawki dodatkowe objęte sekcją 5.2.

▼M2

5.2.    Dawki przypominające

W przypadku gdy dana osoba otrzymuje dawki po serii szczepień pierwotnych, takie dawki przypominające odzwierciedla się w odpowiednich zaświadczeniach w następujący sposób:

Państwa członkowskie wdrażają zasady kodowania określone w niniejszej sekcji do dnia 1 lutego 2022 r.

Państwa członkowskie ponownie wydają, automatycznie lub na wniosek zainteresowanych osób, zaświadczenia, w których podanie dawki przypominającej po serii szczepień pierwotnych szczepionką jednodawkową jest kodowane w taki sposób, że nie można go odróżnić od zakończenia serii szczepień pierwotnych.

Do celów niniejszego załącznika odniesienia do „dawek przypominających” należy rozumieć jako obejmujące również dodatkowe dawki podawane w celu lepszej ochrony osób, które po zakończeniu serii standardowego szczepienia pierwotnego wykazują nieodpowiednie reakcje immunologiczne. W ramach prawnych ustanowionych rozporządzeniem (UE) 2021/953 państwa członkowskie mogą przyjąć środki w celu zaradzenia sytuacji grup szczególnie wrażliwych, które mogą otrzymać dodatkowe dawki w trybie priorytetowym. Na przykład jeżeli państwo członkowskie postanowi o podaniu dodatkowych dawek wyłącznie określonym podgrupom populacji, może zdecydować – zgodnie z art. 5 ust. 1 rozporządzenia (UE) 2021/953 – o wydawaniu zaświadczeń o szczepieniach wskazujących na podanie takich dodatkowych dawek wyłącznie na wniosek, a nie automatycznie. W przypadku przyjęcia takich środków państwa członkowskie informują o tym zainteresowane osoby, a także o tym, że mogą one nadal korzystać z zaświadczenia otrzymanego po zakończeniu serii standardowego szczepienia pierwotnego.

▼M1

6.    Państwo członkowskie lub państwo trzecie, w którym podano szczepionkę/wykonano test

Preferowany system kodów: kody państw ISO 3166.

Kod stosowany w zaświadczeniach 1, 2 i 3.

Zawartość zestawu wartości: pełna lista dwuliterowych kodów, dostępna jako zestaw wartości zdefiniowany w FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). Jeżeli szczepienie lub test przeprowadziła organizacja międzynarodowa (taka jak UNHCR lub WHO), a informacje o kraju nie są dostępne, stosuje się kod organizacji. Komisja publikuje i regularnie aktualizuje przy wsparciu sieci e-zdrowie takie dodatkowe kody.

7.    Rodzaj testu

Kod stosowany w zaświadczeniu 2, a w zaświadczeniu 3 – jeżeli aktem delegowanym wprowadzone zostanie wsparcie dla wydawania zaświadczeń o powrocie do zdrowia opartych na rodzajach testów innych niż test NAAT.

Stosuje się następujące kody.

▼M4

Kod LP217198-3 (Szybki test immunologiczny) wykorzystuje się do wskazania zarówno szybkich testów antygenowych, jak i laboratoryjnych testów antygenowych

▼M1

8.    Producent i nazwa handlowa wykonanego testu (fakultatywne w przypadku testu NAAT)

Kod stosowany w zaświadczeniu 2.

▼M4

Zawartość zestawu wartości obejmuje wybór testu antygenowego wymienionego we wspólnym i uaktualnionym wykazie testów antygenowych na COVID-19, ustanowionym na podstawie zalecenia Rady 2021/C 24/01 i uzgodnionym przez Komitet ds. Bezpieczeństwa Zdrowia. Wykaz ten prowadzi JRC w bazie danych dotyczącej wyrobów do diagnostyki in vitro i metod testowania COVID-19 pod adresem: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

▼M1

W przypadku tego systemu kodów wykorzystuje się odpowiednie pola, takie jak: identyfikator zestawu testu, nazwa testu i producent, zgodnie ze zorganizowanym formatem JRC dostępnym pod adresem: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9.    Wynik testu

Kod stosowany w zaświadczeniu 2.

Stosuje się następujące kody:

▼B

---

ZAŁĄCZNIK III

WSPÓLNA STRUKTURA NIEPOWTARZALNEGO IDENTYFIKATORA ZAŚWIADCZENIA

1.    Wprowadzenie

Każde unijne cyfrowe zaświadczenie COVID (zaświadczenie COVID) musi zawierać niepowtarzalny identyfikator zaświadczenia, który wspiera interoperacyjność zaświadczeń. Identyfikator ten można wykorzystywać do weryfikacji zaświadczenia. Państwa członkowskie są odpowiedzialne za wdrożenie niepowtarzalnego identyfikatora zaświadczenia. Identyfikator ten służy do weryfikacji prawdziwości zaświadczenia oraz w stosownych przypadkach do połączenia z systemem rejestracji (np. z systemem informacyjnym dotyczącym szczepień – IIS). Identyfikatory te umożliwiają również potwierdzenie przez państwa członkowskie (w formie papierowej i elektronicznej), że dane osoby zaszczepiono lub poddano testowi.

2.    Skład niepowtarzalnego identyfikatora zaświadczenia

Niepowtarzalny identyfikator zaświadczenia ma wspólną strukturę i wspólny format ułatwiające interpretację informacji przez człowieka lub maszynę i może odnosić się do takich elementów, jak: państwo członkowskie, w którym miało miejsce szczepienie, sama szczepionka i identyfikator właściwy dla danego państwa członkowskiego. Zapewnia on państwom członkowskim elastyczność w zakresie formatu informacji przy pełnym poszanowaniu przepisów o ochronie danych. Kolejność poszczególnych elementów jest zgodna z określoną hierarchią, która może umożliwiać przyszłe modyfikacje bloków z jednoczesnym zachowaniem ich integralności strukturalnej.

Możliwe rozwiązania dotyczące składu niepowtarzalnego identyfikatora zaświadczenia tworzą spektrum, w którym modułowość i możliwość interpretacji przez człowieka są dwoma głównymi parametrami różnicującymi, a ponadto istnieje jedna podstawowa cecha:

▼M1

3.    Wymogi ogólne

W odniesieniu do niepowtarzalnego identyfikatora zaświadczenia należy spełnić następujące nadrzędne wymogi:

Zapewnia się kompatybilność wsteczną: państwa członkowskie, które na przestrzeni czasu zmieniają strukturę swoich identyfikatorów (w ramach głównej wersji, obecnie ustalonej jako v1), zapewniają, aby dowolne dwa identyczne identyfikatory odpowiadały temu samemu zaświadczeniu o szczepieniu/potwierdzeniu szczepienia. Innymi słowy, państwa członkowskie nie mogą używać identyfikatorów ponownie.

▼B

4.    Warianty niepowtarzalnych identyfikatorów zaświadczeń o szczepieniu

W wytycznych sieci e-zdrowie w sprawie podlegających weryfikacji zaświadczeń o szczepieniu i podstawowych elementów interoperacyjności ( 17 ) przewidziano różne warianty dostępne dla państw członkowskich i innych stron, które to warianty mogą współistnieć w różnych państwach członkowskich. Państwa członkowskie mogą stosować takie różne warianty w różnych wersjach schematu niepowtarzalnego identyfikatora zaświadczenia.

---

ZAŁĄCZNIK IV

ZARZĄDZANIE CERTYFIKATAMI KLUCZY PUBLICZNYCH

1.    Wprowadzenie

Bezpieczna i zaufana wymiana kluczy podpisu unijnych cyfrowych zaświadczeń COVID (zaświadczenia COVID) między państwami członkowskimi jest realizowana za pośrednictwem bramy sieciowej unijnych cyfrowych zaświadczeń COVID (brama sieciowa), która pełni funkcję centralnego repozytorium kluczy publicznych. Poprzez bramę sieciową państwa członkowskie są uprawnione do publikowania kluczy publicznych odpowiadających kluczom prywatnym, które stosują do podpisywania cyfrowych zaświadczeń COVID. Państwa członkowskie mogą korzystać z bramy sieciowej, aby na bieżąco pobierać aktualne materiały dotyczące kluczy publicznych. W późniejszym czasie bramę sieciową można rozszerzyć na wymianę godnych zaufania informacji uzupełniających, które dostarczają państwa członkowskie, takich jak zasady walidacji zaświadczeń COVID. Model zaufania ram zaświadczeń COVID to infrastruktura klucza publicznego. Każde państwo członkowskie posiada co najmniej jedno krajowe centrum certyfikacji dla podpisujących, którego certyfikaty mają stosunkowo długi okres ważności. Zgodnie z decyzją państwa członkowskiego krajowe centrum certyfikacji dla podpisujących może być takie samo lub inne niż centrum certyfikacji wykorzystywane w przypadku dokumentów podróży odczytywanych maszynowo. Krajowe centrum certyfikacji dla podpisujących wydaje certyfikaty klucza publicznego dla krajowych krótko działających podmiotów podpisujących dokumenty (tj. podpisujących zaświadczenia COVID), nazywane certyfikatami dla podpisujących dokumenty. Krajowe centrum certyfikacji dla podpisujących pełni funkcję kotwicy zaufania, dzięki czemu państwa członkowskie, które z niego korzystają, mogą stosować certyfikat krajowego centrum certyfikacji dla podpisujących do walidacji autentyczności i integralności regularnie zmieniających się certyfikatów dla podpisujących dokumenty. Po walidacji państwa członkowskie mogą przekazać te certyfikaty (lub tylko zawarte w nich klucze publiczne) do swoich aplikacji służących do weryfikacji zaświadczeń COVID. Oprócz krajowych centrów certyfikacji dla podpisujących i certyfikatów dla podpisujących dokumenty w bramie sieciowej wykorzystuje się również infrastrukturę klucza publicznego do uwierzytelniania transakcji i podpisywania danych jako podstawę uwierzytelniania oraz jako środek zapewniający integralność kanałów komunikacji między państwami członkowskimi a bramą sieciową.

Podpisy cyfrowe można wykorzystywać do osiągnięcia integralności i autentyczności danych. Infrastruktury klucza publicznego budują zaufanie przez wiązanie kluczy publicznych ze zweryfikowanymi tożsamościami (lub wystawcami). Jest to konieczne, aby umożliwić innym uczestnikom weryfikację pochodzenia danych i tożsamości partnera w komunikacji oraz podjęcie decyzji o zaufaniu. W bramie sieciowej używa się wielu certyfikatów klucza publicznego do zapewnienia autentyczności. W niniejszym załączniku określono, które certyfikaty klucza publicznego są wykorzystywane i jak powinny być zaprojektowane, aby umożliwić szeroko zakrojoną interoperacyjność między państwami członkowskimi. Zawiera on więcej szczegółowych informacji na temat niezbędnych certyfikatów klucza publicznego oraz wytyczne dotyczące szablonów certyfikatów i okresów ważności dla państw członkowskich, które chcą prowadzić własne krajowe centrum certyfikacji dla podpisujących. Ponieważ zaświadczenia COVID muszą być możliwe do sprawdzenia w określonych ramach czasowych (począwszy od wydania do wygaśnięcia po upływie określonego czasu), konieczne jest zdefiniowanie modelu weryfikacji wszystkich podpisów stosowanych na certyfikatach klucza publicznego i zaświadczeniach COVID.

2.    Terminologia

Poniższa tabela zawiera skróty i terminy stosowane w niniejszym załączniku.

3.    Przepływ informacji i usługi bezpieczeństwa bramy sieciowej unijnych cyfrowych zaświadczeń COVID

W niniejszej sekcji przedstawiono przepływ informacji i usługi bezpieczeństwa w systemie bramy sieciowej. Określono w niej również, które klucze i certyfikaty wykorzystuje się do ochrony komunikacji, wysłanych informacji, zaświadczeń COVID oraz podpisanej listy zaufania, która zawiera wszystkie zarejestrowane certyfikaty krajowych centrów certyfikacji dla podpisujących. Brama sieciowa pełni funkcję centrum danych, które umożliwia państwom członkowskim wymianę podpisanych pakietów danych.

Brama sieciowa dostarcza wysłane pakiety danych w stanie niezmienionym, co oznacza, że do otrzymywanych pakietów nie dodaje się żadnych certyfikatów dla podpisującego dokumenty ani nie usuwa się z nich takich certyfikatów. Krajowe systemy zaplecza państw członkowskich muszą mieć możliwość pełnej weryfikacji integralności i autentyczności wysłanych danych. Ponadto krajowe systemy zaplecza i brama sieciowa będą stosować TLS z uwierzytelnianiem wzajemnym, aby ustanowić bezpieczne połączenie. Stanowi to uzupełnienie podpisów zawartych w wymienianych danych.

3.1.    Uwierzytelnianie i ustanawianie połączenia

Do ustanowienia uwierzytelnionego, szyfrowanego kanału między krajowym systemem zaplecza (NB) państwa członkowskiego a środowiskiem bramy sieciowej wykorzystuje się w tej bramie protokół bezpieczeństwa warstwy transportowej (TLS) z uwierzytelnianiem wzajemnym. Brama sieciowa posiada zatem certyfikat serwera TLS – w skrócie DCCGTLS – a krajowe systemy zaplecza posiadają certyfikat klienta TLS – w skrócie NBTLS. Szablony certyfikatów przedstawiono w sekcji 5. Każdy krajowy system zaplecza może dostarczyć własny certyfikat TLS. Certyfikat ten zostanie wyraźnie umieszczony na białej liście, a zatem może być wydany przez publicznie zaufane centrum certyfikacji (np. centrum certyfikacji, który spełnia podstawowe wymogi CA/Browser Forum), przez krajowe centrum certyfikacji lub z podpisem własnym. Każde państwo członkowskie jest odpowiedzialne za swoje dane krajowe i ochronę klucza prywatnego używanego do ustanawiania połączenia z bramą sieciową. Podejście oparte na używaniu własnego certyfikatu wymaga dobrze zdefiniowanego procesu rejestracji i identyfikacji, jak również procedur unieważniania i przedłużania ważności, które opisano w sekcjach4.1, 4.2 i 4.3. Brama sieciowa korzysta z białej listy, do której po udanej rejestracji dodaje się certyfikaty TLS krajowych systemów zaplecza. Bezpieczne połączenie z bramą sieciową mogą nawiązać tylko te krajowe systemy zaplecza, które uwierzytelniają się kluczem prywatnym odpowiadającym certyfikatowi z białej listy. W bramie sieciowej będzie wykorzystywany także certyfikat TLS, który umożliwi krajowym systemom zaplecza weryfikację, czy rzeczywiście ustanawiają połączenie z prawdziwą bramą sieciową, a nie z jakimś złośliwym podmiotem podszywającym się pod tę bramę. Po udanej rejestracji krajowy system zaplecza otrzyma certyfikat bramy sieciowej. Certyfikat DCCGTLS wyda publicznie zaufane centrum certyfikacji (dostępne we wszystkich głównych przeglądarkach internetowych). Obowiązkiem państw członkowskich jest zweryfikowanie, czy ich połączenie z bramą sieciową jest bezpieczne (np. poprzez sprawdzenie zgodności cyfrowego odcisku palca certyfikatu serwera DCCGTLS, z którym nawiązano połączenie, z certyfikatem otrzymanym po rejestracji).

3.2.    Krajowe centra certyfikacji dla podpisujących i model walidacji

Państwa członkowskie uczestniczące w ramach bramy sieciowej muszą korzystać z krajowego centrum certyfikacji dla podpisujących do celów wydawania certyfikatów dla podpisujących dokumenty. Państwa członkowskie mogą posiadać więcej niż jedno takie centrum, np. w przypadku decentralizacji regionalnej. Każde państwo członkowskie może wykorzystywać istniejące centra certyfikacji albo utworzyć specjalne centrum certyfikacji (ewentualnie z podpisem własnym) na potrzeby systemu zaświadczeń COVID.

Państwa członkowskie muszą przedstawić certyfikat(-y) krajowego centrum certyfikacji dla podpisujących operatorowi bramy sieciowej podczas procedury oficjalnej rejestracji. Po udanej rejestracji państwa członkowskiego (zob. więcej szczegółowych informacji w sekcji 4.1) operator bramy sieciowej zaktualizuje podpisaną listę zaufania, która zawiera wszystkie certyfikaty krajowych centrów certyfikacji dla podpisujących aktywne w ramach zaświadczeń COVID. Operator bramy sieciowej będzie stosował specjalną parę kluczy asymetrycznych do podpisywania listy zaufania i certyfikatów w środowisku offline. Klucz prywatny nie będzie przechowywany w systemie online bramy sieciowej, tak aby naruszenie bezpieczeństwa systemu online nie umożliwiało atakującemu naruszenia bezpieczeństwa listy zaufania. Podczas procesu rejestracji krajowe systemy zaplecza otrzymają odpowiedni certyfikat kotwicy zaufania DCCGTA.

Państwa członkowskie mogą pobierać listę zaufania z bramy sieciowej na potrzeby swoich procedur weryfikacji. Krajowe centrum certyfikacji dla podpisujących definiuje się jako centrum certyfikacji, które wydaje certyfikaty dla podpisujących dokumenty, w związku z czym państwa członkowskie, które stosują wielopoziomową hierarchię centrów certyfikacji (np. główny urząd certyfikacji -> krajowe centrum certyfikacji dla podpisujących-> certyfikaty dla podpisujących dokumenty), muszą wskazać podrzędne centrum certyfikacji, które wydaje certyfikaty dla podpisujących dokumenty. W takim przypadku jeżeli państwo członkowskie korzysta z istniejącego centrum certyfikacji, w systemie zaświadczeń COVID wszystkie centra certyfikacji poza krajowym centrum certyfikacji dla podpisujących będą ignorowane i tylko to centrum certyfikacji będzie figurowało na białej liście jako kotwica zaufania (mimo że jest to podrzędne centrum certyfikacji). Wynika to z tego, że w modelu ICAO dopuszcza się tylko dwa poziomy – poziom głównego krajowego centrum certyfikacji dla podpisujących i poziom „liścia”, tj. certyfikat dla podpisujących dokumenty podpisany przez to właśnie centrum certyfikacji.

W przypadku gdy państwo członkowskie prowadzi własne krajowe centrum certyfikacji dla podpisujących, państwo to jest odpowiedzialne za bezpieczne funkcjonowanie tego centrum i zarządzanie jego kluczami. Krajowe centrum certyfikacji dla podpisujących pełni funkcję kotwicy zaufania w odniesieniu do certyfikatów dla podpisujących dokumenty, w związku z czym ochrona klucza prywatnego tego centrum ma zasadnicze znaczenie dla integralności środowiska zaświadczeń COVID. Modelem weryfikacji w infrastrukturze klucza publicznego zaświadczeń COVID jest model zagnieżdżony, który stanowi, że wszystkie certyfikaty w ścieżce walidacji certyfikatów muszą być ważne w danym momencie (tj. w momencie walidacji podpisu). W związku z tym zastosowanie mają następujące ograniczenia:

Sekcja 4.2 zawiera zalecenia dotyczące okresów ważności.

3.3.    Integralność i autentyczność wysłanych danych

Po udanym uwierzytelnieniu wzajemnym krajowe systemy zaplecza mogą wykorzystywać bramę sieciową, by wysyłać i pobierać podpisane cyfrowo pakiety danych. Na początku te pakiety danych zawierają certyfikaty państw członkowskich dla podpisujących dokumenty. Para kluczy, której krajowy system zaplecza używa do podpisu cyfrowego wysyłanych pakietów danych w systemie bramy sieciowej, jest nazywana parą kluczy do podpisu danych wysyłanych przez krajowy system zaplecza, a odpowiadający jej certyfikat klucza publicznego nazywa się w skrócie certyfikatem NBUP. Każde państwo członkowskie posiada własny certyfikat NBUP, który może być certyfikatem z podpisem własnym lub certyfikatem wydanym przez istniejące centrum certyfikacji, takie jak publiczne centrum certyfikacji (tj. centrum certyfikacji, które wydaje certyfikaty zgodnie z podstawowymi wymogami CA/Browser Forum). Certyfikat NBUP musi różnić się do wszelkich innych certyfikatów, których używa państwo członkowskie (tj. certyfikatu krajowego centrum certyfikacji dla podpisujących, certyfikatu klienta TLS lub certyfikatu dla podpisujących dokumenty).

Państwa członkowskie muszą dostarczyć certyfikat wysyłania danych operatorowi bramy sieciowej podczas procedury pierwszej rejestracji (zob. więcej szczegółowych informacji w sekcji 4.1). Każde państwo członkowskie jest odpowiedzialne za swoje dane krajowe i musi chronić klucz prywatny, którego używa się do podpisywania wysyłanych danych.

Inne państwa członkowskie mogą zweryfikować podpisane pakiety danych za pomocą certyfikatów wysyłania danych, których to certyfikatów dostarcza brama sieciowa. Brama sieciowa weryfikuje autentyczność i integralność wysłanych danych za pomocą certyfikatu wysyłania danych krajowego systemu zaplecza, zanim zostaną one udostępnione innym państwom członkowskim.

3.4.    Wymogi dotyczące architektury technicznej bramy sieciowej

Wymogi dotyczące architektury technicznej bramy sieciowej są następujące:

4.    Zarządzanie cyklem życia certyfikatu

4.1.    Rejestracja krajowych systemów zaplecza

Państwa członkowskie muszą się zarejestrować u operatora bramy sieciowej, aby uczestniczyć w systemie bramy sieciowej. W niniejszej sekcji opisano procedurę techniczną i operacyjną, której trzeba dopełnić w celu zarejestrowania krajowego systemu zaplecza.

W celu przeprowadzenia procesu rejestracji operator bramy sieciowej i państwo członkowskie muszą wymienić się informacjami na temat osób wyznaczonych do kontaktów w sprawach technicznych. Zakłada się, że osoby te posiadają uprawnienia przyznane przez państwa członkowskie, a identyfikacja/uwierzytelnienie odbywa się innymi kanałami. Na przykład uwierzytelnienie może polegać na tym, że osoba wyznaczona przez dane państwo członkowskie do kontaktów w sprawach technicznych wysyła pocztą elektroniczną certyfikaty jako pliki zaszyfrowane hasłem, a hasło przekazuje operatorowi bramy sieciowej drogą telefoniczną. Można wykorzystać również inne bezpieczne kanały określone przez operatora bramy sieciowej.

W trakcie procesu rejestracji i identyfikacji państwa członkowskie muszą dostarczyć trzy certyfikaty cyfrowe:

Wszystkie dostarczone certyfikaty muszą spełniać wymogi określone w sekcji 5. Operator bramy sieciowej zweryfikuje, czy przekazane certyfikaty spełniają wymogi określone w sekcji 5. Po identyfikacji i rejestracji operator bramy sieciowej:

4.2.    Centra certyfikacji, okresy ważności i przedłużanie ważności

W przypadku gdy państwo członkowskie chce prowadzić własne krajowe centrum certyfikacji dla podpisujących, certyfikaty krajowego centrum certyfikacji dla podpisujących mogą być certyfikatami z podpisem własnym. Pełnią one funkcję kotwic zaufania państwa członkowskiego, dlatego państwo członkowskie musi solidnie chronić klucz prywatny odpowiadający kluczowi publicznemu certyfikatu krajowego centrum certyfikacji dla podpisujących. Zaleca się, aby państwa członkowskie na potrzeby swojego krajowego centrum certyfikacji dla podpisujących korzystały z systemu offline, tj. z systemu komputerowego, który nie jest podłączony do żadnej sieci. W celu uzyskiwania dostępu do systemu stosuje się kontrolę wieloosobową (np. zgodnie z zasadą „czworga oczu”). Po podpisaniu certyfikatów dla podpisujących dokumenty stosuje się kontrole operacyjne, a system, w którym znajduje się klucz prywatny krajowego centrum certyfikacji dla podpisujących, przechowuje się w bezpiecznym miejscu ze ścisłą kontrolą dostępu. Do celów lepszej ochrony klucza prywatnego krajowego centrum certyfikacji dla podpisujących można wykorzystać sprzętowe moduły bezpieczeństwa lub karty elektroniczne. Certyfikaty cyfrowe posiadają okres ważności, który zmusza do przedłużania ważności certyfikatu. Przedłużanie ważności jest konieczne, żeby korzystać z nowych kluczy kryptograficznych i dostosować wielkość klucza, w przypadku gdy nowe usprawnienia obliczeń lub nowe ataki zagrażają bezpieczeństwu stosowanego algorytmu kryptograficznego. Zastosowanie ma model zagnieżdżony (ang. shell model) (zob. sekcja 3.2).

Z uwagi na jednoroczny okres ważności cyfrowych zaświadczeń COVID zaleca się następujące okresy ważności:

Na potrzeby terminowego przedłużania ważności zaleca się następujące okresy użytkowania kluczy prywatnych:

Aby zapewnić sprawne działanie, państwa członkowskie muszą tworzyć nowe certyfikaty wysyłania danych i certyfikaty TLS terminowo, np. na miesiąc przed wygaśnięciem. Ważność certyfikatów krajowego centrum certyfikacji dla podpisujących i certyfikatów dla podpisujących dokumenty należy przedłużać co najmniej na miesiąc przed upływem terminu użytkowania klucza prywatnego (biorąc pod uwagę niezbędne procedury operacyjne). Państwa członkowskie muszą dostarczyć operatorowi bramy sieciowej zaktualizowane certyfikaty: certyfikat krajowego centrum certyfikacji dla podpisujących, certyfikat wysyłania danych i certyfikat TLS. Certyfikaty, które utraciły ważność, usuwa się z białej listy i listy zaufania.

Państwa członkowskie i operator bramy sieciowej muszą monitorować ważność swoich certyfikatów. Nie istnieje żaden podmiot centralny, który prowadzi rejestr ważności certyfikatów i przekazuje uczestnikom informacje na ten temat.

4.3.    Unieważnianie certyfikatów

Ogólnie rzecz biorąc, certyfikaty cyfrowe może unieważniać wydający je organ certyfikacji, wykorzystując w tym celu listy unieważnionych certyfikatów lub usługę respondera OCSP (ang. online certificate status protocol). Na potrzeby systemu zaświadczeń COVID krajowe centra certyfikacji dla podpisujących powinny udostępniać listy unieważnionych certyfikatów. Nawet jeśli inne państwa członkowskie nie korzystają obecnie z tych list unieważnionych certyfikatów, należy zintegrować te listy na potrzeby przyszłych zastosowań. W przypadku gdy krajowe centrum certyfikacji dla podpisujących postanowi nie udostępniać list unieważnionych certyfikatów, należy przedłużyć okres ważności certyfikatów dla podpisujących dokumenty wydanych przez to krajowe centrum certyfikacji, kiedy listy te staną się obowiązkowe. Do walidacji certyfikatów dla podpisujących dokumenty weryfikatorzy powinni korzystać nie z OCSP, a z list unieważnionych certyfikatów. Zaleca się, aby krajowy system zaplecza przeprowadzał niezbędną walidację certyfikatów dla podpisujących dokumenty pobranych z bramy sieciowej zaświadczeń COVID i przekazywał krajowym walidatorom zaświadczeń COVID jedynie zestaw zaufanych i zwalidowanych certyfikatów dla podpisujących dokumenty. W ramach procesu walidacji walidatorzy zaświadczeń COVID nie powinni w odniesieniu do certyfikatów dla podpisujących dokumenty sprawdzać, czy doszło do unieważnienia. Jednym z powodów jest ochrona prywatności posiadaczy zaświadczeń COVID przez unikanie ryzyka, że usługa respondera OCSP umożliwia monitorowanie posługiwania się jakimkolwiek konkretnym certyfikatem dla podpisujących dokumenty.

Państwa członkowskie mogą samodzielnie usuwać swoje certyfikaty dla podpisujących dokumenty z bramy sieciowej, korzystając z ważnych certyfikatów wysyłania danych i certyfikatów TLS. Usunięcie certyfikatu dla podpisujących dokumenty oznacza, że zaświadczenia COVID wydane z wykorzystaniem tego certyfikatu staną się nieważne, w momencie gdy państwa członkowskie pobiorą zaktualizowane listy certyfikatów dla podpisujących dokumenty. Kluczowe znaczenie ma ochrona klucza prywatnego odpowiadającego certyfikatom dla podpisujących dokumenty. W przypadku gdy państwa członkowskie są zmuszone unieważnić certyfikat wysyłania danych lub certyfikat TLS, np. wskutek naruszenia bezpieczeństwa krajowego systemu zaplecza, muszą poinformować o tym operatora bramy sieciowej Operator bramy sieciowej może wówczas cofnąć zaufanie do danego certyfikatu, np. usuwając go z białej listy TLS. Operator bramy sieciowej może usunąć certyfikaty wysyłania danych z bazy danych bramy sieciowej. Pakiety podpisane przy użyciu klucza prywatnego odpowiadającego temu certyfikatowi wysyłania danych staną się nieważne, gdy krajowy system zaplecza cofnie zaufanie w odniesieniu do unieważnionego certyfikatu. W przypadku gdy konieczne jest unieważnienie certyfikatu krajowego centrum certyfikacji dla podpisujących, państwa członkowskie informują o tym operatora bramy sieciowej, jak również pozostałe państwa członkowskie, z którymi utrzymują relacje zaufania. Operator bramy sieciowej wyda nową listę zaufania, która nie będzie już zawierała unieważnionych certyfikatów. Wszystkie certyfikaty dla podpisujących dokumenty wydane przez to krajowe centrum certyfikacji dla podpisujących staną się nieważne, gdy państwa członkowskie zaktualizują magazyny zaufania krajowego systemu zaplecza. W przypadku gdy konieczne jest unieważnienie certyfikatu DCCGTLS lub DCCGTA, operator bramy sieciowej i państwa członkowskie muszą współpracować, by ustanowić nowe zaufane połączenie z serwerem TLS i nową listę zaufania.

5.    Szablony certyfikatów

W niniejszej sekcji określono wymogi i wytyczne kryptograficzne, a także wymogi dotyczące szablonów certyfikatów. Określono w niej również szablony certyfikatów w odniesieniu do certyfikatów bramy sieciowej.

5.1.    Wymogi kryptograficzne

Algorytmy kryptograficzne i mechanizmy szyfrowania TLS wybiera się na podstawie aktualnego zalecenia niemieckiego Urzędu Federalnego ds. Bezpieczeństwa Informacji (BSI) lub SOG-IS. Zalecenia te i zalecenia innych instytucji i organizacji normalizacyjnych są podobne. Zalecenia te można znaleźć w wytycznych technicznych TR 02102-1 i TR 02102-2 ( 18 ) lub w uzgodnionych mechanizmach kryptograficznych SOG-IS ( 19 ).

5.1.1.    Wymogi dotyczące certyfikatu dla podpisujących dokumenty

Zastosowanie mają wymogi przewidziane w załączniku I sekcja 3.2.2. W związku z tym zdecydowanie zaleca się, aby podpisujący dokumenty stosowali algorytm podpisu cyfrowego krzywej eliptycznej (ECDSA) z NIST-p-256 (zdefiniowany w dodatku D do FIPS PUB 186-4). Inne krzywe eliptyczne nie są obsługiwane. Ze względu na ograniczone miejsce w zaświadczeniu COVID państwa członkowskie nie powinny stosować schematu RSA-PSS, nawet jeśli jest on dozwolony jako algorytm rezerwowy. W przypadku gdy państwa członkowskie stosują RSA-PSS, powinny stosować rozmiar modułu wynoszący 2048 bitów lub maksymalnie 3072 bity. SHA-2 o długości wyjściowej ≥ 256 bitów stosuje się jako kryptograficzną funkcję skrótu (zob. ISO/IEC 10118-3:2004) w odniesieniu do podpisu certyfikatu dla podpisujących dokumenty.

5.1.2.    Wymogi dotyczące certyfikatu TLS, certyfikatu wysyłania danych i certyfikatu krajowego centrum certyfikacji dla podpisujących

W poniższej tabeli podsumowano główne wymogi dotyczące algorytmów kryptograficznych i długości klucza w przypadku certyfikatów cyfrowych i podpisów kryptograficznych w kontekście bramy sieciowej (stan na 2021 r.):

Zalecaną krzywą eliptyczną dla ECDSA jest NIST-p-256 ze względu na jej powszechne stosowanie.

5.2.    Certyfikat krajowego centrum certyfikacji dla podpisujących (NBCSCA)

W poniższej tabeli przedstawiono wytyczne dotyczące szablonu certyfikatu NBCSCA, w przypadku gdy państwo członkowskie postanowi prowadzić własne krajowe centrum certyfikacji dla podpisujących na potrzeby systemu zaświadczeń COVID.

Pozycje pogrubione są wymagane (muszą znajdować się w certyfikacie), pozycje kursywą są zalecane (powinny znajdować się w certyfikacie). W przypadku nieobecnych pól nie określono żadnych zaleceń.

Nazwa podmiotu nie może być pusta i musi być niepowtarzalna w danym państwie członkowskim. Kod państwa (c) musi odpowiadać państwu członkowskiemu, które będzie korzystało z tego certyfikatu krajowego centrum certyfikacji dla podpisujących. Certyfikat musi zawierać niepowtarzalny identyfikator klucza podmiotu (ang. subject key identifier, SKI) zgodny z RFC 5280 ( 20 ).

5.3.    Certyfikat dla podpisujących dokumenty (DSC)

Poniższa tabela zawiera wytyczne dotyczące certyfikatu dla podpisujących dokumenty. Pozycje pogrubione są wymagane (muszą znajdować się w certyfikacie), pozycje kursywą są zalecane (powinny znajdować się w certyfikacie). W przypadku nieobecnych pól nie określono żadnych zaleceń.

Certyfikat dla podpisujących dokumenty musi być podpisany kluczem prywatnym odpowiadającym certyfikatowi krajowego centrum certyfikacji dla podpisujących używanemu przez państwo członkowskie.

Należy stosować następujące rozszerzenia:

Ponadto świadectwo powinno zawierać rozszerzenie punktu dystrybucji listy unieważnionych certyfikatów wskazujące listę unieważnionych certyfikatów dostarczaną przez krajowe centrum certyfikacji dla podpisujących, które wydało certyfikat dla podpisujących dokumenty.

Certyfikat dla podpisujących dokumenty może zawierać rozszerzenie użytkowania klucza o zero lub więcej identyfikatorów zasad użytkowania klucza ograniczających rodzaje HCERT, które ten certyfikat może weryfikować. Jeżeli występuje co najmniej jeden identyfikator, weryfikatorzy sprawdzają użytkowania klucza w odniesieniu do przechowywanego HCERT. W tym celu zdefiniowano następujące wartości extendedKeyUsage:

W przypadku braku jakiegokolwiek rozszerzenia użytkowania klucza (tj. braku rozszerzeń lub zerowych rozszerzeń) certyfikat ten można stosować do walidacji dowolnego rodzaju HCERT. Inne dokumenty mogą zawierać zdefiniowane odpowiednie dodatkowe rozszerzone identyfikatory zasad użytkowania klucza stosowane przy walidacji HCERT.

5.4.    Certyfikaty wysyłania danych (NBUP)

Poniższa tabela zawiera wytyczne dotyczące certyfikatu wysyłania danych krajowego systemu zaplecza. Pozycje pogrubione są wymagane (muszą znajdować się w certyfikacie), pozycje kursywą są zalecane (powinny znajdować się w certyfikacie). W przypadku nieobecnych pól nie określono żadnych zaleceń.

5.5.    Certyfikat uwierzytelniania klienta TLS krajowego systemu zaplecza (NBTLS)

Poniższa tabela zawiera wytyczne dotyczące certyfikatu uwierzytelniania klienta TLS krajowego systemu zaplecza. Pozycje pogrubione są wymagane (muszą znajdować się w certyfikacie), pozycje kursywą są zalecane (powinny znajdować się w certyfikacie). W przypadku nieobecnych pól nie określono żadnych zaleceń.

Certyfikat może również zawierać uwierzytelnienie serwera (1.3.6.1.5.5.7.3.1) rozszerzonego użytkowania klucza, lecz nie jest to wymagane.

5.6.    Certyfikat podpisu listy zaufania (DCCGTA)

W poniższej tabeli zdefiniowano certyfikat kotwicy zaufania bramy sieciowej.

5.7.    Certyfikaty serwera TLS bramy sieciowej (DCCGTLS)

W poniższej tabeli zdefiniowano certyfikat TLS bramy sieciowej.

Certyfikat może również zawierać uwierzytelnienie serwera (1.3.6.1.5.5.7.3.2) rozszerzonego użytkowania klucza, lecz nie jest to wymagane.

Certyfikat TLS bramy sieciowej wydaje publicznie zaufane centrum certyfikacji (dostępne we wszystkich głównych przeglądarkach i systemach operacyjnych, spełniające podstawowe wymogi CA/Browser Forum).

▼M1

---

ZAŁĄCZNIK V

SCHEMAT JSON

1.    Wprowadzenie

Niniejszy załącznik ustanawia techniczną strukturę danych na potrzeby unijnych cyfrowych zaświadczeń COVID, przedstawioną w postaci schematu JSON. Dokument zawiera szczegółowe instrukcje dotyczące poszczególnych pól danych.

2.    Lokalizacja i wersje schematu JSON

Miarodajny schemat JSON dla unijnych cyfrowych zaświadczeń COVID jest dostępny pod adresem https://github.com/ehn-dcc-development/ehn-dcc-schema. Inne lokalizacje nie są miarodajne, ale mogą być wykorzystywane do przygotowania przyszłych zmian.

Domyślnie aktualna wersja określona w niniejszym załączniku i stosowana przez wszystkie państwa obecnie wydające zaświadczenia jest widoczna pod wskazanym adresem URL.

Kolejna wersja, która ma być stosowana w wyznaczonym terminie przez wszystkie państwa, jest widoczna pod wskazanym adresem URL przy użyciu znakowania wersji, co zostało opisane bardziej szczegółowo w pliku Readme.

▼M3

3.    Wspólne struktury i wymagania ogólne

Nie wydaje się unijnego cyfrowego zaświadczenia COVID, jeżeli ze względu na brakujące informacje nie wszystkie pola danych można prawidłowo wypełnić zgodnie z niniejszą specyfikacją. Powyższego nie należy interpretować jako wpływającego na obowiązek państw członkowskich w zakresie wydawania unijnych cyfrowych zaświadczeń COVID.

Informacje we wszystkich polach można podawać przy użyciu pełnego zestawu znaków UNICODE 13.0 zakodowanych przy użyciu UTF-8, chyba że znaki te wyraźnie ograniczają się do zestawów wartości lub węższych zestawów znaków.

Wspólna struktura jest następująca:

„JSON”:{

„ver”:<informacje dotyczące wersji>,

„nam”:{

<informacje dotyczące imienia i nazwiska osoby>

},

„dob”:<data urodzenia>,

„v” lub „t” lub „r”:[

{<dawka szczepionki lub informacja o badaniu lub powrocie do zdrowia, jeden wpis>}

]

}

Szczegółowe informacje na temat poszczególnych kategorii i pól przedstawiono w kolejnych sekcjach.

W przypadku gdy przepisy wskazują, że pole powinno zostać pominięte, oznacza to, że jego zawartość musi być pusta i że ani nazwa, ani wartość pola nie są dozwolone w treści.

3.1.    Wersja

Należy podać informacje na temat wersji. Zapisywanie wersji następuje zgodnie z wersjonowaniem semantycznym (ang. Semantic Versioning) (semver: https://semver.org). W czasie wydawania zaświadczenia powinna to być jedna z oficjalnie opublikowanych wersji (aktualna lub jedna ze starszych oficjalnie opublikowanych wersji). Więcej informacji na ten temat znajduje się w sekcji dotyczącej lokalizacji schematu JSON (ang. JSON Schema).

3.2.    Imię i nazwisko oraz data urodzenia osoby

Imię i nazwisko osoby to oficjalne pełne imię i nazwisko osoby, odpowiadające imieniu i nazwisku podanym w dokumentach podróży. Identyfikatorem struktury jest nam. Należy podać imię i nazwisko dokładnie 1 (jednej) osoby.

3.3.    Kategorie informacji specyficznych dla danego typu zaświadczenia

W schemacie JSON obsługiwane są trzy kategorie pozycji obejmujące informacje specyficzne dla danego typu zaświadczenia. Każde unijne cyfrowe zaświadczenie COVID-19 zawiera dokładnie 1 (jedną) kategorię. Puste kategorie nie są dozwolone.

▼M1

4.    Informacje specyficzne dla danego typu zaświadczenia

4.1.    Zaświadczenie o szczepieniu

Kategoria „szczepienie”, jeżeli występuje, musi zawierać dokładnie 1 (jedną) pozycję opisującą dokładnie jedno szczepienie (jedną dawkę). Wszystkie elementy kategorii „szczepienia” są obowiązkowe, puste wartości nie są obsługiwane.

4.2.    Zaświadczenie o wyniku testu

Kategoria „test”, jeżeli występuje, musi zawierać dokładnie 1 (jedną) pozycję opisującą dokładnie jeden wynik testu.

4.3.    Zaświadczenie o powrocie do zdrowia

Kategoria „powrót do zdrowia”, jeżeli występuje, musi zawierać dokładnie 1 (jedną) pozycję zawierającą dokładnie jedno oświadczenie dotyczące powrotu do zdrowia. Wszystkie elementy kategorii „powrót do zdrowia” są obowiązkowe, puste wartości nie są obsługiwane.

▼M3

---

ZAŁĄCZNIK VI

OBOWIĄZKI PAŃSTW CZŁONKOWSKICH JAKO WSPÓŁADMINISTRATORÓW W ODNIESIENIU DO BRAMY SIECIOWEJ UNIJNEGO CYFROWEGO ZAŚWIADCZENIA COVID NA POTRZEBY WYMIANY LIST UNIEWAŻNIONYCH CERTYFIKATÓW DCC

SEKCJA 1

Podsekcja 1

Podział obowiązków

Podsekcja 2

Obowiązki i role w zakresie rozpatrywania wniosków osób, których dane dotyczą, oraz w zakresie informowania takich osób

SEKCJA 2

Zarządzanie cyberincydentami, w tym naruszeniami ochrony danych osobowych

SEKCJA 3

Ocena skutków dla ochrony danych

---

ZAŁĄCZNIK VII

OBOWIĄZKI KOMISJI JAKO PODMIOTU PRZETWARZAJĄCEGO DANE W ODNIESIENIU DO BRAMY SIECIOWEJ UNIJNEGO CYFROWEGO ZAŚWIADCZENIA COVID NA POTRZEBY WSPIERANIA WYMIANY LIST UNIEWAŻNIONYCH CERTYFIKATÓW DCC

Komisja:

---

( 1 ) rfc8392 (ietf.org).

( 2 ) rfc8152 (ietf.org).

( 3 ) rfc8230 (ietf.org).

( 4 ) rfc8392 (ietf.org).

( 5 ) rfc8392 (ietf.org).

( 6 ) rfc7159 (ietf.org).

( 7 ) rfc7049 (ietf.org).

( 8 ) Rozporządzenie Parlamentu Europejskiego i Rady (UE) 2021/953 z dnia 14 czerwca 2021 r. w sprawie ram wydawania, weryfikowania i uznawania interoperacyjnych zaświadczeń o szczepieniu, o wyniku testu i o powrocie do zdrowia w związku z COVID-19 (unijne cyfrowe zaświadczenie COVID) w celu ułatwienia swobodnego przemieszczania się w czasie pandemii COVID-19, Dz.U. L 211 z 15.6.2021, s. 1.

( 9 ) rfc1950 (ietf.org).

( 10 ) rfc1951 (ietf.org).

( 11 ) rfc7517 (ietf.org).

( 12 ) W odniesieniu do szczegółowych opisów API należy również wziąć pod uwagę pkt 9.5.1.2.

( 13 ) Przestarzałe oznacza, że funkcja ta nie jest brana pod uwagę w przypadku nowych wdrożeń, lecz jest obsługiwana w odniesieniu do już realizowanych wdrożeń przez ściśle określony czas.

( 14 ) rfc3986 (ietf.org)

( 15 ) W przypadku wdrożenia wykorzystującego kody QR państwa członkowskie mogłyby rozważyć zastosowanie dodatkowego zestawu znaków o łącznej długości do 72 znaków (w tym 27–30 znaków samego identyfikatora) do przekazywania innych informacji. Określenie tych informacji należy do państw członkowskich.

( 16 ) Algorytm Luhna mod N jest rozszerzoną wersją algorytmu Luhna (zwanego również algorytmem mod 10) dotyczącą kodów numerycznych i stosowaną na przykład do obliczania sumy kontrolnej w przypadku numerów kart kredytowych. Rozszerzona wersja umożliwia stosowanie tego algorytmu do sekwencji wartości przy dowolnej podstawie (w tym przypadku znaków alfabetycznych).

( 17 ) https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf

( 18 ) BSI – Wytyczne techniczne TR-02102 (bund.de).

( 19 ) SOG-IS – Dokumenty potwierdzające (sogis.eu)

( 20 ) rfc5280 (ietf.org).

( 21 ) rfc5280 (ietf.org).