02021D1073 — CS — 25.04.2022 — 003.001

Tento dokument slouží výhradně k informačním účelům a nemá žádný právní účinek. Orgány a instituce Evropské unie nenesou za jeho obsah žádnou odpovědnost. Závazná znění příslušných právních předpisů, včetně jejich právních východisek a odůvodnění, jsou zveřejněna v Úředním věstníku Evropské unie a jsou k dispozici v databázi EUR-Lex. Tato úřední znění jsou přímo dostupná přes odkazy uvedené v tomto dokumentu

►B PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) 2021/1073 ze dne 28. června 2021, kterým se stanoví technické specifikace a pravidla k provedení rámce pro důvěryhodnost pro digitální certifikát EU COVID stanoveného nařízením Evropského parlamentu a Rady (EU) 2021/953 (Text s významem pro EHP) (Úř. věst. L 230 30.6.2021, s. 32)

Ve znění:









▼B

PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) 2021/1073

ze dne 28. června 2021,

kterým se stanoví technické specifikace a pravidla k provedení rámce pro důvěryhodnost pro digitální certifikát EU COVID stanoveného nařízením Evropského parlamentu a Rady (EU) 2021/953

(Text s významem pro EHP)







Článek 1

Technické specifikace pro digitální certifikát EU COVID, které stanoví obecnou datovou strukturu, mechanismy kódování a mechanismus kódování při přenosu ve strojově čitelném optickém formátu, jsou stanoveny v příloze I.

Článek 2

Pravidla pro vyplňování certifikátů uvedených v čl. 3 odst. 1 nařízení (EU) 2021/953 jsou stanovena v příloze II tohoto rozhodnutí.

Článek 3

Požadavky na společnou strukturu jedinečného identifikátoru certifikátu jsou stanoveny v příloze III.

▼M1

Článek 4

Pravidla správy platná pro certifikáty veřejných klíčů ve vztahu k bráně pro digitální certifikát EU COVID, která podporují aspekty interoperability rámce pro důvěryhodnost, jsou stanovena v příloze IV.

▼M1

Článek 5

Společná koordinovaná datová struktura pro údaje, které mají být zahrnuty do certifikátů uvedených v čl. 3 odst. 1 nařízení (EU) 2021/953 s použitím JavaScriptové objektové notace (JSON), je stanovena v příloze V tohoto rozhodnutí.

▼M3

Článek 5a

Výměna seznamů zneplatněných certifikátů

1. Rámec pro důvěryhodnost digitálních certifikátů EU COVID umožní výměnu seznamů zneplatněných certifikátů prostřednictvím centrální brány pro digitální certifikát EU COVID (dále jen „brána“) v souladu s technickými specifikacemi uvedenými v příloze I.

2. Pokud členské státy zneplatňují digitální certifikáty EU COVID, mohou seznamy zneplatněných certifikátů předávat bráně.

3. Pokud členské státy předávají seznamy zneplatněných certifikátů, vydávající orgány udržují seznam zneplatněných certifikátů.

4. Dochází-li prostřednictvím brány k výměně osobních údajů, omezuje se jejich zpracování na účely podpory výměny informací o zneplatněných certifikátech. Takové osobní údaje se používají pouze pro účely ověřování stavu zneplatnění digitálních certifikátů EU COVID vydaných v oblasti působnosti nařízení (EU) 2021/953.

5. Informace předávané bráně obsahují tyto údaje v souladu s technickými specifikacemi uvedenými v příloze I: a) pseudonymizované jedinečné identifikátory zneplatněných certifikátů; b) datum skončení platnosti předaného seznamu zneplatněných certifikátů.

6. Pokud vydávající orgán zneplatní digitální certifikáty EU COVID, které vydal podle nařízení (EU) 2021/953 nebo nařízení (EU) 2021/954, a hodlá si vyměňovat příslušné informace prostřednictvím brány, předá bráně informace uvedené v odstavci 5 ve formě seznamů zneplatněných certifikátů v zabezpečeném formátu v souladu s technickými specifikacemi uvedenými v příloze I.

7. Vydávající orgány v možném rozsahu poskytnou řešení, pomocí kterého budou v okamžiku zneplatnění držitelé takto zneplatněných certifikátů informováni o stavu zneplatnění svých certifikátů a o důvodu zneplatnění.

8. Brána shromažďuje obdržené seznamy zneplatněných certifikátů. Poskytuje nástroje pro distribuci seznamů členským státům. Seznamy automaticky maže v souladu s datem skončení platnosti, které u každého předaného seznamu uvedl předávající orgán.

9. Určené vnitrostátní orgány nebo úřady členských států, které zpracovávají osobní údaje v bráně, jsou společnými správci zpracovávaných údajů. Příslušné odpovědnosti společných správců jsou rozděleny v souladu s přílohou VI.

10. Zpracovatelem osobních údajů zpracovávaných v rámci brány je Komise. V roli zpracovatele za členské státy Komise zajistí zabezpečení přenosu a uchovávání osobních údajů v rámci brány a plní povinnosti zpracovatele stanovené v příloze VII.

11. Komise a společní správci pravidelně testují, posuzují a hodnotí účinnost technických a organizačních opatření k zajištění bezpečnosti zpracování osobních údajů v rámci brány.

Článek 5b

Předávání seznamů zneplatněných certifikátů třetími zeměmi

Třetí země vydávající certifikáty týkající se onemocnění COVID-19, ve vztahu k nimž Komise přijala prováděcí akt podle čl. 3 odst. 10 nebo čl. 8 odst. 2 nařízení (EU) 2021/953, mohou seznamy zneplatněných certifikátů týkajících se onemocnění COVID-19, na něž se uvedený prováděcí akt vztahuje, předávat ke zpracování Komisí za společné správce v rámci brány uvedené v článku 5a v souladu s technickými specifikacemi uvedenými v příloze I.

Článek 5c

Správa zpracování osobních údajů v centrální bráně pro digitální certifikát EU COVID

1. Rozhodovací proces společných správců řídí pracovní skupina zřízená v rámci výboru uvedeného v článku 14 nařízení (EU) 2021/953.

2. Určené vnitrostátní orgány nebo úřady členských států, které zpracovávají osobní údaje v bráně jako společní správci, jmenují do této skupiny své zástupce.

▼M1

Článek 6

Toto rozhodnutí vstupuje v platnost dnem vyhlášení v Úředním věstníku Evropské unie.

▼B

Toto rozhodnutí vstupuje v platnost dnem vyhlášení v Úředním věstníku Evropské unie.









PŘÍLOHA I

FORMÁT A ŘÍZENÍ DŮVĚRY

Obecná datová struktura, mechanismy kódování a mechanismus kódování při přenosu ve strojově čitelném optickém formátu (dále jen „QR“)

1. Úvod

Technické specifikace uvedené v této příloze obsahují obecnou datovou strukturu a mechanismy kódování pro digitální certifikát EU COVID („DCC“). Specifikují rovněž mechanismus kódování při přenosu ve strojově čitelném optickém formátu („QR“), který lze zobrazit na displeji mobilního zařízení nebo vytisknout. Formáty kontejneru pro elektronický zdravotní certifikát v těchto specifikacích jsou obecné, ale v této souvislosti se používají k přenosu DCC.

2. Terminologie

Pro účely této přílohy se „vydavateli“ rozumí organizace, které používají tyto specifikace pro vydávání zdravotních certifikátů, a „ověřovateli“ se rozumí organizace, které zdravotní certifikáty uznávají jako doklad o zdravotním stavu. „Účastníky“ se rozumí vydavatelé a ověřovatelé. Některé aspekty stanovené v této příloze musí být mezi účastníky koordinovány, například správa jmenného prostoru a distribuce kryptografických klíčů. Předpokládá se, že tyto úkoly vykonává strana, dále nazývaná „sekretariát“.

3. Formát kontejneru pro elektronický zdravotní certifikát

Formát kontejneru pro elektronický zdravotní certifikát („HCERT“) je navržen tak, aby poskytoval jednotný a standardizovaný nosič pro zdravotní certifikáty od různých vydavatelů. Cílem těchto specifikací je harmonizovat způsob, jakým jsou tyto zdravotní certifikáty reprezentovány, kódovány a podepisovány, a to se záměrem usnadnit interoperabilitu.

K tomu, aby bylo možné číst a interpretovat DCC vydaný jakýmkoli vydavatelem, jsou zapotřebí společná datová struktura a dohoda na významu jednotlivých datových polí informačního obsahu. K usnadnění této interoperability je pomocí schématu „JSON“ definována společná koordinovaná datová struktura, která tvoří rámec pro DCC.

3.1. Struktura informačního obsahu

Informační obsah je strukturován a kódován ve formátu CBOR s digitálním podpisem COSE. Tento formát je běžně znám jako „CBOR Web Token“ (CWT) a je definován v RFC 8392 ( 1 ). Informační obsah, jak je definován v následujících oddílech, se přenáší v deklaraci hcert.

Integrita a pravost původu dat informačního obsahu musí být ověřitelné ověřovatelem. K zajištění tohoto mechanismu musí vydavatel podepsat CWT s použitím schématu asymetrického elektronického podpisu definovaného ve specifikaci COSE (RFC 8152 ( 2 )).

3.2. Deklarace CWT

3.2.1. Přehled struktury CWT

Chráněné záhlaví

— Algoritmus podpisu (alg, návěstí 1)

— Identifikátor klíče (kid, návěstí 4)

Informační obsah

— Vydavatel (iss, klíč deklarace 1, volitelný, dvoupísmenný kód země vydavatele dle ISO 3166-1)

— Datum a čas vydání (iat, klíč deklarace 6)

— Datum a čas skončení platnosti (exp, klíč deklarace 4)

— Zdravotní certifikát (hcert, klíč deklarace -260)

— Digitální certifikát EU COVID v1 (eu_DCC_v1, klíč deklarace 1)

Podpis

3.2.2. Algoritmus podpisu

Algoritmus podpisu (alg) je parametr, který označuje, jaký algoritmus se používá pro vytvoření podpisu. Musí splňovat přinejmenším požadavky stávajících pokynů Poradního výboru pro bezpečnost informačních systémů (SOG-IS), které jsou shrnuty v následujících odstavcích.

Je definován jeden primární a jeden sekundární algoritmus. Sekundární algoritmus by měl být použit pouze v případě, že primární algoritmus není přijatelný v rámci pravidel a předpisů, kterými je vydavatel vázán.

Pro zajištění bezpečnosti systému musí všechny implementace zahrnovat sekundární algoritmus. Z tohoto důvodu musí být implementován jak primární, tak sekundární algoritmus.

Pro primární a sekundární algoritmy stanovil výbor SOG-IS tyto úrovně:

— Primární algoritmus: Primárním algoritmem je algoritmus digitálního podpisu ECDSA (Elliptic Curve Digital Signature Algorithm) definovaný v oddíle 2.3 (ISO/IEC 14888–3:2006), který používá parametry P-256 definované v dodatku D (D.1.2.3) (FIPS PUB 186–4) v kombinaci s hašovacím algoritmem SHA-256 definovaným v (ISO/IEC 10118–3:2004) – funkce 4.

To v COSE odpovídá parametru algoritmu ES256.

— Sekundární algoritmus: Sekundární algoritmus je RSASSA-PSS definovaný v (RFC 8230 ( 3 )) s 2048bitovým modulem v kombinaci s hašovacím algoritmem SHA-256 definovaným v (ISO/IEC 10118–3:2004) – funkce 4.

To v COSE odpovídá parametru algoritmu PS256.

3.2.3. Identifikátor klíče

Deklarace identifikátoru klíče (kid) označuje certifikát signatáře dokumentu (DSC) obsahující veřejný klíč, který má ověřovatel použít pro kontrolu správnosti digitálního podpisu. Správu certifikátů veřejných klíčů, včetně požadavků na DSC, popisuje příloha IV.

Deklarace identifikátoru klíče (kid) slouží ověřovatelům pro výběr správného veřejného klíče ze seznamu klíčů vztahujících se k vydavateli, který je uveden v deklaraci vydavatele (iss). Z administrativních důvodů a při obměně klíčů může vydavatel používat souběžně více klíčů. Identifikátor klíče není z hlediska bezpečnosti kritické pole. Z tohoto důvodu může být v případě potřeby umístěn i v nechráněném záhlaví. Ověřovatelé musí akceptovat obě možnosti. Jsou-li přítomny obě možnosti, musí se použít identifikátor klíče v chráněném záhlaví.

Z důvodu zkrácení identifikátoru (kvůli omezení délky) existuje malá, ale nenulová šance, že celkový seznam DSC akceptovaných ověřovatelem může obsahovat DSC s duplicitními kid. Z tohoto důvodu musí ověřovatel zkontrolovat všechny DSC s daným kid.

3.2.4. Vydavatel

Deklarace vydavatele (iss) je hodnota typu řetězec, která může volitelně obsahovat dvoupísmenný kód země (dle ISO 3166-1) subjektu vydávajícího zdravotní certifikát. Na základě této deklarace může ověřovatel určit, kterou sadu DSC má k ověření použít. Tuto deklaraci identifikuje klíč deklarace 1.

3.2.5. Datum a čas skončení platnosti

Deklarace data a času skončení platnosti (exp) obsahuje časové razítko v celočíselném formátu NumericDate (specifikovaném v oddíle 2 dokumentu RFC 8392 ( 4 )), jež udává, do kdy je tento konkrétní podpis informačního obsahu považován za platný; poté musí ověřovatel tento informační obsah zamítnout z důvodu skončení platnosti. Datum skončení platnosti je parametr, jehož účelem je omezit dobu platnosti zdravotního certifikátu. Tuto deklaraci identifikuje klíč deklarace 4.

Datum a čas skončení platnosti nesmí přesáhnout dobu platnosti DSC.

3.2.6. Datum a čas vydání

