02021D1073 — ET — 25.04.2022 — 003.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:









▼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

1. ELi digitaalse COVID-tõendi usaldusraamistik võimaldab ELi digitaalse COVID-tõendi keskse lüüsi (edaspidi „lüüs“) kaudu vahetada tühistatud tõendite loendeid kooskõlas I lisas esitatud tehnilise spetsifikatsiooniga.

2. Kui liikmesriigid tühistavad ELi digitaalseid COVID-tõendeid, võivad nad lüüsile esitada tühistatud tõendite loendeid.

3. Kui liikmesriigid esitavad tühistatud tõendite loendeid, peavad väljaandvad asutused tühistatud tõendite loendi alles hoidma.

4. Kui lüüsi kaudu vahetatakse isikuandmeid, piirdub töötlemine sellega, mida on vaja tühistamisteabe vahetamise toetamiseks. Kõnealuseid isikuandmeid kasutatakse üksnes selleks, et kontrollida määruse (EL) 2021/953 kohaldamisalasse kuuluvate ELi digitaalsete COVID-tõendite tühistamise staatust.

5. Lüüsile esitatav teave sisaldab järgmisi andmeid kooskõlas I lisas esitatud tehnilise spetsifikatsiooniga: a) tühistatud tõendite pseudonüümitud kordumatud tunnused, b) esitatud tühistatud tõendite loendi aegumiskuupäev.

6. Kui väljaandev asutus tühistab määruse (EL) 2021/953 või määruse (EL) 2021/954 kohaselt välja antud ELi digitaalseid COVID-tõendeid ja kavatseb lüüsi kaudu asjakohast teavet vahetada, edastab ta lõikes 5 osutatud teabe lüüsile tühistatud tõendite loenditena turvalises vormingus vastavalt I lisas esitatud tehnilisele spetsifikatsioonile.

7. Väljaandvad asutused pakuvad võimaluse korral välja lahenduse selleks, et teatada tühistatud tõendite omajatele nende tõendite tühistamisest ja tühistamise põhjustest tühistamise ajal.

8. Lüüs kogub saadud tühistatud tõendite loendid kokku. See peab pakkuma vahendid loendite levitamiseks liikmesriikidele. Lüüs kustutab loendid automaatselt vastavalt iga taotluse esitanud asutuse poolt iga loendi kohta teatatud kehtivusaja lõppkuupäevale.

9. Liikmesriikide määratud riiklikud asutused või ametiasutused, kes töötlevad lüüsis isikuandmeid, on kõnealuste andmete kaasvastutavad töötlejad. Kaasvastutavate töötlejate vastavad kohustused jaotatakse vastavalt VI lisale.

10. Komisjon on lüüsis töödeldavate isikuandmete volitatud töötleja. Komisjon, toimides liikmesriikide nimel volitatud töötlejana, tagab lüüsis isikuandmete edastamise ja majutamise turvalisuse ning täidab volitatud töötleja kohustusi, mis on sätestatud VII lisas.

11. Komisjon ja kaasvastutavad töötlejad kontrollivad ja hindavad korrapäraselt lüüsis isikuandmete töötlemise turvalisuse tagamiseks vajalike tehniliste ja korralduslike meetmete tulemuslikkust.

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

1. Kaasvastutavate töötlejate otsustusprotsessi juhib määruse (EL) 2021/953 artiklis 14 osutatud komitee raames loodud töörühm.

2. Liikmesriikide määratud riiklikud asutused või ametiasutused, kes töötlevad lüüsis isikuandmeid kaasvastutavate töötlejatena, määravad sellesse rühma oma esindajad.

▼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

— Allkirja algoritm (alg, märgend 1)

— Võtmeidentifikaator (kid, märgend 4)

Last

— Väljastaja (iss, väitevõti 1, ei ole kohustuslik, väljastaja ISO 3166-1 alpha-2)

— Väljastusaeg (iat, väitevõti 6)

— Aegumisaeg (exp, väitevõti 4)

— Tervisetõend (hcert, väitevõti –260)

— ELi digitaalne COVID-tõend v1 (eu_DCC_v1, väitevõti 1)

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.

— Primaarne algoritm: primaarne algoritm on standardi (ISO/IEC 14888–3:2006) jaotises 2.3 määratletud elliptiliste kõverate digiallkirja algoritm (Elliptic Curve Digital Signature Algorithm, ECDSA), kasutades standardi (FIPS PUB 186–4) D lisas (D.1.2.3) määratletud P–256 parameetreid koos standardi (ISO/IEC 10118–3:2004) funktsioonis 4 määratletud SHA–256 räsialgoritmiga.

See vastab COSE algoritmi parameetrile ES256.

— Sekundaarne algoritm: sekundaarne algoritm on dokumendis RFC 8230 ( 3 ) määratletud RSASSA-PSS koos 2048 bitise mooduliga kombinatsioonis standardi (ISO/IEC 10118–3:2004) funktsioonis 4 määratletud SHA–256 räsialgoritmiga.

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:

— võtme genereerimisprotsessis võib tekkida viga, mistõttu võtmed on nõrgad;

— võtmed võidakse avalikustada inimliku eksimuse tõttu;

— organisatsiooni kuuluv või selle väline isik võib võtmed varastada;

— võtmed võidakse välja arvutada krüptoanalüüsi kasutades.

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:

— liikmesriik võib esitada mitu CSCA-sertifikaati;

— DSC (võtme kasutamise) kehtivusajaks võib seada mis tahes aja, mis ei ületa CSCA-sertifikaadi kehtivusaega, ja see võib puududa;

— DSCd võivad sisaldada tervisetõendite-spetsiifilisi otstarbe tunnuseid (võtmekasutuslaiend);

— liikmesriigid võivad otsustada, et nad ei kontrolli mitte kunagi avaldatud tühistamisi, vaid tuginevad pelgalt sellistele DSCde loeteludele, mille nad iga päev sekretariaadilt saavad või ise koostavad.

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







