02021D1073 — SL — 25.04.2022 — 003.001

To besedilo je zgolj informativne narave in nima pravnega učinka. Institucije Unije za njegovo vsebino ne prevzemajo nobene odgovornosti. Verodostojne različice zadevnih aktov, vključno z uvodnimi izjavami, so objavljene v Uradnem listu Evropske unije. Na voljo so na portalu EUR-Lex. Uradna besedila so neposredno dostopna prek povezav v tem dokumentu

►B IZVEDBENI SKLEP KOMISIJE (EU) 2021/1073 z dne 28. junija 2021 o določitvi tehničnih specifikacij in pravil za izvajanje okvira zaupanja za digitalno COVID potrdilo EU, uvedeno z Uredbo (EU) 2021/953 Evropskega parlamenta in Sveta (Besedilo velja za EGP) (UL L 230 30.6.2021, str. 32)

spremenjen z:









▼B

IZVEDBENI SKLEP KOMISIJE (EU) 2021/1073

z dne 28. junija 2021

o določitvi tehničnih specifikacij in pravil za izvajanje okvira zaupanja za digitalno COVID potrdilo EU, uvedeno z Uredbo (EU) 2021/953 Evropskega parlamenta in Sveta

(Besedilo velja za EGP)







Člen 1

Tehnične specifikacije za digitalno COVID potrdilo EU, ki določajo generično podatkovno strukturo, kodirne mehanizme in mehanizem za kodiranje prenosa v strojno berljivem optičnem formatu, so določene v Prilogi I.

Člen 2

Pravila za izpolnjevanje potrdil iz člena 3(1) Uredbe (EU) 2021/953 so določena v Prilogi II k temu sklepu.

Člen 3

Zahteve, ki določajo skupno strukturo edinstvene identifikacijske oznake potrdila, so določene v Prilogi III.

▼M1

Člen 4

Pravila o upravljanju, ki se uporabljajo za potrdila javnih ključev v zvezi s prehodom za digitalna COVID potrdila EU, ki podpira vidike interoperabilnosti okvira zaupanja, so določena v Prilogi IV.

▼M1

Člen 5

Skupna usklajena struktura podatkov za podatke, ki jih je treba z uporabo sheme JSON vključiti v potrdila iz člena 3(1) Uredbe (EU) 2021/953, je določena v Prilogi V k temu sklepu.

▼M3

Člen 5a

Izmenjava seznamov preklicanih potrdil

1. Okvir zaupanja za digitalno COVID potrdilo EU omogoča izmenjavo seznamov preklicanih potrdil preko osrednjega prehoda za digitalno COVID potrdilo EU (v nadaljnjem besedilu: prehod) v skladu s tehničnimi specifikacijami iz Priloge I.

2. Če države članice prekličejo digitalna COVID potrdila EU, lahko preko prehoda predložijo sezname preklicanih potrdil.

3. Če države članice predložijo sezname preklicanih potrdil, organi izdajatelji vodijo seznam preklicanih potrdil.

4. Če se preko prehoda izmenjujejo osebni podatki, je obdelava omejena na namen podpiranja izmenjave informacij o preklicu. Taki osebni podatki se uporabljajo samo za preverjanje statusa preklica digitalnih COVID potrdil EU, izdanih v okviru področja uporabe Uredbe (EU) 2021/953.

5. Informacije, predložene prehodu, vključujejo naslednje podatke v skladu s tehničnimi specifikacijami iz Priloge I: (a) psevdonimizirane edinstvene oznake potrdil pri preklicanih potrdilih; (b) datum poteka veljavnosti predloženega seznama preklicanih potrdil;

6. Kadar organ izdajatelj prekliče digitalna COVID potrdila EU, ki jih je izdal v skladu z Uredbo (EU) 2021/953 ali Uredbo (EU) 2021/954, in namerava izmenjavati zadevne informacije preko prehoda, lahko informacije iz odstavka 5 v obliki seznamov preklicanih potrdil posreduje preko prehoda v varni obliki v skladu s tehničnimi specifikacijami iz Priloge I.

7. Organi izdajatelji v največji možni meri zagotovijo rešitev, s katero imetnike preklicanih potrdil obvestijo o statusu preklica njihovih potrdil in razlogu za preklic v času preklica.

8. Prehod zbira prejete sezname preklicanih potrdil. Zagotavlja orodja za razdeljevanje seznamov državam članicam. Sezname samodejno izbriše v skladu z datumi izteka veljavnosti, ki jih je za vsak predloženi seznam navedel organ, ki ga je predložil.

9. Imenovani nacionalni organi ali uradni organi držav članic, ki obdelujejo osebne podatke v prehodu, so skupni upravljavci obdelanih podatkov. Odgovornosti posameznih skupnih upravljavcev se določijo v skladu s Prilogo VI.

10. Komisija je obdelovalec osebnih podatkov, ki se obdelujejo v prehodu. Komisija kot obdelovalec v imenu držav članic zagotavlja varnost prenosa in gostovanja osebnih podatkov v prehodu ter izpolnjuje obveznosti obdelovalca iz Priloge VII.

11. Komisija in skupni upravljavci redno preskušajo, ocenjujejo in vrednotijo učinkovitost tehničnih in organizacijskih ukrepov za zagotavljanje varnosti obdelave osebnih podatkov v prehodu.

Člen 5b

Predložitev seznamov preklicanih potrdil s strani tretjih držav

Tretje države, ki izdajajo COVID-19 potrdila, v zvezi s katerimi je Komisija sprejela izvedbeni akt v skladu s členom 3(10) ali členom 8(2) Uredbe (EU) 2021/953, lahko predložijo sezname preklicanih COVID-19 potrdil, zajetih v takem izvedbenem aktu, da jih Komisija obdela v imenu skupnih upravljavcev v prehodu iz člena 5a, v skladu s tehničnimi specifikacijami iz Priloge I.

Člen 5c

Upravljanje obdelave osebnih podatkov v osrednjem prehodu za digitalno COVID potrdilo EU

1. Postopek odločanja skupnih upravljavcev ureja delovna skupina, ustanovljena v okviru odbora iz člena 14 Uredbe (EU) 2021/953.

2. Predstavnike te skupine imenujejo imenovani nacionalni organi ali uradni organi držav članic, ki obdelujejo osebne podatke v prehodu kot skupni upravljavci.

▼M1

Člen 6

Ta sklep začne veljati na dan objave v Uradnem listu Evropske unije.

▼B

Ta sklep začne veljati na dan objave v Uradnem listu Evropske unije.









PRILOGA I

FORMAT IN UPRAVLJANJE ZAUPANJA

Generična podatkovna struktura, kodirni mehanizmi in mehanizem za kodiranje prenosa v strojno berljivem optičnem formatu (v nadaljnjem besedilu: QR)

1. Uvod

Tehnične specifikacije iz te priloge vsebujejo generično podatkovno strukturo in kodirne mehanizme za digitalno COVID potrdilo EU (v nadaljnjem besedilu: DCC). Določajo tudi mehanizem za kodiranje prenosa v strojno berljivem optičnem formatu (v nadaljnjem besedilu: QR), ki se lahko prikaže na zaslonu mobilne naprave ali natisne. Vsebniški formati elektronskega zdravstvenega potrdila iz teh specifikacij so generični, vendar se v tem okviru uporabljajo kot nosilci za potrdilo DCC.

2. Terminologija

V tej prilogi „izdajatelji“ pomenijo organizacije, ki uporabljajo te specifikacije za izdajanje zdravstvenih potrdil, „preveritelji“ pa pomenijo organizacije, ki zdravstvena potrdila sprejemajo kot dokaz o zdravstvenem stanju. „Udeleženci“ pomenijo izdajatelje in preveritelje. Udeleženci morajo medsebojno uskladiti nekatere vidike iz te priloge, kot sta upravljanje imenskega prostora in razdelitev kriptografskih ključev. Predpostavlja se, da te naloge opravlja stranka, v nadaljnjem besedilu imenovana „sekretariat“.

3. Vsebniški format elektronskega zdravstvenega potrdila

Vsebniški format elektronskega zdravstvenega potrdila (v nadaljnjem besedilu: HCERT) je zasnovan tako, da zagotavlja enoten in standardiziran nosilec za zdravstvena potrdila različnih izdajateljev (v nadaljnjem besedilu: izdajatelji). Cilj teh specifikacij je uskladiti način predstavitve, kodiranja in podpisa teh zdravstvenih potrdil, da bi se olajšala interoperabilnost.

Za zmožnost branja in razlage potrdila DCC, ki ga izda kateri koli izdajatelj, sta potrebna skupna podatkovna struktura ter dogovor o pomenu vsakega podatkovnega polja koristne vsebine. Za olajšanje take interoperabilnosti je z uporabo sheme JSON, ki predstavlja okvir DCC, opredeljena skupna usklajena podatkovna struktura.

3.1. Struktura koristne vsebine

Koristna vsebina je strukturirana in kodirana kot CBOR z digitalnim podpisom COSE. To je splošno znano kot „spletni žeton za CBOR“ (CWT), ki je opredeljen v standardu RFC 8392 ( 1 ). Koristna vsebina, kot je opredeljena v naslednjih oddelkih, se prenese v trditvi hcert.

Preveritelj mora imeti možnost, da preveri celovitost in verodostojnost izvora podatkov koristne vsebine. Za zagotovitev tega mehanizma mora izdajatelj podpisati CWT z asimetrično shemo digitalnega podpisa, kot je opredeljena v specifikaciji COSE (RFC 8152 ( 2 )).

3.2. Trditve CWT

3.2.1. Pregled strukture CWT

Zaščitena glava

— Algoritem za podpis (alg, oznaka 1)

— Identifikacijska oznaka ključa (kid, oznaka 4)

Koristna vsebina

— Izdajatelj (iss, ključ trditve 1, neobvezno, oznaka ISO 3166-1 alfa-2 izdajatelja)

— Izdano ob (iat, ključ trditve 6)

— Čas izteka veljavnosti (exp, ključ trditve 4)

— Zdravstveno potrdilo (hcert, ključ trditve -260)

— Digitalno COVID potrdilo EU v1 (eu_DCC_v1, ključ trditve 1)

Podpis

3.2.2. Algoritem za podpis

Parameter algoritma za podpis (alg) kaže, kateri algoritem je uporabljen za ustvarjanje podpisa. Izpolnjevati mora sedanje smernice SOG-IS, kot so povzete v naslednjih odstavkih, ali jih presegati.

Opredeljena sta en primarni in en sekundarni algoritem. Sekundarni algoritem bi se moral uporabljati le, če primarni algoritem ni sprejemljiv v okviru pravil in predpisov, ki veljajo za izdajatelja.

Da bi se zagotovila varnost sistema, morajo vse izvedbe vključevati sekundarni algoritem. Zato se morata izvajati primarni in sekundarni algoritem.

Ravni za primarne in sekundarne algoritme, določene v SOG-IS, so:

— Primarni algoritem: primarni algoritem je algoritem z eliptično krivuljo za digitalni podpis (Elliptic Curve Digital Signature Algorithm – ECDSA), kot je opredeljen v oddelku 2.3 standarda ISO/IEC 14888–3:2006 in ki uporablja parametre P–256, kot so opredeljeni v Dodatku D (D.1.2.3) k standardu FIPS PUB 186–4, v kombinaciji z zgoščevalnim algoritmom SHA–256, kot je opredeljen v oddelku o funkciji 4 standarda ISO/IEC 10118–3:2004.

To ustreza parametru algoritma COSE ES256.

— Sekundarni algoritem: sekundarni algoritem je RSASSA-PSS, kot je opredeljen v (RFC 8230 ( 3 )), z 2048-bitnim modulom v kombinaciji z zgoščevalnim algoritmom SHA–256, kot je opredeljen v oddelku o funkciji 4 (ISO/IEC 10118–3:2004).

To ustreza parametru algoritma COSE: PS256.

3.2.3. Identifikacijska oznaka ključa

Trditev „Identifikacijska oznaka ključa“ (kid) označuje potrdilo za podpisovalnik dokumenta (DSC), ki vsebuje javni ključ, ki ga preveritelj uporablja za preverjanje pravilnosti digitalnega podpisa. Upravljanje potrdil javnih ključev, vključno z zahtevami za DSC, je opisano v Prilogi IV.

Preveritelji uporabljajo trditev „Identifikacijska oznaka ključa“ (kid) za izbiro ustreznega javnega ključa s seznama ključev, ki se nanašajo izdajatelja iz trditve „Izdajatelj“ (iss). Izdajatelj lahko iz upravnih razlogov in ob izvedbi menjave ključev vzporedno uporablja več ključev. Identifikacijska oznaka ključa ni varnostno kritično polje. Zato se lahko po potrebi umesti tudi v nezaščiteno glavo. Preveritelji morajo sprejeti obe možnosti. Če sta na voljo obe možnosti, je treba uporabiti identifikacijsko oznako ključa v zaščiteni glavi.

Zaradi skrajšanja identifikacijske oznake (zaradi omejitve prostora) obstaja majhna, vendar ne ničelna verjetnost, da bi lahko celoten seznam potrdil DSC, ki jih je sprejel preveritelj, vseboval potrdila DSC s podvojenimi identifikacijskimi oznakami kid. Zato mora preveritelj preveriti vsa potrdila DSC z navedeno identifikacijsko oznako kid.

3.2.4. Izdajatelj

Trditev „Izdajatelj“ (iss) je vrednost v obliki niza, ki lahko vsebuje ISO 3166-1 alfa-2 kodo države subjekta, ki izda zdravstveno potrdilo. To trditev lahko preveritelj uporabi za določitev, kateri nabor potrdil DSC uporabiti za preverjanje. Za identifikacijo te trditve se uporablja ključ trditve 1.

3.2.5. Čas izteka veljavnosti

Trditev „Čas izteka veljavnosti“ (exp) vsebuje časovni žig v formatu NumericDate (številčni datum) s celimi števili (kot je določen v oddelku 2 RFC 8392 ( 4 )), ki kaže, kako dolgo se ta podpis za koristno vsebino šteje za veljavnega, po izteku tega obdobja veljavnosti pa mora preveritelj koristno vsebino zavrniti kot poteklo. Namen parametra izteka veljavnosti je uvesti omejitev obdobja veljavnosti zdravstvenega potrdila. Za identifikacijo te trditve se uporablja ključ trditve 4.

Čas izteka veljavnosti ne sme presegati obdobja veljavnosti potrdila DSC.

3.2.6. Izdano ob

Trditev „Izdano ob“ (iat) vsebuje časovni žig v formatu NumericDate (številčni datum) s celimi števili (kot je določen v oddelku 2 RFC 8392 ( 5 )), ki kaže čas, ko je bilo zdravstveno potrdilo ustvarjeno.