Deklarace Datum a čas vydání (iat) obsahuje časové razítko v celočíselném formátu NumericDate (specifikovaném v oddíle 2 dokumentu RFC 8392 ( 5 )), jež udává, kdy byl tento zdravotní certifikát vytvořen.

Pole Datum a čas vydání nesmí předcházet době platnosti DSC.

Ověřovatelé mohou uplatňovat další pravidla pro omezení platnosti zdravotního certifikátu na základě data a času jeho vydání. Tuto deklaraci identifikuje klíč deklarace 6.

3.2.7. Deklarace zdravotního certifikátu

Deklarace zdravotního certifikátu (hcert) je objekt JSON (RFC 7159 ( 6 )), který obsahuje informace o zdravotním stavu. Stejná deklarace může obsahovat více různých typů zdravotních certifikátů, z nichž jedním je digitální certifikát EU COVID.

Objekt JSON slouží pouze pro účely schématu. Formátem pro reprezentaci je CBOR definovaný v (RFC 7049 ( 7 )). Vývojáři aplikací nemusí vůbec dekódovat nebo kódovat z/do formátu JSON, nýbrž mohou používat strukturu v paměti.

Tuto deklaraci identifikuje klíč deklarace -260.

Řetězce v objektu JSON by měly být normalizovány do formy NFC (Normalization Form Canonical Composition) definované v normě Unicode. Dekódující aplikace by však měly být v těchto ohledech tolerantní a robustní a doporučuje se akceptovat veškeré rozumné typové konverze. Pokud se v rámci dekódování nebo následných porovnávacích funkcí objeví nenormalizovaná data, měly by se implementace chovat, jako kdyby byl vstup normalizován do formy NFC.

4. Serializace a vytvoření informačního obsahu DCC

Jako serializační vzor se používá následující schéma:

Proces začíná extrakcí dat, například z úložiště údajů o zdravotním stavu (nebo z nějakého externího zdroje dat), přičemž extrahovaná data jsou strukturována podle definovaných schémat DCC. V rámci tohoto procesu může před začátkem serializace do formátu CBOR proběhnout konverze do definovaného datového formátu a transformace v zájmu srozumitelnosti pro člověka. Zkratky deklarací se v každém případě před serializací a po deserializaci mapují na zobrazované názvy.

V certifikátech vydaných po přijetí nařízení (EU) 2021/953 ( 8 ) není povolen volitelný vnitrostátní datový obsah. Datový obsah je omezen na definované datové prvky uvedené v minimálním datovém souboru, který je specifikován v příloze nařízení 2021/953.

5. Kódování při přenosu

5.1. Nezpracovaná data (raw)

Kontejner HCERT a jeho informační obsahy lze přes blíže neupřesněná datová rozhraní přenášet bez jakékoli změny, přičemž lze využít jakéhokoli podkladového spolehlivého přenosu dat, který bez poškození přenese 8bitové hodnoty. Tato rozhraní mohou zahrnovat NFC (Near-Field Communication), Bluetooth nebo přenos přes protokol aplikační vrstvy, například přenos HCERT od vydavatele do mobilního zařízení držitele.

Je-li přenos HCERT od vydavatele k držiteli založen na výlučně prezentačním rozhraní (např. SMS, e-mail), pak se kódování při přenosu ve formě nezpracovaných dat samozřejmě nepoužije.

5.2. Čárový kód

5.2.1. Komprimace informačního obsahu (CWT)

Za účelem zmenšení velikosti a zvýšení rychlosti a spolehlivosti procesu čtení HCERT se CWT zkomprimuje pomocí ZLIB (RFC 1950 ( 9 )) a kompresního mechanismu Deflate ve formátu definovaném v RFC 1951 ( 10 ).

5.2.2. 2D čárový kód QR

Z důvodu lepší podpory starších zařízení, která jsou navržena pro informační obsah typu ASCII, je komprimovaný CWT před kódováním do 2D čárového kódu kódován jako ASCII s využitím Base45.

Pro generování 2D čárových kódů se použije formát QR definovaný v (ISO/IEC 18004:2015). Doporučuje se nastavit určitou míru korekce chyb „Q“ (kolem 25 %). Vzhledem k použití kódu Base45 musí kód QR používat alfanumerické kódování (režim 2 označený symboly 0010).

Aby mohli ověřovatelé detekovat typ kódovaných dat a vybrat správné schéma dekódování a zpracování, obsahují data v kódování Base45 (v souladu s touto specifikací) předponu v podobě řetězce identifikátoru kontextu „HC1:“. Budoucí verze této specifikace, které budou mít dopad na zpětnou kompatibilitu, definují nový identifikátor kontextu, přičemž znak následující po „HC“ se vybírá ze sady znaků [1-9 A-Z]. Pořadí přírůstků je definováno v tomto pořadí, tj. nejprve [1–9] a poté [A–Z].

Doporučuje se, aby byl optický kód na prezentačním médiu vyobrazen s úhlopříčkou 35 mm až 60 mm, aby bylo možné používat čtečky s pevnou optikou, kdy musí být prezentační médium položeno na povrch čtečky.

Je-li optický kód vytištěn na papíře tiskárnou s nízkým rozlišením (< 300 dpi), je třeba dbát na to, aby každý symbol (tečka) kódu QR byl přesně čtvercový. Neproporční změna měřítka povede k tomu, že v některých řádcích nebo sloupcích kódu QR budou obdélníkové symboly, což v mnoha případech omezí čitelnost.

6. Formát seznamu vytvářejícího důvěru (seznam CSCA a DSC)

Každý členský stát je povinen poskytnout seznam jedné nebo více národních certifikačních autorit (CSCA) a seznam všech platných certifikátů signatářů dokumentů (DSC) a je povinen tyto seznamy aktualizovat.

6.1. Zjednodušené CSCA/DSC

Počínaje touto verzí specifikací nemohou členské státy předpokládat, že se používají jakékoli informace ze seznamu zneplatněných certifikátů nebo že implementátoři ověřují dobu používání soukromých klíčů.

Primárním mechanismem ověření platnosti je místo toho přítomnost certifikátu na nejnovější verzi tohoto seznamu certifikátů.

6.2. Certifikáty ICAO eMRTD PKI a centra důvěry

Členské státy mohou používat samostatnou CSCA, ale mohou rovněž předložit své stávající certifikáty eMRTD CSCA nebo DSC a mohou se dokonce rozhodnout, že si je opatří od (komerčních) center důvěry a následně předloží. Každý DSC však musí být vždy podepsán certifikátem CSCA předloženým příslušným členským státem.

7. Bezpečnostní aspekty

Členské státy při vytváření koncepce schématu na základě této specifikace určují, analyzují a sledují některé bezpečnostní aspekty.

Zohledněny by měly být přinejmenším tyto aspekty:

7.1. Doba platnosti podpisu HCERT

Vydavatel HCERT je povinen omezit dobu platnosti podpisu tím, že uvede datum a čas skončení platnosti podpisu. Pro držitele zdravotního certifikátu z toho vyplývá nutnost pravidelně jej obnovovat.

Na to, jaká doba platnosti je přijatelná, mohou mít určující vliv praktická omezení. Cestující například nemusí mít možnost obnovit si zdravotní certifikát v průběhu cesty do zámoří. Může se však také stát, že vydavatel uvažuje o možnosti určitého narušení bezpečnosti, které vyžaduje, aby vydavatel stáhl určitý DSC (čímž zneplatní všechny zdravotní certifikáty vydané s použitím tohoto klíče ještě v době jejich platnosti). Důsledky takové události lze omezit pravidelnou obměnou klíčů vydavatele a vyžadováním obnovy všech zdravotních certifikátů v určitém přiměřeném intervalu.

7.2. Správa klíčů

Tato specifikace se do značné míry opírá o silné kryptografické mechanismy pro zabezpečení integrity dat a ověřování původu dat. Zachování důvěrnosti soukromých klíčů je proto nezbytné.

Důvěrnost kryptografických klíčů může být ohrožena mnoha různými způsoby, například:

— proces generování klíčů může být chybný, takže výsledné klíče jsou slabé,

— klíče mohu být vyzrazeny lidskou chybou,

— klíče mohou být odcizeny externími nebo interními narušiteli,

— klíče mohou být vypočteny kryptoanalýzou.

V zájmu zmírnění rizika, že v algoritmu podpisu budou objeveny slabiny, které umožní pomocí kryptoanalýzy kompromitovat soukromé klíče, doporučuje tato specifikace všem účastníkům implementovat sekundární záložní podpisový algoritmus založený na odlišných parametrech nebo na jiném matematickém problému než primární algoritmus.

Pokud jde o zmíněná rizika související s operačním prostředím vydavatelů, musí být implementována zmírňující opatření k zajištění účinné kontroly, například generování, ukládání a používání soukromých klíčů v hardwarových bezpečnostních modulech (Hardware Security Module, HSM). Používání HSM pro podepisování zdravotních certifikátů je důrazně doporučováno.

Bez ohledu na to, zda se vydavatel rozhodne HSM používat, by měl být stanoven harmonogram obměny klíčů, přičemž četnost obměn by měla být úměrná tomu, v jaké míře jsou klíče exponované vůči externím sítím, jiným systémům a zaměstnancům. Dobře zvolený harmonogram obměny rovněž omezuje rizika spojená s chybně vydanými zdravotními certifikáty, protože vydavatel může v případě potřeby stáhnout určitý klíč a tím tyto certifikáty hromadně zneplatnit.

7.3. Ověřování platnosti vstupních dat

Tyto specifikace mohou být použity způsobem vedoucím k tomu, že do systémů, které mohou být kriticky důležité, budou přijímána data z nedůvěryhodných zdrojů. V zájmu minimalizace rizik spojených s tímto vektorem útoku musí být všechna vstupní pole řádně validována z hlediska typu dat, délky a obsahu. Před jakýmkoli zpracováním obsahu HCERT se rovněž ověří podpis vydavatele. Ověření platnosti podpisu vydavatele však předpokládá, že se nejprve zanalyzuje chráněné záhlaví vydavatele, do něhož se potenciální útočník může pokusit vložit speciálně vytvořené informace ve snaze narušit bezpečnost systému.

8. Řízení důvěry

K ověření podpisu HCERT je nutný veřejný klíč. Členské státy zajistí přístup k těmto veřejným klíčům. V konečném důsledku každý ověřovatel potřebuje mít seznam všech veřejných klíčů, kterým je ochoten důvěřovat (protože veřejný klíč není součástí HCERT).

Systém má (pouze) dvě vrstvy: pro každý členský stát jeden nebo více vnitrostátních certifikátů, z nichž se každým podepíše jeden nebo více certifikátů signatářů dokumentů, které se pak používají při každodenních činnostech.

Certifikáty členských států se nazývají certifikáty národních certifikačních autorit (Country Signing Certificate Authority, CSCA) a jedná se (zpravidla) o samopodepsané certifikáty. Členské státy jich mohou mít více (například v případě regionální decentralizace). Pomocí těchto certifikátů CSCA se pravidelně podepisují certifikáty signatářů dokumentů (DSC) používané k podepisování zdravotních certifikátů.

„Sekretariát“ je funkční role. Pravidelně shromažďuje DSC členských států a poté, co je ověří podle seznamu certifikátů CSCA (které byly předány a ověřeny jinými prostředky), je zveřejňuje.

Výsledný seznam DSC pak poskytuje souhrnný soubor akceptovatelných veřejných klíčů (a odpovídajících identifikátorů klíče), které mohou ověřovatelé používat k ověřování podpisů zdravotních certifikátů. Ověřovatelé si musí tento seznam pravidelně stahovat a aktualizovat.

Tyto seznamy specifické pro jednotlivé členské státy mohou být ve formátu přizpůsobeném jejich vnitrostátnímu prostředí. Souborový formát tohoto seznamu vytvářejícího důvěru se tak může různit: může se například jednat o podepsaný JWKS (formát JWK Set podle oddílu 5 dokumentu RFC 7517 ( 11 )) nebo o jakýkoli jiný formát specifický pro technologii používanou v daném členském státě.

V zájmu zajištění jednoduchosti mohou členské státy předložit své stávající certifikáty CSCA ze svých systémů ICAO eMRTD nebo v souladu s doporučením WHO vytvořit certifikát specifický pro tuto oblast zdravotnictví.

8.1. Identifikátor klíče (kid)

Identifikátor klíče (kid) se vypočítá při sestavování seznamu důvěryhodných veřejných klíčů na základě DSC a skládá se ze zkráceného (prvních 8 bajtů) otisku SHA-256 certifikátu DSC, který je kódován ve formátu DER (raw).

Ověřovatelé nemusí vypočítávat identifikátor klíče na základě DSC a mohou přímo porovnat identifikátor klíče ve vydaném zdravotním certifikátu s identifikátorem klíče uvedeným na seznamu vytvářejícím důvěru.

8.2. Rozdíly oproti modelu důvěry ICAO eMRTD PKI

Ačkoli se vychází z osvědčených postupů v rámci modelu důvěry ICAO eMRTD PKI, kvůli urychlení se provádí řada zjednodušení:

— Členský stát může předložit více certifikátů CSCA.

— Doba platnosti (použitelnosti klíče) DSC může být nastavena na libovolnou dobu nepřekračující dobu platnosti CSCA a nemusí být stanovena.

— DSC může obsahovat identifikátory zásad (rozšířených použití klíče), které jsou specifické pro zdravotní certifikáty.

— Členské státy se mohou rozhodnout, že nebudou vůbec ověřovat zveřejněná zneplatnění, a že se místo toho spolehnou pouze na seznamy DSC, které každý den obdrží od sekretariátu nebo které si samy sestaví.

▼M3

9. Řešení pro zneplatnění certifikátů

9.1. Poskytování seznamu zneplatněných DCC („DRL“)

Brána poskytuje koncové body a funkce pro uchovávání a správu seznamů zneplatněných certifikátů:

9.2. Model důvěry

