02021D1073 — LV — 25.04.2022 — 003.001

Šis dokuments ir tikai informatīvs, un tam nav juridiska spēka. Eiropas Savienības iestādes neatbild par tā saturu. Attiecīgo tiesību aktu un to preambulu autentiskās versijas ir publicētas Eiropas Savienības “Oficiālajā Vēstnesī” un ir pieejamas datubāzē “Eur-Lex”. Šie oficiāli spēkā esošie dokumenti ir tieši pieejami, noklikšķinot uz šajā dokumentā iegultajām saitēm

►B KOMISIJAS ĪSTENOŠANAS LĒMUMS (ES) 2021/1073 (2021. gada 28. jūnijs), ar ko nosaka tehniskās specifikācijas un noteikumus ar Eiropas Parlamenta un Padomes Regulu (ES) 2021/953 izveidotā ES digitālā Covid sertifikāta uzticamības satvara īstenošanai (Dokuments attiecas uz EEZ) (OV L 230, 30.6.2021., 32. lpp)

Grozīts ar:









▼B

KOMISIJAS ĪSTENOŠANAS LĒMUMS (ES) 2021/1073

(2021. gada 28. jūnijs),

ar ko nosaka tehniskās specifikācijas un noteikumus ar Eiropas Parlamenta un Padomes Regulu (ES) 2021/953 izveidotā ES digitālā Covid sertifikāta uzticamības satvara īstenošanai

(Dokuments attiecas uz EEZ)







1. pants

ES digitālā Covid sertifikāta tehniskās specifikācijas, kurās noteikta vispārīgo datu struktūra, kodēšanas mehānismi un koda pārneses mehānisms mašīnlasāmā optiskā formātā, ir noteikti I pielikumā.

2. pants

Noteikumi par sertifikātu aizpildīšanu, kas minēti Regulas (ES) 2021/953 3. panta 1. punktā, ir izklāstīti šā lēmuma II pielikumā.

3. pants

Prasības par unikālā sertifikāta identifikatora kopīgo struktūru ir izklāstītas III pielikumā.

▼M1

4. pants

Pārvaldības noteikumi, ko piemēro publiskās atslēgas sertifikātiem saistībā ar ES digitālā Covid sertifikāta vārteju, kura atbalsta uzticamības satvara sadarbspējas aspektus, ir izklāstīti IV pielikumā.

▼M1

5. pants

Vienota koordinēta datu struktūra datiem, kas jāiekļauj Regulas (ES) 2021/953 3. panta 1. punktā minētajos sertifikātos, izmantojot JavaScript Object Notation (JSON) shēmu, ir noteikta šā lēmuma V pielikumā.

▼M3

5.a pants

Apmaiņa ar sertifikātu atsaukšanas sarakstiem

1. ES digitālā Covid sertifikāta uzticamības satvars ļauj apmainīties ar sertifikātu atsaukšanas sarakstiem, izmantojot centrālo ES digitālā Covid sertifikāta vārteju (“vārteja”) saskaņā ar I pielikumā izklāstītajām tehniskajām specifikācijām.

2. Ja dalībvalstis atsauc ES digitālos Covid sertifikātus, tās var vārtejā iesniegt sertifikātu atsaukšanas sarakstus.

3. Ja dalībvalstis iesniedz sertifikātu atsaukšanas sarakstus, izdevējas iestādes uztur atsaukto sertifikātu sarakstu.

4. Ja vārtejā notiek persondatu apmaiņa, apstrādi veic vienīgi nolūkā atbalstīt ar atsaukšanu saistītās informācijas apmaiņu. Šādus persondatus izmanto tikai tam, lai pārbaudītu to ES digitālo Covid sertifikātu atsaukšanas statusu, kuri izdoti saskaņā ar Regulu (ES) 2021/953.

5. Vārtejā iesniegtā informācija ietver šādus datus saskaņā ar I pielikumā izklāstītajām tehniskajām specifikācijām: a) atsaukto sertifikātu pseidonimizētie unikālie identifikatori; b) sertifikātu atsaukšanas saraksta derīguma termiņš.

6. Ja izdevējiestāde atsauc ES digitālos Covid sertifikātus, ko tā izdevusi saskaņā ar Regulu (ES) 2021/953 vai Regulu (ES) 2021/954, un plāno apmainīties ar attiecīgo informāciju vārtejā, tā 5. punktā minēto informāciju sertifikātu atsaukšanas sarakstu veidā nosūta uz vārteju drošā formātā saskaņā ar I pielikumā izklāstītajām tehniskajām specifikācijām.

7. Izdevējiestādes, ciktāl iespējams, nodrošina risinājumu, kā atsaukšanas brīdī informēt atcelto sertifikātu turētājus par sertifikātu atsaukšanas statusu un atsaukšanas iemeslu.

8. Vārteja apkopo saņemtos sertifikātu atsaukšanas sarakstus. Tā nodrošina rīkus šo sarakstu izplatīšanai dalībvalstīm. Tā automātiski dzēš sarakstus saskaņā ar derīguma termiņiem, ko katram iesniegtajam sarakstam norādījusi iesniedzējiestāde.

9. Dalībvalstu izraudzītās valsts iestādes vai oficiālās struktūras, kas vārtejā apstrādā persondatus, ir apstrādāto datu kopīgi pārziņi. Kopīgo pārziņu attiecīgie pienākumi tiek sadalīti saskaņā ar VI pielikumu.

10. Vārtejā apstrādāto persondatu apstrādātājs ir Komisija. Komisija kā apstrādātājs dalībvalstu vārdā nodrošina persondatu nosūtīšanas un mitināšanas drošību vārtejā un ievēro apstrādātāja pienākumus, kas noteikti VII pielikumā.

11. Komisija un kopīgie pārziņi regulāri testē, novērtē un izvērtē, cik efektīvi ir tehniskie un organizatoriskie pasākumi, kas nodrošina persondatu apstrādes drošību vārtejā.

5.b pants

Sertifikātu atsaukšanas sarakstu iesniegšana, ko veic trešās valstis

Trešās valstis, kas izdod Covid-19 sertifikātus, attiecībā uz kuriem Komisija saskaņā ar Regulas (ES) 2021/953 3. panta 10. punktu vai 8. panta 2. punktu ir pieņēmusi īstenošanas aktu, var iesniegt sarakstus ar atsauktajiem Covid-19 sertifikātiem, uz kuriem attiecas šāds īstenošanas akts un kuri Komisijai jāapstrādā 5.a pantā minēto vārtejā esošo kopīgo pārziņu vārdā saskaņā ar I pielikumā izklāstītajām tehniskajām specifikācijām.

5.c pants

Centrālajā ES digitālā Covid sertifikāta vārtejā veiktas persondatu apstrādes pārvaldība

1. Kopīgo pārziņu lēmumu pieņemšanas procesu reglamentē darba grupa, kas izveidota Regulas (ES) 2021/953 14. pantā minētās komitejas ietvaros.

2. Dalībvalstu izraudzītās valsts iestādes vai oficiālās struktūras, kas vārtejā apstrādā persondatus kā kopīgi pārziņi, izraugās minētās grupas pārstāvjus.

▼M1

6. pants

Šis lēmums stājas spēkā dienā, kad to publicē Eiropas Savienības Oficiālajā Vēstnesī.

▼B

Šis lēmums stājas spēkā dienā, kad to publicē Eiropas Savienības Oficiālajā Vēstnesī.









I PIELIKUMS

FORMĀTS UN UZTICAMĪBAS PĀRVALDĪBA

Vispārīga datu struktūra, kodēšanas mehānismi un koda pārneses mehānisms mašīnlasāmā optiskā formātā (QR)

1. Ievads

Šajā pielikumā izklāstītās tehniskās specifikācijas ietver vispārīgu datu struktūru un kodēšanas mehānismus ES digitālajam Covid sertifikātam (DCC). Tajās noteikti arī pārneses kodēšanas mehānismi mašīnlasāmā optiskā formātā (QR), ko var attēlot uz mobilās ierīces ekrāna vai izdrukāt uz papīra. Šo specifikāciju elektronisko veselības sertifikātu saturošie formāti ir vispārīgi, bet šajā kontekstā tos izmanto DCC pārnesei.

2. Terminoloģija

Šajā pielikumā apzīmējums “izdevēji” attiecas uz organizācijām, kas veselības sertifikātu izdošanai izmanto šīs specifikācijas, un apzīmējums “verificētāji” attiecas uz organizācijām, kas veselības sertifikātus akceptē kā veselības stāvokļa apliecinājumu. “Dalībnieki” ir izdevēji un verificētāji. Daži šajā pielikumā iekļautie aspekti dalībniekiem ir jāsaskaņo, piemēram, nosaukumu telpas pārvaldība un šifrēšanas atslēgu izplatīšana. Tiek pieņemts, ka šos uzdevumus veic kāda puse, ko turpmāk sauc par “sekretariātu”.

3. Elektronisko veselības sertifikātu saturošais formāts

Elektronisko veselības sertifikātu saturošais formāts (HCERT) ir paredzēts tam, lai nodrošinātu vienotu un standartizētu nesēju veselības sertifikātiem, ko izdevuši dažādi izdevēji (“izdevēji”). Šo specifikāciju mērķis ir harmonizēt to, kā šos veselības sertifikātus attēlo, kodē un paraksta, lai atvieglotu sadarbspēju.

Lai varētu nolasīt un interpretēt jebkura izdevēja izdotu DCC, ir vajadzīga vienota datu struktūra un vienošanās par pamatdatu katra datu lauka nozīmīgumu. Sadarbspējas atvieglošanai vienota saskaņotā datu struktūra ir noteikta, izmantojot “JSON” shēmu, kas veido DCC struktūru.

3.1. Pamatdatu struktūra

Pamatdati ir strukturēti un kodēti kā CBOR ar COSE digitālo parakstu. To parasti dēvē par “CBOR tīmekļa marķieri” (CWT), un tas ir definēts RFC 8392 ( 1 ). Pamatdatus, kas definēti nākamajās iedaļās, pārnes kā hcert pieprasījumu.

Verificētājam ir jāspēj pārliecināties par pamatdatu izcelsmes integritāti un autentiskumu. Šā mehānisma nodrošināšanai izdevējam ir jāparaksta CWT, izmantojot asimetriska elektroniskā paraksta shēmu, kas definēta COSE specifikācijā (RFC 8152 ( 2 )).

3.2. CWT pieprasījumi

3.2.1. CWT struktūras pārskats

Aizsargāta galvene

— Paraksta algoritms (alg, iezīme 1)

— Atslēgas identifikators (kid, iezīme 4)

Pamatdati

— Izdevējs (iss, pieprasījuma atslēga 1, fakultatīvs, izdevēja ISO 3166-1 alpha-2)

— Izdošanas laiks (iat, pieprasījuma atslēga 6)

— Derīguma laiks (exp, pieprasījuma atslēga 4)

— Veselības sertifikāts (hcert, pieprasījuma atslēga -260)

— ES digitālais Covid sertifikāts v1 (eu_DCC_v1, pieprasījuma atslēga 1)

Paraksts

3.2.2. Paraksta algoritms

Paraksta algoritma (alg) parametrs norāda paraksta izveidošanai izmantoto algoritmu. Tam ir jāatbilst pašreizējām SOG-IS pamatnostādnēm, kas izklāstītas turpmāk, vai jāpārsniedz tās.

Ir definēts viens primārais un viens sekundārais algoritms. Sekundārais algoritms būtu jāizmanto tikai tad, ja primārais algoritms nav pieņemams atbilstoši izdevējam piemērotajiem noteikumiem.

Lai nodrošinātu sistēmas aizsardzību, visos izpildījumos jāiekļauj sekundārais algoritms. Tāpēc ir jāievieš gan primārais, gan sekundārais algoritms.

SOG-IS noteiktie līmeņi primārajam un sekundārajam algoritmam:

— primārais algoritms: primārais algoritms ir eliptiskās līknes digitālā paraksta algoritms ( ECDSA ), kas definēts standarta ISO/IEC 14888–3:2006 2.3. iedaļā, izmantojot P–256 parametrus, kas definēti publikācijas “FIPS PUB 186–4” D (D.1.2.3) papildinājumā, kopā ar SHA–256 kontrolsummas algoritmu, kas definēts standarta ISO/IEC 10118–3:2004 4. funkcijā.

Tas atbilst COSE algoritma parametram ES256.

— RSASSA-PSS , kas definēts RFC 8230 ( sekundārais algoritms: sekundārais algoritms ir, kas definēts 3 ), ar 2048 bitu moduli kopā ar SHA–256 kontrolsummas algoritmu, kas definēts standarta ISO/IEC 10118–3:2004 4. funkcijā.

Tas atbilst COSE algoritma parametram PS256.

3.2.3. Atslēgas identifikators

Atslēgas identifikatora (kid) prasījumā norāda dokumenta parakstītāja sertifikātu (DSC), kuram ir publiskā atslēga, kas verificētājam jāizmanto, lai pārbaudītu digitālā paraksta pareizību. Publiskās atslēgas sertifikātu pārvaldība, tostarp prasības attiecībā uz DSC, ir aprakstītas IV pielikumā.

Atslēgas identifikatora (kid) pieprasījumu verificētāji izmanto, lai atlasītu pareizo publisko atslēgu no atslēgu saraksta, kas attiecas uz izdevēja (iss) pieprasījumā norādīto izdevēju. Administratīvu iemeslu dēļ un atslēgu pārņemšanā izdevējs vienlaikus var izmantot vairākas atslēgas. Atslēgas identifikators nav drošībai būtisks lauks. Tāpēc, ja vajadzīgs, to var ievietot neaizsargātā galvenē. Verificētājiem ir jāpieņem abas iespējas. Ja ir izmantotas abas iespējas, jāizmanto aizsargātajā galvenē ievietotais atslēgas identifikators.

Saistībā ar identifikatora saīsināšanu (izmēra ierobežojuma dēļ) pastāv ļoti maza iespējamība, ka kopējā verificētāja akceptēto DSC sarakstā var būt DSC ar dubultiem kid. Tāpēc validētājam ir jāpārbauda visi DSC ar attiecīgo kid.

3.2.4. Izdevējs

Izdevēja (iss) pieprasījums ir vērtība, kas fakultatīvi var saturēt ISO 3166-1 alpha-2 veselības sertifikāta izdevējstruktūras valsts kodu. Verificētājs šo pieprasījumu var izmantot, lai noteiktu, kura DSC kopa jāizmanto verifikācijai. Šā pieprasījuma identificēšanai izmanto pieprasījuma atslēgu 1.

3.2.5. Derīguma laiks

Derīguma laika (exp) pieprasījums satur laika zīmogu, kurš ir vesela skaitļa NumericDate formātā (kā noteikts RFC 8392 ( 4 ), 2. iedaļā) un kurš norāda, cik ilgi konkrētais paraksts attiecībā uz pamatdatiem ir uzskatāms par derīgu; pēc minētā laika verificētājam pamatdati ir jānoraida. Derīguma parametra nolūks ir ierobežot veselības sertifikāta derīguma periodu. Šā pieprasījuma identificēšanai izmanto pieprasījuma atslēgu 4.

Derīguma laiks nedrīkst pārsniegt DSC derīguma periodu.

3.2.6. Izdošanas laiks

Izdošanas laika (iat) pieprasījums satur laika zīmogu, kurš ir vesela skaitļa NumericDate formātā (kā noteikts RFC 8392 ( 5 ), 2. iedaļā) un kurš norāda veselības sertifikāta izveidošanas laiku.

Izdošanas laika laukā norādītais laiks nedrīkst būt pirms DSC derīguma perioda sākuma.

Verificētāji drīkst piemērot papildu noteikumus, kuru mērķis ir ierobežot veselības sertifikāta derīgumu, pamatojoties uz izdošanas laiku. Šā pieprasījuma identificēšanai izmanto pieprasījuma atslēgu 6.

3.2.7. Veselības sertifikāta pieprasījums