Liik Atribuut Räsiarvutus SIGNATURE DCC allkiri DCC allkirja SHA256 UCI UCI (tõendi kordumatu tunnus) UCI SHA256 COUNTRYCODEUCI Väljaandva riigi kood + tõendi kordumatu tunnus Väljaandva riigi kood + tõendi kordumatu tunnuse SHA256

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

{

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

}

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:







Väli Määratlus more Boole’i lipp, mis näitab, et pakke on veel batches Olemasolevaid pakke sisaldav massiiv batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Standardi ISO 3166 kohane riigikood date Standardi ISO 8601 kohane kuupäev (koordineeritud maailmaaeg) Paki lisamise või kustutamise kuupäev deleted Boole’i funktsioon. Kustutatud oleku puhul „true“. Juhul kui lisatud on lipp „kustutatud“, võidakse kanne 7 päeva hiljem päringutabamuste hulgast viimaks eemaldada.

9.5.1.2.1.1. Vastusekoodid







Kood Kirjeldus 200 Kõik on korras 204 Sisu puudub, kui ei leita vastet päisele „If-Modified-Since“.

Päringu päis







Päis Kohustuslik Kirjeldus If-Modified-Since Jah Selleks et saada ainult kõige uuemad tulemused, sisaldab see päis viimast allalaaditud kuupäeva. Algse kutse päis tuleks seadistada väärtusele ‘2021-06-01T00:00:00Z’

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

{

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

}

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







Väli Kohustuslik Liik Määratlus expires Jah String Kuupäev, mil üksuse võib eemaldada. Standardi ISO 8601 kohane kuupäev/kellaaeg (koordineeritud maailmaaeg) country Jah String Standardi ISO 3166 kohane riigikood hashType Jah String Esitatud kannete räsi liik (vt „Räsi liigid“) entries Jah JSON Object Array Vt tabel „Kanded“ kid Jah String DCC allkirjastamiseks kasutatud DSC Base64 vormingus kodeeritud KID. Kui KID ei ole teada, võib kasutada stringi 'UNKNOWN_KID' (ilma '). Märkused.

— Pakid rühmitatakse aegumistähtaja ja DSC järgi: kõik üksused aeguvad samal ajal ja need on allkirjastatud sama võtmega.

— Aegumisaeg on koordineeritud maailmaaja vormingus kuupäev/kellaaeg, kuna EU-DCC on üleilmne süsteem ja meil tuleb kasutada üheti mõistetavat ajanäitu.

— Alaliselt tühistatud DCC aegumiskuupäevaks määratakse selle DSC aegumiskuupäev, mida kasutati DCC allkirjastamiseks, või tühistatud DCC aegumiskuupäev (sel juhul käsitatakse kasutatud NumericDate/epoch aegu koordineeritud maailmaaja ajavööndisse kuuluvatena).

— Riiklik tagateenistus eemaldab üksused oma tühistusloendist aegumise kuupäeva saabudes.

— Riiklik tagateenistus võib üksused oma tühistusloendist eemaldada juhul, kui DCC allkirjastamiseks kasutatud kid tühistatakse.

9.5.1.2.2.1. Kanded







Väli Kohustuslik Liik Määratlus hash Jah String SHA256 räsi esimesed 128 bitti, mis on kodeeritud Base64 stringidena

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







Kood Kirjeldus 200 Kõik on korras 410 Pakki ei ole enam. Riiklik tagateenistus võib paki kustutada

9.5.1.2.2.3. Vastuse päised







Päis Kirjeldus ETag Paki identifikaator

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:

{

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

}

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:

{

‘batchId’: ‘...’

}

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:

{

‘batchId’: ‘...’

}

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:

RevocationListReader

RevocationUploader

RevocationDeleter

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.

Kuna mõned käesoleva lisaga ette nähtud koodisüsteemidel põhinevad väärtuste kogumid (näiteks need, mida kasutatakse vaktsiinide ja antigeeni kiirtestide 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:







Kood Kuva Koodisüsteemi nimi Koodisüsteemi URL Koodisüsteemi objektiidentifikaator (OID) Koodisüsteemi versioon 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

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

— liidu ravimiregister – ELis kehtivat müügiluba omavad vaktsiinid (loa number);

— üleilmne vaktsiinide register, mille võib luua Maailma Terviseorganisatsioon;

— muudel juhtudel vaktsineerimiseks kasutatud ravimi nimetus. Kui nimetus sisaldab tühikuid, asendatakse need sidekriipsudega (-).

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:

— vaktsiini COVID-19 Vaccine Moderna Intramuscular Injection, mis on vaktsiini Spikevax nimi Jaapanis, tähistatakse koodiga EU/1/20/1507, mis vastab kõnealuse vaktsiini nimele ELis.

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

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

Eelistatud koodisüsteem:

— Euroopa Ravimiameti antud organisatsiooni kood (ISO ravimite identifitseerimise standardite kohane süsteem SPOR);

— üleilmne vaktsiinide müügiloa hoidjate või tootjate register, mille võib luua Maailma Terviseorganisatsioon;

— muudel juhtudel organisatsiooni nimi. Kui nimetus sisaldab tühikuid, asendatakse need sidekriipsudega (-).

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:

— organisatsiooni Pfizer AG, kes on Šveitsis kasutatava vaktsiini Comirnaty müügiloa hoidja, tähistatakse koodiga ORG-100030215, mis vastab organisatsioonile BioNTech Manufacturing GmbH, kes on Comirnaty müügiloa hoidja ELis.

— Organisatsiooni Zuellig Pharma, kes on Filipiinidel kasutatava COVID-19 vaktsiini Moderna (Spikevax) ravimi müügiloa hoidja, tähistatakse koodiga ORG-100031184, mis vastab organisatsioonile Moderna Biotech Spain S.L., kes on Comirnaty müügiloa hoidja ELis.

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

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

Kasutatakse tõendi nr 1 puhul.

Kaks välja:

1) järjekorranumber COVID-19 vaktsiini dooside seerias (N);

2) dooside koguarv vaktsineerimisseerias (C).

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:

— 1/1 näitab, et läbitud on esmane ühedoosilise vaktsiini kuur või et läbitud on esmane kuur, mis seisneb ühe kahedoosilise vaktsiini doosi manustamises läbipõdenud isikule kooskõlas liikmesriigi kohaldatava vaktsineerimiskavaga;

— 2/2 näitab, et läbitud on esmane kahedoosilise vaktsiini kuur.

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:

— 2/1 näitab, et pärast ühedoosilise esmase vaktsineerimiskuuri läbimist on manustatud tõhustusdoos või et pärast seda, kui läbitud on esmane kuur, mis seisnes ühe kahedoosilise vaktsiini doosi manustamises läbipõdenud isikule kooskõlas liikmesriigi kohaldatava vaktsineerimiskavaga, on manustatud tõhustusdoos. Pärast esimest tõhustusdoosi manustatud doose (X) väljendatakse valemiga (2+X)/(1) > 1 (näiteks 3/1);

— 3/3 näitab, et pärast kahedoosilise esmase vaktsineerimiskuuri läbimist on manustatud tõhustusdoos. Pärast esimest tõhustusdoosi manustatud doose (X) väljendatakse valemiga (3+X)/(3+X) = 1 (näiteks 4/4).

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:







Kood Kuva Koodisüsteemi nimi Koodisüsteemi URL Koodisüsteemi objektiidentifikaator (OID) Koodisüsteemi versioon LP6464-4 Molekulaarne nukleiinhappe amplifikatsioonil põhinev test LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Immuunkromatograafiline kiirtest LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

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

Kasutatakse tõendi nr 2 puhul.

Väärtuste kogumi sisu hõlmab antigeeni kiirtestide valikut, mis on loetletud COVID-19 antigeeni kiirtestide 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.

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:







Kood Kuva Koodisüsteemi nimi Koodisüsteemi URL Koodisüsteemi objektiidentifikaator (OID) Koodisüsteemi versioon 260415000 Ei tuvastatud SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Tuvastati SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

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

— Modulaarsus: millisel määral koosneb kood eri moodulitest, mis sisaldavad semantiliselt erinevat teavet;

— inimesepoolne tõlgendatavus: millisel määral kood on seda lugeva inimese jaoks mõistetav või tema poolt tõlgendatav;

— üleilmselt kordumatu; riigi või asutuse tunnust hallatakse hoolikalt; igalt riigilt (asutuselt) oodatakse, et ta haldab nimeruumi talle kuuluvat segmenti hoolikalt, see tähendab ei taaskasuta tunnuseid ega väljasta neid uuesti. Selline kombinatsioon tagab, et iga tunnus on ainuke omataoline maailmas.

▼M1

3. Üldnõuded

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

1) Märgistik: lubatud on ainult US-ASCII kohased suured tärgid (A–Z, 0–9); eraldamiseks võidakse kasutada dokumendi RFC3986 ( 14 ) kohaseid täiendavaid erimärke („/“, „#“, „:“).

2) Maksimumpikkus: projekteerijad peavad seadma eesmärgiks pikkuse 27–30 märki ( 15 ) .

3) Versiooni eesliide: näitab tõendi kordumatu tunnuse skeemi versiooni. Dokumendi käesoleva versiooni eesliide on „01“; eesliide koosneb kahest numbrist.

4) Riigi eesliide: riigikoodid on esitatud standardis ISO 3166-1. Pikemad koodid (st kolm märki ja rohkem, nagu näiteks „UNHCR“) jäetakse kasutamiseks tulevikus.

5) Koodi järelliide / kontrollsumma. 5.1 Liikmesriigid võivad kasutada kontrollsummat juhul, kui on tõenäoline, et tunnus edastatakse, kirjutatakse ümber (inimese poolt) või see muul viisil laostub (st juhul kui seda kasutatakse väljatrüki kujul). 5.2 Kontrollsummat ei kasutata tõendi valideerimiseks ja see ei ole tehniliselt tunnuse osa, vaid seda kasutatakse koodi tervikluse kontrolliks. Kontrollsumma peab olema standardi ISO-7812-1 (LUHN–10) ( 16 ) kohane kogu tõendi kordumatu tunnuse digitaalses/sidevahendi kaudu edastatavas vormingus kokkuvõte. Kontrollsumma on tõendi kordumatu tunnuse ülejäänud osast eraldatud märgiga „#“.

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.







Termin Määratlus Sertifikaat Teise nimega digitaalsertifikaat. X.509 v3 sertifikaat, mis sisaldab avaliku üksuse avalikku võtit CSCA Riiklik allkirjastamise sertimiskeskus DCC ELi digitaalne COVID-tõend Allkirjastatud digitaalne dokument, mis sisaldab teavet vaktsineerimise, testimise või läbipõdemise kohta DCCG ELi digitaalse COVID-tõendi lüüs. Süsteem, mida kasutatakse DSCde vahetamiseks liikmesriikide vahel DCCGTA DCCG ankurvõtme sertifikaat. Sellele vastavat privaatvõtit kasutatakse kõigi CSCA-sertifikaatide allkirjastamiseks vallasrežiimis DCCGTLS DCCG TLSi serveri sertifikaat DSC Dokumendi allkirjastaja sertifikaat. Digitaalsertifikaat, mis kuulub liikmesriigi dokumentide allkirjastajale (näiteks süsteemile, millel on luba DCCsid allkirjastada). Selle sertifikaadi väljastab liikmesriigi CSCA EC-DSA Elliptiliste kõverate digiallkirja algoritm. Elliptilistel kõveratel põhinev krüptoalgoritm allkirjastamiseks Liikmesriik ELi liikmesriik mTLS Vastastikune TLS. Transpordikihi turbeprotokoll, mis kasutab vastastikust autentimist NB Liikmesriigi tagateenistus NBCSCA Liikmesriigi CSCA-sertifikaat (võib olla rohkem kui üks) NBTLS Riikliku tagateenistuse TLS-kliendi autentimissertifikaat NBUP Sertifikaat, mida riiklik tagateenistus kasutab DCCGsse üleslaaditavate andmepakettide allkirjastamiseks PKI Avaliku võtme taristu. Digitaalsertifikaatidele ja sertimiskeskustele tuginev usaldusmudel RSA Asümmeetriline krüptoalgoritm, mis põhineb täisarvu tegurdusel ja mida kasutatakse digiallkirjadeks või asümmeetrilises krüptograafias

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:

— CSCA ei väljasta sertifikaate, mille kehtivusaeg on pikem kui sertimiskeskuse enese sertifikaat;

— dokumentide allkirjastaja ei allkirjasta dokumente, mille kehtivusaeg on pikem kui DSC enda oma;

— omaenese CSCAd käitavad liikmesriigid peavad kindlaks määrama oma CSCA ja kõigi väljastatud tõendite kehtivusaja ning kandma hoolt sertifikaatide uuendamise eest.

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.

— DCCG kasutab vastastikust TLS-autentimist, et luua NBdega autenditud ja krüpteeritud ühendus. Seega peab DCCG registreeritud NB TLS kliendisertifikaatide valget nimekirja;

— DCCG kasutab kaht elektroonilist sertifikaati (DCCG TLS ja DCCG TA ), millel on kaks eri võtmepaari. DCCG TA võtmepaari privaatvõtit hoitakse vallaskeskkonnas (mitte DCCG siduselementides);

— DCCG peab NB CSCA -sertifikaatide usaldusloetelu, mis on allkirjastatud DCCG TA privaatvõtmega;

— kasutatavad šifrid peavad vastama punkti 5.1 nõuetele.

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:

— liikmesriigi TLS-sertifikaat NB TLS ;

— liikmesriigi üleslaadimissertifikaat NB UP ;

— liikmesriigi CSCA-sertifikaat/sertifikaadid NB CSCA .

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.

— Lisab NB CSCA sertifikaadi(d) usaldusloetellu, mis on allkirjastatud privaatvõtmega, mis vastab DCCG TA avalikule võtmele;

— lisab NB TLS sertifikaadi DCCG TLS otspunktide valgesse nimekirja;

— lisab NB UP sertifikaadi DCCG süsteemi;

— annab liikmesriigi käsutusse DCCG TA ja DCCG TLS digitaalsertifikaadi.

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:

— CSCA: 4 aastat;

— DSC: 2 aastat;

— üleslaadimine: 1–2 aastat;

— TLS-kliendi autentimine: 1–2 aastat.

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

— CSCA: 1 aasta;

— DSC: 6 kuud.

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







Allkirja algoritm Võtme pikkus Räsifunktsioon EC-DSA Vähemalt 250 bitti SHA-2, mille väljund on ≥ 256 bitti RSA-PSS (soovituslik täidis) RSA-PKCS#1 v1.5 (pärandtäidis) Vähemalt 3000 bitine RSA-moodul (N), mille avalik eksponent e > 2^16 SHA-2, mille väljund on ≥ 256 bitti DSA Vähemalt 3000 bitti algarv p, 250 bitti võti q SHA-2, mille väljund on ≥ 256 bitti

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.







Väli Väärtus Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<CSCAd käitav liikmesriik> Võtme kasutamise eesmärk Sertifikaatide allkirjastamine, tühistatud sertifikaatide loendi allkirjastamine (miinimum) Põhipiirangud CA = true, raja pikkuse piirang = 0

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.







Väli Väärtus Sarjanumber Kordumatu sarjanumber Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<asjaomast DSCd kasutav liikmesriik> Võtme kasutamise eesmärk Digiallkiri (miinimum)

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

Kasutada tuleb järgmisi laiendeid:

— sertifikaat peab sisaldama asutuse võtme identifikaatorit, mis vastab väljastava CSCA-sertifikaadi subjekti võtme identifikaatorile;

— sertifikaat peaks sisaldama kordumatut subjekti võtme identifikaatorit (kooskõlas dokumendiga RFC 5280) ( 21 ).

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.







Väli Väärtus extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 testimistõendite väljastajatele extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 vaktsineerimistõendite väljastajatele extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 paranemistõendite väljastajatele

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.







Väli Väärtus Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<asjaomast üleslaadimissertifikaati kasutav liikmesriik> Võtme kasutamise eesmärk Digiallkiri (miinimum)

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.







Väli Väärtus Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<NB liikmesriik> Võtme kasutamise eesmärk Digiallkiri (miinimum) Võtmekasutuslaiend Kliendi autentimine ( 1.3.6.1.5.5.7.3.2)

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.







Väli Väärtus Subjekt cn = Rohelise digitõendi lüüs, (1) o=<pakkuja>, c=<riik> Võtme kasutamise eesmärk Digiallkiri (miinimum) ( 1 ) Käesolevas kontekstis on jätkatud termini „roheline digitõend“ kasutamist termini „ELi digitaalne COVID-tõend“ asemel, kuna see on termin, mis on tõendisse püsikodeeritud ja selles kasutusele võetud enne, kui kaasseadusandjad otsustasid kasutada uut terminit.

5.7. DCCG TLS serveri sertifikaadid (DCCGTLS)

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







Väli Väärtus Subjekt cn=<DCCG täisdomeeninimi või IP-aadress>, o=<pakkuja>, c= <riik> SubjectAltName dNSName: <DCCG DNS-nimi> või iPAddress: <DCCG IP-aadress> Võtme kasutamise eesmärk Digiallkiri (miinimum) Võtmekasutuslaiend Serveri autentimine ( 1.3.6.1.5.5.7.3.1)

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.







Välja tunnus Välja nimi Juhised ver Skeemi versioon Vastab ELi DCC genereerimiseks kasutatud skeemiversiooni tunnusele. Näide: „ver“:„1.3.0“

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.