Veškerá připojení se navazují podle standardního modelu důvěry DCCG s využitím certifikátů NBTLS a NBUP (viz správa certifikátů). Veškeré informace jsou zabaleny a nahrávány ve formě CMS zpráv, aby byla zajištěna integrita.

9.3. Konstrukce dávek

9.3.1. Dávka (Batch)

Každý seznam zneplatněných certifikátů obsahuje jednu nebo více položek a zabalí se do dávek obsahujících sadu hodnot hash a jejich metadata. Dávka je neměnná (immutable) a definuje datum skončení platnosti, které udává, kdy může být dávka smazána. Datum skončení platnosti všech položek v dávce musí být totožné – to znamená, že dávky se musí seskupovat podle data skončení platnosti a podle podepisujícího DSC. Každá dávka obsahuje nejvýše 1 000 položek. Pokud seznam zneplatněných certifikátů obsahuje více než 1 000 položek, vytvoří se více dávek. Každá položka se může vyskytovat nejvýše v jedné dávce. Dávka se zabalí do struktury CMS a podepíše se certifikátem NBup nahrávající země.

9.3.2. Index dávek (Batch Index)

Když se vytvoří dávka, brána jí přidělí unikátní ID a dávka se automaticky přidá do indexu. Index dávek je řazen podle data poslední změny ve vzestupném chronologickém pořadí.

9.3.3. Chování brány

Brána zpracovává dávky se seznamy zneplatněných certifikátů bez jakýchkoliv změn: nemůže v dávkách žádnou informaci aktualizovat, odstranit ani přidat. Dávky jsou předávány všem schváleným zemím (viz kapitola 9.6).

Brána aktivně sleduje data skončení platnosti dávek a dávky se skončenou platností odstraňuje. Poté, co je dávka smazána, vrací brána pro URL smazané dávky odpověď „HTTP 410 Gone“. Dávka se tedy v indexu dávek objevuje s příznakem „deleted“.

9.4. Typy hodnot hash

Seznam zneplatněných certifikátů obsahuje hodnoty hash, které mohou představovat různé typy/atributy zneplatnění. Tyto typy nebo atributy se uvedou při poskytování seznamů zneplatněných certifikátů. Aktuální typy jsou:







Typ Atribut Výpočet hodnot hash SIGNATURE DCC Signature SHA256 of DCC Signature UCI UCI (Unique Certificate Identifier) SHA256 of UCI COUNTRYCODEUCI Issuing Country Code + UCI SHA256 of Issuing CountryCode + UCI

Do dávek se vkládá a k identifikaci zneplatněných DCC slouží pouze prvních 128 bitů hodnot hash vyjádřených jako řetězec v kódování base64 ( 12 ).

9.4.1. Typ hodnoty hash: SHA256(DCC Signature)

V tomto případě se hodnota hash vypočte z bajtů podpisu COSE_SIGN1 z CWT. V případě podpisů RSA se jako vstup použije celý podpis. Vzorec pro certifikáty podepsané algoritmem EC-DSA používá jako vstup hodnotu r:

SHA256(r)

[vyžadováno pro všechny nové implementace]

9.4.2. Typ hodnoty hash: SHA256(UCI)

V tomto případě se hodnota hash vypočítá z řetězce UCI v kódování UTF-8 převedeného na pole bajtů (byte array).

[zastaralé ( 13 ), avšak podporováno pro účely zpětné kompatibility]

9.4.3. Typ hodnoty hash: SHA256(Issuing CountryCode+UCI)

V tomto případě se vezme kód země vyjádřený jako řetězec v kódování UTF-8 a spojený s identifikátorem UCI vyjádřeným jako řetězec v kódování UTF-8. Výsledek se následně převede na pole bajtů (byte array) a použije jako vstup hašovací funkce.

[zastaralé2, avšak podporováno pro účely zpětné kompatibility]

9.5. Struktura rozhraní API

9.5.1. API pro poskytování zneplatněných položek

9.5.1.1. Účel

API dodává položky na seznamech zneplatněných certifikátů ve formě dávek, a to včetně indexu dávek.

9.5.1.2. Koncové body

9.5.1.2.1. Koncový bod pro stažení seznamu dávek

Koncové body jsou konstruovány jednoduše a vracejí seznam dávek v malém wrapperu poskytujícím metadata. Dávky jsou řazeny podle data ve vzestupném (chronologickém) pořadí:

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

{

‘more‘:true|false, ‘batches‘: [{ ‘batchId‘: ‘{uuid}‘, ‘country‘: ‘XY‘, ‘date‘: ‘2021-11-01T00:00:00Z‘ ‘deleted‘: true | false }, .. ]

}

Poznámka: Výsledek je implicitně omezen na 1 000 . Má-li příznak „more“ hodnotu „true“, odpověď udává, že jsou ke stažení k dispozici další dávky. Pro stažení více položek musí klient nastavit záhlaví If-Modified-Since na datum, které není dřívější než poslední přijatá položka.

V odpovědi je obsaženo pole JSON (JSON array) s následující strukturou:







Pole Definice more Příznak typu Boolean, který udává, že jsou k dispozici další dávky batches Pole (array) se stávajícími dávkami batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Kód země dle ISO 3166 date Datum dle ISO 8601 v UTC. Datum, kdy byla dávka přidána nebo smazána. deleted Boolean. Má hodnotu „true“, byla-li dávka smazána. Je-li příznak „deleted“ nastaven, může být položka po 7 dnech finálně odstraněna z výsledků dotazu.

9.5.1.2.1.1. Kódy odpovědí







Kód Popis 200 Vše ok. 204 Žádný obsah, pokud záhlaví „If-Modified-Since“ nevede k žádné shodě.

Záhlaví požadavku







Záhlaví Povinné Popis If-Modified-Since Ano Toto záhlaví obsahuje naposledy stažené datum, aby se získaly pouze nejnovější výsledky. Při prvním volání by mělo být záhlaví nastaveno na ‘2021-06-01T00:00:00Z‘

9.5.1.2.2. Koncový bod pro stažení dávky

Dávky obsahují seznam identifikátorů certifikátů:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

{

‘country‘: ‘XY‘, ‘expires‘: ‘2022-11-01T00:00:00Z‘, ‘kid‘:‘23S+33f=‘, ‘hashType’:’SIGNATURE’, ‘entries‘:[{ ‘hash‘:‘e2e2e2e2e2e2e2e2‘ }, ..]

}

Odpověď obsahuje CMS včetně podpisu, který musí odpovídat certifikátu NBUP příslušné země. Všechny položky v poli JSON (JSON array) obsahují následující strukturu:







Pole Povinné Typ Definice expires Ano String Datum, kdy je možné položku odstranit. Datum/čas v UTC dle ISO8601 country Ano String Kód země dle ISO 3166 hashType Ano String Typ hodnoty hash poskytnutých položek (viz Typy hodnot hash) entries Ano JSON Object Array Viz tabulka Položky kid Ano String KID certifikátu DSC použitého k podepsání DCC v kódování base64. Není-li KID znám, lze použít řetězec „UNKNOWN_KID“ (bez uvozovek). Poznámky:

— Dávky se seskupí podle data skončení platnosti a DSC – platnost všech položek skončí ve stejném okamžiku a všechny jsou podepsány stejným klíčem.

— Časem skončení platnosti je datum/čas v UTC, neboť EU-DCC je globální systém a je třeba používat jednoznačný čas.

— Jako datum skončení platnosti trvale zneplatněných DCC se nastaví datum skončení platnosti příslušného DSC použitého k podepsání DCC nebo čas skončení platnosti zneplatněného DCC (a v takovém případě se má za to, že časové údaje ve formátu NumericDate/epoch jsou v časovém pásmu UTC).

— Vnitrostátní backendový systém (NB) odstraní položky ze svého seznamu zneplatněných certifikátů v okamžiku, kdy bude dosaženo datum skončení platnosti .

— NB může položky ze svého seznamu zneplatněných certifikátů odstranit v případě, že dojde k zneplatnění kid použitého k podepsání DCC.

9.5.1.2.2.1. Položky







Pole Povinné Typ Definice hash Ano String Prvních 128 bitů hodnoty hash SHA256 jako řetězec v kódování base64

Poznámka: Objekt položek aktuálně obsahuje pouze hodnotu hash, ale pro zajištění kompatibility s budoucími změnami byl namísto pole JSON (JSON array) zvolen objekt.

9.5.1.2.2.2. Kódy odpovědí







Kód Popis 200 Vše ok. 410 Dávka již neexistuje. Dávka může být ve vnitrostátním backendovém systému smazána.

9.5.1.2.2.3. Záhlaví odpovědí







Záhlaví Popis ETag ID dávky.

9.5.1.2.3. Koncový bod pro nahrání dávky

Nahrání se provádí přes stejný koncový bod operací POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

{

‘country‘: ‘XY‘, ‘expires‘: ‘2022-11-01T00:00:00Z‘, ‘kid‘:‘23S+33f=‘, ‘hashType‘:‘SIGNATURE‘, ‘entries‘:[{ ‘hash‘:‘e2e2e2e2e2e2e2e2‘ }, ..]

}

Dávka se podepíše pomocí certifikátu NBUP. Brána ověří, zda byl podpis vytvořen pomocí NBUP pro danou zemi (country). Je-li kontrola podpisu neúspěšná, nahrání se nezdaří.

POZNÁMKA: Každá dávka je neměnná (immutable) a po nahrání ji již nelze změnit. Je však možné ji smazat. ID každé smazané dávky se uloží a případné nahrání nové dávky se stejným ID se odmítne.

9.5.1.2.4. Koncový bod pro odstranění dávky

Dávku lze odstranit přes stejný koncový bod operací DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

‘batchId‘: ‘...‘

}

nebo, z důvodů kompatibility, přes následující koncový bod operací POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

‘batchId‘: ‘...‘

}

9.6. Ochrana API/obecné nařízení o ochraně osobních údajů (GDPR)

V tomto oddíle jsou specifikována opatření pro implementaci s ohledem na splnění ustanovení nařízení 2021/953, pokud jde o zpracování osobních údajů.

9.6.1. Stávající autentizace

Brána pro autentizaci zemí, které se k ní připojují, v současnosti využívá certifikát NBTLS. Tuto autentizaci lze využít pro určení totožnosti země připojené k bráně. Tato identita může být následně využita pro implementaci řízení přístupu.

9.6.2. Řízení přístupu

Aby mohla brána zákonně zpracovávat osobní údaje, zavede mechanismus řízení přístupu.

Brána implementuje seznam řízení přístupu (Access Control List) v kombinaci se zabezpečením na základě rolí (Role Based Security). V rámci tohoto schématu se vedou dvě tabulky – jedna tabulka popisuje, které role mohou použít které operace na které prostředky, druhá tabulka popisuje, které role jsou přiřazeny kterým uživatelům.

K implementaci kontrolních mechanismů vyžadovaných tímto dokumentem jsou zapotřebí tyto tři role:

RevocationListReader

RevocationUploader

RevocationDeleter

Následující koncové body musí kontrolovat, zda je uživateli přiřazena role RevocationListReader; pokud tomu tak je, je mu umožněn přístup, pokud ne, vrátí se HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Následující koncové body musí kontrolovat, zda je uživateli přiřazena role RevocationUploader; pokud tomu tak je, je mu umožněn přístup, pokud ne, vrátí se HTTP 403 Forbidden:

POST/revocation-list

Následující koncové body musí kontrolovat, zda je uživateli přiřazena role RevocationDeleter; pokud tomu tak je, je mu umožněn přístup, pokud ne, vrátí se HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Brána musí rovněž poskytovat spolehlivou metodu, jak mohou správci spravovat role, které jsou spojeny s uživateli, a to takovým způsobem, aby se snížila možnost lidských chyb a zároveň se předešlo zatěžování správců.

▼M1









PŘÍLOHA II

PRAVIDLA TÝKAJÍCÍ SE ÚČELU VYPLŇOVÁNÍ DIGITÁLNÍHO CERTIFIKÁTU EU COVID

Cílem obecných pravidel týkajících se souborů hodnot stanovených v této příloze je zajistit interoperabilitu na sémantické úrovni a umožnit jednotnou technickou implementaci digitálních certifikátů EU COVID. Prvky obsažené v této příloze mohou být použity pro tři různé scénáře (očkování/testování/zotavení), jak je stanoveno v nařízení (EU) 2021/953. V této příloze jsou uvedeny pouze prvky, u kterých je potřebná sémantická normalizace prostřednictvím kódovaných souborů hodnot.

Za překlad kódovaných prvků do národního jazyka odpovídají členské státy.

Kódování pro všechna datová pole, která nejsou uvedena v následujících popisech souborů hodnot, je popsáno v příloze V.

Pokud z nějakého důvodu nelze použít upřednostňované systémy kódování uvedené níže, mohou být použity jiné mezinárodní systémy kódování a mělo by být vydáno doporučení, jak mají být kódy tohoto jiného systému kódování mapovány na upřednostňovaný systém kódování. Ve výjimečných případech, kdy definované soubory hodnot neobsahují vhodný kód, lze jako záložní mechanismus použít text (zobrazované názvy).

Členské státy, které ve svých systémech používají jiné kódování, musí tyto kódy mapovat na popsané soubory hodnot. Za veškerá taková mapování odpovídají členské státy.

Vzhledem k tomu, že některé soubory hodnot založené na systémech kódování stanovených v této příloze, jako jsou soubory hodnot pro kódování očkovacích látek a rychlých testů na antigen, se často mění, zveřejňuje je Komise s podporou sítě pro elektronické zdravotnictví a Výboru pro zdravotní bezpečnost a pravidelně je aktualizuje. Aktualizované soubory hodnot se zveřejňují na příslušných internetových stránkách Komise, jakož i na internetových stránkách sítě pro elektronické zdravotnictví. Musí být poskytnuta historie změn.

1. Onemocnění nebo původce onemocnění, jehož se certifikát týká / Onemocnění, z něhož se držitel uzdravil, nebo původce onemocnění: COVID-19 (SARS-CoV-2 nebo jedna z jeho variant)

