02021D1073 — LT — 15.09.2022 — 004.001

---

Šis tekstas yra skirtas tik informacijai ir teisinės galios neturi. Europos Sąjungos institucijos nėra teisiškai atsakingos už jo turinį. Autentiškos atitinkamų teisės aktų, įskaitant jų preambules, versijos skelbiamos Europos Sąjungos oficialiajame leidinyje ir pateikiamos svetainėje „EUR-Lex“. Oficialūs tekstai tiesiogiai prieinami naudojantis šiame dokumente pateikiamomis nuorodomis

►B

KOMISIJOS ĮGYVENDINIMO SPRENDIMAS (ES) 2021/1073 2021 m. birželio 28 d. kuriuo nustatomos ES skaitmeninio COVID pažymėjimo patikimumo užtikrinimo sistemos, nustatytos Europos Parlamento ir Tarybos reglamentu (ES) 2021/953, techninės specifikacijos ir įgyvendinimo taisyklės (Tekstas svarbus EEE) (OL L 230 2021.6.30, p. 32)

Iš dalies keičiamas:

		Oficialusis leidinys
		Nr.	puslapis	data
►M1	KOMISIJOS ĮGYVENDINIMO SPRENDIMAS (ES) 2021/2014 2021 m. lapkričio 17 d.	L 410	180	18.11.2021
►M2	KOMISIJOS ĮGYVENDINIMO SPRENDIMAS (ES) 2021/2301 2021 m. gruodžio 21 d.	L 458	536	22.12.2021
►M3	KOMISIJOS ĮGYVENDINIMO SPRENDIMAS (ES) 2022/483 2022 m. kovo 21 d.	L 98	84	25.3.2022
►M4	KOMISIJOS ĮGYVENDINIMO SPRENDIMAS (ES) 2022/1516 2022 m. rugsėjo 8 d.	L 235	61	12.9.2022

---

▼B

KOMISIJOS ĮGYVENDINIMO SPRENDIMAS (ES) 2021/1073

2021 m. birželio 28 d.

kuriuo nustatomos ES skaitmeninio COVID pažymėjimo patikimumo užtikrinimo sistemos, nustatytos Europos Parlamento ir Tarybos reglamentu (ES) 2021/953, techninės specifikacijos ir įgyvendinimo taisyklės

(Tekstas svarbus EEE)

1 straipsnis

I priede išdėstomos techninės ES skaitmeninio COVID pažymėjimo specifikacijos, kuriomis nustatoma bendroji duomenų struktūra, kodavimo mechanizmai ir perduodamų duomenų kodavimo kompiuterio skaitomu optiniu formatu mechanizmas.

2 straipsnis

Šio sprendimo II priede nustatomos Reglamento (ES) 2021/953 3 straipsnio 1 dalyje nurodytų pažymėjimo pildymo taisyklės.

3 straipsnis

III priede išdėstomi reikalavimai, kuriais nustatoma bendra unikalaus pažymėjimo identifikatoriaus struktūra.

▼M1

4 straipsnis

IV priede nustatomos ES skaitmeninio COVID pažymėjimo tinklų sietuve naudojamų viešųjų raktų sertifikatų valdymo taisyklės, padedančios įgyvendinti patikimumo užtikrinimo sistemos sąveikumo aspektus.

▼M1

5 straipsnis

Šio sprendimo V priede nustatoma bendra suderinta duomenų, kurie turi būti įtraukiami į Reglamento (ES) 2021/953 3 straipsnio 1 dalyje nurodytus pažymėjimus, struktūra, apibrėžiama naudojant JSON formato schemą.

▼M3

5a straipsnis

Keitimasis panaikintų pažymėjimų sąrašais

5b straipsnis

Trečiųjų valstybių pateikiami panaikintų pažymėjimų sąrašai

COVID-19 pažymėjimus išduodančios trečiosios valstybės, dėl kurių Komisija priėmė įgyvendinimo aktą pagal Reglamento (ES) 2021/953 3 straipsnio 10 dalį arba 8 straipsnio 2 dalį, gali pateikti panaikintų COVID-19 pažymėjimų, kuriems taikomas toks įgyvendinimo aktas, sąrašus, kad Komisija juos bendrų duomenų valdytojų vardu tvarkytų 5a straipsnyje nurodytame tinklų sietuve pagal I priede išdėstytas technines specifikacijas.

5c straipsnis

Asmens duomenų tvarkymo centriniame ES skaitmeninio COVID pažymėjimo tinklų sietuve valdymas

▼M1

6 straipsnis

Šis sprendimas įsigalioja jo paskelbimo Europos Sąjungos oficialiajame leidinyje dieną.

▼B

Šis sprendimas įsigalioja jo paskelbimo Europos Sąjungos oficialiajame leidinyje dieną.

---

I PRIEDAS

FORMATAS IR PATIKIMUMO VALDYMAS

Bendroji duomenų struktūra, kodavimo mechanizmai ir perduodamų duomenų kodavimo kompiuterio skaitomu optiniu formatu (toliau – QR) mechanizmas

1.    Įžanga

Šiame priede išdėstytose techninėse specifikacijose pateikiama ES skaitmeninio COVID pažymėjimo (toliau – SCP) bendroji duomenų struktūra ir kodavimo mechanizmai. Jose taip pat apibrėžtas perduodamų duomenų kodavimo kompiuterio skaitomu optiniu formatu (QR kodu, kuris gali būti rodomas mobiliojo įrenginio ekrane arba spausdinamas popieriuje) mechanizmas. Šiose specifikacijose nurodyti elektroninio sveikatos pažymėjimo rinkmenų formatai yra bendri, tačiau šiomis aplinkybėmis naudojami ES skaitmeniniam COVID pažymėjimo (SCP) duomenims perduoti.

2.    Terminai

Šiame priede išdavėjai yra organizacijos, naudojančios šias specifikacijas sveikatos pažymėjimams išduoti, o tikrintojai yra organizacijos, priimančios sveikatos pažymėjimus kaip sveikatos būklės įrodymą. Dalyviai yra išdavėjai ir tikrintojai. Kai kuriuos šiame priede nurodytus aspektus, pavyzdžiui, vardų erdvių valdymą ir kriptografinių raktų paskirstymą, dalyviai turi derinti tarpusavyje. Daroma prielaida, kad šias užduotis atlieka šalis, toliau vadinama sekretoriatu.

3.    Elektroninio sveikatos pažymėjimo rinkmenos formatas

Elektroninio sveikatos pažymėjimo rinkmenos formatas (toliau – HCERT) sukurtas, kad būtų galima naudoti vienodą ir standartizuotą priemonę, skirtą sveikatos pažymėjimams iš įvairių juos išdavusių subjektų (toliau – išdavėjų) talpinti. Šių specifikacijų tikslas – suderinti tokių sveikatos pažymėjimų atvaizdavimą, kodavimą ir pasirašymą, siekiant palengvinti sąveikumą.

Kad būtų galima nuskaityti ir suprasti bet kurio išdavėjo išduotą SCP, reikalinga bendra duomenų struktūra ir susitarimas dėl kiekvienos naudingųjų duomenų laukelio reikšmės. Siekiant palengvinti sąveikumą, bendra suderinta duomenų struktūra apibrėžiama naudojant JSON schemą, kurios pagrindu suformuota SCP sistema.

3.1.    Naudingųjų duomenų struktūra

Naudingieji duomenys struktūruojami ir koduojami CBOR formatu, naudojant COSE skaitmeninį parašą. Jis paprastai vadinamas CBOR saityno atpažinimo ženklu (angl. CBOR Web Token, CWT) ir yra apibrėžtas standarte RFC 8392 ( 1 ). Naudingieji duomenys, apibrėžiami tolesniuose skirsniuose, perduodami hcert prašymu.

Tikrintojas turi galėti patikrinti naudingųjų duomenų vientisumą ir kilmės autentiškumą. Kad būtų užtikrintas šis mechanizmas, išdavėjas turi pasirašyti CWT naudodamas asimetrinę elektroninio parašo schemą, kuri apibrėžta COSE specifikacijoje (RFC 8152 ( 2 )).

3.2.    CWT prašymai

3.2.1.    CWT struktūros apžvalga

Apsaugota antraštė

Naudingieji duomenys

Parašas

3.2.2.    Parašo algoritmas

Parašo algoritmo (alg) parametru nurodoma, koks algoritmas naudojamas parašui sukurti. Jis turi atitikti dabartines SOG-IS gaires, kurios apibendrintai išdėstytos tolesniuose punktuose, arba būti už jas pranašesnis.

Apibrėžiamas vienas pirminis ir vienas antrinis algoritmas. Antrinis algoritmas turėtų būti naudojamas tik jei pirminis algoritmas yra nepriimtinas pagal išdavėjui nustatytas taisykles ir reglamentus.

Kad būtų užtikrintas sistemos saugumas, visose įgyvendinimo priemonėse turi būti įdiegtas antrinis algoritmas. Dėl šios priežasties turi būti įdiegtas ir pirminis, ir antrinis algoritmas.

Toliau nurodyti pirminio ir antrinio algoritmų SOG-IS rinkinių lygiai.

Jis atitinka COSE algoritmo parametrą ES256.

Jis atitinka COSE algoritmo parametrą PS256.

3.2.3.    Rakto identifikatorius

Rakto identifikatoriaus (kid) prašymas reiškia dokumento pasirašytojo sertifikatą (DSC), kuriame yra viešasis raktas, kurį tikrintojas turi naudoti skaitmeninio parašo teisingumui patikrinti. Viešojo rakto sertifikatų valdymas, įskaitant DSC taikomus reikalavimus, aprašytas IV priede.

Rakto identifikatoriaus (kid) prašymą tikrintojai naudoja, kad iš raktų sąrašo pasirinktų tinkamą išdavėjo (iss) prašyme nurodytą su išdavėju susijusį viešąjį raktą. Administravimo tikslais ir atlikdamas raktų atnaujinimą išdavėjas gali lygiagrečiai naudoti kelis raktus. Rakto identifikatorius nėra saugumui svarbus laukelis. Todėl, prireikus, jis taip pat gali būti pateikiamas neapsaugotoje antraštėje. Tikrintojai turi priimti abi parinktis. Esant abiem parinktims, reikia naudoti apsaugotoje antraštėje esantį rakto identifikatorių.

Kadangi identifikatorius yra sutrumpintas (dėl vietos ribojimo priežasčių), yra nedidelė tikimybė (tačiau ji negali būti atmesta), kad bendrame tvirtintojo priimtų DSC sąraše gali būti DSC su vienodais rakto identifikatoriais (kid). Dėl šios priežasties tikrintojas turi patikrinti visus DSC su atitinkamu rakto identifikatoriumi (kid).

3.2.4.    Išdavėjas

Išdavėjo (iss) prašymas yra eilutės reikšmė, kurioje gali būti nurodytas sveikatos pažymėjimą išdavusio subjekto šalies kodas alfa-2 formatu pagal standartą ISO 3166-1. Šį prašymą tikrintojas gali naudoti nustatydamas, kurį DSC rinkinį naudoti patvirtinimui. Šiam prašymui identifikuoti naudojamas 1 prašymo raktas.

