02021D1073 — HR — 25.04.2022 — 003.001

Ovaj je tekst namijenjen isključivo dokumentiranju i nema pravni učinak. Institucije Unije nisu odgovorne za njegov sadržaj. Vjerodostojne inačice relevantnih akata, uključujući njihove preambule, one su koje su objavljene u Službenom listu Europske unije i dostupne u EUR-Lexu. Tim službenim tekstovima može se izravno pristupiti putem poveznica sadržanih u ovom dokumentu.

►B PROVEDBENA ODLUKA KOMISIJE (EU) 2021/1073 оd 28. lipnja 2021. o utvrđivanju tehničkih specifikacija i pravila za uspostavljanje okvira povjerenja za EU digitalnu COVID potvrdu, uspostavljenu Uredbom (EU) 2021/953 Europskog parlamenta i Vijeća (Tekst značajan za EGP) ( L 230 30.6.2021, 32)

Koju je izmijenila:









▼B

PROVEDBENA ODLUKA KOMISIJE (EU) 2021/1073

оd 28. lipnja 2021.

o utvrđivanju tehničkih specifikacija i pravila za uspostavljanje okvira povjerenja za EU digitalnu COVID potvrdu, uspostavljenu Uredbom (EU) 2021/953 Europskog parlamenta i Vijeća

(Tekst značajan za EGP)







Članak 1.

U Prilogu I. utvrđene su tehničke specifikacije za EU digitalnu COVID potvrdu, u kojima se utvrđuju opća struktura podataka, mehanizmi kodiranja i mehanizam prijenosnog kodiranja u strojno čitljivom optičkom formatu.

Članak 2.

U Prilogu II. ovoj Odluci utvrđena su pravila za ispunjavanje potvrda iz članka 3. stavka 1. Uredbe (EU) 2021/953.

Članak 3.

U Prilogu III. utvrđeni su zahtjevi kojima se utvrđuje zajednička struktura jedinstvenog identifikatora potvrde.

▼M1

Članak 4.

U Prilogu IV. utvrđena su pravila upravljanja za certifikate javnih ključeva s obzirom na pristupnik za EU digitalnu COVID potvrdu kojima se podupiru aspekti interoperabilnosti.

▼M1

Članak 5.

Zajednička koordinirana struktura podataka za podatke koji se upisuju u potvrde iz članka 3. stavka 1. Uredbe (EU) 2021/953 utvrđuje se JSON (JavaScript Object Notation) shemom u Prilogu V. ovoj Odluci.

▼M3

Članak 5.a

Razmjena popisa opozvanih potvrda

1. Okvir povjerenja za EU digitalnu COVID potvrdu omogućuje razmjenu popisâ opozvanih potvrda putem središnjeg pristupnika za EU digitalnu COVID potvrdu („pristupnik”) u skladu s tehničkim specifikacijama iz Priloga I.

2. Ako država članica opozove EU digitalne COVID potvrde, popise opozvanih potvrda može poslati u pristupnik.

3. Ako države članice šalju popise opozvanih potvrda, izdavatelji vode popis opozvanih potvrda.

4. Ako se putem pristupnika razmjenjuju osobni podaci, obrada je ograničena na svrhu podupiranja razmjene informacija o opozivu. Takvi se osobni podaci upotrebljavaju samo za potrebe provjere statusa opoziva EU digitalnih COVID potvrda izdanih unutar područja primjene Uredbe (EU) 2021/953.

5. Informacije poslane u pristupnik sadržavaju sljedeće podatke u skladu s tehničkim specifikacijama iz Priloga I.: (a) pseudonimizirane jedinstvene identifikatore potvrde opozvanih potvrda; (b) datum isteka valjanosti poslanog popisa opozvanih potvrda.

6. Ako izdavatelj opozove EU digitalne COVID potvrde koje je izdalo na temelju Uredbe (EU) 2021/953 ili Uredbe (EU) 2021/954 i namjerava razmjenjivati relevantne informacije putem pristupnika, informacije iz stavka 5. može unijeti u pristupnik u obliku popisâ opozvanih potvrda u sigurnom formatu u skladu s tehničkim specifikacijama iz Priloga I.

7. Izdavatelji su u mjeri u kojoj je to moguće dužni uspostaviti rješenje za obavješćivanje nositelja opozvanih potvrda o statusu opoziva njihovih potvrda uz navođenje razloga opoziva u trenutku opoziva.

8. Pristupnik prikuplja primljene popise opozvanih potvrda. Pristupnik ima alate za distribuciju tih popisa državama članicama. Pristupnik automatski briše popise u skladu s datumima isteka valjanosti koje je za svaki poslani popis navelo tijelo koje ga je dostavilo.

9. Imenovana nacionalna tijela ili službena tijela država članica koja obrađuju osobne podatke u pristupniku su zajednički voditelji obrade podataka koji se obrađuju. Odgovornosti zajedničkih voditelja obrade dodjeljuju se u skladu s Prilogom VI.

10. Komisija je izvršitelj obrade osobnih podataka koji se obrađuju u pristupniku. U svojstvu izvršitelja obrade u ime država članica Komisija jamči sigurnost prijenosa i smještaja osobnih podataka u pristupniku te poštuje obveze izvršitelja obrade utvrđene u Prilogu VII.

11. Komisija i zajednički voditelji obrade redovito testiraju, ocjenjuju i evaluiraju djelotvornost tehničkih i organizacijskih mjera za sigurnost obrade osobnih podataka u pristupniku.

Članak 5.b

Dostavljanje popisa opozvanih potvrda iz trećih zemalja

Treće zemlje koje izdaju COVID-19 potvrde za koje je Komisija donijela provedbeni akt na temelju članka 3. stavka 10. ili članka 8. stavka 2. Uredbe (EU) 2021/953 mogu u skladu s tehničkim specifikacijama utvrđenima u Prilogu I. slati popise opozvanih COVID-19 potvrda obuhvaćenih takvim provedbenim aktom u pristupnik na obradu koju provodi Komisija u ime zajedničkih voditelja obrade iz članka 5.a.

Članak 5.c

Upravljanje obradom osobnih podataka u središnjem pristupniku za EU digitalnu COVID potvrdu

1. Postupkom donošenja odluka zajedničkih voditelja obrade upravlja radna skupina osnovana u okviru odbora iz članka 14. Uredbe (EU) 2021/953.

2. Imenovana nacionalna tijela ili službena tijela država članica koja obrađuju osobne podatke u pristupniku kao zajednički voditelji obrade imenuju predstavnike u tu skupinu.

▼M1

Članak 6.

Ova Odluka stupa na snagu na dan objave u Službenom listu Europske unije.

▼B

Ova Odluka stupa na snagu na dan objave u Službenom listu Europske unije.









PRILOG I.

FORMAT I UPRAVLJANJE POVJERENJEM

Opća struktura podataka, mehanizmi kodiranja i mehanizmi prijenosnog kodiranja u strojno čitljivom optičkom formatu (dalje u tekstu „QR”)

1. Uvod

Tehničke specifikacije utvrđene u ovom Prilogu definiraju opću strukturu podataka i mehanizme kodiranja za EU digitalnu COVID potvrdu (DCC). Utvrđuju i mehanizam prijenosnog kodiranja u strojno čitljivom optičkom formatu (QR), koji se može prikazati na zaslonu mobilnog uređaja ili otisnuti na papiru. Formati spremnika elektroničkih zdravstvenih potvrda iz ovih specifikacija jesu generički, ali ovdje služe za DCC.

2. Terminologija

Za potrebe ovog Priloga „izdavatelji” znači organizacije koje se ovim specifikacijama služe za izdavanje zdravstvenih potvrda, a „vršitelji provjera” znači organizacije koje prihvaćaju zdravstvene potvrde kao dokaz zdravstvenog statusa. „Sudionici” znači izdavatelji i vršitelji provjera. Sudionici moraju koordinirati neke aspekte utvrđene u ovom Prilogu, npr. upravljanje imenskim prostorom i distribuciju kriptografskih ključeva. Pretpostavlja se da te zadaće obavlja određena služba, dalje u tekstu „tajništvo”.

3. Format spremnika elektroničkih zdravstvenih potvrda

Format spremnika elektroničkih zdravstvenih potvrda (HCERT) je osmišljen kao jedinstveno i standardizirano sredstvo za čuvanje zdravstvenih potvrda različitih izdavatelja („izdavatelji”). Cilj tih specifikacija je uskladiti prikazivanje, kodiranje i potpisivanje zdravstvenih potvrda radi lakše interoperabilnosti.

Za čitanje i tumačenje DCC-a bilo kojeg izdavatelja potrebno je imati zajedničku strukturu podataka i dogovor o značenju svakog podatkovnog polja korisnog sadržaja. Za potrebe takve interoperabilnosti zajednička koordinirana struktura podataka definirana je JSON shemom koja je okvir DCC-a.

3.1. Struktura korisnog sadržaja

Korisni sadržaj je strukturiran i kodiran kao CBOR i digitalno potpisan protokolom COSE. To se obično naziva CBOR-ovim web-tokenom (CBOR Web Token ili CWT), koji je definiran u RFC-u 8392 ( 1 ). Korisni sadržaj, definiran u odjeljcima u nastavku, prenosi se u hcert tvrdnji.

Vršitelj provjere mora moći provjeriti cjelovitost i vjerodostojnost porijekla podataka u korisnom sadržaju. Za potrebe tog mehanizma izdavatelj mora potpisati CWT asimetričnom shemom elektroničkog potpisa kako je definirano u specifikaciji COSE-a (RFC 8152 ( 2 )).

3.2. CWT tvrdnje

3.2.1. Pregled strukture CWT-a

Zaštićeno zaglavlje

— Potpisni algoritam (alg, oznaka 1)

— Identifikator ključa (kid, oznaka 4)

Korisni sadržaj

— Izdavatelj (iss, ključ tvrdnje 1, opcionalno, ISO 3166-1 alfa-2 izdavatelja)

— Izdan (iat, ključ tvrdnje 6)

— Istek (exp, ključ tvrdnje 4)

— Zdravstvena potvrda (hcert, ključ tvrdnje -260)

— EU digitalna COVID potvrda v1 (eu_DCC_v1, ključ tvrdnje 1)

Potpis

3.2.2. Potpisni algoritam

Parametar Potpisni algoritam (alg) sadržava algoritam kojim je izrađen potpis. Taj algoritam mora biti barem na razini trenutačnih SOG-IS-ovih smjernica, kako su sažete u sljedećim odlomcima.

Definirana su dva algoritma, primarni i sekundarni. Sekundarni algoritam upotrebljava se samo ako primarni algoritam nije prihvatljiv zbog pravila i propisa koje je uveo izdavatelj.

Zbog sigurnosti sustava sve implementacije sustava moraju sadržavati sekundarni algoritam. To znači da i primarni i sekundarni algoritam moraju biti implementirani.

SOG-IS-ove razine za primarne i sekundarne algoritme su:

— primarni algoritam: primarni algoritam je algoritam za digitalno potpisivanje na temelju eliptičkih krivulja (ECDSA), kako je definiran u odjeljku 2.3. norme ISO/IEC 14888–3:2006, s P–256 parametrima, kako su definirani u Dodatku D (D.1.2.3) norme FIPS PUB 186–4 u kombinaciji s algoritmom za SHA–256 hash kontrolne brojeve, kako je definiran u funkciji 4 norme ISO/IEC 10118–3:2004,

To odgovara parametru COSE algoritma ES256.

— sekundarni algoritam: sekundarni algoritam je RSASSA-PSS, kako je definiran u RFC-u 8230 ( 3 ), s modulom od 2048 bita u kombinaciji s algoritmom za SHA–256 hash kontrolne brojeve, kako je definiran u funkciji 4 norme ISO/IEC 10118–3:2004.

To odgovara parametru COSE algoritma PS256.

3.2.3. Identifikator ključa

Tvrdnja Identifikator ključa (kid) pokazuje potpisni certifikat za dokumente (DSC) s javnim ključem koji vršitelj provjere koristi za provjeru ispravnosti digitalnog potpisa. Upravljanje certifikatima javnih ključeva, uključujući zahtjeve za DSC-ove, opisano je u Prilogu IV.

Vršitelji provjere koriste tvrdnju Identifikator ključa (kid) da odaberu pravi javni ključ s popisa ključeva koji se odnose na izdavatelja iz tvrdnje Izdavatelj (iss). Izdavatelj zbog administrativnih razloga ili zbog prebacivanja na druge ključeve može istodobno koristiti nekoliko ključeva. Polje Identifikator ključa nije sigurnosno kritično. Zbog toga može biti i u nezaštićenom zaglavlju ako je potrebno. Vršitelji provjere moraju prihvaćati obje opcije. Ako Identifikator ključa postoji i u nezaštićenom i u zaštićenom zaglavlju, koristi se onaj iz zaštićenog zaglavlja.

Budući da se identifikator skraćuje (zbog ograničenja veličine), postoji vrlo mala mogućnost da na cijelom popisu DSC-ova koje vršitelj provjere prihvaća postoje DSC-ovi s jednakim kid-ovima. Zbog toga vršitelj provjere mora provjeriti sve DSC-ove s tim kid-om.

3.2.4. Izdavatelj

Tvrdnja Izdavatelj (iss) je niz koji opcionalno može sadržavati alfa-2 oznaku zemlje, u skladu s normom ISO3166-1, subjekta koji izdaje zdravstvenu potvrdu. Vršitelj provjere može iskoristiti tu tvrdnju za utvrđivanje koji skup DSC-ova treba uzeti za provjeru valjanosti. Ključ tvrdnje 1 služi za identifikaciju te tvrdnje.

3.2.5. Istek

Tvrdnja Istek (exp) sadržava vremenski žig kao cijeli broj u formatu NumericDate (kako je definirano u odjeljku 2. RFC-a 8392 ( 4 )), koji pokazuje dokad se taj potpis korisnog sadržaja smatra valjanim, nakon čega vršitelj provjere mora odbaciti sadržaj zbog isteka. Svrha parametra isteka je prisilno ograničiti razdoblje valjanosti zdravstvene potvrde. Ključ tvrdnje 4 služi za identifikaciju te tvrdnje.

Vrijednost tvrdnje Istek ne smije biti vrijeme nakon razdoblja valjanosti DSC-a.

3.2.6. Izdan