Použije se v certifikátu 1, 2 a 3.

Použije se tento kód:







Kód Zobrazení Název systému kódování URL systému kódování OID systému kódování Verze systému kódování 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

2. Očkovací látka nebo profylaxe proti onemocnění COVID-19

Upřednostňovaný systém kódování: SNOMED CT nebo klasifikace ATC.

Použije se v certifikátu 1.

Příkladem kódů z upřednostňovaných systémů kódování, které se musí použít, jsou kódy SNOMED CT 1119305005 (antigenní očkovací látka proti SARS-CoV-2), 1119349007 (očkovací látka proti SARS-CoV-2 na bázi mRNA) nebo J07BX03 (očkovací látky proti onemocnění COVID-19).

Komise s podporou sítě pro elektronické zdravotnictví zveřejňuje a pravidelně aktualizuje soubor hodnot určující kódy, které se mají používat podle systémů kódování stanovených v tomto oddíle. Tento soubor hodnot musí být po vyvinutí a zavedení nových typů očkovacích látek rozšířen.

3. Léčivý přípravek – očkovací látka proti onemocnění COVID-19

Upřednostňované systémy kódování (v pořadí podle preference):

— rejstřík léčivých přípravků Unie pro očkovací látky s celounijní registrací (čísla registrace),

— celosvětový rejstřík očkovacích látek, například rejstřík, který by mohla zřídit Světová zdravotnická organizace,

— v ostatních případech název léčivého přípravku – očkovací látky. Pokud název obsahuje prázdné znaky, musí být nahrazeny spojovníkem (-).

Název souboru hodnot: Očkovací látka.

Použije se v certifikátu 1.

Příkladem kódu z upřednostňovaných systémů kódování, který se musí použít, je EU/1/20/1528 (Comirnaty). Příklad názvu očkovací látky, který se použije jako kód: Sputnik-V (pro Sputnik V).

Komise s podporou sítě pro elektronické zdravotnictví zveřejňuje a pravidelně aktualizuje soubor hodnot určující kódy, které se mají používat podle systémů kódování stanovených v tomto oddíle.

Očkovací látky se kódují pomocí stávajícího kódu ve zveřejněném souboru hodnot, a to i v případě, že se jejich názvy v různých zemích liší. Důvodem je skutečnost, že dosud neexistuje žádný celosvětový rejstřík očkovacích látek, který by obsahoval všechny očkovací látky, jež se v současné době používají. Příklad:

— Pro očkovací látku „COVID-19 Vaccine Moderna Intramuscular Injection“, což je název očkovací látky Spikevax v Japonsku, použijte kód EU/1/20/1507, jelikož se jedná o název této očkovací látky v EU.

Není-li to v konkrétním případě možné nebo žádoucí, uvede se ve zveřejněném souboru hodnot samostatný kód.

4. Držitel rozhodnutí o registraci očkovací látky proti onemocnění COVID-19 nebo výrobce očkovací látky proti onemocnění COVID-19

Upřednostňovaný systém kódování:

— kód organizace udělený agenturou EMA (systém SPOR pro ISO IDMP),

— celosvětový rejstřík držitelů rozhodnutí o registraci nebo výrobců očkovacích látek, například rejstřík, který by mohla zřídit Světová zdravotnická organizace,

— v ostatních případech název organizace. Pokud název obsahuje prázdné znaky, musí být nahrazeny spojovníkem (-).

Použije se v certifikátu 1.

Příkladem kódu z upřednostňovaného systému kódování, který se musí použít, je ORG-100001699 (AstraZeneca AB). Příklad názvu organizace, který se použije jako kód: Sinovac-Biotech (pro Sinovac Biotech).

Komise s podporou sítě pro elektronické zdravotnictví zveřejňuje a pravidelně aktualizuje soubor hodnot určující kódy, které se mají používat podle systémů kódování stanovených v tomto oddíle.

Různé pobočky téhož držitele rozhodnutí o registraci nebo téhož výrobce musí ve zveřejněném souboru hodnot použít existující kód.

Obecně platí, že pro tutéž očkovací látku se použije kód odkazující na držitele rozhodnutí o registraci této očkovací látky v EU, jelikož dosud neexistuje žádný mezinárodně dohodnutý rejstřík výrobců očkovacích látek nebo držitelů rozhodnutí o registraci. Příklady:

— Pro organizaci „Pfizer AG“, která je držitelem rozhodnutí o registraci očkovací látky „Comirnaty“ používané ve Švýcarsku, použijte kód ORG-100030215 odkazující na společnost BioNTech Manufacturing GmbH, jelikož ta je držitelem rozhodnutí o registraci očkovací látky Comirnaty v EU.

— Pro organizaci „Zuellig Pharma“, která je držitelem rozhodnutí o registraci očkovací látky „Covid-19 Vaccine Moderna (Spikevax)“ používané na Filipínách, použijte kód ORG-100031184 odkazující na společnost Moderna Biotech Spain S.L., jelikož ta je držitelem rozhodnutí o registraci očkovací látky Spikevax v EU.

Není-li to v konkrétním případě možné nebo žádoucí, uvede se ve zveřejněném souboru hodnot samostatný kód.

5. Pořadí v rámci řady dávek, jakož i celkový počet dávek v této řadě

Použije se v certifikátu 1.

Dvě pole:

1) pořadí v rámci řady dávek očkovací látky proti COVID-19 (N);

2) celkový počet dávek v rámci očkování (C).

5.1. Základní očkování

Pokud osoba dostává dávky v rámci základního očkování, tj. očkování, které má poskytnout dostatečnou ochranu v počáteční fázi, údaj (C) označuje celkový počet dávek základního očkování (např. 1 nebo 2 v závislosti na typu podané očkovací látky). To zahrnuje i možnost použít zkrácené očkování (C=1), pokud očkovací schéma uplatňované daným členským státem stanoví podání jediné dávky dvoudávkové očkovací látky osobám, které byly v minulosti infikovány virem SARS-CoV-2. Úplné základní očkování se tak označí N/C = 1. Například:

— 1/1 označuje dokončení základního očkování jednou dávkou nebo dokončení základního očkování sestávajícího z jedné dávky dvoudávkové očkovací látky podané uzdravené osobě v souladu s očkovacím schématem uplatňovaným daným členským státem,

— 2/2 označuje dokončení základního očkování dvěma dávkami.

Pokud se základní očkování rozšíří, například u osob s vážně oslabeným imunitním systémem, nebo pokud nebyl dodržen doporučený interval mezi základními dávkami, musí být všechny tyto dávky zakódovány jako dodatečné dávky spadající do oddílu 5.2.

▼M2

5.2 Posilovací dávky

Pokud osoba dostává dávky po základním očkování, tyto posilovací dávky se odrazí v odpovídajících certifikátech následovně:

— 2/1 označuje podání posilovací dávky po základním očkování jednou dávkou nebo podání posilovací dávky po dokončení základního očkování sestávajícího z jedné dávky dvoudávkové očkovací látky podané uzdravené osobě v souladu s očkovacím schématem uplatňovaným daným členským státem. Dávky (X) podané po první posilovací dávce se poté označí jako (2+X)/(1) > 1 (například 3/1);

— 3/3 označuje podání posilovací dávky po základním očkování dvěma dávkami. Dávky (X) podané po první posilovací dávce se poté označí jako (3+X)/(3+X) = 1 (například 4/4).

Členské státy zavedou pravidla pro kódování stanovená v tomto oddíle do 1. února 2022.

Členské státy automaticky nebo na žádost dotčených osob opětovně vydají certifikáty, v nichž je podání posilovací dávky po základním očkování jednou dávkou zakódováno takovým způsobem, že je nelze odlišit od dokončení základního očkování.

Pro účely této přílohy by se „posilovacími dávkami“ měly rozumět rovněž dodatečné dávky podané za účelem lepší ochrany osob, které po dokončení standardního základního očkování vykazují nedostatečnou imunitní reakci. V právním rámci stanoveném nařízením (EU) 2021/953 mohou členské státy přijmout opatření k řešení situace zranitelných skupin, které mohou obdržet dodatečné dávky přednostně. Například pokud se členský stát rozhodne podávat dodatečné dávky pouze konkrétním podskupinám obyvatelstva, může se v souladu s čl. 5 odst. 1 nařízení (EU) 2021/953 rozhodnout, že bude vydávat certifikáty o očkování uvádějící podání těchto dodatečných dávek pouze na žádost, a nikoli automaticky. Pokud jsou taková opatření přijata, uvědomí členské státy dotčené osoby o těchto opatřeních i tom, že mohou nadále používat certifikát získaný po dokončení standardního základního očkování.

▼M1

6. Členský stát nebo třetí země, v nichž byla očkovací látka podána / byl test proveden

Upřednostňovaný systém kódování: kódy zemí podle ISO 3166.

Použije se v certifikátech 1, 2 a 3.

Obsah souboru hodnot: úplný seznam dvoupísmenných kódů, který je k dispozici jako soubor hodnot definovaných ve standardu FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). Pokud očkování nebo test provedla mezinárodní organizace (např. UNHCR nebo WHO) a nejsou k dispozici žádné informace o zemi, použije se kód organizace. Tyto dodatečné kódy zveřejňuje a pravidelně aktualizuje Komise s podporou sítě pro elektronické zdravotnictví.

7. Druh testu

Použije se v certifikátu 2 a dále v certifikátu 3, pokud je prostřednictvím aktu v přenesené pravomoci zavedena podpora pro vydávání certifikátů o zotavení založených na jiných druzích testů, než je NAAT.

Použijí se tyto kódy:







Kód Zobrazení Název systému kódování URL systému kódování OID systému kódování Verze systému kódování LP6464-4 Amplifikace nukleových kyselin se sondou na detekci LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Rychlý imunologický test LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

8. Výrobce a obchodní název použitého testu (pro test NAAT nepovinné)

Použije se v certifikátu 2.

Obsah souboru hodnot zahrnuje výběr rychlých testů na antigen uvedených ve společném a aktualizovaném seznamu rychlých testů na antigen pro diagnostiku onemocnění COVID-19, který byl sestaven na základě doporučení Rady 2021/C 24/01 a schválen Výborem pro zdravotní bezpečnost. Tento seznam spravuje Společné výzkumné středisko v rámci databáze diagnostických prostředků in vitro a metod testování pro onemocnění COVID-19, která je k dispozici na adrese: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

Pro tento systém kódování se použijí relevantní pole, jako je identifikátor testovacího prostředku, název testu a výrobce, podle strukturovaného formátu Společného výzkumného střediska, který je k dispozici na adrese: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9. Výsledek testu

Použije se v certifikátu 2.

Použijí se tyto kódy:







Kód Zobrazení Název systému kódování URL systému kódování OID systému kódování Verze systému kódování 260415000 Nedetekováno SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Detekováno SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼B









PŘÍLOHA III

SPOLEČNÁ STRUKTURA JEDINEČNÉHO IDENTIFIKÁTORU CERTIFIKÁTU

1. Úvod

Každý digitální certifikát EU COVID (DCC) obsahuje jedinečný identifikátor certifikátu (UCI), který podporuje interoperabilitu digitálních certifikátů EU COVID. Identifikátor UCI lze používat k ověření certifikátu. Implementace UCI je odpovědností členských států. UCI je prostředkem k ověření pravdivosti certifikátu a případně k propojení s registračním systémem (například IIS). Tyto identifikátory rovněž umožní členským státům vydávat (papírová a digitální) potvrzení pro jednotlivé osoby, že byly očkovány nebo testovány.

2. Součásti jedinečného identifikátoru certifikátu

Identifikátor UCI se řídí společnou strukturou a formátem usnadňujícím interpretaci informací člověkem nebo strojem a může se týkat prvků, jako je členský stát očkování, samotná očkovací látka a identifikátor specifický pro členský stát. Členským státům zajišťuje flexibilní možnosti stanovení formátu při plném souladu s právními předpisy v oblasti ochrany údajů. Pořadí jednotlivých prvků se řídí definovanou hierarchií, která může umožnit budoucí úpravy bloků při zachování strukturální integrity.

Různé možnosti složení UCI tvoří spektrum, v němž modularita a možnost interpretace člověkem představují dva hlavní rozlišující parametry a tvoří jednu základní charakteristiku:

— modularita: míra, do jaké je kód složen ze samostatných stavebních bloků, které obsahují sémanticky odlišné informace,

— možnost interpretace člověkem: míra, do jaké je kód smysluplný nebo může být interpretován lidským čtenářem,

— globálně jedinečný; identifikátor země nebo orgánu je řádně spravován; očekává se, že každá země (orgán) bude svůj segment jmenného prostoru řádně spravovat, a to tak, že nikdy nebude identifikátory recyklovat nebo opakovaně vydávat. Tato kombinace umožňuje zajistit, aby každý identifikátor byl globálně jedinečný.

▼M1

3. Všeobecné požadavky

V souvislosti s UCI musí být splněny tyto zastřešující požadavky:

1) Znaková sada: povoleny jsou pouze velká písmena a číslice US-ASCII („A“ až „Z“, „0“ až „9“), dále pak zvláštní oddělovací znaky podle RFC3986 ( 14 ), jmenovitě {„/“, „#“, „:“}.

2) Maximální délka: při konstrukci se musí cílit na délku v rozmezí 27–30 znaků ( 15 ).

3) Předpona verze: jedná se o verzi schématu UCI. Předpona verze je pro tuto verzi dokumentu „01“; předpona verze se skládá ze dvou číslic.

4) Předpona země: kód země je specifikován podle normy ISO 3166-1. Delší kódy, např. 3 znaky a více (například „UNHCR“), jsou vyhrazeny pro budoucí použití.

