02021D1073 — ET — 15.09.2022 — 004.001

---

Käesolev tekst on üksnes dokumenteerimisvahend ning sel ei ole mingit õiguslikku mõju. Liidu institutsioonid ei vastuta selle teksti sisu eest. Asjakohaste õigusaktide autentsed versioonid, sealhulgas nende preambulid, on avaldatud Euroopa Liidu Teatajas ning on kättesaadavad EUR-Lexi veebisaidil. Need ametlikud tekstid on vahetult kättesaadavad käesolevasse dokumenti lisatud linkide kaudu

►B	KOMISJONI RAKENDUSOTSUS (EL) 2021/1073, 28. juuni 2021, millega kehtestatakse ELi digitaalse COVID-tõendi usaldusraamistiku (mis loodi Euroopa Parlamendi ja nõukogu määrusega (EL) 2021/953) kasutuselevõtu tehnilised spetsifikatsioonid ja normid (EMPs kohaldatav tekst) (ELT L 230 30.6.2021, lk 32)

Muudetud:

		Euroopa Liidu Teataja
		nr	lehekülg	kuupäev
►M1	KOMISJONI RAKENDUSOTSUS (EL) 2021/2014, 17. november 2021,	L 410	180	18.11.2021
►M2	KOMISJONI RAKENDUSOTSUS (EL) 2021/2301, 21. detsember 2021,	L 458	536	22.12.2021
►M3	KOMISJONI RAKENDUSOTSUS (EL) 2022/483, 21. märts 2022,	L 98	84	25.3.2022
►M4	KOMISJONI RAKENDUSOTSUS (EL) 2022/1516, 8. september 2022,	L 235	61	12.9.2022

---

▼B

KOMISJONI RAKENDUSOTSUS (EL) 2021/1073,

28. juuni 2021,

millega kehtestatakse ELi digitaalse COVID-tõendi usaldusraamistiku (mis loodi Euroopa Parlamendi ja nõukogu määrusega (EL) 2021/953) kasutuselevõtu tehnilised spetsifikatsioonid ja normid

(EMPs kohaldatav tekst)

Artikkel 1

I lisas on esitatud ELi digitaalse COVID-tõendi tehnilised spetsifikatsioonid, millega kehtestatakse üldine andmestruktuur, kodeerimismehhanismid ja kodeerimismehhanism andmete edastamiseks masinloetavas optilises vormingus.

Artikkel 2

Käesoleva otsuse II lisas on esitatud nõuded määruse (EL) 2021/953 artikli 3 lõikes 1 osutatud tõendite andmetega täitmise kohta.

Artikkel 3

III lisas on esitatud normid, millega kehtestatakse tõendi kordumatu tunnuse ühtne struktuur.

▼M1

Artikkel 4

IV lisas on esitatud eeskirjad, mida kohaldatakse digitaalsertifikaatide haldamise suhtes seoses ELi digitaalse COVID-tõendi lüüsi usaldusraamistiku koostalitlusvõimet toetavate aspektidega.

▼M1

Artikkel 5

Käesoleva otsuse V lisas on esitatud ühtne kooskõlastatud andmestruktuur selliste andmete jaoks, mis tuleb kanda määruse (EL) 2021/953 artikli 3 lõikes 1 osutatud tõenditele, kasutades JSON-skeemi.

▼M3

Artikkel 5a

Tühistatud tõendite loendite vahetamine

Artikkel 5b

Tühistatud tõendite loendite esitamine kolmandate riikide poolt

Kolmandad riigid, kes annavad välja COVID-19 tõendeid, mis on hõlmatud kas määruse (EL) 2021/953 artikli 3 lõike 10 või artikli 8 lõike 2 alusel vastu võetud komisjoni rakendusaktiga, võivad esitada kõnealuse rakendusaktiga hõlmatud tühistatud COVID-19 tõendite loendeid, mida komisjon töötleb kaasvastutavate töötlejate nimel artiklis 5a osutatud lüüsis kooskõlas I lisas sätestatud tehnilise spetsifikatsiooniga.

Artikkel 5c

Keskses ELi digitaalse COVID-tõendi lüüsis toimuva isikuandmete töötlemise haldamine

▼M1

Artikkel 6

Käesolev otsus jõustub Euroopa Liidu Teatajas avaldamise päeval.

▼B

Käesolev otsus jõustub Euroopa Liidu Teatajas avaldamise päeval.

---

I LISA

VORMING JA USALDUSTEENUSTE HALDUS

Üldine andmestruktuur, kodeerimismehhanismid ja kodeerimismehhanism andmete edastamiseks masinloetavas optilises vormingus (edaspidi „QR-kood“))

1.    Sissejuhatus

Käesolevas lisas esitatud tehnilised spetsifikatsioonid hõlmavad ELi digitaalse COVID-tõendi üldist andmestruktuuri ja kodeerimismehhanisme. Samuti on sellega kindlaks määratud kodeerimissüsteem andmete edastamiseks masinloetavas optilises vormingus (edaspidi „QR-kood“), mida saab kuvada mobiilseadme ekraanil või trükkida paberile. Käesolevates spetsifikatsioonides on elektroonilise tervisetõendi puhul käibel konteinerite argivormingud, mida selles kontekstis kasutatakse ELi digitaalse COVID-tõendi kanduritena.

2.    Terminoloogia

Käesolevas lisas tähendab „väljastajad“ organisatsioone, kes kasutavad nimetatud spetsifikatsioone tervisetõendite väljastamiseks, ja „kontrollijad“ organisatsioone, kes aktsepteerivad tervisetõendeid tõendina tervisliku seisundi kohta. „Osalejad“ tähendab väljastajaid ja kontrollijaid. Osalejad peavad omavahel kooskõlastama teatavaid käesolevas lisas esitatud aspekte, nagu nimeruumi haldamine ja krüptovõtmete jaotamine. Eelduste kohaselt täidab neid ülesandeid konkreetne üksus (edaspidi „sekretariaat“).

3.    Elektroonilise tervisetõendi konteineri vorming

Elektroonilise tervisetõendi konteineri vorming (Electronic Health Certificate Container Format, edaspidi „HCERT“) on välja töötatud selleks, et anda tervisetõendite eri väljastajate (edaspidi „väljastajad“) käsutusse ühetaoline ja standarditud vahend nende edastamiseks. Spetsifikatsioonide eesmärk on lihtsustada nende tõendite esitamist, kodeerimist ja allkirjastamist, et suurendada koostalitlusvõimet.

Selleks et ELi digitaalset COVID-tõendit saaks lugeda ja tõlgendada kõik väljastajad, on vaja ühtset andmestruktuuri ning kokkulepet lasti kõigi andmeväljade tähenduse kohta. Sellise koostalitlusvõime suurendamiseks määratletakse ühine ühtne andmestruktuur, kasutades ELi digitaalse COVID-tõendi raamistikuna JSON-skeemi.

3.1.    Lasti ülesehitus

Last ehitatakse üles ja kodeeritakse CBOR-kujul COSE-vormingus digiallkirjaga. Selle üldnimetus on „CBOR Web Token“ (edaspidi „CWT“), mis on määratletud dokumendis RFC 8392 ( 1 ). Järgmistes lõikudes määratletud lasti transporditakse hcert väitena.

Kontrollijal peab olema võimalik kontrollida lasti terviklust ja ehtsust. Selle mehhanismi kättesaadavaks tegemiseks peab väljastaja CWT allkirjastama, kasutades asümmeetrilist e-allkirja süsteemi, nagu see on määratletud COSE spetsifikatsioonis RFC 8152 ( 2 ).

3.2.    CWT väited

3.2.1.    Ülevaade CWT struktuurist

Kaitstud päis

Last

Allkiri

3.2.2.    Allkirja algoritm

Parameeter „allkirja algoritm“ (alg) näitab seda, millist algoritmi allkirja loomiseks kasutatakse. See peab vastama järgmistes lõikudes lühidalt kokku võetud kehtivate SOG-IS suuniste nõuetele või neid ületama.

Määratletakse üks primaarne ja üks sekundaarne algoritm. Sekundaarset algoritmi tuleks kasutada ainult juhul, kui primaarne algoritm ei ole väljastajale kehtestatud eeskirjade kohaselt aktsepteeritav.

Süsteemi turvalisuse tagamiseks peavad kõik rakendused hõlmama sekundaarset algoritmi. Sel põhjusel tuleb kasutusele võtta nii primaarne kui ka sekundaarne algoritm.

SOG-ISiga on kehtestatud primaarsete ja sekundaarsete algoritmide jaoks järgmised tasemed.

See vastab COSE algoritmi parameetrile ES256.

See vastab COSE algoritmi parameetrile PS256.

3.2.3.    Võtmeidentifikaator

Väide „võtmeidentifikaator“ (kid) näitab dokumendi allkirjastaja sertifikaati (DSC), mis sisaldab avalikku võtit, mida kontrollija peab kasutama digiallkirja õigsuse kontrollimiseks. Digitaalsertifikaatide haldust, sealhulgas DSCdele esitatavaid nõudeid, on kirjeldatud IV lisas.

Kontrollijad kasutavad väidet „võtmeidentifikaator“ (kid) selleks, et valida väljastaja (iss) väitega seotud väljastajale kuuluvate võtmete loetelust õige avalik võti. Halduslikel põhjustel ja võtmete asendamise (rollover) korral võib väljastaja kasutada paralleelselt mitut võtit. Võtmeidentifikaator ei ole turvalisuse seisukohast kriitiline väli. Seetõttu võidakse see paigutada ka kaitsmata päisesse. Kontrollijad peavad aktsepteerima mõlemat varianti. Kui olemas on mõlemad, tuleb kasutada kaitstud päises olevat võtmeidentifikaatorit.

Kuna identifikaatorit on lühendatud (piiratud ruumi tõttu), on väike, kuid siiski eksisteeriv võimalus, et kontrollija poolt heaks kiidetud dokumendi allkirjastaja sertifikaatide (Document Signer Certificates, edaspidi „DSC“) üldises loetelus leidub DSCsid, millel on sama kid. Sel põhjusel peab kontrollija kontrollima kõiki DSCsid, milles on asjaomane kid.

3.2.4.    Väljastaja