Välja tunnus Välja nimi Juhised nam/fn Perekonnanimi/perekonnanimed Omaja perekonnanimi/perekonnanimed Kui omajal ei ole perekonnanimesid ja on eesnimi, jäetakse see väli vahele. Kõigil muudel juhtudel esitatakse täpselt 1 (üks) väli, mis ei ole tühi ja millele on märgitud kõik perekonnanimed. Mitme perekonnanime korral eraldatakse need üksteisest tühikutega. Siiski peavad samaks jääma sidekriipse või muid sarnaseid märke sisaldavad liitnimed. Näited: „fn“:„Musterfrau-Gößinger“ „fn“:„Musterfrau-Gößinger Müller“ nam/fnt Standarditud perekonnanimi/perekonnanimed Omaja perekonnanimi/perekonnanimed, mis on translitereeritud vastavalt süsteemile, mida on kasutatud omaja masinloetavate reisidokumentide puhul (näiteks ICAO dokumendi 9303 osas 3 esitatud reeglid). Kui omajal ei ole perekonnanimesid ja on eesnimi, jäetakse see väli vahele. Kõigil muudel juhtudel esitatakse täpselt 1 (üks) väli, mis ei ole tühi ja millel on kasutatud ainult märke A-Z ja <. Maksimumpikkus: 80 tähemärki (vastavalt ICAO spetsifikatsioonile nr 9303). Näited: „fnt“:„MUSTERFRAU<GOESSINGER“ „fnt“:„MUSTERFRAU<GOESSINGER<MUELLER“ nam/gn Eesnimi/eesnimed Omaja eesnimi/eesnimed. Kui omajal ei ole eesnimesid ja on perekonnanimi, jäetakse see väli vahele. Kõigil muudel juhtudel esitatakse täpselt 1 (üks) väli, mis ei ole tühi ja millele on märgitud kõik eesnimed. Mitme eesnime korral eraldatakse need üksteisest tühikutega. Näide: „gn“:„Isolde Erika“ nam/gnt Standarditud eesnimi/eesnimed Omaja eesnimi/eesnimed, mis on translitereeritud vastavalt süsteemile, mida on kasutatud omaja masinloetavate reisidokumentide puhul (näiteks ICAO dokumendi 9303 osas 3 esitatud reeglid). Kui omajal ei ole eesnimesid ja on perekonnanimi, jäetakse see väli vahele. Kõigil muudel juhtudel esitatakse täpselt 1 (üks) väli, mis ei ole tühi ja millel on kasutatud ainult märke A-Z ja <. Maksimumpikkus: 80 tähemärki. Näide: „gnt“:„ISOLDE<ERIKA“ dob Sünniaeg DCC omaja sünniaeg. Täielik või osaline kuupäev (kellaajata), mis jääb vahemikku 1900-01–01 kuni 2099-12–31. Kui täielik või osaline sünniaeg on teada, esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Kui teada ei ole isegi osalist sünniaega, märgitakse väljale tühi string „“. See peaks kokku langema teabega, nagu see on esitatud reisidokumentidel. Kui teave sünniaja kohta on olemas, kasutatakse üht järgmistest ISO 8601 vormingutest. Muid variante ei toetata. AAAA-KK-PP AAAA-KK AAAA (Kontrollimisrakendus võib kuvada sünniaja puuduvaid osi, kasutades XX süsteemi nagu see, mida kasutatakse masinloetavate reisidokumentide puhul, näiteks 1990-XX-XX.) Näited: „dob“:„1979-04–14“ „dob“:„1901-08“ „dob“:„1939“ „dob“:„“

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.







Rühma tunnus Rühma nimi Kanded v Vaktsineerimisrühm Selle olemasolul sisaldab täpselt 1 (üht) kannet, mis kirjeldab täpselt 1 (üht) vaktsiinidoosi (üht doosi). t Testimisrühm Selle olemasolul sisaldab täpselt 1 (üht) kannet, mis kirjeldab täpselt 1 (üht) testitulemust. r Läbipõdemisrühm Selle olemasolul sisaldab täpselt 1 (üht) kannet, mis kirjeldab 1 (üht) läbipõdemiskinnitust.

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







Välja ID Andmevälja nimi Juhised v/tg Asjaomane haigus või haigustekitaja: COVID-19 (SARS-CoV-2 või üks selle variantidest) Kodeeritud väärtus väärtuste kogumist disease-agent-targeted.json. Selles väärtuste kogumis on üks kanne 840539006, mis on COVID-19 kood SNOMED CT (GPS) järgi. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "tg":"840539006" v/vp COVID-19 vaktsiin või profülaktika Kasutatud vaktsiin või profülaktika Kodeeritud väärtus väärtuste kogumist vaccine-prophylaxis.json. Väärtuste kogumit jagatakse ELi DCC lüüsi kaudu. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "vp":"1119349007"(SARS-CoV-2 mRNA vaktsiin) v/mp COVID-19 vaktsiin Ravim, mida on kasutatud selle konkreetse vaktsiinidoosi jaoks. Kodeeritud väärtus väärtuste kogumist vaccine-medicinal-product.json. Väärtuste kogumit jagatakse ELi DCC lüüsi kaudu. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "mp":"EU/1/20/1528" (Comirnaty) v/ma COVID-19 vaktsiini müügiloa hoidja või tootja Müügiloa hoidja või tootja, kui müügiloa hoidja puudub. Kodeeritud väärtus väärtuste kogumist vaccine-mah-manf.json. Väärtuste kogumit jagatakse ELi DCC lüüsi kaudu. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "ma":"ORG-100030215"(Biontech Manufacturing GmbH) v/dn Doosi number seerias Asjaomase vaktsineerimise käigus manustatud doosi järjekorranumber (positiivne täisarv). 1 näitab esimest doosi, 2 teist doosi jne. Täpsemad nõuded on esitatud II lisa punktis 5. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näited: "dn":"1"(esimene doos) "dn":"2"(teine doos) "dn":"3"(kolmas doos) v/sd Dooside koguarv seerias Dooside koguarv (positiivne täisarv) vaktsineerimisseerias. Täpsemad nõuded on esitatud II lisa punktis 5. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näited: "sd":"1"(ühedoosilise esmase vaktsineerimise kuuri korral) "sd":"2"(kahedoosilise esmase vaktsineerimisseeria korral või juhul kui ühedoosilisele esmase vaktsineerimise kuurile on järgnenud lisadoos) "sd":"3"(näiteks kui kahedoosilise esmase vaktsineerimise kuurile on järgnenud lisadoosid) v/dt Vaktsineerimise kuupäev Kirjeldatud doosi saamise kuupäev vormingus AAAA-KK-PP (kuupäev täiskujul kellaajata). Muid vorminguid ei ole toetata. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "dt":"2021-03-28" v/co Liikmesriik või kolmas riik, kus vaktsiin manustati Riik, mis on väljendatud kahetähelise ISO3166-koodiga (SOOVITATAV), või viide rahvusvahelisele organisatsioonile (nagu UNHCR või WHO), kes vastutab vaktsineerimise eest. Kodeeritud väärtus väärtuste kogumist country-2-codes.json. Väärtuste kogumit jagatakse ELi DCC lüüsi kaudu. Esitatakse täpselt 1 (üks) väli. Näide: "co":"CZ" "co":"UNHCR" v/is Tõendi väljastaja Tõendi väljastanud organisatsiooni nimi. Tunnused on lubatud nime osana, kuid ei ole soovitatav kasutada neid eraldi (ilma nimeta) tekstina. Kõige rohkem 80 UTF-8 märki. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "is":"Tšehhi Vabariigi tervishoiuministeerium" "is":"Vaktsineerimiskeskus: 3. lõunapiirkond" v/ci Tõendi kordumatu tunnus Tõendi kordumatu tunnus vastavalt dokumendile https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf Kontrollsumma lisamine ei ole kohustuslik. Lisada võidakse eesliide "URN:UVCI:". Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näited: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2. Testimistõend

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