5) Přípona kódu / kontrolní součet: 5.1 Členské státy musí použít kontrolní součet, pokud je pravděpodobné, že může dojít k poškození při přenosu, přepisu (člověkem) nebo jiným způsobem (například při použití v tištěné podobě). 5.2 Kontrolní součet se nesmí používat k ověřování platnosti certifikátu a technicky vzato není součástí identifikátoru, nýbrž slouží pouze k ověření integrity kódu. Tento kontrolní součet musí být souhrnem celého UCI ve formátu pro digitální přenos podle normy ISO-7812-1 (LUHN-10) ( 16 ). Od ostatních částí UCI je kontrolní součet oddělen znakem „#“.

Musí být zajištěna zpětná kompatibilita: členské státy, které v průběhu času mění strukturu svých identifikátorů (v rámci hlavní verze, v současné době stanovené jako v1), musí zajistit, aby kterékoli dva identifikátory, které jsou totožné, reprezentovaly tentýž certifikát o očkování / totéž potvrzení. Jinými slovy, členské státy nemohou identifikátory recyklovat.

▼B

4. Možnosti jednoznačných identifikátorů certifikátů, pokud jde o certifikáty o očkování

Pokyny pro ověřitelné certifikáty o očkování a základní prvky interoperability ( 17 ), které vydala síť pro elektronické zdravotnictví, poskytují členským státům a dalším stranám různé možnosti, které mohou mezi různými členskými státy existovat souběžně. Členské státy mohou tyto různé možnosti uplatňovat v různých verzích schématu UCI.









PŘÍLOHA IV

SPRÁVA CERTIFIKÁTŮ VEŘEJNÝCH KLÍČŮ

1. Úvod

Bezpečnou a důvěryhodnou výměnu podpisových klíčů pro digitální certifikáty EU COVID (DCC) mezi členskými státy zajišťuje brána pro digitální certifikát EU COVID (DCCG), která slouží jako centrální úložiště veřejných klíčů. DCCG umožňuje členským státům zveřejňovat veřejné klíče odpovídající soukromým klíčům, které používají k podepisování digitálních certifikátů COVID. Členské státy, které bránu DCCG využívají, ji mohou použít ke včasnému získávání aktuálních veřejných klíčů. Později může být brána DCCG rozšířena, aby umožňovala i výměnu doplňujících důvěryhodných informací, které členské státy poskytují, jako jsou pravidla pro ověřování platnosti DCC. Modelem důvěry, který se pro rámec DCC používá, je infrastruktura veřejných klíčů (PKI). Každý členský provozuje jednu nebo více národních certifikačních autorit (CSCA), jejichž certifikáty mají relativně dlouhou životnost. Podle rozhodnutí daného členského státu může být autorita CSCA stejná či odlišná od CSCA využívané pro strojově čitelné cestovní doklady. CSCA vydává certifikáty veřejných klíčů pro vnitrostátní signatáře dokumentů (tj. pro signatáře DCC), které mají krátkou životnost a označují se jako certifikáty signatářů dokumentů (DSC). CSCA funguje jako zdroj důvěry, takže členské státy, které ji využívají, mohou certifikát CSCA použít k ověřování pravosti a integrity pravidelně se měnících DSC. Po ověření jejich platnosti mohou členské státy tyto certifikáty (nebo pouze veřejné klíče v nich obsažené) použít ve svých aplikacích pro ověřování platnosti DCC. Kromě CSCA a DSC využívá brána DCCG infrastrukturu veřejných klíčů také k ověřování pravosti transakcí, podepisování dat, jako základ pro autentizaci a jako prostředek k zajištění integrity komunikačních kanálů mezi členskými státy a bránou DCCG.

K zajištění integrity a pravosti dat lze používat digitální podpisy. Infrastruktury veřejných klíčů vytvářejí důvěru tím, že vytvářejí vazbu mezi veřejnými klíči a ověřenými identitami (nebo vydavateli). To je nutné k tomu, aby ostatní účastníci mohli ověřit původ dat a totožnost komunikačního partnera a rozhodnout se o jejich důvěryhodnosti. V rámci brány DCCG se pro zajištění pravosti používá více certifikátů veřejných klíčů. V této příloze je definováno, jaké certifikáty veřejných klíčů se používají a jak mají být koncipovány, aby umožňovaly širokou interoperabilitu mezi členskými státy. Jsou v ní uvedeny podrobnější informace o nezbytných certifikátech veřejných klíčů a pokyny k šablonám certifikátů a dobám platnosti pro členské státy, které chtějí provozovat vlastní CSCA. Vzhledem k tomu, že digitální certifikáty EU COVID musí být ověřitelné v určitém stanoveném časovém rozmezí (od vydání do skončení platnosti po uplynutí určité doby), je nezbytné definovat ověřovací model pro všechny podpisy použité na certifikátech veřejných klíčů a digitálních certifikátech EU COVID.

2. Terminologie

Následující tabulka obsahuje zkratky a terminologii používané v této příloze.







Pojem Definice Certifikát Též certifikát veřejného klíče. Certifikát X.509 v3, který obsahuje veřejný klíč určitého subjektu. CSCA Národní certifikační autorita (Country Signing Certificate Authority) DCC Digitální certifikát EU COVID. Podepsaný digitální dokument, který obsahuje informace o očkování, testu nebo zotavení. DCCG Brána pro digitální certifikát EU COVID (EU Digital COVID Certificate Gateway). Tento systém se používá k výměně DSC mezi členskými státy. DCCGTA Certifikát zdroje důvěry (Trust Anchor) brány DCCG. Příslušným soukromým klíčem se off-line podepisuje seznam všech certifikátů CSCA. DCCGTLS Serverový certifikát TLS brány DCCG DSC Certifikát signatáře dokumentu (Document Signer Certificate). Certifikát veřejného klíče autority členského státu pro podepisování dokumentů (například systému, který je oprávněn podepisovat DCC). Tento certifikát vydává CSCA členského státu. EC-DSA Elliptic Curve Digital Signature Algorithm. Kryptografický algoritmus podpisu založený na eliptických křivkách. Členský stát Členský stát Evropské unie mTLS Mutual TLS. Protokol zabezpečení na transportní vrstvě včetně vzájemné autentizace. NB Vnitrostátní backendový systém (National Backend) členského státu NBCSCA Certifikát CSCA členského státu (může být více než jeden) NBTLS Autentizační klientský certifikát TLS vnitrostátního backendového systému NBUP Certifikát používaný vnitrostátním backendovým systémem k podepisování datových balíčků, které jsou nahrávány do DCCG PKI Infrastruktura veřejných klíčů (Public Key Infrastructure). Model důvěry založený na certifikátech veřejných klíčů a certifikačních autoritách. RSA Asymetrický kryptografický algoritmus založený na rozkladu na prvočinitele, používaný pro digitální podpisy nebo asymetrické šifrování

3. Komunikační toky a bezpečnostní služby brány DCCG

Tento oddíl poskytuje přehled komunikačních toků a bezpečnostních služeb v systému DCCG. Definuje také, které klíče a certifikáty se používají k ochraně komunikace, nahrávaných informací, digitálních certifikátů EU COVID a podepsaného seznamu vytvářejícího důvěru, který obsahuje veškeré přijaté certifikáty CSCA. DCCG funguje jako datový uzel, který členským státům umožňuje předávání podepsaných datových balíčků.

Nahrané datové balíčky poskytuje brána DCCG ve stejné podobě, v jaké je obdržela, což znamená, že do balíčků, které obdrží, DCCG nepřidává žádné DSC ani je z nich neodebírá. Vnitrostátní backendový systém (NB) členských států musí být schopen ověřit end-to-end integritu a pravost nahraných dat. Kromě toho budou vnitrostátní backendové systémy a brána DCCG používat i vzájemné ověřování totožnosti prostřednictvím TLS k navázání bezpečného spojení. To je nad rámec podpisů obsažených v předávaných datech.

3.1. Ověření totožnosti a navázání spojení

Brána DCCG používá protokol TLS (Transport Layer Security) se vzájemnou autentizací k vytvoření autentizovaného šifrovaného kanálu mezi vnitrostátním backendovým systémem (NB) členského státu a prostředím brány. DCCG je proto držitelem serverového certifikátu TLS, označovaného zkratkou DCCGTLS, a vnitrostátní backendové systémy jsou držiteli klientského certifikátu TLS, označovaného zkratkou NBTLS. Šablony certifikátů jsou uvedeny v oddíle 5. Každý vnitrostátní backendový systém může poskytnout svůj vlastní certifikát TLS. Tento certifikát bude zařazen na seznam výslovně povolených certifikátů, a může být tudíž vydán důvěryhodnou veřejnou certifikační autoritou (například certifikační autoritou, která se řídí základními požadavky fóra CA Browser Forum), národní certifikační autoritou nebo může být samopodepsaný. Každý členský stát odpovídá za svá vnitrostátní data a za ochranu soukromého klíče používaného k navázání spojení s bránou DCCG. Přístup založený na tom, že každý z účastníků poskytuje svůj vlastní certifikát, vyžaduje dobře definovaný postup registrace a identifikace, jakož i postupy zneplatnění a obnovení platnosti certifikátů, které jsou popsány v oddílech 4.1, 4.2 a 4.3. Brána DCCG používá seznam povolených certifikátů, na který jsou po úspěšné registraci přidány certifikáty TLS vnitrostátních backendových systémů. Bezpečné připojení k bráně DCCG mohou navázat pouze vnitrostátní backendové systémy, které prokáží svou totožnost s použitím soukromého klíče, jenž odpovídá některému z certifikátů v seznamu povolených certifikátů. Brána DCCG také použije certifikát TLS, který umožní vnitrostátním backendovým systémům ověřit, že navazují spojení se „skutečnou“ bránou DCCG, a nikoli s nějakým zlovolným subjektem, který se za bránu DCCG pouze vydává. Certifikát brány DCCG bude vnitrostátním backendovým systémům poskytnut po úspěšné registraci. Certifikát DCCGTLS bude vydán důvěryhodnou veřejnou certifikační autoritou (která je uznávána všemi nejpoužívanějšími prohlížeči). Je na členských státech, aby ověřily, zda je jejich připojení k bráně DCCG bezpečné (například kontrolou otisku certifikátu DCCGTLS serveru, k němuž se připojují, vůči certifikátu, který jim byl poskytnut po registraci).

3.2. Národní certifikační autority a model ověřování platnosti

Členské státy zapojené do rámce DCCG musí k vydávání DSC používat CSCA. Členské státy mohou mít více než jednu CSCA, například v případě regionální decentralizace. Každý členský stát může buď použít stávající certifikační autority, nebo může vytvořit certifikační autoritu (případně samopodepsanou) vyhrazenou pro systém digitálních certifikátů EU COVID.

Během oficiálního postupu onboardingu musí členské státy předložit svůj certifikát (certifikáty) CSCA provozovateli brány DCCG. Po úspěšné registraci členského státu (bližší informace jsou uvedeny v oddíle 4.1) aktualizuje provozovatel brány DCCG podepsaný seznam vytvářející důvěru, který obsahuje všechny certifikáty CSCA, jež jsou v rámci systému DCC aktivní. Provozovatel DCCG podepíše seznam vytvářející důvěru a certifikáty v off-line prostředí s použitím vyhrazeného páru asymetrických klíčů. Soukromý klíč nebude uložen v on-line systému DCCG, aby narušením zabezpečení on-line systému nezískal útočník možnost ohrozit zabezpečení seznamu vytvářejícího důvěru. Během postupu onboardingu bude vnitrostátním backendovým systémům předán odpovídající certifikát zdroje důvěry DCCGTA.

Členské státy mohou získat seznam vytvářející důvěru z brány DCCG pro své postupy ověřování. CSCA je definována jako certifikační autorita, která vydává DSC, takže členské státy, které používají víceúrovňovou hierarchii certifikačních autorit (například kořenová certifikační autorita -> CSCA -> DSC), musí poskytnout podřízenou certifikační autoritu, která vydává DSC. Používá-li v takovém případě členský stát stávající certifikační autoritu, pak bude systém DCC ignorovat vše nad úrovní CSCA a na seznam povolených certifikátů zahrne jako zdroj důvěry pouze CSCA (i když se jedná o podřízenou certifikační autoritu). Jde o model ICAO, až na to, že se připouští právě 2 úrovně – kořenová CSCA a podřízené DSC podepsané právě touto CSCA.

V případě, že členský stát provozuje svou vlastní CSCA, je tento členský stát odpovědný za bezpečný provoz a správu klíčů této certifikační autority. CSCA slouží jako zdroj důvěry pro DSC, ochrana soukromého klíče CSCA je proto zcela zásadní podmínkou integrity prostředí DCC. Modelem ověřování platnosti v rámci DCC PKI je model „shell“, podle kterého musí být při ověřování posloupnosti certifikátů všechny certifikáty platné v daném okamžiku (tj. v době ověřování podpisu). Proto platí tato omezení:

— CSCA nevydává certifikáty, které mají delší platnost než certifikát certifikační autority,

— signatář dokumentu nepodepisuje dokumenty, které mají delší platnost než DSC,

— členské státy, které provozují svou vlastní CSCA, musí pro svou CSCA a pro všechny vydané certifikáty stanovit příslušné doby platnosti a musí se postarat o obnovování certifikátů.

Oddíl 4.2 obsahuje doporučení týkající se dob platnosti.

3.3. Integrita a pravost nahrávaných dat

Vnitrostátní backendové systémy mohou pomocí brány DCCG po úspěšné vzájemné autentizaci nahrávat a stahovat digitálně podepsané datové balíčky. Zprvu tyto datové balíčky obsahují DSC členských států. Pár klíčů, který vnitrostátní backendový systém používá pro digitální podpis datových balíčků nahrávaných do systému DCCG, se nazývá nahrávací pár podpisových klíčů vnitrostátního backendového systému a odpovídající certifikát veřejného klíče se označuje zkratkou NBUP. Každý členský stát předkládá svůj vlastní certifikát NBUP, který může samopodepsán nebo vystaven stávající certifikační autoritou, například veřejnou certifikační autoritou (tj. certifikační autoritou, která vydává certifikáty v souladu se základními požadavky fóra CAB). Certifikát NBUP se musí lišit od všech ostatních certifikátů používaných daným členským státem (tj. certifikátu CSCA, klientského certifikátu TLS nebo certifikátů DSC).