Väide „väljastaja“ (iss) on string, mis võib valikuliselt sisaldada tervisetõendit väljastava üksuse ISO 3166-1 alpha-2 riigikoodi. Kontrollija saab seda väidet kasutada, et teha kindlaks, millist DSCde kogumit kontrolliks kasutada. Selle väite identifitseerimiseks kasutatakse väitevõtit 1.

3.2.5.    Aegumisaeg

Väide „aegumisaeg“ (exp) peab sisaldama täisarvuna esitatud ajatemplit NumericDate-vormingus (vastavalt dokumendi RFC 8392 ( 4 ) jaotisele 2), mis näitab, kui kaua tuleb lasti seda konkreetset allkirja pidada kehtivaks (aeg, mille möödumisel peab kontrollija lasti tagasi lükkama kui aegunu). Aegumisparameetri eesmärk on piiritleda periood, mille jooksul tervisetõend kehtib. Selle väite identifitseerimiseks kasutatakse väitevõtit 4.

Aegumisaeg ei tohi ületada DSC kehtivusaega.

3.2.6.    Väljastusaeg

Väide „väljastusaeg“ (iat) peab sisaldama täisarvuna esitatud ajatemplit NumericDate-vormingus (vastavalt dokumendi RFC 8392 ( 5 ) jaotisele 2), mis näitab aega, kui tervisetõend loodi.

Välja „väljastusaeg“ väärtus ei tohi olla varasem kui DSC kehtivusaja algus.

Kontrollijad võivad kohaldada täiendavaid tegevuspõhimõtteid, et piirata tervisetõendi kehtivust väljastamisaja alusel. Selle väite identifitseerimiseks kasutatakse väitevõtit 6.

3.2.7.    Väide „tervisetõend“

Väide „tervisetõend“ (hcert) on dokumendi RFC 7159 ( 6 ) kohane JSON-vormingus objekt, mis sisaldab teavet tervisliku seisundi kohta. Üks ja sama väide võib hõlmata mitut tervisetõendit, millest üks on digitaalne COVID-tõend.

JSON on mõeldud pelgalt skeemi määratlusena. Edastamisvorming on dokumendis RFC 7049 ( 7 ) määratletud CBOR. Rakenduste arendajad ei pruugi tegelikkuses JSON-vormingus esitatud andmeid üldse dekodeerida ega kodeerida – selle asemel kasutavad nad mälus olevat struktuuri.

Selle väite identifitseerimiseks tuleb kasutada väitevõtit –260.

JSON-vormingus objektide stringid tuleks normaliseerida vastavalt Unicode standardis määratletud NFC-le (Normalization Form Canonical Composition). Samas peaksid dekodeerimisrakendused olema neis aspektides sallivad ja töökindlad ning tungivalt soovitatakse aktsepteerida kõiki teisendusviise. Kui dekodeerimisel või järgnevate võrdlusfunktsioonide kestel leitakse normaliseerimata andmeid, peaksid rakendused käituma nii, nagu oleks sisend NFC järgi normaliseeritud.

4.    DCC lasti jadastamine ja loomine

Jadastamismallina kasutatakse järgmist skeemi.

Protsess algab andmete ekstraheerimisega (näiteks terviseandmete hoidlast või mõnest välisest andmeallikast), struktureerides ekstraheeritud andmed digitaalse COVID-tõendi jaoks määratletud skeemide kohaselt. Selle protsessi käigus võib teisendamine kindlaksmääratud andmevormingusse ja inimloetavaks muutmine toimuda enne CBOR-vormingusse jadastamise algust. Igal juhul toimub enne jadastamist ja pärast objektimist väite akronüümide vastandamine kuvatavatele nimedele.

Määruse (EL) 2021/953 ( 8 ) kohaselt väljastatud tõendites ei ole lubatud riiklik valikuline andmesisu. Andmesisu on piiratud määruse 2021/953 lisas loetletud miinimumandmete kindlaksmääratud andmeelementidega.

5.    Kodeerimissüsteem andmete edastamiseks

5.1.    Toorkodeering

Eri andmeliideste puhul võib HCERTi konteineri ja selle lastid edastada muutmata kujul, kasutades ükskõik millist olemasolevat 8-bitist, turvalist ja usaldusväärset andmeedastust. Nende liideste hulgas võivad olla lähiväljaside (NFC), Bluetooth või edastus rakenduskihi protokolli kaudu, näiteks kui väljastaja edastab HCERTi selle omaja mobiilseadmesse.

Kui väljastaja edastab HCERTi selle omajale ainult kuvamiskihti sisaldava liidese kaudu (näiteks SMSi või e-kirjaga), ei ole toorkodeering loomulikult kohaldatav.

5.2.    Vöötkood

5.2.1.    Lasti (CWT) tihendus

Et vähendada HCERTi mahtu ning suurendada selle lugemisprotsessi kiirust ja usaldusväärsust, kasutatakse CWT tihendamisel ZLIB-vormingut (RFC 1950 ( 9 )) ja Deflate tihendusmehhanismi dokumendis (RFC 1951 ( 10 )) määratletud vormingus.

5.2.2.    QR 2D vöötkood

ASCII lastidega toimivate pärandseadmete paremaks haldamiseks kodeeritakse tihendatud CWT enne 2D vöötkoodiks kodeerimist Base45 koodi kasutades ASCIIsse.

2D vöötkoodi genereerimiseks kasutatakse standardis (ISO/IEC 18004:2015) määratletud QR-vormingut. Soovituslik veaparandustase on Q (umbes 25 %). Tulenevalt Base45 kasutamisest tuleb QR-koodis kasutada tärkkoodi (Mode 2, mida näitavad sümbolid 0010).

Selleks et kontrollijad saaksid kindlaks teha kodeeritud andmete liigi ning valida kohase dekodeerimis- ja töötlusskeemi, lisatakse Base45ga kodeeritud andmete (käesoleva spetsifikatsiooni kohaselt) ette kontekstituvastusstring „HC1:“. Selle spetsifikatsiooni tulevastes tagasiühilduvust mõjutavates versioonides määratletakse uus kontekstiidentifikaator, milles ühendile „HC“ järgnev tärk valitakse tärgistikust [1–9A–Z]. Sammud tehakse seda järjestust järgides, st kõigepealt [1–9] ja seejärel [A–Z].

Soovitatav on ilmestada koodi optiline kujutis esitusmeediumis diagonaali pikkusega 35 mm kuni 60 mm, et seda saaks kasutada liikumatu optikaga lugemisseadmetes, kui esitusmeedium peab asuma lugemisseadme pinnal.

Kui koodi optiline kujutis trükitakse paberile, kasutades väikese eraldusvõimega (< 300 dpi) printerit, tuleb hoolitseda selle eest, et kõik QR-koodi sümbolid (punktid) oleksid täpselt ruudukujulised. Kui mastabeerimine on ebavõrdeline, on mõnede QR-koodi ridade või veergude sümbolid ristkülikukujulised, mis halvendab paljudel juhtudel loetavust.

6.    Usaldusloetelu vorming (CSCA sertifikaatide ja DSCde loetelu)

Kõik liikmesriigid peavad esitama loetelu ühe või mitme riikliku allkirjastamise sertimiskeskuse (Country Signing Certification Authority, edaspidi „CSCA“) ja loetelu kõigi kehtivate dokumentide allkirjastaja sertifikaatide (Document Signer Certificate, edaspidi „DSC“) kohta ning neid loetelusid ajakohastama.

6.1.    Lihtsustatud CSCA/DSC

Alates spetsifikatsioonide sellest versioonist ei eelda liikmesriigid, et kasutatakse ükskõik millise tühistatud sertifikaatide loendi (Certificate Revocation List, edaspidi „CRL“) teavet või et teostajad kontrollivad privaatvõtme kasutamisperioodi.

Selle asemel on esmane meetod kehtivuse kontrolliks sertifikaadi olemasolu kõnealuse sertifikaatide loetelu uusimas versioonis.

6.2.    Rahvusvahelise Tsiviillennunduse Organisatsiooni (ICAO) elektrooniliselt masinloetavate reisidokumentide (eMRTD) avaliku võtme taristu (PKI) ja usalduskeskused

Liikmesriigid võivad kasutada eraldi CSCAd, kuid võivad samuti esitada oma kehtivad elektrooniliselt masinloetavate reisidokumentide (edaspidi „eMRTD“) CSCA-sertifikaadid ja/või DSCd; neil on isegi võimalus otsustada hankida need (äriühingutest) usalduskeskustelt ja need esitada. Samas peab kõik DSCd allkirjastama asjaomase liikmesriigi poolt teatatud CSCA.

7.    Turvakaalutlused

Kui liikmesriigid töötavad välja käesolevat spetsifikatsiooni kasutavat skeemi, peavad nad teatavad turvalisusega seotud aspektid määratlema ning neid analüüsima ja jälgima.

Minimaalselt tuleks arvesse võtta järgmisi aspekte.

7.1.    HCERTi allkirja kehtivusaeg

HCERTide väljastaja peab piirama allkirja kehtivusaega, määrates kindlaks selle aegumisaja. Seega peab tervisetõendi omaja seda korrapäraste ajavahemike järel uuendama.

Vastuvõetava kehtivusaja võivad ära määrata praktilised asjaolud. Näiteks reisijal ei pruugi olla võimalust uuendada tervisetõendit välisreisi kestel. Teisalt aga võib näiteks juhtuda nii, et väljastaja peab võimalikuks mõnd turvariket, mistõttu väljastaja peab DSC tühistama (muutes kehtetuks kõik seda võtit kasutades väljastatud tervisetõendid, ehkki võtme kehtivusaeg ei ole lõppenud). Sellise juhtumi mõju võib vähendada sellega, et korrapäraselt asendatakse väljastaja võtmeid ja nõutakse, et kõiki tervisetõendeid mõistlike ajavahemike järel uuendataks.

7.2.    Võtmehaldus

See spetsifikatsioon kasutab andmete tervikluse tagamiseks ja andmete päritolu autentimiseks ennekõike tugevaid krüptograafiamehhanisme. Seega on vaja säilitada privaatvõtmete konfidentsiaalsus.

Krüptovõtmete konfidentsiaalsust on võimalik rikkuda mitmel eri viisil, näiteks:

Leevendamaks riski, et allkirjastamise algoritm osutub nõrgaks, mistõttu privaatvõtmeid on võimalik murda krüptoanalüüsiga, soovitatakse käesolevas spetsifikatsioonis kõigil osalejatel rakendada sekundaarne allkirjastamise algoritm (varuvariant), mis tugineb muudele parameetritele või teistsugusele matemaatilisele probleemile kui primaarne algoritm.