Čas v polju „Izdano ob“ ne sme biti pred začetkom obdobja veljavnosti potrdila DSC.

Preveritelji lahko uporabljajo dodatne politike za omejitev veljavnosti zdravstvenega potrdila glede na čas izdaje. Za določitev te trditve se uporablja ključ trditve 6.

3.2.7. Trditev „Zdravstveno potrdilo“

Trditev „Zdravstveno potrdilo“ (hcert) je objekt JSON (RFC 7159 ( 6 )), ki vsebuje informacije o zdravstvenem stanju. V okviru iste trditve je lahko več različnih vrst zdravstvenih potrdil, ena od njih pa je DCC.

JSON se uporablja zgolj za namene sheme. Kodirni format je CBOR, kot je opredeljen v RFC 7049 ( 7 ). Razvijalci aplikacij dejansko ne smejo nikoli kodirati v format JSON in dekodirati iz njega, ampak uporabljajo pomnilniško strukturo.

Za določitev te trditve se uporablja ključ trditve -260.

Nize v objektu JSON bi bilo treba normalizirati v skladu z NFC (Normalization Form Canonical Composition), opredeljenim v standardu Unicode. Aplikacije za dekodiranje pa bi morale biti s teh vidikov permisivne in zanesljive, poleg tega se zelo priporoča sprejetje kakršne koli razumne pretvorbe podatkovnega tipa. Če se med dekodiranjem ali v poznejših primerjalnih funkcijah odkrijejo podatki, ki niso normalizirani, bi se morale izvedbe obnašati, kot da so vhodni podatki normalizirani po NFC.

4. Serializacija in ustvarjanje koristne vsebine potrdila DCC

Kot vzorec za serializacijo se uporablja naslednja shema:

Postopek se začne s pridobivanjem podatkov, na primer iz odložišča zdravstvenih podatkov (ali zunanjega vira podatkov), pri čemer se pridobljeni podatki strukturirajo v skladu z opredeljenimi shemami DCC. V tem postopku se lahko pretvorba v določen format podatkov in preoblikovanje v berljivost za ljudi izvedeta, preden se začne serializacija v format CBOR. Kratice trditev se v vsakem primeru preslikajo v prikazna imena pred serializacijo in po deserializaciji.

V potrdilih, izdanih v skladu z Uredbo (EU) 2021/953 ( 8 ), ni dovoljena neobvezna nacionalna vsebina podatkov. Vsebina podatkov je omejena na opredeljene podatkovne elemente v minimalnem naboru podatkov iz Priloge k Uredbi (EU) 2021/953.

5. Kodiranje prenosa

5.1. Neobdelano

Pri poljubnih podatkovnih vmesnikih se lahko vsebnik HCERT in njegove koristne vsebine prenašajo taki, kot so, pri čemer se lahko uporablja kateri koli osnoven, 8-bitni, varen in zanesljiv prenos podatkov. Med temi vmesniki so lahko komunikacija v bližnjem polju (NFC, Near-Field Communication), Bluetooth ali prenos prek protokola aplikacijske plasti, na primer prenos potrdila HCERT od izdajatelja do mobilne naprave imetnika.

Če prenos potrdila HCERT od izdajatelja do imetnika temelji na vmesniku, ki omogoča le predstavitev (npr. SMS, e-pošta), kodiranje prenosa v neobdelani obliki očitno ni ustrezno.

5.2. Črtna koda

5.2.1. Stiskanje koristne vsebine (CWT)

Za zmanjšanje velikosti ter izboljšanje hitrosti in zanesljivosti v postopku branja potrdila HCERT se spletni žeton CWT stisne po metodi ZLIB (RFC 1950 ( 9 )) in z mehanizmom za stiskanje podatkov brez izgub v formatu, opredeljenem v RFC 1951 ( 10 ).

5.2.2. Dvodimenzionalna črtna koda QR

Za boljše upravljanje obstoječe opreme, zasnovane za obdelavo koristnih vsebin v formatu ASCII, je stisnjeni CWT pred kodiranjem v dvodimenzionalno (2D) črtno kodo kodiran v formatu ASCII z uporabo sheme Base45.

Za generiranje 2D črtnih kod se uporablja format QR, kot je opredeljen v standardu ISO/IEC 18004:2015. Priporočena je stopnja popravljanja napak „Q“ (približno 25 %). Ker se uporablja shema Base45, se mora za kodo QR uporabljati alfanumerično kodiranje (način 2, označen s simboli 0010).

Da bi lahko preveritelji ugotovili vrsto kodiranih podatkov in izbrali ustrezno shemo dekodiranja in obdelave, imajo podatki, kodirani po shemi Base45 (v skladu s to specifikacijo), predpono v obliki niza identifikacijske oznake konteksta „HC1:“. S prihodnjimi različicami te specifikacije, ki bodo vplivale na združljivost za nazaj, bo opredeljena nova identifikacijska oznaka konteksta, medtem ko bo znak, ki sledi „HC“, vzet iz nabora znakov [1–9A–Z]. Vrstni red povečanj je določen v navedenem vrstnem redu, tj. najprej [1–9] in nato [A–Z].

Priporoča se, da se optična koda prikaže na predstavitvenem mediju z velikostjo diagonale 35–60 mm, da se prilagodi čitalnikom s fiksno optiko, pri katerih je treba predstavitveni medij postaviti na površino čitalnika.

Če se optična koda natisne na papir s tiskalniki z nizko ločljivostjo (<300 dpi), je treba paziti, da je vsak simbol (pika) QR kode pravilen kvadrat. Z nesorazmernim spreminjanjem velikosti so simboli v nekaterih vrsticah ali stolpcih QR kode pravokotni, kar v številnih primerih zmanjša berljivost.

6. Format zanesljivega seznama (seznam CSCA in DSC)

Vsaka država članica mora predložiti seznam enega ali več državnih organov overiteljev potrdila (Country Signing Certificate Authority – CSCA) in seznam vseh veljavnih potrdil za podpisovalnike dokumentov (Document Signer Certificate – DSC) ter ju redno posodabljati.

6.1. Poenostavljeni CSCA/DSC

Od te različice specifikacij države članice ne domnevajo, da se uporabljajo katere koli informacije s seznama preklicanih potrdil (CRL) ali da izvajalci preverjajo obdobje uporabe zasebnega ključa.

Namesto tega je primarni mehanizem veljavnosti prisotnost potrdila na najnovejši različici navedenega seznama potrdil.

6.2. PKI in središča zaupanje za eMRTD organizacije ICAO

Države članice lahko uporabljajo ločeno potrdilo CSCA, lahko pa tudi predložijo svoja obstoječa potrdila CSCA za strojno berljive elektronske potne listine (eMRTD) in/ali potrdila DSC; lahko se celo odločijo, da bodo ta potrdila kupile od (komercialnih) središč zaupanja, in predložijo taka potrdila. Vendar mora vsako potrdilo DSC vedno podpisati CSCA, ki ga je sporočila zadevna država članica.

7. Varnostni vidiki

Pri oblikovanju sheme na podlagi te specifikacije države članice opredelijo, analizirajo in spremljajo nekatere varnostne vidike.

Upoštevati bi bilo treba vsaj naslednje vidike:

7.1. Obdobje veljavnosti podpisa HCERT

Izdajatelj potrdil HCERT mora omejiti obdobje veljavnosti podpisa, tako da določi čas izteka veljavnosti podpisa. Zato mora imetnik zdravstvenega potrdila to potrdilo redno podaljševati.

Sprejemljivo obdobje veljavnosti je lahko odvisno od praktičnih omejitev. Potnik med potovanjem v tujino na primer morda ne bo mogel podaljšati zdravstvenega potrdila. Lahko pa se zgodi tudi, da izdajatelj preučuje možnost nekakšne varnostne grožnje, zaradi katere mora umakniti potrdilo DSC (in s tem razveljaviti vsa zdravstvena potrdila, izdana z zadevnim ključem, ki so še vedno veljavna). Posledice takega dogodka se lahko omejijo z rednim menjavanjem ključev izdajatelja in zahtevanjem podaljšanja vseh zdravstvenih potrdil v določenih razumnih časovnih razmikih.

7.2. Upravljanje ključev

Ta specifikacija v glavnem temelji na močnih kriptografskih mehanizmih za zagotovitev celovitosti podatkov in avtentikacije izvora podatkov. Zato je treba ohranjati zaupnost zasebnih ključev.

Zaupnost kriptografskih ključev je lahko ogrožena na več različnih načinov, na primer:

— postopek generiranja ključev je lahko pomanjkljiv, posledica pa so šibki ključi;

— ključi so lahko razkriti zaradi človeške napake;

— ključe lahko ukradejo zunanji ali notranji storilci;

— ključi se lahko izračunajo s kriptoanalizo.

Za zmanjšanje tveganja, da bo algoritem za podpis šibek in bo omogočal ogrožanje zasebnih ključev s kriptoanalizo, se s to specifikacijo vsem udeležencem priporoča, naj uvedejo sekundarni algoritem za ponovno pridobitev podpisa, ki temelji na drugačnih parametrih ali drugačnem matematičnem problemu kot primarni.

Kar zadeva navedena tveganja, povezana z operacijskim okoljem izdajateljev, se izvedejo blažilni ukrepi za zagotovitev učinkovitega nadzora, na primer za generiranje, shranjevanje in uporabo zasebnih ključev v varnostnih modulih strojne opreme (Hardware Security Module – HSM). Za podpisovanje zdravstvenih potrdil se zelo spodbuja uporaba varnostnih modulov strojne opreme.

Ne glede na to, ali se izdajatelj odloči za uporabo varnostnih modulov strojne opreme ali ne, bi bilo treba določiti časovni razpored menjave ključev, pri katerem je pogostost menjave ključev sorazmerna z izpostavljenostjo ključev zunanjim omrežjem, drugim sistemom in osebju. Dobro izbran časovni razpored menjave tudi omejuje tveganja, povezana z napačno izdanimi zdravstvenimi potrdili, saj izdajatelju omogoča, da prekliče serije takih zdravstvenih potrdil, tako da po potrebi umakne ključ.

7.3. Potrjevanje vhodnih podatkov

Te specifikacije se lahko uporabljajo na način, ki vključuje sprejemanje podatkov iz neverodostojnih virov v sisteme, ki so lahko ključni za izvedbo naloge. Za zmanjšanje tveganj, povezanih s tem napadnim vektorjem, morajo biti vsa vnosna polja ustrezno preverjena glede na vrste podatkov, njihove dolžine in vsebino. Podpis izdajatelja se prav tako preveri pred kakršno koli obdelavo vsebine potrdila HCERT. Vendar potrditev veljavnosti podpisa izdajatelja pomeni, da je treba najprej razčleniti zaščiteno glavo izdajatelja, v katero lahko potencialni napadalec poskuša vnesti skrbno oblikovane informacije, namenjene ogrožanju varnosti sistema.

8. Upravljanje zaupanja

Za preverjanje podpisa potrdila HCERT je potreben javni ključ. Države članice dajo te javne ključe na voljo. Na koncu mora imeti vsak preveritelj seznam vseh javnih ključev, ki jim lahko zaupa (ker javni ključ ni del potrdila HCERT).

Sistem je sestavljen iz (samo) dveh slojev; za vsako državo članico eno ali več potrdil na ravni države, vsako od njih pa podpiše eno ali več potrdil za podpisovalnik dokumenta, ki se uporabljajo pri vsakodnevnih dejavnostih.

Potrdila držav članic se imenujejo potrdila državnega organa overitelja potrdila (CSCA) in so (običajno) samopodpisana. Države članice imajo lahko več kot eno tako potrdilo (npr. v primeru regionalne decentralizacije). Ta potrdila CSCA redno podpisujejo potrdila za podpisovalnike dokumentov (DSC), ki se uporabljajo za podpisovanje potrdil HCERT.

„Sekretariat“ ima funkcionalno vlogo. Redno zbira in objavlja potrdila DSC držav članic, potem ko jih preveri na podlagi seznama potrdil CSCA (ki so bila posredovana in preverjena z drugimi sredstvi).

Dobljeni seznam potrdil DSC nato vsebuje združeni nabor sprejemljivih javnih ključev (in ustrezne identifikacijske oznake „kid“), ki jih lahko preveritelji uporabljajo za potrjevanje veljavnosti podpisov v potrdilih HCERT. Preveritelji morajo pridobiti ta seznam in ga redno posodabljati.

Format takih posebnih seznamov za posamezne države članice se lahko prilagodi, da ustreza nacionalnemu okolju. Zato se lahko format datoteke tega zanesljivega seznama razlikuje, in gre lahko na primer za podpisani format JWKS (format niza JWK v skladu z oddelkom 5 RFC 7517 ( 11 )) ali kateri koli drug format, značilen za tehnologijo, ki se uporablja v zadevni državi članici.

Za zagotovitev enostavnosti lahko države članice predložijo obstoječa potrdila CSCA iz svojih sistemov ICAO eMRTD ali, kot priporoča SZO, ustvarijo potrdilo CSCA posebej za to zdravstveno področje.

8.1. Identifikacijska oznaka ključa (kid)

Identifikacijska oznaka ključa (kid) se izračuna ob oblikovanju seznama zaupanja vrednih javnih ključev iz potrdil DSC in je sestavljena iz skrajšanega (prvih 8 bajtov) prstnega odtisa SHA-256 potrdila DSC, kodiranega v formatu DER (neobdelanem).

Preveriteljem ni treba izračunati identifikacijske oznake „kid“ na podlagi potrdila DSC, ampak lahko identifikacijsko oznako ključa v izdanem zdravstvenem potrdilu neposredno povežejo z identifikacijsko oznako „kid“ na zanesljivem seznamu.

8.2. Razlike glede na model zaupanja PKI za eMRTD organizacije ICAO

Medtem ko je treba upoštevati dobre prakse v zvezi z modelom zaupanja PKI za eMRTD organizacije ICAO, se zaradi hitrosti uvede več poenostavitev:

— država članica lahko predloži več potrdil CSCA;

— obdobje veljavnosti potrdila DSC (uporaba ključa) je lahko katera koli vrednost, ki ne presega obdobja veljavnosti potrdila CSCA, in lahko sploh ni določeno;

— potrdilo DSC lahko vsebuje identifikacijske oznake politike (uporaba razširjenega ključa), značilne za zdravstvena potrdila;

— države članice se lahko odločijo, da nikoli ne bodo preverjale objavljenih preklicev; namesto tega se lahko zanašajo le na sezname potrdil DSC, ki jih vsak dan dobijo od sekretariata ali jih sestavijo same.

▼M3

9. Rešitev za preklic

9.1 Določba za seznam preklicev DCC (DRL)