3.2.5.    Galiojimo laikas

Galiojimo pabaigos laiko (exp) prašyme pateikta laiko žyma sveikųjų skaičių (NumericDate) formatu (kaip apibrėžta standarto RFC 8392 ( 4 ) 2 skirsnyje), žyminti konkretaus parašo, pateikto dėl tų naudingųjų duomenų, galiojimo laiką, po kurio tikrintojas naudinguosius duomenis turi atmesti kaip nebegaliojančius. Galiojimo pabaigos parametro paskirtis – nustatyti sveikatos pažymėjimo galiojimo laikotarpio ribas. Šiam prašymui identifikuoti naudojamas 4 prašymo raktas.

Galiojimo laikas negali viršyti DSC galiojimo laikotarpio.

3.2.6.    Išdavimo laikas

Išdavimo laiko (iat) prašyme pateikta laiko žyma sveikųjų skaičių (NumericDate) formatu (kaip apibrėžta standarto RFC 8392 ( 5 ) 2 skirsnyje), žyminti sveikatos pažymėjimo sukūrimo laiką.

Išdavimo laiko laukelio reikšmė negali būti ankstesnė už DSC galiojimo laikotarpį.

Tikrintojai gali taikyti papildomas taisykles, kuriomis siekiama apriboti sveikatos pažymėjimo galiojimą pagal jo išdavimo laiką. Šiam prašymui identifikuoti naudojamas 6 prašymo raktas.

3.2.7.    Sveikatos pažymėjimo prašymas

Sveikatos pažymėjimo (hcert) prašymas yra JSON (RFC 7159 ( 6 )) objektas, kuriame pateikiama sveikatos būklės informacija. Pagal tą patį prašymą gali būti išduodami kelių skirtingų tipų sveikatos pažymėjimai, iš kurių vienas yra SCP.

JSON naudojamas tik schemai. Pateikimo formatas yra CBOR, apibrėžtas standarte RFC 7049 ( 7 ). Taikomųjų programų kūrėjai gali visiškai nekoduoti į JSON formatą ir iš jo, bet naudoti atmintyje išsaugotą struktūrą.

Šiam prašymui identifikuoti naudojamas -260 prašymo raktas.

JSON objekto eilutės turėtų būti normalizuotos pagal unikodo standarte apibrėžtą kanoninės sudėties normalizavimo formą (angl. Normalization Form Canonical Composition, NFC). Tačiau šiuo požiūriu dekodavimo taikomosios programos turėtų būti pralaidžios ir patikimos, todėl labai rekomenduojama priimti bet kokį pagrįsto tipo konvertavimą. Jei dekoduojant arba vykdant tolesnes palyginimo funkcijas aptinkama nenormalizuotų duomenų, įdiegtos programos turėtų elgtis taip, tarsi įvestis būtų normalizuota pagal NFC formą.

4.    SCP naudingųjų duomenų serializavimas ir sukūrimas

Serializavimui taikoma ši schema:

Procesas prasideda nuo duomenų išgavimo, pavyzdžiui, iš sveikatos duomenų saugyklos (arba iš kokio nors išorinio duomenų šaltinio), struktūruojant gautus duomenis pagal nustatytas SCP schemas. Šio proceso metu, prieš pradedant serializavimą CBOR, gali būti atliekamas perkeitimas į nustatytą duomenų formatą ir transformavimas į žmogui suprantamą formatą. Prieš serializavimą ir deserializavimą prašymų santrumpos visais atvejais turi būti prilyginamos rodomiems pavadinimams.

Pažymėjimuose, išduotuose pagal Reglamentą (ES) 2021/953 ( 8 ), neleidžiamas pasirinktinis nacionalinių duomenų turinys. Duomenų turinys turi būti apribotas Reglamento (ES) 2021/953 priede nurodyto minimalaus duomenų rinkinio apibrėžtais duomenų elementais.

5.    Koduotų duomenų perdavimas

5.1.    Neapdoroti duomenys

Jei naudojamos bet kokios pasirinktinės duomenų sąsajos, HCERT rinkmena ir jos naudingieji duomenys gali būti perduodami tokie, kokie yra, naudojant bet kokį pagrindinį 8 bitų saugų ir patikimą duomenų perdavimą. Šios sąsajos gali būti keitimosi duomenimis trumpu atstumu technologija (NFC), „Bluetooth“ arba perdavimas per taikomosios programos lygmens protokolą, pavyzdžiui, HCERT perdavimas iš išdavėjo į turėtojo mobilųjį įrenginį.

Jei HCERT iš išdavėjo turėtojui perduodamas tik naudojant pateikimo sąsają (pvz., žinutes, e. paštą), akivaizdu, kad neapdorotų koduotų duomenų perdavimas netaikomas.

5.2.    Brūkšninis kodas

5.2.1.    Naudingųjų duomenų (CWT) glaudinimas

Siekiant sumažinti HCERT dydį ir padidinti nuskaitymo proceso greitį bei patikimumą, CWT turi būti glaudinamas naudojant programinę įrangą ZLIB (RFC 1950 ( 9 )) ir glaudinimo mechanizmą „Deflate“, kurio formatas apibrėžtas standarte RFC 1951 ( 10 ).

5.2.2.    QR 2D brūkšninis kodas

Kad būtų galima geriau panaudoti senesnę įrangą, skirtą ASCII naudingiesiems duomenims, suglaudintas CWT, prieš jį koduojant 2D brūkšniniu kodu, pirmiausia koduojamas kaip ASCII naudojant „Base45“.

2D brūkšniniam kodui generuoti naudojamas QR formatas, apibrėžtas standarte ISO/IEC 18004:2015. Rekomenduojama naudoti klaidų taisymo koeficientą „Q“ (apie 25 %). Kadangi naudojamas „Base45“, QR kodas turi būti naudojamas naudojant raidinį skaitmeninį kodavimą (2 būdas, žymimas simboliais 0010).

Kad tikrintojai galėtų nustatyti koduotų duomenų tipą ir parinkti tinkamą iškodavimo ir apdorojimo schemą, prieš „Base45“ koduotus duomenis (pagal šią specifikaciją) įrašoma konteksto identifikatoriaus eilutė „HC1:“. Būsimose šios specifikacijos versijose, turinčiose įtakos atgaliniam suderinamumui, turi būti apibrėžtas naujas konteksto identifikatorius, o po „HC“ einantis simbolis pasitelkiamas iš simbolių rinkinio [1–9A–Z]. Didėjimo tvarka apibrėžiama nurodyta tvarka, t. y. pirma [1–9] ir po to [A–Z].

Optinį kodą rekomenduojama pateikti 35–60 mm įstrižainės pateikimo laikmenoje, kad jį būtų galima nuskaityti skaitytuvais su stacionaria optika, kai pateikimo laikmeną reikia padėti ant skaitytuvo paviršiaus.

Jei optinis kodas spausdinamas popieriuje naudojant mažos skiriamosios gebos (< 300 dpi) spausdintuvus, reikia stengtis, kad kiekvienas QR kodo simbolis (taškas) būtų tiksliai kvadratinis. Dėl neproporcingo mastelio keitimo kai kuriose QR eilutėse ar stulpeliuose simboliai bus stačiakampiai, ir juos daugeliu atvejų bus sunku nuskaityti.

6.    Patikimumo sąrašo formatas (CSCA ir DSC sąrašas)

Kiekviena valstybė narė privalo pateikti vienos ar daugiau parašą patvirtinančių šalies sertifikavimo įstaigų (CSCA) sąrašą ir visų galiojančių dokumento pasirašytojo sertifikatų (DSC) sąrašą ir šiuos sąrašus nuolat atnaujinti.

6.1.    Supaprastinta CSCA / DSC

Patvirtinus šią specifikacijų versiją valstybės narės nebegali daryti prielaidos, kad naudojama kokia nors atšauktų sertifikatų sąrašo (CRL) informacija arba kad privačiojo rakto naudojimo laikotarpį tikrina programinės įrangos diegėjai.

Vietoje to pagrindinis galiojimo mechanizmas yra sertifikatas, įtrauktas į naujausią atitinkamo sertifikatų sąrašo versiją.

6.2.    ICAO elektroninio mašininio nuskaitymo kelionės dokumento (eMRTD) viešojo rakto infrastruktūra (PKI) ir patikimumo užtikrinimo centrai

Valstybės narės gali pasitelkti atskirą CSCA, tačiau taip pat gali pateikti savo esamus elektroninio mašininio nuskaitymo kelionės dokumento CSCA sertifikatus ir (arba) DSC; jos netgi gali nuspręsti šiuos sertifikatus įsigyti iš (komercinių) patikimumo užtikrinimo centrų ir juos pateikti. Tačiau bet koks DSC visada turi būti pasirašytas tos valstybės narės nurodytos CSCA.

7.    Saugumo aspektai

Rengdamos schemą pagal šią specifikaciją valstybės narės nustato, analizuoja ir stebi tam tikrus saugumo aspektus.

Turėtų būti atsižvelgta bent į šiuos aspektus:

7.1.    HCERT parašo galiojimo laikas

HCERT išdavėjas privalo apriboti parašo galiojimo laiką, nurodydamas parašo galiojimo pabaigos laiką. Tai reiškia, kad sveikatos pažymėjimo turėtojas turi periodiškai jį atnaujinti.

Priimtinas galiojimo laikotarpis gali būti nustatytas atsižvelgiant į praktinius apribojimus. Pavyzdžiui, keliautojas gali neturėti galimybės atnaujinti sveikatos pažymėjimo keliaudamas užsienyje. Tačiau taip pat galimi atvejai, kad išdavėjas numato tam tikro saugumo pažeidimo galimybę, dėl kurios išdavėjas turi atšaukti DSC (panaikindamas visus naudojant tą raktą išduotus sveikatos pažymėjimus, kurių galiojimo laikas dar nepasibaigęs). Tokio atvejo pasekmes galima apriboti reguliariai keičiant išdavėjo raktus ir reikalaujant, kad visi sveikatos pažymėjimai būtų atnaujinami tam tikru pagrįstu periodiškumu.

7.2.    Raktų valdymas

Ši specifikacija pagrįsta patikimais kriptografiniais mechanizmais, kad būtų užtikrintas duomenų vientisumas ir duomenų kilmės autentiškumas. Todėl būtina užtikrinti privačių raktų konfidencialumą.

Kriptografinių raktų konfidencialumas gali būti pažeistas įvairiais būdais, kaip antai:

Siekiant sumažinti riziką, kad pasirašymo algoritmas gali būti silpnas ir dėl to naudojant kriptoanalizės priemones gali būti pažeisti privatieji raktai, šioje specifikacijoje visiems dalyviams rekomenduojama įdiegti antrinį atsarginį pasirašymo algoritmą, pagrįstą kitais parametrais arba kitu matematiniu uždaviniu nei pagrindinis.