Seoses nimetatud riskidega, mis on seotud väljastajate tegevuskeskkonnaga, tuleb tulemusliku kontrolli eesmärgil rakendada selliseid leevendusmeetmeid nagu privaatvõtmete genereerimine, säilitamine ja kasutamine füüsilistes turvamoodulites (edaspidi „HSM“). Tungivalt soovitatakse HSMe kasutada tervisetõendite allkirjastamiseks.

Sõltumata sellest, kas väljastaja otsustab HSMe kasutada või mitte, tuleks kehtestada võtmete asendamise ajakava, mille kohaselt võtmete asendamissagedus on võrdeline sellega, kui kaitsetud on võtmed väliste võrkude, muude süsteemide ja personali suhtes. Samuti piirab hästi valitud asendamise ajakava riske, mis on seotud ekslikult väljastatud tervisetõenditega, võimaldades väljastajal sellised tõendid vajaduse korral võtme tühistamisega ühekorraga kehtetuks muuta.

7.3.    Sisendandmete valideerimine

Neid spetsifikatsioone saab kasutada nii, et ebausaldusväärsetest allikatest andmeid võetakse vastu süsteemides, mis võivad oma loomult olla missioonikriitilised. Selle ründevektoriga seonduvate riskide minimeerimiseks tuleb kõik andmeväljad andmeliikide, pikkuste ja sisu põhjal nõuetekohaselt valideerida. Enne HCERTi sisu mistahes töötlemist tuleb samuti kontrollida väljastaja allkirja. Samas eeldab väljastaja allkirja valideerimine väljastaja kaitstud päise (Protected Issuer Header) eelnevat parsimist ja selle käigus võib võimalik ründaja teha katset sisestada hoolikalt meisterdatud teavet, mille eesmärk on õõnestada süsteemi turvalisust.

8.    Usaldusteenuste haldus

HCERTi allkirja kontrolliks on vaja avalikku võtit. Liikmesriigid avalikustavad sellised avalikud võtmed. Põhimõtteliselt peab igal kontrollijal olema loetelu kõigi avalike võtmete kohta, mida ta on nõus usaldama (kuna avalik võti ei ole HCERTi osa).

Süsteemil on (ainult) kaks kihti: iga liikmesriigi kohta on üks või mitu riigi tasandi sertifikaati, millega allkirjastatakse üks või rohkem igapäevaste toimingute juures kasutatavatest dokumentide allkirjastaja sertifikaatidest.

Liikmesriikide sertifikaate nimetatakse riiklike allkirjastamise sertimiskeskuste (CSCA) sertifikaatideks ja tegu on (tavaliselt) iseallkirjastatud sertifikaatidega. Liikmesriikidel võib neid olla rohkem kui üks (näiteks piirkondliku detsentraliseerituse korral). Selliste CSCA-sertifikaatidega allkirjastatakse korrapäraselt dokumentide allkirjastaja sertifikaate (DSC), mida kasutatakse HCERTide allkirjastamiseks.

Sekretariaat täidab talitluslikku rolli. Ta koondab ja avaldab korrapäraselt liikmesriikide DSCsid, olles neid eelnevalt kontrollinud CSCA-sertifikaatide loetelust (mis on edastatud ja mida on kontrollitud muude vahenditega).

Selle põhjal moodustuv DSCde loetelu koondab aktsepteeritavaid avalikke võtmeid (ja neile vastavaid võtmeindikaatoreid), mida kontrollijad võivad kasutada HCERTide allkirjade valideerimiseks. Kontrollijad peavad selle loetelu võtma ja seda korrapäraselt ajakohastama.

Selliste liikmesriigispetsiifiliste loetelude vormingut võib kohandada riiklike olude järgi. Seega võib selle usaldusloetelu failivorming varieeruda: näiteks võib see olla allkirjastatud JWKS (dokumendi RFC 7517 ( 11 ) jaotise 5 kohane JWK set-vorming) või mis tahes muu asjaomases liikmesriigis kasutatavale tehnoloogiale iseloomulik vorming.

Lihtsuse tagamiseks võivad liikmesriigid niihästi esitada oma ICAO eMRTD süsteemide kehtivad CSCA-sertifikaadid või – nagu soovitab WHO – luua sertifikaadi spetsiaalselt selle tervishoiuvaldkonna jaoks.

8.1.    Võtmeidentifikaator (kid)

Võtmeidentifikaator (kid) arvutatakse DSCde usaldusväärsete avalike võtmete loetelu koostamisel ja see koosneb DER-(toor)vormingusse kodeeritud DSC kärbitud (esimesed 8 baiti) SHA-256 sõrmejäljest.

Kontrollijad ei pea võtmeidentifikaatorit DSC põhjal arvutama ja saavad väljastatud tervisetõendi võtmeidentifikaatorit kohe kõrvutada usaldusloetelus oleva võtmeindikaatoriga.

8.2.    Erinevus ICAO eMRTD PKI usaldusmudelist

Ehkki spetsifikatsioonid järgivad ICAO eMRTD PKI usaldusmudeli häid tavasid, tehakse neis kiiruse eesmärgil mitu lihtsustust:

▼M3

9.    Tühistamislahendus

9.1.    DCCde tühistusloendi esitamine

Lüüsi kaudu tagatakse otspunktid ja funktsioonistik tühistusloendite säilitamiseks ja haldamiseks.

9.2.    Usaldusmudel

Kõik ühendused luuakse, kasutades standardset DCCG usaldusmudelit ning NBTLS ja NBUP sertifikaate (vt sertifikaatide haldust käsitlev osa). Tervikluse tagamiseks kasutatakse teabe pakkimisel ja üleslaadimisel CMSi kohaseid sõnumeid.

9.3.    Paki ülesehitus

9.3.1.    Pakk

Iga tühistusloend sisaldab üht või mitut kannet ning see pakitakse sellisteks pakkideks, mis sisaldavad räside komplekti ja nende metaandmeid. Pakk on muudetamatu ja sellega kehtestatakse aegumiskuupäev, mis määrab ära selle, millal võib paki kustutada. Kõigi paki üksuste aegumiskuupäev peab olema täpselt sama, mis tähendab, et pakid tuleb rühmitada aegumiskuupäeva ja DSCde allkirjastamise järgi. Igasse pakki kuulub kõige enam 1 000 kannet. Kui tühistusloend koosneb rohkemast kui 1 000 kandest, luuakse mitu pakki. Üks kanne võib esineda kõige enam ühes pakis. Pakk pakitakse CMSi kohaseks struktuuriks ja allkirjastatakse üleslaadiva riigi NBup sertifikaadiga.

9.3.2.    Pakkide register

Paki loomisel määrab lüüs sellele kordumatu ID ja see kantakse automaatselt registrisse. Pakkide register on järjestatud muutmiskuupäeva järgi kronoloogiliselt (vanemast uuemani).

9.3.3.    Lüüsi käitumine

Lüüs töötleb tühistuspakke neid mitte mingil moel muutmata: see ei saa pakkide andmeid uuendada või kustutada ega neisse andmeid lisada. Pakid edastatakse kõigile vastavat luba omavatele riikidele (vt peatükk 9.6).

Lüüs jälgib aktiivselt pakkide aegumiskuupäeva ja eemaldab aegunud pakid. Pärast paki kustutamist tagastab lüüs kustutatud paki URLile vastuse „HTTP 410 Gone“. Seega kuvatakse paki staatuseks pakkide registris „kustutatud“.

9.4.    Räsi liigid

Tühistusloend sisaldab räsisid, mis tähistavad tühistamise eri liike/atribuute. Nimetatud liigid või atribuudid on ära märgitud tühistusloendi valmenduses. Praegu on olemas järgmised liigid:

Pakkidesse lisatakse Base64 stringidena kodeeritud räsidest ainult esimesed 128 bitti, mida kasutatakse tühistatud DCC identifitseerimiseks ( 12 ).

9.4.1.    Räsi liik SHA256 (DCC allkiri)

Sellisel juhul arvutatakse räsi CWTst pärineva COSE_SIGN1 allkirja baitide põhjal. RSA kohaste allkirjade puhul kasutatakse sisendina kogu allkirja. EC-DSA allkirjaga sertifikaatide puhul kasutatakse sisendina väärtust r:

SHA256(r)

[nõutav kõigi uute rakenduste puhul]

9.4.2.    Räsi liik SHA256(UCI)

Sellisel juhul arvutatakse räsi UTF-8 vormingus kodeeritud UCI stringi põhjal ja konverteeritakse baidimassiiviks.

[taunitav, ( 13 ) kuid toetatakse tagasiühilduvuse eesmärgil].

9.4.3.    Räsi liik SHA256 (Issuing CountryCode+UCI)

Sellisel juhul UTF-8 vormingus kodeeritud riigikoodi ja UTF-8 vormingus UCI konkatenatsioon. Seejärel konverteeritakse see baidimassiiviks ja kasutatakse räsifunktsiooni sisendina.

[taunitav2, kuid toetatakse tagasiühilduvuse eesmärgil].

9.5.    API struktuur

9.5.1.    Tühistamiskandeid valmendav API

9.5.1.1.    Eesmärk

API esitab tühistusloendi kandeid pakkidena (sh pakkide registri).

9.5.1.2.    Otspunktid

9.5.1.2.1.   Pakkide loetelu allalaadimise otspunkt (Batch List Download Endpoint)

Otspunktid on üles ehitatud lihtsa skeemi kohaselt, tagastades pakkide loetelu väikese ümbrisega, mis sisaldab metaandmeid. Pakid reastatakse kuupäeva järgi kronoloogiliselt (vanemast uuemani):

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

Märkus: vaikimisi esitatakse 1 000 tulemust. Kui lipp „more“ on seadistatud olekusse „true“, on vastuses ära märgitud, et allalaaditavaid pakke on rohkem. Täiendavate üksuste allalaadimiseks peab klient seadistama päise If-Modified-Since kuupäeva, mis ei ole varasem kui viimane esitatud kanne.

Vastus sisaldab JSON-massiivi, millel on järgmine struktuur:

9.5.1.2.1.1.   Vastusekoodid

Päringu päis

9.5.1.2.2.   Pakkide allalaadimise otspunkt (Batch Download Endpoint)