Prehod zagotavlja končne točke in funkcionalnost za hranjenje in upravljanje seznamov preklicev:

9.2 Model zaupanja

Vse povezave so vzpostavljene s standardnim modelom zaupanja DCCG s potrdili NBTLS in NBUP (glej upravljanje potrdil). Vse informacije so zapakirane in naložene s sporočili CMS, da se zagotovi celovitost.

9.3 Sestava serije

9.3.1 Serija

Vsak seznam preklicev vsebuje enega ali več vnosov in se pakira v serije, ki vsebujejo sklop zgoščenih vrednosti (hash) in njihove metapodatke. Serija je nespremenljiva in določa datum poteka veljavnosti, ki označuje, kdaj se serija lahko izbriše. Datum izteka veljavnosti vseh elementov v seriji mora biti popolnoma enak, kar pomeni, da morajo biti serije združene po datumu poteka veljavnosti in s podpisom potrdila DSC. Vsaka serija vsebuje največ 1 000 vnosov. Če seznam preklicev vsebuje več kot 1 000 vnosov, se ustvari več serij. Vsak vnos se lahko pojavi v največ eni seriji. Serija se pakira v strukturo CMS in se podpiše s potrdilom NBup države, ki jo je naložila.

9.3.2 Indeks serij

Ko se ustvari serija, ji prehod dodeli edinstveno identifikacijsko oznako in se samodejno doda v indeks. Indeks serij je urejen po datumu spremembe v naraščajočem kronološkem vrstnem redu.

9.3.3 Vedenje prehoda

Prehod obdeluje serije preklicev brez kakršnih koli sprememb: ne more niti posodobiti niti odstraniti niti dodati nobenih informacij v serije. Serije se pošljejo vsem pooblaščenim državam (glejte poglavje 9.6).

Portal dejavno spremlja datume poteka veljavnosti serij in briše potekle serije. Po izbrisu serije vstopno mesto vrne odgovor „HTTP 410 Gone“ za URL izbrisane serije. Zato je serija v indeksu serij označena z „izbrisano“.

9.4 Vrste zgoščene vrednosti

Seznam preklicev vsebuje zgoščene vrednosti, ki lahko predstavljajo različne vrste/lastnosti preklicev. Te vrste ali lastnosti se navedejo pri pripravi seznamov preklicev. Trenutne vrste so:







Vrsta Atribut Izračun zgoščene vrednosti SIGNATURE DCC Signature SHA256 of DCC Signature UCI UCI (Unique Certificate Identifier) SHA256 of UCI COUNTRYCODEUCI Issuing Country Code + UCI SHA256 of Issuing CountryCode + UCI

Samo prvih 128 bitov zgoščenih vrednosti, kodiranih kot nizi base64, se vstavi v serije in uporabi za identifikacijo preklicanega DCC ( 12 ).

9.4.1 Vrsta zgoščene vrednosti: SHA256(podpis DDC)

V tem primeru se zgoščena vrednost izračuna prek bajtov podpisa COSE_SIGN1 iz CWT. Pri podpisih RSA se bo kot vnos uporabil celoten podpis. Formula za potrdila, podpisana z ES-DSA, kot vhodni podatek uporablja vrednost r:

SHA256(r)

[zahtevano za vse nove izvedbe]

9.4.2 Vrsta zgoščene vrednosti: SHA256(UCI)

V tem primeru se zgoščena vrednost izračuna na podlagi niza UCI, kodiranega v UTF-8 in pretvorjenega v vrsto (array) bajtov.

[zastarelo ( 13 ), vendar podprto zaradi združljivosti za nazaj]

9.4.3 Vrsta zgoščene vrednosti: SHA256(Koda države izdajateljice + UCI)

V tem primeru je koda države izdajateljice kodirana kot niz UTF-8, povezan z UCI, kodiranim z nizom UTF-8. Ta se nato pretvori v vrsto bajtov in uporabi kot vnos v funkcijo zgoščene vrednosti.

[zastarelo2, vendar podprto zaradi združljivost za nazaj]

9.5. Struktura API

9.5.1 API za dodeljevanje vnosov s seznama preklicev

9.5.1.1 Namen

API zagotavlja vnose s seznama preklicev v serijah, vključno z indeksom serij.

9.5.1.2 Končne točke

9.5.1.2.1 Končna točka za prenos seznama serij

Končne točke imajo preprosto zasnovo in vračajo seznam serij z majhnim ovojem, ki vsebuje metapodatke. Serije so razvrščene po datumu v naraščajočem (kronološkem) vrstnem redu:

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

}

Opomba: Rezultat je privzeto omejen na 1 000 . Če je oznaka „more“ nastavljena na vrednost „true“, je v odzivu navedeno, da je na voljo več serij za prenos. Če želite prenesti več elementov, mora odjemalec nastaviti glavo If-Modified-Since na datum, ki ni starejši od zadnjega prejetega vnosa.

Odziv vsebuje vrsto JSON z naslednjo strukturo:







Polje Opredelitev more Oznaka Boolean, ki kaže, da obstaja več serij. batches Vrsta z obstoječimi serijami. batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Koda države ISO 3166 date ISO 8601 Datum UTC. Datum, ko je bila serija dodana ali izbrisana. deleted boolean. Vrednost „true“, če je izbrisano. Če je nastavljena oznaka „izbrisano“, se lahko vnos po 7 dneh dokončno odstrani iz zadetkov poizvedbe.

9.5.1.2.1.1 Kode odzivov







Koda Opis 200 Vse v redu. 204 Ni vsebine, če vsebina glave „If-Modified-Since“ nima ujemanja.

Glava zahtevka







Glava Obvezno Opis If-Modified-Since Da Ta glava vsebuje datum zadnjega prenosa, tako da dobite le najnovejše rezultate. Ob prvem pozivu mora biti v glavi nastavljena vrednost ‘2021-06-01T00:00:00Z’

9.5.1.2.2 Končna točka za prenos serije

Serije vsebujejo seznam identifikatorjev potrdila:

/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 vsebuje CMS, vključno s podpisom, ki se mora ujemati s potrdilom NBUP države. Vsi elementi v vrsti JSON vsebujejo naslednjo strukturo:







Polje Obvezno Vrsta Opredelitev expires Da String Datum, ko se element lahko odstrani. ISO 8601 Datum/Čas UTC country Da String Koda države ISO 3166 hashType Da String Vrsta zgoščene vrednosti navedenih vnosov (glej Vrste zgoščene vrednosti) entries Da JSON Object Array Glejte tabelo Vnosi kid Da String KID potrdila DSC, kodiran z base64, ki se uporablja za podpis DCC. Če KID ni znan, se lahko uporabi niz „UNKNOWN_KID“ (brez '). Opombe:

— Serije se združijo po datumu poteka veljavnosti in DSC – vsem elementom veljavnost poteče hkrati in so podpisani z istim ključem.

— Čas izteka je datum/čas v UTC, ker je EU-DCC globalen sistem in moramo uporabljati nedvoumen čas.

— Datum izteka veljavnosti trajno preklicanega DCC se določi na datum izteka ustreznega potrdila DSC, ki se uporablja za podpis DCC, ali na čas izteka preklicanega DCC (v tem primeru se uporabljeni časi v formatu NumericDate/epoch obravnavajo, kot da so v časovnem pasu UTC).

— Nacionalno zaledje (NB) odstrani predmete s seznama preklica, ko je dosežen datum poteka veljavnosti .

— NB lahko odstrani elemente s svojega seznama preklicev v primeru, da je bil kid , ki je bil uporabljen za podpis DCC, preklican.

9.5.1.2.2.1 Vnosi







Polje Obvezno Vrsta Opredelitev hash Da String Prvih 128 bitov zgoščene vrednosti SHA256, kodiranih kot niz base64

Opomba: Objekt vnosov trenutno vsebuje le zgoščeno vrednost, da pa bi bil združljiv s spremembami v prihodnosti, je bil namesto vrste json izbran objekt.

9.5.1.2.2.2 Kode odzivov







Koda Opis 200 Vse v redu. 410 Izbrisana serija. Serija se lahko izbriše v nacionalnem zaledju.

9.5.1.2.2.3 Glave za odzive







Glava Opis ETag Identifikacijska številka serije.

9.5.1.2.3 Končna točka za nalaganje serije

Nalaganje se izvede prek iste končne točke s funkcijo (verb) POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

{

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

}

Serija se podpiše s potrdilom NBUP. Portal preveri, ali je NBUP za zadevno državo določil podpis. Če preverjanje podpisa ni uspešno, je nalaganje neuspešno.

OPOMBA: Vsaka serija je nespremenljiva in je po nalaganju ni mogoče spremeniti. Vendar se jo lahko izbriše. Identifikacijska oznaka (ID) vsake izbrisane serije se shrani, nalaganje nove serije z isto identifikacijsko oznako (ID) pa se zavrne.

9.5.1.2.4 Končna točka za izbris serije

Serija se lahko prek iste končne točke izbriše s funkcijo (verb) „DELETE“:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

‘batchId’: ‘...’

}

ali (zaradi združljivosti) do naslednje končne točke s funkcijo (verb) „POST“:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

‘batchId’: ‘...’

}

9.6 Zaščita API/Splošna uredba o varstvu podatkov

Ta oddelek določa ukrepe za izvajanje za skladnost z določbami Uredbe 2021/953 v zvezi z obdelavo osebnih podatkov.

9.6.1 Obstoječa avtentikacija

Prehod trenutno uporablja potrdilo NBTLS za avtentikacijo držav, ki se povezujejo s prehodom. Ta avtentikacija se lahko uporabi za določitev identitete države, povezane s prehodom. Ta identiteta se lahko nato uporabi za izvajanje nadzora dostopa.

9.6.2 Upravljanje dostopa

Da bi lahko prehod zakonito obdeloval osebne podatke, izvaja mehanizem za nadzor dostopa.

Prehod uporablja kontrolni seznam dostopa v kombinaciji z varnostjo na podlagi vloge (Role Based Security). V tej shemi se ohranjata dve tabeli – v eni od njiju je opisano, katere vloge lahko uporabljajo katere operacije za katere vire, v drugi pa, katere vloge se dodelijo katerim uporabnikom.

Za izvajanje postopkov nadzora, ki jih zahteva ta dokument, so potrebne tri vloge, in sicer:

RevocationListReader

RevocationUploader

RevocationDeleter

Naslednje končne točke preverijo, ali ima uporabnik vlogo RevocationListReader; če jo ima, se dostop odobri, če pa ne, uporabnik dobi sporočilo HTTP 403 Forbidden:

GET /revocation-list/

GET /revocation-list/{batchId}

Naslednje končne točke preverijo, ali ima uporabnik vlogo RevocationUploader; če jo ima, se dostop odobri, če pa ne, uporabnik dobi sporočilo HTTP 403 Forbidden:

POST /revocation-list

Naslednje končne točke preverijo, ali ima uporabnik vlogo RevocationDeleter; če jo ima, se dostop odobri, če pa ne, uporabnik dobi sporočilo HTTP 403 Forbidden:

DELETE /revocation-list

POST /revocation-list/delete

Prehod zagotavlja tudi zanesljivo metodo, s katero lahko administratorji vloge, ki so povezane z uporabniki, upravljajo tako, da zmanjšajo možnost človeške napake, hkrati pa ne obremenjujejo funkcionalnih administratorjev.

▼M1









PRILOGA II

PRAVILA ZA IZPOLNJEVANJE DIGITALNEGA COVID POTRDILA EU

Splošna pravila glede naborov vrednosti, določena v tej prilogi, so namenjena zagotavljanju interoperabilnosti na semantični ravni in omogočajo enotne tehnične izvedbe za digitalno COVID potrdilo EU. Elementi v tej prilogi se lahko uporabljajo za tri različne primere (cepljenje/testiranje/prebolela bolezen), kot je določeno v Uredbi (EU) 2021/953. V tej prilogi so navedeni samo elementi, pri katerih je potrebna semantična standardizacija prek kodiranih naborov vrednosti.

Za prevajanje kodiranih elementov v nacionalni jezik so odgovorne države članice.

Za vsa podatkovna polja, ki niso navedena v naslednjih opisih naborov vrednosti, je kodiranje opisano v Prilogi V.

Če iz kakršnega koli razloga ni mogoče uporabiti spodaj navedenih prednostnih kodnih sistemov, se lahko uporabijo drugi mednarodni kodni sistemi, poleg tega se zagotovijo nasveti, kako kode iz drugega kodnega sistema preslikati v prednostni kodni sistem. Besedilo (prikazna imena) se lahko v izjemnih primerih uporabi kot rezervni mehanizem, kadar v opredeljenih naborih vrednosti ni na voljo ustrezna koda.

Države članice, ki v svojih sistemih uporabljajo druge kode, morajo take kode preslikati v opisane nabore vrednosti. Za vse take preslikave so odgovorne države članice.

Ker se nekateri nabori vrednosti, ki temeljijo na sistemih kodiranja iz te priloge, kot so sistemi kodiranja za cepljenje in hitre antigenske teste, pogosto spreminjajo, jih Komisija objavi in redno posodablja ob pomoči mreže e-zdravje in Odbora za zdravstveno varnost. Posodobljeni nabori vrednosti se objavijo na ustreznem spletnem mestu Komisije, pa tudi na spletni strani mreže e-zdravje. Zagotoviti je treba zgodovino sprememb.

1. Ciljna bolezen ali njen povzročitelj / bolezen ali njen povzročitelj, ki jo/ga je imetnik prebolel: COVID-19 (SARS-CoV-2 ali ena od njegovih različic)

Uporabljati v potrdilih 1, 2 in 3.

Uporablja se naslednja koda:







Koda Prikazovalnik Ime kodnega sistema Naslov URL kodnega sistema Identifikacijska oznaka kodnega sistema Različica kodnega sistema 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

2. Cepivo ali profilaksa proti COVID-19

Prednostni kodni sistem: SNOMED CT ali klasifikacija ATC

Uporabljati v potrdilu 1.

Primeri kod iz prednostnih kodnih sistemov, ki jih je treba uporabljati, so kode SNOMED CT 1119305005 (antigensko cepivo proti SARS-CoV-2), 1119349007 (cepivo mRNK proti SARS-CoV-2) ali J07BX03 (cepiva proti COVID-19).

Nabor vrednosti, ki določa kode, ki se uporabljajo v skladu s kodnimi sistemi, vzpostavljenimi v tem oddelku, Komisija objavi in redno posodablja ob pomoči mreže e-zdravje. Ko se razvijejo in začnejo uporabljati nove vrste cepiv, se nabor vrednosti razširi.

3. Zdravilo (cepivo) proti COVID-19

Prednostni kodni sistemi (v prednostnem vrstnem redu):