Veselības sertifikāta (hcert) pieprasījums ir JSON (RFC 7159 ( 6 )) objekts, kas satur veselības stāvokļa informāciju. Ar vienu un to pašu pieprasījumu var apzīmēt vairākus dažāda veida veselības sertifikātus, un DCC ir viens no tiem.

JSON izmanto tikai shematiskām vajadzībām. Tam izmanto CBOR atveides formātu, kas noteikts (RFC 7049 ( 7 )). Lietotņu izstrādātāji nedrīkst faktiski atkodēt vai kodēt uz JSON formātu un no tā, bet gan izmanto atmiņā esošo struktūru.

Šā pieprasījuma identificēšanai izmanto pieprasījuma atslēgu -260.

JSON objekta virknes normalizē atbilstoši Unicode standartā definētajai normalizācijas formas kanoniskajai kompozīcijai (Normalization Form Canonical Composition, NFC). Tomēr atkodēšanas lietotnēm šajā ziņā ir jābūt pielaidīgākām un noturīgākām, un tiek stingri mudināts akceptēt jebkādu piemērota veida konvertēšanu. Ja atkodēšanas laikā vai ar vēlāk izmantotām salīdzināšanas funkcijām tiek konstatēti nenormalizēti dati, izpildījumam būtu jāreaģē tā, it kā ievadītie dati ir normalizēti atbilstoši NFC.

4. DCC pamatdatu serializēšana un izveide

Serializēšanai izmanto šādu shēmu:

Process sākas ar datu iegūšanu, piemēram, no Veselības datu repozitorija (vai kāda ārēja datu avota), iegūtos datus strukturējot atbilstoši noteiktajām DCC shēmām. Šajā procesā, pirms sākas serializēšana uz CBOR, var notikt pārvēršana uz noteikto datu formātu un pārveidošana, lai atvieglotu salasāmību cilvēkiem. Pieprasījuma akronīmus kartē katrā gadījumā, lai parādītu nosaukumus pirms serializācijas un pēc deserializācijas.

Sertifikātos, kas izdoti saskaņā ar Regulu (ES) 2021/953 ( 8 ), fakultatīvais valsts datu saturs nav atļauts. Ir pieļaujams tikai tāds datu saturs, kas atbilst definētajiem datu elementiem minimālajā datu kopā, kura norādīta Regulas 2021/953 pielikumā.

5. Pārneses kodēšana

5.1. Jēldati

Attiecībā uz dažādām datu saskarnēm HCERT konteineru un tā pamatdatus var pārnest tādus, kādi tie ir, izmantojot jebkādu pamatā esošu 8 bitu drošu, uzticamu datu pārnesi. Šādas saskarnes var būt tuva darbības lauka komunikācija (NFC), Bluetooth vai pārnese pa lietotņslāņa protokolu, piemēram, HCERT pārnese no izdevēja uz turētāja mobilo ierīci.

Ja HCERT pārnese no izdevēja turētājam pamatā ir tikai uzrādīšanas saskarne (piem., SMS, e-pasts), tad jēldatu pārneses kodēšanu, protams, nepiemēro.

5.2. Svītrkods

5.2.1. Pamatdatu (CWT) kompresija

Lai samazinātu izmēru un uzlabotu HCERT nolasīšanas ātrumu un uzticamību, CWT kompresē, izmantojot ZLIB (RFC 1950 ( 9 )) un Deflate kompresijas mehānismu formātā, kas noteikts (RFC 1951 ( 10 )).

5.2.2. QR 2D svītrkods

Lai labāk pielāgotos novecojušām iekārtām, ar kurām paredzēts apstrādāt ASCII pamatdatus, kompresēto CWT pirms kodēšanas 2D svītrkodā kodē kā ASCII, izmantojot Base45.

2D svītrkoda ģenerēšanai izmanto QR formātu, kas noteikts standartā ISO/IEC 18004:2015. Ieteicams izmantot kļūdu labošanas koeficientu “Q” (ap 25 %). Tā kā izmanto Base45, QR kodam ir jāizmanto burtciparu kodējums (2. režīms, ko apzīmē ar simboliem 0010).

Lai verificētāji spētu noteikt kodēto datu veidu un izvēlēties pareizo atkodēšanas un apstrādes shēmu, Base45 kodēto datu (atbilstoši šai specifikācijai) priekšā iekļauj kontekstuālā identifikatora virkni “HC1:”. Šīs specifikācijas turpmākajās versijās, kas ietekmē atgriezenisko savietojamību, definē jaunu kontekstuālo identifikatoru, rakstzīmes pēc “HC” izvēloties no rakstzīmju kopas [1-9A-Z]. Papildu rakstzīmju secība ir tāda, kā norādīts, t. i., sākumā [1-9] un tad [A-Z].

Optisko kodu ieteicams atveidot uz informācijas nesēja, kura izmērs pa diagonāli ir no 35 mm līdz 60 mm, lai tas būtu pielāgots lasītājiem ar fiksētu optiku, kurai nepieciešams, ka informācijas nesējs ir novietots uz lasītāja virsmas.

Ja optiskais kods ir izdrukāts uz papīra, izmantojot zemas izšķirtspējas (< 300 dpi) printeri, jāraugās, lai katrs QR koda simbols (punkts) būtu kvadrāts. Neproporcionālas mērogošanas rezultātā dažās QR koda līnijās vai ailēs var rasties taisnstūrveida simboli, kas daudzos gadījumos apgrūtinās nolasīšanu.

6. Uzticamības saraksta formāts (CSCA un DSC saraksts)

Katrai dalībvalstij jāiesniedz saraksts ar vienu vai vairākām valsts parakstīšanas sertificēšanas iestādēm (CSCA) un saraksts ar visiem derīgiem dokumentu parakstītāju sertifikātiem (DSC), un šie saraksti ir jāatjaunina.

6.1. Vienkāršots CSCA/DSC

Sākot ar šo specifikāciju versiju, dalībvalstis nepieņem, ka tiek izmantota sertifikāta atsaukšanas saraksta (CRL) informācija vai ka izpildītāji verificē privāto atslēgu lietošanas periodu.

Tā vietā kā primāro derīguma mehānismu izmanto sertifikāta esību jaunākajā sertifikāta saraksta versijā.

6.2. ICAO eMRTD PKI un uzticamības centri

Dalībvalstis var izmantot atsevišķu CSCA, bet var iesniegt arī savus esošos eMRTD CSCA sertifikātus un/vai DSC; un tās pat var izvēlēties tos iegādāties no (komerciāliem) uzticamības centriem un iesniegt tos. Tomēr DSC vienmēr jāparaksta attiecīgās dalībvalsts norādītajai CSCA.

7. Drošības apsvērumi

Veidojot shēmu uz šīs specifikācijas pamata, dalībvalstis identificē, analizē un uzrauga dažus drošības aspektus.

Jāņem vērā vismaz šādi aspekti:

7.1. HCERT paraksta derīguma laiks

HCERT izdevējam ir jāierobežo paraksta derīguma periods, nosakot paraksta derīguma laiku. Tas nozīmē, ka veselības sertifikāta turētājam periodiski sertifikāts ir jāatjaunina.

Pieņemamo derīguma periodu var noteikt praktiski apsvērumi. Piemēram, ceļotājam var nebūt iespēja atjaunot veselības sertifikātu ceļojuma laikā ārvalstīs. Tomēr, iespējams, ka izdevējs ņem vērā kaut kādus drošības apsvērumus, kuru dēļ tam ir jāanulē DSC (tādējādi anulējot visus veselības sertifikātus, kas izdoti ar attiecīgo atslēgu, kuras derīguma periods vēl nav beidzies). Šāda notikuma sekas var ierobežot, ja regulāri, bet saprātīgā intervālā maina izdevēja atslēgas un pieprasa atjaunot visus veselības sertifikātus.

7.2. Atslēgu pārvaldība

Šī specifikācija lielā mērā ir atkarīga no spēcīgiem kriptogrāfiskiem mehānismiem, ar kuriem nodrošina datu integritāti un datu izcelsmes autentifikāciju. Tāpēc ir nepieciešams saglabāt privāto atslēgu konfidencialitāti.

Kriptogrāfisko atslēgu konfidencialitāte var tikt apdraudēta dažādos veidos, piemēram:

— atslēgas ģenerēšanas process var būt kļūdains, kā rezultātā atslēgas ir vājas,

— atslēgas var tikt atklātas cilvēka kļūdas dēļ,

— atslēgas var nozagt ārējs vai iekšējs likumpārkāpējs,

— atslēgas var aprēķināt, izmantojot kriptoanalīzes metodes.

Lai mazinātu risku, ka paraksta algoritms ir vājš, proti, privāto atslēgu aizsardzību var apdraudēt ar kriptoanalīzes metodēm, šajā specifikācijā visiem dalībniekiem ir ieteikts ieviest sekundāro rezerves paraksta algoritmu, kura pamatā ir atšķirīgi parametri vai atšķirīgas matemātiskās problēmas nekā primārajā algoritmā.

Attiecībā uz risku, kas saistīts ar izdevēju darbības vidi, ir jāveic risku mazinoši pasākumi, ar kuriem nodrošina efektīvu kontroli, piemēram, privāto atslēgu ģenerēšana, uzglabāšana un izmantošana aparatūras drošības moduļos (HSM). Veselības sertifikātu parakstīšanai ļoti ieteicams izmantot HSM.

Neatkarīgi no tā, vai izdevējs nolemj lietot HSM, būtu jāizveido atslēgu maiņas grafiks, kurā atslēgas maiņas biežums ir proporcionāls tam, cik bieži atslēgas nonāk ārējos tīklos, citās sistēmās vai tās apstrādā darbinieki. Labā maiņas grafikā arī vajadzētu ierobežot risku, kas saistīts ar kļūdaini izdotiem veselības sertifikātiem, tādējādi dodot izdevējam iespēju atsaukt šādus veselības sertifikātus visus kopā, vajadzības gadījumā izmantojot vienu atslēgu.

7.3. Ievades datu validācija

Šīs specifikācijas var izmantot tādā veidā, kas netieši pieļauj datu saņemšanu no neuzticamiem avotiem tādās sistēmās, kas var būt ļoti svarīgas. Lai līdz minimumam samazinātu risku ar šāda uzbrukuma vektoru, visi ievades dati ir pienācīgi jāvalidē, pārbaudot datu veidu, garumu un saturu. Pirms HCERT satura apstrādes jāvalidē arī izdevēja paraksts. Tomēr izdevēja paraksta validēšana netieši nozīmē, kas visupirms tiek parsēta aizsargātā izdevēja galvene, kurā iespējamais uzbrucējs var ievietot īpaši pielāgotu informāciju, ar kuru mazināt sistēmas drošību.

8. Uzticamības pārvaldība

Lai verificētu HCERT parakstu, ir vajadzīga publiska atslēga. Dalībvalstis minētās publiskās atslēgas dara pieejamas. Katram verificētājam ir jābūt visu uzticamo publisko atslēgu sarakstam (jo publiskā atslēga nav daļa no HCERT).

Sistēmai ir (tikai) divi slāņi; katrai dalībvalstij viens vai vairāki valsts līmeņa sertifikāti, ar kuriem paraksta vienu vai vairākus dokumentu parakstītāju sertifikātus, kurus izmanto ikdienas darbībām.

Dalībvalsts sertifikātus dēvē par valsts parakstīšanas sertificēšanas iestādes (CSCA) sertifikātiem, un tie (parasti) ir pašparakstīti sertifikāti. Dalībvalstīm var būt vairāk nekā viens sertifikāts (piemēram, reģionālu atšķirību gadījumā). Šos CSCA sertifikātus regulāri paraksta ar dokumentu parakstītāju sertifikātiem (DSC), ko izmanto HCERT parakstīšanai.

“Sekretariāts” ir funkcionāla loma. Tas regulāri apkopo un publicē dalībvalstu DSC pēc tam, kad ir tie verificēti, salīdzinot tos ar CSCA sertifikātu sarakstu (ko nodod un verificē ar citiem līdzekļiem).

Iegūto DSC sarakstu apkopo, lai iegūtu akceptējamo publisko atslēgu kopu (un attiecīgos atslēgas identifikatorus), ko verificētāji var izmantot, lai validētu HCERT parakstus. Verificētājiem šis saraksts regulāri jāiegūst un jāatjaunina.

Šādus dalībvalstīm paredzētus sarakstus var pielāgot formātam, ko izmanto valsts līmenī. Šāda uzticamības saraksta datnes formāts var būt atšķirīgs, piemēram, tas var būt parakstīts JWKS (JWK formāts atbilstoši RFC 7517 ( 11 ), 5. iedaļa) vai kādā citā formātā, kas piemērots attiecīgajā dalībvalstī izmantotajai tehnoloģijai.

Vienkāršības labad dalībvalstis var iesniegt esošos CSCA sertifikātus no ICAO eMRTD sistēmām vai, ievērojot PVO ieteikumu, izveidot īpašu sertifikātu šai veselības jomai.

8.1. Atslēgas identifikators (kid)

Atslēgas identifikatoru (kid) aprēķina, kad tiek veidots DSC uzticamo publisko atslēgu saraksts, un to veido saīsināts DSC (pirmie 8 baiti) SHA-256 digitālnospiedums, kas kodēts DER (raw) formātā.

Verificētājiem nav jāaprēķina kid, kura pamatā ir DSC, un tas tieši atbilst atslēgas identifikatoram izdotajā veselības sertifikātā, kura kid ir uzticamības sarakstā.

8.2. Atšķirības no ICAO eMRTD PKI uzticamības modeļa

Lai arī ICAO eMRTD PKI uzticamības modeļa pamatā ir paraugprakse, tomēr ātrdarbības labad ir veikti vairāki vienkāršojumi:

— dalībvalstis var iesniegt vairākus CSCA sertifikātus,

— DSC (atslēgas lietojuma) derīguma periodu var brīvi noteikt, nepārsniedzot CSCA sertifikāta derīguma periodu, un to var arī neiekļaut,

— DSC var iekļaut noteikumu identifikatorus (paplašināts atslēgas lietojums), kas atbilst veselības sertifikātiem,

— Dalībvalstis var izvēlēties neveikt publisko atsaukumu verifikāciju, bet tā vietā vienkārši paļauties uz DSC sarakstiem, ko tās katru dienu saņem no sekretariāta vai apkopo pašas.

▼M3

9. ATSAUKŠANAS RISINĀJUMS

9.1. DCC atsaukšanas saraksta (DRL) noteikums

Vārteja nodrošina galapunktus un funkcionalitāti, kas vajadzīga, lai glabātu un pārvaldītu atsaukšanas sarakstus:

9.2. Uzticamības modelis

Visus savienojumus veido, izmantojot DCCG standarta uzticamības modeli ar NBTLS un NBUP sertifikātiem (sk. sertifikātu pārvaldību). Lai nodrošinātu integritāti, visu informāciju iekļauj un augšupielādē ar CMS ziņojumiem.

9.3. Partijas veidošana

9.3.1. Partija

Katrā atsaukšanas sarakstā ir viens vai vairāki ieraksti, un tos veido pa partijām, iekļaujot kontrolsummas (hashes) un to metadatus. Partija ir nemaināma un nosaka derīguma termiņu, kurā partiju var dzēst. Visu partijas vienību derīguma termiņam jābūt vienādam, proti, partijas jāgrupē pēc derīguma termiņa un pēc parakstīšanas DSC. Katrā partijā ir ne vairāk kā 1 000 ierakstu. Ja atsaukšanas sarakstā ir vairāk nekā 1 000 ierakstu, izveido vairākas partijas. Katrs ieraksts var būt tikai vienā partijā. Partiju ievieto CMS struktūrā un paraksta ar augšupielādētājas valsts NBup sertifikātu.

9.3.2. Partijas indekss

Vārteja partijai pēc izveidošanas piešķir unikālu ID, ko automātiski pievieno indeksam. Partiju indeksu sakārto augošā hronoloģiskā secībā pēc izmaiņu datuma.

9.3.3. Vārtejas darbība