Välja ID Andmevälja nimi Juhised t/tg Asjaomane haigus või haigustekitaja: COVID-19 (SARS-CoV-2 või üks selle variantidest) Kodeeritud väärtus väärtuste kogumist disease-agent-targeted.json. Selles väärtuste kogumis on üks kanne 840539006, mis on COVID-19 kood SNOMED CT (GPS) järgi. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "tg":"840539006" t/tt Testi liik Kasutatud testi liik, vastavalt testiga uuritavale materjalile. Kodeeritud väärtus väärtuste kogumist test-type.json (vastavalt süsteemile LOINC). Lubatud ei ole väärtused, mis ei kuulu väärtuste kogumisse. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "tt":"LP6464-4" (molekulaarne nukleiinhappe amplifikatsioonil põhinev test) "tt":"LP217198-3" (immuunkromatograafiline kiirtest) t/nm Testi nimi (ainult nukleiinhappe amplifitseerimise test) Kasutatud nukleiinhappe amplifitseerimise testi nimi. Nimi peaks sisaldama testi tootja nime ja testi kaubanduslikku nimetust, mis on komaga eraldatud. Nukleiinhappe amplifitseerimise test: välja täitmine ei ole kohustuslik. Immuunkromatograafiline kiirtest: välja ei kasutata, kuna testi nimi on kaudselt esitatud testimisseadme tunnusega (t/ma). Esitamise korral ei tohi väli olla tühi. Näide: "nm":"ELITechGroup, SARS-CoV-2 ELITe MGB® Kit" t/ma Testimisseadmed tunnus (ainult antigeeni kiirtestid) Antigeeni kiirtesti seadme tunnus Teadusuuringute Ühiskeskuse andmebaasis. Väärtuste kogum (terviseohutuse komitee ühine loetelu): — kõik terviseohutuse komitee ühisesse loetellu kuuluvad antigeeni kiirtestid (inimloetav). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (masinloetav, loetelu sisaldab väärtuste kogumist pärinevaid välja id_device väärtusi). ELi/EMP riikides väljastavad väljastajad tõendeid ainult selliste testide kohta, mis kuuluvad väljastamisajal kehtivasse väärtuste kogumisse. Väärtuste kogumit uuendatakse iga 24 tunni järel. Väärtusi, mis ei kuulu väärtuste kogumisse, võib kasutada kolmandate riikide väljastatud tõendites, kuid tunnused peavad sellest hoolimata pärinema Teadusuuringute Ühiskeskuse andmebaasist. Lubatud ei ole kasutada muid kui otse testide valmistajate esitatud tunnuseid. Kontrollimisrakendused teevad kindlaks väärtused, mis ei kuulu ajakohastatud väärtuste kogumisse, ja näitavad neid sisaldavaid tõendeid kehtetutena. Kui tunnus väärtuste kogumist kustutatakse, võidakse seda sisaldavaid tõendeid aktsepteerida kõige enam 72 tunni jooksul pärast kustutamiskuupäeva. Väärtuste kogumit jagatakse ELi DCC lüüsi kaudu. Immuunkromatograafiline kiirtest: esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Nukleiinhappe amplifitseerimise test: välja ei kasutata, isegi kui nukleiinhappe amplifitseerimise testi tunnus on Teadusuuringute Ühiskeskuse andmebaasis olemas. Näide: "ma":"344"(SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc Testi jaoks proovi võtmise kuupäev ja kellaaeg Kuupäev ja kellaaeg, kui võeti proov testi jaoks. Kellaaeg sisaldab teavet ajavööndi kohta. Väärtus ei märgi aega, kui testitulemus genereeriti. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Kasutatakse ainult üht järgmistest ISO 8601 vormingutest. Muid variante ei toetata. AAAA-KK-PPThh:mm:ssZ AAA-KK-PPThh:mm:ss[+-]hh AAA-KK-PPThh:mm:ss[+-]hhmm AAAA-KK-PPThh:mm:ss[+-]hh:mm Näited: "sc":"2021-08-20T10:03:12Z"(UTC aeg) "sc":"2021-08-20T12:03:12+02"(Kesk-Euroopa suveaeg) "sc":"2021-08-20T12:03:12+0200"(Kesk-Euroopa suveaeg) "sc":"2021-08-20T12:03:12+02:00"(Kesk-Euroopa suveaeg) t/tr Testitulemus Testi tulemus. Kodeeritud väärtus väärtuste kogumist test-result.json (SNOMED CT, GPS alusel). Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "tr":"260415000"(Ei tuvastatud) t/tc Testimiskeskus või -asutus Testi teinud asutuse nimi. Tunnused on lubatud nime osana, kuid ei ole soovitatav kasutada neid eraldi (ilma nimeta) tekstina. Kõige rohkem 80 UTF-8 märki. Kõik lisamärgid võidakse kärpida. Nimi ei ole ette nähtud automaatseks kontrolliks. Nukleiinhappe amplifitseerimise testid: esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Antigeeni kiirtestid: välja täitmine ei ole kohustuslik. Esitamise korral ei ole tühi. Näide: "tc":"Testimiskeskus: läänepiirkond 245" t/co Liikmesriik või kolmas riik, kus test tehti Riik, mis on väljendatud kahetähelise ISO3166-koodiga (SOOVITATAV), või viide rahvusvahelisele organisatsioonile (nagu UNHCR või WHO), kes vastutab testi tegemise eest. Kodeeritud väärtus väärtuste kogumist country-2-codes.json. Väärtuste kogumit jagatakse ELi DCC lüüsi kaudu. Esitatakse täpselt 1 (üks) väli. Näited: "co":"CZ" "co":"UNHCR" t/is Tõendi väljastaja Tõendi väljastanud organisatsiooni nimi. Tunnused on lubatud nime osana, kuid ei ole soovitatav kasutada neid eraldi (ilma nimeta) tekstina. Kõige rohkem 80 UTF-8 märki. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näited: "is":"Tšehhi Vabariigi tervishoiuministeerium" "is":"Loodepiirkonna tervishoiuvalitsus" t/ci Tõendi kordumatu tunnus Tõendi kordumatu tunnus vastavalt dokumendile vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Kontrollsumma lisamine ei ole kohustuslik. Lisada võidakse eesliide "URN:UVCI:". Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näited: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

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.







Välja ID Andmevälja nimi Juhised r/tg Haigus või haigustekitaja, mille tõendi omaja on läbi põdenud: COVID-19 (SARS-CoV-2 või üks selle variantidest) Kodeeritud väärtus väärtuste kogumist disease-agent-targeted.json. Selles väärtuste kogumis on üks kanne 840539006, mis on COVID-19 kood SNOMED CT (GPS) järgi. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "tg":"840539006" r/fr Tõendi omajale esimese positiivse tulemuse andnud nukleiinhappe amplifitseerimise testi kuupäev Kuupäev, kui võeti proov selle nukleiinhappe amplifitseerimise testi jaoks, mille tulemus oli positiivne, vormingus AAAA-KK-PP (täielik kuupäev kellaajata). Muid vorminguid ei ole toetata. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "fr":"2021-05-18" r/co Liikmesriik või kolmas riik, kus test tehti Riik, mis on väljendatud kahetähelise ISO3166-koodiga (SOOVITATAV), või viide rahvusvahelisele organisatsioonile (nagu UNHCR või WHO), kes vastutab testi tegemise eest. Kodeeritud väärtus väärtuste kogumist country-2-codes.json. Väärtuste kogumit jagatakse ELi DCC lüüsi kaudu. Esitatakse täpselt 1 (üks) väli. Näited: "co":"CZ" "co":"UNHCR" r/is Tõendi väljastaja Tõendi väljastanud organisatsiooni nimi. Tunnused on lubatud nime osana, kuid ei ole soovitatav kasutada neid eraldi (ilma nimeta) tekstina. Kõige rohkem 80 UTF-8 märki. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "is":"Tšehhi Vabariigi tervishoiuministeerium" "is":"Ülikooli keskhaigla" r/df Tõend kehtiv alates Esimene kuupäev, kui tõend loetakse kehtivaks. Kuupäev ei ole varasem kui kuupäev, mis arvutatakse järgmiselt: r/fr + 11 päeva. Kuupäev esitatakse vormingus AAAA-KK-PP (kuupäev täiskujul kellaajata). Muid vorminguid ei ole toetata. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "df":"2021-05-29" r/du Tõend kehtiv kuni Viimane kuupäev, kui tõend loetakse kehtivaks, mille määrab tõendi väljastaja. Kuupäev ei ole hilisem kui kuupäev, mis arvutatakse järgmiselt: r/fr + 180 päeva. Kuupäev esitatakse vormingus AAAA-KK-PP (kuupäev täiskujul kellaajata). Muid vorminguid ei ole toetata. Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näide: "du":"2021-11-14" r/ci Tõendi kordumatu tunnus Tõendi kordumatu tunnus vastavalt dokumendile vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Kontrollsumma lisamine ei ole kohustuslik. Lisada võidakse eesliide "URN:UVCI:". Esitatakse täpselt 1 (üks) väli, mis ei ole tühi. Näited: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

▼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

1) Kaasvastutavad töötlejad töötlevad isikuandmeid usaldusraamistiku lüüsi kaudu vastavalt I lisas esitatud tehnilisele spetsifikatsioonile.

