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

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

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.

---

(1)  rfc8392 (ietf.org)

(2)  rfc8152 (ietf.org)

(3)  rfc8230 (ietf.org)

(4)  rfc8392 (ietf.org)

(5)  rfc8392 (ietf.org)

(6)  rfc7159 (ietf.org)

(7)  rfc7049 (ietf.org)

(8)  Uredba (EU) 2021/953 Europskog parlamenta i Vijeća od 14. lipnja 2021. o okviru za izdavanje, provjeru i prihvaćanje interoperabilnih potvrda o cijepljenju, testiranju i preboljenju bolesti COVID-19 (EU digitalna COVID potvrda) radi olakšavanja slobodnog kretanja tijekom pandemije bolesti COVID-19, SL L 211, 15.6.2021., str. 1.

(9)  rfc1950 (ietf.org)

(10)  rfc1951 (ietf.org)

(11)  rfc7517 (ietf.org)

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 DCC-a. Elementi iz ovog Priloga mogu se upotrebljavati za tri različite vrijednosti (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.

Za sva podatkovna polja koja nisu navedena u sljedećim opisima skupova vrijednosti preporučeno je da budu kodirana u UTF-8 (ime, centar za testiranje, izdavatelj potvrde). Za podatkovna polja koja sadržavaju datume (datum rođenja, datum uzimanja uzorka, datum prvog pozitivnog rezultata testa, datumi valjanosti potvrde) preporučeno je da budu kodirana u skladu s normom ISO 8601.

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

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

Komisija je uz potporu mreže e-zdravstva i Odbora za zdravstvenu sigurnost dužna redovito ažurirati te skupove vrijednosti. Ažurirani skupovi vrijednosti objavljuju se na odgovarajućim internetskim stranicama Komisije i na internetskim stranicama mreže e-zdravstva. Na raspolaganju bi trebala postojati evidencija promjena.

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

Najpoželjniji kodni sustav: SNOMED CT.

Za upotrebu u potvrdi 1, 2 i 3.

Odabrani kodovi odnose se na COVID-19 ili, ako su potrebni detaljniji podaci o genetskoj varijanti virusa SARS-CoV-2, na te varijante ako su zbog epidemioloških razloga potrebne tako detaljni podaci.

Primjer koda koji bi trebalo koristiti je, za kod SNOMED CT, 840539006 (COVID-19).

2.   Cjepivo ili profilaksa protiv bolesti COVID-19

Najpoželjniji kodni sustav: SNOMED CT ili klasifikacija ATC.

Za upotrebu u potvrdi 1.

Primjeri kodova koje bi trebalo koristiti iz najpoželjnijih kodnih sustava su, za kod 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). Trebalo bi proširiti skup vrijednosti u skladu s razvojem i puštanjem u uporabu novih vrsta cjepiva.

3.   Lijek (cjepivo) protiv bolesti COVID-19

Najpoželjniji kodni sustavi (od najpoželjnijeg):

—	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 lijeka (cjepiva) u ostalim slučajevima; sve bjeline u nazivu zamjenjuju se spojnicom (-).

Ime skupa vrijednosti: Cjepivo.

Za upotrebu u potvrdi 1.

Primjer koda koji bi trebalo koristiti je, za najpoželjnije kodne sustave, EU/1/20/1528 (Comirnaty). Primjer ako se kao kod koristi naziv cjepiva: Sputnik-V (za Sputnik V).

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

Najpoželjniji kodni sustav:

—	Kod 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 nazivu zamjenjuju se spojnicom (-).

Za upotrebu u potvrdi 1.

Primjer koda koji bi trebalo koristiti je, za najpoželjniji kodni sustav, ORG-100001699 (AstraZeneca AB). Primjer ako se kao kod koristi ime organizacije: Sinovac-Biotech (za Sinovac Biotech).

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

Za upotrebu u potvrdi 1.

Dva polja:

(1)	broj doze u ciklusu

(2)	broj očekivanih doza za cijeli ciklus (specifičan za osobu u vrijeme cijepljenja).