Vārteja atsaukšanas partijas apstrādā, neizdarot izmaiņas, proti, tā neatjauno, nedzēš un nepievieno partijām jaunu informāciju. Partijas nosūta visām pilnvarotajām valstīm (sk. 9.6. nodaļu).

Vārteja aktīvi novēro partiju derīguma termiņu un izņem partijas, kurām derīguma termiņš ir beidzies. Kad partija ir dzēsta, vārteja attiecībā uz dzēstās partijas URL nosūta atbildi “HTTP 410 Gone”. Tādējādi partija indeksā parādās kā “dzēsta”.

9.4. Kontrolsummu veidi

Atsaukšanas saraksti satur kontrolsummas, kas atbilst dažādiem atsaukšanas veidiem/atribūtiem. Šos veidus vai atribūtus norāda atsaukšanas sarakstu aprakstā. Pašreizējie veidi ir šādi:







Veids Atribūts Kontrolsummas aprēķināšana 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

Partijā iekļauj tikai sākotnējos kontrolsummas 128 bitus, kas kodēti kā base64 virknes, un tos izmanto atsaukto DCC identificēšanai ( 12 ).

9.4.1. Kontrolsummu veids: SHA256(DCC paraksts)

Šajā gadījumā kontrolsummu aprēķina no CWT COSE_SIGN1 paraksta baitiem. RSA parakstu gadījumā kā ievadi izmanto visu parakstu. EC-DSA parakstīto sertifikātu gadījumā formulā kā ievadi izmanto r vērtību:

SHA256(r)

[nepieciešama visiem jauniem īstenošanas gadījumiem]

9.4.2. Kontrolsummu veids: SHA256(UCI)

Šajā gadījumā kontrolsummu aprēķina no UCI virknes, kas kodēta UTF-8 un konvertēta baitu kopumā.

[novecojis ( 13 ), bet tiek atbalstīts, lai nodrošinātu atpakaļsaderību]

9.4.3. Kontrolsummu veids: SHA256(Issuing CountryCode+UCI)

Šajā gadījumā CountryCode ir kodēta kā UTF-8 virkne, kas savienota ar UCI, kas kodēta ar UTF-8 virkni. To pēc tam konvertē baitu virknē un izmanto kā ievadi kontrolsummas funkcijā.

[novecojis2, bet tiek atbalstīts, lai nodrošinātu atpakaļsaderību]

9.5. API struktūra

9.5.1. Atsaukšanas ierakstu sniedzošā API

9.5.1.1. Nolūks

API sniedz atsaukšanas saraksta ierakstus partijās, tai skaitā partijas indeksu.

9.5.1.2. Galapunkti

9.5.1.2.1. Partijas saraksta lejupielādes galapunkts

Galapunkti veidoti pēc vienkārša principa; tie nosūta atpakaļ partiju sarakstu un metadatu informāciju (wrapper). Partijas sakārto pēc datuma augošā (hronoloģiskā) secībā:

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

}

Piezīme. Rezultāti pēc noklusējuma ir ierobežoti līdz 1 000 vienībām. Ja karogu “more” iestata kā patiesu (true), atbildē tiek norādīts, ka lejupielādei ir pieejamas papildu partijas. Lai lejupielādētu vairāk vienību, klientam galvenē (header) If-Modified-Since jāievada datums, kas nav agrāks kā pēdējā saņemtā ieraksta datums.

Atbilde satur JSON kopu ar šādu struktūru:







Lauks Definīcija more Būla vērtības karogs, kas norāda, ka ir vairāk partiju. batches Esošo partiju kopa. batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Valsts kods no ISO 3166 date ISO 8601 datums UTC laikā. Datums, kad partija pievienota vai dzēsta. deleted Būla vērtība. Patiesa (true), ja dzēsta. Ja dzēšanas karogs ir iestatīts, ierakstu no vaicājuma rezultātiem var dzēst pēc 7 dienām.

9.5.1.2.1.1. Atbildes kodi







Kods Apraksts 200 Viss kārtībā. 204 Nav satura, ja galvenei If-Modified-Since nav atbilsmes.

Pieprasījuma galvene







Galvene Obligāts Apraksts If-Modified-Since Jā Šajā galvenē ir norādīts pēdējais lejupielādētais datums, lai iegūtu tikai jaunākos rezultātus. Sākotnējā pieprasījumā galvenei jābūt ‘2021-06-01T00:00:00Z’.

9.5.1.2.2. Partijas lejupielādes galapunkts

Partijas satur sertifikātu identifikatoru sarakstu:

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

}

Atbilde satur CMS, tai skaitā parakstu, kam jāatbilst valsts NBUP sertifikātam. Visām JSON kopas vienībām ir šāda struktūra:







Lauks Obligāts Veids Definīcija expires Jā String Datums, kurā vienību var dzēst. ISO8601 datums/UTC laiks. country Jā String Valsts kods no ISO 3166 hashType Jā String Sniegto ierakstu kontrolsummas veids (sk. kontrolsummas veidus) entries Jā JSON Object Array Sk. tabulu par ierakstiem kid Jā String base64 kodēts KID no DSC, ko izmanto DCC parakstīšanai. Ja KID nav zināms, tad var izmantot virkni “UNKNOWN_KID” (bez pēdiņām). Piezīmes

— Partijas grupē pēc derīguma termiņa un DSC ; visām vienībām ir vienāds derīgums, un tās ir parakstītas ar to pašu atslēgu.

— Derīguma termiņš ir datums/ UTC laiks, jo EU-DCC ir globāla sistēma un ir jāizmanto nepārprotams laiks.

— Pilnīgi atsaukta DCC derīguma termiņu nosaka tā attiecīgā DSC derīguma termiņā, kuru izmanto DCC parakstīšanai, vai atsauktā DCC derīguma laikā (šādā gadījumā izmantotos NumericDate / epoch laikus uzskata par UTC laika zonā esošiem laikiem).

— Nacionālā aizmugursistēma ( NB ) vienības no sava atsaukšanas saraksta dzēš, kad tiek sasniegts derīguma termiņš .

— NB no sava atsaukšanas saraksta vienības var dzēst, ja tiek atsaukts DCC parakstīšanai izmantotais kid .

9.5.1.2.2.1. Ieraksti







Lauks Obligāts Veids Definīcija hash Jā String Sākotnējie 128 biti no SHA256 kontrolsummas, kas kodēta kā base64 virkne.

Piezīme. Ierakstu objekts pašlaik satur tikai kontrolsummu, bet, lai tas būtu saderīgs ar izmaiņām nākotnē, tika izvēlēts objekts, nevis json kopa.

9.5.1.2.2.2. Atbildes kodi







Kods Apraksts 200 Viss kārtībā. 410 Partijas nav. Partiju var dzēst nacionālajā aizmugursistēmā.

9.5.1.2.2.3. Atbildes galvenes







Galvene Apraksts ETag Partijas ID.

9.5.1.2.3. Partijas augšupielādes galapunkts

Augšupielādi veic ar to pašu galapunktu, izmantojot verbu 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’ }, ..]

}

Partiju paraksta, izmantojot NBUP sertifikātu. Vārteja verificē, vai parakstu ir noteicis attiecīgās valsts NBUP . Ja paraksta pārbaude neizdodas, augšupielāde nenotiek.

PIEZĪME. Katra partija ir nemaināma, un to nevar izmainīt pēc augšupielādes. Bet to var izdzēst. Katras dzēstās partijas ID tiek glabāts, un jaunas partijas augšupielāde ar tādu pašu ID tiek noraidīta.

9.5.1.2.4. Partijas dzēšanas galapunkts

Partiju no tāda paša galapunkta var izdzēst, izmantojot verbu DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

‘batchId’: ‘...’

}

vai saderības vajadzībām ar turpmāk minēto galapunktu, izmantojot verbu POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{

‘batchId’: ‘...’

}

9.6. API aizsardzība/GDPR

Šajā iedaļā aprakstīti īstenošanas pasākumi, ar kuriem izpilda Regulas (ES) 2021/953 prasības attiecībā uz persondatu apstrādi.

9.6.1. Pašreizējā autentifikācija

Šobrīd vārteja izmanto NBTLS sertifikātu, lai autentificētu valstis, kas savienojas ar vārteju. Šo autentifikāciju var izmantot, lai noteiktu ar vārteju savienotās valsts identitāti. Pēc tam šo identitāti var izmantot, lai kontrolētu piekļuvi.

9.6.2. Piekļuves kontrole

Lai likumīgi varētu apstrādāt persondatus, vārteja piemēro piekļuves kontroles mehānismu.

Vārteja izveido piekļuves kontroles sarakstu, ko izmanto kopā ar drošības pasākumiem, kuru pamatā ir lomas. Minētajā shēmā uztur divas tabulas: vienā tabulā apraksta, kādas darbības lomām ir atļautas ar attiecīgiem resursiem, otrā tabulā apraksta, kuras lomas lietotājiem piešķirtas.

Lai veiktu šajā dokumentā paredzēto kontroli, ir vajadzīgas trīs lomas:

RevocationListReader

RevocationUploader

RevocationDeleter

Turpmāk minētie galapunkti pārbauda, vai lietotājam ir loma RevocationListReader; ja lietotājam šī loma ir, piešķir piekļuvi, bet ja lietotājam šīs lomas nav, nosūta atbildi HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Turpmāk minētie galapunkti pārbauda, vai lietotājam ir loma RevocationUploader; ja lietotājam šī loma ir, piešķir piekļuvi, bet ja lietotājam šīs lomas nav, nosūta atbildi HTTP 403 Forbidden:

POST/revocation-list

Turpmāk minētie galapunkti pārbauda, vai lietotājam ir loma RevocationDeleter; ja lietotājam šī loma ir, piešķir piekļuvi, bet ja lietotājam šīs lomas nav, nosūta atbildi HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Vārteja nodrošina uzticamu metodi, ar ko administratori var pārvaldīt ar lietotājiem saistītās lomas tā, lai samazinātu cilvēka kļūdas, vienlaikus neapgrūtinot funkcionālos administratorus.

▼M1









II PIELIKUMS

NOTEIKUMI ATTIECĪBĀ UZ ES DIGITĀLĀ COVID SERTIFIKĀTA AIZPILDĪŠANU

Vispārīgo noteikumu, kas attiecas uz šajā pielikumā noteiktajām vērtību kopām, mērķis ir nodrošināt sadarbspēju semantiskā līmenī un panākt ES digitālā Covid sertifikāta vienotu tehnisko ieviešanu. Šajā pielikumā ietvertos elementus var izmantot trijos dažādos iestatījumos (vakcinācija/tests/pārslimošana), kā noteikts Regulā (ES) 2021/953. Šajā pielikumā ir uzskaitīti tikai tie elementi, kam nepieciešama semantiska standartizācija, izmantojot kodētas vērtību kopas.

Kodēto elementu tulkošana valsts valodā ir dalībvalstu kompetencē.

Visiem datu laukiem, kas nav minēti turpmākajos vērtību kopu aprakstos, kodējums ir aprakstīts V pielikumā.

Ja kāda iemesla dēļ turpmāk norādītās vēlamās kodu sistēmas nevar izmantot, tad drīkst izmantot citas starptautiskas kodu sistēmas un izstrādāt ieteikumus par to, kā citas kodu sistēmas kodus samēro ar vēlamo kodu sistēmu. Ja noteiktajās vērtību kopās nav pieejams piemērots kods, izņēmuma gadījumos kā rezerves mehānismu var izmantot tekstu (parādīt nosaukumus).

Dalībvalstis, kas savās sistēmās izmanto cita veida kodēšanu, šādus kodus samēro ar aprakstītajām vērtību kopām. Par šādu samērošanu atbildīgas ir dalībvalstis.

Tā kā dažas vērtību kopas, kuru pamatā ir šajā pielikumā paredzētās kodēšanas sistēmas, piemēram, vakcīnu un ātrā antigēna testa kodēšanas sistēmas, bieži mainās, Komisija tās publicē un regulāri atjaunina ar e-veselības tīkla un Veselības drošības komitejas atbalstu. Atjauninātās vērtību kopas publicē attiecīgajā Komisijas tīmekļvietnē, kā arī e-veselības tīkla tīmekļa lapā. Nodrošina izmaiņu vēsturi.

1. Mērķa slimība vai ierosinātājs/slimība, ko sertifikāta turētājs ir pārslimojis, vai tās ierosinātājs: Covid-19 (SARS-CoV-2 vai viens no tā variantiem)

Jāizmanto sertifikātā Nr. 1, 2, 3.

Izmanto šādu kodu:







Kods Displejs Koda sistēmas nosaukums Koda sistēmas URL Koda sistēmas OID Koda sistēmas versija 840539006 Covid-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

2. Covid-19 vakcīna vai profilakse

Vēlamā kodu sistēma: SNOMED CT vai ATC klasifikācija.

Jāizmanto sertifikātā Nr. 1.

Piemēri no vēlamajām kodu sistēmām izmantojamajiem kodiem: SNOMED CT kods 1119305005 (SARS-CoV-2 antigēna vakcīna), 1119349007 (SARS-CoV-2 mRNS vakcīna) vai J07BX03 (Covid-19 vakcīnas).

Vērtību kopu, kurā noteikti kodi, kas jāizmanto saskaņā ar šajā iedaļā noteiktajām kodu sistēmām, Komisija publicē un regulāri atjaunina ar e-veselības tīkla atbalstu. Vērtību kopu paplašina, kad tiek izstrādāti un ieviesti jauni vakcīnu veidi.

3. Covid-19 vakcīna (zāles)

Vēlamās kodu sistēmas (prioritārā secībā):

— Savienības Zāļu reģistrs, kurā iekļautas ES mērogā atļautas vakcīnas (atļaujas numuri),

— pasaules mēroga vakcīnu reģistrs, ko varētu izveidot Pasaules Veselības organizācija,

— pārējos gadījumos vakcīnas (zāļu) nosaukums. Ja nosaukums ietver atstarpes, tās aizstāj ar defisi (-).

Vērtību kopas nosaukums: vakcīna.

Jāizmanto sertifikātā Nr. 1.

Piemērs no vēlamajām kodu sistēmām izmantojamajam kodam: EU/1/20/1528 (Comirnaty). Vakcīnas nosaukuma, ko izmanto kā kodu, piemērs: Sputnik-V (nozīmē Sputnik V).

Vērtību kopu, kurā noteikti kodi, kas jāizmanto saskaņā ar šajā iedaļā noteiktajām kodu sistēmām, Komisija publicē un regulāri atjaunina ar e-veselības tīkla atbalstu.

Vakcīnas kodē, izmantojot jau esošu kodu publicētajā vērtību kopā, pat ja to nosaukumi dažādās valstīs atšķiras. Iemesls ir tāds, ka vēl nav pasaules mēroga vakcīnu reģistra, kurā iekļautu visas vakcīnas, kas pašlaik tiek izmantotas. Piemērs:

— Vakcīnai “Covid-19 Vaccine Moderna Intramuscular Injection”, kas ir Japānas vakcīnas Spikevax nosaukums, izmanto kodu EU/1/20/1507, jo tas ir šīs vakcīnas nosaukums ES.

Ja konkrētajā gadījumā tas nav iespējams vai ieteicams, publicētajā vērtību kopā tiks norādīts atsevišķs kods.

4. Covid-19 vakcīnas tirdzniecības atļaujas turētājs vai ražotājs

Vēlamā kodu sistēma:

— EMA organizācijas kods ( SPOR sistēma attiecībā uz ISO IDMP ),

— Pasaules mēroga vakcīnu tirdzniecības atļaujas turētāju vai ražotāju reģistrs, ko varētu izveidot Pasaules Veselības organizācija,

— pārējos gadījumos organizācijas nosaukums. Ja nosaukums ietver atstarpes, tās aizstāj ar defisi (-).

Jāizmanto sertifikātā Nr. 1.