— register zdravil Unije za cepiva z dovoljenjem, ki velja za celotno EU (številke dovoljenj);

— svetovni register cepiv, kot bi ga lahko vzpostavila na primer Svetovna zdravstvena organizacija;

— v drugih primerih ime zdravila (cepiva). Če ime vključuje presledke, jih je treba nadomestiti z vezajem (-).

Ime nabora vrednosti: cepivo.

Uporabljati v potrdilu 1.

Primer kode iz prednostnih kodnih sistemov, ki jo je treba uporabljati, je EU/1/20/1528 (Comirnaty). Primer imena cepiva, ki se uporabi kot koda: Sputnik-V (kar pomeni cepivo Sputnik V).

Nabor vrednosti, ki določa kode, ki se uporabljajo v skladu s kodnimi sistemi, vzpostavljenimi v tem oddelku, Komisija objavi in redno posodablja ob pomoči mreže e-zdravje.

Cepiva se kodirajo z obstoječo kodo v objavljenem naboru vrednosti, tudi če se njihova imena v različnih državah razlikujejo. Razlog za to je, da še ni globalnega registra cepiv, ki bi zajemal vsa cepiva, ki se trenutno uporabljajo. Primer:

— za cepivo „COVID-19 Vaccine Moderna Intramuscular Injection“, ki je ime cepiva Spikevax na Japonskem, uporabite kodo EU/1/20/1507, saj je to ime cepiva v EU.

Če to v posameznem primeru ni mogoče ali priporočljivo, bo v objavljenem naboru vrednosti navedena ločena koda.

4. Imetnik dovoljenja za promet s cepivom proti COVID-19 ali izdelovalec cepiva

Prednostni kodni sistem:

— koda organizacije Evropske agencije za zdravila (sistem SPOR za ISO IDMP);

— svetovni register imetnikov dovoljenj za promet s cepivom ali izdelovalcev cepiv, kot bi ga lahko vzpostavila na primer Svetovna zdravstvena organizacija;

— v drugih primerih ime organizacije. Če ime vključuje presledke, jih je treba nadomestiti z vezajem (-).

Uporabljati v potrdilu 1.

Primer kode iz prednostnega kodnega sistema, ki se uporabi, je ORG-100001699 (AstraZeneca AB). Primer imena organizacije, ki se uporabi kot koda: Sinovac-Biotech (kar pomeni Sinovac Biotech).

Nabor vrednosti, ki določa kode, ki se uporabljajo v skladu s kodnimi sistemi, vzpostavljenimi v tem oddelku, Komisija objavi in redno posodablja ob pomoči mreže e-zdravje.

Različne podružnice istega imetnika dovoljenja za promet z zdravilom ali istega izdelovalca cepiv uporabijo obstoječo kodo v objavljenem naboru vrednosti.

Praviloma se za isto cepivo uporablja koda, ki se nanaša na imetnika dovoljenja za promet z zdravilom v EU, saj še ni mednarodno dogovorjenega registra izdelovalcev cepiva ali imetnikov dovoljenja za promet z zdravilom. Primeri:

— za organizacijo „Pfizer AG“, ki je imetnik dovoljenja za promet s cepivom „Comirnaty“, ki se uporablja v Švici, uporabite kodo ORG-100030215, ki se nanaša na BioNTech Manufacturing GmbH, saj je ta imetnik dovoljenja za promet z zdravilom Comirnaty v EU;

— za organizacijo „Zuellig Pharma“, ki je imetnik dovoljenja za promet z zdravilom za cepivo Covid-19 Vaccine Moderna (Spikevax), ki se uporablja na Filipinih, uporabite kodo ORG-100031184, ki se nanaša na Moderno Biotech Spain S.L., saj je ta imetnik dovoljenja za promet z zdravilom Spikevax v EU.

Če to v posameznem primeru ni mogoče ali priporočljivo, bo v objavljenem naboru vrednosti navedena ločena koda.

5. Številka odmerka v seriji in skupno število odmerkov v seriji

Uporabljati v potrdilu 1.

Dve polji:

(1) številka odmerka v seriji cepljenja proti COVID-19 (N);

(2) skupno število odmerkov v seriji cepljenja (C).

5.1. Serija primarnega cepljenja

Kadar oseba prejema odmerke iz serije primarnega cepljenja, tj. serija cepljenja, namenjena zagotavljanju zadostne zaščite v začetni fazi, (C) odraža skupno število odmerkov iz standardne serije primarnega cepljenja (npr. 1 ali 2, odvisno od vrste uporabljenega cepiva). To vključuje možnost uporabe krajše serije cepljenja (C = 1), kadar protokol cepljenja, ki ga uporablja država članica, določa dajanje enkratnega odmerka cepiva z dvema odmerkoma osebam, ki so bile predhodno okužene z virusom SARS-CoV-2. Zaključena serija primarnega cepljenja se tako označi z N/C = 1. Na primer:

— 1/1 označuje zaključek serije primarnega cepljenja z enkratnim odmerkom ali zaključek serije primarnega cepljenja, ki ga sestavlja en odmerek cepiva z dvema odmerkoma, ki ga je prejela oseba, ki je prebolela okužbo, v skladu s protokolom cepljenja, ki ga uporablja država članica;

— 2/2 označuje zaključek serije primarnega cepljenja z dvema odmerkoma.

Kadar se serija primarnega cepljenja podaljša, na primer za osebe z močno oslabljenim imunskim sistemom ali kadar priporočeni interval med odmerki v primarnem cepljenju ni bil upoštevan, se vsi taki odmerki kodirajo kot dodatni odmerki iz oddelka 5.2.

▼M2

5.2. Poživitveni odmerki

Kadar oseba prejme odmerke po primarni seriji cepljenja, se taki poživitveni odmerki navedejo v ustreznih potrdilih, kot sledi:

— 2/1 označuje dajanje poživitvenega odmerka po primarni seriji cepljenja z enkratnim odmerkom ali dajanje poživitvenega odmerka po zaključku primarne serije, ki jo sestavlja en odmerek cepiva z dvema odmerkoma, ki ga je prejela oseba, ki je prebolela okužbo, v skladu s protokolom cepljenja, ki ga uporablja država članica. Nato se odmerki (X), dani po prvem poživitvenem odmerku, označijo z (2+X)/(1) > 1 (na primer 3/1),

— 3/3 označuje dajanje poživitvenega odmerka po primarni seriji cepljenja z dvema odmerkoma. Nato se odmerki (X), dani po prvem poživitvenem odmerku, označijo s (3+X)/(3+X) = 1 (na primer 4/4).

Države članice uvedejo pravila kodiranja iz tega oddelka do 1. februarja 2022.

Države članice samodejno ali na zahtevo zadevnih oseb ponovno izdajo potrdila, v katerih je dajanje poživitvenega odmerka po primarni seriji cepljenja z enkratnim odmerkom kodirano tako, da ga ni mogoče razlikovati od zaključka primarne serije cepljenja.

V tej prilogi bi bilo treba sklice na „poživitvene odmerke“ razumeti tako, da zajemajo tudi dodatne odmerke za boljšo zaščito posameznikov, ki po zaključeni standardni primarni seriji cepljenja nimajo ustreznega imunskega odziva. Znotraj pravnega okvira, vzpostavljenega z Uredbo (EU) 2021/953, lahko države članice sprejmejo ukrepe za obravnavanje položaja ranljivih skupin, ki lahko prednostno prejmejo dodatne odmerke Če se na primer država članica odloči, da bo dodatne odmerke dajala samo določenim podskupinam prebivalstva, se lahko v skladu s členom 5(1) Uredbe (EU) 2021/953 odloči, da bo potrdila o cepljenju, v katerih je navedeno dajanje takih dodatnih odmerkov, izdala samo na zahtevo in ne avtomatično. Če se taki ukrepi sprejmejo, države članice o tem ustrezno obvestijo zadevne osebe, tudi o tem, da lahko še naprej uporabljajo potrdilo, ki so ga prejele po zaključku standardne serije primarnega cepljenja.

▼M1

6. Država članica ali tretja država, v kateri je bilo opravljeno cepljenje/testiranje

Prednostni kodni sistem: kode držav po ISO 3166

Uporabljati v potrdilih 1, 2 in 3.

Vsebina nabora vrednosti: celoten seznam dvočrkovnih kod, ki je na voljo kot nabor vrednosti, opredeljen v standardu FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). Če je cepljenje ali test izvedla mednarodna organizacija (kot sta UNHCR ali SZO) in informacije o državi niso na voljo, se uporabi koda za organizacijo. Take dodatne kode objavi in redno posodablja Komisija ob pomoči mreže e-zdravje.

7. Vrsta testa

Uporabljati v potrdilu 2 oziroma potrdilu 3, če se z delegiranim aktom uvede podpora za izdajo potrdil o preboleli bolezni na podlagi vrst testov, ki niso amplifikacijski test nukleinske kisline (NAAT).

Uporabljajo se naslednje kode:







Koda Prikazovalnik Ime kodnega sistema Naslov URL kodnega sistema Identifikacijska oznaka kodnega sistema Različica kodnega sistema LP6464-4 Pomnoževanje nukleinskih kislin z zaznavanjem s sondo LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Hitri imunološki preskus LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

8. Izdelovalec cepiva in trgovsko ime uporabljenega testa (neobvezno za test NAAT)

Uporabljati v potrdilu 2.

Vsebina nabora vrednosti vključuje izbiro hitrega antigenskega testa, kot je naveden na skupnem in posodobljenem seznamu hitrih antigenskih testov na COVID-19, uvedenem na podlagi Priporočila Sveta 2021/C 24/01 in dogovorjenem z Odborom za zdravstveno varnost. Seznam vodi JRC v okviru podatkovne zbirke in vitro diagnostičnih medicinskih pripomočkov in metod testiranja na COVID-19 na spletnem naslovu: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

Za ta kodni sistem se uporabljajo ustrezna polja, kot so identifikacijska oznaka naprave za testiranje, ime testa in izdelovalec, v skladu s strukturiranim formatom JRC, ki je na voljo na spletnem naslovu: https://covid-19-diagnostics.jrc.ec.europa.eu/devices.

9. Rezultat testa

Uporabljati v potrdilu 2.

Uporabljajo se naslednje kode:







Koda Prikazovalnik Ime kodnega sistema Naslov URL kodnega sistema Identifikacijska oznaka kodnega sistema Različica kodnega sistema 260415000 Okužba ni odkrita SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Okužba odkrita SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼B









PRILOGA III

SKUPNA STRUKTURA EDINSTVENE IDENTIFIKACIJSKE OZNAKE POTRDILA

1. Uvod

Vsako digitalno COVID potrdilo EU (DCC) vključuje edinstveno identifikacijsko oznako potrdila (UCI), ki podpira interoperabilnost potrdil DCC. UCI se lahko uporablja za preverjanje potrdila. Za uvedbo UCI so odgovorne države članice. UCI je sredstvo za preverjanje verodostojnosti potrdila in za povezavo s sistemom za registracijo (npr. IIS), kjer je to ustrezno. Te identifikacijske oznake omogočajo tudi navedbe držav članic (na papirju in v digitalni obliki), da so bili posamezniki cepljeni ali testirani.

2. Sestava edinstvene identifikacijske oznake potrdila

UCI ima skupno strukturo in format, ki lajšata interpretabilnost za človeka in/ali stroj, ter se lahko nanaša na elemente, kot so država članica cepljenja, samo cepivo in posebna identifikacijska oznaka države članice. Državam članicam zagotavlja prožnost pri njenem oblikovanju ob popolnem spoštovanju zakonodaje o varstvu podatkov. Vrstni red ločenih elementov sledi opredeljeni hierarhiji, ki omogoča prihodnje spremembe gradnikov, hkrati pa ohranja strukturno celovitost.

Možne rešitve za sestavo UCI tvorijo spekter, pri katerem sta modularnost in interpretabilnost za ljudi glavna parametra diverzifikacije in temeljna značilnost:

— modularnost: v kakšnem obsegu je koda sestavljena iz različnih gradnikov, ki vsebujejo semantično različne informacije;

— interpretabilnost za ljudi: kako smiselna je koda za človeškega bralca ali v kakšnem obsegu jo lahko človeški bralec razlaga;

— edinstvenost na svetovni ravni; identifikacijska oznaka države ali organa je dobro upravljana, poleg tega se od vsake države (organa) pričakuje, da bo dobro upravljala svoj segment imenskega prostora in da identifikacijskih oznak ne bo nikoli ponovno uporabila ali izdala. Kombinacija teh značilnosti zagotavlja, da je vsaka identifikacijska oznaka edinstvena na svetovni ravni.

▼M1

3. Splošne zahteve

V zvezi z edinstveno identifikacijsko oznako (oznaka UCI) potrdila je treba izpolniti naslednje splošne zahteve:

(1) nabor znakov: dovoljeni so samo alfanumerični znaki (velike črke) US-ASCII („A“ do „Z“, „0“ do „9“) in dodatni posebni znaki za ločevanje od RFC3986 ( 14 ), in sicer {„/“, „#“, „:“};

(2) največja dolžina: oblikovalci si morajo prizadevati za dolžino od 27 do 30 znakov ( 15 );

(3) predpona različice: nanaša se na različico sheme UCI. Predpona različice za to različico dokumenta je „01“; sestavljena je iz dveh števk;

(4) predpona države: oznaka države je določena s standardom ISO 3166-1. Daljše oznake (npr. trije znaki in več (npr. „UNHCR“)) so rezervirane za prihodnjo uporabo;

(5) pripona kode / kontrolna vsota: 5.1 države članice lahko uporabijo kontrolno vsoto, kadar obstaja verjetnost prenosa, (človeškega) prepisa ali drugih napak (tj. pri uporabi tiskane oblike); 5.2 kontrolna vsota se ne sme uporabljati za preverjanje veljavnosti potrdila in tehnično ni del identifikacijske oznake, ampak se uporablja za preverjanje celovitosti kode. Ta kontrolna vsota mora biti povzetek celotne oznake UCI v formatu za digitalni prenos / prenos po žici v skladu z ISO-7812-1 (LUHN-10) ( 16 ). Kontrolna vsota je od preostalega dela oznake UCI ločena z znakom „#“.

Zagotoviti je treba združljivost za nazaj: države članice, ki v daljšem časovnem obdobju spremenijo strukturo identifikacijskih oznak (v okviru glavne različice, ki je trenutno v1), zagotovijo, da kateri koli enaki identifikacijski oznaki predstavljata isto potrdilo/navedbo o cepljenju. Povedano drugače, države članice identifikacijskih oznak ne morejo ponovno uporabiti.

▼B

4. Možnosti za edinstvene identifikacijske oznake potrdil za potrdila o cepljenju

Smernice mreže e-zdravje za preverljiva potrdila o cepljenju in osnovne elemente interoperabilnosti ( 17 ) določajo različne možnosti, ki so na voljo državam članicam in drugim stranem in ki lahko soobstajajo v različnih državah članicah. Države članice lahko take različne možnosti uporabijo v različnih različicah sheme UCI.









PRILOGA IV

UPRAVLJANJE POTRDIL JAVNIH KLJUČEV

1. Uvod

Države članice si ključe za podpis digitalnih COVID potrdil EU (DCC) med sabo varno in na zaupanja vreden način izmenjujejo prek prehoda za digitalno COVID potrdilo EU (DCCG), ki deluje kot centralno odložišče javnih ključev. S prehodom DCCG so države članice pooblaščene za objavo javnih ključev, ki ustrezajo zasebnim ključem, ki jih uporabljajo za podpisovanje digitalnih COVID potrdil. Države članice, ki se zanašajo na prehod DCCG, ga lahko uporabljajo za pravočasno pridobitev posodobljenega materiala javnih ključev. Pozneje se lahko prehod DCCG razširi na izmenjavo zanesljivih dodatnih informacij, ki jih zagotovijo države članice, na primer pravil za potrjevanje potrdil DCC. Model zaupanja okvira potrdil DCC je infrastruktura javnih ključev (Public Key Infrastructure – PKI). Vsaka država članica ohranja enega ali več državnih overiteljev podpisnikov potrdil (Country Signing Certificate Authority – CSCA), katerih potrdila so razmeroma dolgotrajna. Po odločitvi države članice se lahko uporablja isti CSCA, kot se uporablja za strojno berljive potne listine, ali drug CSCA. CSCA izdaja potrdila javnih ključev za nacionalne kratkotrajne podpisovalnike dokumenta (tj. podpisovalnike za potrdila DCC), ki se imenujejo potrdila za podpisovalnike dokumenta (Document Signer Certificate – DSC). CSCA deluje kot sidro zaupanja, tako da lahko države članice, ki se zanašajo nanj, s potrdilom CSCA potrdijo verodostojnost in celovitost redno spreminjajočih se potrdil DSC. Ko so potrjena, lahko države članice ta potrdila (ali samo javne ključe, ki jih vsebujejo) naložijo v svoje aplikacije za potrjevanje potrdil DCC. Poleg potrdil CSCS in DSC se tudi prehod DCCG opira na infrastrukturo javnih ključev, in sicer za avtentikacijo transakcij in podpisovanje podatkov, kot na podlago za avtentikacijo in kot na način zagotavljanja celovitosti komunikacijskih kanalov med državami članicami in prehodom DCCG.

Digitalni podpisi se lahko uporabljajo za doseganje celovitosti in verodostojnosti podatkov. Infrastrukture javnih ključev vzpostavljajo zaupanje, tako da javne ključe povezujejo s preverjenimi identitetami (ali izdajatelji). To je potrebno, da lahko drugi udeleženci preverijo izvor podatkov in identiteto partnerja, s katerim komunicirajo, ter se odločijo glede zaupanja. Na prehodu DCCG se za verodostojnost uporablja več potrdil javnih ključev. Ta priloga določa, katera potrdila javnih ključev se uporabljajo in kako se oblikujejo, da se omogoči široka interoperabilnost med državami članicami. Zagotavlja več podrobnosti o potrebnih potrdilih javnih ključev ter smernice o predlogah potrdil in obdobjih veljavnosti za države članice, ki želijo upravljati svoja potrdila CSCA. Ker je potrdila DCC mogoče preveriti v določenem časovnem obdobju (od izdaje, veljavnost pa poteče po določenem času), je treba opredeliti model preverjanja za vse podpise, ki se uporabljajo na potrdilih javnih ključev in potrdilih DCC.

2. Terminologija

Naslednja preglednica vsebuje kratice in terminologijo, ki se uporabljajo v tej prilogi.







Pojem Opredelitev Potrdilo Ali potrdilo javnega ključa. Potrdilo X.509 v3, ki vsebuje javni ključ subjekta. CSCA Državni organ overitelj potrdila (Country Signing Certificate Authority). DCC Digitalno COVID potrdilo EU. Podpisan digitalni dokument, ki vsebuje informacije o cepljenju, testu ali preboleli bolezni. DCCG Prehod za digitalno COVID potrdilo EU. Ta sistem se uporablja za izmenjavo potrdil DSC med državami članicami. DCCGTA Potrdilo sidra zaupanja prehoda DCCG. Ustrezni zasebni ključ se uporablja za podpisovanje seznama vseh potrdil CSCA brez spletne povezave. DCCGTLS Potrdilo strežnika TLS na prehodu DCCG. DSC Potrdilo za podpisovalnik dokumenta. Potrdilo javnega ključa organa države članice za podpisovanje dokumentov (npr. sistem, ki lahko podpisuje potrdila DCC). To potrdilo izda CSCA države članice. EC-DSA Algoritem z eliptično krivuljo za digitalni podpis. Kriptografski algoritem za podpis, ki temelji na eliptičnih krivuljah. Država članica Država članica Evropske unije. mTLS Skupni protokol TLS (Transport Layer Security – varnost prenosnega sloja). Protokol TLS z medsebojno avtentikacijo. NB Nacionalno zaledje države članice. NBCSCA Potrdilo CSCA države članice (lahko je več kot eno). NBTLS Potrdilo nacionalnega zaledja za avtentikacijo odjemalca TLS. NBUP Potrdilo, ki ga nacionalno zaledje uporablja za podpisovanje podatkovnih paketov, naloženih na prehod DCCG. PKI Infrastruktura javnih ključev. Model zaupanja, ki temelji na potrdilih javnih ključev in organih overiteljih potrdila. RSA Asimetrični kriptografski algoritem na osnovi faktorizacije celih števil, ki se uporablja za digitalne podpise ali asimetrično šifriranje.

3. Komunikacijski tokovi in varnostne storitve prehoda DCCG

Ta oddelek vsebuje pregled komunikacijskih tokov in varnostnih storitev v sistemu DCCG. V njem je opredeljeno tudi, kateri ključi in potrdila se uporabljajo za zaščito komunikacije, naloženih informacij, potrdil DCC in podpisanega zanesljivega seznama, ki vsebuje vsa sprejeta potrdila CSCA. Prehod DCCG deluje kot podatkovno vozlišče, ki omogoča izmenjavo podpisanih podatkovnih paketov za države članice.

Naložene podatkovne pakete zagotavlja „take, kot so“, kar pomeni, da v paketih, ki jih prejme, ne dodaja ali briše potrdil DSC. Nacionalnemu zaledju držav članic se omogoči preverjanje celovitosti in verodostojnosti naloženih podatkov od konca do konca. Poleg tega bodo nacionalna zaledja in prehod DCCG uporabljali medsebojno avtentikacijo TLS za vzpostavitev varne povezave. Uporabljali jih bodo poleg podpisov v izmenjanih podatkih.

3.1. Avtentikacija in vzpostavitev povezave

Prehod DCCG uporablja protokol Transport Layer Security (TLS) z medsebojno avtentikacijo za vzpostavitev avtentificiranega šifriranega kanala med nacionalnim zaledjem države članice in okoljem prehoda. Zato ima prehod DCCG potrdilo strežnika TLS, okrajšano DCCGTLS, nacionalno zaledje pa potrdilo odjemalca TLS, okrajšano NBTLS. Predloge potrdil so na voljo v oddelku 5. Vsako nacionalno zaledje lahko zagotovi lastno potrdilo TLS. To potrdilo bo izrecno uvrščeno na beli seznam in ga bo zato lahko izdal organ overitelj potrdila, ki uživa javno zaupanje (npr. organ overitelj potrdila, ki upošteva osnovne zahteve foruma CA/Browser Forum), ali nacionalni organ overitelj potrdila ali pa je lahko samopodpisano potrdilo. Vsaka država članica je odgovorna za svoje nacionalne podatke in zaščito zasebnega ključa, ki ga uporablja za vzpostavitev povezave s prehodom DCCG. Za pristop „prinesi svoje potrdilo“ so potrebni natančno opredeljen postopek registracije in identifikacije ter postopka preklica in podaljšanja, kot je navedeno v oddelkih 4.1 4.2 in 4.3. Prehod DCCG uporablja beli seznam, na katerega se po uspešni registraciji dodajo potrdila TLS nacionalnih zaledij. Samo nacionalna zaledja, avtentificirana z zasebnim ključem, ki ustreza potrdilu z belega seznama, lahko vzpostavijo varno povezavo s prehodom DCCG. Prehod DCCG bo uporabljal tudi potrdilo TLS, ki nacionalnim zaledjem omogoča, da preverijo, ali dejansko vzpostavljajo povezavo s „pravim“ prehodom DCCG in ne s kakšno zlonamerno entiteto, ki se izdaja za prehod DCCG. Potrdilo prehoda DCCG bo nacionalnemu zaledju zagotovljeno po uspešni registraciji. Potrdilo DCCGTLS bo izdal organ overitelj potrdila, ki uživa javno zaupanje (in je vključen v vse glavne brskalnike). Države članice so odgovorne, da preverijo, ali je njihova povezava s prehodom DCCG varna (npr. s primerjanjem prstnega odtisa potrdila DCCGTLS povezanega strežnika s tistim, pridobljenim po registraciji).

3.2. Državni organi overitelji potrdila in model potrjevanja

Države članice, ki sodelujejo v okviru prehoda DCCG, morajo za izdajo potrdil DSC uporabljati CSCA. Države članice imajo lahko več kot en organ CSCA, na primer v primeru regionalne decentralizacije. Vsaka država članica lahko uporablja obstoječe organe overitelje potrdila ali pa za sistem potrdil DCC uvede poseben (po možnosti samopodpisan) organ overitelj potrdila.

Države članice morajo med uradnim postopkom vstopanja upravljavcu prehoda DCCG predložiti svoja potrdila CSCA. Po uspešni registraciji države članice (za več podrobnosti glej oddelek 4.1) bo upravljavec prehoda DCCG posodobil podpisan zanesljiv seznam, ki vsebuje vsa potrdila CSCA, aktivna v okviru potrdil DCC. Upravljavec prehoda DCCG bo v okolju brez spletne povezave z namenskim asimetričnim parom ključev podpisal zanesljivi seznam in potrdila. Zasebni ključ ne bo shranjen v spletnem sistemu DCCG, tako da ogroženost spletnega sistema napadalcu ne bo omogočila ogrožanja zanesljivega seznama. Ustrezno potrdilo sidra zaupanja DCCGTA bo nacionalnim zaledjem zagotovljeno med postopkom vstopanja.

Države članice lahko za svoje postopke preverjanja s prehoda DCCG pridobijo zanesljivi seznam. CSCA je opredeljen kot organ overitelj potrdila, ki izdaja potrdila DSC, zato morajo države članice, ki uporabljajo večstopenjsko hierarhijo organov overiteljev potrdila (npr. korenski organ overitelj potrdila -> CSCA -> potrdila DSC), zagotoviti podrejeni organ overitelj potrdila, ki izdaja potrdila DSC. V tem primeru, če država članica uporablja obstoječi organ overitelj potrdila, bo sistem potrdil DCC prezrl vse, kar je nad organom CSCA, in na beli seznam uvrstil samo CSCA kot sidro zaupanja (čeprav gre za podrejeni organ overitelj potrdila). Razlog za to je, da model ICAO omogoča le točno dve ravni – „korenski“ organ CSCA in potrdilo DSC končnega subjekta, ki ga podpiše le navedeni CSCA.

Če država članica upravlja svoj organ CSCA, je odgovorna za varno delovanje in upravljanje ključev tega organa overitelja potrdila. CSCA deluje kot sidro zaupanja za potrdila DSC, zato je zaščita zasebnega ključa CSCA bistvena za celovitost okolja potrdil DCC. Model preverjanja v infrastrukturi javnih ključev DCC je model Shell , v skladu s katerim morajo biti vsa potrdila pri potrjevanju poti potrdil veljavna v določenem trenutku (tj. ob potrditvi podpisa). Zato se uporabljajo naslednje omejitve:

— CSCA ne izdaja potrdil, ki so veljavna dlje časa kot samo potrdilo organa overitelja potrdila;

— podpisovalnik dokumenta ne podpisuje dokumentov, ki so veljavni dlje časa kot samo potrdilo DSC;

— države članice, ki upravljajo svoj organ CSCA, morajo določiti obdobja veljavnosti tega CSCA in vseh izdanih potrdil ter poskrbeti za podaljšanje potrdil.

Oddelek 4.2 vsebuje priporočila za obdobja veljavnosti.

3.3. Celovitost in verodostojnost naloženih podatkov

Nacionalna zaledja lahko prehod DCCG po uspešni medsebojni avtentikaciji uporabljajo za nalaganje in prenos digitalno podpisanih podatkovnih paketov. Na začetku ti podatkovni paketi vsebujejo potrdila DSC držav članic. Par ključev, ki ga nacionalno zaledje uporablja za digitalni podpis naloženih podatkovnih paketov v sistemu DCCG, se imenuje par ključev nacionalnega zaledja za podpis nalaganja, skrajšana oblika imena ustreznega potrdila javnega ključa pa je potrdilo NBUP. Vsaka država članica zagotovi svoje potrdilo NBUP, ki je lahko samopodpisano ali pa ga izda obstoječi organ overitelj potrdila, na primer javni organ overitelj potrdila (tj. organ, ki izda potrdilo v skladu z osnovnimi zahtevami foruma CAB (CA/Browser Forum)). Potrdilo NBUP se razlikuje od vseh drugih potrdil, ki jih uporablja država članica (tj. CSCA, odjemalec TLS ali potrdila DSC).

Države članice morajo med postopkom prve registracije upravljavcu prehoda DCCG zagotoviti potrdilo za nalaganje (za več podrobnosti glej oddelek 4.1). Vsaka država članica je odgovorna za svoje nacionalne podatke in mora zaščititi zasebni ključ, ki se uporablja za podpisovanje nalaganja.

Druge države članice lahko podpisane podatkovne pakete preverijo s potrdili za nalaganje, ki jih zagotovi prehod DCCG. Prehod DCCG s potrdilom nacionalnega zaledja za nalaganje preverja verodostojnost in celovitost naloženih podatkov, preden se ti zagotovijo drugim državam članicam.

3.4. Zahteve glede tehnične arhitekture prehoda DCCG

Zahteve glede tehnične arhitekture prehoda DCCG so naslednje:

— prehod DCCG uporablja medsebojno avtentikacijo TLS za vzpostavitev avtentificirane šifrirane povezave z nacionalnimi zaledji. Zato vodi beli seznam registriranih odjemalčevih potrdil NB TLS ;

— prehod DCCG uporablja dve digitalni potrdili (DCCG TLS in DCCG TA ) z dvema ločenima paroma ključev. Zasebni ključ para ključev DCCG TA se hrani v sistemu brez spletne povezave (ne na spletnih komponentah prehoda DCCG);

— prehod DCCG vodi zanesljivi seznam NB CSCA , ki je podpisan z zasebnim ključem DCCG TA ;

— uporabljene šifre morajo izpolnjevati zahteve iz oddelka 5.1 .

4. Upravljanje življenjskega cikla potrdil

4.1. Registracija nacionalnih zaledij

Države članice se morajo za sodelovanje v sistemu DCCG registrirati pri njegovem upravljavcu. V tem oddelku je opisan tehnični in operativni postopek, ki ga je treba upoštevati za registracijo nacionalnega zaledja.

Upravljavec prehoda DCCG in država članica si morata izmenjati informacije o kontaktnih tehnikih za postopek vstopanja. Predpostavlja se, da so kontaktne tehnike pooblastile države članice in da se identifikacija/avtentikacija izvaja prek drugih kanalov. Avtentikacija se lahko doseže na primer tako, da kontaktni tehnik države članice prek e-pošte predloži potrdila kot datoteke, šifrirane z geslom, ustrezno geslo pa upravljavcu prehoda DCCG sporoči po telefonu. Lahko se uporabljajo tudi drugi varni kanali, ki jih določi upravljavec prehoda DCCG.

Država članica mora med postopkom registracije in identifikacije predložiti tri digitalna potrdila:

— potrdilo TLS države članice NB TLS ,

— potrdilo NB UP države članice za nalaganje,

— potrdila CSCA države članice NB CSCA .

Vsa predložena potrdila morajo biti v skladu z zahtevami iz oddelka 5. Upravljavec prehoda DCCG bo preveril, ali predloženo potrdilo izpolnjuje zahteve iz oddelka 5. Po identifikaciji in registraciji upravljavec prehoda DCCG:

— doda potrdila NB CSCA na zanesljivi seznam, podpisan z zasebnim ključem, ki ustreza javnemu ključu DCCG TA ;

— doda potrdilo NB TLS na beli seznam končne točke TLS na prehodu DCCG ;

— doda potrdilo NB UP v sistem DCCG;

— državi članici zagotovi potrdili javnega ključa DCCG TA in DCCG TLS .

4.2. Organi overitelji potrdila, obdobja veljavnosti in podaljšanje

Če želi država članica upravljati svoj organ CSCA, so lahko potrdila CSCA samopodpisana. Delujejo kot sidro zaupanja države članice, zato mora država članica močno zaščititi zasebni ključ, ki ustreza javnemu ključu potrdila CSCA. Priporočljivo je, da države članice za svoj CSCA uporabljajo sistem brez spletne povezave, tj. računalniški sistem, ki ni povezan z nobenim omrežjem. Za dostop do sistema se uporablja nadzor več oseb (npr. v skladu z načelom štirih oči). Po podpisu potrdil DSC se uporabi operativni nadzor, sistem, v katerem je zasebni ključ CSCA, pa se varno shrani s strogim nadzorom dostopa. Za dodatno zaščito zasebnega ključa CSCA se lahko uporabijo varnostni moduli strojne opreme ali pametne kartice. Digitalna potrdila vsebujejo obdobje veljavnosti, ki zahteva podaljšanje potrdila. Podaljšanje je potrebno za uporabo svežih kriptografskih ključev in za prilagoditev velikosti ključev, kadar nove izboljšave računanja ali novi napadi ogrožajo varnost uporabljenega kriptografskega algoritma. Uporablja se model Shell (, glej oddelek 3.2).

Glede na enoletno veljavnost digitalnih COVID potrdil se priporočajo naslednja obdobja veljavnosti:

— CSCA: 4 leta;

— DSC: 2 leti;

— potrdilo za nalaganje: 1–2 leti;

— avtentikacija odjemalca TLS: 1–2 leti.

Za pravočasno podaljšanje se priporočajo naslednja obdobja uporabe zasebnega ključa:

— CSCA: 1 leto;

— DSC: 6 mesecev.

Države članice morajo pravočasno ustvariti nova potrdila za nalaganje in potrdila TLS, na primer en mesec pred potekom, da se omogoči nemoteno delovanje. Potrdila CSCA in DSC bi bilo treba podaljšati vsaj en mesec pred prenehanjem uporabe zasebnega ključa (ob upoštevanju potrebnih operativnih postopkov). Države članice morajo upravljavcu prehoda DCCG zagotoviti posodobljena potrdila CSCA, potrdila za nalaganje in potrdila TLS. Potekla potrdila se odstranijo z belega seznama in zanesljivega seznama.

Države članice in upravljavec prehoda DCCG morajo spremljati veljavnost svojih potrdil. Ni centralnega subjekta, ki bi vodil evidenco o veljavnosti potrdil in obveščal udeležence.

4.3. Preklic potrdil

Digitalna potrdila lahko na splošno prekliče organ overitelj potrdila (CA), ki jih je izdal, pri čemer uporabi sezname preklicanih potrdil ali odzivnik spletnega protokola za status potrdila (Online Certificate Status Protocol – OCSP). Sezname preklicanih potrdil bi morali zagotoviti organi CSCA za sistem potrdil DCC. Tudi če druge države članice trenutno ne uporabljajo teh seznamov preklicanih potrdil, bi jih bilo treba vključiti za prihodnjo uporabo. Če se organ CSCA odloči, da ne bo predložil seznamov preklicanih potrdil, je treba potrdila DSC tega organa CSCA podaljšati, ko seznami preklicanih potrdil postanejo obvezni. Preveritelji za potrditev potrdil DSC ne bi smeli uporabljati odzivnika OCSP, ampak sezname preklicanih potrdil. Priporočljivo je, da nacionalno zaledje izvede potrebno potrditev potrdil DSC, prenesenih s prehoda DCC, in nacionalnim potrjevalcem potrdil DCC posreduje samo nabor zaupanja vrednih in potrjenih potrdil DSC. Potrjevalci potrdil DCC v postopku potrjevanja ne bi smeli preverjati preklicev DSC. Eden od razlogov za to je varovanje zasebnosti imetnikov potrdil DCC, pri čemer se prepreči kakršna koli možnost, da bi lahko odzivnik OCSP, povezan z določenim potrdilom DSC, spremljal uporabo tega potrdila.

Države članice lahko svoja potrdila DSC same odstranijo s prehoda DCCG z veljavnimi potrdili za nalaganje in potrdili TLS. Odstranitev potrdila DSC pomeni, da bodo vsa potrdila DCC, izdana s tem potrdilom DSC, postala neveljavna, ko bodo države članice pridobile posodobljene sezname DSC. Zaščita materiala zasebnih ključev, ki ustreza potrdilom DSC, je ključna. Države članice morajo upravljavca prehoda DCCG obvestiti, ko morajo preklicati potrdila za nalaganje ali potrdila TLS, na primer zaradi ogrožanja nacionalnega zaledja. Nato lahko upravljavec prehoda DCCG prekliče zaupanje za ogroženo potrdilo, na primer tako, da potrdilo odstrani z belega seznama TLS. Potrdila za nalaganje lahko odstrani iz podatkovne zbirke prehoda DCCG. Paketi, podpisani z zasebnim ključem, ki ustreza temu potrdilu za nalaganje, bodo postali neveljavni, ko bodo nacionalna zaledja preklicala zaupanje v zvezi s preklicanim potrdilom za nalaganje. Če je treba preklicati potrdilo CSCA, države članice o tem obvestijo upravljavca prehoda DCCG in druge države članice, s katerimi imajo vzpostavljen odnos zaupanja. Upravljavec prehoda DCCG bo izdal nov zanesljiv seznam, ki ne bo več vseboval ogroženega potrdila. Vsa potrdila DSC, ki jih je izdal ta CSCA, bodo postala neveljavna, ko bodo države članice posodobile shrambo zaupanja vrednih potrdil v okviru svojega nacionalnega zaledja. Če je treba preklicati potrdilo DCCGTLS ali potrdilo DCCGTA, morajo upravljavec prehoda DCCG in države članice skupaj vzpostaviti novo zaupanja vredno povezavo TLS in zanesljivi seznam.

5. Predloge potrdil

V tem oddelku so določene kriptografske zahteve in smernice ter zahteve glede predlog potrdil. Poleg tega so v njem opredeljene predloge za potrdila DCCG.

5.1. Kriptografske zahteve

Kriptografski algoritmi in nabori šifer TLS se izberejo na podlagi trenutnega priporočila nemškega zveznega urada za informacijsko varnost (Bundesamt für Sicherheit in der Informationstechnik – BSI) ali SOG-IS. Ta priporočila in priporočila drugih institucij in organizacij za standardizacijo so podobna. Priporočila so na voljo v tehničnih smernicah TR 02102-1 in TR 02102-2 ( 18 ) ali dokumentu SOG-IS Agreed Cryptographic Mechanisms ( 19 ) (Dogovorjeni kriptografski mehanizmi SOG-IS).

5.1.1. Zahteve glede DSC

Uporabljajo se zahteve iz oddelka 3.2.2 Priloge I. Zato je zelo priporočljivo, da podpisovalniki dokumentov uporabljajo algoritem z eliptično krivuljo za digitalni podpis (ECDSA) s krivuljo NIST-p-256 (kot je opredeljena v Dodatku D k standardu FIPS PUB 186-4). Druge eliptične krivulje niso podprte. Zaradi prostorskih omejitev DCC države članice ne bi smele uporabljati algoritma RSA-PSS, niti če je dovoljen kot algoritem za ponovno pridobitev. Če države članice uporabljajo algoritem RSA-PSS, bi morale uporabljati velikost modula 2048 bitov ali največ 3072 bitov. Kot kriptografska zgoščevalna funkcija za podpis potrdil DSC se uporablja SHA-2 z izhodno dolžino ≥ 256 bitov (glej standard ISO/IEC 10118-3:2004).

5.1.2. Zahteve glede potrdila TLS, potrdila za nalaganje in potrdila CSCA

Kar zadeva digitalna potrdila in kriptografske podpise v okviru prehoda DCCG, so glavne zahteve glede kriptografskih algoritmov in dolžine ključev povzete v naslednji preglednici (od leta 2021):







Algoritem za podpis Velikost ključa Zgoščevalna funkcija EC-DSA Najmanj 250 bitov SHA-2 z izhodno dolžino ≥ 256 bitov RSA-PSS (priporočeno zapolnjevanje) RSA-PKCS#1 v1.5 (uveljavljeno zapolnjevanje) Najmanj 3000-bitni modul RSA (N) z javnim eksponentom e > 2^16 SHA-2 z izhodno dolžino ≥ 256 bitov DSA Najmanj 3000-bitno praštevilo p, 250-bitni ključ q SHA-2 z izhodno dolžino ≥ 256 bitov

Priporočena eliptična krivulja za EC-DSA je NIST-p-256 zaradi njene široke uporabe.

5.2. Potrdilo CSCA (NBCSCA)

Naslednja preglednica vsebuje smernice glede predloge potrdila NBCSCA, če se država članica odloči, da bo za sistem potrdil DCC upravljala svoj CSCA.

Vnosi v krepkem tisku so obvezni (morajo biti vključeni v potrdilo), vnosi v ležečem tisku pa so priporočeni (bi jih bilo treba vključiti). Za polja, ki niso prikazana v preglednici, ni opredeljenih priporočil.







Polje Vrednost Imetnik cn=<edinstveno splošno ime, ki ni prazno>, o=<ponudnik>, c=<država članica, ki upravlja CSCA> Uporaba ključa (vsaj) podpisovanje potrdil, podpisovanje seznama preklicanih potrdil Osnovne omejitve CA = true, path length constraints = 0

Ime imetnika mora biti edinstveno v zadevni državi članici in ne sme biti prazno. Oznaka države (c) se mora ujemati z državo članico, ki bo uporabljala to potrdilo CSCA. Potrdilo mora vsebovati edinstveno identifikacijsko oznako imetnikovega ključa (SKI) v skladu z RFC 5280 ( 20 ).

5.3. Potrdilo za podpisovalnik dokumenta (DSC)

Naslednja preglednica vsebuje smernice za potrdilo DSC. Vnosi v krepkem tisku so obvezni (morajo biti vključeni v potrdilo), vnosi v ležečem tisku pa so priporočeni (bi jih bilo treba vključiti). Za polja, ki niso prikazana v preglednici, ni opredeljenih priporočil.







Polje Vrednost Serijska številka edinstvena serijska številka Imetnik cn=<edinstveno splošno ime, ki ni prazno>, o=<ponudnik>, c=<država članica, ki uporablja to potrdilo DSC> Uporaba ključa (vsaj) digitalni podpis

Potrdilo DSC mora biti podpisano z zasebnim ključem, ki ustreza potrdilu CSCA, ki ga uporablja država članica.

Uporabljajo se naslednje razširitve:

— Potrdilo mora vsebovati identifikacijsko oznako organovega ključa (Authority Key Identifier – AKI), ki se ujema z identifikacijsko oznako imetnikovega ključa (Subject Key Identifier – SKI) potrdila izdajatelja CSCA.

— Potrdilo bi moralo vsebovati edinstveno identifikacijsko oznako imetnikovega ključa (v skladu z RFC 5280 ( 21 )).

Poleg tega bi moralo potrdilo vsebovati razširitev razpošiljevalne točke CRL, ki napotuje na seznam preklicanih potrdil (CRL), ki ga zagotovi C SCA, ki je izdal potrdilo DSC.

Potrdilo DSC lahko vsebuje razširitev za uporabo razširjenega ključa z nič ali več identifikacijskimi oznakami politike uporabe ključa, s katerimi je omejena vrsta potrdil HCERT, ki jih lahko preveri to potrdilo. Če je prisotna ena ali več identifikacijskih oznak, preveritelji primerjajo uporabo ključa s shranjenim potrdilom HCERT. V ta namen so opredeljene naslednje vrednosti extendedKeyUsage:







Polje Vrednost extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 za izdajatelje potrdil o testiranju extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 za izdajatelje potrdil o cepljenju extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 za izdajatelje potrdil o preboleli bolezni

Če ni razširitve za uporabo ključa (tj. ni razširitev ali pa so prisotne nične razširitve), se lahko to potrdilo uporablja za potrditev katere koli vrste potrdila HCERT. V drugih dokumentih so lahko opredeljene ustrezne dodatne identifikacijske oznake politike uporabe razširjenega ključa, ki se uporabljajo pri potrjevanju potrdil HCERT.

5.4. Potrdila za nalaganje (NBUP)

Naslednja preglednica vsebuje smernice za potrdilo nacionalnega zaledja za nalaganje. Vnosi v krepkem tisku so obvezni (morajo biti vključeni v potrdilo), vnosi v ležečem tisku pa so priporočeni (bi jih bilo treba vključiti). Za polja, ki niso prikazana v preglednici, ni opredeljenih priporočil.







Polje Vrednost Imetnik cn=<edinstveno splošno ime, ki ni prazno>, o=<ponudnik>, c=<država članica, ki uporablja to potrdilo za nalaganje> Uporaba ključa (vsaj) digitalni podpis

5.5. Avtentikacija odjemalca TLS v nacionalnem zaledju (NBTLS)

Naslednja preglednica vsebuje smernice za potrdilo nacionalnega zaledja za avtentikacijo odjemalca TLS. Vnosi v krepkem tisku so obvezni (morajo biti vključeni v potrdilo), vnosi v ležečem tisku pa so priporočeni (bi jih bilo treba vključiti). Za polja, ki niso prikazana v preglednici, ni opredeljenih priporočil.







Polje Vrednost Imetnik cn=<edinstveno splošno ime, ki ni prazno>, o=<ponudnik>, c=<nacionalno zaledje države članice> Uporaba ključa (vsaj) digitalni podpis Uporaba razširjenega ključa avtentikacija odjemalca (1.3.6.1.5.5.7.3.2)

Potrdilo lahko vsebuje tudi uporabo razširjenega ključa za avtentikacijo strežnika (1.3.6.1.5.5.7.3.1), vendar to ni obvezno.

5.6. Potrdilo za podpis zanesljivega seznama (DCCGTA)

V naslednji preglednici je opredeljeno potrdilo sidra zaupanja DCCG.







Polje Vrednost Imetnik cn=prehod za digitalno zeleno potrdilo (1) , o=<ponudnik>, c=<država> Uporaba ključa (vsaj) digitalni podpis ( 1 ) V tem okviru je namesto „digitalno COVID potrdilo EU“ ohranjen izraz „digitalno zeleno potrdilo“, ker je bil ta izraz trdo kodiran in uveden v potrdilo, preden sta se sozakonodajalca odločila za novo terminologijo.

5.7. Potrdila strežnika TLS na prehodu DCCG (DCCGTLS)

V naslednji preglednici je opredeljeno potrdilo TLS na prehodu DCCG.







Polje Vrednost Imetnik cn=<ime FQDN ali naslov IP DCCG>, o=<ponudnik>, c= <država> SubjectAltName dnsName: <ime DNS DCCG> ali iPAddress: <naslov IP DCCG> Uporaba ključa (vsaj) digitalni podpis Uporaba razširjenega ključa avtentikacija strežnika (1.3.6.1.5.5.7.3.1)

Potrdilo lahko vsebuje tudi uporabo razširjenega ključa za avtentikacijo odjemalca (1.3.6.1.5.5.7.3.2), vendar to ni obvezno.

Potrdilo TLS na prehodu DCCG izda organ overitelj potrdila, ki uživa javno zaupanje (in je vključen v vse glavne brskalnike in operacijske sisteme v skladu z osnovnimi zahtevami foruma CAB).

▼M1









PRILOGA V

SHEMA JSON (JAVASCRIPT OBJECT NOTATION)

1. Uvod

Ta priloga določa tehnično strukturo podatkov za digitalna COVID potrdila EU, ki je predstavljena kot shema JSON. Dokument vsebuje posebna navodila v zvezi s posameznimi podatkovnimi polji.

2. Lokacija in različice sheme JSON

Edina verodostojna uradna shema JSON za digitalna COVID potrdila EU je na voljo na spletni strani https://github.com/ehn-dcc-development/ehn-dcc-schema. Druge lokacije niso verodostojne, vendar se lahko uporabijo za pripravo prihodnjih sprememb.

Avtomatično je trenutna različica, kot je določena v tej prilogi in jo podpirajo vse države ter trenutno pripravlja potrdila, prikazana pod navedenim URL.

Prihodnja različica, ki jo morajo do določenega datuma potrditi vse države, je prikazana pod navedenim URL z oznako različic (version tagging), ki je podrobneje opisana v datoteki Readme.

▼M3

3. Skupne strukture in splošne zahteve

Digitalno COVID potrdilo EU se ne izda, če zaradi manjkajočih informacij ni mogoče pravilno izpolniti vseh podatkovnih polj v skladu s to specifikacijo. To ne vpliva na obveznost držav članic, da izdajajo digitalna COVID potrdila EU.

Informacije v vseh poljih se lahko navedejo z uporabo celotnega nabora znakov UNICODE 13.0, kodiranih z uporabo UTF-8, razen če so posebej omejeni na nabore vrednosti ali ožji nabor znakov.

Skupna struktura je naslednja:

"JSON":{

"ver":<informacije o različici>,

"nam":{

<informacije o imenu osebe>

},

"dob":<datum rojstva>,

"v" ali "t" ali "r":[

{<< odmerek cepiva ali podatki o testu ali prebolevnosti, en vnos>}

]

}

Podrobne informacije o posameznih skupinah in poljih so na voljo v naslednjih oddelkih.

Kadar pravila določajo, da se polje preskoči, to pomeni, da je njegova vsebina prazna in da v vsebini nista dovoljena niti ime niti vrednost polja.

3.1 Različica

Zagotovijo se informacije o različici. Različica sledi sistemu semantičnega določanja različic (semver: https://semver.org). Pri pripravi potrdil je to ena od uradno objavljenih različic (trenutna ali ena od starejših uradno objavljenih različic). Za več podrobnosti glej oddelek JSON Schema location.







ID polja Ime polja Navodila ver Različica sheme Ujemati se mora z identifikacijsko oznako različice sheme, ki se uporablja za pripravo digitalnega COVID potrdila EU. Primer: "ver":"1.3.0"

3.2 Ime in datum rojstva osebe

Ime osebe je uradno polno ime osebe, ki se ujema z imenom, navedenim na potnih listinah. Identifikacijska oznaka strukture je nam. Zagotovi se natanko eno (1) ime osebe.







ID polja Ime polja Navodila nam/fn Priimek(-ki) Priimek(-ki) imetnika. Če imetnik nima priimkov in ima ime, se polje preskoči. V vseh drugih primerih je treba navesti natanko 1 (eno) neprazno polje, ki vključuje vse priimke. V primeru več priimkov so ti ločeni s presledkom. Vendar morajo kombinirana imena, vključno z vezajem ali podobnimi znaki, ostati enaka. Primeri: "fn":"Musterfrau-Gößinger" "fn":"Musterfrau-Gößinger Müller" nam/fnt Standardiziran(-i) priimek(-ki) Priimek(-ki) imetnika, prečrkovani z uporabo iste konvencije, kot se uporablja v strojno berljivih potnih listinah imetnika (kot so na primer pravila, opredeljena v dokumentu ICAO 9303, del 3). Če imetnik nima priimkov in ima ime, se polje preskoči. V vseh drugih primerih se zagotovi natanko eno (1) neprazno polje, ki vključuje samo znake A–Z in <. Največja dolžina: 80 znakov (v skladu s specifikacijo ICAO 9303). Primeri: "fnt":"MUSTERFRAU<GOESSINGER" "fnt":"MUSTERFRAU<GOESSINGER<MUELLER" nam/gn Ime(-na) Ime(-na), na primer rojstno(-a) ime(-na) imetnika. Če imetnik nima imen in ima priimek, se polje preskoči. V vseh drugih primerih se zagotovi natanko eno (1) neprazno polje, ki vključuje vsa imena. V primeru več imen so ta ločena s presledkom. Primer: "gn":"Isolde Erika" nam/gnt Standardiziran(-a) ime(-na) Ime(-na) imetnika, prečrkovana z uporabo iste konvencije, kot se uporablja v strojno berljivih potovalnih dokumentih imetnika (kot so na primer pravila, opredeljena v dokumentu ICAO 9303, del 3). Če imetnik nima imen in ima priimek, se polje preskoči. V vseh drugih primerih se zagotovi natanko eno (1) neprazno polje, ki vključuje samo znake A–Z in <. Največja dolžina: 80 znakov. Primer: "gnt":"ISOLDE<ERIKA" dob Datum rojstva Datum rojstva imetnika potrdila digitalnega COVID potrdila EU. Popolni ali delni datum brez časovne omejitve, omejen na razpon od 1900-01-01 do 2099-12-31. Če je znan popolni ali delni datum rojstva, se zagotovi natanko eno (1) neprazno polje. Če datum rojstva ni znan niti delno, se v polje vnese prazen niz „“. To bi se moralo ujemati z informacijami, kakor so navedene v potnih listinah. Če so na voljo informacije o datumu rojstva, se uporabi eden od naslednjih formatov ISO 8601. Druge možnosti niso podprte. YYYY-MM-DD YYYY-MM YYYY (Aplikacija za preverjanje lahko manjkajoče dele datuma rojstva označi z XX, kot pri strojno berljivih potovalnih listinah, npr. 1990-XX-XX.) Primeri: "dob":"1979-04-14" "dob":"1901-08" "dob":"1939" "dob":""

3.3 Skupine za posebne informacije o vrsti potrdila

Shema JSON podpira tri skupine vnosov, ki vključujejo posebne informacije o vrsti potrdila. Vsako digitalno COVID potrdilo EU mora vsebovati natanko eno (1) skupino. Prazne skupine niso dovoljene.







Identifikacijska oznaka skupine Ime skupine Vnosi v Skupina cepljeni Če je na voljo, mora vsebovati natanko en (1) vnos, ki navaja natanko en (1) odmerek cepiva (en odmerek). t Skupina testirani Če je na voljo, mora vsebovati natanko en (1) vnos, ki navaja natanko en (1) rezultat testiranja. r Skupina preboleli Če je na voljo, vsebuje natanko en (1) vnos, ki navaja natanko eno (1) izjavo o prebolelosti.

▼M1

4. Posebne informacije o vrsti potrdila

4.1. Potrdilo o cepljenju

Če je skupina cepljeni na voljo, mora vsebovati natanko en (1) vnos, ki navaja natanko eno cepljenje (en odmerek). Vsi elementi skupine cepljeni so obvezni, prazne vrednosti niso podprte.







ID polja Ime polja Navodila v/tg Ciljna bolezen ali povzročitelj: COVID-19 (SARS-CoV-2 ali ena od njegovih različic) Kodirana vrednost iz nabora vrednosti disease-agent-targeted.json. Ta vrednost ima en vnos 840539006, ki je koda za COVID-19 iz SNOMED CT (GPS). Zagotovi se natanko eno (1) neprazno polje. Primer: „tg“:„840539006“ v/vp Cepivo ali profilaksa proti COVID-19 Vrsta uporabljenega cepiva ali profilakse. Kodirana vrednost iz nabora vrednosti vaccine-prophylaxis.json. Nabor vrednosti se distribuira prek prehoda za digitalna COVID potrdila EU. Zagotovi se natanko eno (1) neprazno polje. Primer: „vp“:„1119349007“(cepivo proti virusu SARS-CoV-2 mRNA) v/mp Zdravilo (cepivo) proti COVID-19 Zdravilo, ki se uporablja za ta konkretni odmerek cepiva. Kodirana vrednost iz nabora vrednosti vaccine-medicinal-product.json. Nabor vrednosti se distribuira prek prehoda za digitalna COVID potrdila EU. Zagotovi se natanko eno (1) neprazno polje. Primer: „mp“:„EU/1/20/1528“ (Comirnaty) v/ma Imetnik dovoljenja za promet s cepivom proti COVID-19 ali izdelovalec cepiva Imetnik dovoljenja za promet s cepivom ali izdelovalec cepiva, če imetnik dovoljenja za promet s cepivom ne obstaja. Kodirana vrednost iz nabora vrednosti vaccine-mah-manf.json. Nabor vrednosti se distribuira prek prehoda za digitalna COVID potrdila EU. Zagotovi se natanko eno (1) neprazno polje. Primer: „ma“:„ORG-100030215“ (Biontech Manufacturing GmbH) v/dn Številka odmerka v seriji Zaporedna številka (pozitivno celo število) odmerka, danega med tem cepljenjem. 1 za prvi odmerek, 2 za drugi odmerek itd. V Prilogi II, oddelek 5, so navedena podrobnejša pravila. Zagotovi se natanko eno (1) neprazno polje. Primeri: „dn“:„1“ (prvi odmerek) „dn“:„2“(drugi odmerek) „dn“:„3“ (tretji odmerek) v/sd Skupno število odmerkov v seriji Skupno število odmerkov (pozitivno celo število) v seriji cepljenja Podrobnejša pravila so določena v Prilogi II, oddelek 5. Zagotovi se natanko eno (1) neprazno polje. Primeri: „sd“:„1“ (v primeru serije primarnega cepljenja z enim odmerkom) „sd“:„2“ (v primeru serije primarnega cepljenja z dvema odmerkoma ali dodatnega odmerka po seriji primarnega cepljenja z enim odmerkom) „sd“:„3“ (npr. v primeru dodatnih odmerkov po seriji primarnega cepljenja z dvema odmerkoma) v/dt Datum cepljenja Datum prejema opisanega odmerka v obliki LLLL-MM-DD (polni datum brez časovne omejitve). Drugi formati niso podprti. Zagotovi se natanko eno (1) neprazno polje. Primer: „dt“:„2021-03-28“ v/co Država članica ali tretja država, v kateri je bilo opravljeno cepljenje Država, izražena kot dvočrkovna oznaka ISO3166 (PRIPOROČENO) ali kot sklic na mednarodno organizacijo, pristojno za cepljenje (kot sta UNHCR ali SZO). Kodirana vrednost iz nabora vrednosti country-2-codes.json. Nabor vrednosti se distribuira prek prehoda za digitalna COVID potrdila EU. Zagotovi se natanko eno (1) prazno polje. Primer: „co“:„CZ“ „co“:„UNHCR“ v/is Izdajatelj potrdila Ime organizacije, ki je izdala potrdilo. Identifikacijske oznake se lahko uporabljajo kot del imena, vendar se priporoča, da se ne uporabljajo posamezno brez imena. Največ 80 znakov UTF-8. Zagotovi se natanko eno (1) neprazno polje. Primer: „is“:„Ministrstvo za zdravje Češke republike“ „is“:„Cepilni center za južno okrožje 3“ v/ci Edinstvena identifikacijska oznaka potrdila Edinstvena identifikacijska oznaka potrdila (oznaka UVCI), kot je določena v https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf Vključitev kontrolne vsote ni obvezna. Lahko se doda predpona „URN: UVCI:“. Zagotovi se natanko eno (1) neprazno polje. Primeri: „ci“:„URN:UVCI:01:NL:187/37512422923“ „ci“:„URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B“

4.2. Potrdilo o testiranju

Če je skupina testirani na voljo, mora vsebovati natanko en (1) vnos, ki navaja natanko en rezultat testiranja.







ID polja Ime polja Navodila t/tg Ciljna bolezen ali povzročitelj: COVID-19 (SARS-CoV-2 ali ena od njegovih različic) Kodirana vrednost iz nabora vrednosti disease-agent-targeted.json. Ta vrednost ima en vnos 840539006, ki je koda za COVID-19 iz SNOMED CT (GPS). Zagotovi se natanko eno (1) neprazno polje. Primer: „tg“:„840539006“ t/tt Vrsta testa Vrsta uporabljenega testa glede na material, uporabljen za testiranje. Kodirana vrednost iz nabora vrednosti test-type.json (na podlagi LOINC). Vrednosti zunaj nabora vrednosti niso dovoljene. Zagotovi se natanko eno (1) neprazno polje. Primer: „tt“:„LP6464-4“ (Pomnoževanje nukleinskih kislin z zaznavanjem s sondo) „tt“:„LP217198-3“ (Hitri imunološki preskus) t/nm Ime testa (samo pomnoževanje nukleinskih kislin) Ime uporabljenega amplifikacijskega testa nukleinske kisline (NAAT). Ime mora vključevati ime proizvajalca testa in trgovsko ime testa, ločeno z vejico. Za teste NAAT: to polje je neobvezno. Za teste RAT: to polje se ne uporablja, saj se ime testa navede posredno prek identifikacijske oznake naprave za testiranje (t/ma). Kadar je polje zagotovljeno, ne sme biti prazno. Primer: „nm“:„ELITechGroup, SARS-CoV-2 ELITe MGB® Kit“ t/ma Identifikacijska oznaka naprave za testiranje (samo hitri antigenski testi) Identifikacijska oznaka naprave za hitri antigenski test (RAT) iz podatkovne zbirke JRC. Nabor vrednosti (skupni seznam HSC): — Skupni seznam HSC vseh hitrih antigenskih testov (v berljivi obliki). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (strojno berljivo, vrednosti polja id_device, vključene na seznam, tvorijo nabor vrednosti). Izdajatelji v državah EU/EGP izdajajo potrdila samo za teste, ki spadajo v trenutno veljavni nabor vrednosti. Nabor vrednosti se posodablja vsakih 24 ur. V potrdilih, ki jih izdajo tretje države, se lahko uporabljajo vrednosti zunaj nabora vrednosti, vendar morajo biti identifikacijske oznake še vedno iz podatkovne zbirke JRC. Uporaba drugih identifikacijskih oznak, kot so tiste, ki jih neposredno zagotovijo proizvajalci testov, ni dovoljena. Aplikacije za preverjanje odkrivajo vrednosti, ki ne spadajo v posodobljen nabor vrednosti, in potrdila, ki imajo take vrednosti, prikažejo kot neveljavna. Če se identifikacijska oznaka odstrani iz nabora vrednosti, se lahko potrdila s tako oznako sprejmejo še največ 72 ur po datumu odstranitve. Nabor vrednosti se distribuira prek prehoda za digitalna COVID potrdila EU. Za teste RAT: Zagotovi se natanko eno (1) neprazno polje. Za teste NAAT: Polje se ne uporabi, tudi če je identifikacijska oznaka testa NAA na voljo v podatkovni zbirki JRC. Primer: „ma“:„344“ (SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc Datum in čas odvzema testnega vzorca Datum in čas, ko je bil odvzet testni vzorec. Čas vključuje informacije o časovnem pasu. Vrednost ne označuje časa, ko je nastal rezultat testa. Zagotovi se natanko eno (1) neprazno polje. Uporabi se eden od naslednjih formatov ISO 8601. Druge možnosti niso podprte. LLLL-MM-DDTuu:mm:ssZ LLLL-MM-DDTuu:mm:ss[+-]uu LLLL-MM-DDTuu:mm:ss[+-]uumm LLLL-MM-DDTuu:mm:ss[+-]uu:mm Primeri: „sc“:„2021-08-20T10:03:12Z“ (koordinirani univerzalni čas) „sc“:„2021-08-20T12:03:12+02“ (srednjeevropski čas) „sc“:„2021-08-20T12:03:12+0200“ (srednjeevropski čas) „sc“:„2021-08-20T12:03:12+02:00“ (srednjeevropski čas) t/tr Rezultat testa Rezultat testa. Kodirana vrednost iz nabora vrednosti test-result.json (na podlagi SNOMED CT, GPS). Zagotovi se natanko eno (1) neprazno polje. Primer: „tr“:„260415000“ (Okužba ni odkrita) t/tc Center za testiranje ali kraj izvedbe testa Ime subjekta, ki je opravil test. Identifikacijske oznake se lahko uporabljajo kot del imena, vendar se priporoča, da se ne uporabljajo posamezno brez imena. Največ 80 znakov UTF-8. Morebitne dodatne znake je treba skrajšati. Ime ni zasnovano za avtomatizirano preverjanje. Za teste NAAT: Zagotovi se natanko eno (1) neprazno polje. Za teste RAT: to polje je neobvezno. Če je na voljo, ne sme biti prazno. Primer: „tc“:„Center za testiranje za zahodno regijo 245“ t/co Država članica ali tretja država, v kateri je bilo opravljeno testiranje Država, izražena kot dvočrkovna oznaka ISO3166 (PRIPOROČENO) ali kot sklic na mednarodno organizacijo, pristojno za izvajanje testiranja (kot sta UNHCR ali SZO). To mora biti kodirana vrednost iz nabora vrednosti country-2-codes.json. Nabor vrednosti se distribuira prek prehoda za digitalna COVID potrdila EU. Zagotovi se natanko eno (1) prazno polje. Primeri: „co“:„CZ“ „co“:„UNHCR“ t/is Izdajatelj potrdila Ime organizacije, ki je izdala potrdilo. Identifikacijske oznake se lahko uporabljajo kot del imena, vendar se priporoča, da se ne uporabljajo posamezno brez imena. Največ 80 znakov UTF-8. Zagotovi se natanko eno (1) neprazno polje. Primeri: „is“:„Ministrstvo za zdravje Češke republike“ „is“:„Zdravstveni organ za severozahodno regijo“ t/ci Edinstvena identifikacijska oznaka potrdila Edinstvena identifikacijska oznaka potrdila (oznaka UVCI), kot je določena v vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Vključitev kontrolne vsote ni obvezna. Lahko se doda predpona „URN: UVCI:“. Zagotovi se natanko eno (1) neprazno polje. Primeri: „ci“:„URN:UVCI:01:NL:187/37512422923“ „ci“:„URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B“

4.3. Potrdilo o prebolelosti

Če je skupina preboleli na voljo, mora vsebovati natanko en (1) vnos, ki navaja natanko eno izjavo o prebolelosti. Vsi elementi skupine prebolelih so obvezni in prazne vrednosti niso podprte.







ID polja Ime polja Navodila r/tg Bolezen ali njen povzročitelj, ki jo/ga je imetnik prebolel: COVID-19 (SARS-CoV-2 ali ena od njegovih različic) Kodirana vrednost iz nabora vrednosti disease-agent-targeted.json. Ta vrednost ima en vnos 840539006, ki je koda za COVID-19 iz SNOMED CT (GPS). Zagotovi se natanko eno (1) neprazno polje. Primer: „tg“:„840539006“ r/fr Datum prvega pozitivnega rezultata testa NAAT, ki ga je opravil imetnik Datum odvzetega vzorca za test NAAT, s katerim je bil rezultat pozitiven, v obliki LLLL-MM-DD (vpišite datum brez časovne omejitve). Drugi formati niso podprti. Zagotovi se natanko eno (1) neprazno polje. Primer: „fr“:„2021-05-18“ r/co Država članica ali tretja država, v kateri je bilo opravljeno testiranje Država, izražena kot dvočrkovna oznaka ISO3166 (PRIPOROČENO) ali kot sklic na mednarodno organizacijo, pristojno za izvajanje testiranja (kot sta UNHCR ali SZO). To mora biti kodirana vrednost iz nabora vrednosti country-2-codes.json. Nabor vrednosti se distribuira prek prehoda za digitalna COVID potrdila EU. Zagotovi se natanko eno (1) prazno polje. Primeri: „co“:„CZ“ „co“:„UNHCR“ r/is Izdajatelj potrdila Ime organizacije, ki je izdala potrdilo. Identifikacijske oznake se lahko uporabljajo kot del imena, vendar se priporoča, da se ne uporabljajo posamezno brez imena. Največ 80 znakov UTF-8. Zagotovi se natanko eno (1) neprazno polje. Primer: „is“:„Ministrstvo za zdravje Češke republike“ „is“:„Centralna univerzitetna bolnišnica“ r/df Potrdilo veljavno od Prvi datum, ko se potrdilo šteje za veljavno. Datum ne sme biti zgodnejši od datuma, izračunanega kot r/fr +11 dni. Datum se navede v obliki LLLL-MM-DD (vpišite datum brez časovne omejitve). Drugi formati niso podprti. Zagotovi se natanko eno (1) neprazno polje. Primer: „df“:„2021-05-29“ r/du Potrdilo veljavno do Zadnji datum, ko se potrdilo šteje za veljavno, ki ga določi izdajatelj potrdila. Datum ne sme biti poznejši od datuma, izračunanega kot r/fr+ 180 dni. Datum se navede v obliki LLLL-MM-DD (vpišite datum brez časovne omejitve). Drugi formati niso podprti. Zagotovi se natanko eno (1) neprazno polje. Primer: „du“:„2021-11-14“ r/ci Edinstvena identifikacijska oznaka potrdila Edinstvena identifikacijska oznaka potrdila (oznaka UVCI), kot je določena v vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Vključitev kontrolne vsote ni obvezna. Lahko se doda predpona „URN: UVCI:“. Zagotovi se natanko eno (1) neprazno polje. Primeri: „ci“:„URN:UVCI:01:NL:187/37512422923“ „ci“:„URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B“

▼M3









PRILOGA VI

ODGOVORNOSTI DRŽAV ČLANIC KOT SKUPNIH UPRAVLJAVCEV PREHODA ZA DIGITALNO COVID POTRDILO EU ZA IZMENJAVO SEZNAMOV PREKLICANIH DIGITALNIH COVID POTRDIL EU

ODDELEK 1

Pododdelek 1

Delitev odgovornosti

(1) Skupni upravljavci osebne podatke obdelujejo prek prehoda okvira zaupanja (trust framework gateway) v skladu s tehničnimi specifikacijami iz Priloge I.

(2) Organi izdajatelji držav članic ostajajo edini upravljavec za zbiranje, uporabo, razkritje in kakršno koli drugo obdelavo informacij o preklicu zunaj prehoda, vključno s postopkom, ki vodi do preklica potrdila.

(3) Vsak upravljavec je odgovoren za obdelavo osebnih podatkov v prehodu okvira zaupanja v skladu s členi 5, 24 in 26 Splošne uredbe o varstvu podatkov.

(4) Vsak upravljavec vzpostavi kontaktno točko z namenskim poštnim predalom, ki se uporablja za komunikacijo med skupnimi upravljavci ter med skupnimi upravljavci in obdelovalcem.

(5) Delovna skupina, ki jo ustanovi odbor iz člena 14 Uredbe (EU) 2021/953, je pooblaščena za odločanje o vprašanjih, ki izhajajo iz izmenjave seznamov preklicev in skupnega upravljanja s tem povezane obdelave osebnih podatkov, ter za omogočanje usklajenih navodil Komisiji kot obdelovalcu. Postopek odločanja skupnih upravljavcev ureja ta delovna skupina in poslovnik, ki ga sprejme. Osnovno pravilo je, da neudeležba katerega koli skupnega upravljavca na sestanku te delovne skupine, ki je bil napovedan vsaj sedem (7) dni pred pisnim sklicem, pomeni tiho soglasje z rezultati tega sestanka delovne skupine. Sestanek te delovne skupine lahko skliče kateri koli skupni upravljavec.

(6) Navodila obdelovalcu pošlje katera koli od kontaktnih točk skupnih upravljavcev v dogovoru z drugimi skupnimi upravljavci v skladu s postopkom odločanja delovne skupine, opisanim v točki 5. Skupni upravljavec, ki daje navodila, jih mora pisno posredovati obdelovalcu in o tem obvestiti vse druge skupne upravljavce. Če je obravnavana zadeva tako nujna, da ni možen sestanek delovne skupine iz točke 5, je kljub temu mogoče dati navodilo, ki pa ga lahko delovna skupina prekliče. To navodilo bi bilo treba dati v pisni obliki in o tem v času dajanja navodila obvestiti vse druge skupne upravljavce.

(7) Delovna skupina, ustanovljena v skladu s točko 5, ne izključuje individualne pristojnosti katerega koli od skupnih upravljavcev, da uradno obvesti svoj pristojni nadzorni organ v skladu s členoma 33 in 24 splošne uredbe o varstvu podatkov. Za tako uradno obvestilo ni potrebna privolitev drugih skupnih upravljavcev.

(8) V okviru prehoda okvira zaupanja lahko do izmenjanih osebnih podatkov dostopajo samo osebe, ki jih pooblastijo imenovani nacionalni organi ali uradni organi.

(9) Vsak organ izdajatelj vodi evidenco dejavnosti obdelave, za katere je odgovoren. V evidenci se lahko navede skupno upravljanje.

Pododdelek 2

Odgovornosti in vloge pri obravnavanju zahtevkov in obveščanju posameznikov, na katere se nanašajo osebni podatki

(1) Vsak upravljavec v vlogi organa izdajatelja fizičnim osebam, katerih potrdilo oziroma potrdila je preklical (v nadaljnjem besedilu: posamezniki, na katere se nanašajo osebni podatki), zagotovi informacije o navedenem preklicu in obdelavi njihovih osebnih podatkov v prehodu za digitalno COVID potrdilo EU za namene podpore izmenjavi seznamov preklicev v skladu s členom 14 Splošne uredbe o varstvu podatkov, razen če se to izkaže za nemogoče ali bi vključevalo nesorazmerno veliko truda.

(2) Vsak upravljavec deluje kot kontaktna točka za fizične osebe, katerih potrdilo je preklical, in obravnava zahteve, ki jih posamezniki, na katere se nanašajo osebni podatki, ali njihovi predstavniki predložijo pri uveljavljanju svojih pravic v skladu s Splošno uredbo o varstvu podatkov. Če skupni upravljavec prejme zahtevo posameznika, na katerega se nanašajo osebni podatki, ki se nanaša na potrdilo, ki ga je izdal drug skupni upravljavec, obvesti posameznika, na katerega se nanašajo osebni po