2) Liikmesriikide väljaandvad asutused on väljaspool lüüsi toimuva tühistamist puudutava teabe kogumise, kasutamise, avalikustamise ja igasuguse muu töötlemise, muu hulgas tõendite tühistamiseni viiva menetluse puhul ainuisikuliselt vastutavad töötlejad.

3) Iga vastutav töötleja vastutab isikuandmete töötlemise eest usaldusraamistiku lüüsis kooskõlas isikuandmete kaitse üldmääruse artiklitega 5, 24 ja 26.

4) Iga vastutav töötleja loob üldpostkastiga varustatud kontaktpunkti, mida kasutatakse teabe vahetamiseks nii kaasvastutavate töötlejate vahel kui ka kaasvastutavate töötlejate ja volitatud töötleja vahel.

5) Määruse (EL) 2021/953 artiklis 14 osutatud komitee loodud töörühmale tehakse ülesandeks otsustada kõikide küsimuste üle, mis tulenevad tühistusloendite vahetamisest ja kaasvastutusest sellega seonduval isikuandmete töötlemisel, ning hõlbustada kooskõlastatud juhiste andmist komisjonile kui volitatud töötlejale. Kaasvastutavate töötlejate otsustusprotsess allub nimetatud töörühmale ja tema poolt vastu võetud töökorrale. Kui mõni kaasvastutav töötleja ei osale kõnealuse töörühma koosolekul, millest on teatatud vähemalt seitse (7) päeva enne selle kokkukutsumist kirjalikult, tähendab see vaikimisi nõustumist töörühma selle koosoleku tulemustega. Töörühma koosoleku võib kokku kutsuda iga kaasvastutav töötleja.