Piemērs no vēlamās kodu sistēmas izmantojamajam kodam: ORG-100001699 (AstraZeneca AB). Organizācijas nosaukuma, ko izmanto kā kodu, piemērs: Sinovac-Biotech (nozīmē Sinovac Biotech).

Vērtību kopu, kurā noteikti kodi, kas jāizmanto saskaņā ar šajā iedaļā noteiktajām kodu sistēmām, Komisija publicē un regulāri atjaunina ar e-veselības tīkla atbalstu.

Tirdzniecības atļaujas turētāja vai tā paša ražotāja dažādās filiāles publicētajā vērtību kopā izmanto esošu kodu.

Parasti vienam un tam pašam vakcīnas produktam izmanto kodu, kas atsaucas uz tā tirdzniecības atļaujas turētāju ES, jo vēl nav starptautiski saskaņota vakcīnas ražotāju vai tirdzniecības atļaujas turētāju reģistra. Piemēri:

— Organizācijai Pfizer AG , kas ir Šveicē izmantotās vakcīnas Comirnaty tirdzniecības atļaujas turētājs, izmanto kodu ORG-100030215, kas atsaucas uz BioNTech Manufacturing GmbH , jo tas ir Comirnaty tirdzniecības atļaujas turētājs ES.

— Organizācijai Zuellig Pharma , kas ir Filipīnās izmantotās vakcīnas Covid-19 Vaccine Moderna ( Spikevax ) tirdzniecības atļaujas turētājs, izmanto kodu ORG-100031184, kas atsaucas uz Moderna Biotech Spain S.L. , jo tas ir Spikevax tirdzniecības atļaujas turētājs ES.

Ja konkrētajā gadījumā tas nav iespējams vai ieteicams, publicētajā vērtību kopā tiks norādīts atsevišķs kods.

5. Devas kārtas numurs vakcinācijas kursā, kā arī kopējais devu skaits vakcinācijas kursā

Jāizmanto sertifikātā Nr. 1.

Divi lauki:

1) Covid-19 vakcīnas devas kārtas numurs vakcinācijas kursā (N);

2) Kopējais devu skaits vakcinācijas kursā (C).

5.1. Pirmreizējās vakcinācijas kurss

Ja persona saņem pirmreizējās vakcinācijas kursa devas, tas ir, vakcinācijas kurss, kas paredzēts, lai nodrošinātu pietiekamu aizsardzību sākotnējā posmā, (C) norāda standarta pirmreizējās vakcinācijas kursa kopējo devu skaitu (piemēram, 1 vai 2 atkarībā no ievadītās vakcīnas veida). Tas ietver iespēju izmantot īsāku kursu (C=1), ja dalībvalsts piemērotais vakcinācijas protokols paredz 2 devu vakcīnas vienreizējas devas ievadīšanu personām, kuras iepriekš bijušas inficētas ar SARS-CoV-2. Tādējādi pabeigto pirmreizējās vakcinācijas kursu norāda ar N/C = 1. Piemēram,

— 1/1 norādītu, ka ir pabeigts pirmreizējās vienas devas vakcinācijas kurss vai pabeigts pirmreizējais kurss, kas sastāv no 2 devu vienreizējas devas vakcīnas, ko ievada personai, kas šo infekciju ir pārslimojusi, saskaņā ar dalībvalsts piemēroto vakcinācijas protokolu.

— 2/2 norādītu to, ka ir pabeigts pirmreizējās 2 devu vakcinācijas kurss.

Ja pirmreizējās vakcinācijas kurss tiek pagarināts, piemēram, personām ar stipri novājinātu imūnsistēmu vai ja nav ievērots ieteicamais intervāls starp pirmreizējām devām, katru no šādām devām kodē kā papildu devas, uz kurām attiecas 5.2. iedaļa.

▼M2

5.2. Balstdevas

Ja persona saņem vakcīnas devas pēc pirmreizējās vakcinācijas kursa, šādas balstdevas attiecīgajos sertifikātos atspoguļo šādi:

— ar 2/1 norāda balstdevas ievadīšanu pēc vienas devas pirmreizējās vakcinācijas kursa vai balstdevas ievadīšanu pēc divu devu vakcīnas vienas devas pirmreizējās vakcinācijas kursa pārslimojušai personai saskaņā ar dalībvalsts piemēroto vakcinācijas protokolu. Pēc tam devas (X), ko ievada pēc pirmās balstdevas, norāda ar (2+X)/(1) > 1 (piemēram, 3/1),

— ar 3/3 norāda balstdevas ievadīšanu pēc divu devu pirmreizējās vakcinācijas kursa. Pēc tam devas (X), ko ievada pēc pirmās balstdevas, norāda ar (3+X)/(3+X) = 1 (piemēram, 4/4).

Šajā iedaļā noteiktos aizpildīšanas noteikumus dalībvalstis ievieš līdz 2022. gada 1. februārim.

Dalībvalstis automātiski vai pēc attiecīgo personu pieprasījuma atkārtoti izdod sertifikātus, kuros balstdevas ievadīšana pēc vienas devas pirmreizējās vakcinācijas kursa ir reģistrēta tā, ka to nevar atšķirt no pirmreizējās vakcinācijas kursa pabeigšanas.

Šajā pielikumā termins “balstdeva” ietver arī papildu devas, ko ievada, lai labāk aizsargātu indivīdus, kuriem pēc standarta pirmreizējās vakcinācijas kursa pabeigšanas uzrādās nepietiekama imūnreakcija. Ievērojot ar Regulu (ES) 2021/953 izveidoto tiesisko regulējumu, dalībvalstis var veikt pasākumus attiecībā uz neaizsargāto grupu personām, kuras var saņemt papildu devas prioritārā kārtā. Piemēram, ja dalībvalsts nolemj piedāvāt papildu devas tikai konkrētām iedzīvotāju apakšgrupām, tā saskaņā ar Regulas (ES) 2021/953 5. panta 1. punktu var izvēlēties izdot vakcinācijas sertifikātus par šādu papildu devu ievadīšanu tikai pēc pieprasījuma, nevis automātiski. Ja šādi pasākumi tiek veikti, dalībvalstis par to informē attiecīgās personas, norādot arī to, ka tās var turpināt izmantot sertifikātu, kas saņemts pēc standarta pirmreizējās vakcinācijas kursa pabeigšanas.

▼M1

6. Dalībvalsts vai trešā valsts, kurā saņemta vakcīna/veikts tests

Vēlamā kodu sistēma: ISO 3166 valstu kodi.

Jāizmanto sertifikātā Nr. 1, 2, 3.

Vērtību kopas saturs: pilns divu burtu kodu saraksts, pieejams kā vērtību kopa, kas noteikta FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). Ja vakcināciju vai testu ir veikusi starptautiska organizācija (piemēram, UNHCR vai PVO) un informācija par valsti nav pieejama, izmanto organizācijas kodu. Komisija publicē un regulāri atjaunina šādus papildu kodus ar e-veselības tīkla atbalstu.

7. Testa veids

Jāizmanto sertifikātā Nr. 2, kā arī sertifikātā Nr. 3, ja ar deleģēto aktu tiek ieviests atbalsts tādu pārslimošanas sertifikātu izdošanai, kuru pamatā ir citi testu veidi, nevis NAAT.

Izmanto šādus kodus.







Kods Displejs Koda sistēmas nosaukums Koda sistēmas URL Koda sistēmas OID Koda sistēmas versija LP6464-4 Nukleīnskābes amplifikācijas tests ar zondes noteikšanu LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Ātrā imūnanalīze LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

8. Izmantotā testa ražotājs un tirdzniecības nosaukums (NAAT testa gadījumā fakultatīvi)

Jāizmanto sertifikātā Nr. 2.

Vērtību kopas saturs ietver tāda ātrā antigēna testa atlasi, kas iekļauts Covid-19 ātro antigēna testu kopīgajā un atjauninātajā sarakstā, kurš izveidots, pamatojoties uz Padomes Ieteikumu 2021/C 24/01, un saskaņots ar Veselības drošības komiteju. Šo sarakstu uztur JRC Covid-19 in vitro diagnostikas iekārtu un testēšanas metožu datubāzē, kas pieejama tīmekļa lapā https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

Šai kodu sistēmai izmanto attiecīgos laukus, piemēram, testa ierīces identifikators, testa nosaukums un ražotājs, ievērojot JRC strukturēto formātu, kas pieejams tīmekļa lapā https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9. Testa rezultāts

Jāizmanto sertifikātā Nr. 2.

Izmanto šādus kodus.







Kods Displejs Koda sistēmas nosaukums Koda sistēmas URL Koda sistēmas OID Koda sistēmas versija 260415000 Nav konstatēts SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Konstatēts SNOMED CT http://snomed.info/sct 2.16.840.96.113883.6.1 2021-01-31

▼B









III PIELIKUMS

UNIKĀLĀ SERTIFIKĀTA IDENTIFIKATORA KOPĪGĀ STRUKTŪRA

1. Ievads

Katrā ES digitālajā Covid sertifikātā (DCC) iekļauj unikālu sertifikāta identifikatoru (UCI), kas atbalsta DCC sadarbspēju. UCI var izmantot sertifikāta verifikācijai. Par UCI ieviešanu atbildīgas ir dalībvalstis. UCI izmanto, lai pārliecinātos par sertifikāta patiesumu un attiecīgā gadījumā savienotos ar reģistrācijas sistēmu (piemēram, IIS). Šie identifikatori arī dalībvalstīm ļauj (papīra formātā un digitāli) apliecināt, ka personas ir vakcinētas vai testētas.

2. Unikālā sertifikāta identifikatora sastāvs

UCI veido atbilstoši kopīgai struktūrai un formātam, kas atvieglo informācijas sniegšanu cilvēklasāmā un/vai mašīnlasāmā formātā un var attiekties uz tādiem elementiem kā vakcinācijas dalībvalsts, pati vakcīna un dalībvalsts īpašais identifikators. Tas nodrošina dalībvalstīm elastību UCI noformēšanā, pilnībā ievērojot datu aizsardzības tiesību aktus. Atsevišķo elementu secība atbilst noteiktai hierarhijai, kas var iespējot bloku turpmāku pārveidošanu, vienlaikus saglabājot strukturālo integritāti.

Iespējamie risinājumi attiecībā uz UCI sastāvu veido spektru, kura divi galvenie dažādojošie parametri ir modularitāte un cilvēklasāms formāts un kuram ir viena pamatīpašība:

— modularitāte: cik lielā mērā kods sastāv no atšķirīgiem veidojošiem blokiem, kas satur semantiski atšķirīgu informāciju,

— cilvēklasāms formāts: cik lielā mērā kods ir jēgpilns vai cik lielā mērā cilvēks to var nolasīt,

— unikalitāte pasaulē: valsts vai iestādes identifikators ir labi pārvaldīts; tiek gaidīts, ka katra valsts (iestāde) labi pārvalda savu nosaukumu telpas segmentu, identifikatorus nekad nereciklē un neizdod atkārtoti. Šāda kombinācija nodrošina, ka katrs identifikators ir pasaulē unikāls.

▼M1

3. Vispārīgas prasības

Attiecībā uz UCI ir jāizpilda šādas galvenās prasības:

1) Rakstzīmju kopa: ir atļautas tikai lielo burtu US-ASCII burtciparu rakstzīmes (no “A” līdz “Z”, no “0” līdz “9”), izmantojot RFC3986 ( 14 ) noteiktās papildu īpašās rakstzīmes atdalīšanai, proti, {“/”“#”, “:”};

2) Maksimālais garums: izstrādātājiem jāmēģina sasniegt 27-30 rakstzīmes ( 15 );

3) Versijas prefikss: attiecas uz UCI shēmas versiju. Šīs dokumenta redakcijas versijas prefikss ir “01”; versijas prefiksu veido divi cipari;

4) valsts prefikss: ISO 3166-1 norādītais valsts kods. Garāki kodi (piemēram, trīs un vairāk rakstzīmes (piemēram, “UNHCR”)) ir rezervēti izmantošanai nākotnē;

5) koda sufikss / kontrolsumma: 5.1. Dalībvalstis var izmantot kontrolsummu, ja ir iespējams, ka var rasties pārnese, (cilvēka) pārrakstīšanās vai cita veida kļūdas (t. i., ja izmanto drukātā veidā). 5.2. Kontrolsummu neizmanto sertifikāta validēšanā, un tā tehniski ir nevis identifikatora daļa, bet gan tiek izmantota, lai pārliecinātos par koda integritāti. Šī kontrolsumma atbilst ISO-7812-1 (LUHN-10) ( 16 ) kopsavilkumam attiecībā uz visu UCI digitāli/pa vadiem pārnestā formātā. Kontrolsummu no pārējā UCI atdala ar zīmi “#”.

Nodrošina atgriezenisko savietojamību: dalībvalstis, kas laika gaitā maina savu identifikatoru struktūru (galvenās versijas ietvaros, pašlaik v1), nodrošina, ka jebkuri divi identiski identifikatori attiecas uz vienu un to pašu vakcinācijas sertifikātu/apliecinājumu. Vai, citiem vārdiem sakot, dalībvalstis nedrīkst reciklēt identifikatorus.

▼B

4. Vakcinācijas sertifikātu unikālo sertifikāta identifikatoru iespējas

E-veselības tīkla pamatnostādnēs par verificējamiem vakcinācijas sertifikātiem un sadarbspējas pamatelementiem ( 17 ) ir paredzētas atšķirīgas iespējas, kas pieejamas dalībvalstīm un citām pusēm un kas dažādās dalībvalstīs var pastāvēt līdzās. Dalībvalstis var izmantot šādas atšķirīgas iespējas dažādās UCI shēmas versijās.









IV PIELIKUMS

PUBLISKĀS ATSLĒGAS SERTIFIKĀTU PĀRVALDĪBA

1. Ievads

Drošu un uzticamu ES digitālo Covid sertifikātu (DCC) parakstīšanas atslēgu apmaiņu starp dalībvalstīm īsteno ES digitālo Covid sertifikātu vārteja (DCCG), kas darbojas kā publisko atslēgu centrālais repozitorijs. DCCG dod dalībvalstīm tiesības publicēt publiskās atslēgas, kas atbilst privātajām atslēgām, kuras tās izmanto digitālo Covid sertifikātu parakstīšanai. Piedalīgās dalībvalstis ES digitālo Covid sertifikātu vārteju var izmantot, lai savlaicīgi saņemtu jaunākos materiālus par publiskajām atslēgām. DCCG pēc tam var paplašināt, lai apmainītos ar uzticamu papildu informāciju, ko sniedz dalībvalstis, piemēram, par DCC validēšanas noteikumiem. DCC sistēmas uzticamības modelis ir publiskās atslēgas infrastruktūra (PKI). Katrai dalībvalstij ir viena vai vairākas valsts parakstīšanas sertificēšanas iestādes (CSCA), kuru sertifikāti ir salīdzinoši ilglaicīgi. Atbilstoši dalībvalsts lēmumam CSCA var būt tā pati CSCA, ko izmanto mašīnlasāmiem ceļošanas dokumentiem, vai arī cita. CSCA izdod publiskās atslēgas sertifikātus īstermiņa valsts dokumentu parakstītājiem (t. i., DCC parakstītājiem), un tos sauc par dokumentu parakstītāju sertifikātiem (DSC). CSCA darbojas kā uzticamības enkurs, kas nodrošina, ka piedalīgās dalībvalstis CSCA sertifikātu var izmantot, lai validētu regulāri mainīgo DSC autentiskumu un integritāti. Pēc validācijas dalībvalstis šos sertifikātus (vai tikai tajos ietvertās publiskās atslēgas) var izmantot saviem DCC validācijas pieteikumiem. Lai autentificētu transakcijas, parakstītu datus, izmantotu par pamatu autentificēšanai un nodrošinātu komunikācijas kanālu integritāti starp dalībvalstīm un DCCG, ES digitālo Covid sertifikātu vārteja papildus CSCA un DSC izmanto arī PKI.