Pakid sisaldavad tõendite tunnuste loetelu:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

Vastus sisaldab CMSi, sealhulgas allkirja, mis peab vastama riigi NBUP sertifikaadile. Kõikidel JSON-massiivi kuuluvatel elementidel on järgmine struktuur:

9.5.1.2.2.1.   Kanded

Märkus: praegu sisaldab kannete objekt ainult räsi, kuid ühilduvuse tagamiseks tulevaste muudatustega valiti JSON-massiivi asemel objekt.

9.5.1.2.2.2.   Vastusekoodid

9.5.1.2.2.3.   Vastuse päised

9.5.1.2.3.   Pakkide üleslaadimise otspunkt (Batch Upload Endpoint)

Üleslaadimine toimub sama otspunkti kaudu, kasutades verbi POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

Pakk allkirjastatakse NBUP sertifikaati kasutades. Lüüs kontrollib, et allkirja andis konkreetse riigi NBUP sertifikaat. Allkirjakontrolli nurjumisel üleslaadimine nurjub.

MÄRKUS: pakid on muudetamatud ja neid ei saa pärast üleslaadimist muuta. Teisalt saab neid kustutada. Kõigi kustutatud pakkide ID salvestatakse ja uue paki üleslaadimine sama IDga lükatakse tagasi.

9.5.1.2.4.   Pakkide kustutamise otspunkt (Batch Delete Endpoint)

Üleslaadimine toimub sama otspunkti kaudu, kasutades verbi DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

või ühilduvuse eesmärgil järgmise otspunkti kaudu, kasutades verbi POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

9.6.    API kaitse/isikuandmete kaitse üldmäärus

Selles punktis määratletakse rakendamisel järgitavad meetmed, mille eesmärk on täita määruse (EL) 2021/953 nõudeid isikuandmete töötlemise seisukohast.

9.6.1.    Olemasolevad autentimisviisid

Praegu kasutab lüüs sellega ühenduse loovate riikide autentimiseks NBTLS sertifikaati. Seda autentimisviisi saab kasutada lüüsiga ühenduse loonud riigi identifitseerimiseks. Seejärel saab kõnealust identiteeti kasutada juurdepääsukontrolli kasutuselevõtuks.

9.6.2.    Juurdepääsukontroll

Isikuandmete seadusliku töötlemise võimaldamiseks võtab lüüs kasutusele juurdepääsukontrollimehhanismi.

Lüüs kasutab juurdepääsukontrolli loendit koos rollipõhise turbega. Selle skeemi kohaselt peetakse kaht tabelit: ühes on kirjeldatud seda, milline roll võib kehtida milliste operatsioonide puhul milliste ressurssidega, teises tabelis seda, millised rollid on määratud millistele kasutajatele.

Käesoleva dokumendiga nõutava kontrolli rakendamiseks on tarvis kolme rolli, mis on järgmised:

Järgmised otspunktid kontrollivad, kas kasutajal on roll RevocationListReader ja selle olemasolul võimaldatakse juurdepääs, selle puudumisel on vastus HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Järgmised otspunktid kontrollivad, kas kasutajal on roll RevocationUploader ja selle olemasolul võimaldatakse juurdepääs, selle puudumisel on vastus HTTP 403 Forbidden:

POST/revocation-list

Järgmised otspunktid kontrollivad, kas kasutajal on roll RevocationDeleter ja selle olemasolul võimaldatakse juurdepääs, selle puudumisel on vastus HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Lisaks sellele nähakse lüüsiga ette usaldusväärne meetod, mida kasutades administraatorid saavad hallata kasutajatega seotud rolle viisil, millega vähendatakse inimlike eksimuste võimalust, koormamata samal ajal toimimisega seotud administraatoreid.

▼M1

---

II LISA

NORMID ELi DIGITAALSE COVID-TÕENDI ANDMETEGA TÄITMISE KOHTA

Käesoleva lisaga kehtestatud väärtuste kogumeid puudutavate üldeeskirjade eesmärk on tagada semantilise tasandi koostalitlusvõime ja need peavad võimaldama ELi digitaalse COVID-tõendi tehnilisi rakendusi. Vastavalt määruses (EL) 2021/953 sätestatule võib käesolevas lisas esitatud elemente kasutada kõigi kolme eri olukorra (vaktsineerimine/testimine/läbipõdemine) puhul. Käesolevas lisas on loetletud ainult elemendid, mis vajavad semantilist standardimist kodeeritud väärtuskogumitega.

Kodeeritud elementide riigikeelde tõlkimise eest vastutavad liikmesriigid.

Kõigi selliste andmeväljade puhul, mida ei ole järgmistes väärtuste kogumites nimetatud, kirjeldatakse kodeerimist V lisas.

Kui ükskõik millisel põhjusel ei saa kasutada allpool loetletud eelistatud koodisüsteeme, võib kasutada muid rahvusvahelisi koodisüsteeme ja koostatakse juhised selle kohta, kuidas vastendada teise koodisüsteemi koodid eelistatud koodisüsteemiga. Kui kindlaksmääratud väärtuste kogumites ei ole olemas sobilikku koodi, võib erandjuhtudel kasutada teksti (kuvatavad nimed).

Liikmesriigid, kes kasutavad oma süsteemides teistsugust kodeerimist, vastendavad oma koodid kirjeldatud väärtuste kogumitega. Igasuguse sellise vastendamise eest vastutavad liikmesriigid.

►M4  Kuna mõned käesoleva lisaga ette nähtud koodisüsteemidel põhinevad väärtuste kogumid (näiteks need, mida kasutatakse vaktsiinide ja antigeenitestide kodeerimisel) muutuvad sageli, tegeleb komisjon, keda abistavad e-tervise võrgustik ja terviseohutuse komitee, nende avaldamise ja nende regulaarse ajakohastamisega. ◄ Ajakohastatud väärtuste kogumid avaldatakse komisjoni vastaval veebisaidil, samuti e-tervise võrgustiku veebilehel. Esitatakse ülevaade tehtud muudatustest.

1.    Asjaomane haigus või haigustekitaja / haigus või haigustekitaja, mille tõendi omaja on läbi põdenud: COVID-19 (SARS-CoV-2 või üks selle variantidest)

Kasutatakse tõendite nr 1, 2 ja 3 puhul.

Kasutatakse järgmisi koode:

2.    COVID-19 vaktsiin või profülaktika

Eelistatud koodisüsteem: SNOMED CT või anatoomiline, terapeutiline ja keemiline (ATC) klassifikatsioon.

Kasutatakse tõendi nr 1 puhul.

Näide eelistatud koodisüsteemidest pärinevate koodide kohta, mida tuleb kasutada: SNOMED CT kood 1119305005 (SARS-CoV-2 antikehade põhine vaktsiin), 1119349007 (SARS-CoV-2 mRNA vaktsiin), J07BX03 (COVID-19 vaktsiinid).

Komisjon, keda toetab e-tervise võrgustik, avaldab väärtuste kogumi, milles on esitatud koodid, mida tuleb kasutada selles osas esitatud koodisüsteemide kohaselt, ja ajakohastab seda regulaarselt. Uute vaktsiiniliikide väljatöötamise ja kasutuselevõtu korral laiendatakse väärtuste kogumit.

3.    COVID-19 vastu vaktsineerimiseks kasutatud ravim

Eelistatud koodisüsteemid (eelistuse järjekorras):

Väärtuste kogumi nimi: vaktsiin.

Kasutatakse tõendi nr 1 puhul.

Näide eelistatud koodisüsteemidest pärineva koodi kohta, mida tuleb kasutada: EU/1/20/1528 (Comirnaty). Näide koodina kasutatava vaktsiini nimetuse kohta: Sputnik-V (tähistab vaktsiini Sputnik V).

Komisjon, keda toetab e-tervise võrgustik, avaldab väärtuste kogumi, milles on esitatud koodid, mida tuleb kasutada selles osas esitatud koodisüsteemide kohaselt, ja ajakohastab seda regulaarselt.

Vaktsiinide kodeerimisel kasutatakse avaldatud väärtuste kogumis leiduvat koodi, isegi kui neil on eri riikides erinevad nimed. See tuleneb asjaolust, et veel ei eksisteeri üleilmset vaktsiinide registrit, mis hõlmaks kõiki praegu kasutusel olevaid vaktsiine. Näide:

Kui see ei ole konkreetsel juhul võimalik või soovitatav, esitatakse avaldatud väärtuste kogumis eraldi kood.

▼M4

Kui ELi digitaalset COVID-tõendit kasutav riik otsustab väljastada vaktsineerimistõendi kliinilises uuringus osalejatele kliinilise uuringu ajal, siis kodeeritakse vaktsineerimiseks kasutatud ravim järgmiselt:

CT_clinical-trial-identifier (CT_kliinilise uuringu tunnus).

Kui kliiniline uuring on kantud ELi kliiniliste uuringute registrisse, siis kasutatakse kõnealuse registri kliinilise uuringu tunnust. Muudel juhtudel võib kasutada muude registrite (näiteks registri clinicaltrials.gov või Australian New Zealand Clinical Trials Registry) tunnuseid.

Kliinilise uuringu tunnus sisaldab eesliidet, mis võimaldab teha kindlaks kliiniliste uuringute registri (näiteks EUCTR ELi kliiniliste uuringute registri puhul, NCT registri clinicaltrials.gov puhul ja ACTRN registri Australian New Zealand Clinical Trials Registry puhul).

Kui komisjon on saanud terviseohutuse komiteelt, Haiguste Ennetamise ja Tõrje Euroopa Keskuselt (ECDC) või Euroopa Ravimiametilt (EMA) suuniseid kliinilist uuringut läbiva COVID-19 vaktsiini tõendi aktsepteerimise kohta, siis avaldatakse suunised kas väärtuste kogumite dokumendi osana või eraldi.

▼M1

4.    COVID-19 vaktsiini müügiloa hoidja või tootja

Eelistatud koodisüsteem:

Kasutatakse tõendi nr 1 puhul.

Näide eelistatud koodisüsteemidest pärineva koodi kohta, mida kasutada: ORG-100001699 (AstraZeneca AB). Näide koodina kasutatava organisatsiooni nime kohta: Sinovac-Biotech (tähistab organisatsiooni Sinovac Biotech).