Tvrdnja Izdan (iat) sadržava vremenski žig kao cijeli broj u formatu NumericDate (kako je definirano u odjeljku 2. RFC-a 8392 ( 5 )), koji pokazuje kad je zdravstvena potvrda nastala.

Vrijednost polja Izdan ne smije biti vrijeme prije razdoblja valjanosti DSC-a.

Vršitelji provjere smiju uvesti dodatna pravila da ograniče valjanost zdravstvene potvrde na temelju vremena izdavanja. Ključ tvrdnje 6 služi za identifikaciju te tvrdnje.

3.2.7. Tvrdnja Zdravstvena potvrda

Tvrdnja Zdravstvena potvrda (hcert) je JSON objekt (RFC 7159 ( 6 )) koji sadržava podatke o zdravstvenom statusu. U istoj tvrdnji može postojati nekoliko različitih vrsta zdravstvenih potvrda, jedna od kojih je DCC.

JSON služi isključivo za davanje sheme. Prezentacijski je format CBOR, kako je definiran u (RFC 7049 ( 7 )). Razvojni programeri zapravo ne moraju nikada dekodirati niti kodirati u/iz JSON-a nego mogu koristiti strukturu u memoriji.

Ključ tvrdnje za identifikaciju te tvrdnje je -260.

Nizovi u JSON objektu trebali bi biti normalizirani u skladu s kanonskim sastavljanjem normalizacijskog oblika (NFC) definiranim u normi Unicode. Aplikacije za dekodiranje trebale bi biti blage i robusne u tim aspektima, pri čemu je vrlo poželjno da se prihvaća bilo koja razumna konverzija tipa. Ako se u dekodiranju ili naknadnim funkcijama usporedbe naiđe na nenormalizirane podatke, implementacije bi se trebale ponašati kao da su ulazni podaci normalizirani u skladu s NFC-om.

4. Serijalizacija i izrada korisnog sadržaja DCC-a

Obrazac serijalizacije prikazan je na sljedećoj slici:

Proces počinje ekstrakcijom podataka, npr. iz repozitorija zdravstvenih podataka (ili nekog vanjskog izvora podataka), pri čemu se dobiveni podaci strukturiraju u skladu s definiranim shemama DCC-a. U tom se procesu konverzija podataka u definirani format i prilagođavanje da budu čitljivi ljudima mogu izvršiti prije serijalizacije u CBOR. Pokrate tvrdnji u svim se slučajevima povezuju s prikaznim imenima prije serijalizacije i nakon deserijalizacije.

Opcionalni nacionalni podatkovni sadržaj nije dopušten u potvrdama izdanima na temelju Uredbe (EU) 2021/953 ( 8 ). Podatkovni sadržaj je ograničen na definirane podatkovne elemente u minimalnom skupu podataka utvrđenom u Prilogu Uredbi 2021/953.

5. Prijenosno kodiranje

5.1. Neformatirano

Kroz sučelja za proizvoljne podatke HCERT spremnik i njegovi korisni sadržaji mogu se prenositi u početnom obliku bilo kojim temeljnim pouzdanim prijenosom podataka koji je siguran za 8-bitno kodirane podatke. Među tim sučeljima su Near-Field Communication (NFC), Bluetooth ili prijenos protokolom na aplikacijskom sloju, na primjer prijenos HCERT-a od izdavatelja do nositeljeva mobilnog uređaja.

Ako se prijenos HCERT-a od izdavatelja do nositelja temelji na sučelju koje je samo za pokazivanje (npr. SMS, e-poruka), neformatirano prijenosno kodiranje očito nije primjenjivo.

5.2. Crtični kod

5.2.1. Komprimiranje korisnog sadržaja (CWT-a)

Da bi se smanjila veličina i da bi se povećale brzina i pouzdanost procesa čitanja HCERT-a, CWT se komprimira ZLIB-om (RFC 1950 ( 9 )) i kompresijskim mehanizmom Deflate u formatu definiranom u RFC-u 1951 ( 10 ).

5.2.2. QR 2D crtični kod

Da bi bolje radio sa starijom opremom koja je projektirana za rad s korisnim sadržajima u ASCII-ju, prije kodiranja u 2D crtični kod komprimirani CWT kodira se u ASCII kodnom shemom Base45.

Za generiranje 2D crtičnog koda koristi se QR format definiran u normi ISO/IEC 18004:2015. Preporučena je stopa ispravljanja pogrešaka Q (približno 25 %). Budući da se koristi Base45, QR kod mora koristiti alfanumeričko kodiranje (način 2, označen simbolima 0010).

Da bi vršitelji provjere mogli utvrditi tip kodiranih podataka i odabrati odgovarajuću shemu za dekodiranje i obradu, podaci kodirani s Base45 (kao u ovoj specifikaciji) moraju imati niz Identifikator konteksta, prefiks „HC1:”. Buduće verzije ove specifikacije koje utječu na kompatibilnost s prijašnjim verzijama definirat će novi niz Identifikator konteksta, pri čemu znak iza „HC” mora biti iz skupa znakova [1-9 A-Z]. Poredak povećanja definiran je tim redom, tj. prvo [1-9], a onda [A-Z].

Preporučeno je da prezentacijski medij na kojem se nalazi optički kod bude veličine dijagonale od 35 mm do 60 mm da bi ga mogli očitati čitači s fiksnim optičkim mehanizmima u kojima se prezentacijski medij postavlja na površinu čitača.

Ako je optički kod otisnut pisačem niske rezolucije (< 300 dpi), mora se paziti da je svaki simbol (točka) QR koda pravilan kvadrat. Nerazmjerna promjena veličine značila bi da bi neki redovi ili stupci QR koda imali pravokutne simbole, što bi u mnogim slučajevima smanjilo čitljivost.

6. Format popisa povjerenja (popis CSCA-ova i DSC-ova)

Svaka država članica dužna je dostaviti popis s najmanje jednim krovnim nacionalnim certifikacijskim tijelom za potpisivanje certifikata (CSCA) i popis svih valjanih potpisnih certifikata za dokumente (DSC-ovi).

6.1. Pojednostavnjeni CSCA/DSC

U ovoj verziji specifikacija države članice ne pretpostavljaju da se upotrebljavaju informacije iz popisa povučenih certifikata (CRL) niti da vršitelji provjere provjeravaju razdoblje upotrebe privatnog ključa.

Umjesto toga, primarni mehanizam za provjeru valjanosti je prisutnost certifikata na najnovijoj verziji tog popisa certifikata.

6.2. PKI i centri povjerenja za ICAO-ove eMRTD-ove

Države članice smiju imati zasebni CSCA – ali mogu i prijaviti i certifikate postojećih CSCA-ova ili DSC-ove za strojno čitljive putne isprave (eMRTD-ovi) ili ih čak nabavljati od (komercijalnih) centara povjerenja – pa ih prijavljivati. Međutim, svaki DSC mora biti potpisan od CSCA-a koji je država članica prijavila.

7. Sigurnosni elementi

U razvoju shema na temelju ove specifikacije države članice identificiraju, analiziraju i prate određene sigurnosne aspekte.

Trebalo bi uzeti u obzir barem aspekte u nastavku.

7.1. Razdoblje valjanosti potpisa HCERT-a

Izdavatelj HCERT-a dužan je ograničiti razdoblje valjanosti potpisa definiranjem isteka potpisa. Zbog toga nositelj mora periodično obnavljati zdravstvenu potvrdu.

Prihvatljivo razdoblje valjanosti određuje se na temelju praktičnih ograničenja. Na primjer, putnik možda ne bude mogao obnoviti zdravstvenu potvrdu za vrijeme puta u inozemstvo. Moguće je i da izdavatelj razmatra mogućnost neke sigurnosne prijetnje zbog koje bi izdavatelj morao povući DSC (što podrazumijeva prestanak valjanosti svih zdravstvenih potvrda potpisanih tim ključem prije isteka). Posljedice takvog događaja mogu se ograničiti redovitim zamjenama ključeva izdavatelja i zahtijevanjem obnavljanja svih zdravstvenih potvrda u razumnim intervalima.

7.2. Upravljanje ključevima

Radi osiguravanja cjelovitosti podataka i provjeravanja autentičnosti porijekla podataka ova se specifikacija u velikoj mjeri oslanja na jake kriptografske mehanizme. Stoga je potrebno štititi povjerljivost privatnih ključeva.

Povjerljivost kriptografskih ključeva može biti kompromitirana zbog različitih razloga, npr.:

— proces generiranja ključeva mogao je imati nedostatke, pa su generirani slabi ključevi,

— ključevi su mogli biti izloženi zbog ljudske pogreške,

— unutarnji ili vanjski počinitelji mogli su ukrasti ključeve,

— ključevi se mogu izračunati kriptoanalizom.

Radi umanjivanja rizika zbog preslabog potpisnog algoritma, zbog čega se ključevi mogu kompromitirati kriptoanalizom, u ovoj je specifikaciji preporučeno da svi sudionici uvedu sekundarni, pričuvni potpisni algoritam koji će se od primarnog razlikovati na temelju parametara ili matematičkog problema.

Kad su navedeni rizici posljedica izdavateljeva radnog okruženja, moraju se uvesti mjere ublažavanja kojima se osigurava djelotvorna kontrola, npr. generiranje, pohranjivanje i upotrebljavanje ključeva u hardverskim sigurnosnim modulima (HSM-ovi). Snažno se potiče korištenje HSM-ova za potpisivanje zdravstvenih potvrda.

Neovisno o tome koristi li izdavatelj HSM-ove, trebalo bi definirati raspored prebacivanja na nove ključeve s učestalošću zamjena ključeva koja je razmjerna izloženosti ključeva vanjskim mrežama, drugim sustavima i osoblju. Dobro odabran raspored prebacivanja na druge ključeve također smanjuje rizike povezane s pogrešno izdanim zdravstvenim potvrdama jer izdavatelj može prema potrebi povlačenjem ključa skupno povući takve zdravstvene potvrde.

7.3. Provjera valjanosti ulaznih podataka

Ove specifikacije mogu se primijeniti tako da se podrazumijeva da se podaci, koji se unose u sustave koji bi mogli biti kritični za rad, primaju iz nepouzdanih izvora. Da bi se rizici povezani s tim vektorom napada sveli na najmanju moguću mjeru, mora se provjeriti valjanost svih ulaznih polja na temelju vrste podataka, duljine i sadržaja. Izdavateljev potpis mora se provjeriti prije bilo kakva obrade sadržaja HCERT-a. Međutim, provjera izdavatelja potpisa znači da se prvo mora proći kroz izdavateljevo zaštićeno zaglavlje u koje potencijalni napadač može pokušati ubaciti pažljivo sastavljene informacije osmišljene za kompromitiranje sigurnosti sustava.

8. Upravljanje povjerenjem

Da bi se provjerio potpis HCERT-a, potreban je javni ključ. Države članice objavljuju te javne ključeve. Svaki vršitelj provjere treba imati popis svih javnih ključeva kojima je spreman vjerovati (jer javni ključ nije dio HCERT-a).

Sustav se sastoji od (samo) dva sloja: za svaku državu članicu najmanje jedan certifikat na nacionalnoj razini, kakvim se potpisuju potpisni certifikati za dokumente koji se koriste u svakodnevnom radu.

Certifikati država članica zovu se certifikati krovnog nacionalnog certifikacijskog tijela za potpisivanje certifikata (CSCA) i obično su samopotpisani certifikati. Države članice mogu imati više CSCA-ova, npr. ako prenose obveze na regionalnu razinu. Certifikatima CSCA-ova redovito se potpisuju potpisni certifikati za dokumente (DSC-ovi), kojima se potpisuju HCERT-ovi.

„Tajništvo” je funkcija. Ono redovito objedinjuje i objavljuje DSC-ove država članica, nakon što ih provjeri na temelju popisa certifikata CSCA-ova (koji je dostavljen i provjeren na drugi način).

Dobiveni popis DSC-ova je objedinjeni skup prihvatljivih javnih ključeva (i odgovarajućih identifikatora ključeva) koji vršitelji provjere mogu koristiti za provjeru potpisa na HCERT-ovima. Vršitelji provjera moraju redovito preuzimati taj popis pa ažurirati svoju kopiju.

Format takvih popisa specifičnih za pojedinačnu državu članicu može se prilagoditi za pojedinačno nacionalno okruženje. Zbog toga format datoteke tog popisa povjerenja može biti različit, npr. može biti potpisani JWKS (format JWK skupa u skladu s odjeljkom 5. RFC-a 7517 ( 11 )) ili bilo koji drugi format specifičan za tehnologiju u primjeni u toj državi članici.

Radi jednostavnosti države članice mogu dostaviti certifikate postojećih CSCA-ova za svoje sustave za ICAO-ve eMRTD-ove ili, kako preporučuje Svjetska zdravstvena organizacija, generirati novi koji će biti namjenski za zdravstvo.

8.1. Identifikator ključa (kids)

Identifikator ključa (kid) izračunava se u trenutku sastavljanja popisa pouzdanih javnih ključeva od DSC-ova i sastoji se od skraćenog (prvih 8 bajtova) SHA-256 otiska DCS-a kodiranog u DER (neformatiranom) formatu.

Vršitelji provjere ne moraju izračunavati identifikator ključa na temelju DSC-a i mogu izravno usporediti identifikator ključa u izdanoj zdravstvenoj potvrdi s identifikatorom ključa na popisu povjerenja.

8.2. Razlike u odnosu na model povjerenja infrastrukture javnih ključeva za ICAO-ove eMRTD-ove

Iako se ovaj model temelji na najboljim praktičnim rješenjima modela povjerenja infrastrukture javnih ključeva za ICAO-ove eMRTD-ove, radi brzine je uvedeno nekoliko pojednostavnjenja:

— svaka država članica smije dostaviti više certifikata CSCA-ova,

— razdoblje valjanosti DSC-a (upotreba ključa) smije biti bilo koja vrijednost unutar razdoblja valjanosti certifikata CSCA-a, koja ne mora ni biti deklarirana,

— DSC može sadržavati identifikatore pravila (proširena upotreba ključa) koja su specifična za zdravstvene potvrde,

— države članice, ako tako odluče, nikad ne moraju provjeravati objavljena povlačenja, nego se mogu samo oslanjati na popise DSC-ova koje im svakodnevno šalje tajništvo ili koje same sastavljaju.

▼M3

9. Rješenje za opoziv

9.1 Utvrđivanje popisa opozvanih DCC-a (DRL)