Digitālos parakstus var izmantot, lai nodrošinātu datu integritāti un autentiskumu. Publisko atslēgu infrastruktūras ir uzticamas, jo publiskās atslēgas tiek piesaistītas verificētām identitātēm (vai izdevējiem). Tas ir nepieciešams, lai ļautu citiem dalībniekiem pārliecināties par komunikācijas partnera datu izcelsmi un identitāti un lemt par uzticēšanos. ES digitālo Covid sertifikātu vārtejā autentificēšanai tiek izmantoti vairāki publisko atslēgu sertifikāti. Šajā pielikumā ir noteikts, kuri publiskās atslēgas sertifikāti tiek izmantoti un kā tie jāizstrādā tā, lai nodrošinātu plašu sadarbspēju starp dalībvalstīm. Tajā sniegta sīkāka informācija par nepieciešamajiem publiskās atslēgas sertifikātiem un sniegti norādījumi par sertifikātu veidnēm un derīguma periodiem dalībvalstīm, kuras vēlas izmantot savu CSCA. Tā kā DCC ir verificējami noteiktā laikposmā (no izdošanas brīža līdz beigu termiņam pēc noteikta laika), ir jānosaka verifikācijas modelis attiecībā uz visiem parakstiem, ko izmanto publiskās atslēgas sertifikātos un DCC.

2. Terminoloģija

Nākamajā tabulā ir ietverti šajā pielikumā izmantotie saīsinājumi un terminoloģija.







Termins Definīcija Sertifikāts Vai publiskās atslēgas sertifikāts. X.509 v3 sertifikāts, kas satur subjekta publisko atslēgu CSCA Valsts parakstīšanas sertificēšanas iestāde DCC ES digitālais Covid sertifikāts. Parakstīts elektroniskais dokuments, kas satur informāciju par vakcināciju, testu vai pārslimošanu DCCG ES digitālo Covid sertifikātu vārteja. Šo sistēmu izmanto, lai starp dalībvalstīm apmainītos ar DSC DCCG TA DCCG uzticamības enkura sertifikāts. Attiecīgo privāto atslēgu izmanto, lai visu CSCA sertifikātu sarakstu parakstītu bezsaistē DCCG TLS DCCG TLS servera sertifikāts DSC Dokumenta parakstītāja sertifikāts. Dalībvalsts dokumentu parakstītājiestādes (piemēram, sistēma, kas ir pilnvarota parakstīt DCC) publiskās atslēgas sertifikāts. Šo sertifikātu izdod dalībvalsts CSCA EC-DSA Eliptiskās līknes digitālā paraksta algoritms. Paraksta šifrēšanas algoritms, kura pamatā ir eliptiskas līknes Dalībvalsts Eiropas Savienības dalībvalsts mTLS Savstarpēja TLS. Transporta slāņa drošības protokols ar savstarpēju autentifikāciju NB Dalībvalsts nacionālā aizmugursistēma NB CSCA Dalībvalsts CSCA sertifikāts (var būt vairāk nekā viens) NB TLS Nacionālās aizmugursistēmas TLS klienta autentifikācijas sertifikāts NB UP Sertifikāts, ko nacionālajā aizmugursistēmā izmanto, lai parakstītu datu pakotnes, kas augšupielādētas DCCG PKI Publiskās atslēgas infrastruktūra. Uzticamības modelis, kura pamatā ir publiskās atslēgas sertifikāti un sertificēšanas iestādes RSA Asimetrisks šifrēšanas algoritms, kura pamatā ir sadalīšana reizinātājos, ko izmanto digitālajiem parakstiem vai asimetriskai šifrēšanai

3. DCCG komunikācijas plūsmas un drošības pakalpojumi

Šajā iedaļā sniegts pārskats par komunikācijas plūsmām un drošības pakalpojumiem DCCG sistēmā. Tajā arī noteikts, kuras atslēgas un sertifikātus izmanto, lai aizsargātu komunikāciju, augšupielādēto informāciju, DCC un parakstītu uzticamības sarakstu, kurā ir visi ietvertie CSCA sertifikāti. DCCG darbojas kā datu centrs, kas dalībvalstīm ļauj apmainīties ar parakstīto datu pakotnēm.

Augšupielādētās datu pakotnes ES digitālo Covid sertifikātu vārteja nodrošina “faktiskajā stāvoklī”, proti, saņemtajām pakotnēm vārtejā DSC netiek pievienoti un netiek no tām izņemti. Dalībvalstu nacionālajai aizmugursistēmai (NB) ir jāspēj verificēt augšupielādēto datu pilnīgumu un autentiskumu visā komunikācijas ceļā. Turklāt, lai izveidotu drošu savienojumu, nacionālās aizmugursistēmas un DCCG izmanto savstarpēju TLS autentifikāciju. Šī darbība papildina parakstus datos, ar kuriem notiek apmaiņa.

3.1. Autentifikācija un savienojuma izveide

Lai izveidotu autentificētu šifrētu kanālu starp dalībvalsts nacionālo aizmugursistēmu (NB) un vārtejas vidi, DCCG izmanto transporta slāņa drošību (TLS) ar savstarpēju autentifikāciju. Šajā nolūkā ES digitālo Covid sertifikātu vārtejai ir TLS servera sertifikāts (saīsinājumā DCCG TLS) un nacionālajām aizmugursistēmām ir TLS klienta sertifikāts (saīsinājumā NB TLS). Sertifikātu veidnes ir sniegtas 5. iedaļā. Katra nacionālā aizmugursistēma var nodrošināt savu TLS sertifikātu. Šo sertifikātu skaidri norāda baltajā sarakstā, un tāpēc to var izdot uzticama publiska sertifikācijas iestāde (piemēram, sertifikācijas iestāde, kas atbilst CA/Browser Forum pamatprasībām), valsts sertificēšanas iestāde vai tā var būt pašparakstīta. Katra dalībvalsts ir atbildīga par saviem valsts datiem un privātās atslēgas aizsardzību, ko izmanto, lai izveidotu savienojumu ar DCCG. Pieeja “Iesniedz savu sertifikātu” prasa skaidri definētu reģistrācijas un identifikācijas procesu, kā arī atsaukšanas un atjaunošanas procedūras, kas aprakstītas 4.1., 4.2. un 4.3. iedaļā. DCCG izmanto balto sarakstu, kurā pēc sekmīgas reģistrācijas tiek pievienoti nacionālo aizmugursistēmu TLS sertifikāti. Drošu savienojumu ar DCCG var izveidot tikai tādas NB, kas autentificējas ar privātu atslēgu, kura atbilst baltajā sarakstā iekļautam sertifikātam. DCCG izmanto arī TLS sertifikātu, kas ļauj NB pārliecināties, ka tās izveido savienojumu ar “patieso”DCCG, nevis kādu citu subjektu, kas ļaunprātīgi uzdodas par DCCG. Nacionālajām aizmugursistēmām DCCG sertifikāts tiek nodrošināts pēc sekmīgas reģistrācijas. DCCG TLS sertifikātu izdod uzticama publiska sertificēšanas iestāde (iekļauta visās lielākajās pārlūkprogrammās). Dalībvalstu pienākums ir pārliecināties, ka to pieslēgums DCCG ir drošs (piemēram, pārbaudīt pieslēgtā servera DCCG TLS sertifikāta digitālnospiedumu salīdzinājumā ar digitālnospiedumu, kas sniegts pēc reģistrācijas).

3.2. Valsts parakstīšanas sertificēšanas iestādes un validācijas modelis

Dalībvalstīm, kas piedalās DCCG satvarā, DSC izdošanai jāizmanto CSCA. Dalībvalstīm var būt vairāk nekā viens CSCA, piemēram, ja vara nodota reģioniem. Katra dalībvalsts var vai nu izmantot pastāvošas sertificēšanas iestādes, vai izveidot īpašu (varbūt pašparakstītu sertifikātu) sertificēšanas iestādi DCC sistēmai.

Dalībvalstīm savi CSCA sertifikāti jāuzrāda DCCG operatoram oficiālās pievienošanas procedūras gaitā. Kad dalībvalsts būs reģistrēta (sīkākai informācijai sk. 4.1. iedaļu), DCCG operators atjauninās parakstītu uzticamības sarakstu, kurā ir visi CSCA sertifikāti, kas ir aktīvi DCC satvarā. DCCG operators izmantos īpašu asimetrisku atslēgu pāri, lai uzticamības sarakstu un sertifikātus varētu parakstīt bezsaistes vidē. Šī privātā atslēga netiks uzglabāta tiešsaistes DCCG sistēmā, lai gadījumā, ja tiešsaistes sistēma tiktu kompromitēta, uzbrucējs nevarētu kompromitēt uzticamības sarakstu. Nacionālajām aizmugursistēmām pievienošanas procesā tiks izsniegts atbilstošais uzticamības enkura sertifikāts DCCGTA .

Dalībvalstis uzticamības sarakstu var iegūt no DCCG savām verifikācijas procedūrām. CSCA ir definēta kā sertificēšanas iestāde, kas izdod DSC, tāpēc dalībvalstīm, kas izmanto daudzlīmeņu CA hierarhiju (piemēram, Root CA -> CSCA -> DSC), jānorāda padotā sertificēšanas iestāde, kas izdod DSC. Šajā gadījumā, ja dalībvalsts izmanto pastāvošu sertificēšanas iestādi, tad DCC sistēma ignorēs visu, kas ir virs CSCA, un baltajā sarakstā kā uzticamības enkuru iekļaus tikai CSCA (kaut arī tā ir padota sertificēšanas iestāde). Tas ir tāpēc, ka ICAO modelis pieļauj tikai tieši divus līmeņus – “root”CSCA un “leaf’ DSC”, ko parakstījusi šī konkrētā CSCA.

Ja dalībvalstij ir pašai sava CSCA, tad dalībvalsts ir atbildīga par šīs sertificēšanas iestādes drošu darbību un atslēgu pārvaldību. CSCA funkcionē kā DSC uzticamības enkurs, un tāpēc DCC vides integritātes nolūkā būtiski ir aizsargāt CSCA privāto atslēgu. Verifikācijas modelis DCC PKI ir čaulas modelis, kas nosaka, ka visiem sertifikātiem sertifikātu ķēdes validācijā jābūt derīgiem konkrētajā laika momentā (t. i., paraksta validēšanas laikā). Tāpēc piemēro šādus ierobežojumus:

— CSCA neizdod sertifikātus, kas ir derīgi ilgāk nekā pats sertificēšanas iestādes sertifikāts,

— dokumentu parakstītājs neparaksta dokumentus, kas ir derīgi ilgāk nekā pats DSC ,

— Dalībvalstīm, kurām ir sava CSCA , jānosaka derīguma termiņi savai CSCA un visiem izdotajiem sertifikātiem, un tām jārūpējas par sertifikātu pagarināšanu.

Ieteikumi par derīguma termiņiem ir izklāstīti 4.2. iedaļā.

3.3. Augšupielādēto datu integritāte un autentiskums

Nacionālās aizmugursistēmas var DCCG izmantot digitāli parakstītas datu pakotnes augšupielādēšanai un lejupielādēšanai pēc sekmīgas savstarpējas autentifikācijas. Sākumā šīs datu pakotnes satur dalībvalstu DSC. Atslēgu pāri, ko izmanto nacionālajā aizmugursistēmā augšupielādētu datu pakotņu digitālai parakstīšanai DCCG sistēmā, sauc par nacionālās aizmugursistēmas augšupielādes paraksta atslēgu pāri, un atbilstošais publiskās atslēgas sertifikāts saīsināti tiek saukts par NBUP sertifikātu. Katrai dalībvalstij ir pašai savs NBUP sertifikāts, kas var būt pašparakstīts vai to var būt izdevusi pastāvoša sertificēšanas iestāde, piemēram, publiska sertificēšanas iestāde (t. i., sertificēšanas iestāde, kas sertifikātu izdod atbilstoši CAB Forum pamatprasībām). NBUP sertifikātam jāatšķiras no visiem citiem sertifikātiem, ko izmanto dalībvalsts (t. i., CSCA, TLS klients vai DSC).

Dalībvalstīm jāizsniedz augšupielādes sertifikāts DCCG operatoram sākotnējās reģistrācijas procedūras gaitā (sīkākai informācijai sk. 4.1. iedaļu). Katra dalībvalsts ir atbildīga par saviem valsts datiem, un tai jāaizsargā privātā atslēga, kas tiek izmantota augšupielāžu parakstīšanai.

Citas dalībvalstis parakstītās datu pakotnes var verificēt, izmantojot augšupielādes sertifikātus, ko sniedz DCCG. DCCG verificē augšupielādēto datu autentiskumu un integritāti ar NB augšupielādes sertifikātu, pirms tie tiek sniegti citām dalībvalstīm.

3.4. Tehniskās DCCG arhitektūras prasības

Tehniskās DCCG arhitektūras prasības ir šādas.

— DCCG izmanto savstarpēju TLS autentificēšanu, lai izveidotu autentificētu šifrētu savienojumu ar NB . Tāpēc DCCG uztur balto sarakstu ar reģistrētiem NB TLS klientu sertifikātiem.

— DCCG izmanto divus digitālos sertifikātus ( DCCG TLS un DCCG TA ) ar diviem atšķirīgiem atslēgu pāriem. DCCG TA atslēgu pāra privātā atslēga tiek turēta bezsaistē (nevis uz DCCG tiešsaistes komponentiem).

— DCCG uztur uzticamības sarakstu ar NB CSCA sertifikātiem, kas tiek parakstīts ar DCCG TA privāto atslēgu.

— Izmantotajiem šifriem jāatbilst prasībām, kas izklāstītas 5.1. iedaļā .

4. Sertifikātu dzīves cikla pārvaldība

4.1. Nacionālo aizmugursistēmu reģistrācija

Lai dalībvalstis varētu piedalīties DCCG sistēmā, tām jāreģistrējas pie DCCG. Šajā iedaļā ir aprakstīta tehniskā un operatīvā procedūra, kas jāizpilda, lai reģistrētu nacionālo aizmugursistēmu.

DCCG operatoram un dalībvalstij jāapmainās ar informāciju par tehniskajām kontaktpersonām pievienošanas procesā. Pieņem, ka dalībvalstis ir legalizējušas savas tehniskās kontaktpersonas un ka identifikācija/autentifikācija tiek veikta, izmantojot citus kanālus. Piemēram, autentificēšanu var paveikt tad, kad dalībvalsts tehniskā kontaktpersona izsniedz sertifikātus ar paroli aizsargātu datņu veidā pa e-pastu un attiecīgo paroli pasaka DCCG operatoram pa tālruni. Var izmantot arī citus drošus kanālus, ko nosaka DCCG operators.

Dalībvalstij reģistrācijas un identificēšanas procesā jāsniedz trīs digitālie sertifikāti:

— dalībvalsts TLS sertifikāts NB TLS ,

— dalībvalsts augšupielādes sertifikāts NB UP ,

— dalībvalsts CSCA sertifikāts(-i) NB CSCA .

Visiem sniegtajiem sertifikātiem jāatbilst prasībām, kas noteiktas 5. iedaļā. DCCG operators pārbaudīs, vai sniegtais sertifikāts atbilst 5. iedaļā izklāstītajām prasībām. Pēc identificēšanas un reģistrēšanas DCCG operators:

— pievieno NB CSCA sertifikātu(-us) uzticamības sarakstam, kas parakstīts ar privāto atslēgu, kura atbilst DCCG TA publiskajai atslēgai,

— pievieno NB TLS sertifikātu DCCG TLS galapunkta baltajam sarakstam,

— ievada NB UP sertifikātu DCCG sistēmā,

— izsniedz DCCG TA un DCCG TLS publiskās atslēgas sertifikātu dalībvalstij.

4.2. Sertificēšanas iestādes, derīguma termiņi un pagarināšana