Kalbant apie minėtą riziką, susijusią su išdavėjų veiklos aplinka, turi būti įgyvendinamos veiksmingą kontrolę užtikrinančios rizikos švelninimo priemonės, pavyzdžiui, privačiuosius raktus generuoti, saugoti ir naudoti aparatiniuose saugumo moduliuose (toliau – ASM). Sveikatos pažymėjimams pasirašyti labai rekomenduojama naudoti ASM.

Nepriklausomai nuo to, ar išdavėjas nusprendžia naudoti ASM, turėtų būti sudarytas raktų atnaujinimo grafikas, pagal kurį raktų atnaujinimo dažnumas būtų proporcingas raktų poveikiui išoriniams tinklams, kitoms sistemoms ir personalui. Tinkamai parinkus atnaujinimo grafiką taip pat sumažinama rizika, susijusi su klaidingai išduodamais sveikatos pažymėjimais, nes prireikus išdavėjas gali atšaukti tokius sveikatos pažymėjimus partijomis, anuliuodamas raktą.

7.3.    Įvesties duomenų patvirtinimas

Šios specifikacijos gali būti panaudojamos taip, kad iš nepatikimų šaltinių būtų gaunami duomenys į sistemas, kurios gali būti kritinės svarbos. Siekiant sumažinti su tokiu atakos vektoriumi susijusią riziką, visi įvesties laukeliai turi būti tinkamai patvirtinti pagal duomenų tipus, ilgį ir turinį. Prieš pradedant tvarkyti HCERT turinį taip pat patikrinamas išdavėjo parašas. Tačiau norint patvirtinti išdavėjo parašą, pirmiausia reikia išanalizuoti apsaugotą išdavėjo antraštę, kurioje potencialus užpuolikas gali bandyti įterpti kruopščiai sukurtą informaciją, kuria siekiama pakenkti sistemos saugumui.

8.    Patikimumo užtikrinimas

HCERT parašui patikrinti reikalingas viešasis raktas. Valstybės narės suteikia galimybę naudotis šiais viešaisiais raktais. Galiausiai kiekvienas tikrintojas turi turėti visų viešųjų raktų, kuriais jis gali pasitikėti, sąrašą (nes viešasis raktas nėra HCERT dalis).

Sistemą sudaro (tik) du lygiai; kiekvienai valstybei narei – po vieną ar daugiau šalies lygmens sertifikatų, kuriais pasirašoma po vieną ar daugiau dokumento pasirašytojo sertifikatų, naudojamų kasdienėje veikloje.

Valstybių narių sertifikatai vadinami parašą patvirtinančios šalies sertifikavimo įstaigos (CSCA) sertifikatais ir (paprastai) yra savarankiškai pasirašyti sertifikatai. Valstybėse narėse gali būti daugiau nei vienas sertifikatas (pavyzdžiui, regioninės decentralizacijos atveju). Tokiais CSCA sertifikatais nuolat pasirašomi dokumento pasirašytojo sertifikatai (DSC), naudojami HCERT pasirašyti.

Sekretoriato vaidmuo yra funkcinis. Jis reguliariai apibendrina ir skelbia valstybių narių DSC, prieš tai patikrinęs juos pagal CSCA sertifikatų (kurie buvo perduoti ir patikrinti kitais būdais) sąrašą.

Taip gautame DSC sąraše pateikiamas apibendrintas priimtinų viešųjų raktų (ir atitinkamų rakto identifikatorių) rinkinys, kurį tikrintojai gali naudoti HCERT parašams patvirtinti. Tikrintojai turi periodiškai gauti ir atnaujinti šį sąrašą.

Tokie konkrečiai valstybei narei skirti sąrašai gali būti pritaikomi jos nacionalinei aplinkai. Todėl šio patikimumo sąrašo failo formatas gali būti įvairus, pavyzdžiui, tai gali būti pasirašytas JWKS (JWK rinkinio formatas pagal standarto RFC 7517 ( 11 ) 5 skirsnį) arba bet koks kitas formatas, būdingas toje valstybėje narėje naudojamai technologijai.

Siekdamos užtikrinti paprastumą, valstybės narės gali pateikti esamus CSCA sertifikatus iš savo ICAO elektroninio mašininio nuskaitymo kelionės dokumentų sistemų arba, kaip rekomenduoja PSO, sukurti specialiai šiai sveikatos sričiai skirtą pažymėjimą.

8.1.    Rakto identifikatorius (kid)

Rakto identifikatorius (kid) apskaičiuojamas sukūrus DSC patikimų viešųjų raktų sąrašą, kurį sudaro sutrumpintas (pirmieji 8 baitai) DSC, koduoto DER (neapdorotu) formatu, SHA-256 pirštų atspaudas.

Tikrintojams nereikia apskaičiuoti rakto identifikatoriaus pagal DSC; jie gali tiesiogiai palyginti išduotame sveikatos pažymėjime esantį rakto identifikatorių su patikimumo sąraše esančiu rakto identifikatoriumi.

8.2.    Skirtumai, palyginti su ICAO elektroninio mašininio nuskaitymo kelionės dokumento viešojo rakto infrastruktūros patikimumo užtikrinimo modeliu

Nors šis modelis parengtas pagal ICAO elektroninio mašininio nuskaitymo kelionės dokumento viešojo rakto infrastruktūros patikimumo modelio geriausią praktiką, siekiant spartos reikalingi keli supaprastinimai:

▼M3

9.    Su panaikintais pažymėjimais susijęs sprendinys

9.1.    Galimybė teikti panaikintų SCP sąrašus

Tinklų sietuve sukuriami panaikintų pažymėjimų sąrašams saugoti ir tvarkyti reikalingi galiniai taškai (angl. endpoints) ir funkcinės galimybės:

9.2.    Patikimumo užtikrinimo modelis

Visi ryšiai užmezgami taikant standartinį SCPTS patikimumo užtikrinimo modelį, naudojant NBTLS ir NBUP sertifikatus (žr. sertifikatų valdymo nuostatas). Siekiant užtikrinti vientisumą, visa informacija supakuojama ir įkeliama CMS pranešimais.

9.3.    Paketų sudarymas

9.3.1.    Paketas

Kiekvienas iš vieno ar kelių įrašų susidedantis panaikintų pažymėjimų sąrašas yra įtraukiamas į paketą (angl. batch), kurį sudaro maišos reikšmių (angl. hashes) ir jų metaduomenų rinkinys. Paketas yra nekintamas ir jam yra nustatoma galiojimo pabaigos data, t. y. diena, kurią paketas gali būti pašalintas. Visų į paketą įeinančių elementų galiojimo pabaigos data turi būti ta pati, t. y. paketai turi būti grupuojami pagal galiojimo pabaigos datą ir pasirašymui naudotą DSC. Kiekvieną paketą gali sudaryti ne daugiau kaip 1 000 įrašų. Jei panaikintų pažymėjimų sąrašą sudaro daugiau kaip 1 000 įrašų, sukuriami keli paketai. Kiekvienas įrašas gali būti įtrauktas į ne daugiau kaip vieną paketą. Paketas supakuojamas į CMS struktūrą ir pasirašomas naudojant jį įkeliančios šalies NBUP sertifikatą.

9.3.2.    Paketų rodyklė

Sukurtam paketui tinklų sietuve suteikiamas unikalus identifikatorius, o paketo nuoroda yra automatiškai įtraukiama į rodyklę (angl. index). Paketai rodyklėje nurodomi eilės tvarka pagal jų pakeitimo datą, pradedant nuo seniausiai pakeistų paketų.

9.3.3.    Tinklų sietuvo veiksmai

Tinklų sietuvas panaikintų pažymėjimų paketus tvarko niekaip jų nekeisdamas – jis negali nei atnaujinti ar pašalinti jokios į paketus įeinančios informacijos, nei į juos įtraukti papildomos informacijos. |Paketai persiunčiami visoms šalims, kurioms juos galima siųsti (žr. 9.6 skirsnį).

Tinklų sietuvas aktyviai seka paketų galiojimo pabaigos datas ir pašalina paketus, kurių galiojimas baigėsi. Kai paketas pašalinamas, į kreipimąsi jo URL adresu tinklų sietuvas atsako pranešimu „HTTP 410 Gone“. Todėl paketų rodyklėje tas paketas nurodomas kaip pašalintas.

9.4.    Maišos reikšmių tipai

Panaikintų pažymėjimų sąrašą sudaro maišos reikšmės (angl. hashes), kuriomis gali būti išreikšti skirtingi panaikintų pažymėjimų tipai ir (arba) požymiai. Šie tipai arba požymiai nurodomi užtikrinant galimybę teikti panaikintų pažymėjimų sąrašus. Dabartiniai tipai yra:

Į paketus yra įtraukiami ir panaikintiems SCP identifikuoti naudojami tik pirmieji 128 maišos reikšmių, užkoduotų „base64“ eilutėmis (angl. strings), bitai ( 12 ).

9.4.1.    Maišos reikšmės tipas SHA256 (SCP parašas)

Šiuo atveju maišos reikšmė apskaičiuojama naudojant COSE_SIGN1 parašo baitus iš CWT. RSA parašų atveju kaip įvedinys naudojamas visas parašas. Jei pažymėjimas pasirašytas EC-DSA parašu, formulėje kaip įvedinys naudojama r reikšmė:

SHA256(r).

[privaloma naudoti visose naujose įgyvendinimo priemonėse]

9.4.2.    Maišos reikšmės tipas SHA256 (UPI)

Šiuo atveju maišos reikšmė apskaičiuojama naudojant UTF-8 koduote užkoduotą ir į baitų masyvą (angl. byte array) paverstą UPI eilutę.

[nebenaudotina ( 13 ), tačiau palaikoma siekiant užtikrinti atgalinį suderinamumą]

9.4.3.    Maišos reikšmės tipas SHA256 (pažymėjimą išdavusios šalies kodas ir UPI)

Šiuo atveju UTF-8 eilute užkoduotas šalies kodas yra sujungiamas su UTF-8 eilute užkoduotu UPI. Gautas junginys paverčiamas baitų masyvu ir naudojamas kaip maišos funkcijos įvedinys.

[nebenaudotina2, tačiau palaikoma siekiant užtikrinti atgalinį suderinamumą]

9.5.    API struktūra

9.5.1.    Įrašų apie panaikintus pažymėjimus pateikimo API

9.5.1.1.   Tikslas

API pateikia į atskirus paketus suskirstytus panaikintų pažymėjimų sąrašų įrašus ir paketų rodyklę.

9.5.1.2.   Galiniai taškai

9.5.1.2.1.   Paketų sąrašo atsisiuntimo galinis taškas

Galinių taškų struktūra yra paprasta; jos paskirtis – pateikti paketų sąrašą kartu su nedideliu kiekiu metaduomenų. Paketai išdėstomi eilės tvarka pagal datą, pradedant nuo seniausio paketo.

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

Pastaba. Rezultatų skaičius standartiškai yra apribotas iki 1 000 . Jei žymos „more“ reikšmė yra „true“, atsakyme nurodoma, kad esama daugiau galimų atsisiųsti paketų. Norėdamas atsisiųsti daugiau elementų, klientas turi pakeisti antraštės „If-Modified-Since“ reikšmę į datą, kuri yra ne ankstesnė nei paskutinio gauto įrašo data.

