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ů NBTLS.

— DCCG používá dva digitální certifikáty (DCCGTLS a DCCGTA) se dvěma odlišnými páry klíčů. Soukromý klíč z páru klíčů k DCCGTA 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 NBCSCA, který je podepsán soukromým klíčem DCGGTA.

— 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 NBTLS

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

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

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) NBCSCA 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 DCCGTA,

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

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

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

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 (1) nebo v dokumentu SOG-IS Agreed Cryptographic Mechanisms (Dohodnuté kryptografické mechanismy výboru SOG-IS) (2).

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 (3).

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 (4)).

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 (5) , o=<Poskytovatel>, c=<země> Key Usage (použití klíče) digital signature (digitální podpis) (minimálně)

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

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

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

(3) rfc5280 (ietf.org)

(4) rfc5280 (ietf.org)

(5) 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.