Ja dalībvalsts vēlas izmantot savu CSCA, CSCA sertifikāti var būt pašparakstīti sertifikāti. Tie pilda dalībvalsts uzticamības enkura funkciju, un tāpēc dalībvalstij labi jāaizsargā privātā atslēga, kas atbilst CSCA sertifikāta publiskajai atslēgai. Dalībvalstīm savai CSCA ir ieteicams izmantot bezsaistes sistēmu, proti, datorsistēmu, kas nav savienota ne ar vienu tīklu. Sistēmas piekļuvei jāizmanto vairāku personu kontrole (piemēram, četru acu princips). Pēc DSC parakstīšanas piemēro darbības kontroles, un sistēmu, kurā glabājas privātā CSCA atslēga, tur drošībā ar stingru piekļuves kontroli. Lai vēl labāk aizsargātu CSCA privāto atslēgu, var izmantot aparatūras drošības moduļus vai viedkartes. Digitālajos sertifikātos ir ietverts derīguma termiņš, kas mudina sertifikātu pagarināt. Pagarināšana ir vajadzīga, lai varētu izmantot jaunas šifrēšanas atslēgas un pielāgot atslēgu izmērus, kad jauni uzlabojumi skaitļošanā vai jauni uzbrukumi kompromitē izmantotā šifrēšanas algoritma drošību. Izmanto čaulas modeli (sk. 3.2. iedaļu).

Ņemot vērā digitālo Covid sertifikātu viena gada derīguma termiņu, ir ieteicami šādi derīguma termiņi:

— CSCA : 4 gadi,

— DSC : 2 gadi,

— Augšupielāde: 1–2 gadi,

— TLS klienta autentifikācija: 1–2 gadi.

Lai pagarināšana notiktu savlaicīgi, ir ieteicami šādi privāto atslēgu izmantošanas periodi:

— CSCA : 1 gads,

— DSC : 6 mēneši.

Dalībvalstīm jauni augšupielādes sertifikāti un TLS jāizveido savlaicīgi, piemēram, mēnesi pirms derīguma termiņa beigām, lai darbība notiktu bez traucējumiem. CSCA sertifikāti un DSC jāpagarina vismaz mēnesi pirms privātās atslēgas izmantošanas beigām (ņemot vērā vajadzīgās darbības procedūras). Dalībvalstīm atjauninātie CSCA sertifikāti, augšupielādes un TLS sertifikāti jāizsniedz DCCG operatoram. Sertifikāti, kuriem derīguma termiņš beidzies, jāizņem no baltā saraksta un uzticamības saraksta.

Dalībvalstīm un DCCG operatoram pašam jāseko līdzi savu sertifikātu derīgumam. Nav tādu centrālu struktūru, kas sertifikātu derīguma termiņam sekotu līdzi un formētu dalībniekus.

4.3. Sertifikātu atsaukšana

Principā digitālos sertifikātus var atsaukt tā sertificēšanas iestāde, kas tos izdevusi, un tam izmanto sertifikātu atsaukšanas sarakstus jeb tiešsaistes sertifikātu statusa pārbaudes protokolu (OCSP pakalpojumu). CSCA iestādei DCC sistēmai jānodrošina sertifikātu atsaukšanas saraksti (CRL). Lai arī citas dalībvalstis šos CRL pašlaik neizmanto, tiem jābūt integrētiem izmantošanai nākotnē. Ja CSCA nolemj CRL nenodrošināt, šīs CSCA DSC jābūt pagarinātiem, kad CRL kļūs obligāti. Verificētājiem DSC validēšanai jāizmanto CRL, nevis OCSP. Nacionālajai aizmugursistēmai ieteicams validēt no DCC vārtejas lejupielādētos DSC un pārsūtīt nacionālajiem DCC validētājiem tikai noteiktus uzticamus un validētus DSC. DCC validētājiem savā validācijas procesā nevajadzētu veikt nekādu DSC atsaukšanas pārbaudi. Viens iemesls ir tāds, lai aizsargātu DCC īpašnieku privātumu, nepieļaujot nekādu iespēju, ka kāda konkrēta DSC izmantošanu varētu pārraudzīt ar to saistītais OCSP.

Dalībvalstis var pašas no DCCG izņemt savus DSC, izmantojot derīgus augšupielādes un TLS sertifikātus. DSC izņemšana nozīmē, ka visi DCC, kas izdoti ar šo DSC, kļūs nederīgi, kad dalībvalstis dabūs atjauninātos DSC sarakstus. Ļoti svarīgi ir aizsargāt privāto atslēgu materiālu, kas atbilst DSC. Dalībvalstīm jāinformē DCCG operators, kad tām jāatsauc augšupielādes vai TLS sertifikāti, piemēram, tāpēc, ka ir kompromitēta nacionālā aizmugursistēma. DCCG operators tad var noņemt uzticamību skartajam sertifikātam, piemēram, izņemot to no TLS baltā saraksta. DCCG operators var izņemt augšupielādes sertifikātus no DCCG datubāzes. Pakotnes, kas parakstītas ar privāto atslēgu, kura atbilst šim augšupielādes sertifikātam, kļūs nederīgas, kad nacionālās aizmugursistēmas noņems atceltā augšupielādes sertifikāta uzticamību. Ja jāatsauc CSCA sertifikāts, dalībvalstis informē DCCG operatoru, kā arī citas dalībvalstis, ar kurām tām ir uzticamības attiecības. DCCG operators izdos jaunu uzticamības sarakstu, kurš vairs nesatur skarto sertifikātu. Visi šīs CSCA izdotie DSC kļūs nederīgi, kad dalībvalstis atjauninās savu nacionālās aizmugursistēmas uzticamības krātuvi. Ja jāatceļ DCCGTLS sertifikāts vai DCCGTA sertifikāts, DCCG operatoram un dalībvalstīm jāsadarbojas un jāizveido jauns uzticams TLS savienojums un uzticamības saraksts.

5. Sertifikātu veidnes

Šajā iedaļā ir izklāstītas šifrēšanas prasības un norādījumi, kā arī sertifikātu veidņu prasības. Šajā iedaļā ir noteiktas DCCG sertifikātu veidnes.

5.1. Šifrēšanas prasības

Šifrēšanas algoritmus un TLS šifra komplektus izvēlas, pamatojoties uz Vācijas Federālā informācijas drošības biroja (BSI) vai SOG-IS pašreizējo ieteikumu. Šie un citu iestāžu un standartizācijas organizācijas ieteikumi ir līdzīgi. Ieteikumi ir atrodami tehniskajos norādījumos Nr. TR 02102-1 un Nr. TR 02102-2 ( 18 ) vai dokumentā “SOG-IS Agreed Cryptographic Mechanisms ( 19 )”.

5.1.1. Prasības attiecībā uz DSC

Piemēro prasības, kas izklāstītas I pielikuma 3.2.2. iedaļā. Tāpēc ir stingri ieteicams, lai dokumentu parakstītāji izmantotu ECDSA (Elliptic Curve Digital Signature Algorithm) ar NIST-p-256 (kas definēts FIPS PUB 186-4 D papildinājumā). Citas eliptiskās līknes netiek atbalstītas. Tā kā digitālajā Covid sertifikātā trūkst vietas, dalībvalstīm nevajadzētu izmantot RSA-PSS, lai arī tas atļauts kā rezerves algoritms. Ja dalībvalstis RSA-PSS izmanto, izmantotajam modulim jābūt 2048 vai maks. 3072 bitus lielam. Par DSC paraksta šifrēšanas jaucējfunkciju izmanto SHA-2 ar izvades garumu ≥ 256 biti (sk. ISO/IEC 10118-3:2004).

5.1.2. TLS, augšupielādes un CSCA sertifikātu prasības

Digitālajiem sertifikātiem un šifrēšanas parakstiem DCCG kontekstā galvenās prasības attiecībā uz šifrēšanas algoritmiem un atslēgu garumu ir rezumētas turpmāk dotajā tabulā (no 2021. gada).







Paraksta algoritms Atslēgas izmērs Jaucējfunkcija EC-DSA Min. 250 biti SHA-2 ar izvades garumu ≥ 256 biti RSA-PSS (ieteicamais papildinājums) RSA-PKCS#1 v1.5 (mantotais papildinājums) Min. 3000 bitu RSA modulis (N) ar publisko eksponentu e > 2^16 SHA-2 ar izvades garumu ≥ 256 biti DSA Min. 3000 bitu prime p, 250 bitu atslēga q SHA-2 ar izvades garumu ≥ 256 biti

Ieteicamā EC-DSA eliptiskā līkne ir NIST-p-256, pamatojoties uz tās plašo izmantojumu.

5.2. CSCA sertifikāts (NBCSCA)

Turpmāk dotajā tabulā ir norādījumi par NBCSCA sertifikāta veidni, ja dalībvalsts nolemj DCC sistēmai izmantot savu CSCA.

Treknrakstā iespiestie ieraksti ir obligāti (jābūt iekļautiem sertifikātā), slīprakstā iespiestie ieraksti ir ieteikti (vajadzētu iekļaut). Tukšie lauki nozīmē, ka par tiem ieteikumu nav.







Lauks Vērtība Tēma cn=<netukšs un unikāls vispārīgais nosaukums>, o=<Nodrošinātājs>, c=<Dalībvalsts, kas izmanto CSCA> Atslēgas lietojums certificate signing, CRL signing (vismaz) Pamatierobežojumi CA = true, path length constraints = 0

Tēmas nosaukumam jābūt netukšam un unikālam norādītajā dalībvalstī. Valsts kodam (c) jāatbilst dalībvalstij, kas šo CSCA sertifikātu izmantos. Sertifikātam jāsatur unikāls tēmas atslēgas identifikators (SKI), kas atbilst RFC 5280 ( 20 ).

5.3. Dokumenta parakstītāja sertifikāts (DSC)

Turpmāk dotajā tabulā ir norādījumi par DSC. Treknrakstā iespiestie ieraksti ir obligāti (jābūt iekļautiem sertifikātā), slīprakstā iespiestie ieraksti ir ieteikti (vajadzētu iekļaut). Tukšie lauki nozīmē, ka par tiem ieteikumu nav.







Lauks Vērtība Sērijas numurs unikālais sērijas numurs Tēma cn=<netukšs un unikāls kopējais nosaukums>, o=<Nodrošinātājs>, c=<Dalībvalsts, kas izmanto CSCA> Atslēgas lietojums digital signature (vismaz)

DSC jāparaksta ar privāto atslēgu, kas atbilst CSCA sertifikātam, kuru dalībvalsts izmanto.

Jāizmanto šādi paplašinājumi.

— Sertifikātam jāsatur sertificēšanas iestādes atslēgas identifikators ( AKI ), kas atbilst izdevējas CSCA sertifikāta tēmas atslēgas identifikatoram ( SKI ).