6) Juhiseid volitatud töötlejale tuleb saata kaasvastutavate töötlejate kontaktpunktide kaudu kokkuleppel teiste kaasvastutavate töötlejatega, vastavalt punktis 5 kirjeldatud töörühma otsustusprotsessile. Juhiseid andev kaasvastutav töötleja esitab need volitatud töötlejale kirjalikult ja teatab sellest kõigile teistele kaasvastutavatele töötlejatele. Kui arutlusel olev küsimus on nii kiireloomuline, et punktis 5 osutatud töörühma kokkukutsumist ei ole võimalik korraldada, võib siiski anda juhise, kuid töörühm võib selle tühistada. See juhis tuleks anda kirjalikult ning kõigile teistele kaasvastutavatele töötlejatele tuleks sellest juhise andmise ajal teatada.

7) Punkti 5 kohaselt loodud töörühm ei välista kaasvastutavate töötlejate individuaalset pädevust teavitada oma pädevat järelevalveasutust kooskõlas isikuandmete kaitse üldmääruse artikliga 33 ja 24. Kõnealuseks teavitamiseks ei ole vaja ühegi teise kaasvastutava töötleja nõusolekut.

8) Usaldusraamistiku lüüsi raames võivad vahetatava teabega tutvuda ainult määratud riiklike asutuste või ametiasutuste poolt volitatud isikud.

9) Iga väljaandev asutus peab registrit oma vastutusalasse kuuluvate töötlemistoimingute kohta. Registrisse võib märkida kaasvastutuse.

2. alajagu

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

1) Oma väljaandva asutuse rolli täites esitab vastutav töötleja kooskõlas isikuandmete kaitse üldmääruse artikliga 14 füüsilistele isikutele, kelle tõendi(d) ta on tühistanud (edaspidi „andmesubjektid“), teabe, mis puudutab kõnealust tühistamist ja nende isikuandmete töötlemist ELi digitaalse COVID-tõendi lüüsis eesmärgiga võimaldada tühistusloendite vahetamist, välja arvatud juhul kui see osutub võimatuks või kui see nõuaks ebaproportsionaalseid jõupingutusi.

2) Vastutav töötleja tegutseb selliste füüsilisest isikute kontaktpunktina, kelle tõendi ta on tühistanud, ja menetleb taotlusi, mille on esitanud andmesubjektid või nende esindajad, kes kasutavad oma õigusi vastavalt isikuandmete kaitse üldmäärusele. Kui kaasvastutav töötleja saab andmesubjektilt taotluse, mis on seotud teise kaasvastutava töötleja välja antud tõendiga, teatab ta andmesubjektile asjaga tegeleva kaasvastutava töötleja nime ja tema kontaktandmed. Kui mõni kaasvastutav töötleja seda taotleb, abistavad teised kaasvastutavad töötlejad teda andmesubjektide taotluste käsitlemisel ning vastavad üksteisele põhjendamatu viivituseta ja hiljemalt 1 kuu jooksul alates abitaotluse saamisest. Juhul kui taotlus puudutab kolmanda riigi esitatud andmeid, menetleb taotluse saanud vastutav töötleja seda ning teatab andmesubjektile kolmanda riigi väljaandva asutuse nime ja kontaktandmed.

3) Vastutav töötleja teeb andmesubjektidele kättesaadavaks käesoleva lisa sisu, sealhulgas punktides 1 ja 2 sätestatud korra.

2. JAGU

Turvaintsidentide, sealhulgas isikuandmetega seotud rikkumiste haldamine

1) Kaasvastutavad töötlejad abistavad üksteist ELi digitaalse COVID-tõendi lüüsis töötlemisega seotud turvaintsidentide, sealhulgas isikuandmetega seotud rikkumiste kindlakstegemisel ja käsitlemisel.

2) Kaasvastutavad töötlejad teavitavad üksteist eelkõige järgmisest:

a) usaldusraamistiku lüüsis töödeldavate isikuandmete kättesaadavuse, konfidentsiaalsuse ja/või terviklusega seotud võimalikud või tegelikud ohud;

b) kõik isikuandmetega seotud rikkumised, isikuandmetega seotud rikkumise tõenäolised tagajärjed ja füüsiliste isikute õigusi ja vabadusi ähvardava ohu hindamine ning kõik meetmed, mis on võetud isikuandmetega seotud rikkumise käsitlemiseks ning füüsiliste isikute õigusi ja vabadusi ähvardava riski maandamiseks;

c) usaldusraamistiku lüüsi töötlemistoimingutega seotud tehniliste ja/või korralduslike kaitsemeetmete rikkumine.

3) Kaasvastutavad töötlejad teavitavad komisjoni, pädevaid järelevalveasutusi ja kui see on nõutav, andmesubjekte kooskõlas isikuandmete kaitse üldmääruse artiklitega 33 ja 34 kõigist isikuandmetega seotud rikkumistest, mis leiavad aset usaldusraamistiku lüüsi töötlemistoimingute käigus.

4) Väljaandvad asutused rakendavad asjakohaseid t