Pristupnik mora imati krajnje točke i funkcionalnost za čuvanje popisa opozvanih potvrda i za upravljanje tim popisima:

9.2 Model povjerenja

Sve se veze uspostavljaju na temelju certifikata NBTLS i NBUP standardnog modela povjerenja DCCG-a (vidjeti upravljanje certifikatima). Radi zaštite cjelovitosti sve se informacije pakiraju i šalju CMS porukama.

9.3 Sastavljanje skupa

9.3.1 Skup

Svaki popis opozvanih potvrda sastoji se od najmanje jednog unosa i mora biti zapakiran u skupovima koji sadržavaju hasheve i njihove metapodatke. Skup je nepromjenjiv i s definiranim datumom isteka, koji označava kad se skup može izbrisati. Svi elementi skupa moraju imati isti datum isteka, što znači da se skupovi mogu grupirati po datumu isteka i po DSC-u. Najveći dopušteni broj unosa u skupu je 1 000 . Ako popis opozvanih potvrda ima više od 1 000 unosa, izrađuje se više skupova. Nijedan unos ne može biti u više od jednog skupa. Skup se pakira u CMS strukturu i potpisuje certifikatom NBup države koja ga šalje.

9.3.2 Indeks skupova

Pristupnik skupu dodjeljuje jedinstven identifikator u trenutku sastavljanja, koji se automatski dodaje u indeks. Indeks skupova poredan je po datumu izmjene, počevši od najstarijeg.

9.3.3 Ponašanje pristupnika

Pristupnik obrađuje skupove opozvanih potvrda bez ikakvih promjena: pristupnik ne može ažurirati, uklanjati niti dodavati informacije u skupovima. Skupovi se prosljeđuju svim odobrenim zemljama (vidjeti poglavlje 9.6.).

Pristupnik aktivno prati datume isteka skupova i uklanja istekle skupove. Nakon što se neki skup izbriše, pristupnik na URL izbrisanog skupa odgovara s „HTTP 410 Gone”. U indeksu skupova taj skup je označen kao izbrisan.

9.4 Vrste hasheva

Popis opozvanih potvrda sadržava hasheve koji mogu označavati različite vrste/atribute opozvanih potvrda. Te vrste i atributi navode se zajedno s popisom opozvanih potvrda. Trenutačne su vrste:







Vrsta Atribut Izračun hasha SIGNATURE potpis DCC-a SHA256 potpisa DCC-a UCI UCI (jedinstveni identifikator potvrde) SHA256 UCI-ja COUNTRYCODEUCI kod zemlje izdavateljice + UCI SHA256 koda zemlje izdavateljice + USI-ja

U skupove se unosi samo prvih 128 bitova hasheva kodiranih u base64 nizove koji služe za identifikaciju opozvanog DCC-a ( 12 ).

9.4.1 Vrsta hasha: SHA256 (potpis DCC-a)

Hash se izračunava za COSE_SIGN1 potpis iz CWT-a. Za RSA potpise ulazna vrijednost je cijeli potpis. Formula za certifikate potpisane EC-DSA-om je uzimanje r kao ulazne vrijednosti:

SHA256(r)

[obvezno u svim novim implementacijama]

9.4.2 Vrsta hasha: SHA256 (UCI)

Hash se izračunava za niz UCI-ja kodiran u UTF-8 pa se konvertira u polje bajtova.

[zastarjelo ( 13 ), ali podržano zbog kompatibilnosti sa starijim elementima sustava]

9.4.3 Vrsta hasha: SHA256 (kod zemlje izdavateljice + USI)

U ovom je slučaju kod zemlje niz (string) kodiran u UTF-8 kojem je dodan UCI koji je niz (string) kodiran u UTF-8. Taj se niz konvertira u polje bajtova koje je ulazna vrijednost funkcije za generiranje hasha.

[zastarjelo2, ali podržano zbog kompatibilnosti sa starijim elementima sustava]

9.5 Struktura API-ja

9.5.1 API za unošenje opozvanih potvrda

9.5.1.1 Svrha

API organizira unose s popisa opozvanih potvrda u skupovima i sastavlja indeks skupova.

9.5.1.2 Krajnje točke

9.5.1.2.1 Krajnja točka za preuzimanje popisa skupova

Krajnje su točke dizajnirane jednostavno, a njihov je izlaz popis skupova u malom omotaču koji sadržava metapodatke. Skupovi su poredani po datumu od najstarijeg:

/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 }, .. ]

}

Napomena: Najveća veličina je 1 000 . Ako je parametar „more” postavljen na istinito (true), to znači da postoji još skupova za preuzimanje. Da bi se preuzeli dodatni skupovi, klijent mora postaviti vrijednost zaglavlja If-Modified-Since na datum koji nije prije datuma posljednjeg primljenog skupa.

Odgovor je JSON polje sljedeće strukture:







Polje Definicija more ako je vrijednost ovog parametra istinito (True), to znači da postoji još skupova batches polje s postojećim skupovima batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country kod zemlje u skladu s normom ISO 3166 date UTC datum u skladu s normom ISO 8601 datum dodavanja ili brisanja skupa deleted moguće vrijednosti su istinito/neistinito; vrijednost istinito (True) označava da je skup izbrisan; unos se može ukloniti iz rezultata upita sedam dana nakon što se ova vrijednost postavi na istinito

9.5.1.2.1.1 Kodovi odgovora







Kôd Opis 200 sve je u redu 204 nema sadržaja ako nema rezultata za zaglavlje „If-Modified-Since”

Zaglavlje zahtjeva







Zaglavlje Obvezno Opis If-Modified-Since da Ova vrijednost zaglavlja sadržava datum zadnjeg preuzimanja da bi se dobili samo najnoviji rezultati. Vrijednost se postavlja na „2021-06-01T00:00:00Z” prilikom prvog pozivanja.

9.5.1.2.2 Krajnja točka za preuzimanje skupova

Skupovi sadržavaju popis identifikatora certifikata:

/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’ }, ..]

}

Odgovor sadržava CMS s potpisom koji mora odgovarati certifikatu NBUP zemlje. Struktura svake stavke u JSON polju je sljedeća:







Polje Obvezno Vrsta Definicija expires da niz (string) datum kad se stavka može ukloniti UTC datum/vrijeme u skladu s normom ISO 8601 country da niz (string) kod zemlje u skladu s normom ISO 3166 hashType da niz (string) vrsta hasha unosa (vidjeti Vrste hasheva) entries da blok JSON objekta vidjeti tablicu s unosima kid da niz (string) KID kodiran u base64 DSC-a kojim je potpisan DCC; Ako KID nije poznat, može se unijeti niz „UNKNOWN_KID” (bez navodnika). Napomene:

— Skupine se grupiraju po datumu isteka i po DSC-u – svi elementi istječu u istom trenutku i moraju biti potpisani istim ključem.

— Rok isteka je UTC datum/vrijeme jer je EUDCC svjetski sistem u kojem vrijeme mora uvijek biti jednoznačno.

— Datum isteka trajno opozvanog DCC-a postavlja se na datum isteka odgovarajućeg DSC-a kojim je DCC potpisan ili na Istek opozvanog DCC-a (u kom slučaju se vremena NumericDate/epoch obrađuju kao da su u vremenskoj zoni UTC).

— Nacionalni backend (NB) uklanja elemente sa svojih popisa opozvanih potvrda na datum isteka .

— NB može ukloniti elemente sa svojih popisa opozvanih potvrda ako je povučen kid kojim je DCC potpisan.

9.5.1.2.2.1 Unosi







Polje Obvezno Vrsta Definicija hash da niz (string) prvih 128 bitova hasheva dobivenih algoritmom SHA256 koji su kodirani u base64

Napomena: Objekt s elementima trenutačno sadržava samo hash, ali se zbog kompatibilnosti s budućim promjenama koristi objekt umjesto JSON polja.

9.5.1.2.2.2 Kodovi odgovora







Kôd Opis 200 sve je u redu 410 skupa nema; skup se može izbrisati u nacionalnom backendu

9.5.1.2.2.3 Zaglavlje odgovora







Zaglavlje Opis ETag identifikator skupa

9.5.1.2.3 Krajnja točka za slanje skupova

Skupovi se šalju preko iste krajnje točke metodom POST Verb:

/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’ }, ..]

}

Skup se potpisuje certifikatom NBUP. Pristupnik provjerava da je skup potpisan certifikatom NBUP odgovarajuće zemlje (country). Slanje skupa neće biti dopušteno ako ta provjera ne potvrdi potpis.

NAPOMENA: Nijedan se skup ne može mijenjati nakon slanja. Međutim, skupove je moguće obrisati. Identifikator svakog izbrisanog skupa se čuva te se ne dopušta slanje novog skupa s istim identifikatorom.

9.5.1.2.4 Krajnja točka za brisanje skupova

Skupovi se mogu izbrisati preko iste krajnje točke metodom DELETE Verb:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

„batchId”: „...”

}

ili se zbog kompatibilnosti mogu izbrisati i preko ove krajnje točke metodom POST Verb:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

„batchId”: „...”

}

9.6 Zaštita API-ja/GDPR

U ovom su odjeljku utvrđene mjere koje se u implementacijama koriste radi ispunjavanja odredbi Uredbe 2021/953 s obzirom na obradu osobnih podataka.

9.6.1 Postojeća autentifikacija

Pristupnik trenutačno koristi certifikat NBTLS da bi autentificirao zemlje koje mu pristupaju. Ta autentifikacija može poslužiti za utvrđivanje identiteta zemlje povezane s pristupnikom. Ta autentifikacija može onda poslužiti za kontrolu pristupa.

9.6.2 Kontrola pristupa

Da bi se osobni podaci mogli zakonito obrađivati, u pristupniku mora postojati mehanizam za kontrolu pristupa.

Pristupnik ima popis za kontrolu pristupa koji funkcionira zajedno sa sigurnošću na temelju uloga. To znači da se u pristupniku vode dvije tablice, jedna u kojoj je definirano koje uloge mogu izvesti koje radnje na kojim resursima i druga u kojoj je navedeno koje su uloge dodijeljene kojim korisnicima.

Za kontrole propisane ovim dokumentom potrebne su tri uloge:

RevocationListReader

RevocationUploader

RevocationDeleter

Za provjeru ima li korisnik ulogu RevocationListReader služe sljedeće krajnje točke. Ako pristup bude potvrđen na tim krajnjim točkama, pristup će biti odobren, a u suprotnom će odgovor biti poruka HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Za provjeru ima li korisnik ulogu RevocationUploader služe sljedeće krajnje točke. Ako pristup bude potvrđen na tim krajnjim točkama, pristup će biti odobren, a u suprotnom će odgovor biti poruka HTTP 403 Forbidden:

POST/revocation-list

Za provjeru ima li korisnik ulogu RevocationDeleter služe sljedeće krajnje točke. Ako pristup bude potvrđen na tim krajnjim točkama, pristup će biti odobren, a u suprotnom će odgovor biti poruka HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Pristupnik mora administratorima omogućivati pouzdano upravljanje ulogama povezanima s korisnicima tako da se smanji mogućnost ljudske pogreške, ali ne i poveća opterećenje administratora funkcija.

▼M1









PRILOG II.

PRAVILA ZA ISPUNJAVANJE EU DIGITALNIH COVID POTVRDA

Cilj je općih pravila za skupove vrijednosti utvrđenih u ovom Prilogu postići interoperabilnost na semantičkoj razini i omogućiti dosljednost u tehničkim implementacijama EU digitalne COVID potvrde. Elementi iz ovog Priloga mogu se upotrebljavati za tri različita slučaja (cijepljenje/testiranje/preboljenje), kako je propisano u Uredbi (EU) 2021/953. U ovom su Prilogu popisani samo elementi koje je potrebno semantički standardizirati skupovima kodiranih vrijednosti.

Države članice su odgovorne za prevođenje kodiranih elemenata na nacionalni jezik.

Kodiranje svih podatkovnih polja koja nisu navedena u sljedećim opisima skupova vrijednosti opisano je u Prilogu V.

Ako iz nekog razloga nije moguće primijeniti preferirani kodni sustav, mogu se upotrijebiti drugi međunarodni kodni sustavi, pri čemu treba navesti kako se kodovi tog drugog sustava mapiraju na preferirani kodni sustav. U iznimnim slučajevima tekst (prikazna imena) smije poslužiti kao pričuvni mehanizam ako odgovarajući kôd nije prisutan u definiranim skupovima vrijednosti.

Države članice koje upotrebljavaju druga kodiranja u svojim sustavima moraju mapirati takve kodove na opisane skupove vrijednosti. Države članice su odgovorne za sva takva mapiranja.

Budući da se neki skupovi vrijednosti koji se temelje na sustavima kodiranja propisanima u ovom Prilogu, npr. kodiranje cjepiva i brzih antigenskih testova, često mijenjaju, Komisija ih uz potporu mreže e-zdravstva i Odbora za zdravstvenu sigurnost objavljuje i redovito ažurira. Ažurirani skupovi vrijednosti objavljuju se na odgovarajućim internetskim stranicama Komisije i na internetskim stranicama mreže e-zdravstva. Evidencija promjena mora biti dostupna.

1. Bolest ili agens na koji se cilja/bolest ili agens koji je nositelj prebolio: COVID-19 (SARS-CoV-2 ili neka od njegovih varijanti)

Za upotrebu u potvrdi 1, 2 i 3.

Koristi se sljedeći kôd:







Kôd Prikaz Ime kodnog sustava URL kodnog sustava OID kodnog sustava Verzija kodnog sustava 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

2. Cjepivo ili profilaksa protiv bolesti COVID-19

Preferirani kodni sustav: SNOMED CT ili klasifikacija ATC.

Za upotrebu u potvrdi 1.

Primjeri kodova kodiranih preferiranim kodnim sustavima su, za kôd SNOMED CT, 1119305005 (antigensko cjepivo protiv virusa SARS-CoV-2), 1119349007 (mRNA cjepivo protiv virusa SARS-CoV-2) ili J07BX03 (cjepiva protiv bolesti COVID-19).

Komisija uz potporu mreže e-zdravstva objavljuje i redovito ažurira skup kodova u skladu s kodnim sustavima utvrđenima u ovom odjeljku koji treba koristiti. Taj se skup vrijednosti proširuje u skladu s razvojem i puštanjem u uporabu novih vrsta cjepiva.

3. Cjepivo protiv bolesti COVID-19

Preferirani kodni sustavi (prema redoslijedu prioriteta):