— RFC 5280 ( Sertifikātam jāsatur unikāls tēmas atslēgas identifikators (atbilstoši5280 ( 21 )).

Turklāt sertifikātam jāsatur CRL izplatīšanas punkta pagarinājums, kas norāda uz sertifikāta atsaukšanas sarakstu (CRL), ko nodrošina CSCA, kas DSC izdevusi.

DSC var saturēt paplašinātas atslēgas lietošanas paplašinājumu ar nulles vai vairākiem atslēgas lietojuma politikas identifikatoriem, kas ierobežo to, kāda veda HCERT ar šo sertifikātu atļauts verificēt. Ja ir viens vai vairāki identifikatori, verificētāji pārbauda atslēgas lietojumu pret uzglabāto HCERT. Šim nolūkam ir noteiktas šādas paplašinātas atslēgas lietošanas (extendedKeyUsage) vērtības







Lauks Vērtība extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1“testa” izdevējiem extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 “vakcinācijas” izdevējiem extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 “pārslimošanas” izdevējiem

Ja atslēgas lietojuma paplašinājuma nav (proti, paplašinājuma nav vai paplašinājums ir nulle), šo sertifikātu var izdot, lai validētu jebkāda veida HCERT. Citi dokumenti var noteikt attiecīgos papildu paplašinātās atslēgas lietošanas politikas identifikatorus, kas tiek izmantoti ar HCERT validēšanu.

5.4. Augšupielādes sertifikāti (NBUP)

Turpmāk dotajā tabulā ir norādījumi par nacionālās aizmugursistēmas augšupielādes sertifikātu. Treknrakstā iespiestie ieraksti ir obligāti (jābūt iekļautiem sertifikātā), slīprakstā iespiestie ieraksti ir ieteikti (vajadzētu iekļaut). Tukšie lauki nozīmē, ka par tiem ieteikumu nav.







Lauks Vērtība Tēma cn=<netukšs un unikāls kopējais nosaukums>, o=<Nodrošinātājs>, c=<Dalībvalsts, kas izmanto šo augšupielādes sertifikātu> Atslēgas lietojums digital signature (vismaz)

5.5. Nacionālās aizmugursistēmas TLS klienta autentificēšana (NBTLS)

Turpmāk dotajā tabulā ir norādījumi par nacionālās aizmugursistēmas TLS klienta autentificēšanas sertifikātu. Treknrakstā iespiestie ieraksti ir obligāti (jābūt iekļautiem sertifikātā), slīprakstā iespiestie ieraksti ir ieteikti (vajadzētu iekļaut). Tukšie lauki nozīmē, ka par tiem ieteikumu nav.







Lauks Vērtība Tēma cn=<netukšs un unikāls vispārīgais nosaukums>, o=<Nodrošinātājs>, c=<Dalībvalsts NB> Atslēgas lietojums digital signature (vismaz) Paplašināta atslēgas lietošana client authentication (1.3.6.1.5.5.7.3.2)

Sertifikātā var būt iekļauts arī paplašinātais atslēgas lietojums server authentication (1.3.6.1.5.5.7.3.1), bet tas nav obligāts.

5.6. Uzticamības saraksta paraksta sertifikāts (DCCGTA)

Turpmāk dotajā tabulā ir definēts DCCG uzticamības enkura sertifikāts.







Lauks Vērtība Tēma cn = Digital Green Certificate Gateway (1) , o=<Nodrošinātājs>, c=<valsts> Atslēgas lietojums digital signature (vismaz) ( 1 ) Šajā kontekstā ir saglabāts termins “digitālais zaļais sertifikāts” (Digital Green Certificate), nevis “ES digitālais Covid sertifikāts” (EU Digital COVID Certificate), jo tas ir termins, kas tika izmantots sertifikātā ar aparatūras kodu, pirms likumdevējiestādes nolēma lietot jaunu terminu.

5.7. DCCG TLS servera sertifikāti (DCCGTLS)

Turpmāk dotajā tabulā ir definēts DCCG TLS sertifikāts.







Lauks Vērtība Tēma cn=<FQDN vai DCCG IP adrese>, o=<Nodrošinātājs>, c= <valsts> SubjectAltName dNSName: <DCCG DNS nosaukums> vai iPAddress: <DCCG IP adrese> Atslēgas lietojums digital signature (vismaz) Extended Key usage server authentication (1.3.6.1.5.5.7.3.1)

Sertifikātā var būt iekļauts arī paplašinātais atslēgas lietojums client authentication (1.3.6.1.5.5.7.3.2), bet tas nav obligāts.

DCCG TLS sertifikātu izdod publiski uzticama sertificēšanas iestāde (iekļauta visos lielākajās pārlūkprogrammās un operētājsistēmās, ievērojot CAB Forum pamatprasības).

▼M1









V PIELIKUMS

JAVASCRIPT OBJECT NOTATION (JSON) SHĒMA

1. Ievads

Šajā pielikumā ir noteikta datu tehniskā struktūra ES digitālajiem Covid sertifikātiem (EUDCC), kas attēlota kā JSON shēma. Šajā dokumentā sniegti īpaši norādījumi par atsevišķiem datu laukiem.

2. JSON shēmas atrašanās vieta un versijas

Autoritatīvā oficiālā JSON shēma EUDCC vajadzībām ir pieejama tīmekļa vietnē https://github.com/ehn-dcc-development/ehn-dcc-schema. Citas vietas nav autoritatīvas, bet tās var izmantot, lai sagatavotu gaidāmo pārskatīšanu.

Pēc noklusējuma pašreizējā versija, kas noteikta šajā pielikumā un ko atbalsta visas pašlaik sertifikāta ģenerēšanā iesaistītās valstis, ir parādīta norādītajā URL.

Nākamā versija, ko no konkrēta datuma atbalstīs visas valstis, ir parādīta norādītajā URL ar iezīmēto versiju, kas sīkāk aprakstīta lasāmatmiņas datnē.

▼M3

3. Kopīgas struktūras un vispārīgas prasības

ES digitālo Covid sertifikātu neizdod, ja trūkstošas informācijas dēļ nav iespējams pareizi aizpildīt visus datu laukus saskaņā ar šo specifikāciju. Tas neietekmē dalībvalstu pienākumu izdot ES digitālos Covid sertifikātus.

Informāciju visos laukos var sniegt, izmantojot pilnu UNICODE 13.0 rakstzīmju kopu, kas kodēta, izmantojot UTF-8, izņemot, ja tas nav īpaši atļauts tikai vērtību kopām vai šaurākām rakstzīmju kopām.

Kopīgā struktūra ir šāda:

"JSON":{

"ver":<informācija par versiju>,

"nam":{

<personas vārda informācija>

},

"dob":<dzimšanas datums>,

"v" vai "t", vai "r":[

{<vakcīnas devas vai testa, vai atsaukšanas informācija; viens ieraksts>}

]

}

Sīkāka informācija par atsevišķām grupām un laukiem ir sniegta nākamajās iedaļās.

Ja noteikumos paredzēts, ka kāds lauks ir jāizlaiž, tas nozīmē, ka tam jābūt tukšam un ka tajā nedrīkst būt ne lauka nosaukums, ne vērtība.

3.1. Versija

Sniedz informāciju par versiju. Versijas noteikšanai izmanto semantisko versiju (semver: https://semver.org). Ražošanā tā ir viena no oficiāli izlaistajām (pašreizējām vai vecākām oficiāli izlaistām) versijām. Sīkākai informācijai skatīt iedaļu “JSON Schema location”).







Lauka ID Lauka nosaukums Instrukcijas ver Shēmas versija Atbilst EUDCC sagatavošanai izmantotās shēmas versijas identifikatoram. Piemēram: "ver":"1.3.0"

3.2. Personas vārds, uzvārds un dzimšanas datums

Personas vārds ir personas oficiālais pilnais vārds, kas atbilst ceļošanas dokumentos norādītajam vārdam. Struktūras identifikators ir nam. Sniedz tieši 1 (vienas) personas vārdu.







Lauka ID Lauka nosaukums Instrukcijas nam/fn Uzvārds(-i) Turētāja uzvārds(-i). Ja turētājam nav uzvārdu, bet ir vārds, šo lauku izlaiž. Visos pārējos gadījumos sniedz tieši 1 (vienu) lauku, kas nav tukšs, kurā ietverti visi uzvārdi. Vairāku uzvārdu gadījumā tos atdala ar atstarpi. Uzvārdu kombinācijai, kurā ir defises vai līdzīgas rakstzīmes, ir jāpaliek nemainīgai. Piemēram: "fn":"Musterfrau-Gößinger" "fn":"Musterfrau-Gößinger Müller" nam/fnt Standartizēts(-i) uzvārds(-i) Turētāja uzvārds(-i), kas transliterēts(-i), izmantojot to pašu konvenciju, kas izmantota turētāja mašīnlasāmos ceļošanas dokumentos (piemēram, ICAO dokumenta 9303 3. daļas noteikumi). Ja turētājam nav uzvārdu, bet ir vārds, šo lauku izlaiž. Visos pārējos gadījumos sniedz tieši 1 (vienu) lauku, kas nav tukšs, kurā ietvertas tikai rakstzīmes A-Z un <. Maksimālais garums: 80 rakstzīmes (saskaņā ar ICAO 9303 specifikāciju) Piemēram: "fnt":"MUSTERFRAU<GOESSINGER" "fnt":"MUSTERFRAU<GOESSINGER<MUELLER" nam/gn Vārds(-i) Turētāja vārds(-i). Ja turētājam nav vārdu, bet ir uzvārds, šo lauku izlaiž. Visos pārējos gadījumos sniedz tieši 1 (vienu) lauku, kas nav tukšs, kurā ietverti visi vārdi. Vairāku vārdu gadījumā tos atdala ar atstarpi. Piemēram: "gn":"Isolde Erika" nam/gnt Standartizēts(-i) vārds(-i) Turētāja vārds(-i), kas transliterēts(-i), izmantojot to pašu konvenciju, kas izmantota turētāja mašīnlasāmos ceļošanas dokumentos (piemēram, ICAO dokumenta 9303 3. daļas noteikumi). Ja turētājam nav vārdu, bet ir uzvārds, šo lauku izlaiž. Visos pārējos gadījumos sniedz tieši 1 (vienu) lauku, kas nav tukšs, kurā ietvertas tikai rakstzīmes A-Z un <. Maksimālais garums: 80 rakstzīmes. Piemēram: "gnt": "ISOLDE<ERIKA" dob Dzimšanas datums DCC turētāja dzimšanas datums. Pilnīgs vai daļējs datums, nenorādot dzimšanas laiku, vērtību intervālā no 1900-01-01 līdz 2099-12-31. Sniedz tieši 1 (vienu) lauku, kas nav tukšs, ja ir zināms pilnīgs vai daļējs dzimšanas datums. Ja dzimšanas datums nav zināms pat daļēji, lauku iestata uz tukšu virkni “”. Tam būtu jāatbilst informācijai, kas sniegta ceļošanas dokumentos. Izmanto vienu no šādiem ISO 8601 formātiem, ja ir pieejama informācija par dzimšanas datumu. Citas iespējas netiek atbalstītas. YYYY-MM-DD YYYY-MM YYYY (Verificētāja lietotne var parādīt trūkstošās dzimšanas datuma daļas, izmantojot XX konvenciju, kas izmantota mašīnlasāmos ceļošanas dokumentos, piemēram, 1990-XX-XX.). Piemēram: "dob":"1979-04-14" "dob":"1901-08" "dob":"1939" "dob":""

3.3. Grupas konkrēta veida sertifikāta informācijai

JSON shēma atbalsta ierakstu trīs grupas, kas ietver konkrēta veida sertifikāta informāciju. Katrā EUDCC ir tieši 1 (viena) grupa. Tukšas grupas nav atļautas.







Grupas identifikators Grupas nosaukums Ieraksti v Vakcinācijas grupa Ja tāda ir, tā ietver tieši 1 (vienu) ierakstu, kurā precīzi apraksta 1 (vienu) vakcīnas devu (viena deva). t Testa grupa Ja tāda ir, tā ietver tieši 1 (vienu) ierakstu, kurā precīzi apraksta 1 (vienu) testa rezultātu. r Pārslimošanas grupa Ja tāda ir, tā ietver tieši 1 (vienu) ierakstu, kurā apraksta 1 (vienu) paziņojumu par pārslimošanu.

▼M1

4. Konkrēta veida sertifikāta informācija

4.1. Vakcinācijas sertifikāts

Ja tāda ir, vakcinācijas grupa ietver tieši 1 (vienu) ierakstu, kurā precīzi apraksta vienu vakcināciju (viena deva). Visi vakcinācijas grupas elementi ir obligāti, tukšas vērtības netiek atbalstītas.







Lauka ID Lauka nosaukums Instrukcijas v/tg Mērķa slimība vai ierosinātājs: Covid-19 (SARS-CoV2 vai viens no tā variantiem) Kodēta vērtība no vērtību kopas disease-agent-targeted.json. Šai vērtību kopai ir viens ieraksts 840539006, kas ir kods Covid-19 no SNOMED CT (GPS). Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "tg":"840539006" v/vp Covid-19 vakcīna vai profilakse Izmantotās vakcīnas vai profilakses veids. Kodēta vērtība no vērtību kopas vaccine-prophylaxis.json. Vērtību kopa ir sadalīta no EUDCC vārtejas. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "vp":"1119349007"(SARS-CoV-2 mRNS vakcīna) v/mp Covid-19 vakcīnas produkts Medicīnisks produkts, ko izmanto šai specifiskajai vakcinācijas devai. Kodēta vērtība no vērtību kopas vaccine-medicinal-product.json. Vērtību kopa ir sadalīta no EUDCC vārtejas. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "mp":"EU/1/20/1528" (Comirnaty) v/ma Covid-19 vakcīnas tirdzniecības atļaujas turētājs vai ražotājs Tirdzniecības atļaujas turētājs vai ražotājs, ja nav tirdzniecības atļaujas turētāja. Kodēta vērtība no vērtību kopas vaccine-mah-manf.json. Vērtību kopa ir sadalīta no EUDCC vārtejas. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "ma":"ORG-100030215"(Biontech Manufacturing GmbH) v/dn Devas kārtas numurs vakcinācijas kursā Šīs vakcinācijas laikā ievadītās devas kārtas numurs (pozitīvs vesels skaitlis). 1 pirmajai devai, 2 otrajai devai utt. Ir paredzēti konkrētāki noteikumi II pielikuma 5. iedaļā. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemēri: "dn":"1"(pirmā deva) "dn":"2"(otrā deva) "dn":"3"(trešā deva) v/sd Kopējais devu skaits vakcinācijas kursā Kopējais devu skaits (pozitīvs vesels skaitlis) vakcinācijas kursā. Konkrētāki noteikumi ir sniegti II pielikuma 5. iedaļā. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemēri: "sd":"1"(1 devas pirmreizējās vakcinācijas kursa gadījumā) "sd":"2"(2 devu pirmreizējās vakcinācijas kursa gadījumā vai papildu deva pēc 1 devas pirmreizējās vakcinācijas kursa) "sd":"3"(piemēram, papildu devu gadījumā pēc divu devu pirmreizējās vakcinācijas kursa) v/dt Vakcinācijas datums Datums, kurā tika saņemta aprakstītā deva GGGG-MM-DD formātā (pilns datums bez laika) Citi formāti netiek atbalstīti. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "dt":"28.03.2021" v/co Dalībvalsts vai trešā valsts, kurā saņemta vakcīna Valsts, kas izteikta kā ISO 3166 divburtu kods (IETEICAMS) vai atsauce uz starptautisku organizāciju, kas atbild par vakcinācijas pasākumu (piemēram, UNHCR vai PVO). Kodēta vērtība no vērtību kopas country-2-codes.json. Vērtību kopa ir sadalīta no EUDCC vārtejas. Sniedz tieši 1 (vienu) lauku. Piemērs: "co":"CZ" "co":"UNHCR" v/is Sertifikāta izdevējs Sertifikātu izdevušās organizācijas nosaukums. Identifikatori ir atļauti kā daļa no nosaukuma, bet nav ieteicams tos izmantot atsevišķi bez nosaukuma kā tekstu. Maks. 80 UTF-8 rakstzīmes. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "is":"Ministry of Health of the Czech Republic" "is":"Vaccination Centre South District 3" v/ci Unikālais sertifikāta identifikators. Unikālais sertifikāta identifikators (UVCI), kā noteikts https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf Kontrolsummas iekļaušana nav obligāta. Prefiksu “URN:UVCI:” var pievienot. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemēri: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2. Testa sertifikāts

Testa grupa, ja tāda ir, ietver tieši 1 (vienu) ierakstu, kurā precīzi apraksta vienu testa rezultātu.







Lauka ID Lauka nosaukums Instrukcijas t/tg Mērķa slimība vai ierosinātājs: Covid-19 (SARS-CoV vai viens no tā variantiem) Kodēta vērtība no vērtību kopas disease-agent-targeted.json. Šai vērtību kopai ir viens ieraksts 840539006, kas ir kods Covid-19 no SNOMED CT (GPS). Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "tg":"840539006" t/tt Testa veids Izmantotā testa veids, pamatojoties uz materiālu, uz kuru attiecas tests. Kodēta vērtība no vērtību kopas test-type.json. (pamatojoties uz LOINC). Vērtības ārpus vērtību kopas nav atļautas. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "tt":"LP6464-4"(Nukleīnskābes amplifikācijas tests ar zondes noteikšanu) "tt":"LP217198-3"(ātrā imūnanalīze) t/nm Testa nosaukums (tikai nukleīnskābes amplifikācijas testiem) Izmantotā nukleīnskābes amplifikācijas testa (NAAT) nosaukums. Nosaukumā jāiekļauj testa ražotāja nosaukums un testa komercnosaukums, ko atdala ar komatu. NAAT: šis lauks nav obligāts. RAT: šo lauku neizmanto, jo šī testa nosaukumu netieši norāda ar testa ierīces identifikatoru (t/ma). Ja to norāda, minētais lauks ir aizpildīts. Piemērs: "nm":"ELITechGroup, SARS-CoV-2 ELITe MGB® Kit" t/ma Testa ierīces identifikators (tikai ātrajiem antigēna testiem) Ātrā antigēna testa (RAT) ierīces identifikators no JRC datubāzes. Vērtību kopa (HSC kopējais saraksts): — Visi ātrie antigēna testi HSC kopējā sarakstā (cilvēkiem salasāmi). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (mašīnlasāmas, lauka id_device vērtības, kas iekļautas vērtību kopas sarakstā). ES/EEZ valstīs emitenti izdod sertifikātus tikai par testiem, kuri pieder pašreiz spēkā esošajai vērtību kopai. Minēto vērtību kopu atjaunina ik pēc 24 stundām. Vērtības ārpus noteiktās vērtību kopas var izmantot trešo valstu izdotajos sertifikātos, tomēr identifikatori joprojām ir no JRC datubāzes. Nav atļauts izmantot citus identifikatorus, piemēram, tos, ko tieši nodrošina testu ražotāji. Verificētāja lietotnes konstatē vērtības, kuras nepieder atjauninātajai vērtību kopai, un uzrāda sertifikātus, kuri tās uzrāda kā nederīgas. Ja identifikators tiek izņemts no vērtību kopas, sertifikātus, kuri ietver šādu identifikatoru, var pieņemt ne ilgāk kā 72 stundas pēc izņemšanas. Vērtību kopa ir sadalīta no EUDCC vārtejas. RAT: sniedz tieši 1 (vienu) lauku, kas nav tukšs. NAAT: šo lauku neizmanto, pat ja JRC datubāzē ir pieejams NAA testa identifikators. Piemērs: "ma":"344"(SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc Testa parauga ņemšanas datums un laiks Testa parauga ņemšanas datums un laiks. Laiks ietver informāciju par laika zonu. Vērtība nav laiks, kad iegūts testa rezultāts. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Izmanto vienu no šādiem ISO 8601 formātiem. Citas iespējas netiek atbalstītas. GGGG-MM-DDThh:mm:ssZ GGGG-MM-DDThh:mm:ss[+-]hh GGGG-MM-DDThh:mm:ss[+-]hhmm GGGG-MM-DDThh:mm:ss[+-]hh:mm Piemēri: "sc":"2021-08-20T10:03:12Z"(koordinētais universālais laiks) "sc":"2021-08-20T12:03:12+02"(Centrāleiropas laiks) "sc":"2021-08-20T12:03:12+0200"(Centrāleiropas laiks) "sc":"2021-08-20T12:03:12+02:00"(Centrāleiropas laiks) t/tr Testa rezultāts Tests rezultāts. Kodēta vērtība no vērtību kopas test-type.json. (pamatojoties uz SNOMED CT, GPS). Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "tr":"260415000"(Nav konstatēts) t/tc Testēšanas centrs vai struktūra Personas vārds, kura veica testu. Identifikatori ir atļauti kā daļa no nosaukuma, bet nav ieteicams tos izmantot atsevišķi bez nosaukuma kā tekstu. Maks. 80 UTF-8 rakstzīmes. Visas papildu rakstzīmes būtu jāsaīsina. Nosaukums nav paredzēts automātiskai verifikācijai. NAAT testiem: sniedz tieši 1 (vienu) lauku, kas nav tukšs. RAT testiem: šis lauks nav obligāts. Ja to sniedz, tas nav tukšs. Piemērs: "tc":"Test centre west region 245" t/co Dalībvalsts vai trešā valsts, kurā veikts tests Valsts, kas izteikta kā ISO 3166 divburtu kods (IETEICAMS) vai atsauce uz starptautisku organizāciju, kas atbild par testa veikšanu (piemēram, UNHCR vai PVO). Tā ir kodēta vērtība no vērtību kopas country-2-codes.json. Vērtību kopa ir sadalīta no EUDCC vārtejas. Sniedz tieši 1 (vienu) lauku. Piemēri: "co":"CZ" "co":"UNHCR" t/is Sertifikāta izdevējs Sertifikātu izdevušās organizācijas nosaukums. Identifikatori ir atļauti kā daļa no nosaukuma, bet nav ieteicams tos izmantot atsevišķi bez nosaukuma kā tekstu. Maks. 80 UTF-8 rakstzīmes. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemēri: “is”:"Ministry of Health of the Czech Republic" "is":"North-West region health authority" t/ci Unikālais sertifikāta identifikators. Unikālais sertifikāta identifikators (UVCI), kā noteikts vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Kontrolsummas iekļaušana nav obligāta. Prefiksu “URN:UVCI:” var pievienot. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemēri: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.3. Pārslimošanas sertifikāts

Pārslimošanas grupa, ja tāda ir, ietver tieši 1 (vienu) ierakstu, kurā precīzi apraksta vienu paziņojumu par pārslimošanu. Visi pārslimošanas grupas elementi ir obligāti, tukšas vērtības netiek atbalstītas.







Lauka ID Lauka nosaukums Instrukcijas r/tg Slimība vai ierosinātājs, ko sertifikāta turētājs ir pārslimojis: Covid-19 (SARS-CoV-2 vai viens no tā variantiem) Kodēta vērtība no vērtību kopas disease-agent-targeted.json. Šai vērtību kopai ir viens ieraksts 840539006, kas ir kods Covid-19 no SNOMED CT (GPS). Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "tg":"840539006" r/fr Sertifikāta turētāja pirmā pozitīvā NAAT testa rezultāta datums Datums, kad tika ņemts paraugs NAAT testam ar pozitīvu rezultātu GGGG-MM-DD formātā (pilns datums bez laika). Citi formāti netiek atbalstīti. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "fr":"18.05.2021" r/co Dalībvalsts vai trešā valsts, kurā veikts tests Valsts, kas izteikta kā ISO3166 divburtu kods (IETEICAMS) vai atsauce uz starptautisku organizāciju, kas atbild par testa veikšanu (piemēram, UNHCR vai PVO). Kodēta vērtība no vērtību kopas country-2-codes.json. Vērtību kopa ir sadalīta no EUDCC vārtejas. Sniedz tieši 1 (vienu) lauku. Piemēri: "co":"CZ" "co":"UNHCR" r/is Sertifikāta izdevējs Sertifikātu izdevušās organizācijas nosaukums. Identifikatori ir atļauti kā daļa no nosaukuma, bet nav ieteicams tos izmantot atsevišķi bez nosaukuma kā tekstu. Maks. 80 UTF-8 rakstzīmes. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "is":"Ministry of Health of the Czech Republic" "is":"Central University Hospital" r/df Sertifikāts derīgs no Pirmais datums, kurā sertifikāts uzskatāms par derīgu. Minētais datums nedrīkst būt agrāks par datumu, kas aprēķināts kā r/fr + 11 dienas. Datumu sniedz GGGG-MM-DD formātā (pilns datums bez laika). Citi formāti netiek atbalstīti. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "df":"29.05.2021" r/du Sertifikāts derīgs līdz Pēdējais datums, kurā sertifikāts uzskatāms par derīgu un kuru piešķīris sertifikāta izdevējs. Minētais datums nedrīkst būt pēc datuma, kas aprēķināts kā r/fr + 180 dienas. Datumu sniedz GGGG-MM-DD formātā (pilns datums bez laika). Citi formāti netiek atbalstīti. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemērs: "du":"14.11.2021" r/ci Unikālais sertifikāta identifikators. Unikālais sertifikāta identifikators (UVCI), kā noteikts vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Kontrolsummas iekļaušana nav obligāta. Prefiksu "URN:UVCI:" var pievienot. Sniedz tieši 1 (vienu) lauku, kas nav tukšs. Piemēri: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

▼M3









VI PIELIKUMS

DALĪBVALSTU PIENĀKUMI KĀ ES DIGITĀLĀ COVID SERTIFIKĀTA VĀRTEJAS KOPĪGIEM PĀRZIŅIEM ATTIECĪBĀ UZ ES DCC ATSAUKŠANAS SARAKSTU APMAIŅU

1. IEDAĻA

1. apakšiedaļa

Pienākumu sadale

1. Kopīgie pārziņi uzticamības satvara vārtejā apstrādā persondatus atbilstoši tehniskajām specifikācijām, kas noteiktas I pielikumā.

2. Dalībvalstu izdevējiestādes joprojām ir vienīgais pārzinis par atsaukšanas informācijas vākšanu, izmantošanu, izpaušanu un jebkādu citu apstrādi ārpus vārtejas, tai skaitā par procedūru līdz sertifikāta atsaukšanai.

3. Katrs pārzinis ir atbildīgs par uzticamības satvara vārtejā esošo persondatu apstrādi atbilstīgi Vispārīgās datu aizsardzības regulas 5., 24. un 26. pantam.

4. Katrs pārzinis izveido kontaktpunktu ar funkcionālo pastkastīti, kas tiks izmantota saziņai starp kopīgajiem pārziņiem pašiem un starp kopīgajiem pārziņiem un apstrādātāju.

5. Darba grupai, ko izveidojusi Regulas (ES) 2021/953 14. pantā minētā komiteja, ir pilnvaras lemt par visām problēmām, kas rodas sakarā ar atsaukšanas sarakstu apmaiņu un ar to saistīto persondatu apstrādes kopīgo pārziņu, un sekmēt saskaņotu norādījumu sniegšanu Komisijai kā apstrādātājam. Kopīgo pārziņu lēmumu pieņemšanas procesu reglamentē minētā darba grupa un reglaments, kas tai jāpieņem. Pamatnoteikums ir tāds, ka, ja kāds no kopīgajiem pārziņiem nepiedalās šīs darba grupas sanāksmē, par kuru ir rakstveidā paziņots vismaz septiņas (7) dienas pirms tās sasaukšanas, tas nozīmē automātisku piekrišanu minētās darba grupas sanāksmes rezultātiem. Jebkurš no kopīgajiem pārziņiem var sasaukt šīs darba grupas sanāksmi.

6. Norādījumus apstrādātājam nosūta jebkurš kopīgo pārziņu kontaktpunkts, vienojoties ar pārējiem kopīgajiem pārziņiem atbilstīgi darba grupas lēmumu pieņemšanas procesam, kas izklāstīts 5. punktā. Kopīgais pārzinis, kurš sniedz norādījumus, apstrādātājam tos sniedz rakstveidā un par tiem informē visus pārējos kopīgos pārziņus. Ja lēmums par kādu jautājumu jāpieņem īsā laikā un šajā laikā nevar sasaukt darba grupas sanāksmi, kā minēts 5. punktā, var sniegt norādījumus, bet darba grupa tos var atsaukt. Šādi norādījumi jādod rakstveidā, un visi pārējie kopīgie pārziņi par to jāinformē norādījumu došanas brīdī.

7. Saskaņā ar 5. punktu izveidotā darba grupa neliedz kopīgajiem pārziņiem izmantot savu individuālo kompetenci informēt savu kompetento uzraudzības iestādi saskaņā ar Vispārīgās datu aizsardzības regulas 33. un 24. pantu. Šādam paziņojumam nav vajadzīga pārējo kopīgo pārziņu piekrišana.

8. Uzticamības satvara vārtejas tvērumā persondatiem, ar kuriem notikusi apmaiņa, drīkst piekļūt tikai personas, kuras pilnvarojusi izraudzītā valsts iestāde vai oficiālās struktūras.

9. Katra izdevējiestāde reģistrē apstrādes darbības, par kurām tā ir atbildīga. Kopīgo pārziņu veiktās darbības var norādīt reģistrā.

2. apakšiedaļa

Pienākumi un lomas attiecībā uz datu subjektu pieprasījumu izskatīšanu un viņu informēšanu

1. Katrs pārzinis, pildot izdevējiestādes pienākumus, fiziskām personām, kuru sertifikātu(-us) tas ir atsaucis (“datu subjekti”), sniedz informāciju par minēto atsaukšanu un viņu persondatu apstrādi ES digitālā Covid sertifikāta vārtejā, kas notikusi saistībā ar atsaukšanas sarakstu apmaiņu, saskaņā ar Vispārīgās datu aizsardzības regulas 14. pantu, izņemot, ja tas nav iespējams vai būtu saistīts ar nesamērīgām pūlēm.

2. Katrs pārzinis rīkojas kā kontaktpunkts fiziskām personām, kuru sertifikātu(-us) tas ir atsaucis, un apstrādā pieprasījumus, ko datu subjekti vai to pārstāvji iesnieguši, izmantojot savas tiesības atbilstīgi Vispārīgai datu aizsardzības regulai. Ja kopīgais pārzinis no datu subjekta saņem pieprasījumu, kas ir saistīts ar sertifikātu, ko izdevis cits kopīgais pārzinis, datu subjekts ir jāinformē par atbildīgā kopīgā pārziņa identitāti un kontaktinformāciju. Pēc pieprasījuma saņemšanas no cita kopīgā pārziņa tie cits citam palīdz izskatīt datu subjektu pieprasījumus un cits citam atbild bez liekas kavēšanās un vēlākais 1 mēneša laikā pēc palīdzības pieprasījuma saņemšanas. Ja pieprasījums ir saistīts ar trešās valsts iesniegtiem datiem, pārzinis, kas saņem pieprasījumu, to izskata un informē datu subjektu par trešās valsts izdevējiestādes identitāti un kontaktinformāciju.

3. Katrs pārzinis datu subjektiem dara pieejamu šā pielikuma saturu, arī 1. un 2. punktā noteikto.

2. IEDAĻA

Rīcība drošības incidentu, tai skaitā persondatu aizsardzības pārkāpumu, gadījumā

1. Kopīgie pārziņi cits citam palīdz identificēt un risināt drošības incidentus, arī persondatu aizsardzības pārkāpumus, kas saistīti ar datu apstrādi ES digitālā Covid sertifikāta vārtejā.

2. Jo īpaši, kopīgie pārziņi cits citam paziņo:

a) jebkuru potenciālu vai faktisku risku uzticamības satvara vārtejā esošo apstrādājamo persondatu pieejamībai, konfidencialitātei un/vai integritātei;

b) jebkuru persondatu aizsardzības pārkāpumu, persondatu aizsardzības pārkāpuma iespējamās sekas un fizisku personu tiesību un brīvību riska novērtējumu, un jebkurus pasākumus, kas veikti, lai risinātu persondatu aizsardzības pārkāpumu un mazinātu risku fizisku personu tiesībām un brīvībām;

c) jebkuru apstrādes darbības tehnisko un/vai organizatorisko aizsardzības pasākumu pārkāpumu uzticamības satvara vārtejā.