Na primjer, 1/1 i 2/2 smatraju se cijelim ciklusom, što obuhvaća i opciju 1/1 za cjepiva koja se sastoje od dvije doze, ali u slučaju građana kojima je prije cijepljenja dijagnosticiran COVID-19 država članica primjenjuje protokol cijepljenja jednom dozom. Ukupan broj doza u seriji navodi se u skladu s podacima dostupnima u trenutku cijepljenja. Na primjer, ako je za neko cjepivo potrebno cijepljenje trećom dozom (docjepljivanje) u trenutku zadnjeg cijepljenja, to bi se trebalo vidjeti iz broja u drugom polju (2/3, 3/3 itd.).

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

Najpoželjniji 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).

7.   Vrsta testa

Najpoželjniji kodni sustav: LOINC.

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.

Kodovi u ovom skupu vrijednosti odnose se na metodu testiranja i odabiru se tako da se barem vidjeti razlika između NAAT testova i brzih antigenskih testova, kako je navedeno u Uredbi (EU) 2021/953.

Primjer koda koji bi trebalo koristiti je, za najpoželjniji kodni sustav, LP217198-3 (brzi imunološki test).

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

Najpoželjniji kodni sustav: HSC-ov popis brzih antigenskih testova, kako ga vodi JRC (baza podataka o in vitro dijagnostičkim proizvodima i metodama za testiranje na COVID-19).

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

Najpoželjniji kodni sustav: SNOMED CT.

Za upotrebu u potvrdi 2.

Na temelju odabranih kodova mora se vidjeti razlika između pozitivnog (otkriveno) i negativnog (nije otkriveno) rezultata testa. Dodatne vrijednosti (npr. neodređeno) mogu se dodati u slučaju potrebe.

Primjeri kodova koje bi trebalo koristiti su, za najpoželjniji kodni sustav, 260415000 (nije otkriveno) i 260373001 (otkriveno).

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.

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 (1) (2), tj. {‚/’,’#’,’:’};

(2)	najveća duljina: u osmišljavanju rješenja trebalo bi ciljati na 27-30 znakova (3);

(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 trebale bi 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) (4) na temelju cijelog UCI-ja u digitalnom/fizičkom prijenosnom formatu. Kontrolni zbroj mora biti odvojen od ostatka UCI-ja znakom „#”.

Trebalo bi 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 o cijepljenju/tvrdnju. Drugim riječima, države članice ne smiju ponovno upotrijebiti isti identifikator.

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

---

(1)  rfc3986 (ietf.org)

(2)  Polja kao što su spol, broj serije/lota, punkt za cijepljenje, identifikacija zdravstvenog radnika, datum sljedećeg cijepljenja nisu nužno potrebna osim za medicinsku uporabu.

(3)  Kad je riječ o rješenjima s QR kodovima, države članice trebale bi razmotriti dodatni skup znakova ukupne duljine od 72 znaka (uključujući 27-30 znakova samog identifikatora) koji može prenositi druge informacije. Definiranje specifikacija tih informacija je u nadležnosti država članica.

(4)  Algoritam Luhn mod N je proširenje Luhnova algorithma (poznatog i kao algoritam mod 10) koji služi za brojčane oznake, a koristi se, npr., za izračun kontrolnog zbroja na kreditnim karticama. Proširenje omogućuje algoritmu da radi s nizovima vrijednosti bilo koje baze (u našem slučaju s alfa znakovima).

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

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

—	DCCG koristi dva digitalna certifikata (DCCGTLS i DCCGTA) s dva različita para ključeva. Privatni ključ para ključeva DCCGTA č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 NBCSCA koji je potpisan privatnim ključem DCCGTA,

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

—	certifikat države članice za slanje, NBUP,

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

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 NBCSCA na popis povjerenja potpisan privatnim ključem koji odgovara javnom ključu DCCGTA,

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

—	dodaje certifikat NBUP u sustav DCCG-a,

—	dostavlja certifikate javnih ključeva DCCGTA i DCCGTLS 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 (1) ili SOG-IS-ovom dokumentu Agreed Cryptographic Mechanisms (2).

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

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

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  (5) , o=<pružatelj>, c=<zemlja>
Key Usage	digitalni potpis (minimalno)

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

---

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

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

(3)  rfc5280 (ietf.org)

(4)  rfc5280 (ietf.org)

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