Komisjon, keda toetab e-tervise võrgustik, avaldab väärtuste kogumi, milles on esitatud koodid, mida tuleb kasutada selles osas esitatud koodisüsteemide kohaselt, ja ajakohastab seda regulaarselt.

Sama müügiloa hoidja või sama tootja eri filiaalid kasutavad avaldatud väärtuste kogumis leiduvat koodi.

Üldjuhul kasutatakse sama vaktsiini kohta koodi, mis tähistab selle müügiloa hoidjat ELis, kuna veel ei eksisteeri vaktsiinitootjate või müügiloa hoidjate rahvusvaheliselt kokku lepitud registrit. Näited:

Kui see ei ole konkreetsel juhul võimalik või soovitatav, esitatakse avaldatud väärtuste kogumis eraldi kood.

▼M4

Kui ELi digitaalset COVID-tõendit kasutav riik otsustab väljastada vaktsineerimistõendi kliinilises uuringus osalejatele kliinilise uuringu ajal, siis kodeeritakse vaktsiini müügiloa hoidja või tootja talle väärtuste kogumis määratud väärtuse abil, kui see on saadaval. Muudel juhtudel kodeeritakse vaktsiini müügiloa hoidja või tootja punktis 3 „Vaktsineerimiseks kasutatud ravim“ (CT_clinical-trial-identifier) kirjeldatud nõuete kohaselt.

▼M1

5.    Järjekorranumber mitme doosi korral ning dooside koguarv seerias

Kasutatakse tõendi nr 1 puhul.

Kaks välja:

5.1.    Esmane vaktsineerimisseeria

Kui isik saab doose, mis kuuluvad esmasesse vaktsineerimisseeriasse, see tähendab vaktsineerimiseeriasse, mille eesmärk on pakkuda küllaldast kaitset algetapis, kajastab (C) tavalise esmase vaktsineerimisseeria dooside koguarvu (st sõltuvalt manustatud vaktsiini liigist on see 1 või 2). See hõlmab võimalust kasutada lühemat seeriat (C=1), kui liikmesriigi kohaldatava vaktsineerimiskavaga on ette nähtud, et eelnevalt SARS-CoV-2 nakkuse saanud isikutele manustatakse üks doos kahedoosilisest vaktsiinist. Seega tähistatakse täielikult läbitud esmast vaktsineerimisseeriat N/C = 1. Näide:

Kui esmast vaktsineerimisseeriat pikendatakse, näiteks tõsiselt nõrgenenud immuunsüsteemiga isikute puhul või juhul kui esmaste dooside vahelisest soovituslikust ajavahemikust ei ole kinni peetud, kodeeritakse kõik sellised doosid lisadoosidena, mis kuuluvad punkti 5.2 alla.

▼M2

5.2.    Tõhustusdoosid

Kui isik saab doose pärast esmast vaktsineerimiskuuri, kajastatakse selliseid tõhustusdoose vastavates tõendites järgmiselt:

Liikmesriigid rakendavad käesolevas punktis sätestatud kodeerimiseeskirjad 1. veebruariks 2022.

Liikmesriigid väljastavad automaatselt või asjaomaste isikute taotluse korral uuesti tõendid, milles pärast ühedoosilise esmase vaktsineerimiskuuri läbimist manustatud tõhustusdoos on kodeeritud viisil, et seda ei ole võimalik eristada esmase vaktsineerimiskuuri lõpetamisest.

Käesoleva lisa viiteid tõhustusdoosidele tuleks käsitada nii, et need hõlmavad ka lisadoose, mida manustatakse selleks, et paremini kaitsta inimesi, kelle immuunsusvastus pärast standardse esmase vaktsineerimiskuuri lõpetamist ei olnud piisav. Liimesriigid võivad määrusega (EL) 2021/953 loodud õigusraamistiku piires võtta meetmeid, et käsitleda olukorda seoses haavatavate rühmadega, kes võivad saada lisadoose esmajärjekorras. Näiteks juhul kui liikmesriik otsustab manustada lisadoose ainult elanikkonna konkreetsetele alarühmadele, võib ta kooskõlas määruse (EL) 2021/953 artikli 5 lõikega 1 otsustada, et väljastab selliste lisadooside manustamist näitavaid vaktsineerimistõendeid ainult taotluse alusel ja mitte automaatselt. Niisuguste meetmete võtmise korral teavitab liikmesriik asjaomaseid isikuid nii sellest kui ka asjaolust, et nad võivad jätkata standardse esmase vaktsineerimiskuuri läbimise järel saadud tõendi kasutamist.

▼M1

6.    Liikmesriik või kolmas riik, kus vaktsiin manustati / test tehti

Eelistatud koodisüsteem: ISO 3166 riigikoodid.

Kasutatakse tõendite nr 1, 2 ja 3 puhul.

Väärtuste kogumi sisu: täielik kahetäheliste koodide loetelu, mis on FHIRi spetsifikatsiooni kohase väärtuste kogumina kättesaadav aadressil http://hl7.org/fhir/ValueSet/iso3166-1-2. Kui vaktsineerija või testi tegija oli rahvusvaheline organisatsioon, nagu UNHCR või WHO, ja puudub teave riigi kohta, kasutatakse organisatsiooni koodi. Komisjon, keda toetab e-tervise võrgustik, avaldab sellised lisakoodid ja ajakohastab neid regulaarselt.

7.    Testi liik

Kasutatakse tõendi nr 2 puhul ja juhul kui delegeeritud õigusaktiga hakatakse toetama selliste läbipõdemistõendite väljastamist, mis tuginevad muud liiki testidele kui nukleiinhappe amplifitseerimise test, tõendi nr 3 puhul.

Kasutatakse järgmisi koode:

▼M4

Koodi LP217198-3 (Immuunkromatograafiline kiirtest) kasutatakse nii antigeeni kiirtestide kui ka laboratoorsete antigeenianalüüside tähistamiseks.

▼M1

8.    Kasutatud testi tootja ja kaubanduslik nimetus (nukleiinhappe amplifitseerimise testi puhul ei ole kohustuslik)

Kasutatakse tõendi nr 2 puhul.

▼M4

Väärtuste kogumi sisu hõlmab antigeenitestide valikut, mis on loetletud COVID-19 antigeenitestide ajakohastatud ühisloetelus, mis loodi nõukogu soovituse 2021/C 24/01 alusel ja mille on heaks kiitnud terviseohutuse komitee. Loetelu haldab Teadusuuringute Ühiskeskus ja see asub COVID-19 in vitro diagnostika meditsiiniseadmete ja testimismeetodite andmebaasis aadressil https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

▼M1

Selle koodisüsteemi puhul kasutatakse asjakohaseid välju (testimisseadme tunnus, testi ja tootja nimi) vastavalt Teadusuuringute Ühiskeskuse struktureeritud vormingule, mis on esitatud aadressil https://covid-19-diagnostics.jrc.ec.europa.eu/devices.

9.    Testitulemus

Kasutatakse tõendi nr 2 puhul.

Kasutatakse järgmisi koode:

▼B

---

III LISA

TÕENDI KORDUMATU TUNNUSE ÜHTNE STRUKTUUR

1.    Sissejuhatus

Igal ELi digitaalsel COVID-tõendil on tõendi kordumatu tunnus, mis toetab selliste tõendite koostalitlusvõimet. Tõendi kordumatut tunnust saab kasutada tõendi kontrolliks. Tõendi kordumatu tunnuse kasutuselevõtu eest vastutavad liikmesriigid. Tõendi kordumatu tunnus on vahend, millega kontrollida tõendi õigsust ja vajaduse korral siduda see registreerimissüsteemiga (näiteks immuniseerimise infosüsteemiga). Samuti võimaldavad need tunnused liikmesriikidel veenduda (paberkandja alusel ja digitaalselt), et isik on vaktsineeritud või teda on testitud.

2.    Tõendi kordumatu tunnuse ülesehitus

Tõendi kordumatu tunnus järgib ühtset struktuuri ja vormingut, mis hõlbustavad teabe tõlgendamist inimeste poolt ja/või masinaga, ning see võib puudutada selliseid elemente nagu vaktsineerimise liikmesriik, vaktsiin ise ja liikmesriigi konkreetne tunnus. See tagab liikmesriikidele paindlikkuse selle vormistamisel täielikus kooskõlas normidega isikuandmete kaitse kohta. Eri elementide järjestus vastab kindlale hierarhiale, mis võimaldab plokke tulevikus muuta, säilitades samal ajal selle struktuurse terviklikkuse.

Tõendi kordumatu tunnuse ülesehituse võimalikud lahendused moodustavad spektri, millel on kaks peamist muutuvat parameetrit – modulaarsus ja inimesepoolne tõlgendatavus – ning üks keskne omadus.

▼M1

3.    Üldnõuded

Tõendi kordumatu tunnus peab vastama järgmistele üldnõuetele.

Tagada tuleb tagasiühilduvus: liikmesriigid, kes muudavad aja jooksul oma tunnuste struktuuri (põhiversiooni – praegu on see v1 – piires), tagavad, et mis tahes kaks identset tunnust tähistavad ühte ja sama vaktsineerimistõendit/-kinnitust. Teisisõnu ei saa liikmesriigid tunnuseid taaskasutada.

▼B

4.    Vaktsineerimistõendite kordumatute tunnuste variandid

E-tervise võrgustiku suunistes kontrollitavate vaktsineerimistõendite ja nende põhiliste koostalitlusvõime elementide kohta ( 17 ) on esitatud eri võimalused, mida liikmesriigid ja muud osalised saavad kasutada ning mis võivad liikmesriikides samal ajal käibel olla. Liikmesriigid saavad sellised eri variandid kasutusele võtta tõendi kordumatu tunnuse skeemi eri versioonis.

---

IV LISA

DIGITAALSERTIFIKAATIDE HALDUS

1.    Sissejuhatus