3. Jebkurus persondatu aizsardzības pārkāpumus saistībā ar apstrādes darbību uzticamības satvara vārtejā kopīgie pārziņi saskaņā ar Vispārīgās datu aizsardzības regulas 33. un 34. pantu vai pēc Komisijas paziņojuma paziņo Komisijai, kompetentajām uzraudzības iestādēm un vajadzības gadījumā datu subjektiem.

4. Katra izdevējiestāde īsteno pienācīgus tehniskus un organizatoriskus pasākumus, kuru nolūks ir:

a) nodrošināt un aizsargāt kopīgi apstrādāto persondatu pieejamību, integritāti un konfidencialitāti;

b) aizsargāt pret jebkādu neatļautu vai nelikumīgu tās rīcībā esošo persondatu apstrādi, nozaudēšanu, izmantošanu, izpaušanu vai iegūšanu vai piekļuvi tiem;

c) nodrošināt, ka piekļuve persondatiem netiek izpausta vai atļauta nevienam citam, izņemot saņēmējus vai apstrādātājus.

3. IEDAĻA

Novērtējums par ietekmi uz datu aizsardzību

1. Ja pārzinim, lai izpildītu Regulas (ES) 2016/679 35. un 36. pantā norādītos pienākumus, vajadzīga informācija no cita pārziņa, tas sūta īpašu pieprasījumu uz 1. iedaļas 1. apakšiedaļas 4. punktā minēto funkcionālo pastkasti. Attiecīgi šis cits pārzinis dara visu iespējamo, lai šo informāciju sniegtu.









VII PIELIKUMS

KOMISIJAS PIENĀKUMI KĀ ES DIGITĀLĀ COVID SERTIFIKĀTA VĀRTEJAS DATU APSTRĀDĀTĀJAI ATTIECĪBĀ UZ ES DCC ATSAUKŠANAS SARAKSTU APMAIŅAS ATBALSTĪŠANU

Komisija:

1. Dalībvalstu vārdā izveido un nodrošina drošu un uzticamu sakaru infrastruktūru, kas atbalsta digitālā Covid sertifikāta vārtejā iesniegto atsaukšanas sarakstu apmaiņu.

2. Lai izpildītu dalībvalstu uzticamības satvara vārtejas datu apstrādātāja pienākumus, Komisija kā apakšapstrādātājus var piesaistīt trešās personas; Komisija informē pārziņus par visām plānotajām izmaiņām attiecībā uz citu apakšapstrādātāju pievienošanu vai aizstāšanu, tādējādi dodot pārziņiem iespēju kopīgi iebilst pret šādām izmaiņām. Komisija gādā, lai šādiem apakšapstrādātājiem būtu tādi paši datu aizsardzības pienākumi, kādi izklāstīti šajā lēmumā.

3. Persondatus apstrādā, tikai pamatojoties uz pārziņu dotiem dokumentētiem norādījumiem, ja vien tas nav prasīts Savienības vai dalībvalstu tiesību aktos; šādā gadījumā Komisija pirms datu apstrādes darbības par attiecīgo juridisko prasību informē kopīgos pārziņus, ja vien šādas informācijas iesniegšana ar attiecīgo tiesību aktu nav aizliegta, ievērojot svarīgas sabiedrības intereses. Apstrādes ietvaros Komisija: a) autentificē valstu aizmugursistēmas serverus, pamatojoties uz valstu aizmugursistēmas serveru sertifikātiem; b) saņem Lēmuma 5.a panta 3. punktā minētos un valstu aizmugursistēmas serveru augšupielādētos datus, nodrošinot lietojumprogrammas saskarni, ar kuras palīdzību valstu aizmugursistēmas serveri var augšupielādēt attiecīgos datus; c) glabā datus ES digitālā Covid sertifikāta vārtejā; d) dod iespēju datus lejupielādēt valstu aizmugursistēmas serveros; e) dzēš datus derīguma termiņā vai pēc tā pārziņa norādījumiem, kas tos iesniedzis; f) pēc pakalpojuma sniegšanas beigām dzēš visus atlikušos datus, ja vien Savienības vai dalībvalsts tiesību akti nepieprasa glabāt persondatus.

4. Veic visus mūsdienīgos organizatoriskos, fiziskos un loģiskos drošības pasākumus, kādi vajadzīgi, lai uzturētu ES digitālā Covid sertifikāta vārteju. Šajā nolūkā Komisija: a) nozīmē struktūru, kas ir atbildīga par drošības pārvaldību ES digitālā Covid sertifikāta vārtejas līmenī, paziņo kopīgajiem pārziņiem tās kontaktinformāciju un nodrošina tās pieejamību, lai tā varētu reaģēt uz drošības apdraudējumiem; b) uzņemas atbildību par ES digitālā Covid sertifikāta vārtejas drošību, tai skaitā regulāri veic drošības pasākumu testus, izvērtējumus un novērtējumus; c) nodrošina, ka visas personas, kam piešķirta piekļuve E