02021D1073 — CS — 15.09.2022 — 004.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í:

		Úřední věstník
		Č.	Strana	Datum
►M1	PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) 2021/2014 ze dne 17. listopadu 2021,	L 410	180	18.11.2021
►M2	PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) 2021/2301 ze dne 21. prosince 2021,	L 458	536	22.12.2021
►M3	PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) 2022/483 ze dne 21. března 2022,	L 98	84	25.3.2022
►M4	PROVÁDĚCÍ ROZHODNUTÍ KOMISE (EU) 2022/1516 ze dne 8. září 2022,	L 235	61	12.9.2022

---

▼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ů

Č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

▼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í

Informační obsah

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ě:

To v COSE odpovídá parametru algoritmu ES256.

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:

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í:

▼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:

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

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:

9.5.1.2.1.1.   Kódy odpovědí

Záhlaví požadavku

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

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:

9.5.1.2.2.1.   Položky

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í

9.5.1.2.2.3.   Záhlaví odpovědí

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:

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:

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:

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:

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.

►M4  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 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:

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):

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:

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.

▼M4

Pokud se země používající digitální certifikát EU COVID rozhodne vydat certifikáty o očkování účastníkům klinických hodnocení během probíhajících klinických hodnocení, léčivý přípravek – očkovací látka se kóduje podle vzoru

CT_clinical-trial-identifier

Pokud bylo klinické hodnocení registrováno v registru klinických hodnocení EU (EU-CTR), použije se identifikátor klinického hodnocení z tohoto registru. V ostatních případech mohou být použity identifikátory z jiných registrů (jako jsou internetové stránky clinicaltrials.gov nebo registr klinických hodnocení Austrálie a Nového Zélandu).

Identifikátor klinického hodnocení musí obsahovat předponu umožňující identifikaci registru klinických hodnocení (např. EUCTR pro registr klinických hodnocení EU, NCT pro clinicaltrials.gov, ACTRN pro registr klinických hodnocení Austrálie a Nového Zélandu).

Pokud Komise obdrží pokyny od Výboru pro zdravotní bezpečnost, Evropského střediska pro prevenci a kontrolu nemocí (ECDC) nebo Evropské agentury pro léčivé přípravky (EMA), pokud jde o uznávání certifikátů vydaných pro očkovací látku proti onemocnění COVID-19, která je předmětem klinických hodnocení, pokyny se zveřejní buď jako součást dokumentu obsahujícího soubory hodnot, nebo samostatně.

▼M1

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í:

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:

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.

▼M4

Pokud se země používající digitální certifikát EU COVID rozhodne vydat účastníkům klinického hodnocení certifikáty o očkování během probíhajících klinických hodnocení, držitel rozhodnutí o registraci očkovací látky nebo výrobce očkovací látky se kóduje pomocí hodnoty, která byla mu byla přidělena v souboru hodnot, je-li k dispozici. V ostatních případech se držitel rozhodnutí o registraci očkovací látky nebo výrobce očkovací látky kóduje pomocí pravidla popsaného v oddíle 3 „Léčivý přípravek – očkovací látka“ (CT_clinical-trial-identifier).

▼M1

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:

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:

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ě:

Č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:

▼M4

K označení rychlých testů na antigen i laboratorních testů na antigen se použije kód LP217198-3 (rychlý imunologický test).

▼M1

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

Použije se v certifikátu 2.

▼M4

Obsah souboru hodnot zahrnuje výběr testů na antigen uvedených ve společném a aktualizovaném seznamu 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.

▼M1

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:

▼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:

▼M1

3.    Všeobecné požadavky

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

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.

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í:

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:

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:

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:

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:

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

Č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):

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í.

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í.

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 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):

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í.

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í.

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.

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

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

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.

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.

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.

▼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.

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.

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.

▼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í

Pododdíl 2

Odpovědnosti a role při vyřizování žádostí subjektů údajů a jejich informování

ODDÍL 2

Řízení bezpečnostních incidentů včetně porušení zabezpečení osobních údajů

ODDÍL 3

Posouzení vlivu na ochranu osobních údajů

---

PŘÍLOHA VII

ODPOVĚDNOSTI KOMISE JAKOŽTO ZPRACOVATELE ÚDAJŮ, POKUD JDE O BRÁNU PRO DIGITÁLNÍ CERTIFIKÁT EU COVID A PODPORU VÝMĚNY SEZNAMŮ ZNEPLATNĚNÝCH CERTIFIKÁTŮ EU COVID

Komise:

---

( 1 ) rfc8392 (ietf.org)

( 2 ) rfc8152 (ietf.org)

( 3 ) rfc8230 (ietf.org)

( 4 ) rfc8392 (ietf.org)

( 5 ) rfc8392 (ietf.org)

( 6 ) rfc7159 (ietf.org)

( 7 ) rfc7049 (ietf.org)

( 8 ) Nařízení Evropského parlamentu a Rady (EU) 2021/953 ze dne 14. června 2021 o rámci pro vydávání, ověřování a uznávání interoperabilních certifikátů o očkování, o testu a o zotavení v souvislosti s onemocněním COVID-19 (digitální certifikát EU COVID) za účelem usnadnění volného pohybu během pandemie COVID-19 (Úř. věst. L 211, 15.6.2021, s. 1).

( 9 ) rfc1950 (ietf.org)

( 10 ) rfc1951 (ietf.org)

( 11 ) rfc7517 (ietf.org)

( 12 ) Podrobné popisy API naleznete také v oddíle 9.5.1.2.

( 13 ) Pojmem „zastaralé“ se rozumí, že o této funkci se v nových implementacích neuvažuje, avšak u stávajících implementací bude po přesně vymezené časové období podporována.

( 14 ) rfc3986 (ietf.org)

( 15 ) Při implementaci s kódy QR by členské státy mohly uvažovat o další sadě znaků až do celkové délky 72 znaků (včetně 27–30 znaků samotného identifikátoru), která by umožnila předávání dalších informací. Specifikace těchto informací je věcí členských států.

( 16 ) Algoritmus Luhn mod N je rozšířením algoritmu Luhn (který je znám rovněž jako algoritmus mod 10), který pracuje s číselnými kódy a používá se například pro výpočet kontrolního součtu čísel kreditních karet. Uvedené rozšíření umožňuje algoritmu pracovat se sekvencemi hodnot v libovolné bázi (v našem případě s písmeny).

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

( 18 ) BSI – technické pokyny TR-02102 (bund.de)

( 19 ) SOG-IS – podpůrné dokumenty (sogis.eu)

( 20 ) rfc5280 (ietf.org)

( 21 ) rfc5280 (ietf.org)