— registar lijekova Unije za cjepiva s odobrenjem na razini EU-a (brojevi odobrenja),

— neki svjetski registar cjepiva, npr. registar koji bi mogla uspostaviti Svjetska zdravstvena organizacija,

— naziv cjepiva u ostalim slučajevima; sve bjeline u nazivu zamjenjuju se spojnicom (-).

Ime skupa vrijednosti: cjepivo.

Za upotrebu u potvrdi 1.

Primjer koda kodiranog preferiranim kodnim sustavom je EU/1/20/1528 (Comirnaty). Primjer ako se kao kôd koristi naziv cjepiva: Sputnik-V (za Sputnik V).

Komisija uz potporu mreže e-zdravstva objavljuje i redovito ažurira skup kodova u skladu s kodnim sustavima utvrđenima u ovom odjeljku koji treba koristiti.

Cjepiva se kodiraju postojećim kodom iz objavljenog skupa vrijednosti, čak i ako se u različitim zemljama drukčije zovu. To je zato što još uvijek ne postoji svjetski registar cjepiva u kojem su popisana sva cjepiva trenutačno u uporabi. Primjer:

— Za cjepivo „COVID-19 Vaccine Moderna Intramuscular Injection”, kako se cjepivo Spikevax zove u Japanu, koristi se kôd EU/1/20/1507 jer je to naziv cjepiva u EU-u.

Ako to u određenom slučaju nije moguće ili preporučljivo, u objavljenom skupu vrijednosti bit će propisan zaseban kôd.

4. Nositelj odobrenja za stavljanje u promet cjepiva protiv bolesti COVID-19 ili proizvođač tog cjepiva

Preferirani kodni sustav:

— kôd organizacije iz EMA-e (SPOR za ISO norme za identifikaciju lijekova),

— neki svjetski registar nositelja odobrenja za stavljanje u promet cjepiva ili proizvođača tog cjepiva, npr. registar koji bi mogla uspostaviti Svjetska zdravstvena organizacija,

— ime organizacije u ostalim slučajevima; sve bjeline u imenu zamjenjuju se spojnicom (-).

Za upotrebu u potvrdi 1.

Primjer koda kodiranog preferiranim kodnim sustavom je ORG-100001699 (AstraZeneca AB). Primjer ako se kao kôd koristi ime organizacije: Sinovac-Biotech (za Sinovac Biotech).

Komisija uz potporu mreže e-zdravstva objavljuje i redovito ažurira skup kodova u skladu s kodnim sustavima utvrđenima u ovom odjeljku koji treba koristiti.

Različite podružnice istog nositelja odobrenja za stavljanje u promet ili istog proizvođača dužne su koristiti postojeći kôd iz objavljenog skupa vrijednosti.

Budući da još uvijek ne postoji međunarodno dogovoren registar proizvođača cjepiva ili nositelja odobrenja za stavljanje u promet, opće je pravilo da se za isto cjepivo koristi kôd koji upućuje na nositelja odobrenja za stavljanje u promet u EU-u. Primjeri:

— Za organizaciju „Pfizer AG”, koja je nositelj odobrenja za stavljanje u promet cjepiva „Comirnaty” u Švicarskoj, koristi se kôd ORG-100030215 koji upućuje na BioNTech Manufacturing GmbH jer je to nositelj odobrenja za stavljanje u promet cjepiva „Comirnaty” u EU-u.

— Za organizaciju „Zuellig Pharma”, koja je nositelj odobrenja za stavljanje u promet cjepiva „Covid-19 Vaccine Moderna (Spikevax)” na Filipinima, koristi se kôd ORG-100031184 koji upućuje na Moderna Biotech Spain S.L. jer je to nositelj odobrenja za stavljanje u promet cjepiva „Spikevax” u EU-u.

Ako to u određenom slučaju nije moguće ili preporučljivo, u objavljenom skupu vrijednosti bit će propisan zaseban kôd.

5. Broj doze u seriji i ukupan broj doza u seriji

Za upotrebu u potvrdi 1.

Dva polja:

(1) broj doze u seriji doza cjepiva protiv bolesti COVID-19 (N);

(2) ukupni broj doza u seriji doza cjepiva (C).

5.1. Primarna serija cjepiva

Ako osoba prima doze iz primarne serije cjepiva, tj. serije cjepiva namijenjene da u početnoj fazi pruži dostatnu zaštitu, (C) je ukupni broj doza u primarnoj seriji cjepiva (npr. 1 ili 2, ovisno o vrsti cjepiva kojim se cijepi). To uključuje mogućnost kraće serije (C = 1) ako država članica primjenjuje protokol cijepljenja prema kojem se osobe koje su prethodno bile zaražene virusom SARS-CoV-2 cijepe 1 dozom cjepiva za koje je predviđeno cijepljenje s 2 doze. U tom se slučaju primarna serija cijepljenja označava s N/C = 1. Na primjer:

— 1/1 znači da je završena primarna serija cjepiva s cjepivom za koje je predviđeno cijepljenje s 1 dozom ili da je završena primarna serija cjepiva s 1 dozom cjepiva za koje je predviđeno cijepljenje s 2 doze u skladu s protokolom cijepljenja koji država članica primjenjuje za osobe koje su preboljele bolest,

— 2/2 znači da je završena primarna serija cijepljenja s 2 doze.

Ako je primarna serija cijepljenja proširena, npr. za osobe sa znatno oslabljenim imunosnim sustavom ili koje nisu primile doze primarne serije u preporučenom razmaku, takve se doze kodiraju kao dodatne doze iz odjeljka 5.2.

▼M2

5.2. Doze za docjepljivanje

Ako osoba primi dodatne doze nakon cijepljenja primarnom serijom cjepiva, takve doze za docjepljivanje moraju biti upisane u potvrde o cijepljenju kako slijedi:

— 2/1 znači da je osoba docijepljena nakon primarnog cijepljenja cjepivom koje je namijenjeno za cijepljenje jednom dozom, ili da je osoba preboljela bolest i u skladu s protokolom cijepljenja koji država članica primjenjuje za takve osobe primarno cijepljena jednom dozom cjepiva koje je inače namijenjeno za cijepljenje s dvije doze, a nakon toga docijepljena. Nakon toga, doze (X) koje su dane nakon prve doze za docjepljivanje navode se prema formuli (2+X)/(1) > 1 (na primjer 3/1);

— 3/3 znači da je osoba docijepljena nakon primarne serije cijepljenja s 2 doze. Nakon toga, doze (X) koje su dane nakon prve doze za docjepljivanje navode se prema formuli (3+X)/(3+X) = 1 (na primjer 4/4).

Države članice moraju primjenjivati pravila za kodiranje iz ovog odjeljka do 1. veljače 2022.

Države članice moraju, automatski ili na zahtjev osobe na koju se potvrda odnosi, ponovno izdati potvrde u kojima je docjepljivanje nakon primarnog potpunog cijepljenja cjepivom koje je namijenjeno za cijepljenje jednom dozom kodirano na takav način da se ne može razlikovati od potpunog cijepljenja primarnom serijom cjepiva.

Za svrhe ovog Priloga upućivanje na „doze za docjepljivanje” trebalo bi tumačiti tako da obuhvaća i dodatne doze koje su dane kako bi se bolje zaštitile osobe koje nemaju dovoljno dobru reakciju imunosnog sustava nakon standardnog potpunog cijepljenja primarnom serijom cjepiva. U pravnom okviru uspostavljenom Uredbom (EU) 2021/953 države članice mogu poduzeti mjere za pomaganje ranjivim skupinama koje bi mogle prioritetno primiti dodatne doze. Na primjer, ako država članica odluči dodatnim dozama cijepiti samo specifične podskupine stanovništva, može odabrati da u skladu sa stavkom 1. člankom 5. Uredbe (EU) 2021/953 umjesto automatski izdaje samo na zahtjev potvrde o cijepljenju na kojima je navedeno da je obavljeno cijepljene takvim dodatnim dozama. Ako se poduzmu takve mjere, države članice dužne su o tim mjerama obavijestiti osobe na koje se te mjere odnose te ih također obavijestiti o tome da se i dalje mogu služiti potvrdom primljenom po završetku standardne primarne serije cijepljenja.

▼M1

6. Država članica ili treća zemlja u kojoj je cjepivo primljeno/u kojoj je obavljeno testiranje

Preferirani kodni sustav: oznake zemalja ISO 3166.

Za upotrebu u potvrdi 1, 2 i 3.