ELi digitaalsete COVID-tõendite (digital COVID certificates, edaspidi „DCC“) signeerimisvõtmete turvaline ja usaldusväärne vahetamine liikmesriikide vahel toimub ELi digitaalse COVID-tõendi lüüsi kaudu (Digital COVID Certificate Gateway, edaspidi „DCCG“), mis toimib avalike võtmete keskse hoidlana. DCCG annab liikmesriikidele võimaluse avaldada avalikud võtmed, mis vastavad nende poolt DCCde allkirjastamiseks kasutatavatele privaatvõtmetele. DCCG-le tuginevad liikmesriigid võivad selle vahendusel hankida kiiresti uusimat avalike võtmete materjali. Hiljem saab DCCGd laiendada, et vahetada liikmesriikide esitatavat usaldusväärset lisateavet, nagu DCCde valideerimisreeglid. COVID-tõendite raamistiku usaldusmudel on avaliku võtme taristu (edaspidi „PKI“). Igal liikmesriigil on üks või mitu riiklikku allkirjastamise sertimiskeskust (Country Signing Certification Authority, edaspidi „CSCA“), kelle sertifikaadid on küllaltki pika kehtivusajaga. Vastavalt liikmesriigi otsusele võib CSCA olla sama nagu masinloetavate reisidokumentide puhul kasutatav CSCA või sellest erineda. CSCA väljastab digitaalsertifikaate riiklikele ja lühiajalistele dokumentide allkirjastajatele (st DCCde allkirjastajatele), mida nimetatakse dokumentide allkirjastaja sertifikaatideks (Document Signer Certificates, edaspidi „DSC“). CSCA toimib ankurvõtmena, nii et sellele tuginevad liikmesriigid saavad kasutada CSCA-sertifikaati korrapäraselt muutuvate DSCde ehtsuse ja tervikluse valideerimiseks. Pärast valideerimist saavad liikmesriigid kasutada nimetatud sertifikaate (või pelgalt neis sisalduvaid avalikke võtmeid) omaenese rakendustes DCCde valideerimiseks. Lisaks CSCAdele ja DSCdele tugineb DCCG tehingute autentimisel ja andmete allkirjastamisel ka PKI-le kui autentimise alusele ja vahendile, millega tagada liikmesriikide ja lüüsi vaheliste sidekanalite terviklus.

Andmete tervikluse ja ehtsuse saavutamiseks saab kasutada digiallkirju. Avalike võtmete ja kontrollitud identiteetide (või väljastajate) sidumisega loovad avaliku võtme taristud usaldusväärsuse. Seda on vaja, et muud osalised saaksid kontrollida andmete päritolu ja sidepartneri identiteeti ning teha usaldamisega seotud otsuseid. DCCG kasutab ehtsuse kinnitamiseks mitut digitaalsertifikaati. Käesolevas lisas määratakse kindlaks, milliseid digitaalsertifikaate kasutatakse ja kuidas need välja töötada, et tagada liikmesriikides nende laialdane koostalitlusvõime. Selles on esitatud üksikasjalikum teave vajalike digitaalsertifikaatide kohta ning antud suuniseid sertifikaadimallide ja kehtivusaja kohta liikmesriikides, kes soovivad käitada omaenese CSCAd. Kuna DCCsid saab kontrollida konkreetse ajavahemiku vältel (alates väljastamisest, aeguvad teatud aja jooksul), on vaja kindlaks määrata kontrollimudel kõigi digitaalsertifikaatidele ja DCCdele lisatavate allkirjade jaoks.

2.    Terminoloogia

Järgmises tabelis on esitatud käesolevas lisas kasutatud lühendid ja terminid.

3.    DCCG andmevood ja turvateenused

Selles punktis antakse ülevaade DCCG süsteemi andmevoogudest ja turvateenustest. Samuti määratletakse selles võtmed ja sertifikaadid, mida kasutatakse, et kaitsta sidet, üleslaaditud teavet, DCCsid ja allkirjastatud usaldusloetelu kõigist kaasatud CSCA-sertifikaatidest. DCCG toimib andmekeskusena, mis võimaldab liikmesriikidel vahetada allkirjastatud andmepakette.

DCCG pakub üleslaaditud andmepakette nende algkujul, mis tähendab, et DCCG ei lisa talle saabunud pakettidele DSCsid ega kustuta sealt neid. Liikmesriikide tagateenistusel on võimalik kontrollida üleslaaditud andmete läbivat terviklust ja ehtsust. Lisaks sellele kasutavad riiklikud tagateenistused ja DCCG vastastikust TLS-autentimist turvalise ühenduse loomiseks. See lisandub vahetatud andmetes leiduvatele allkirjadele.

3.1.    Autentimine ja ühenduse loomine

DCCG kasutab transpordikihi vastastikuse autentimisega turvet (TLS), et luua liikmesriigi tagateenistuse ja lüüsikeskkonna vahele autenditud ja krüpteeritud kanal. Seega on DCCG-l TLS-serveri sertifikaat (lühivormis „DCCGTLS“) ja riiklikel tagateenistustel on TLS-kliendi sertifikaat (lühivormis „NBTLS“). Sertifikaatide mallid on esitatud punktis 5. Kõik riiklikud tagateenistused võivad esitada oma TLS-sertifikaadi. See sertifikaat kantakse ühemõtteliselt valgesse nimekirja ja seega võib selle väljastada avalikult usaldatav sertimiskeskus (näiteks sertimiskeskus, kes järgib CA/Browser Forumi põhinõudeid), riiklik sertimiskeskus või see võib olla ise allkirjastatud. Iga liikmesriik vastutab oma riiklike andmete ja DCCGga ühenduse loomiseks kasutatud privaatvõtme kaitse eest. Nn oma sertifikaadi (bring your own certificate) lähenemisviisiks on vaja täpselt määratletud registreerimis- ja identimisprotsessi, samuti tühistamis- ja uuendamismenetlusi, nagu kirjeldatud punktides 4.1 , 4.2 ja 4.3. DCCG kasutab valget nimekirja, kuhu NBde TLS-sertifikaadid lisatakse pärast nende edukat registreerimist. Turvalise ühenduse DCCGga saavad luua ainult need NBd, kes autendivad ennast privaatvõtmega, mis vastab valgesse nimekirja kuuluvale sertifikaadile. Ka DCCG kasutab TLS-sertifikaati, mis võimaldab NBdel kontrollida, et nad loovad tõepoolest ühenduse tegeliku DCCGga, mitte mõne DCCGd teeskleva pahatahtliku üksusega. DCCG sertifikaat antakse NBdele pärast edukat registreerimist. DCCGTLS sertifikaadi väljastab avalikult usaldatav sertimiskeskus (sealhulgas kõigi peamiste brauserite jaoks). Selle eest, et ühendus DCCGga on turvaline, vastutavad liikmesriigid (näiteks võivad nad võrrelda ühendusserveri DCCGTLS sertifikaadi sõrmejälge sellega, mis edastati pärast registreerimist).

3.2.    Riiklikud allkirjastamise sertimiskeskused ja valideerimismudel

DCCG raamistikus osalevad liikmesriigid peavad DSCde väljastamiseks kasutama CSCAd. Liikmesriikidel võib olla rohkem kui üks CSCA (näiteks piirkondliku detsentraliseerituse korral). Iga liikmesriik võib kas kasutada olemasolevaid sertimiskeskusi või luua spetsiaalse (võimaluse korral iseallkirjastatud) sertimiskeskuse DCC-süsteemi jaoks.

Ametliku kaasamisprotsessi käigus peavad liikmesriigid esitama oma CSCA-sertifikaadi(d) DCCG käitajale. Pärast liikmesriigi edukat registreerimist (täpsemat teavet vt punkt 4.1) uuendab DCCG käitaja allkirjastatud usaldusloetelu, mis sisaldab kõiki DCC raamistikus aktiivseid CSCA-sertifikaate. DCCG käitaja kasutab spetsiaalset asümmeetrilist võtmepaari, et usaldusloetelu ja sertifikaadid vallaskeskkonnas allkirjastada. Privaatvõtit ei säilitata DCCG sidussüsteemis, nii et sidussüsteemi rikkumine ei anna ründajale võimalust rikkuda usaldusloetelu. Sellele vastav ankurvõtme sertifikaat (DCCGTA) antakse riiklike tagateenistuste käsutusse kaasamisprotsessi käigus.

Liikmesriigid saavad usaldusloetelu oma kontrollimenetluste jaoks DCCG-lt. CSCA on määratletud kui DSCsid väljastav sertimiskeskus ja seega peavad liikmesriigid, kes kasutavad mitmetasandilist sertimiskeskuste hierarhiat (näiteks juursertimiskeskus -> CSCA -> DSCd), esitama DSCsid väljastava alamsertimiskeskuse. Sellisel juhul, see tähendab kui liikmesriik kasutab olemasolevat sertimiskeskust, eirab DCC-süsteem kõike, mis on CSCAst ülalpool, ja paneb valgesse nimekirja ankurvõtmena ainult CSCA (hoolimata sellest, et tegu on alamsertimiskeskusega). See tuleneb asjaolust, et ICAO mudel võimaldab ainult täpselt kaht tasandit – nn juur ehk CSCA ja nn leht ehk DSC, mis on allkirjastatud just selle CSCA poolt.

Juhul kui liikmesriik käitab omaenese CSCAd, vastutab selle sertimiskeskuse turvalise toimimise ja võtmehalduse eest liikmesriik. CSCA toimib DSCde ankurvõtmena ja seega on CSCA privaatvõtme kaitse DCC keskkonna tervikluse seisukohalt keskse tähtsusega. DCC PKI kontrollimudel on kestmudel (shell model), mis deklareerib, et kõik sertifitseerimisahela valideerimiseks kasutatavad sertifikaadid peavad kehtima teataval ajal (st allkirja valideerimise ajal). Seega kehtivad järgmised piirangud:

Punktis 4.2 on esitatud soovitused kehtivusaegade kohta.

3.3.    Üleslaaditud andmete terviklus ja ehtsus

Riiklikud tagateenistused saavad DCCGd pärast edukat vastastikust autentimist kasutada selleks, et laadida üles ja alla digitaalselt allkirjastatud andmepakette. Alguses sisaldavad need andmepaketid liikmesriikide DSCsid. Võtmepaari, mida riiklik tagateenistus kasutab DCCG süsteemi üles laaditud andmepakettidele digiallkirjastamiseks, nimetatakse riikliku tagateenistuse üleslaadimisallkirja võtmepaariks ja selle vastava digitaalsertifikaadi lühivorm on NBUP-sertifikaat. Iga liikmesriik kasutab omaenese isiklikku NBUP-sertifikaati, mis võib olla iseallkirjastatud või mille võib olla väljastanud olemasolev sertimiskeskus, näiteks riiklik sertimiskeskus (st vastavalt CA/Browser Forumi põhinõuetele sertifikaate väljastav sertimiskeskus). NBUP-sertifikaat erineb kõigist liikmesriigi kasutatavatest sertifikaatidest (st CSCA, TLSi klient või DSCd).