Členské státy musí poskytnout nahrávací certifikát provozovateli brány DCCG při počáteční registraci (bližší informace jsou uvedeny v oddíle 4.1). Každý členský stát odpovídá za svá vnitrostátní data a musí chránit soukromý klíč, který používá k podepisování nahraných dat.

Ostatní členské státy mohou ověřovat podepsané datové balíčky pomocí nahrávacích certifikátů, které poskytuje brána DCCG. Před poskytnutím nahraných dat jiným členským státům ověřuje brána DCCG pravost a integritu nahraných dat s použitím nahrávacího certifikátu příslušného vnitrostátního backendového systému.

3.4. Požadavky na technickou architekturu DCCG

Na technickou architekturu brány DCCG se vztahují následující požadavky:

— K navázání autentizovaného šifrovaného spojení s vnitrostátními backendovými systémy používá brána DCCG vzájemnou autentizaci pomocí TLS. DCCG proto vede seznam povolených registrovaných klientských certifikátů NB TLS .

— DCCG používá dva digitální certifikáty (DCCG TLS a DCCG TA ) se dvěma odlišnými páry klíčů. Soukromý klíč z páru klíčů k DCCG TA je uchováván off-line (tj. mimo on-line součásti DCCG).

— DCCG vede seznam vytvářející důvěru s certifikáty NB CSCA , který je podepsán soukromým klíčem DCGG TA .

— Použité šifry musí splňovat požadavky uvedené v oddíle 5.1 .

4. Řízení životního cyklu certifikátů

4.1. Registrace vnitrostátních backendových systémů

Členské státy se musí zaregistrovat u provozovatele brány DCCG, aby se mohly účastnit systému DCCG. Tento oddíl popisuje technický a provozní postup, který je při registraci vnitrostátního backendového systému třeba dodržet.

Provozovatel DCCG a členský stát si musejí pro účely procesu onboardingu předat informace o technických kontaktních osobách. Předpokládá se, že technické kontaktní osoby mají od svých členských států příslušné oprávnění a že identifikace/autentizace se provádí prostřednictvím jiných kanálů. Autentizaci lze například zajistit tak, že technická kontaktní osoba členského státu poskytne certifikáty e-mailem jako soubory zašifrované heslem a příslušné heslo sdělí provozovateli DCCG telefonicky. Lze využít i jiné bezpečné kanály definované provozovatelem DCCG.

Během procesu registrace a identifikace musí členský stát poskytnout tři digitální certifikáty:

— certifikát TLS členského státu NB TLS

— nahrávací certifikát členského státu NB UP ,

— certifikát(y) CSCA členského státu NB CSCA .

Všechny poskytnuté certifikáty musí vyhovovat požadavkům stanoveným v oddíle 5. To, zda daný certifikát požadavky oddílu 5 splňuje, ověří provozovatel DCCG. Po identifikaci a registraci provozovatel DCCG:

— přidá certifikát(y) NB CSCA do seznamu vytvářejícího důvěru, který je podepsán soukromým klíčem odpovídajícím veřejnému klíči DCCG TA ,

— přidá certifikát NB TLS na seznam povolených certifikátů v koncovém bodě TLS systému DCCG,

— přidá certifikát NB UP do systému DCCG,

— poskytne členskému státu certifikát veřejného klíče DCCG TA a DCCG TLS .

4.2. Certifikační autority, doby platnosti a obnovení

V případě, že členský stát chce provozovat vlastní autoritu CSCA, mohou být certifikáty CSCA samopodepsané. Fungují jako zdroj důvěry členského státu, a členský stát proto musí důsledně chránit soukromý klíč odpovídající veřejnému klíči v certifikátu CSCA. Doporučuje se, aby členské státy pro své autority CSCA používaly off-line systém, tj. počítačový systém, který není připojen k žádné síti. K přístupu do tohoto systému by měla být zapotřebí součinnost více osob (například podle principu čtyř očí). Po podepsání certifikátů DSC se zavedou provozní kontroly a systém, ve kterém je uchováván soukromý klíč CSCA, musí být umístěn na bezpečném místě s přísným řízením přístupu. K další ochraně soukromého klíče CSCA lze použít hardwarové bezpečnostní moduly nebo čipové karty. Digitální certifikáty obsahují údaj o době platnosti, který nutí k obnovování certifikátů. Obnovování je nezbytné k tomu, aby se v případě, kdy je v důsledku nových vylepšení v oblasti výpočetních technologií nebo nových útoků ohrožena bezpečnost použitého kryptografického algoritmu, mohly použít nové kryptografické klíče a upravit délky klíčů. Použije se model „shell“ (viz oddíl 3.2).

S ohledem na roční platnost digitálních certifikátů COVID se doporučují následující doby platnosti:

— CSCA: 4 roky,

— DSC: 2 roky,

— nahrávací certifikát: 1–2 roky,

— autentizační klientský certifikát TLS: 1–2 roky.

Pro účely včasného obnovení se doporučují následující doby používání soukromých klíčů:

— CSCA: 1 rok,

— DSC: 6 měsíců.

Členské státy musí vytvořit nové nahrávací certifikáty a certifikáty TLS včas, například měsíc před skončením platnosti, aby byl zajištěn bezproblémový provoz. Certifikáty CSCA a DSC by měly být obnoveny nejméně jeden měsíc před ukončením používání příslušného soukromého klíče (s přihlédnutím k nezbytným provozním postupům). Členské státy musí poskytnout aktualizované certifikáty CSCA, nahrávací certifikáty a certifikáty TLS provozovateli DCCG. Certifikáty, kterým skončila platnost, se odstraní ze seznamu povolených certifikátů i ze seznamu vytvářejícího důvěru.

Členské státy a provozovatel DCCG musejí sledovat platnost svých vlastních certifikátů. Neexistuje žádný ústřední subjekt, který by vedl záznamy o platnosti certifikátů a informoval o ní účastníky.

4.3. Zneplatnění certifikátů

Obecně platí, že digitální certifikáty mohou být zneplatněny certifikační autoritou, která je vydala, a to pomocí seznamů zneplatněných certifikátů nebo prostřednictvím respondéru OCSP (Online Certificate Status Protocol). Autority CSCA pro systém DCC by měly poskytovat seznamy zneplatněných certifikátů (CRL). I když tyto seznamy zneplatněných certifikátů v současné době jiné členské státy nevyužívají, měly by být integrovány pro účely budoucích aplikací. V případě, že se CSCA rozhodne neposkytovat seznamy zneplatněných certifikátů, musí být certifikáty DSC od této CSCA obnoveny hned poté, co seznamy zneplatněných certifikátů začnou být povinné. Ověřovatelé by k ověřování platnosti certifikátů DSC neměli používat OCSP a měli by používat seznamy zneplatněných certifikátů. Doporučuje se, aby vnitrostátní backendový systém provedl nezbytné ověření platnosti DSC stažených z brány DCCG a vnitrostátním ověřovatelům platnosti DCC předal pouze sadu důvěryhodných a ověřených DSC. Ověřovatelé platnosti DCC by neměli v rámci svého postupu ověřování platnosti ověřovat, zda je nebo není zneplatněn DSC. Jedním z důvodů je ochrana soukromí držitelů digitálních certifikátů EU COVID, protože se tak vyloučí možnost, že by používání kteréhokoli konkrétního DSC mohlo být sledováno příslušným respondérem OCSP.

Členské státy mohou své certifikáty DSC z brány DCCG samy odstraňovat za použití platných nahrávacích certifikátů a certifikátů TLS. Odstranění DSC znamená, že všechny digitální certifikáty EU COVID vydané s použitím tohoto DSC pozbydou platnosti, jakmile si členské státy stáhnou aktualizované seznamy DSC. Zásadní význam má ochrana obsahu soukromých klíčů odpovídajících certifikátům DSC. V případě, že jsou členské státy nuceny zneplatnit nahrávací certifikát nebo certifikát TLS, například z důvodu narušení bezpečnosti vnitrostátního backendového systému, musí o tom informovat provozovatele DCCG. Provozovatel DCCG pak může zbavit dotčený certifikát důvěryhodnosti, například tak, že jej odstraní ze seznamu povolených certifikátů TLS. Provozovatel DCCG může odebrat nahrávací certifikáty z databáze DCCG. Balíčky podepsané soukromým klíčem, který odpovídá tomuto nahrávacímu certifikátu, se stanou neplatnými, jakmile vnitrostátní backendové systémy přestanou považovat zneplatněný nahrávací certifikát za důvěryhodný. V případě, že musí být zneplatněn certifikát CSCA, informují o tom členské státy provozovatele DCCG i ostatní členské státy, s nimiž udržují vztah důvěry. Provozovatel DCCG vydá nový seznam vytvářející důvěru, ve kterém již dotčený certifikát nebude obsažen. Všechny certifikáty DSC vydané touto autoritou CSCA se stanou neplatnými, jakmile členské státy aktualizují úložiště důvěry ve svém vnitrostátním backendovém systému. V případě, že musí být zneplatněn certifikát DCCGTLS nebo DCCGTA, musí provozovatel DCCG a členské státy spolupracovat na navázání nového důvěryhodného spojení TLS a vytvoření nového seznamu vytvářejícího důvěru.

5. Šablony certifikátů

V tomto oddíle jsou stanoveny kryptografické požadavky a pokyny, jakož i požadavky na šablony certifikátů. Pro certifikáty DCCG jsou v tomto oddíle definovány šablony certifikátů.

5.1. Kryptografické požadavky

Kryptografické algoritmy a sady šifer TLS se volí na základě stávajícího doporučení německého Spolkového úřadu pro bezpečnost informací (BSI) nebo Poradního výboru pro bezpečnost informačních systémů (SOG-IS). Tato doporučení a doporučení jiných institucí a normalizačních organizací jsou si podobná. Tato doporučení lze najít v technických pokynech TR 02102-1 a TR 02102-2 ( 18 ) nebo v dokumentu SOG-IS Agreed Cryptographic Mechanisms (Dohodnuté kryptografické mechanismy výboru SOG-IS) ( 19 ).

5.1.1. Požadavky na DSC

Použijí se požadavky stanovené v oddíle 3.2.2 přílohy I. Důrazně se proto doporučuje, aby signatáři dokumentů používali algoritmus ECDSA s křivkou NIST-p-256 (podle definice uvedené v dodatku D dokumentu FIPS PUB 186-4). Jiné eliptické křivky nejsou podporovány. Vzhledem k omezenému množství místa v digitálních certifikátech EU COVID by členské státy neměly používat RSA-PSS, i když je tento algoritmus přípustný jako záložní možnost. V případě, že členské státy RSA-PSS využívají, měly by použít 2048bitový nebo maximálně 3072bitový modulus. Jako kryptografická hašovací funkce pro podpis DSC se použije SHA-2 s délkou výstupu ≥ 256 bitů (viz ISO/IEC 10118-3:2004).

5.1.2. Požadavky na certifikáty TLS, nahrávací certifikáty a certifikáty CSCA

Pokud jde o digitální certifikáty a kryptografické podpisy používané v kontextu DCCG, hlavní požadavky na kryptografické algoritmy a délku klíče jsou shrnuty v následující tabulce (stav v roce 2021):







Algoritmus podpisu Délka klíče Hašovací funkce EC-DSA min. 250 bitů SHA-2 s délkou výstupu ≥ 256 bitů RSA-PSS (doporučená výplň) RSA-PKCS#1 v1.5 (starší výplň) min. 3000bitový modulus RSA (N) s veřejným exponentem e > 2^16 SHA-2 s délkou výstupu ≥ 256 bitů DSA min. 3000bitové prvočíslo p, 250bitový klíč q SHA-2 s délkou výstupu ≥ 256 bitů

Eliptickou křivkou doporučenou pro EC-DSA je NIST-p-256 vzhledem k širokému rozšíření této implementace.

5.2. Certifikát CSCA (NBCSCA)

Následující tabulka obsahuje pokyny k šabloně certifikátu NBCSCA pro případ, že se členský stát rozhodne provozovat pro systém DCC svou vlastní CSCA.

Tučně vyznačené údaje jsou povinné (musí být v certifikátu obsaženy), údaje vyznačené kurzívou jsou doporučené (certifikát by je měl obsahovat). Na chybějící pole se nevztahují žádná doporučení.







Pole Hodnota Subject (subjekt) cn=<neprázdný a jedinečný běžný název>, o=<Poskytovatel>, c=<členský stát provozující CSCA> Key usage (použití klíče) certificate signing (podepisování certifikátů), CRL signing (podepisování CRL) (minimálně) Basic Constraints (základní omezení) CA = true, path length constraints = 0

Název subjektu musí neprázdný a v daném členském státě jedinečný. Kód země (c) musí odpovídat členskému státu, který bude tento certifikát CSCA využívat. Certifikát musí obsahovat jedinečný identifikátor klíče subjektu (SKI) podle RFC 5280 ( 20 ).

5.3. Certifikát signatáře dokumentu (DSC)

Následující tabulka obsahuje pokyny pro DSC. Tučně vyznačené údaje jsou povinné (musí být v certifikátu obsaženy), údaje vyznačené kurzívou jsou doporučené (certifikát by je měl obsahovat). Na chybějící pole se nevztahují žádná doporučení.







Pole Hodnota Serial Number (sériové číslo) jedinečné sériové číslo Subject (subjekt) cn=<neprázdný a jedinečný běžný název>, o=<Poskytovatel>, c=<členský stát používající tento DSC> Key Usage (použití klíče) digital signature (digitální podpis) (minimálně)

Certifikát DSC musí být podepsán soukromým klíčem odpovídajícím certifikátu CSCA, který členský stát používá.

Používat se mají tato rozšíření:

— certifikát musí obsahovat identifikátor klíče autority (AKI) odpovídající identifikátoru klíče subjektu (SKI) v certifikátu autority CSCA, která jej vydala,

— certifikát by měl obsahovat jedinečný identifikátor klíče subjektu (SKI, v souladu s RFC 5280 ( 21 )).

Certifikát by měl navíc obsahovat rozšíření CRL Distribution Point (distribuční místo seznamu zneplatněných certifikátů) s odkazem na seznam zneplatněných certifikátů (CRL) poskytnutý autoritou CSCA, která tento DSC vydala.

DSC může obsahovat rozšíření Extended Key Usage (rozšířené použití klíče), které může obsahovat nula nebo více identifikátorů zásad používání klíče, které stanoví omezení pro typy certifikátů HCERT, které lze prostřednictvím tohoto certifikátu ověřovat. Pokud je alespoň jeden takový identifikátor přítomen, ověřovatelé ověří použití klíče podle uloženého HCERT. Pro tento účel jsou definovány tyto hodnoty extendedKeyUsage (rozšířené použití klíče):







Pole Hodnota extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 pro vydavatele certifikátů o testu extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 pro vydavatele certifikátů o očkování extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 pro vydavatele certifikátů o zotavení

Pokud certifikát žádné takové rozšíření použití klíče neobsahuje, lze jej použít k ověření jakéhokoli typu HCERT. Příslušné doplňující identifikátory zásad rozšířeného používání klíče používané pro ověřování platnosti certifikátů HCERT mohou být definovány v jiných dokumentech.

5.4. Nahrávací certifikáty (NBUP)

Následující tabulka obsahuje pokyny pro nahrávací certifikát vnitrostátního backendového systému. Tučně vyznačené údaje jsou povinné (musí být v certifikátu obsaženy), údaje vyznačené kurzívou jsou doporučené (certifikát by je měl obsahovat). Na chybějící pole se nevztahují žádná doporučení.







Pole Hodnota Subject (subjekt) cn=<neprázdný a jedinečný běžný název>, o=<Poskytovatel>, c=<členský stát používající tento nahrávací certifikát> Key Usage (použití klíče) digital signature (digitální podpis) (minimálně)

5.5. Autentizační klientský certifikát TLS vnitrostátního backendového systému (NBTLS)

Následující tabulka obsahuje pokyny pro autentizační klientský certifikát TLS vnitrostátního backendového systému. Tučně vyznačené údaje jsou povinné (musí být v certifikátu obsaženy), údaje vyznačené kurzívou jsou doporučené (certifikát by je měl obsahovat). Na chybějící pole se nevztahují žádná doporučení.







Pole Hodnota Subject (subjekt) cn=<neprázdný a jedinečný běžný název>, o=<Poskytovatel>, c=<členský stát provozující vnitrostátní koncový bod> Key Usage (použití klíče) digital signature (digitální podpis) (minimálně) Extended key usage (rozšířené použití klíče) client authentication (autentizace klienta) (1.3.6.1.5.5.7.3.2)

Certifikát může také obsahovat rozšířené použití klíče server authentication (1.3.6.1.5.5.7.3.1), ale není to povinné.

5.6. Certifikát pro podepisování seznamu vytvářejícího důvěru (DCCGTA)

Následující tabulka definuje certifikát zdroje důvěry DCCG.







Pole Hodnota Subject (subjekt) cn = Digital Green Certificate Gateway (1) , o=<Poskytovatel>, c=<země> Key Usage (použití klíče) digital signature (digitální podpis) (minimálně) ( 1 ) Název „Digital Green Certificate“ (digitální zelený certifikát) namísto „digitální certifikát EU COVID“ je v této souvislosti zachován, protože jde o název, který byl napevno nastaven a zaveden v daném certifikátu předtím, než se spolunormotvůrci dohodli na novém termínu.

5.7. Serverové certifikáty TLS pro DCCG (DCCGTLS)

Následující tabulka definuje certifikát TLS pro DCCG.







Pole Hodnota Subject (subjekt) cn=<plně kvalifikovaný název domény nebo IP adresa DCCG>, o=<Poskytovatel>, c= <země> SubjectAltName (alternativní název subjektu) dNSName: <DNS název DCCG> nebo iPAddress: <IP adresa DCCG> Key Usage (použití klíče) digital signature (digitální podpis) (minimálně) Extended Key usage (rozšířené použití klíče) server authentication (autentizace serveru) (1.3.6.1.5.5.7.3.1)

Certifikát může také obsahovat rozšířené použití klíče client authentication (1.3.6.1.5.5.7.3.2), ale není to povinné.

Certifikát DCCG pro TLS je vydán důvěryhodnou veřejnou certifikační autoritou (která je uznávána všemi nejpoužívanějšími prohlížeči a operačními systémy v souladu se základními požadavky fóra CAB).

▼M1









PŘÍLOHA V

JAVASCRIPTOVÁ OBJEKTOVÁ NOTACE (JSON)

1. Úvod

Tato příloha stanoví strukturu technických údajů pro digitální certifikáty EU COVID (EUDCC), které jsou prezentovány jako schéma JSON. Dokument obsahuje konkrétní pokyny týkající se jednotlivých datových polí.

2. Umístění a verze schématu JSON

Autorizované úřední schéma JSON pro EUDCC je k dispozici na adrese https://github.com/ehn-dcc-development/ehn-dcc-schema. Jiná umístění nejsou autorizována, ale mohou být použita pro přípravu nadcházejících revizí.

Ve výchozím nastavení je stávající verze, která je uvedena v této příloze a je podporována všemi zeměmi, které ji v současné době používají, zobrazena na uvedeném URL.

Nadcházející příští verze, kterou mají do určeného data akceptovat všechny země, je k dispozici na uvedené adrese URL pod příslušnou značkou verze a podrobněji popsána v souboru Readme.

▼M3

3. Společné struktury a všeobecné požadavky

Digitální certifikát EU COVID se nevydá, pokud kvůli chybějícím informacím nelze správně vyplnit všechna datová pole v souladu s touto specifikací. Tím není dotčena povinnost členských států vydávat digitální certifikáty EU COVID.

Informace ve všech polích lze uvádět s použitím celé sady znaků UNICODE 13.0 v kódování UTF-8, pokud není stanoveno výslovné omezení co do souboru hodnot nebo užších souborů znaků.

Společná struktura je tato:

„JSON“:{

„ver“:<informace o verzi>,

„nam“:{

<informace o jméně osoby>

},

„dob“:<datum narození>,

„v“ nebo „t“ nebo „r“:[

{<informace o dávce očkování nebo testu nebo zotavení, jedna položka>}

]

}

Podrobné informace o jednotlivých skupinách a polích jsou uvedeny v dalších oddílech.

Pokud je v pravidlech uvedeno, že se pole má přeskočit, znamená to, že jeho obsah je prázdný a že v obsahu není povoleno uvádět ani název, ani hodnotu pole.

3.1. Verze