Atsakyme pateikiamas JSON formato masyvas, kurio struktūra yra tokia:

9.5.1.2.1.1.   Atsakymų kodai

Užklausų antraštės

9.5.1.2.2.   Paketų atsisiuntimo galinis taškas

Paketą sudaro pažymėjimų identifikatorių sąrašas:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

Atsakymui naudojama CMS, įskaitant parašą, kuris turi atitikti konkrečios šalies NBUP sertifikatą. Visų JSON formato masyvo elementų struktūra yra tokia:

9.5.1.2.2.1.   Įrašai

Pastaba. Šiuo metu įrašų objektas apima tik maišos reikšmę, tačiau ne JSON formato masyvas, o objektas buvo pasirinktas tam, kad būtų galima prisiderinti prie pokyčių ateityje.

9.5.1.2.2.2.   Atsakymų kodai

9.5.1.2.2.3.   Atsakymų antraštės

9.5.1.2.3.   Paketų įkėlimo galinis taškas

Paketai įkeliami per tą patį galinį tašką naudojant metodą (angl. verb) POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

Paketas pasirašomas naudojant NBUP sertifikatą. Tinklų sietuvas patikrina, ar parašą sukūrė atitinkamos šalies NBUP. Jei parašo patvirtinti nepavyksta, paketas neįkeliamas.

PASTABA. Visi paketai yra nekintami ir po įkėlimo negali būti keičiami. Tačiau jie gali būti pašalinami. Kiekvieno pašalinto paketo identifikatorius išsaugomas ir bandymai įkelti naują paketą, kuriam suteiktas toks pats identifikatorius, atmetami.

9.5.1.2.4.   Paketų pašalinimo galinis taškas

Paketą galima pašalinti per tą patį galinį tašką naudojant metodą DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

arba – dėl suderinamumo priežasčių – per šį galinį tašką naudojant metodą POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

9.6.    API apsauga/BDAR

Šiame skirsnyje nurodomos įgyvendinimo priemonės, kurių tikslas – užtikrinti, kad būtų laikomasi su asmens duomenų tvarkymu susijusių Reglamento (ES) 2021/953 nuostatų.

9.6.1.    Dabartinis tapatumo nustatymo procesas

Prie tinklų sietuvo besijungiančių šalių tapatumas šiuo metu nustatomas naudojant NBTLS sertifikatą. Šis tapatumo nustatymo procesas gali būti naudojamas prie tinklų sietuvo prisijungusios šalies tapatybei nustatyti. Tada pagal tą tapatybę gali būti taikomos prieigos kontrolės priemonės.

9.6.2.    Prieigos kontrolė

Kad būtų galima teisėtai tvarkyti asmens duomenis, tinklų sietuve įdiegiamas prieigos kontrolės mechanizmas.

Konkrečiai, tinklų sietuve taikomas prieigos teisių sąrašas ir funkcijomis grindžiama saugumo sistema. Pagal šį mechanizmą tvarkomos dvi lentelės – vienoje aprašoma, kokius veiksmus su kokiais ištekliais gali atlikti kiekvienos konkrečios funkcijos vykdytojas, kitoje nurodoma, kokios funkcijos yra priskirtos konkretiems naudotojams.

Siekiant vykdyti šiame dokumente reikalaujamą kontrolę, reikalingos trys funkcijos:

Toliau nurodyti galiniai taškai patikrina, ar naudotojui yra priskirta funkcija RevocationListReader; jei taip, jam suteikiama prieiga, o jei ne, pateikiamas klaidos pranešimas HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Toliau nurodyti galiniai taškai patikrina, ar naudotojui yra priskirta funkcija RevocationUploader; jei taip, jam suteikiama prieiga, o jei ne, pateikiamas klaidos pranešimas HTTP 403 Forbidden:

POST/revocation-list

Toliau nurodyti galiniai taškai patikrina, ar naudotojui yra priskirta funkcija RevocationDeleter; jei taip, jam suteikiama prieiga, o jei ne, pateikiamas klaidos pranešimas HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Tinklų sietuve taip pat įdiegiamas patikimas metodas, kurį taikydami administratoriai galėtų valdyti naudotojams priskiriamas funkcijas taip, kad žmogiškųjų klaidų tikimybė būtų kuo mažesnė ir kad tai neapsunkintų funkcinių administratorių.

▼M1

---

II PRIEDAS

ES SKAITMENINIO COVID PAŽYMĖJIMO PILDYMO TAISYKLĖS

Šiame priede nustatytomis bendrosiomis reikšmių rinkinių taisyklėmis siekiama užtikrinti sąveikumą semantiniu lygmeniu ir sudaryti sąlygas vienodam techniniam ES skaitmeninio COVID pažymėjimo įgyvendinimui. Šiame priede esantys elementai gali būti naudojami trims skirtingiems formatams (skiepijimo, tyrimo rezultatų ir persirgimo), numatytiems Reglamente (ES) 2021/953. Šiame priede išvardyti tik tie elementai, kuriuos būtina semantiškai standartizuoti naudojant koduotus reikšmių rinkinius.

Už koduotų elementų vertimą į nacionalinę kalbą atsako valstybės narės.

Visų duomenų laukelių, nepaminėtų toliau nurodytuose reikšmių rinkinio aprašymuose, kodavimas apibūdintas V priede.

Jei dėl kokių nors priežasčių negalima naudoti toliau išvardytų pageidaujamų kodų sistemų, galima naudoti kitas tarptautines kodų sistemas ir rekomendacijas, kaip kitos kodų sistemos kodus perkelti į pageidaujamą kodų sistemą. Tekstas (rodomi pavadinimai) gali būti naudojamas išimtiniais atvejais kaip atsarginis mechanizmas, kai apibrėžtuose reikšmių rinkiniuose nėra tinkamo kodo.

Valstybės narės, savo sistemose naudojančios kitus kodus, priskiria juos aprašytiems reikšmių rinkiniams. Valstybės narės yra atsakingos už visus tokio priskyrimo atvejus.

►M4  Kadangi kai kurie reikšmių rinkiniai, pagrįsti šiame priede numatytomis kodavimo sistemomis, pvz., vakcinoms ir antigenų testams koduoti, dažnai kinta, Komisija juos skelbia ir reguliariai atnaujina ir jai padeda E. sveikatos tinklas ir Sveikatos saugumo komitetas. ◄ Atnaujinti reikšmių rinkiniai skelbiami atitinkamoje Komisijos interneto svetainėje ir E. sveikatos tinklo interneto svetainėje. Pateikiama pakeitimų istorija.

1.    Tiriama liga ar sukėlėjas / Liga, kuria pažymėjimo turėtojas persirgo, arba ligos sukėlėjas: COVID-19 (SARS-CoV-2 arba viena iš jo atmainų)

Naudotina 1, 2 ir 3 pažymėjimuose.

Naudojami šie kodai:

2.    COVID-19 vakcina arba profilaktinis gydymas

Pageidaujama kodų sistema: SNOMED CT arba ATC klasifikacija.

Naudotina 1 pažymėjime.

Pageidaujamų kodų sistemų naudotinų kodų pavyzdžiai: SNOMED CT kodas 1119305005 (SARS-CoV-2 antigenų vakcina), 1119349007 (SARS-CoV-2 mRNA vakcina) arba J07BX03 (COVID-19 vakcinos).

Komisija, padedama E. sveikatos tinklo, skelbia ir reguliariai atnaujina reikšmių rinkinį, kuriame pateikiami pagal šiame skirsnyje numatytas kodų sistemas naudotini kodai. Sukūrus ir pradėjus naudoti naujų rūšių vakcinas reikšmių rinkinys išplečiamas.

3.    COVID-19 vakcina

Pageidaujamos kodų sistemos (eilės tvarka):

Reikšmių rinkinio pavadinimas: vakcina.

Naudotina 1 pažymėjime.

Pageidaujamų kodų sistemų naudotino kodo pavyzdys – EU/1/20/1528 („Comirnaty“). Vakcinos pavadinimo, kuris bus naudojamas kaip kodas, pavyzdys – Sputnik-V (reiškia „Sputnik V“).

Komisija, padedama E. sveikatos tinklo, skelbia ir reguliariai atnaujina reikšmių rinkinį, kuriame pateikiami pagal šiame skirsnyje numatytas kodų sistemas naudotini kodai.

Vakcinos koduojamos naudojant paskelbtame reikšmių rinkinyje esantį kodą, net jei šalyse vartojami skirtingi jų pavadinimai. Taip yra todėl, kad dar nėra pasaulinio vakcinų registro, į kurį būtų įtrauktos visos dabar naudojamos vakcinos. Pavyzdys:

Jei konkrečiu atveju tai neįmanoma ar nepageidaujama, paskelbtame reikšmių rinkinyje bus pateiktas atskiras kodas.

▼M4

Jei ES skaitmeninį COVID pažymėjimą (ES SCP) naudojanti šalis nusprendžia išduoti skiepijimo pažymėjimus klinikinių tyrimų dalyviams vykstant klinikiniams tyrimams, vakcina koduojama pagal šį modelį:

CT_clinical-trial-identifier.

Jei klinikinis tyrimas užregistruotas ES klinikinių tyrimų registre, naudojamas klinikinio tyrimo identifikatorius iš šio registro. Kitais atvejais gali būti naudojami kitų registrų (pvz., clinicaltrials.gov arba „Australian New Zealand Clinical Trials Registry“) identifikatoriai.

Klinikinio tyrimo identifikatorius apima prefiksą, pagal kurį galima identifikuoti klinikinių tyrimų registrą (pvz., EUCTR – ES klinikinių tyrimų registras, NCT – clinicaltrials.gov, ACTRN – „Australian New Zealand Clinical Trials Registry“).

Jeigu Komisija gavo Sveikatos saugumo komiteto, Europos ligų prevencijos ir kontrolės centro (ECDC) arba Europos vaistų agentūros (EMA) gaires dėl pažymėjimų, išduodamų paskiepijus COVID-19 vakcina, dėl kurios atliekami klinikiniai tyrimai, pripažinimo, gairės paskelbiamos kaip reikšmių rinkinių dokumento dalis arba atskirai.

▼M1

4.    COVID-19 vakcinos rinkodaros leidimo turėtojas arba gamintojas

Pageidaujama kodų sistema:

Naudotina 1 pažymėjime.

Pageidaujamų kodų sistemų naudotino kodo pavyzdys – ORG-100001699 („AstraZeneca AB“). Kaip kodas naudotino organizacijos pavadinimo pavyzdys – Sinovac-Biotech (reiškia „Sinovac Biotech“).

Komisija, padedama E. sveikatos tinklo, skelbia ir reguliariai atnaujina reikšmių rinkinį, kuriame pateikiami pagal šiame skirsnyje numatytas kodų sistemas naudotini kodai.

To paties rinkodaros leidimo turėtojo arba to paties gamintojo filialams naudojamas paskelbtame reikšmių rinkinyje esantis kodas.