Liikmesriigid peavad üleslaadimissertifikaadi DCCG käitajale esitama algse registreerimismenetluse käigus (üksikasjalikum teave vt punkt 4.1). Iga liikmesriik vastutab oma riiklike andmete eest ja peab kaitsma üleslaaditud andmete allkirjastamiseks kasutatavat privaatvõtit.

Teised liikmesriigid saavad allkirjastatud andmepakette kontrollida, kasutades DCCG poolt nende käsutusse antud üleslaadimissertifikaate. Enne üleslaaditud andmete edastamist teistele liikmesriikidele kontrollib DCCG selle ehtsust ja terviklust NB üleslaadimissertifikaadi abil.

3.4.    DCCG tehnilisele arhitektuurile esitatavad nõuded

DCCG tehnilise arhitektuuri suhtes kehtivad järgmised nõuded.

4.    Sertifikaatide elutsükli haldus

4.1.    Riiklike tagateenistuste registreerimine

Liikmesriigid peavad DCCG süsteemis osaleva käitaja DCCG juures registreerima. Käesolevas punktis on kirjeldatud tehnilisi toiminguid ja töökorda, mida tuleb järgida riikliku tagateenistuse registreerimiseks.

DCCG käitaja ja liikmesriigid peavad kaasamisprotsessi eesmärgil vahetama teavet tehniliste kontaktisikute kohta. Eeldatakse, et tehnilised kontaktisikud on nende liikmesriigi poolt õiguspäraseks tunnistatud ja identimine/autentimine toimub muude kanalite kaudu. Näiteks võib autentimine toimuda nii, et liikmesriigi tehniline kontaktisik esitab sertifikaadid salasõnaga krüpteeritud failidena e-postiga ja annab vastava salasõna DCCG käitajale telefonitsi. Samuti võib kasutada muid DCCG käitaja poolt kindlaksmääratud turvalisi kanaleid.

Registreerimise ja identimise käigus peab liikmesriik esitama kolm elektroonilist sertifikaati:

Kõik esitatud sertifikaadid peavad vastama punktis 5 esitatud nõuetele. DCCG käitaja kontrollib, et esitatud sertifikaat vastab punktis 5 esitatud nõuetele. Pärast identimist ja registreerimist teeb DCCG käitaja järgmist.

4.2.    Sertimiskeskused, kehtivusajad ja uuendamine

Juhul kui liikmesriik soovib kasutada omaenese CSCAd, võivad CSCA-sertifikaadid olla iseallkirjastatud sertifikaadid. Need toimivad liikmesriigi ankurvõtmena ja seega peab liikmesriik CSCA-sertifikaadi avalikule võtmele vastavat privaatvõtit kindlalt kaitsma. Liikmesriigil soovitatakse oma CSCA jaoks kasutada vallassüsteemi, st arvutisüsteemi, mis ei ole ühendatud ühtegi võrku. Süsteemile juurdepääsuks tuleb kasutada mitut inimest nõudvat korda (näiteks järgides nn nelja silma põhimõtet). Pärast DSCde allkirjastamist kohaldatakse toimimiskontrolli, CSCA privaatvõtit sisaldavat süsteemi hoitakse turvaliselt ja juurdepääsu sellele kontrollitakse rangelt. CSCA privaatvõtme täiendavaks kaitseks võib kasutada füüsilisi turvamooduleid või kiipkaarte. Elektroonilistel sertifikaatidel on kehtivusaeg, mis sunnib sertifikaati uuendama. Uuendamist on vaja, et kasutada värskeid krüptovõtmeid ja kohandada võtmete pikkust, kui kasutatava krüptoalgoritmi turvalisust ohustavad uued edusammud andmetöötluse vallas või uued ründed. Kasutatakse kestmudelit (vt punkt 3.2).

Arvestades digitaalsete COVID-tõendite aastast kehtivust, soovitatakse järgmisi kehtivusaegu:

Õigeaegseks uuendamiseks soovitatakse privaatvõtmete puhul järgmisi kasutusaegu:

Selleks et võimaldada sujuvat toimimist, peavad liikmesriigid looma uued üleslaadimissertifikaadid ja TLS-sertifikaadid õigeaegselt, näiteks kuu aega enne nende aegumist. CSCA sertifikaate ja DSCsid tuleks uuendada vähemalt kuu aega enne privaatvõtme kehtivuse lõppu (võttes arvesse vajalikke korralduslikke meetmeid). Liikmesriigid peavad esitama uuendatud CSCA, üleslaadimis- ja TLS-sertifikaadid DCCG käitajale. Aegunud sertifikaadid eemaldatakse valgest nimekirjast ja usaldusloetelust.

Liikmesriigid ja DCCG käitaja peavad ise jälgima oma sertifikaatide kehtivust. Puudub keskne üksus, kes peaks arvet sertifikaatide kehtivuse üle ja osalisi teavitaks.

4.3.    Sertifikaatide tühistamine

Üldiselt saab elektroonilise sertifikaadi tühistada selle väljastanud sertimiskeskus, kasutades tühistatud sertifikaatide loendit või OCSP kehtivuskinnitusi. DCC süsteemi CSCAd peaksid esitama tühistatud sertifikaatide loendi. Isegi kui teised liikmesriigid neid tühistatud sertifikaatide loendeid praegu ei kasuta, tuleks need integreerida tulevaseks kasutuseks. Juhul kui CSCA otsustab tühistatud sertifikaatide loendeid mitte esitada, tuleb kõnealuse CSCA DSCsid uuendada, kui tühistatud sertifikaatide loendid muutuvad kohustuslikuks. Kontrollijad ei peaks DSCde valideerimiseks kasutama mitte OCSP kehtivuskinnitusi, vaid tühistatud sertifikaatide loendeid. On soovitatav, et riiklik tagateenistus tegeleb DCC lüüsist alla laaditud DSCde vajaliku valideerimisega ja edastab riiklikele DCC valideerijatele ainult usaldusväärsete ja valideeritud DSCde kogumi. DCC valideerijad ei peaks oma valideerimisprotsessi käigus tegelema DSC kehtivuse kontrolliga. Selle üks põhjus on kaitsta DCC omajate privaatsust, vältides mis tahes võimalust, et ühe konkreetse DSC kasutamist saaks jälgida sellega seotud OCSP kehtivuskinnituse kaudu.

Liikmesriigid saavad oma DSCd kehtivat üleslaadimis- ja TLS-sertifikaati kasutades DCCGst ise eemaldada. DSC eemaldamine tähendab, et kui liikmesriigid laadivad alla DSCde uuendatud loetelu, muutuvad kõik selle DSCga väljastatud DCCd kehtetuks. DSCdele vastava privaatvõtme materjali kaitse on eluliselt tähtis. Kui liikmesriigid peavad üleslaadimis- või TLS-sertifikaate uuendama, näiteks riikliku tagateenistuse rikkumise tõttu, peavad nad DCCG käitajat sellest teavitama. Siis saab DCCG käitaja mõjutatud sertifikaadilt usalduse ära võtta, näiteks eemaldades selle TLSi valgest nimekirjast. DCCG käitaja võib üleslaadimissertifikaadid DCCG andmebaasist eemaldada. Sellele üleslaadimissertifikaadile vastava privaatvõtmega allkirjastatud paketid kaotavad kehtivuse, kui riiklikud tagateenistused usalduse tühistatud sertifikaadilt ära võtavad. Juhul kui tühistada tuleb CSCA-sertifikaat, teavitavad liikmesriigid DCCG käitajat, samuti teisi liikmesriike, kellega neil on usaldussuhted. DCCG käitaja väljastab uue usaldusloetelu, milles asjaomast sertifikaati enam ei ole. Kõik selle CSCA väljastatud DSCd kaotavad kehtivuse, kui liikmesriigid oma tagateenistuse usaldusväärsete sertifikaatide ladu uuendavad. Juhul kui on vaja tühistada DCCGTLS sertifikaat või DCCGTA sertifikaat, peavad DCCG käitaja ja liikmesriik tegema koostööd, et luua uus usaldatav TLS-ühendus ja usaldusloetelu.

5.    Sertifikaatide mallid

Selles punktis on esitatud nõuded ja suunised krüptograafia kohta, samuti teatavatele mallidele esitatavad nõuded. DCCG sertifikaatide kohta on käesolevas punktis määratletud sertifikaatide mallid.

5.1.    Krüptograafilised nõuded

Krüptoalgoritmid ja TLSi šifrikomplektid võib valida vastavalt Saksamaa Infoturbe Liiduameti (BSI) või SOG-ISi soovitustele. Need soovitused on sarnased muude institutsioonide ja standardiorganisatsioonide soovitustega. Soovitused on esitatud tehnilistes suunistes TR 02102-1 ja TR 02102-2 ( 18 ) või SOG-ISi dokumendis „Agreed Cryptographic Mechanisms“ ( 19 ).

5.1.1.    Nõuded DSC-le

Kehtivad I lisa punktis 3.2.2 esitatud nõudeid. Seega soovitatakse tungivalt, et dokumentide allkirjastajad kasutaksid elliptiliste kõverate digiallkirja algoritmi ja NIST-p-256 (nagu on kirjeldatud standardi (FIPS PUB 186–4) D lisas). Teistele elliptilistele kõveratele puudub tugi. DCC ruumipiirangute tõttu ei peaks liikmesriigid kasutama RSA-PSSi, ehkki see on lubatud kui algoritmi varuvariant. Juhul kui liikmesriik kasutab RSA-PSSi, peaks mooduli suurus olema 2048 või kõige enam 3072 bitti. DSC allkirja krüptograafilise räsifunktsiooni jaoks tuleb kasutada SHA-2, mille väljund on ≥ 256 bitti (vt ISO/IEC 10118-3:2004).

5.1.2.    Nõuded seoses TLS-, üleslaadimis- ja CSCA-sertifikaatidega

DCCG kontekstis on peamised nõuded, mis esitatakse krüptoalgoritmidele ja võtmete pikkusele elektrooniliste sertifikaatide ja krüpteeritud allkirjade puhul, kokku võetud järgmises tabelis (2021. aasta seisuga).

EC-DSA soovituslik elliptiline kõver on NIST-p-256 tulenevalt selle laialdasest kasutusest.