Poskytnou se informace o verzi. Verze se vytvářejí podle systému „Semantic Versioning“ (semver: https://semver.org). V produkčním prostředí se musí jednat o jednu z oficiálně zveřejněných verzí (aktuální verze nebo jedna ze starších oficiálně zveřejněných verzí). Pro další podrobnosti viz oddíl Umístění schématu JSON.







ID pole Název pole Pokyny ver Verze schématu Musí odpovídat identifikátoru verze schématu použitého k vystavení EUDCC. Příklad: „ver“:“1.3.0“

3.2. Jméno a datum narození osoby

Jméno osoby je celé úřední jméno osoby shodné se jménem uvedeným v cestovních dokladech. Identifikátor struktury je nam. Uvede se přesně 1 (jedno) jméno osoby.







ID pole Název pole Pokyny nam/fn Příjmení Příjmení držitele. Nemá-li držitel žádná příjmení a má jméno, pole se přeskočí. Ve všech ostatních případech se uvede přesně 1 (jedno) neprázdné pole obsahující všechna příjmení. V případě více příjmení se tato příjmení oddělí mezerou. Kombinovaná jména se spojovníky nebo podobnými znaky však musí zůstat stejná. Příklady: „fn“:“Musterfrau-Gößinger“ „fn“:“Musterfrau-Gößinger Müller“ nam/fnt Standardizované (standardizovaná) příjmení Příjmení držitele transliterované (transliterovaná) podle stejné konvence jako ve strojově čitelných cestovních dokladech držitele (jako jsou pravidla definovaná v dokumentu ICAO 9303 části 3). Nemá-li držitel žádná příjmení a má jméno, pole se přeskočí. Ve všech ostatních případech se uvede přesně 1 (jedno) neprázdné pole obsahující pouze znaky A–Z a <. Maximální délka: 80 znaků (podle specifikace ICAO 9303). Příklady: „fnt“:“MUSTERFRAU<GOESSINGER“ „fnt“:“MUSTERFRAU<GOESSINGER<MUELLER“ nam/gn Jméno (jména) Jméno (jména), např. křestní jméno (jména) držitele. Nemá-li držitel žádné jméno a má příjmení, pole se přeskočí. Ve všech ostatních případech se uvede přesně 1 (jedno) neprázdné pole obsahující všechna jména. V případě více jmen se tato jména oddělí mezerou. Příklad: „gn“:“Isolde Erika“ nam/gnt Standardizované jméno (standardizovaná jména) Jméno (jména) držitele transliterované (transliterovaná) podle stejné konvence jako ve strojově čitelných cestovních dokladech držitele (jako jsou pravidla definovaná v dokumentu ICAO 9303 části 3). Nemá-li držitel žádné jméno a má příjmení, pole se přeskočí. Ve všech ostatních případech se uvede přesně 1 (jedno) neprázdné pole obsahující pouze znaky A–Z a <. Maximální délka: 80 znaků. Příklad: „gnt“:“ISOLDE<ERIKA“ dob Datum narození Datum narození držitele DCC. Úplné nebo částečné datum bez časového údaje omezené na rozmezí od 1900-01-01 do 2099-12-31. Pokud je známo úplné nebo částečné datum narození, uvede se přesně 1 (jedno) neprázdné pole. Není-li datum narození známo ani částečně, pole se nastaví na prázdný řetězec „". To by mělo odpovídat informacím uvedeným v cestovních dokladech. Je-li k dispozici údaj o datu narození, použije se jeden z následujících formátů ISO 8601. Jiné možnosti nejsou podporovány. YYYY-MM-DD YYYY-MM YYYY (Ověřovací aplikace může zobrazit chybějící části data narození za použití konvence XX stejně jako u strojově čitelných cestovních dokladů, např. 1990-XX-XX.) Příklady: „dob“:“1979-04-14“ „dob“:“1901-08“ „dob“:“1939“ „dob“:„"

3.3. Skupiny údajů specifických pro daný typ certifikátu

Schéma JSON podporuje tři skupiny údajů, které zahrnují informace specifické pro daný typ certifikátu. Každý EUDCC musí obsahovat přesně 1 (jednu) skupinu. Prázdné skupiny nejsou povoleny.







Identifikátor skupiny Název skupiny Údaje v Skupina týkající se očkování Pokud existuje, musí obsahovat přesně 1 (jeden) údaj popisující přesně 1 (jednu) dávku očkovací látky. t Skupina týkající se testu Pokud existuje, musí obsahovat přesně 1 (jeden) údaj popisující přesně 1 (jeden) výsledek testu. r Skupina týkající se zotavení Pokud existuje, musí obsahovat přesně 1 (jeden) údaj popisující přesně 1 (jedno) potvrzení o zotavení.

▼M1

4. Údaje specifické pro daný typ certifikátu

4.1. Certifikát o očkování

Skupina týkající se očkování, pokud existuje, musí obsahovat přesně 1 (jeden) údaj popisující přesně jeden očkovací úkon (jedna dávka). Všechny prvky skupiny týkající se očkování jsou povinné, prázdné hodnoty nejsou podporovány.







ID pole Název pole Pokyny v/tg Onemocnění nebo původce onemocnění, jehož se certifikát týká: COVID-19 (SARS-CoV nebo jedna z jeho variant) Kódovaná hodnota ze souboru hodnot disease-agent-targeted.json. Tato hodnota má jeden údaj 840539006, což je kód pro COVID-19 ze SNOMED CT (GPS). Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "tg":"840539006" v/vp Očkovací látka nebo profylaxe proti onemocnění COVID-19 Typ použité očkovací látky nebo profylaxe. Kódovaná hodnota ze souboru hodnot vaccine-prophylaxis.json. Soubor hodnot je distribuován z brány EUDCC Gateway. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "vp":"1119349007" (očkovací látka proti SARS-CoV-2 na bázi mRNA) v/mp Přípravek – očkovací látka proti onemocnění COVID-19 Léčivý přípravek použitý pro tuto konkrétní dávku očkování. Kódovaná hodnota ze souboru hodnot vaccine-medicinal-product.json. Soubor hodnot je distribuován z brány EUDCC Gateway. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "mp":"EU/1/20/1528" (Comirnaty) v/ma Držitel rozhodnutí o registraci očkovací látky proti onemocnění COVID-19 nebo výrobce očkovací látky proti onemocnění COVID-19 Držitel rozhodnutí o registraci nebo výrobce, pokud neexistuje žádný držitel rozhodnutí o registraci. Kódovaná hodnota ze souboru hodnot vaccine-mah-manf.json. Soubor hodnot je distribuován z brány EUDCC Gateway. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "ma":"ORG-100030215" (Biontech Manufacturing GmbH) v/dn Pořadí v rámci řady dávek Pořadové číslo (kladné celé číslo) dávky podané během tohoto očkovacího úkonu. 1 pro první dávku, 2 pro druhou dávku atd. Specifičtější pravidla jsou stanovena v příloze II oddíle 5. Uvede se přesně 1 (jedno) neprázdné pole. Příklady: "dn":"1" (první dávka) "dn":"2" (druhá dávka) "dn":"3" (třetí dávka) v/sd Celkový počet dávek v rámci řady Celkový počet dávek (kladné celé číslo) v rámci očkování. Specifičtější pravidla jsou stanovena v příloze II oddíle 5. Uvede se přesně 1 (jedno) neprázdné pole. Příklady: "sd":"1" (v případě základního očkování jednou dávkou) "sd":"2" (v případě základního očkování dvěma dávkami nebo pro dodatečnou dávku po základním očkování jednou dávkou) "sd":"3" (např. v případě dodatečných dávek po základním očkování dvěma dávkami) v/dt Datum očkování Datum podání popsané dávky ve formátu RRRR-MM-DD (úplné datum bez časového údaje). Jiné formáty nejsou podporovány. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "dt": ""2021-03-28" v/co Členský stát nebo třetí země, v nichž byla očkovací látka podána Země vyjádřená jako dvoupísmenný kód ISO3166 (DOPORUČENO) nebo odkaz na mezinárodní organizaci odpovědnou za očkovací úkon (např. UNHCR nebo WHO). Kódovaná hodnota ze souboru hodnot country-2-codes.json. Soubor hodnot je distribuován z brány EUDCC Gateway. Uvede se přesně 1 (jedno) pole. Příklad: "co":"CZ" "co":"UNHCR" v/is Vydavatel certifikátu Název organizace, která certifikát vydala. Identifikátory jsou povoleny jako součást názvu, ale nedoporučuje se používat je jednotlivě bez názvu jako text. Maximálně 80 znaků UTF-8. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "is":"Ministerstvo zdravotnictví České republiky" "is":"Očkovací středisko Jižní oblast 3" v/ci Jedinečný identifikátor certifikátu Jedinečný identifikátor certifikátu (UVCI), jak je specifikován na adrese https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf Zahrnutí kontrolního součtu je nepovinné. Lze doplnit předponu "URN:UVCI:" . Uvede se přesně 1 (jedno) neprázdné pole. Příklady: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2. Certifikát o testu

Skupina týkající se testu, pokud existuje, musí obsahovat přesně 1 (jeden) údaj popisující přesně jeden výsledek testu.







ID pole Název pole Pokyny t/tg Onemocnění nebo původce onemocnění, jehož se certifikát týká: COVID-19 (SARS-CoV nebo jedna z jeho variant) Kódovaná hodnota ze souboru hodnot disease-agent-targeted.json. Tato hodnota má jeden údaj 840539006, což je kód pro COVID-19 ze SNOMED CT (GPS). Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "tg":"840539006" t/tt Druh testu Druh použitého testu na základě materiálu, na který se test zaměřuje. Kódovaná hodnota ze souboru hodnot (na základě LOINC). Hodnoty mimo soubor hodnot nejsou povoleny. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "tt":"LP6464-4" (amplifikace nukleových kyselin se sondou na detekci) "tt":"LP217198-3" (rychlý imunologický test) t/nm Název testu (pouze test založený na amplifikaci nukleových kyselin) Název použitého testu založeného na amplifikaci nukleových kyselin (NAAT). Název by měl obsahovat jméno výrobce testu a obchodní název testu, oddělené čárkou. Pro NAAT: toto pole je nepovinné. Pro rychlý test na antigen (RAT): pole se nepoužije, protože název testu je dodáván nepřímo prostřednictvím identifikátoru testovacího prostředku (t/ma). Je-li toto pole uvedeno, nesmí být prázdné. Příklad: "nm":"ELITechGroup, SARS-CoV-2 ELITe MGB® Kit" t/ma Identifikátor testovacího prostředku (pouze rychlé testy na antigen) Identifikátor prostředku pro rychlý test na antigen (RAT) z databáze JRC. Soubor hodnot (společný seznam Výboru pro zdravotní bezpečnost): — Všechny rychlé testy na antigen ve společném seznamu Výboru pro zdravotní bezpečnost (čitelný okem). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (strojově čitelný, soubor hodnot tvoří hodnoty pole id_device zahrnuté na seznamu). V zemích EU/EHP vydají vydavatelé certifikáty pouze pro testy, které patří do aktuálně platného souboru hodnot. Soubor hodnot se aktualizuje každých 24 hodin. Hodnoty mimo soubor hodnot mohou být použity v certifikátech vydaných třetími zeměmi, identifikátory však stále musejí pocházet z databáze JRC. Použití jiných identifikátorů, například těch, které poskytují přímo výrobci testů, není povoleno. Ověřovatelé detekují hodnoty, které nepatří do aktuálního souboru hodnot, a zobrazují certifikáty opatřené těmito hodnotami jako neplatné. Pokud je identifikátor ze souboru hodnot odstraněn, mohou být certifikáty obsahující tento identifikátor uznány po dobu nejvýše 72 hodin od data odstranění. Soubor hodnot je distribuován z brány EUDCC Gateway. Pro RAT: uvede se přesně 1 (jedno) neprázdné pole. Pro NAAT: pole se nepoužije, a to ani v případě, že je identifikátor testu NAA k dispozici v databázi JRC. Příklad: "ma":"344" (SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc Datum a čas odběru vzorku pro test Datum a čas, kdy byl vzorek pro test odebrán. Údaj o čase musí zahrnovat informace o časovém pásmu. Tato hodnota neoznačuje okamžik, kdy byl získán výsledek testu. Uvede se přesně 1 (jedno) neprázdné pole. Použije se jeden z následujících formátů ISO 8601. Jiné možnosti nejsou podporovány. RRRR-MM-DDThh:mm:ssZ RRRR-MM-DDThh:mm:ss[+-]hh RRRR-MM-DDThh:mm:ss[+-]hhmm RRRR-MM-DDThh:mm:ss[+-]hh:mm Příklady: "sc":"2021-08-20T10:03:12Z" (čas v UTC) "sc":"2021-08-20T12:03:12+02" (čas v SELČ) "sc":"2021-08-20T12:03:12+0200" (čas v SELČ) "sc":"2021-08-20T12:03:12+02:00" (čas v SELČ) t/tr Výsledek testu Výsledek testu. Kódovaná hodnota ze souboru hodnot test-result.json (na základě SNOMED CT, GPS). Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "tr":"260415000" (nedetekováno) t/tc Testovací středisko nebo zařízení Jméno aktéra, který test provedl. Identifikátory jsou povoleny jako součást názvu, ale nedoporučuje se používat je jednotlivě bez názvu jako text. Maximálně 80 znaků UTF-8. Jakékoli dodatečné znaky by měly být zredukovány. Název není určen pro automatické ověřování. Pro testy NAAT: uvede se přesně 1 (jedno) neprázdné pole. Pro testy RAT: toto pole je nepovinné. Je-li toto pole uvedeno, nesmí být prázdné. Příklad: "tc":"Testovací středisko Západní oblast 245" t/co Členský stát nebo třetí země, v nichž byl test proveden Země vyjádřená jako dvoupísmenný kód ISO3166 (DOPORUČENO) nebo odkaz na mezinárodní organizaci odpovědnou za provedení testu (např. UNHCR nebo WHO). Kódovaná hodnota ze souboru hodnot country-2-codes.json. Soubor hodnot je distribuován z brány EUDCC Gateway. Uvede se přesně 1 (jedno) pole. Příklady: "co":"CZ" "co":"UNHCR" t/is Vydavatel certifikátu Název organizace, která certifikát vydala. Identifikátory jsou povoleny jako součást názvu, ale nedoporučuje se používat je jednotlivě bez názvu jako text. Maximálně 80 znaků UTF-8. Uvede se přesně 1 (jedno) neprázdné pole. Příklady: "is":"Ministerstvo zdravotnictví České republiky" "is":"Zdravotnický orgán v severozápadním regionu" t/ci Jedinečný identifikátor certifikátu Jedinečný identifikátor certifikátu (UVCI), jak je specifikován na adrese vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Zahrnutí kontrolního součtu je nepovinné. Lze doplnit předponu "URN:UVCI:" . Uvede se přesně 1 (jedno) neprázdné pole. Příklady: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.3. Certifikát o zotavení

Skupina týkající se zotavení, pokud existuje, musí obsahovat přesně 1 (jeden) údaj popisující přesně jedno potvrzení o zotavení. Všechny prvky skupiny týkající se zotavení jsou povinné, prázdné hodnoty nejsou podporovány.







ID pole Název pole Pokyny r/tg Onemocnění, z něhož se držitel uzdravil, nebo původce onemocnění COVID-19 (SARS-CoV-2 nebo jedna z jeho variant) Kódovaná hodnota ze souboru hodnot disease-agent-targeted.json. Tato hodnota má jeden údaj 840539006, což je kód pro COVID-19 ze SNOMED CT (GPS). Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "tg":"840539006" r/fr Datum prvního pozitivního výsledku testu NAAT držitele Datum, kdy byl odebrán vzorek pro test NAAT, který vedl k pozitivnímu výsledku, ve formátu RRRR-MM-DD (vyplnit datum bez časového údaje). Jiné formáty nejsou podporovány. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "fr":"2021-05-18" r/co Členský stát nebo třetí země, v nichž byl test proveden Země vyjádřená jako dvoupísmenný kód ISO3166 (DOPORUČENO) nebo odkaz na mezinárodní organizaci odpovědnou za provedení testu (např. UNHCR nebo WHO). Kódovaná hodnota ze souboru hodnot country-2-codes.json. Soubor hodnot je distribuován z brány EUDCC Gateway. Uvede se přesně 1 (jedno) pole. Příklady: "co":"CZ" "co":"UNHCR" r/is Vydavatel certifikátu Název organizace, která certifikát vydala. Identifikátory jsou povoleny jako součást názvu, ale nedoporučuje se používat je jednotlivě bez názvu jako text. Maximálně 80 znaků UTF-8. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "is":"Ministerstvo zdravotnictví České republiky" "is":"Centrální univerzitní nemocnice" r/df Certifikát platný od První den, kdy je certifikát považován za platný. Toto datum nesmí být dřívější než datum vypočtené jako r/fr + 11 dnů. Datum musí být uvedeno ve formátu RRRR-MM-DD (úplné datum bez časového údaje). Jiné formáty nejsou podporovány. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "df":"2021-05-29" r/du Certifikát platný do Poslední den, kdy je certifikát považován za platný, který stanoví vydavatel certifikátu. Toto datum nesmí být pozdější než datum vypočtené jako r/fr + 180 dnů. Datum musí být uvedeno ve formátu RRRR-MM-DD (úplné datum bez časového údaje). Jiné formáty nejsou podporovány. Uvede se přesně 1 (jedno) neprázdné pole. Příklad: "du":"2021-11-14" r/ci Jedinečný identifikátor certifikátu Jedinečný identifikátor certifikátu (UVCI), jak je specifikován na adrese vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Zahrnutí kontrolního součtu je nepovinné. Lze doplnit předponu "URN:UVCI:" . Uvede se přesně 1 (jedno) neprázdné pole. Příklady: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

▼M3









PŘÍLOHA VI

ODPOVĚDNOSTI ČLENSKÝCH STÁTŮ JAKOŽTO SPOLEČNÝCH SPRÁVCŮ, POKUD JDE O BRÁNU PRO DIGITÁLNÍ CERTIFIKÁT EU COVID A VÝMĚNU SEZNAMŮ ZNEPLATNĚNÝCH CERTIFIKÁTŮ EU COVID

ODDÍL 1

Pododdíl 1

Rozdělení odpovědností

1) Společní správci zpracovávají osobní údaje prostřednictvím brány rámce pro důvěryhodnost v souladu s technickými specifikacemi uvedenými v příloze I.

2) Vydávající orgány členských států zůstávají výhradním správcem v souvislosti se shromažďováním, využíváním, sdělováním a veškerým dalším zpracováním informací o zneplatněných certifikátech mimo bránu, včetně postupu vedoucího ke zneplatnění certifikátu.

3) Každý správce odpovídá za zpracování osobních údajů prostřednictvím brány rámce pro důvěryhodnost v souladu s články 5, 24 a 26 obecného nařízení o ochraně osobních údajů.

4) Každý správce zřídí kontaktní místo s dedikovanou e-mailovou schránkou, jež bude sloužit pro komunikaci mezi společnými správci navzájem a mezi společnými správci a zpracovatelem.

5) Rozhodováním o veškerých otázkách vyplývajících z výměny seznamů zneplatněných certifikátů a ze společné správy souvisejícího zpracování osobních údajů a usnadňováním koordinovaného předávání pokynů Komisi jakožto zpracovateli je pověřena pracovní skupina zřízená výborem uvedeným v článku 14 nařízení (EU) 2021/953. Rozhodovací proces společných správců je řízen touto pracovní skupinou a jejím jednacím řádem, který přijme. Základním pravidlem je, že neúčast kteréhokoli společného správce na zasedání této pracovní skupiny, které bylo oznámeno alespoň sedm (7) dní před písemným svoláním, znamená tichý souhlas s výstupy tohoto zasedání pracovní skupiny. Kterýkoli ze společných správců smí svolat zasedání této pracovní skupiny.

6) Pokyny se zpracovateli zasílají prostřednictvím kontaktního místa kteréhokoliv společného správce, a to na základě dohody s ostatními společnými správci a v souladu s rozhodovacím procesem pracovní skupiny popsaným výše v bodě 5. Společný správce, který pokyn předává, by jej měl zpracovateli předat písemně a informovat o tom všechny ostatní společné správce. Je-li záležitost natolik neodkladná, že nelze uspořádat zasedání pracovní skupiny, jak uvádí bod 5 výše, může být pokyn přesto předán, ale pracovní skupina jej může zrušit. Tento pokyn by měl být předán písemně a všichni ostatní společní správci by o tom měli být v době předání pokynu informováni.

7) Zřízení pracovní skupiny podle bodu 5 neupírá žádnému ze společných správců individuální kompetenci učinit ohlášení příslušnému dozorovému úřadu podle článků 33 a 24 obecného nařízení o ochraně osobních údajů. K takovému ohlášení se nevy