Paprastai tos pačios vakcinos atveju naudojamas jos rinkodaros leidimo turėtoją ES nurodantis kodas, kadangi dar nėra tarptautiniu mastu sutarto vakcinų gamintojų ar rinkodaros leidimo turėtojų registro. Pavyzdžiai:

Jei konkrečiu atveju tai neįmanoma ar nepageidaujama, paskelbtame reikšmių rinkinyje bus pateiktas atskiras kodas.

▼M4

Jeigu šalis, kuri naudoja ES SCP, nusprendžia klinikinių tyrimų dalyviams išduoti skiepijimo pažymėjimus vykstant klinikiniams tyrimams, vakcinos rinkodaros leidimo turėtojui arba gamintojui kodas priskiriamas naudojant reikšmių rinkinyje jam priskirtą reikšmę, jei tokia yra. Kitais atvejais vakcinos rinkodaros leidimo turėtojui arba gamintojui kodas priskiriamas pagal 3 skirsnyje („COVID-19 vakcina“) aprašytą taisyklę (CT_clinical-trial-identifier).

▼M1

5.    Skiepijimo kurso dozės eilės numeris ir bendras kurso dozių skaičius

Naudotina 1 pažymėjime.

Du laukeliai:

5.1.    Pirminio skiepijimo kursas

Jei asmuo gauna pirminio skiepijimo kurso, t. y. skiepijimo kurso, kuriuo siekiama suteikti pakankamai apsaugos pradiniu etapu, dozes, skaičius C atitinka bendrą standartinio pirminio skiepijimo kurso dozių skaičių (pvz., 1 arba 2, atsižvelgiant į vakcinos, kuria skiepijama, rūšį). Tai apima galimybę naudoti trumpesnį kursą (C = 1), jei pagal valstybės narės taikomą skiepijimo protokolą asmenis, kurie buvo užsikrėtę SARS-CoV-2, numatoma skiepyti tik viena dviejų dozių vakcinos doze. Tokiu atveju užbaigtas pirminio skiepijimo kursas būtų nurodamas taip: N/C = 1. Pavyzdžiui:

Jei pirminio skiepijimo kursas pratęsiamas, pvz., labai susilpnėjusios imuninės sistemos asmenims arba nesilaikius rekomenduojamo laiko tarpo tarp pirminių dozių, visos šios dozės koduojamos kaip papildomos dozės, kurioms taikomas 5.2 skirsnis.

▼M2

5.2.    Stiprinamosios dozės

Po pirminio skiepijimo kurso paskiepijus asmenį stiprinamosiomis dozėmis, šios dozės atitinkamuose pažymėjimuose nurodomos taip:

Šiame skirsnyje nustatytas kodavimo taisykles valstybės narės įgyvendina iki 2022 m. vasario 1 d.

Valstybės narės automatiškai arba atitinkamų asmenų prašymu pakartotinai išduoda pažymėjimus, kuriuose paskiepijimas stiprinamąja doze po pirminio skiepijimo vienos dozės vakcina kurso koduojamas taip, kad jo nebūtų galima atskirti nuo pirminio skiepijimo kurso užbaigimo.

Šiame priede nuorodos į „stiprinamąsias dozes“ turėtų būti suprantamos kaip apimančios ir papildomas dozes, skiriamas siekiant geriau apsaugoti asmenis, kurių imuninis atsakas užbaigus standartinį pirminio skiepijimo kursą buvo nepakankamas. Laikydamosi Reglamentu (ES) 2021/953 nustatytos teisinės sistemos valstybės narės gali imtis priemonių, kad atsižvelgtų į pažeidžiamų grupių, kurioms papildomos dozės gali būti skiriamos prioriteto tvarka, padėtį. Pavyzdžiui, jei valstybė narė nusprendžia papildomomis dozėmis skiepyti tik konkrečius gyventojų pogrupius, ji, vadovaudamasi Reglamento (ES) 2021/953 5 straipsnio 1 dalimi, gali pasirinkti išduoti skiepijimo pažymėjimus, kuriuose nurodomos šios papildomos dozės, tik pagal prašymą, o ne automatiškai. Jei imamasi tokių priemonių, valstybės narės atitinkamai informuoja susijusius asmenis ir taip pat praneša jiems, kad jie gali toliau naudotis pažymėjimu, gautu užbaigus standartinį pirminio skiepijimo kursą.

▼M1

6.    Valstybė narė arba trečioji valstybė, kurioje buvo paskiepyta arba atliktas tyrimas

Pageidaujama kodų sistema: šalių kodai pagal ISO 3166.

Naudotina 1, 2 ir 3 pažymėjimuose.

Reikšmių rinkinio turinys: išsamus 2 raidžių kodų sąrašas, pateikiamas kaip reikšmių rinkinys, apibrėžtas FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). Jei asmuo paskiepytas arba tyrimas atliktas tarptautinės organizacijos (pvz., UNHCR arba PSO), o informacijos apie šalį nėra, naudojamas atitinkamos organizacijos kodas. Komisija, padedant E. sveikatos tinklui, skelbia ir reguliariai atnaujina šių papildomų kodų sąrašą.

7.    Tyrimo rūšis

Naudotina 2 pažymėjime ir, jei deleguotuoju teisės aktu numatoma galimybė išduoti persirgimo pažymėjimus, grindžiamus ne nukleorūgščių amplifikacijos (NRA) tyrimais, o kitų rūšių tyrimais, 3 pažymėjime.

Naudojami toliau nurodyti kodai.

▼M4

Kodas LP217198-3 (greitasis imunologinis tyrimas) naudojamas ir greitiesiems antigenų testams, ir laboratorijoje atliekamiems antigenų tyrimams nurodyti.

▼M1

8.    Naudoto testo gamintojas ir komercinis pavadinimas (neprivaloma NRA testų atveju)

Naudotina 2 pažymėjime.

▼M4

Reikšmių rinkinį sudaro antigenų testai, išvardyti bendrame atnaujintame COVID-19 antigenų testų sąraše, sudarytame remiantis Tarybos rekomendacija 2021/C 24/01, kuriam pritarė Sveikatos saugumo komitetas. Šį sąrašą tvarko Jungtinis tyrimų centras (JRC), naudodamas COVID-19 in vitro diagnostikos prietaisų ir tyrimo metodų duomenų bazę: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

▼M1

Šioje kodų sistemoje naudojami atitinkami laukeliai, pvz., testo priemonės identifikatorius, testo pavadinimas ir gamintojas, pagal JRC nustatytos struktūros formatą, kuris pateikiamas adresu https://covid-19-diagnostics.jrc.ec.europa.eu/devices.

9.    Tyrimo rezultatas

Naudotina 2 pažymėjime.

Naudojami šie kodai:

▼B

---

III PRIEDAS

BENDRA UNIKALAUS PAŽYMĖJIMO IDENTIFIKATORIAUS STRUKTŪRA

1.    Įžanga

Kiekviename ES skaitmeniniame COVID pažymėjime (SCP) turi būti unikalus pažymėjimo identifikatorius (UPI), užtikrinantis SCP sąveikumą. UPI gali būti naudojamas pažymėjimui patikrinti. Valstybės narės yra atsakingos už UPI įgyvendinimą. UPI – tai priemonė pažymėjimo tikrumui patikrinti ir, jei taikoma, susieti su registravimo sistema (pvz., IIS). Šie identifikatoriai taip pat sudaro sąlygas valstybėms narėms (popierine ir skaitmenine forma) patvirtinti, kad asmenys buvo paskiepyti arba ištirti.

2.    Unikalaus pažymėjimo identifikatoriaus sudėtis

UPI turi atitikti bendrą struktūrą ir formatą, lengvinantį informacijos aiškinimą žmogui ir (arba) mašinoms, ir gali būti susijęs su tokiais elementais kaip skiepijimo valstybė narė, pati vakcina ir valstybei narei būdingas identifikatorius. Taip valstybėms narėms užtikrinamas lankstumas jį formuojant, visapusiškai laikantis duomenų apsaugos teisės aktų. Atskirų elementų eiliškumas atitinka nustatytą hierarchiją, pagal kurią ateityje galima keisti blokus, išlaikant jų struktūrinį vientisumą.

Galimais UPI sudėties sprendimais suformuojamas spektras, kurio du pagrindiniai varijuojantys parametrai ir viena iš esminių savybių yra moduliškumas ir žmonių gebėjimas jį suprasti:

▼M1

3.    Bendrieji reikalavimai

Laikomasi toliau išvardytų bendrųjų reikalavimų, susijusių su UPI:

Užtikrinamas atgalinis suderinamumas: valstybės narės, kurios ilgainiui pakeičia savo identifikatorių struktūrą (pagal pagrindinę versiją – šiuo metu 1-ą versiją), užtikrina, kad bet kokie du identiški identifikatoriai reikštų tą patį skiepijimo pažymėjimą ir (arba) patvirtinimą. Kitaip tariant, valstybės narės negali pakartotinai naudoti identifikatorių.

▼B

4.    Skiepų pažymėjimų unikalių pažymėjimo identifikatorių parinktys

E. sveikatos tinklo gairėse dėl patikrinamų skiepų pažymėjimų ir pagrindinių sąveikumo elementų ( 17 ) numatytos įvairios parinktys, kuriomis gali naudotis valstybės narės ir kitos šalys ir kurios gali egzistuoti kartu skirtingose valstybėse narėse. Valstybės narės gali taikyti tokias skirtingas parinktis skirtingose UPI schemos versijose.

---

IV PRIEDAS

VIEŠOJO RAKTO SERTIFIKATO VALDYMAS

1.    Įžanga

Saugus ir patikimas keitimasis ES skaitmeninių COVID pažymėjimų (SCP) parašo raktais tarp valstybių narių vykdomas per ES skaitmeninio COVID pažymėjimo tinklų sietuvą (SCPTS), kuris veikia kaip centrinė viešųjų raktų saugykla. Naudodamos SCPTS, valstybės narės turi teisę skelbti viešuosius raktus, atitinkančius privačiuosius raktus, kuriuos jos naudoja COVID skaitmeniniams pažymėjimams pasirašyti. Pasikliaujančios valstybės narės gali naudotis SCPTS, kad laiku gautų naujausią viešojo rakto medžiagą. Vėliau SCPTS gali būti išplėstas, kad būtų galima keistis patikima papildoma informacija, kurią pateikia valstybės narės, pavyzdžiui, SCP patvirtinimo taisyklėmis. SCP sistemos patikimumo modelis yra viešojo rakto infrastruktūra. Kiekviena valstybė narė turi vieną ar daugiau parašą patvirtinančių šalies sertifikavimo įstaigų (CSCA), kurių sertifikatai galioja gana ilgai. Valstybės narės sprendimu, CSCA gali būti ta pati arba kita nei mašininio nuskaitymo kelionės dokumentams naudojama CSCA. CSCA išduoda nacionaliniams trumpalaikiams dokumentų pasirašytojams (t. y. SCP pasirašytojams) viešojo rakto skaitmeninius sertifikatus, kurie vadinami dokumento pasirašytojo sertifikatais (DSC). CSCA veikia kaip patikimumo užtikrinimo priemonė, todėl ja besiremiančios valstybės narės gali naudoti CSCA sertifikatą reguliariai keičiamų DSC autentiškumui ir vientisumui patvirtinti. Patvirtintus sertifikatus (arba tik juose esančius viešuosius raktus) valstybės narės gali pateikti savo SCP patvirtinimo programoms. Be CSCA ir DSC, SCPTS taip pat remiasi viešojo rakto infrastruktūra sandorių autentiškumui nustatyti, duomenims pasirašyti, kaip pagrindu autentiškumui nustatyti ir valstybių narių ir SCPTS ryšių kanalų vientisumui užtikrinti.