5.2.    CSCA sertifikaat (NBCSCA)

Järgmises tabelis antakse suuniseid NBCSCA sertifikaadi malli kohta, kui liikmesriik otsustab DCC süsteemi jaoks käitada omaenese CSCAd.

Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

Subjekti nimi peab olema mittetühi ja nimetatud liikmesriigis kordumatu. Riigikood (c) peab langema kokku seda CSCA-sertifikaati kasutava liikmesriigiga. Sertifikaat peab sisaldama dokumendi RFC 5280 ( 20 ) kohast subjekti võtme identifikaatorit.

5.3.    Dokumendi allkirjastaja sertifikaat (DSC)

Järgmises tabelis on esitatud suunised DSC kohta. Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

DSC peab olema allkirjastatud privaatvõtmega, mis vastab liikmesriigi poolt kasutatavale CSCA-sertifikaadile.

Kasutada tuleb järgmisi laiendeid:

Lisaks sellele peaks sertifikaat sisaldama tühistatud sertifikaatide loendi väljastamispunkti laiendit, mis viitab tühistatud sertifikaatide loendile, mille on esitanud DSC väljastanud CSCA.

DSC võib sisaldada laiendatud võtmekasutuslaiendit, milles on null või rohkem võtmekasutuse otstarbe tunnust, mis piiravad seda, millist liiki HCERTe asjaomane sertifikaat tohib kontrollida. Kui neid on üks või rohkem, võrdlevad kontrollijad võtit selle kontrolliks salvestatud HCERTiga. Selle jaoks on määratletud järgmised extendedKeyUsage väärtused.

Juhul kui võtmekasutuslaiend puudub (st puuduv laiend või null laiendit), võib asjaomast sertifikaati kasutada ükskõik mis liiki HCERTi valideerimiseks. Muudes dokumentides võidakse määratleda võtmekasutuslaiendis asjakohased täiendavad otstarbe tunnused, mida kasutatakse HCERTide valideerimiseks.

5.4.    Üleslaadimissertifikaadid (NBUP)

Järgmises tabelis on esitatud suunised riikliku tagateenistuse üleslaadimissertifikaadi kohta. Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

5.5.    Riikliku tagateenistuse TLS-kliendi autentimine (NBTLS)

Järgmises tabelis on esitatud suunised riikliku tagateenistuse TLS-kliendi autentimissertifikaadi kohta. Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

Samuti võib sertifikaat sisaldada võtmekasutuslaiendit serveri autentimine ( 1.3.6.1.5.5.7.3.1), kuid see ei ole nõutav.

5.6.    Usaldusloetelu allkirjastamise sertifikaat (DCCGTA)

DCCG ankurvõtme sertifikaat on määratletud järgmises tabelis.

5.7.    DCCG TLS serveri sertifikaadid (DCCGTLS)

DCCG TLS-sertifikaat on määratletud järgmises tabelis.

Samuti võib sertifikaat sisaldada võtmekasutuslaiendit kliendi autentimine ( 1.3.6.1.5.5.7.3.2), kuid see ei ole nõutav.

DCCG TLS-sertifikaadi väljastab avalikult usaldatav sertimiskeskus (sealhulgas kõigi peamiste brauserite ja operatsioonisüsteemide jaoks järgides CA/Browser Forumi põhinõudeid).

▼M1

---

V LISA

JSON-SKEEM

1.    Sissejuhatus

Käesoleva lisaga kehtestatakse ELi digitaalse COVID-tõendi (Digital COVID Certificate, edaspidi „DCC“) tehniline andmestruktuur, mis on esitatud JSON-skeemina. Dokumendis on esitatud konkreetsed juhised eri andmeväljade kohta.

2.    JSON-skeemi asukoht ja versioonid

ELi DCC autentne ametlik JSON-skeem tehakse kättesaadavaks aadressil https://github.com/ehn-dcc-development/ehn-dcc-schema. Muud asukohad ei ole autoriteetsed, kuid neid võib kasutata tulevaste läbivaatamiste ettevalmistamiseks.

Vaikimisi näidatakse sel internetiaadressil praegu genereerimiseks kasutatavat kehtivat versiooni, mis on esitatud käesolevas lisas ja mida toetavad kõik riigid.

Tulevast uut versiooni, mida peavad kindlaks kuupäevaks toetama kõik riigid, näidatakse esitatud internetiaadressil versioonisildiga, mida on täpsemalt kirjeldatud saatefailis (Readme).

▼M3

3.    Ühtne struktuur ja üldnõuded

ELi digitaalset COVID-tõendit ei anta välja, kui puuduva teabe tõttu ei ole võimalik kõiki andmevälju käesoleva spetsifikatsiooni kohaselt andmetega täita. Seda ei tohiks mõista nii, nagu mõjutaks see liikmesriikide kohustust anda välja ELi digitaalseid COVID-tõendeid.

Kõigi väljade teabe esitamisel võib kasutada UTF-8-vormingus kodeeritud UNICODE 13.0 märke, välja arvatud juhul, kui selleks on eraldi määratud piiratud väärtuste kogumid või väiksemad märgistikud.

Ühtne struktuur on järgmine:

„JSON“:{

„ver“:<teave versiooni kohta>,

„nam“:{

<teave isiku nime kohta>

},

„dob“:<sünniaeg>,

„v“ või „t“ või „r“:[

{<teave vaktsiinidoosi või testi või läbipõdemise kohta, üks kanne>}

]

}

Üksikasjalik teave iga üksiku rühma ja välja kohta on esitatud järgmistes punktides.

Kui reeglite kohaselt tuleb väli vahele jätta, tähendab see, et välja sisu on tühi ja et sisus ei ole lubatud ei selle nimi ega selle väärtus.

3.1.    Versioon

Esitatakse teave versiooni kohta. Versioonitähistusel kasutatakse semantilist tähistusviisi (Semantic Versioning: https://semver.org). Genereerimisel on see üks ametlikult välja lastud (kehtiv või üks vanematest ametlikult välja lastud) versioonidest. Üksikasjalikum teave vt JSON-skeemi asukoht.

3.2.    Isikunimi ja sünniaeg

Isikunimi on isiku ametlik täisnimi, mis langeb kokku reisidokumentidel märgitud nimega. Struktuuri tunnus on nam. Esitatakse täpselt 1 (üks) isikunimi.

3.3.    Tõendiliigispetsiifilise teabe rühmad

JSON-skeem toetab kolme kannete rühma, mis hõlmab tõendiliigispetsiifilist teavet. Igasse ELi DCCsse kuulub täpselt 1 (üks) rühm. Tühjad rühmad ei ole lubatud.

▼M1

4.    Tõendiliigispetsiifiline teave

4.1.    Vaktsineerimistõend

Vaktsineerimisrühma olemasolul sisaldab see täpselt 1 (üht) kannet, mis kirjeldab täpselt üht vaktsineerimist (üht doosi). Kõik vaktsineerimisrühma elemendid on kohustuslikud, tühje välju ei toetata.

4.2.    Testimistõend

Testimisrühma olemasolul sisaldab see täpselt 1 (üht) kannet, mis kirjeldab täpselt 1 (üht) testitulemust.

4.3.    Läbipõdemistõend

Läbipõdemisrühma olemasolul sisaldab see täpselt 1 (üht) kannet, mis kirjeldab täpselt üht (1) läbipõdemist. Kõik läbipõdemisrühma elemendid on kohustuslikud, tühje välju ei toetata.

▼M3

---

VI LISA

LIIKMESRIIKIDE KUI ELi DIGITAALSE COVID-TÕENDI LÜÜSI KAASVASTUTAVATE TÖÖTLEJATE ÜLESANDED SEOSES ELi DCC TÜHISTUSLOENDITE VAHETAMISEGA

1. JAGU

1. alajagu

Vastutuse jaotus

2. alajagu

Andmesubjektide taotluste käsitlemise ja teavitamisega seotud ülesanded ja rollid

2. JAGU

Turvaintsidentide, sealhulgas isikuandmetega seotud rikkumiste haldamine

3. JAGU

Andmekaitsealane mõjuhinnang

---

VII LISA

KOMISJONI KUI ELi DIGITAALSE COVID-TÕENDI LÜÜSI VOLITATUD TÖÖTLEJA ÜLESANDED SEOSES ELi DCC TÜHISTUSLOENDITE VAHETAMISE TOETAMISEGA

Komisjon teeb järgmist.

---

( 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 ) Euroopa Parlamendi ja nõukogu 14. juuni 2021. aasta määrus (EL) 2021/953, millega kehtestatakse koostalitlusvõimeliste COVID-19 vaktsineerimis-, testimis- ja läbipõdemistõendite (ELi digitaalne COVID-tõend) väljaandmise, kontrollimise ja aktsepteerimise raamistik, et hõlbustada vaba liikumist COVID-19 pandeemia ajal (ELT L 211, 15.6.2021, lk 1).

( 9 ) rfc1950 (ietf.org)

( 10 ) rfc1951 (ietf.org)

( 11 ) rfc7517 (ietf.org)

( 12 ) API üksikasjaliku kirjelduse kohta vt ka punkt 9.5.1.2.

( 13 ) „Taunitav“ – funktsiooni ei võeta arvesse uutes rakendustes, kuid olemasolevad rakendused toetavad seda täpselt määratletud ajavahemiku jooksul.

( 14 ) rfc3986 (ietf.org)

( 15 ) QR-koodide kasutuselevõtu korral võivad liikmesriigid kaaluda võimalust kasutada lisamärke kogupikkusega kuni 72 märki (sealhulgas tunnuse enese 27–30 märki), et edastada muud teavet. Selle, millise teabega on tegu, määravad kindlaks liikmesriigid ise.

( 16 ) Luhn’i mod N algoritm on laiendatud Luhn’i algoritm (mida nimetatakse ka mod 10 algoritmiks), mis toimib numbrikoodide puhul ja mida kasutatakse näiteks krediitkaartide kontrollsumma arvutamiseks. Laiendus võimaldab algoritmil toimida ükskõik millise väärtuste jada puhul (siinsel juhul tähtedega).

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

( 18 ) BSI - Technical Guidelines TR-02102 (bund.de)

( 19 ) SOG-IS - Supporting documents (sogis.eu)

( 20 ) rfc5280 (ietf.org)

( 21 ) rfc5280 (ietf.org)