02021D1073 — LV — 18.11.2021 — 001.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ā.

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.

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

5.2. Papildu devas

Ja persona saņem devas pēc pirmreizējās vakcinācijas kursa, šādas papildu devas (X) atspoguļo attiecīgajos sertifikātos, palielinot ievadīto devu skaitu (N) un kopējo devu skaitu (C) (rezultātā (N+X)/(C+X)). Piemēram,

— 2/2 norādītu, ka ir ievadīta papildu deva pēc pirmreizējās vienas devas vakcinācijas kursa vai ir ievadīta papildu deva pēc pabeigta pirmreizējā kursa, 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.

— 3/3 norādītu to, ka ir ievadīta papildu deva pēc pirmreizējās 2 devu vakcinācijas kursa.

Tādējādi papildu devas, kas ievadītas pēc pabeigta pirmreizējās vakcinācijas kursa, norāda ar (N+X)/(C+X) = 1.

Vakcinācijas sertifikātus, kuri izdoti līdz 2021. gada 31. decembrim, turpinās pieņemt pat tad, ja šādu sertifikātu numuri ir kodēti saskaņā ar atšķirīgiem noteikumiem attiecībā uz vakcinācijas kursu vai kopējo devu skaitu vakcinācijas kursā. Lai to nodrošinātu, var veikt tehniskus pasākumus.

Piemērojot tiesisko regulējumu, kas izveidots ar Regulu (ES) 2021/953, dalībvalstis var veikt pasākumus, lai risinātu situāciju attiecībā uz neaizsargātām grupām, kas var saņemt papildu devas prioritārā kārtā. Piemēram, ja dalībvalsts izlemj ievadī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, kuros norādīta šādas papildu devas ievadīšana, tikai pēc pieprasījuma, nevis automātiski. Ja šādi pasākumi tiek veikti, dalībvalstis par to informē attiecīgās personas, kā arī par to, ka tās var turpināt izmantot to sertifikātu, kas saņemts pēc standarta pirmreizējās vakcinācijas kursa pabeigšanas.

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 ( 12 ) 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 ( 13 );

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) ( 14 ) 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 ( 15 ) 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 ( 16 ) vai dokumentā “SOG-IS Agreed Cryptographic Mechanisms ( 17 )”.

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

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

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

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-19 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ārds>

},

"dob":<dzimšanas datums>,

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

{<informācija par vakcināciju, testu vai pārslimošanu, viens ieraksts>}

]

}

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

3.1. Versija

Sniedz informāciju par versiju. Versija ir šāda semantiskā versija (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 JSON Schema location. iedaļu).







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

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

Personas vārds ir personas oficiālais pilns 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). 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. Vārdu kombinācijai, kas ietver defises vai līdzīgas rakstzīmes, ir jāpaliek nemainīgai. Piemēri: "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). 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 ICAO9303 specifikāciju) Piemēri: "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, š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ērs: "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 dokumenta9303 3. daļas noteikumi). Ja turētājam nav vārdu, š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ērs: "gnt":"ISOLDE<ERIKA" dob Dzimšanas datums EUDCC turētāja dzimšanas datums. Pilnīgs vai daļējs datums, nenorādot dzimšanas laiku, virknē 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. GGGG-MM-DD GGGG–MM GGGG (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ēri: "dob":"1979-04-14" "dob":"1901-08" "dob":"1939" "dob":""

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

JSON shēma atbalsta trīs ierakstu 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) vakcinācijas 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.

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"