Skaitmeniniai parašai gali būti naudojami duomenų vientisumui ir autentiškumui užtikrinti. Viešojo rakto infrastruktūra užtikrina patikimumą, susiedama viešuosius raktus su patikrintomis tapatybėmis (arba išdavėjais). Tai būtina, kad kiti dalyviai galėtų patikrinti duomenų kilmę ir ryšio partnerio tapatybę ir nuspręsti dėl patikimumo. SCPTS autentiškumui patvirtinti naudojami keli viešojo rakto sertifikatai. Šiame priede apibrėžiama, kokie viešojo rakto sertifikatai yra naudojami ir kaip jie turi būti sukurti, kad valstybės narės galėtų užtikrinti išsamų sąveikumą. Jame pateikiama daugiau informacijos apie būtinus viešojo rakto sertifikatus, o valstybėms narėms, norinčioms naudoti savo CSCA, pateikiamos rekomendacijos dėl pažymėjimo šablonų ir galiojimo laikotarpių. Kadangi SCP patikrinamumas turi būti užtikrinamas apibrėžtu laikotarpiu (nuo išdavimo iki galiojimo po tam tikro laiko), būtina nustatyti visų parašų, taikomų viešojo rakto sertifikatams ir SCP, tikrinimo modelį.

2.    Terminai

Toliau lentelėje pateikiamos šiame priede vartojamos santrumpos ir terminai.

3.    SCPTS ryšių srautai ir apsaugos paslaugos

Šiame skirsnyje apžvelgiami SCPTS sistemos ryšių srautai ir apsaugos paslaugos. Jame taip pat apibrėžiama, kokie raktai ir sertifikatai naudojami ryšiui, įkeltai informacijai, SCP ir pasirašytam patikimumo sąrašui, kuriame yra visi įkelti CSCA sertifikatai, apsaugoti. SCPTS veikia kaip duomenų centras, kuriame galima keistis valstybių narių pasirašytais duomenų paketais.

Įkeltus duomenų paketus SCPTS pateikia nepakeistus, t. y. SCPTS į gautus paketus DSC neprideda ir jų nepašalina. Valstybių narių nacionalinėje galinėje sistemoje turi būti galimybė patikrinti įkeltų duomenų vientisumą ir autentiškumą. Be to, nacionalinėse galinėse sistemoje ir SCPTS saugiam ryšiui užmegzti naudojamas abipusis TLS autentiškumo patvirtinimas. Tai yra papildoma priemonė šalia parašų duomenyse, kuriais keičiamasi.

3.1.    Autentiškumo nustatymas ir ryšio užmezgimas

SCPTS naudoja perkėlimo lygmens saugumo (TLS) protokolą su abipusio autentiškumo patvirtinimu patvirtinto autentiškumo šifruotam kanalui tarp valstybės narės nacionalinės galinės sistemos (NB) ir tinklų sietuvo aplinkos sukurti. Todėl SCPTS suteiktas TLS serverio sertifikatas – SCPTSTLS, o nacionalinėms galinėms sistemoms suteiktas TLS kliento sertifikatas – NBTLS. Skaitmeninių sertifikatų šablonai pateikti 5 skirsnyje. Kiekviena nacionalinė galinė sistema gali pateikti savo TLS sertifikatą. Šis sertifikatas bus aiškiai įtrauktas į baltąjį sąrašą, todėl jį gali išduoti viešai patikima sertifikavimo įstaiga (pavyzdžiui, sertifikavimo įstaiga, kuri laikosi „CA Browser Forum“ pagrindinių reikalavimų), nacionalinė sertifikavimo įstaiga arba jis gali būti pasirašytas savarankiškai. Kiekviena valstybė narė yra atsakinga už savo nacionalinius duomenis ir privačiojo rakto, naudojamo ryšiui su SCPTS užmegzti, apsaugą. Taikant nuosavo sertifikato naudojimo metodą reikia aiškiai apibrėžto registravimo ir identifikavimo proceso, taip pat atšaukimo ir atnaujinimo procedūrų, kaip aprašyta 4.1, 4.2 ir 4.3 skirsniuose. SCPTS naudojamas baltasis sąrašas, į kurį po sėkmingos registracijos įtraukiami nacionalinių vidinių serverių TLS sertifikatai. Saugų ryšį su SCPTS gali užmegzti tik tie nacionaliniai vidiniai serveriai, kurie autentiškumą patvirtina privačiuoju raktu, atitinkančiu į baltąjį sąrašą įtrauktą sertifikatą. SCPTS taip pat naudos TLS sertifikatą, pagal kurį nacionaliniai vidiniai serveriai gali patikrinti, ar jie iš tikrųjų užmezga ryšį su „tikruoju“ SCPTS, o ne su kokiu nors piktybišku subjektu, besidedančiu SCPTS. Sėkmingai užsiregistravus, nacionaliniam vidiniam serveriui bus suteiktas SCPTS sertifikatas. SCPTSTLS skaitmeninį sertifikatą išduoda viešai patikima sertifikavimo institucija (įtraukta į visas pagrindines naršykles). Valstybės narės privalo patikrinti, ar jų ryšys su SCPTS yra saugus (pavyzdžiui, patikrinti, ar serverio, prie kurio jungiamasi, SCPTSTLS sertifikato pirštų atspaudas atitinka po registracijos pateiktą pirštų atspaudą).

3.2.    Parašą patvirtinančios šalies sertifikavimo įstaigos ir patvirtinimo modelis

SCPTS sistemoje dalyvaujančios valstybės narės DSC išduoti turi naudoti CSCA. Valstybės narės gali turėti daugiau nei vieną CSCA, pavyzdžiui, regioninės decentralizacijos atveju. Kiekviena valstybė narė gali naudotis esamomis sertifikavimo institucijomis arba gali įsteigti specialią sertifikavimo instituciją SCP sistemai (kuri galbūt pasirašo sertifikatus savarankiškai).

Valstybės narės turi pateikti savo CSCA sertifikatą (-us) SCPTS operatoriui per oficialią prisijungimo procedūrą. Po sėkmingos valstybės narės registracijos (daugiau informacijos žr. 4.1 skirsnį) SCPTS operatorius atnaujins pasirašytą patikimumą sąrašą, kuriame yra visi į SCP sistemą įtraukti CSCA sertifikatai. SCPTS operatorius naudos specialią asimetrinių raktų porą patikimumo sąrašui ir skaitmeniniams sertifikatams pasirašyti neprisijungus prie interneto. Privatusis raktas nebus saugomas SCPTS internetinėje sistemoje, kad įsilaužėlis, įsilaužęs į internetinę sistemą, negalėtų pasiekti patikimumo sąrašo. Atitinkamas patikimumo užtikrinimo priemonės sertifikatas SCPTSTA bus pateiktas nacionalinėms galinėms sistemoms prisijungimo metu.

Valstybės narės iš SCPTS gali gauti patikimumą sąrašą, kad galėtų atlikti patikrinimo procedūras. CSCA apibrėžiama kaip DSC išduodanti sertifikavimo institucija, todėl valstybės narės, naudojančios daugiapakopę sertifikavimo įstaigų hierarchiją (pvz., pagrindinė sertifikavimo įstaiga -> CSCA -> DSC), turi nurodyti pavaldžią sertifikavimo įstaigą, išduodančią DSC. Tokiu atveju, jei valstybė narė naudoja esamą sertifikavimo įstaigą, SCP sistema ignoruos visas virš CSCA esančias įstaigas ir į baltąjį sąrašą kaip patikimumo užtikrinimo priemonę įtrauks tik CSCA (net jei ji yra pavaldžioji sertifikavimo įstaiga). Taip yra todėl, kad pagal ICAO modelį galima taikyti tik 2 lygmenis – pagrindinę CSCA ir „lapo“ DSC, kurį pasirašė tik ta CSCA.

Jei valstybė narė turi savo CSCA, ji yra atsakinga už saugų šios sertifikavimo įstaigos veikimą ir raktų valdymą. CSCA veikia kaip DSC patikimumo užtikrinimo priemonė, todėl CSCA privačiojo rakto apsauga yra labai svarbi siekiant užtikrinti SCP aplinkos vientisumą. SCP viešojo rakto infrastruktūros tikrinimo modelis yra karkaso modelis, kuriuo užtikrinama, kad visi sertifikato maršruto tvirtinimo sertifikatai turi galioti konkrečiu laiku (t. y. tvirtinant parašą). Todėl taikomi šie apribojimai:

4.2 skirsnyje pateikiamos rekomendacijos dėl galiojimo laikotarpių.

3.3.    Įkeltų duomenų vientisumas ir autentiškumas

Nacionalinės galinės sistemos gali naudoti SCPTS, kad įkeltų ir parsisiųsdintų skaitmeniniu būdu pasirašytus duomenų paketus po sėkmingo abipusio autentiškumo patvirtinimo. Iš pradžių šiuose duomenų paketuose pateikiami valstybių narių DSC. Raktų pora, kurią nacionalinė galinė sistema naudoja skaitmeniniam įkeltų duomenų paketų pasirašymui SCPTS sistemoje, vadinama nacionalinio vidinio serverio įkeltų duomenų pasirašymo raktų pora, o atitinkamas viešojo rakto skaitmeninis sertifikatas sutrumpintai vadinamas NBUP sertifikatu. Kiekviena valstybė narė turi savo NBUP sertifikatą, kuris gali būti savarankiškai pasirašytas pati arba kurį išduoda esama sertifikavimo įstaiga, pavyzdžiui, viešoji sertifikavimo įstaiga (t. y. sertifikavimo įstaiga, išduodanti sertifikatus pagal „CAB-Forum“ pagrindinius reikalavimus). NBUP sertifikatas turi skirtis nuo visų kitų valstybės narės naudojamų sertifikatų (t. y. CSCA, TLS kliento ar DSC).

Valstybės narės turi pateikti įkėlimo sertifikatą SCPTS operatoriui pirminės registracijos procedūros metu (daugiau informacijos žr. 4.1 skirsnį). Kiekviena valstybė narė yra atsakinga už savo nacionalinius duomenis ir privalo apsaugoti privatųjį raktą, naudojamą įkeltiems dokumentams pasirašyti.

Kitos valstybės narės gali patikrinti pasirašytus duomenų paketus naudodamos SCPTS pateiktus duomenų įkėlimo sertifikatus. SCPTS patikrina įkeltų duomenų autentiškumą ir vientisumą naudodamas nacionalinio vietinio serverio įkėlimo sertifikatą, prieš juos pateikiant kitoms valstybėms narėms.

3.4.    Techninės SCPTS architektūros reikalavimai