Sadržaj skupa vrijednosti: cijeli popis dvoslovnih oznaka, dostupan kao skup vrijednosti u FHIR-u (http://hl7.org/fhir/ValueSet/iso3166-1-2). Ako je cijepljenje ili test izvršila međunarodna organizacija (kao što je UNHCR ili Svjetska zdravstvena organizacija) i ako nema podatka o zemlji, koristi se kôd organizacije. Komisija uz potporu mreže e-zdravstva objavljuje i redovito ažurira takve dodatne kodove.

7. Vrsta testa

Za upotrebu u potvrdi 2 i, ako se delegiranim aktom uvede izdavanje potvrda o preboljenju na temelju testova koji nisu NAAT, za upotrebu u potvrdi 3.

Koriste se sljedeći kodovi:







Kôd Prikaz Ime kodnog sustava URL kodnog sustava OID kodnog sustava Verzija kodnog sustava LP6464-4 umnažanje nukleinske kiseline s detekcijom sondi LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 brzi imunološki test LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

8. Proizvođač i trgovačko ime testa (nije obvezno za test NAAT)

Za upotrebu u potvrdi 2.

Sadržaj skupa vrijednosti su brzi antigenski testovi sa zajedničkog i ažuriranog popisa brzih antigenskih testova za COVID-19 koji je sastavljen na temelju Preporuke Vijeća 2021/C 24/01 i dogovoren s Odborom za zdravstvenu sigurnost. Taj popis održava JRC u bazi podataka o in vitro dijagnostičkim proizvodima i metodama za testiranje na COVID-19: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

U tom kodnom sustavu upotrebljavaju se relevantna polja, npr. identifikator proizvoda za testiranje, naziv testa i ime proizvođača, u skladu s JRC-ovim strukturiranim formatom dostupnim na: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9. Rezultat testa

Za upotrebu u potvrdi 2.

Koriste se sljedeći kodovi:







Kôd Prikaz Ime kodnog sustava URL kodnog sustava OID kodnog sustava Verzija kodnog sustava 260415000 nije otkriveno SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 otkriveno SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼B









PRILOG III.

ZAJEDNIČKA STRUKTURA JEDINSTVENOG IDENTIFIKATORA POTVRDE

1. Uvod

Svaka EU digitalna COVID potvrda (DCC) mora sadržavati jedinstveni identifikator potvrde (UCI) na temelju kojeg je moguća interoperabilnost DCC-ova. UCI može poslužiti za provjeru potvrde. Države članice su odgovorne za praktičnu primjenu UCI-ja. UCI je način za provjeravanje istinitosti potvrde i, ako je primjenjivo, za povezivanje s registracijskim sustavom (npr. IIS-om). Na temelju tih identifikatora funkcioniraju i (papirnate i digitalne) tvrdnje država članica da su pojedinci cijepljeni ili testirani.

2. Elementi jedinstvenog identifikatora potvrde

UCI ima zajedničku strukturu i format na temelju kojeg strojevi i ljudi mogu lako tumačiti podatke i može biti povezan s elementima kao što su država članica cijepljenja, samo cjepivo i identifikator države članice. Državama članicama daje fleksibilnost da ga formatiraju uz potpuno poštovanje propisa o zaštiti podataka. Poredak zasebnih elemenata slijedi definiranu hijerarhiju koja omogućuje da se blokovi u budućnosti mijenjaju, a da se ne naruši njezina strukturna cjelovitost.

Moguća rješenja za sastav UCI-ja čine raspon u kojem su modularnost i razumljivost za ljude dva glavna parametra na temelju kojih nastaju razlike, a u kojem postoji jedna temeljna karakteristika:

— modularnost: stupanj u kojem je kod sastavljen od jasno različitih blokova sa semantički različitim informacijama,

— razumljivost za ljude: stupanj u kojem kod ima značenje ili u kojem ga čovjek može protumačiti,

— globalna jedinstvenost: dobro upravljanje identifikatorom zemlje ili tijela, pri čemu se od svake zemlje (od svakog tijela) očekuje da upravlja svojim dijelom imenskog prostora tako da nikada ne upotrijebi ili ne izda isti identifikator. Ta kombinacija omogućava da svaki identifikator bude globalno jedinstven.

▼M1

3. Opći zahtjevi

Za UCI moraju biti ispunjeni sljedeći temeljni zahtjevi:

(1) skup znakova: dopušteni su samo veliki alfanumerički znakovi iz skupa US-ASCII (velika slova od „A” do „Z” i brojke od „0” do „9”), u kombinaciji sa specijalnim znakovima za razdvajanje iz RFC-a 3986 ( 14 ), tj. {„/“, „#”, „:“};

(2) najveća duljina: u osmišljavanju rješenja cilja se na 27–30 znakova ( 15 );

(3) prefiks verzije: odnosi se na verziju UCI sheme. Prefiks verzije je „01” za ovu verziju dokumenta; prefiks verzije je dvoznamenkasti broj;

(4) prefiks zemlje: oznaka zemlje je utvrđena u normi ISO 3166-1. Dulje oznake (najmanje 3 znaka, npr. „UNHCR”) rezervirane su za buduću upotrebu;

(5) Sufiks koda/kontrolni zbroj. 5.1. Države članice smiju koristiti kontrolne zbrojeve ako je vjerojatno da bi moglo doći do pogreške zbog prijenosa, (ljudske) transkripcije ili drugog razloga (tj. u slučaju pisanog oblika). 5.2. Kontrolni zbroj ne smije biti temelj provjere valjanosti potvrde niti je tehnički dio identifikatora; on služi samo za provjeru cjelovitosti koda. Kontrolni zbroj izračunava se u skladu s normom ISO-7812-1 (LUHN-10) ( 16 ) na temelju cijelog UCI-ja u digitalnom/fizičkom prijenosnom formatu. Kontrolni zbroj mora biti odvojen od ostatka UCI-ja znakom „#”.

Mora se osigurati kompatibilnost s prijašnjim verzijama: države članice koje s vremenom promijene strukturu svojih identifikatora (unutar glavne verzije, trenutačno v1) moraju se pobrinuti da se bilo koja dva identična identifikatora odnose na istu potvrdu/tvrdnju o cijepljenju. Drugim riječima, države članice ne smiju ponovno upotrijebiti isti identifikator.

▼B

4. Opcije za jedinstvene identifikatore potvrde za potvrde o cijepljenju

U smjernicama mreže e-zdravstva za provjerive potvrde o cijepljenju i za osnovne elemente interoperabilnosti ( 17 ) predviđene su različite opcije na raspolaganju državama članicama i drugim stranama, pri čemu u različitim državama članicama mogu istodobno postojati različite opcije. Države članice mogu primijeniti te opcije u različitim verzijama UCI sheme.









PRILOG IV.

UPRAVLJANJE CERTIFIKATIMA JAVNIH KLJUČEVA

1. Uvod

Države članice sigurno i pouzdano razmjenjuju potpisne ključeve za EU digitalne COVID potvrde pristupnikom za EU digitalnu COVID potvrdu (DCCG), koji je središnji repozitorij za javne ključeve. DCCG omogućava državama članicama da objavljuju javne ključeve koji su parovi privatnim ključevima kojima potpisuju digitalne COVID potvrde. Države članice se mogu osloniti na DCCG da pravodobno preuzmu ažurne materijale javnih ključeva. DCCG se naknadno može proširiti za razmjenu pouzdanih dopunskih informacija država članica, npr. pravila valjanosti za DCC-ove. Model povjerenja okvira za DCC je infrastruktura javnih ključeva (PKI). Svaka država članica mora imati najmanje jedno krovno nacionalno certifikacijsko tijelo za potpisivanje certifikata (CSCA), čiji certifikati imaju relativno dugo razdoblje valjanosti. Ovisno o odluci države članice, CSCA može biti isti CSCA koji se koristi za strojno čitljive putne isprave, ali se može i razlikovati od njega. CSCA izdaje certifikate javnih ključeva nacionalnim, kratkoročnim potpisnicima (tj. potpisnicima za DCC-ove), a ti se certifikati nazivaju potpisni certifikati za dokumente (DSC-ovi). CSCA je temelj povjerenja čiji certifikat države članice mogu iskoristiti da provjere vjerodostojnost i cjelovitost redovito mijenjanih DSC-ova. Nakon potvrde valjanosti države članice mogu dostaviti te certifikate (ili samo njihove javne ključeve) svojim aplikacijama za provjeru valjanost DCC-ova. Uz CSCA-ove i DSC-ove DCCG se također oslanja na PKI za provjeru vjerodostojnosti transakcija i potpisivanje podataka te kao na temelj autentifikacije i način jamčenja cjelovitosti komunikacijskih kanala između država članica i DCCG-a.

Digitalni potpisi mogu služiti da se postignu cjelovitost i vjerodostojnost podataka. Infrastrukture javnih ključeva stvaraju povjerenje jer povezuju javne ključeve s provjerenim identitetima (ili izdavateljima). To je potrebno da bi drugi sudionici mogli provjeriti porijeklo podataka i identitet komunikacijskog partnera, pa odlučiti vjeruju li im. DCCG se služi višestrukim certifikatima javnih ključeva radi potvrđivanja vjerodostojnosti. Da bi se postigla opća interoperabilnost među državama članicama, ovim Prilogom određuje se koji se certifikati javnih ključeva koriste i kako se generiraju. Navedeni su detaljniji podaci o certifikatima javnih ključeva i daju se smjernice za predloške certifikata i razdoblja valjanosti za države članice koje žele imati vlastiti CSCA. Budući da DCC-ovi moraju biti provjerivi u definiranom razdoblju (od izdavanja do zadanog isteka), potrebno je definirati model provjere za sve potpise primijenjene na certifikate javnih ključeva i DCC-ove.

2. Terminologija

Sljedeća tablica sadržava pokrate i terminologiju koji se koriste u ovom Prilogu.







Pojam Definicija Certifikat Ili certifikat javnog ključa. X.509 v3 certifikat s javnim ključem subjekta. CSCA Krovno nacionalno certifikacijsko tijelo za potpisivanje certifikata. DCC EU digitalna COVID potvrda. Potpisani digitalni dokument s informacijama o cijepljenju, testiranju ili preboljenju. DCCG Pristupnik za EU digitalnu COVID potvrdu. Sustav za razmjenu DSC-ova među državama članicama. DCCGTA Certifikat temelj povjerenja DCCG-a. Odgovarajući privatni ključ koristi se za potpisivanje svih certifikata CSCA-ova izvan mrežnog okruženja. DCCGTLS TLS certifikat poslužitelja DCCG-a. DSC Potpisni certifikat za dokumente. Certifikat javnog ključa tijela potpisnika dokumenata države članice (npr. sustava koji smije potpisivati DCC-ove). Ovaj certifikat izdaje CSCA države članice. EC-DSA Algoritam za digitalno potpisivanje na temelju eliptičkih krivulja. Država članica Država članica Europske unije. mTLS Uzajamni TLS. TLS protokol s uzajamnom autentifikacijom. NB Nacionalni backend sustav države članice. NBCSCA Certifikat CSCA-a države članice (može postojati više od jednog CSCA-a). NBTLS Autentifikacijski TLS certifikat klijenta nacionalnog backend sustava. NBUP Certifikat koji nacionalni backend sustav koristi za potpisivanje podatkovnih paketa koji se šalju DCCG-u. PKI Infrastruktura javnih ključeva. Model povjerenja koji se temelji na certifikatima javnih ključeva i certifikacijskim tijelima. RSA Asimetrični kriptografski algoritam koji se temelji na rastavljanju na cjelobrojne faktore korišten za digitalne potpise ili asimetrično šifriranje.

3. Komunikacijski tokovi i sigurnosne usluge DCCG-a

Ovaj odjeljak je pregled komunikacijskih tokova i sigurnosnih usluga u DCCG-u. U njemu je također definirano koji se ključevi i certifikati koriste za zaštitu komunikacije, primljenih informacija, DCC-ova i potpisanog popisa povjerenja koji sadržava sve uvrštene certifikate CSCA-ova. DCCG funkcionira kao podatkovno čvorište na kojem države članice mogu razmjenjivati potpisane podatkovne pakete.

DCCG predaje primljene podatkovne pakete doslovno, tj. DCCG niti briše niti dodaje DSC-ove iz primljenih paketa. NB-ovi država članica moraju moći provjeravati cjelovitost i vjerodostojnost primljenih podataka u cijeloj komunikaciji. U tu svrhu nacionalni NB-ovi i DCCG koriste uzajamnu TLS autentifikaciju da uspostave sigurnu vezu. To je dodatna mjera uz potpise razmijenjenih podataka.

3.1. Autentifikacija i uspostava veze

DCCG koristi TLS s uzajamnom autentifikacijom za uspostavljanje autentificiranog šifriranog kanala između NB-a države članice i okruženja pristupnika. DCCG ima TLS certifikat poslužitelja, skraćeno DCCGTLS, a NB TLS certifikat klijenta, skraćeno NBTLS. Predlošci certifikata nalaze se u odjeljku 5. Svaki NB može dati vlastiti TLS certifikat. Taj certifikat bit će izričito naveden kao prihvatljiv pa ga može izdati certifikacijsko tijelo od javnog povjerenja (npr. certifikacijsko tijelo koje ispunjava osnovne zahtjeve konzorcija CA Browser Forum) ili nacionalno certifikacijsko tijelo, a može biti i samopotpisan. Svaka država članica odgovorna je za svoje nacionalne podatke i za zaštitu privatnog ključa kojim uspostavlja vezu s DCCG-om. Pristup „ponesi svoj certifikat” zahtijeva precizno definirane postupke registracije i identifikacije te povlačenja i obnavljanja, kako je opisano u odjeljcima 4.1., 4.2. i 4.3. DCCG koristi popis dopuštenih certifikata na koji se nakon uspješne registracije dodaju TLS certifikati NB-ova. Samo NB-ovi koji se autentificiraju privatnim ključem koji odgovara certifikatu s popisa dopuštenih certifikata mogu uspostaviti sigurnu vezu s DCCG-om. DCCG će također upotrebljavati TLS certifikat kojim će NB-ovi moći provjeriti da stvarno uspostavljaju vezu s „pravim” DCCG-om, a ne sa zlonamjernim subjektom koji se predstavlja kao DCCG. NB-ovi će dobiti certifikat DCCG-a nakon uspješne registracije. DCCGTLS izdaje CA od javnog povjerenja (takvi CA-ovi su prisutni u svim najvažnijim preglednicima). Države članice dužne su provjeriti da je njihova veza s DCCG-om sigurna (npr. uspoređivanjem kontrolnog otiska (fingerprint) certifikata DCCGTLS poslužitelja na koji su spojeni s onim koji su dobile nakon registracije).

3.2. Krovna nacionalna certifikacijska tijela za potpisivanje certifikata i model provjere

Države članice koje sudjeluju u okviru DCCG-a moraju koristiti CSCA za izdavanje DSC-ova. Države članice mogu imati više CSCA-ova, npr. ako prenose obveze na regionalnu razinu. Svaka država članica može ili koristiti postojeća certifikacijska tijela ili uspostaviti namjensko (moguće i samopotpisano) certifikacijsko tijelo za sustav za DCC.

Države članice moraju pokazati certifikate svojih CSCA-ova operateru DCCG-a tijekom službenog postupka početnog priključivanja. Nakon uspješne registracije države članice (vidjeti odjeljak 4.1. za više informacija) operater DCCG-a ažurira potpisani popis povjerenja koji sadržava sve certifikate CSCA-ova koji su aktivni u okviru za DCC. Operater DCCG-a potpisuje popis povjerenja i certifikate namjenskim asimetričnim parom ključeva u okruženju koje nije priključeno na mrežu. Privatni ključ ne smije biti pohranjen u sustavu DCCG-a priključenom na mrežu zato da kompromitiranje sustava priključenog na mrežu ne omogući napadaču da kompromitira popis povjerenja. Tijekom postupka priključivanja NB-ovi će dobiti odgovarajući certifikat temelj povjerenja DCCGTA.

Države članice mogu s DCCG-a preuzeti popis povjerenja za svoje postupke provjere. CSCA je definiran kao certifikacijsko tijelo koje izdaje DSC-ove pa države članice koje imaju višestupanjsku hijerarhiju certifikacijskih tijela (npr. vršno certifikacijsko tijelo -> CSCA -> DSC-ovi) moraju prijaviti podređeno certifikacijsko tijelo koje izdaje DSC-ove. U tom slučaju, ako država članica koristi postojeće certifikacijsko tijelo, sustav za DCC će zanemariti sve iznad razine CSCA-a i na dopušteni popis staviti samo CSCA kao temelj povjerenja (iako je riječ o podređenom certifikacijskom tijelu). To je zato što ICAO-ov model dopušta točno dvije razine – vršni CSCA i podređeni DCS koji je potpisao taj CSCA.

Ako država članica vodi vlastiti CSCA, njezina je odgovornost da to certifikacijsko tijelo radi i upravlja ključevima na siguran način. Budući da je CSCA temelj povjerenja za DSC-ove, zaštita privatnog ključa CSCA-a je ključna za cjelovitost okruženja za DCC. Model provjere u infrastrukturi javnih ključeva za DCC je tzv. model školjke u kojem svi certifikati u provjeri lanca certifikata moraju biti valjani u tom trenutku (tj. u trenutku provjere potpisa). To znači da postoje sljedeća ograničenja:

— CSCA ne smije izdavati certifikate koji istječu nakon certifikata samog certifikacijskog tijela,

— potpisnik dokumenta ne smije potpisati dokumente koji istječu nakon samog DSC-a,

— države članice koje vode vlastite CSCA-ove moraju definirati razdoblja valjanosti za svoje CSCA-ove i sve izdane certifikate te se pobrinuti za obnavljanje certifikata.

Odjeljak 4.2. sadržava preporuke za razdoblja valjanosti.

3.3. Cjelovitost i vjerodostojnost poslanih podataka

Nakon uspješne uzajamne autentifikacije NB-ovi mogu slati digitalno potpisane podatkovne pakete DCCG-u i preuzimati takve pakete od njega. U početku ti podatkovni paketi sadržavaju DSC-ove država članica. Par ključeva kojim NB digitalno potpisuje podatkovne pakete poslane u sustav DCCG-a zove se par ključeva nacionalnog backend sustava za slanje, a odgovarajući certifikat javnog ključa skraćen je kao certifikat NBUP. Svaka država članica ima vlastiti certifikat NBUP, koji može biti samopotpisan ili izdan od postojećeg certifikacijskog tijela (npr. certifikacijskog tijela koje izdaje certifikate u skladu s osnovnim zahtjevima konzorcija CAB-Forum). Certifikat NBUP mora se razlikovati od svih drugih certifikata koje država članica koristi (tj. od certifikata CSCA-a, TLS certifikata klijenta ili DSC-ova).

U postupku početne registracije (vidjeti odjeljak 4.1. za više informacija) države članice moraju operateru DCCG-a dostaviti certifikat za slanje. Svaka država članica odgovorna je za svoje nacionalne podatke i za zaštitu privatnog ključa kojim potpisuje poslane podatke.

Druge države članice mogu provjeriti potpisane podatkovne pakete certifikatima za slanje koje je dao DCCG. DCCG provjerava vjerodostojnost i cjelovitost poslanih podataka certifikatom NB-a za slanje prije nego što ih stavi na raspolaganje drugim državama članicama.

3.4. Zahtjevi za tehničku arhitekturu DCCG-a

Zahtjevi za tehničku arhitekturu DCCG-a su:

— DCCG koristi TLS s uzajamnom autentifikacijom za uspostavljanje autentificiranog šifriranog kanala s NB-ovima. DCCG zbog toga vodi dopušteni popis registriranih klijentskih certifikata NB TLS ,

— DCCG koristi dva digitalna certifikata (DCCG TLS i DCCG TA ) s dva različita para ključeva. Privatni ključ para ključeva DCCG TA čuva se izvan mrežnog okruženja (tj. nije na komponenti DCCG-a koja je povezana s mrežom),

— DCCG vodi popis povjerenja s certifikatima NB CSCA koji je potpisan privatnim ključem DCCG TA ,

— korištene šifre moraju ispunjavati zahtjeve iz odjeljka 5.1 .

4. Upravljanje životnim vijekom certifikata

4.1. Registracija nacionalnih backend sustava

Da bi se priključile u sustav DCCG-a, države članice moraju se registrirati kod operatera DCCG-a. U ovom je odjeljku opisan tehnički i operativni postupak za registraciju nacionalnog backend sustava.

Da bi proveli postupak priključivanja, operater DCCG-a i država članica moraju razmijeniti podatke za kontakt osoba za tehnička pitanja. Pretpostavlja se da su države članice ovlastile svoje osobe za tehnička pitanja i da se identifikacija/autentifikacija provodi drugim kanalima. Na primjer, autentifikacija se može obaviti tako što osoba za tehnička pitanja države članice e-poštom pošalje šifrirane datoteke s certifikatima pa telefonski javi odgovarajuću lozinku operateru DCCG-a. Mogu se upotrebljavati i drugi sigurni kanali koje odredi operater DCCG-a.

U registracijskom i identifikacijskom postupku država članica mora dostaviti tri certifikata:

— TLS certifikat države članice, NB TLS ,

— certifikat države članice za slanje, NB UP ,

— certifikate CSCA-ova države članice, NB CSCA .

Svi dostavljeni certifikati moraju ispunjavati zahtjeve iz odjeljka 5. Operater DCCG-a provjerava da dostavljeni certifikati ispunjavaju zahtjeve iz odjeljka 5. Nakon identifikacije i registracije operater DCCG-a:

— dodaje certifikate NB CSCA na popis povjerenja potpisan privatnim ključem koji odgovara javnom ključu DCCG TA ,

— dodaje certifikat NB TLS na dopušteni popis DCCG-ove krajnje točke TLS-a,

— dodaje certifikat NB UP u sustav DCCG-a,

— dostavlja certifikate javnih ključeva DCCG TA i DCCG TLS državi članici.

4.2. Certifikacijska tijela, razdoblja valjanosti i obnavljanje

Ako država članica želi voditi vlastiti CSCA, certifikati CSCA-a mogu biti samopotpisani. Ti certifikati su temelj povjerenja države članice pa država članica stoga mora snažno štititi privatni ključ koji odgovara javnom ključu certifikata CSCA-a. Preporučeno je da država članica za svoj CSCA koristi sustav izvan mrežnog okruženja, tj. računalni sustav koji nije priključen ni na kakvu mrežu. Pristup sustavu mora kontrolirati više osoba (npr. primjena načela četiri oka). Nakon potpisivanja DSC-ova primjenjuju se operativne kontrole pa se sustav s privatnim ključem CSCA-a sigurno pohranjuje uz stroge kontrole pristupa. Za dodatnu zaštitu privatnog ključa CSCA-a mogu se upotrebljavati hardverski sigurnosni moduli ili pametne kartice. Digitalni certifikati imaju razdoblje valjanosti zbog kojih je nužno obnavljanje certifikata. Obnavljanje je potrebno radi korištenja svježih kriptografskih ključeva i prilagođavanja duljina ključeva kad dođe do poboljšanja u računalstvu ili ako neki novi napad ugrozi sigurnost korištenog kriptografskog algoritma. Primjenjuje se model oklopa (vidjeti odjeljak 3.2.).

Preporučena su sljedeća razdoblja valjanosti, s obzirom na jednogodišnju valjanost digitalnih COVID potvrda:

— CSCA: 4 godine

— DSC: 2 godine

— certifikat za slanje: 1-2 godine

— autentifikacijski TLS certifikat klijenta: 1-2 godine

Preporučena su sljedeća razdoblja upotrebe radi pravodobnog obnavljanja:

— CSCA: 1 godina

— DSC: 6 mjeseci

Da bi zajamčile neprekidan rad, države članice moraju pravodobno generirati nove certifikate za slanje i TLS certifikate, npr. mjesec dana prije isteka. Certifikate CSCA-ova i DSC-ove trebalo bi obnavljati barem mjesec dana prije isteka upotrebe privatnog ključa (zbog potrebnih operativnih postupaka). Države članice moraju operateru DCCG-a dostaviti ažurirane certifikate CSCA-ova, certifikate za slanje i TLS certifikate. Istekli certifikati brišu se s popisa dopuštenih certifikata i popisa povjerenja.

Države članice i operater DCCG-a moraju pratiti valjanost vlastitih certifikata. Ne postoji središnji subjekt koji bi pratio valjanost certifikata pa obavještavao sudionike o isteku.

4.3. Povlačenje certifikata

Certifikacijsko tijelo izdavatelj u pravilu može povlačiti digitalne certifikate pomoću popisa povučenih certifikata ili responderima internetskog protokola za utvrđivanje statusa certifikata (OCSP). CSCA-ovi bi za potrebe sustava za DCC trebali dostavljati popise povučenih certifikata (CRL-ovi). Ako druge države članice trenutačno i ne koriste te CRL-ove, CRL-ovi bi trebali biti dio sustava zbog budućih primjena. Ako CSCA odluči ne dostavljati CRL-ove, DSC-ovi tog CSCA-a moraju se obnoviti kad CRL-ovi postanu obvezni. Vršitelji provjera ne bi trebali provjeravati DSC-ove OCSP-om nego na temelju CRL-ova. Preporučeno je da nacionalni backend sustav provede potrebne provjere DSC-ova preuzetih s pristupnika za DCC pa da nacionalnim vršiteljima provjere DCC-a proslijedi samo skup pouzdanih i provjerenih DSC-ova. Vršitelji provjera DCC-ova ne bi u svojim provjerama trebali provjeravati jesu li DSC-ovi povučeni. Među razlozima za to je zaštita privatnosti nositelja DCC-a izbjegavanjem svake mogućnosti da se određeni DSC možda prati odgovarajućim OCSP responderom.

Države članice mogu samostalno ukloniti svoje DSC-ove s DCCG-a valjanim certifikatima za slanje i TLS certifikatima. Uklanjanje DSC-a znači da svi DCC-ovi izdani tim DSC-om prestaju važiti kad države članice preuzmu ažurirane popise DSC-ova. Zaštita materijala privatnih ključeva koji odgovaraju DSC-ovima je od ključne važnosti. Države članice dužne su obavijestiti operatera DCCG-a ako moraju povući certifikate za slanje ili TLS certifikate, npr. zbog kompromitiranog nacionalnog backend sustava. Operater DCCG-a tad može povući povjerenje zahvaćenom certifikatu, npr. tako da ga ukloni s popisa dopuštenih TLS certifikata. Operater DCCG-a može ukloniti certifikate za slanje iz baze podataka DCCG-a. Paketi potpisani privatnim ključem koji odgovara tom certifikatu za slanje prestat će važiti kad nacionalni backend prestane imati povjerenje u povučeni certifikat za slanje. Ako se mora povući certifikat CSCA-a, države članice obavješćuju operatera DCCG-a i države članice s kojima su uspostavile odnos povjerenja. Operater DCCG-a izdat će novi popis povjerenja na kojem više nema zahvaćenog certifikata. Svi DSC-ovi koje je taj CSCA izdao prestaju važiti kad države članice ažuriraju svoju arhivu povjerenja u nacionalnom backend sustavu. Ako se mora povući certifikat DCCGTLS ili DCCGTA, operater DCCG-a i države članice moraju zajednički uspostaviti novu pouzdanu TLS vezu i novi popis povjerenja.

5. Predlošci certifikata

U ovom se odjeljku utvrđuju kriptografski zahtjevi i smjernice te zahtjevi za predloške certifikata. U ovom se odjeljku utvrđuju predlošci certifikata DCCG-a.

5.1. Kriptografski zahtjevi

Kriptografski algoritmi i skupovi šifri TLS-a odabiru se na temelju trenutačne preporuke njemačkog Saveznog ureda za informatičku sigurnost (BSI) ili SOG-IS-a. Te preporuke su slične preporukama drugih institucija i normizacijskih organizacija. Preporuke su dostupne u tehničkim smjernicama TR 02102-1 i TR 02102-2 ( 18 ) ili SOG-IS-ovom dokumentu Agreed Cryptographic Mechanisms ( 19 ).

5.1.1. Zahtjevi za DSC

Primjenjuju se zahtjevi iz odjeljka 3.2.2. Priloga I. Stoga je veoma preporučeno da potpisnici dokumenata koriste algoritam za digitalno potpisivanje na temelju eliptičkih krivulja (ECDSA) s NIST-p-256 (kako je definiran u Dodatku D norme FIPS PUB 186-4). Nisu podržane druge eliptičke krivulje. Zbog ograničenja prostora na DCC-u države članice ne bi trebale koristiti RSA-PSS, iako je dopušten kao pričuvni algoritam. Ako države članice koriste RSA-PSS, veličina modula bi trebala biti 2048 bita ili najviše 3072 bita. Kriptografska hash funkcija (vidjeti ISO/IEC 10118-3:2004) za potpis DSC-A je SHA-2 s izlaznom duljinom ≥ 256 bita.

5.1.2. Zahtjevi za TLS certifikate, certifikate za slanje i certifikate CSCA-ova

Za digitalne certifikate i kriptografske potpise u kontekstu DCCG-a pregled glavnih zahtjeva naveden je u sljedećoj tablici (od 2021.):







Potpisni algoritam Duljina ključa Hash funkcija EC-DSA najmanje 250 bita SHA-2 s izlaznom duljinom ≥ 256 bita RSA-PSS (preporučeno dopunjavanje) RSA-PKCS#1 v1.5 (prijašnje dopunjavanje) najmanje 3000 bitni RSA modul (N) s javnim eksponentom e > 2^16 SHA-2 s izlaznom duljinom ≥ 256 bita DSA najmanje 3000 bitni primarni broj p, 250 bitni ključ q SHA-2 s izlaznom duljinom ≥ 256 bita

Preporučena eliptička krivulja za EC-DSA je NIST-p-256 jer je njezina primjena veoma raširena.

5.2. Certifikat CSCA-a (NBCSCA)

U sljedećoj su tablici smjernice za predložak certifikata NBCSCA ako država članica odluči voditi vlastiti CSCA za sustav za DCC.

Ako je unos podebljan, obvezan je (mora biti u certifikatu), ako je u kurzivu, preporučen je (trebao bi biti u certifikatu). Ako polja nema, nema definiranih preporuka.







Polje Vrijednost Subject cn=<ne smije biti prazan, mora biti jedinstveno zajedničko ime>, o=<pružatelj>, c=<država članica koja vodi CSCA> Key usage potpisivanje certifikata, potpisivanje CRL-a (minimalno) Basic Constraints CA = true, path length constraints = 0

Ime subjekta ne smije biti prazno i mora biti jedinstveno u navedenoj državi članici. Oznaka zemlje (c) mora odgovarati državi članici koja će koristiti taj certifikat CSCA-a. Certifikat mora sadržavati jedinstveni identifikator ključa subjekta (SKI) u skladu s RFC-om 5280 ( 20 ).

5.3. Potpisni certifikat za dokumente (DSC)

U sljedećoj su tablici smjernice za DSC. Ako je unos podebljan, obvezan je (mora biti u certifikatu), ako je u kurzivu, preporučen je (trebao bi biti u certifikatu). Ako polja nema, nema definiranih preporuka.







Polje Vrijednost Serial Number jedinstveni serijski broj Subject cn=<ne smije biti prazan, mora biti jedinstveno zajedničko ime>, o=<pružatelj>, c=<država članica koja koristi ovaj DSC> Key Usage digitalni potpis (minimalno)

DSC mora biti potpisan privatnim ključem koji odgovara certifikatu CSCA-a koji koristi država članica.

Treba koristiti sljedeća proširenja:

— certifikat mora sadržavati identifikator ključa tijela (AKI) koji odgovara identifikatoru ključa subjekta (SKI) certifikata CSCA-a izdavatelja,

— certifikat treba sadržavati jedinstveni identifikator ključa subjekta (SKI) u skladu s RFC-om 5280 ( 21 ).

Certifikat bi uz to trebao sadržavati proširenje za distribucijsku točku CRL-a koja pokazuje popis povučenih certifikata (CRL) koji je dostavio CSCA koji je izdao DSC.

DSC može sadržavati proširenje proširene upotrebe ključa s identifikatorima pravila za proširenu upotrebu ključa koja ograničavaju vrste HCERT-ova koji se smiju provjeriti ovim certifikatom; to proširenje ne mora imati nijedan takav identifikator. Ako je neki identifikator prisutan, vršitelji provjere provjeravaju upotrebu ključa s obzirom na pohranjeni HCERT. U tu svrhu su definirane sljedeće vrijednosti extendedKeyUsage:







Polje Vrijednost extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 za izdavatelje potvrda o testiranju extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 za izdavatelje potvrda o cijepljenju extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 za izdavatelje potvrda o preboljenju

Ako nema nijednog proširenja upotrebe ključa (tj. proširenja nema ili je proširenje nulto), na temelju ovog certifikata može se provjeriti valjanost svake vrste HCERT-a. Moguće je da se u drugim dokumentima definiraju dodatni identifikatori pravila za proširenu upotrebu ključa koji se koriste za provjeru HCERT-ova.

5.4. Certifikati za slanje (NBUP)

U sljedećoj su tablici smjernice za certifikate za slanje nacionalnih backend sustava. Ako je unos podebljan, obvezan je (mora biti u certifikatu), ako je u kurzivu, preporučen je (trebao bi biti u certifikatu). Ako polja nema, nema definiranih preporuka.







Polje Vrijednost Subject cn=<ne smije biti prazan, mora biti jedinstveno zajedničko ime>, o=<pružatelj>, c=<država članica koja koristi ovaj certifikat za slanje> Key Usage digitalni potpis (minimalno)

5.5. Autentifikacijski TLS certifikat klijenta nacionalnog backend sustava (NBTLS)

U sljedećoj su tablici smjernice za autentifikacijski TLS certifikat klijenta nacionalnih backend sustava. Ako je unos podebljan, obvezan je (mora biti u certifikatu), ako je u kurzivu, preporučen je (trebao bi biti u certifikatu). Ako polja nema, nema definiranih preporuka.







Polje Vrijednost Subject cn=<ne smije biti prazan, mora biti jedinstveno zajedničko ime>, o=<pružatelj>, c=<država članica NB-a> Key Usage digitalni potpis (minimalno) Extended key usage autentifikacija klijenta (1.3.6.1.5.5.7.3.2)

Certifikat može sadržavati proširenu upotrebu ključa autentifikacija poslužitelja (1.3.6.1.5.5.7.3.1), ali to nije obvezno.

5.6. Potpisni certifikat popisa povjerenja (DCCGTA)

U sljedećoj je tablici definiran certifikat temelj povjerenja DCCG-a.







Polje Vrijednost Subject cn = Digital Green Certificate Gateway (1) , o=<pružatelj>, c=<zemlja> Key Usage digitalni potpis (minimalno) ( 1 ) Termin „digitalna zelena potvrda” je zadržana u ovom kontekstu umjesto „EU digitalne COVID potvrde” jer je termin upisan u kod i primijenjen u certifikatu prije nego što su suzakonodavci odlučili o novom terminu.

5.7. DCCG-ovi TLS certifikati poslužitelja (DCCGTLS)

U sljedećoj je tablici definiran TLS certifikat DCCG-a.







Polje Vrijednost Subject cn=<FQDN ili IP adresa DCCG-a>, o=<pružatelj>, c= <zemlja> SubjectAltName dNSName: <DCCG DNS name> ili iPAddress: <DCCG IP address> Key Usage digitalni potpis (minimalno) Extended key usage autentifikacija poslužitelja (1.3.6.1.5.5.7.3.1)

Certifikat može sadržavati proširenu upotrebu ključa client authentication (1.3.6.1.5.5.7.3.2.), ali to nije obvezno.

TLS certifikat DCCG-a izdaje certifikacijsko tijelo od javnog povjerenja (takav CA je prisutan u svim najvažnijim preglednicima i operativnim sustavima, u skladu s osnovnim zahtjevima konzorcija CA Browser Forum).

▼M1









PRILOG V.

JSON (JAVASCRIPT OBJECT NOTATION) SHEMA

1. Uvod

U ovom se Prilogu utvrđuje tehnička struktura podataka za EU digitalne COVID potvrde (EUDCC) u obliku JSON sheme. U dokumentu su utvrđene posebne upute za pojedinačna podatkovna polja.

2. Mjesto i verzije JSON sheme

Mjerodavna službena JSON shema za EUDCC dostupna je na adresi https://github.com/ehn-dcc-development/ehn-dcc-schema. Druga mjesta nisu mjerodavna, ali se mogu upotrebljavati za pripremu budućih revizija.

Na navedenom URL-u automatski se prikazuje trenutačna verzija, kako je utvrđena u ovom Prilogu, koju podržavaju sve zemlje koje trenutačno koriste sustav.

Sljedeća verzija, koju će sve zemlje podržavati od zadanog datuma, prikazana je ispod navedenog URL-a oznakom verzije i detaljnije objašnjena u datoteci Readme.

▼M3

3. Zajedničke strukture i opći zahtjevi

EU digitalna COVID potvrda ne smije se izdati ako se zbog podataka koji nedostaju sva podatkovna polja ne mogu popuniti ispravno u skladu sa specifikacijama. To ne utječe na obvezu država članica da izdaju EU digitalne COVID potvrde.

Podaci u svim poljima mogu biti uneseni s punim skupom znakova u skladu s normom UNICODE 13.0 kodirani u UTF-8, osim ako nisu izričito ograničeni na skup vrijednosti ili ograničeniji skup znakova.

Zajednička struktura je:

„JSON”:{

„ver”:<version information>,

„nam”:{

<person name information>

},

„dob”:<date of birth>,

„v” or „t” or „r”:[

{<vaccination dose or test or recovery information, one entry>}

]

}

U sljedećem odjeljku nalaze se detaljne informacije o pojedinačnim skupinama i poljima.

Ako bi prema pravilu polje trebalo preskočiti, to znači da je njegov sadržaj prazan i da u sadržaju ne smiju biti ni ime ni vrijednost polja.

3.1. Verzija

Mora se navesti verzija. Označavanje verzija mora biti u skladu sa semantičkim označavanjem verzija (semver: https://semver.org). U radnom sustavu verzija je jedna od službeno objavljenih verzija (trenutačna verzija ili neka od prethodnih službeno objavljenih verzija). Za dodatne informacije vidjeti odjeljak Mjesto JSON sheme.







Identifikator polja Ime polja Upute ver Verzija sheme Ova vrijednost mora biti jednaka identifikatoru verzije sheme na temelju koje je EUDCC izrađen. Primjer: „ver”:„1.3.0”

3.2. Ime osobe i datum rođenja

Ime osobe je službeno puno ime osobe, kako je napisano u putnim ispravama. Identifikator strukture je nam. Mora postojati točno jedno (1) ime osobe.







Identifikator polja Ime polja Upute nam/fn Prezime (prezimena) Prezimena nositelja. Ako nositelj nema prezimena, ali ima ime, ovo se polje može preskočiti. U svim ostalim slučajevima mora postojati točno jedno (1) polje koje nije prazno i koje sadržava sva prezimena. Ako osoba ima više od jednog prezimena, prezimena moraju biti razdvojena razmakom (bjelinom). Kombinacije imena sa spojnicama ili sličnim znakovima ne smiju se mijenjati. Primjeri: „fn”:”Musterfrau-Gößinger” „fn”:”Musterfrau-Gößinger Müller” nam/fnt Standardizirano prezime (standardizirana prezimena) Prezimena nositelja transliterirana u skladu s pravilima koja su primijenjena za nositeljeve strojno čitljive putne isprave (npr. pravila iz dijela 3. dokumenta ICAO-a br. 9303). Ako nositelj nema prezimena, ali ima ime, ovo se polje može preskočiti. U svim ostalim slučajevima mora postojati točno jedno (1) polje koje nije prazno i koje sadržava samo znakove A-Z i <. Najveća duljina: 80 znakova (u skladu sa specifikacijom iz dokumenta ICAO-a br. 9303). Primjeri: „fnt”:”MUSTERFRAU<GOESSINGER” „fnt”:”MUSTERFRAU<GOESSINGER<MUELLER” nam/gn Ime (imena) Imena nositelja. Ako nositelj nema imena, ali ima prezime, ovo se polje može preskočiti. U svim ostalim slučajevima mora postojati točno jedno (1) polje koje nije prazno i koje sadržava sva imena. Ako osoba ima više od jednog imena, imena moraju biti razdvojena razmakom (bjelinom). Primjer: „gn”:”Isolde Erika” nam/gnt Standardizirano ime (standardizirana imena) Imena nositelja transliterirana u skladu s pravilima koja su primijenjena za nositeljeve strojno čitljive putne isprave (npr. pravila iz dijela 3. dokumenta ICAO-a br. 9303). Ako nositelj nema imena, ali ima prezime, ovo se polje može preskočiti. U svim ostalim slučajevima mora postojati točno jedno (1) polje koje nije prazno i koje sadržava samo znakove A-Z i <. Najveća duljina: 80 znakova. Primjer: „gnt”:”ISOLDE<ERIKA” dob Datum rođenja Datum rođenja imatelja DCC-a. Cijeli ili djelomični datum, bez vremena, ograničen na raspon od 1900-01-01 do 2099-12-31. Mora postojati točno jedno (1) polje koje nije prazno ako je poznat cijeli ili djelomični datum rođenja. Ako datum rođenja nije poznat ni djelomično, polje je prazan niz, „”. Sadržaj polja trebao bi biti jednak podacima na putnim ispravama. Ako je datum rođenja dostupan, koristi se jedan od sljedećih formata iz norme ISO 8601. Nisu dopuštene druge opcije. GGGG-MM-DD GGGG-MM GGGG (Aplikacija vršitelj provjere može prikazati dijelove datuma rođenja koji nedostaju koristeći konvenciju XX, koja se koristi u strojno čitljivim putnim ispravama, npr. 1990-XX-XX.) Primjeri: „dob”:”1979-04-14” „dob”:”1901-08” „dob”:”1939” „dob”:

3.3. Skupine za podatke specifične za vrstu potvrde

JSON shema podržava tri skupine unosa koji obuhvaćaju podatke specifične za vrstu potvrde. Svaki EUDCC sadržava točno jednu (1) skupinu. Nisu dopuštene prazne skupine.







Identifikacijska oznaka skupine Ime skupine Unosi v Skupina „cijepljenje” Ako postoji, sadržava točno jedan (1) unos koji opisuje točno jednu (1) dozu cjepiva. t Skupina „test” Ako postoji, sadržava točno jedan (1) unos koji opisuje točno jedan (1) rezultat testa. r Skupina „preboljenje” Ako postoji, sadržava točno jedan (1) unos koji opisuje točno jednu (1) izjavu o preboljenju.

▼M1

4. Podaci specifični za vrstu potvrde

4.1. Potvrda o cijepljenju

Skupina „cijepljenje”, ako postoji, sadržava točno jedan (1) unos koji opisuje jedan čin cijepljenja (jednu dozu). Svi su elementi skupine „cijepljenje” obvezni, a prazne vrijednosti nisu dopuštene.







Identifikator polja Ime polja Upute v/tg bolest ili agens protiv kojeg je namijenjeno: COVID-19 (SARS-CoV ili neka od njegovih varijanti) Kodirana vrijednost iz skupa vrijednosti disease-agent-targeted.json. Ovaj skup vrijednosti ima točno jedan unos, 840539006, a to je kôd za COVID-19 prema kodnom sustavu SNOMED CT (GPS). Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "tg":"840539006" v/vp cjepivo ili profilaksa protiv bolesti COVID-19 Vrsta primijenjenog cjepiva ili profilakse. Kodirana vrijednost iz skupa vrijednosti vaccine-prophylaxis.json. Vrijednost se distribuira iz pristupnika za EUDCC. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "vp":"1119349007" (mRNA cjepivo protiv virusa SARS-CoV-2) v/mp lijek (cjepivo) protiv bolesti COVID-19 Cjepivo u ovoj dozi cijepljenja. Kodirana vrijednost iz skupa vrijednosti vaccine-medicinal-product.json. Vrijednost se distribuira iz pristupnika za EUDCC. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "mp":"EU/1/20/1528" (Comirnaty) v/ma nositelj odobrenja za stavljanje u promet cjepiva protiv bolesti COVID-19 ili proizvođač tog cjepiva Nositelj odobrenja za stavljanje u promet ili, ako nema nositelja odobrenja za stavljanje u promet, proizvođač. Kodirana vrijednost iz skupa vrijednosti vaccine-mah-manf.json. Vrijednost se distribuira iz pristupnika za EUDCC. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "ma":"ORG-100030215" (Biontech Manufacturing GmbH) v/dn broj doze u seriji doza Uzastopni broj (pozitivan cijeli broj) doze primljene u ovom činu cijepljenja. 1 za prvu dozu, 2 za drugu dozu itd. Detaljnija pravila utvrđena su u odjeljku 5. Priloga II. Mora postojati točno jedno (1) polje koje nije prazno. Primjeri: "dn":"1" (prva doza) "dn":"2" (druga doza) "dn":"3" (treća doza) v/sd ukupni broj doza u seriji Ukupni broj doza (pozitivan cijeli broj) u seriji cjepiva. Detaljnija pravila utvrđena su u odjeljku 5. Priloga II. Mora postojati točno jedno (1) polje koje nije prazno. Primjeri: "sd":"1" (u slučaju primarne serije cjepiva s 1 dozom) "sd":"2" (u slučaju primarne serije cjepiva s 2 doze ili u slučaju dodatne doze nakon primarne serije cjepiva s 1 dozom) "sd":"3" (npr. u slučaju dodatnih doza nakon primarne serije cjepiva s 2 doze) v/dt datum cijepljenja Datum primitka opisane doze u formatu YYYY-MM-DD (cijeli datum, bez vremena). Nisu dopušteni drugi formati. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "dt":"2021-03-28" v/co država članica ili treća zemlja u kojoj je cjepivo primljeno Zemlja navedena dvoslovnom oznakom u skladu s normom ISO 3166 (PREPORUČENO) ili upućivanje na međunarodnu organizaciju odgovornu za čin cijepljenja (kao što je UNHCR ili Svjetska zdravstvena organizacija). Kodirana vrijednost iz skupa vrijednosti country-2-codes.json. Vrijednost se distribuira iz pristupnika za EUDCC. Mora postojati točno jedno (1) polje. Primjer: "co":"CZ" "co":"UNHCR" v/is izdavatelj potvrde Ime organizacije koja je izdala potvrdu. Dopušteno je uvrstiti identifikator kao dio imena, ali nije preporučeno koristiti samo identifikatore bez imena u tekstualnom obliku. Najviše 80 znakova kodiranih u UTF-8. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "is":"Ministry of Health of the Czech Republic" "is":"Vaccination Centre South District 3" v/ci jedinstveni identifikator potvrde Jedinstveni identifikator potvrde (UVCI), u skladu s dokumentom https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf Dodavanje kontrolnog zbroja nije obvezno. Prefiks "URN:UVCI:" smije se dodati. Mora postojati točno jedno (1) polje koje nije prazno. Primjeri: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2. Potvrda o testiranju

Skupina „test”, ako postoji, sadržava točno jedan (1) unos koji opisuje točno jedan (1) rezultat testa.







Identifikator polja Ime polja Upute t/tg bolest ili agens protiv kojeg je namijenjeno: COVID-19 (SARS-CoV ili neka od njegovih varijanti) Kodirana vrijednost iz skupa vrijednosti disease-agent-targeted.json. Ovaj skup vrijednosti ima točno jedan unos, 840539006, a to je kôd za COVID-19 prema kodnom sustavu SNOMED CT (GPS). Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "tg":"840539006" t/tt vrsta testa Vrsta korištenog testa na temelju materijala koji se testom traži. Kodirana vrijednost iz skupa vrijednosti test-type.json (na temelju LOINC-a). Nisu dopuštene vrijednosti koje nisu u skupu vrijednosti. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "tt":"LP6464-4" (umnažanje nukleinske kiseline s detekcijom sondi) "tt":"LP217198-3" (brzi imunološki test) t/nm naziv testa (samo za testove koji se temelje na umnažanju nukleinske kiseline) Naziv korištenog testa koji se temelji na umnažanju nukleinske kiseline (NAAT). Naziv bi trebao sadržavati ime proizvođača i trgovačko ime testa, razdvojene zarezom. Za NAAT: ovo polje nije obvezno. Za RAT: ovo se polje ne koristi jer se naziv testa neizravno dobiva iz identifikatora proizvoda za testiranje (t/ma). Ako je podatak dostavljen, polje ne smije biti prazno. Primjer: "nm":"ELITechGroup, SARS-CoV-2 ELITe MGB® Kit" t/ma identifikator proizvoda za testiranje (samo za brze antigenske testove) Identifikator proizvoda za testiranje brzim antigenskim testom (RAT) iz JRC-ove baze podataka. Skup vrijednosti (HSC-ov zajednički popis): — svi brzi antigenski test na HSC-ovu zajedničkom popisu (format čitljiv čovjeku). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (strojno čitljiv, vrijednosti polja id_device uvrštene na popis iz skupa vrijednosti). U zemljama EU-a/EGP-a izdavatelji izdaju potvrde samo za testove iz trenutačno važećeg skupa vrijednosti. Skup vrijednosti ažurira se svaka 24 sata. Vrijednosti koje nisu u skupu vrijednosti smiju se koristiti u potvrdama koje izdaju treće zemlje, ali identifikatori moraju biti iz JRC-ove baze podataka. Nije dopušteno korištenje drugih identifikatora, npr. onih koje je izravno dao proizvođač testa. Vršitelji provjere moraju detektirati vrijednosti koje nisu u ažurnom skupu vrijednosti i za potvrde s tim vrijednostima pokazati da nisu valjane. Ako se identifikator ukloni iz skupa vrijednosti, potvrde s tim identifikatorom mogu se prihvaćati najviše 72 sata od datuma uklanjanja. Vrijednost se distribuira iz pristupnika za EUDCC. Za RAT: mora postojati točno jedno (1) polje koje nije prazno. Za NAAT: ovo se polje ne koristi, čak i ako je identifikator NAAT testa prisutan u JRC-ovoj bazi podataka. Primjer: "ma":"344" (SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc datum i vrijeme uzimanja uzorka Datum i vrijeme uzimanja uzorka. Vrijeme mora sadržavati vremensku zonu. Ova vrijednost nije vrijeme kad je dobiven rezultat testa. Mora postojati točno jedno (1) polje koje nije prazno. Koristi se jedan od sljedećih formata iz norme ISO 8601. Nisu dopuštene druge opcije. YYYY-MM-DDThh:mm:ssZ YYYY-MM-DDThh:mm:ss[+-]hh YYYY-MM-DDThh:mm:ss[+-]hhmm YYYY-MM-DDThh:mm:ss[+-]hh:mm Primjeri: "sc":"2021-08-20T10:03:12Z" (UTC) "sc":"2021-08-20T12:03:12+02" (CEST) "sc":"2021-08-20T12:03:12+0200" (CEST) "sc":"2021-08-20T12:03:12+02:00" (CEST) t/tr rezultat testa Rezultat testa. Kodirana vrijednost iz skupa vrijednosti test-result.json (prema kodnom sustavu SNOMED CT, GPS). Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "tr":"260415000" (nije otkriveno) t/tc centar ili objekt za testiranje Ime subjekta koji je proveo ispitivanje. Dopušteno je uvrstiti identifikator kao dio imena, ali nije preporučeno koristiti samo identifikatore bez imena u tekstualnom obliku. Najviše 80 znakova kodiranih u UTF-8. Svi suvišni znakovi u nizu trebali bi se odbaciti. Ime nije predviđeno za automatsku provjeru. Za NAAT testove: mora postojati točno jedno (1) polje koje nije prazno. Za RAT testove: ovo polje nije obvezno. Ako postoji, ne smije biti prazno. Primjer: "tc":"Test centre west region 245" t/co država članica ili treća zemlja u kojoj je obavljeno testiranje Zemlja navedena dvoslovnom oznakom u skladu s normom ISO 3166 (PREPORUČENO) ili upućivanje na međunarodnu organizaciju odgovornu za obavljanje testiranja (kao što je UNHCR ili Svjetska zdravstvena organizacija). Kodirana vrijednost iz skupa vrijednosti country-2-codes.json. Vrijednost se distribuira iz pristupnika za EUDCC. Mora postojati točno jedno (1) polje. Primjeri: "co":"CZ" "co":"UNHCR" t/is izdavatelj potvrde Ime organizacije koja je izdala potvrdu. Dopušteno je uvrstiti identifikator kao dio imena, ali nije preporučeno koristiti samo identifikatore bez imena u tekstualnom obliku. Najviše 80 znakova kodiranih u UTF-8. Mora postojati točno jedno (1) polje koje nije prazno. Primjeri: "is":"Ministry of Health of the Czech Republic" "is":"North-West region health authority" t/ci jedinstveni identifikator potvrde Jedinstveni identifikator potvrde (UVCI), u skladu s dokumentom vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Dodavanje kontrolnog zbroja nije obvezno. Prefiks "URN:UVCI:" smije se dodati. Mora postojati točno jedno (1) polje koje nije prazno. Primjeri: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.3. Potvrda o preboljenju

Skupina „preboljenje”, ako postoji, sadržava točno jedan (1) unos koji opisuje točno jednu (1) izjavu o preboljenju. Svi su elementi skupine „preboljenje” obvezni, a prazne vrijednosti nisu dopuštene.







Identifikator polja Ime polja Upute r/tg bolest ili agens koji je nositelj prebolio: COVID-19 (SARS-CoV-2 ili neka od njegovih varijanti) Kodirana vrijednost iz skupa vrijednosti disease-agent-targeted.json. Ovaj skup vrijednosti ima točno jedan unos, 840539006, a to je kôd za COVID-19 prema kodnom sustavu SNOMED CT (GPS). Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "tg":"840539006" r/fr datum prvog pozitivnog rezultata testa NAAT nositelja Datum na koji je uzet uzorak za koji je u testu NAAT dobiven pozitivan rezultat u formatu YYYY-MM-DD (cijeli datum, bez vremena). Nisu dopušteni drugi formati. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "fr":"2021-05-18" r/co država članica ili treća zemlja u kojoj je obavljeno testiranje Zemlja navedena dvoslovnom oznakom u skladu s normom ISO 3166 (PREPORUČENO) ili upućivanje na međunarodnu organizaciju odgovornu za obavljanje testiranja (kao što je UNHCR ili Svjetska zdravstvena organizacija). Kodirana vrijednost iz skupa vrijednosti country-2-codes.json. Vrijednost se distribuira iz pristupnika za EUDCC. Mora postojati točno jedno (1) polje. Primjeri: "co":"CZ" "co":"UNHCR" r/is izdavatelj potvrde Ime organizacije koja je izdala potvrdu. Dopušteno je uvrstiti identifikator kao dio imena, ali nije preporučeno koristiti samo identifikatore bez imena u tekstualnom obliku. Najviše 80 znakova kodiranih u UTF-8. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "is":"Ministry of Health of the Czech Republic" "is":"Central University Hospital" r/df početak valjanosti potvrde Prvi datum od kojeg se potvrda smatra valjanom. Datum ne smije biti ranije od datuma izračunanog iz r/fr + 11 dana. Datum mora biti u formatu YYYY-MM-DD (cijeli datum, bez vremena). Nisu dopušteni drugi formati. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "df":"2021-05-29" r/du istek valjanosti potvrde Posljednji datum na koji se potvrda smatra valjanom, koji dodjeljuje izdavatelj potvrde. Datum ne smije biti iza datuma izračunanog iz r/fr + 180 dana. Datum mora biti u formatu YYYY-MM-DD (cijeli datum, bez vremena). Nisu dopušteni drugi formati. Mora postojati točno jedno (1) polje koje nije prazno. Primjer: "du":"2021-11-14" r/ci jedinstveni identifikator potvrde Jedinstveni identifikator potvrde (UVCI), u skladu s dokumentom vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Dodavanje kontrolnog zbroja nije obvezno. Prefiks "URN:UVCI:" smije se dodati. Mora postojati točno jedno (1) polje koje nije prazno. Primjeri: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

▼M3









PRILOG VI.

ODGOVORNOSTI DRŽAVA ČLANICA KAO ZAJEDNIČKIH VODITELJA OBRADE ZA PRISTUPNIK ZA EU DIGITALNU COVID POTVRDU U POGLEDU RAZMJENE POPISA OPOZVANIH EU DIGITALNIH COVID POTVRDA

ODJELJAK 1.

Pododjeljak 1.

Podjela odgovornosti

(1) Zajednički voditelji obrade obrađuju osobne podatke putem pristupnika unutar okvira povjerenja u skladu s tehničkim specifikacijama iz Priloga I.

(2) Izdavatelji država članica ostaju jedini voditelj obrade za prikupljanje, upotrebu, otkrivanje i svaku drugu obradu informacija o opozivu izvan pristupnika, uključujući postupak za opoziv potvrde.

(3) Svaki voditelj obrade odgovoran je za obradu osobnih podataka u pristupniku unutar okvira povjerenja u skladu s člancima 5., 24. i 26. Opće uredbe o zaštiti podataka.

(4) Svaki voditelj obrade uspostavlja kontaktnu točku sa zajedničkom e-adresom za komunikaciju među zajedničkim voditeljima obrade te između zajedničkih voditelja obrade i izvršitelja obrade.

(5) Radna skupina koju osnuje odbor iz članka 14. Uredbe (EU) 2021/953 ovlaštena je za odlučivanje o svim pitanjima koja proizlaze iz razmjene popisa opozvanih potvrda i iz zajedničkog vođenja povezane obrade osobnih podataka te za olakšavanje davanja koordiniranih uputa Komisiji kao izvršitelju obrade. Ta radna skupina upravlja postupkom donošenja odluka zajedničkih voditelja obrade i uređuje ga poslovnikom koji donese. Osnovno je pravilo da se smatra da svaki zajednički voditelj obrade koji pisano najavi najmanje sedam (7) dana unaprijed da ne namjerava sudjelovati na nekom sastanku radne skupine prešutno pristaje na ishode tog sastanka na kojem ne sudjeluje. Svaki zajednički voditelj obrade može sazvati sastanak radne skupine.

(6) Izvršitelju obrade upute šalje bilo koja kontaktna točka zajedničkih voditelja obrade u dogovoru s drugim zajedničkim voditeljima obrade u skladu s postupkom iz točke (5) kojim radna skupina donosi odluke. Zajednički voditelj obrade koji daje upute trebao bi ih napismeno dati izvršitelju obrade i o tome obavijestiti sve druge zajedničke voditelje obrade. Ako je tema dovoljno hitna da nije moguće sazvati sastanak radne skupine u skladu s točkom (5), svejedno se mogu dati upute, ali te upute radna skupina može povući. Te se upute daju u pisanom obliku, o čemu se u trenutku davanja uputa obavješćuju svi drugi zajednički voditelji obrade.

(7) Radna skupina uspostavljena u skladu s točkom (5) ne oslobađa nijednog zajedničkog voditelja obrade od pojedinačne odgovornosti da izvješćuje svoje nadležno nadzorno tijelo u skladu s člancima 33. i 24. Opće uredbe o zaštiti podataka. Za takvo izvješćivanje nije potrebna suglasnost nijednog drugog zajedničkog voditelja obrade.

(8) U području primjene pristupnika unutar okvira povjerenja razmijenjenim osobnim podacima smiju pristupati samo osobe koje su za to ovlastila imenovana nacionalna tijela ili službena tijela.

(9) Svaki izdavatelj vodi evidenciju aktivnosti obrade za koje je odgovoran. Zajedničko vođenje može se navesti u evidenciji.

Pododjeljak 2.

Odgovornosti i uloge za obradu zahtjeva i obavješćivanje ispitanikâ

(1) U skladu s člankom 14. Opće uredbe o zaštiti podataka svaki voditelj obrade u okviru svoje uloge izdavatelja daje fizičkim osobama čije je potvrde opozvao („ispitanici”) informacije o tom opozivu i obradi njihovih osobnih podataka u pristupniku za EU digitalnu COVID potvrde za potrebe razmjene popisa opozvanih potvrda osim ako se to pokaže nemogućim ili bi za to bio potreban nerazmjeran trud.

(2) Svaki je voditelj obrade kontaktna točka za fizičke osobe čiju je potvrdu opozvao i obrađuje zahtjeve koje su podnijeli ispitanici ili njihovi predstavnici u okviru ostvarivanja svojih prava u skladu s Općom uredbom o zaštiti podataka. Zajednički voditelj obrade koji primi ispitanikov zahtjev koji se odnosi na potvrdu koju je izdao drugi zajednički voditelj obrade obavješćuje ispitanika o identitetu i podacima za kontakt tog odgovornog zajedničkog voditelja obrade. Ako to zatraži drugi zajednički voditelj obrade, zajednički voditelji obrade međusobno si pomažu u obradi zahtjeva ispitanika i jedni drugima odgovaraju bez nepotrebne odgode, a najkasnije u roku od mjesec dana od primitka zahtjeva za pomoć. Ako se zahtjev odnosi na podatke koje je dostavila treća zemlja, voditelj obrade koji primi taj zahtjev obrađuje ga i obavješćuje ispitanika o identitetu i podacima za kontakt izdavatelja iz te treće zemlje.

(3) Svaki voditelj obrade ispitanicima stavlja na raspolaganje sadržaj ovog Priloga, uključujući postupke utvrđene u točkama 1. i 2.

ODJELJAK 2.

Upravljanje sigurnosnim incidentima, uključujući povrede osobnih podataka

(1) Zajednički voditelji obrade međusobno si pomažu u utvrđivanju i rješavanju sigurnosnih incidenata, uključujući povrede osobnih podataka, povezanih s obradom u pristupniku za EU digitalnu COVID potvrdu.

(2) Zajednički voditelji obrade međusobno se obavješćuju o:

(a) svim potencijalnim ili stvarnim rizicima za dostupnost, povjerljivost i/ili cjelovitost osobnih podataka koji se obrađuju u pristupniku unutar okvira povjerenja;

(b) svakoj povredi osobnih podataka, vjerojatnim posljedicama povrede osobnih podataka i procjeni rizika za prava i slobode pojedinaca te svim mjerama poduzetima za rješavanje povrede osobnih podataka i ublažavanje rizika za prava i slobode pojedinaca;

(c) svakom kršenju tehničkih i/ili organizacijskih zaštitnih mjera postupka obrade u pristupniku unutar okvira povjerenja.

(3) Zajednički voditelji obrade o svim povredama osobnih podataka povezanima s postupkom obrade u pristupniku unutar okvira povjerenja obavješćuju Komisiju, nadležna nadzorna tijela i, prema potrebi, ispitanike u skladu s člancima 33. i 34. Opće uredbe o zaštiti podataka ili nakon obavijesti Komisije.

(4) Svaki izdavatelj provodi odgovara