Techninei SCPTS architektūrai keliami šie reikalavimai:

4.    Sertifikato gyvavimo ciklo valdymas

4.1.    Nacionalinių galinių sistemų registravimas

Norėdamos dalyvauti SCPTS sistemoje, valstybės narės turi užsiregistruoti per SCPTS operatorių. Šiame skirsnyje aprašoma techninė ir veiklos procedūra, kurios reikia laikytis norint užregistruoti nacionalinę galinę sistemą.

SCPTS operatorius ir valstybė narė turi keistis informacija apie techninius kontaktinius asmenis, atsakingus už prisijungimo prie sistemos procesą. Daroma prielaida, kad techninius kontaktinius asmenis įteisina jų valstybės narės, o tapatybės nustatymas ir (arba) autentiškumo patvirtinimas atliekamas kitais kanalais. Pavyzdžiui, autentiškumo patvirtinimas gali būti atliekamas, kai valstybės narės techninis kontaktinis asmuo e. paštu pateikia sertifikatus kaip slaptažodžiu užšifruotas rinkmenas ir telefonu perduoda atitinkamą slaptažodį SCPTS operatoriui. Taip pat gali būti naudojami kiti saugūs kanalai, kuriuos nustato SCPTS operatorius.

Registravimo ir identifikavimo proceso metu valstybė narė turi pateikti tris skaitmeninius sertifikatus:

Visi pateikti sertifikatai turi atitikti 5 skirsnyje nustatytus reikalavimus. SCPTS operatorius patikrins, ar pateiktas sertifikatas atitinka 5 skirsnio reikalavimus. Po identifikavimo ir registracijos SCPTS operatorius:

4.2.    Sertifikavimo įstaigos, galiojimo laikotarpiai ir atnaujinimas

Jei valstybė narė nori naudoti savo CSCA, šios įstaigos skaitmeniniai sertifikatai gali būti savarankiškai pasirašyti sertifikatai. Jie veikia kaip valstybės narės patikimumo užtikrinimo priemonė, todėl valstybė narė turi griežtai saugoti privatųjį raktą, atitinkantį CSCA sertifikato viešąjį raktą. Rekomenduojama, kad valstybės narės savo CSCA naudotų sistemą neprisijungus, t. y. kompiuterinę sistemą, kuri nėra prijungta prie jokio tinklo. Prieigai prie sistemos turi būti naudojama kelių asmenų kontrolė (pvz., pagal keturių akių principą). Pasirašius DSC, taikoma veiklos kontrolė, o sistema, kurioje saugomas privatusis CSCA raktas, saugoma taikant griežtą prieigos kontrolę. CSCA privačiajam raktui papildomai apsaugoti galima naudoti aparatinius saugumo modulius arba lustines korteles. Skaitmeniniuose sertifikatuose nurodytas galiojimo laikotarpis, kuriuo užtikrinamas sertifikato atnaujinimas. Atnaujinimas būtinas norint naudoti naujus kriptografinius raktus ir pritaikyti raktų dydžius, kai nauji skaičiavimo patobulinimai arba naujos atakos kelia grėsmę naudojamo kriptografinio algoritmo saugumui. Taikomas karkaso modelis (žr. 3.2 skirsnį).

Atsižvelgiant į tai, kad skaitmeniniai COVID pažymėjimai galioja vienus metus, rekomenduojami šie galiojimo laikotarpiai:

Kad informacija būtų atnaujinta laiku, rekomenduojama nustatyti šiuos privačiųjų raktų naudojimo laikotarpius:

Valstybės narės turi laiku, pavyzdžiui, likus mėnesiui iki galiojimo pabaigos, sukurti naujus įkėlimo sertifikatus ir TLS sertifikatus, kad būtų užtikrintas sklandus veikimas. CSCA sertifikatai ir DSC turėtų būti atnaujinami likus ne mažiau kaip mėnesiui iki privačiojo rakto naudojimo pabaigos (atsižvelgiant į būtinas veiklos procedūras). Valstybės narės SCPTS operatoriui turi pateikti atnaujintus CSCA, įkėlimo ir TLS sertifikatus. Nebegaliojantys sertifikatai išbraukiami iš baltųjų ir patikimumo sąrašų.

Valstybės narės ir SCPTS operatorius turi stebėti savo sertifikatų galiojimą. Nėra centrinio subjekto, kuris saugotų įrašus apie sertifikato galiojimą ir informuotų dalyvius.

4.3.    Sertifikatų atšaukimas

Paprastai skaitmeninius sertifikatus gali atšaukti juos išdavusi sertifikavimo įstaiga, naudodama sertifikatų atšaukimo sąrašus arba internetinį sertifikatų būsenos protokolo atsakiklį (OCSP). SCP sistemai CSCA turėtų pateikti sertifikatų atšaukimo sąrašus (CRL). Net jei šiuo metu šių CRL nenaudoja kitos valstybės narės, jie turėtų būti integruoti į būsimas programas. Jei CSCA nusprendžia neteikti CRL, tokios įstaigos DSC turi būti atnaujinti, kai CRL taps privalomi. Tikrintojai neturėtų naudoti OCSP dokumentų pasirašymo sertifikatams (DSC) patvirtinti; vietoje to, jie turėtų naudoti CRL. Rekomenduojama, kad nacionalinė galinė sistema atliktų būtiną iš SCPTS parsisiųsdintų DSC patvirtinimą ir tik patikimų ir patvirtintų DSC rinkinį perduotų nacionaliniams SCP tvirtintojams. SCP tvirtintojai neturėtų atlikti jokio DSC atšaukimo tikrinimo. Viena iš priežasčių – apsaugoti SCP turėtojų privatumą išvengiant bet kokios galimybės, kad bet kurio konkretaus DSC naudojimą gali stebėti su juo susijęs OCSP atsakiklis.

Valstybės narės gali pačios pašalinti savo DSC iš SCPTS, naudodamos galiojančius įkėlimo ir TLS sertifikatus. DSC pašalinimas reiškia, kad visi jį naudojant išduoti SCP taps negaliojantys, kai valstybės narės gaus atnaujintus DSC sąrašus. Labai svarbu apsaugoti DSC atitinkančią privačiojo rakto medžiagą. Valstybės narės turi informuoti SCPTS operatorių, kai jos turi atšaukti įkėlimo arba TLS sertifikatus, pavyzdžiui, dėl nacionalinės galinės sistemos saugumo pažeidimo. Tuomet SCPTS operatorius gali panaikinti pažeisto sertifikato patikimumą, pavyzdžiui, išbraukti jį iš TLS baltojo sąrašo. SCPTS operatorius gali pašalinti įkėlimo sertifikatus iš SCPTS duomenų bazės. Paketai, pasirašyti privačiuoju raktu, atitinkančiu šį įkėlimo sertifikatą, taps negaliojantys, kai nacionalinės galinės sistemos panaikins atšaukto įkėlimo sertifikato patikimumą. Jei CSCA sertifikatas turi būti atšauktas, valstybės narės informuoja SCPTS operatorių ir kitas valstybes nares, su kuriomis jas sieja patikimumo santykiai. SCPTS operatorius išduos naują patikimumo sąrašą, kuriame nebebus paveikto sertifikato. Visi šios CSCA išduoti DSC taps negaliojantys, kai valstybės narės atnaujins savo nacionalinės galinės sistemos patikimumo saugyklą. Jei reikia atšaukti SCPTSTLS arba SCPTSTA sertifikatą, SCPTS operatorius ir valstybės narės turi bendradarbiauti, kad užmegztų naują patikimą TLS ryšį ir sukurtų patikimumo sąrašą.

5.    Sertifikatų šablonai

Šiame skirsnyje nustatomi kriptografiniai reikalavimai ir rekomendacijos, taip pat sertifikatų šablonams taikomi reikalavimai. Šiame skyriuje taip pat apibrėžiami SCPTS pažymėjimų šablonai.

5.1.    Kriptografiniai reikalavimai

Kriptografiniai algoritmai ir TLS šifrų rinkiniai pasirenkami pagal dabartines Vokietijos federalinio informacijos saugumo biuro (BSI) arba vyresniųjų pareigūnų grupės informacinių sistemų klausimais (SOG-IS) sistemos rekomendacijas. Šios ir kitų institucijų bei standartizacijos organizacijų rekomendacijos yra panašios. Rekomendacijas galima rasti techninėse gairėse TR 02102-1 ir TR 02102-2 ( 18 ) arba SOG-IS suderintuose kriptografiniuose mechanizmuose ( 19 ).

5.1.1.    DSC taikomi reikalavimai

Taikomi I priedo 3.2.2 skirsnyje nustatyti reikalavimai. Todėl dokumentus pasirašantiems asmenims primygtinai rekomenduojama naudoti elipsinės kreivės skaitmeninio parašo algoritmą (ECDSA) su NIST-p-256 (kaip apibrėžta FIPS PUB 186-4 D priede). Kitos elipsinės kreivės nepalaikomos. Dėl SCP vietos apribojimų valstybės narės neturėtų naudoti RSA-PSS, net jei jis leidžiamas kaip atsarginis algoritmas. Jei valstybės narės naudoja RSA-PSS, jos turėtų naudoti 2048 bitų arba ne didesnį kaip 3072 bitų modulį. DSC parašui, kaip kriptografinė maišos funkcija, naudojamas SHA-2, kurio išvesties ilgis ≥ 256 bitai (žr. ISO/IEC 10118-3:2004).

5.1.2.    Reikalavimai, taikomi perkėlimo lygmens saugumo, įkėlimo ir CSCA sertifikatams

Skaitmeniniams sertifikatams ir kriptografiniams parašams aktualūs SCPTS taikomi pagrindiniai reikalavimai kriptografiniams algoritmams ir rakto ilgiui apibendrinti toliau pateiktoje lentelėje (2021 m.):

Dėl plataus įgyvendinimo rekomenduojama EC-DSA elipsinė kreivė yra NIST-p-256.

5.2.    CSCA sertifikatas (NBCSCA)

Toliau pateiktoje lentelėje pateikiamos rekomendacijos dėl NBCSCA sertifikato šablono, jei valstybė narė nusprendžia SCP sistemoje naudoti savo CSCA.

Įrašai paryškintu šriftu yra privalomi (turi būti įtraukti į sertifikatą), įrašai kursyvu yra rekomenduojami (turėtų būti įtraukti). Dėl nesamų laukelių rekomendacijos nenustatytos.

Objekto pavadinimo laukelis nurodytoje valstybėje narėje turi būti ne tuščias ir unikalus. Šalies kodas (c) turi sutapti su valstybe nare, kuri naudos šį CSCA sertifikatą. Sertifikate turi būti unikalus objekto rakto identifikatorius (SKI) pagal RFC 5280 ( 20 ).

5.3.    Dokumento pasirašytojo sertifikatas (DSC)

Toliau pateiktoje lentelėje pateikiamos DSC gairės. Įrašai paryškintu šriftu yra privalomi (turi būti įtraukti į sertifikatą), įrašai kursyvu yra rekomenduojami (turėtų būti įtraukti). Dėl nesamų laukelių rekomendacijos nenustatytos.

DSC turi būti pasirašytas privačiuoju raktu, atitinkančiu valstybės narės naudojamą CSCA sertifikatą.

Turi būti naudojami šie plėtiniai:

Be to, sertifikate turėtų būti CRL skirstomojo taško plėtinys, nukreipiantis į sertifikatų atšaukimo sąrašą (CRL), kurį pateikia DSC išdavusi CSCA.

DSC gali būti naudojamas išplėstinis rakto plėtinys su nuliu ar daugiau rakto naudojimo politikos identifikatorių, kurie apriboja HCERT tipus, kuriuos leidžiama tikrinti šiuo sertifikatu. Jei jų yra vienas ar daugiau, tikrintojai patikrina rakto naudojimą pagal saugomą HCERT. Šiuo atveju nustatomos šios išplėstinio rakto naudojimo vertės:

Jei nėra jokio rakto naudojimo plėtinio (t. y. jokių plėtinių ar nulinių plėtinių), šis sertifikatas gali būti naudojamas bet kokio tipo HCERT patvirtinti. Kituose dokumentuose gali būti apibrėžti atitinkami papildomi išplėstinių raktų naudojimo politikos identifikatoriai, naudojami tvirtinant HCERT.

5.4.    Įkėlimo sertifikatai (NBUP)

Toliau pateiktoje lentelėje pateikiamos nacionalinės galinės sistemos įkėlimo sertifikato gairės. Įrašai paryškintu šriftu yra privalomi (turi būti įtraukti į sertifikatą), įrašai kursyvu yra rekomenduojami (turėtų būti įtraukti). Dėl nesamų laukelių rekomendacijos nenustatytos.

5.5.    Nacionalinės galinės sistemos TLS kliento autentiškumo nustatymas (NBTLS)

Toliau pateiktoje lentelėje pateikiamos nacionalinės galinės sistemos TLS kliento autentiškumo nustatymo sertifikato gairės. Įrašai paryškintu šriftu yra privalomi (turi būti įtraukti į sertifikatą), įrašai kursyvu yra rekomenduojami (turėtų būti įtraukti). Dėl nesamų laukelių rekomendacijos nenustatytos.

Sertifikate taip pat gali būti naudojamas išplėstinis raktas – serverio autentiškumo patvirtinimas (1.3.6.1.5.5.7.3.1), – tačiau jis nebūtinas.

5.6.    Patikimumo sąrašo parašo sertifikatas (SCPTSTA)

Toliau pateiktoje lentelėje apibrėžiamas SCPTS sertifikatas su patikimumo užtikrinimo priemone.

5.7.    SCPTS TLS serverio sertifikatai (SCPTSTLS)

Toliau pateiktoje lentelėje apibrėžiamas SCPTS TLS sertifikatas.

Sertifikate taip pat gali būti naudojamas išplėstinis raktas – serverio autentiškumo patvirtinimas (1.3.6.1.5.5.7.3.2), – tačiau jis nebūtinas.

SCPTS TLS sertifikatą turi išduoti viešai patikima sertifikavimo įstaiga (įtraukta į visas pagrindines naršykles ir operacines sistemas pagal „CAB Forum“ bazinius reikalavimus).

▼M1

---

V PRIEDAS

JSON FORMATO SCHEMA

1.    Įžanga

Šiame priede nustatoma ES skaitmeninių COVID pažymėjimų (ES SCP) techninių duomenų struktūra, pateikiama kaip JSON formato schema. Dokumente pateikiami konkretūs nurodymai dėl atskirų duomenų laukelių.

2.    JSON formato schemos šaltinis ir versijos

Pirminė ir oficiali ES SCP JSON formato schema pateikiama adresu https://github.com/ehn-dcc-development/ehn-dcc-schema. Kiti šaltiniai nėra pirminiai, bet gali būti naudojami patikslintoms versijoms parengti.

Nurodytu URL adresu kaip numatytoji parinktis pateikiama esama, šiame priede nustatyta versija, naudojama visų šiuo metu ES SCP diegiančių šalių.

Būsima nauja versija, kurią iki nustatytos datos pradės naudoti visos šalys, pateikiama nurodytu URL adresu ženklinant versijas (išsamiau aprašyta faile „Readme“).

▼M3

3.    Bendros struktūros ir bendrieji reikalavimai

ES skaitmeninis COVID pažymėjimas neišduodamas, jei dėl trūkstamos informacijos ne visi duomenų laukeliai gali būti tinkamai užpildyti pagal šias specifikacijas. Tai nedaro poveikio valstybių narių pareigai išduoti ES skaitmeninius COVID pažymėjimus.

Informacija visuose laukeliuose gali būti pateikiama naudojant visą UTF-8 koduote užkoduotų UNICODE 13.0 ženklų rinkinį, išskyrus konkrečius atvejus, kuriais leidžiama naudoti tik tam tikrus reikšmių rinkinius arba mažesnius ženklų rinkinius.

Naudojama ši bendra struktūra:

„JSON“:{

„ver“:<version information>,

„nam“:{

<person name information>

},

„dob“:<date of birth>,

„v“ or „t“ or „r“:[

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

]

}

Išsamesnė informacija apie atskiras grupes ir laukelius pateikiama tolesniuose skirsniuose.

Jei taisyklėse nurodyta, kad laukelis praleidžiamas, tai reiškia, kad jo turinys turi būti tuščias ir jame negali būti nurodytas nei laukelio pavadinimas, nei jo reikšmė.

3.1.    Versija

Pateikiama informacija apie versiją. Versijos nurodomos pagal semantinio versijų žymėjimo sistemą (semver: https://semver.org). Praktiškai naudojama viena iš oficialiai paskelbtų (naujausia arba viena iš senesnių oficialiai paskelbtų) versijų. Daugiau informacijos pateikiama skirsnyje apie JSON formato schemos šaltinį.

3.2.    Asmenvardis ir gimimo data

Asmenvardis – visas oficialus asmenvardis, sutampantis su nurodytuoju kelionės dokumentuose. Struktūros identifikatorius – nam. Pateikiamas tik 1 (vienas) asmenvardis.

3.3.    Konkrečios rūšies pažymėjimuose pateikiamos informacijos grupės

JSON formato schemoje numatytos trys konkrečios rūšies pažymėjimuose pateikiamą informaciją apimančios įrašų grupės. Kiekviename ES SCP turi būti naudojama tik 1 (viena) grupė. Ji negali būti tuščia.

▼M1

4.    Konkrečios rūšies pažymėjimo informacija

4.1.    Skiepijimo pažymėjimas

Skiepijimo informacijos grupėje, jei ji naudojama, privalomas 1 (vienas) įrašas apie vieną skiepijimo atvejį (viena dozė). Visi skiepijimo informacijos grupės elementai yra privalomi, negalima naudoti tuščių reikšmių.

4.2.    Tyrimo rezultatų pažymėjimas

Jei naudojama tyrimo informacijos grupė, privalomas 1 (vienas) įrašas apie vieno tyrimo rezultatą.

4.3.    Persirgimo pažymėjimas

Jei naudojama persirgimo informacijos grupė, privalomas 1 (vienas) įrašas apie vieno persirgimo atvejį. Visi persirgimo informacijos grupės elementai yra privalomi, negalima naudoti tuščių reikšmių.

▼M3

---

VI PRIEDAS

VALSTYBIŲ NARIŲ, KAIP BENDRŲ DUOMENŲ VALDYTOJŲ, KURIOS VALDO PER ES SKAITMENINIO COVID PAŽYMĖJIMO TINKLŲ SIETUVĄ PERDUODAMUS DUOMENIS SIEKDAMOS KEISTIS PANAIKINTŲ ES SCP SĄRAŠAIS, ATSAKOMYBĖ

1 SKIRSNIS

1 poskirsnis

Atsakomybės pasidalijimas

2 poskirsnis

Su duomenų subjektų prašymų nagrinėjimu ir duomenų subjektų informavimu susijusi atsakomybė ir funkcijos

2 SKIRSNIS

Saugumo incidentų, įskaitant asmens duomenų saugumo pažeidimus, valdymas

3 SKIRSNIS

Poveikio duomenų apsaugai vertinimas

---

VII PRIEDAS

KOMISIJOS, KAIP DUOMENŲ TVARKYTOJOS, KURI TVARKO PER ES SKAITMENINIO COVID PAŽYMĖJIMO TINKLŲ SIETUVĄ PERDUODAMUS DUOMENIS SIEKDAMA PADĖTI KEISTIS PANAIKINTŲ ES SCP SĄRAŠAIS, ATSAKOMYBĖ

Komisija:

---

( 1 ) rfc8392 (ietf.org).

( 2 ) rfc8152 (ietf.org).

( 3 ) rfc8230 (ietf.org).

( 4 ) rfc8392 (ietf.org).

( 5 ) rfc8392 (ietf.org).

( 6 ) rfc7159 (ietf.org).

( 7 ) rfc7049 (ietf.org).

( 8 ) 2021 m. birželio 14 d. Europos Parlamento ir Tarybos reglamentas (ES) 2021/953 dėl sąveikiųjų COVID-19 skiepijimo, tyrimo rezultatų ir persirgimo pažymėjimų (ES skaitmeninis COVID pažymėjimas) išdavimo, tikrinimo ir pripažinimo sistemos, kuria siekiama sudaryti palankesnes sąlygas laisvai judėti COVID-19 pandemijos metu (OL L 211, 2021 6 15, p. 1).

( 9 ) rfc1950 (ietf.org).

( 10 ) rfc1951 (ietf.org).

( 11 ) rfc7517 (ietf.org).

( 12 ) Žr. ir 9.5.1.2 skirsnį, kuriame pateikiami išsamūs API aprašymai.

( 13 ) Nuoroda „nebenaudotina“ reiškia, kad naujose įgyvendinimo priemonėse šio elemento nebebus, tačiau esamose įgyvendinimo priemonėse jis dar bus palaikomas tam tikrą aiškiai nustatytą laikotarpį.

( 14 ) rfc3986 (ietf.org)

( 15 ) Diegdamos QR kodus valstybės narės gali svarstyti galimybę naudoti papildomą simbolių rinkinį, kurio bendras ženklų skaičius neviršija 72 simbolių (įskaitant 27–30 identifikatoriaus simbolių), kitai informacijai perteikti. Šią informaciją turi nurodyti pačios valstybės narės.

( 16 ) Algoritmas „Luhn mod N“ yra algoritmo „Luhn“ plėtinys (vadinamasis algoritmas „mod 10“), kuris tinka skaitmeniniams kodams ir naudojamas, pvz., kredito kortelių kontrolinei sumai apskaičiuoti. Šis plėtinys sudaro sąlygas naudoti algoritmą su bet kokio pagrindo reikšmių sekomis (mūsų atveju – raidžių simboliais).

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

( 18 ) BSI. Techninės gairės TR-02102 (bund.de).

( 19 ) SOG-IS. Patvirtinamieji dokumentai (sogis.eu).

( 20 ) rfc5280 (ietf.org).

( 21 ) rfc5280 (ietf.org).