IV LISA

DIGITAALSERTIFIKAATIDE HALDUS

1. Sissejuhatus

ELi digitaalsete COVID-tõendite (digital COVID certificates, edaspidi „DCC“) signeerimisvõtmete turvaline ja usaldusväärne vahetamine liikmesriikide vahel toimub ELi digitaalse COVID-tõendi lüüsi kaudu (Digital COVID Certificate Gateway, edaspidi „DCCG“), mis toimib avalike võtmete keskse hoidlana. DCCG annab liikmesriikidele võimaluse avaldada avalikud võtmed, mis vastavad nende poolt DCCde allkirjastamiseks kasutatavatele privaatvõtmetele. DCCG-le tuginevad liikmesriigid võivad selle vahendusel hankida kiiresti uusimat avalike võtmete materjali. Hiljem saab DCCGd laiendada, et vahetada liikmesriikide esitatavat usaldusväärset lisateavet, nagu DCCde valideerimisreeglid. COVID-tõendite raamistiku usaldusmudel on avaliku võtme taristu (edaspidi „PKI“). Igal liikmesriigil on üks või mitu riiklikku allkirjastamise sertimiskeskust (Country Signing Certification Authority, edaspidi „CSCA“), kelle sertifikaadid on küllaltki pika kehtivusajaga. Vastavalt liikmesriigi otsusele võib CSCA olla sama nagu masinloetavate reisidokumentide puhul kasutatav CSCA või sellest erineda. CSCA väljastab digitaalsertifikaate riiklikele ja lühiajalistele dokumentide allkirjastajatele (st DCCde allkirjastajatele), mida nimetatakse dokumentide allkirjastaja sertifikaatideks (Document Signer Certificates, edaspidi „DSC“). CSCA toimib ankurvõtmena, nii et sellele tuginevad liikmesriigid saavad kasutada CSCA-sertifikaati korrapäraselt muutuvate DSCde ehtsuse ja tervikluse valideerimiseks. Pärast valideerimist saavad liikmesriigid kasutada nimetatud sertifikaate (või pelgalt neis sisalduvaid avalikke võtmeid) omaenese rakendustes DCCde valideerimiseks. Lisaks CSCAdele ja DSCdele tugineb DCCG tehingute autentimisel ja andmete allkirjastamisel ka PKI-le kui autentimise alusele ja vahendile, millega tagada liikmesriikide ja lüüsi vaheliste sidekanalite terviklus.

Andmete tervikluse ja ehtsuse saavutamiseks saab kasutada digiallkirju. Avalike võtmete ja kontrollitud identiteetide (või väljastajate) sidumisega loovad avaliku võtme taristud usaldusväärsuse. Seda on vaja, et muud osalised saaksid kontrollida andmete päritolu ja sidepartneri identiteeti ning teha usaldamisega seotud otsuseid. DCCG kasutab ehtsuse kinnitamiseks mitut digitaalsertifikaati. Käesolevas lisas määratakse kindlaks, milliseid digitaalsertifikaate kasutatakse ja kuidas need välja töötada, et tagada liikmesriikides nende laialdane koostalitlusvõime. Selles on esitatud üksikasjalikum teave vajalike digitaalsertifikaatide kohta ning antud suuniseid sertifikaadimallide ja kehtivusaja kohta liikmesriikides, kes soovivad käitada omaenese CSCAd. Kuna DCCsid saab kontrollida konkreetse ajavahemiku vältel (alates väljastamisest, aeguvad teatud aja jooksul), on vaja kindlaks määrata kontrollimudel kõigi digitaalsertifikaatidele ja DCCdele lisatavate allkirjade jaoks.

2. Terminoloogia

Järgmises tabelis on esitatud käesolevas lisas kasutatud lühendid ja terminid.

Termin Määratlus Sertifikaat Teise nimega digitaalsertifikaat. X.509 v3 sertifikaat, mis sisaldab avaliku üksuse avalikku võtit CSCA Riiklik allkirjastamise sertimiskeskus DCC ELi digitaalne COVID-tõend Allkirjastatud digitaalne dokument, mis sisaldab teavet vaktsineerimise, testimise või läbipõdemise kohta DCCG ELi digitaalse COVID-tõendi lüüs. Süsteem, mida kasutatakse DSCde vahetamiseks liikmesriikide vahel DCCGTA DCCG ankurvõtme sertifikaat. Sellele vastavat privaatvõtit kasutatakse kõigi CSCA-sertifikaatide allkirjastamiseks vallasrežiimis DCCGTLS DCCG TLSi serveri sertifikaat DSC Dokumendi allkirjastaja sertifikaat. Digitaalsertifikaat, mis kuulub liikmesriigi dokumentide allkirjastajale (näiteks süsteemile, millel on luba DCCsid allkirjastada). Selle sertifikaadi väljastab liikmesriigi CSCA EC-DSA Elliptiliste kõverate digiallkirja algoritm. Elliptilistel kõveratel põhinev krüptoalgoritm allkirjastamiseks Liikmesriik ELi liikmesriik mTLS Vastastikune TLS. Transpordikihi turbeprotokoll, mis kasutab vastastikust autentimist NB Liikmesriigi tagateenistus NBCSCA Liikmesriigi CSCA-sertifikaat (võib olla rohkem kui üks) NBTLS Riikliku tagateenistuse TLS-kliendi autentimissertifikaat NBUP Sertifikaat, mida riiklik tagateenistus kasutab DCCGsse üleslaaditavate andmepakettide allkirjastamiseks PKI Avaliku võtme taristu. Digitaalsertifikaatidele ja sertimiskeskustele tuginev usaldusmudel RSA Asümmeetriline krüptoalgoritm, mis põhineb täisarvu tegurdusel ja mida kasutatakse digiallkirjadeks või asümmeetrilises krüptograafias

3. DCCG andmevood ja turvateenused

Selles punktis antakse ülevaade DCCG süsteemi andmevoogudest ja turvateenustest. Samuti määratletakse selles võtmed ja sertifikaadid, mida kasutatakse, et kaitsta sidet, üleslaaditud teavet, DCCsid ja allkirjastatud usaldusloetelu kõigist kaasatud CSCA-sertifikaatidest. DCCG toimib andmekeskusena, mis võimaldab liikmesriikidel vahetada allkirjastatud andmepakette.

DCCG pakub üleslaaditud andmepakette nende algkujul, mis tähendab, et DCCG ei lisa talle saabunud pakettidele DSCsid ega kustuta sealt neid. Liikmesriikide tagateenistusel on võimalik kontrollida üleslaaditud andmete läbivat terviklust ja ehtsust. Lisaks sellele kasutavad riiklikud tagateenistused ja DCCG vastastikust TLS-autentimist turvalise ühenduse loomiseks. See lisandub vahetatud andmetes leiduvatele allkirjadele.

3.1. Autentimine ja ühenduse loomine

DCCG kasutab transpordikihi vastastikuse autentimisega turvet (TLS), et luua liikmesriigi tagateenistuse ja lüüsikeskkonna vahele autenditud ja krüpteeritud kanal. Seega on DCCG-l TLS-serveri sertifikaat (lühivormis „DCCGTLS“) ja riiklikel tagateenistustel on TLS-kliendi sertifikaat (lühivormis „NBTLS“). Sertifikaatide mallid on esitatud punktis 5. Kõik riiklikud tagateenistused võivad esitada oma TLS-sertifikaadi. See sertifikaat kantakse ühemõtteliselt valgesse nimekirja ja seega võib selle väljastada avalikult usaldatav sertimiskeskus (näiteks sertimiskeskus, kes järgib CA/Browser Forumi põhinõudeid), riiklik sertimiskeskus või see võib olla ise allkirjastatud. Iga liikmesriik vastutab oma riiklike andmete ja DCCGga ühenduse loomiseks kasutatud privaatvõtme kaitse eest. Nn oma sertifikaadi (bring your own certificate) lähenemisviisiks on vaja täpselt määratletud registreerimis- ja identimisprotsessi, samuti tühistamis- ja uuendamismenetlusi, nagu kirjeldatud punktides 4.1 , 4.2 ja 4.3. DCCG kasutab valget nimekirja, kuhu NBde TLS-sertifikaadid lisatakse pärast nende edukat registreerimist. Turvalise ühenduse DCCGga saavad luua ainult need NBd, kes autendivad ennast privaatvõtmega, mis vastab valgesse nimekirja kuuluvale sertifikaadile. Ka DCCG kasutab TLS-sertifikaati, mis võimaldab NBdel kontrollida, et nad loovad tõepoolest ühenduse tegeliku DCCGga, mitte mõne DCCGd teeskleva pahatahtliku üksusega. DCCG sertifikaat antakse NBdele pärast edukat registreerimist. DCCGTLS sertifikaadi väljastab avalikult usaldatav sertimiskeskus (sealhulgas kõigi peamiste brauserite jaoks). Selle eest, et ühendus DCCGga on turvaline, vastutavad liikmesriigid (näiteks võivad nad võrrelda ühendusserveri DCCGTLS sertifikaadi sõrmejälge sellega, mis edastati pärast registreerimist).

3.2. Riiklikud allkirjastamise sertimiskeskused ja valideerimismudel

DCCG raamistikus osalevad liikmesriigid peavad DSCde väljastamiseks kasutama CSCAd. Liikmesriikidel võib olla rohkem kui üks CSCA (näiteks piirkondliku detsentraliseerituse korral). Iga liikmesriik võib kas kasutada olemasolevaid sertimiskeskusi või luua spetsiaalse (võimaluse korral iseallkirjastatud) sertimiskeskuse DCC-süsteemi jaoks.

Ametliku kaasamisprotsessi käigus peavad liikmesriigid esitama oma CSCA-sertifikaadi(d) DCCG käitajale. Pärast liikmesriigi edukat registreerimist (täpsemat teavet vt punkt 4.1) uuendab DCCG käitaja allkirjastatud usaldusloetelu, mis sisaldab kõiki DCC raamistikus aktiivseid CSCA-sertifikaate. DCCG käitaja kasutab spetsiaalset asümmeetrilist võtmepaari, et usaldusloetelu ja sertifikaadid vallaskeskkonnas allkirjastada. Privaatvõtit ei säilitata DCCG sidussüsteemis, nii et sidussüsteemi rikkumine ei anna ründajale võimalust rikkuda usaldusloetelu. Sellele vastav ankurvõtme sertifikaat (DCCGTA) antakse riiklike tagateenistuste käsutusse kaasamisprotsessi käigus.

Liikmesriigid saavad usaldusloetelu oma kontrollimenetluste jaoks DCCG-lt. CSCA on määratletud kui DSCsid väljastav sertimiskeskus ja seega peavad liikmesriigid, kes kasutavad mitmetasandilist sertimiskeskuste hierarhiat (näiteks juursertimiskeskus -> CSCA -> DSCd), esitama DSCsid väljastava alamsertimiskeskuse. Sellisel juhul, see tähendab kui liikmesriik kasutab olemasolevat sertimiskeskust, eirab DCC-süsteem kõike, mis on CSCAst ülalpool, ja paneb valgesse nimekirja ankurvõtmena ainult CSCA (hoolimata sellest, et tegu on alamsertimiskeskusega). See tuleneb asjaolust, et ICAO mudel võimaldab ainult täpselt kaht tasandit – nn juur ehk CSCA ja nn leht ehk DSC, mis on allkirjastatud just selle CSCA poolt.

Juhul kui liikmesriik käitab omaenese CSCAd, vastutab selle sertimiskeskuse turvalise toimimise ja võtmehalduse eest liikmesriik. CSCA toimib DSCde ankurvõtmena ja seega on CSCA privaatvõtme kaitse DCC keskkonna tervikluse seisukohalt keskse tähtsusega. DCC PKI kontrollimudel on kestmudel (shell model), mis deklareerib, et kõik sertifitseerimisahela valideerimiseks kasutatavad sertifikaadid peavad kehtima teataval ajal (st allkirja valideerimise ajal). Seega kehtivad järgmised piirangud:

— CSCA ei väljasta sertifikaate, mille kehtivusaeg on pikem kui sertimiskeskuse enese sertifikaat;

— dokumentide allkirjastaja ei allkirjasta dokumente, mille kehtivusaeg on pikem kui DSC enda oma;

— omaenese CSCAd käitavad liikmesriigid peavad kindlaks määrama oma CSCA ja kõigi väljastatud tõendite kehtivusaja ning kandma hoolt sertifikaatide uuendamise eest.

Punktis 4.2 on esitatud soovitused kehtivusaegade kohta.

3.3. Üleslaaditud andmete terviklus ja ehtsus

Riiklikud tagateenistused saavad DCCGd pärast edukat vastastikust autentimist kasutada selleks, et laadida üles ja alla digitaalselt allkirjastatud andmepakette. Alguses sisaldavad need andmepaketid liikmesriikide DSCsid. Võtmepaari, mida riiklik tagateenistus kasutab DCCG süsteemi üles laaditud andmepakettidele digiallkirjastamiseks, nimetatakse riikliku tagateenistuse üleslaadimisallkirja võtmepaariks ja selle vastava digitaalsertifikaadi lühivorm on NBUP-sertifikaat. Iga liikmesriik kasutab omaenese isiklikku NBUP-sertifikaati, mis võib olla iseallkirjastatud või mille võib olla väljastanud olemasolev sertimiskeskus, näiteks riiklik sertimiskeskus (st vastavalt CA/Browser Forumi põhinõuetele sertifikaate väljastav sertimiskeskus). NBUP-sertifikaat erineb kõigist liikmesriigi kasutatavatest sertifikaatidest (st CSCA, TLSi klient või DSCd).

Liikmesriigid peavad üleslaadimissertifikaadi DCCG käitajale esitama algse registreerimismenetluse käigus (üksikasjalikum teave vt punkt 4.1). Iga liikmesriik vastutab oma riiklike andmete eest ja peab kaitsma üleslaaditud andmete allkirjastamiseks kasutatavat privaatvõtit.

Teised liikmesriigid saavad allkirjastatud andmepakette kontrollida, kasutades DCCG poolt nende käsutusse antud üleslaadimissertifikaate. Enne üleslaaditud andmete edastamist teistele liikmesriikidele kontrollib DCCG selle ehtsust ja terviklust NB üleslaadimissertifikaadi abil.

3.4. DCCG tehnilisele arhitektuurile esitatavad nõuded

DCCG tehnilise arhitektuuri suhtes kehtivad järgmised nõuded.

— DCCG kasutab vastastikust TLS-autentimist, et luua NBdega autenditud ja krüpteeritud ühendus. Seega peab DCCG registreeritud NBTLS kliendisertifikaatide valget nimekirja;

— DCCG kasutab kaht elektroonilist sertifikaati (DCCGTLS ja DCCGTA), millel on kaks eri võtmepaari. DCCGTA võtmepaari privaatvõtit hoitakse vallaskeskkonnas (mitte DCCG siduselementides);

— DCCG peab NBCSCA-sertifikaatide usaldusloetelu, mis on allkirjastatud DCCGTA privaatvõtmega;

— kasutatavad šifrid peavad vastama punkti 5.1 nõuetele.

4. Sertifikaatide elutsükli haldus

4.1. Riiklike tagateenistuste registreerimine

Liikmesriigid peavad DCCG süsteemis osaleva käitaja DCCG juures registreerima. Käesolevas punktis on kirjeldatud tehnilisi toiminguid ja töökorda, mida tuleb järgida riikliku tagateenistuse registreerimiseks.

DCCG käitaja ja liikmesriigid peavad kaasamisprotsessi eesmärgil vahetama teavet tehniliste kontaktisikute kohta. Eeldatakse, et tehnilised kontaktisikud on nende liikmesriigi poolt õiguspäraseks tunnistatud ja identimine/autentimine toimub muude kanalite kaudu. Näiteks võib autentimine toimuda nii, et liikmesriigi tehniline kontaktisik esitab sertifikaadid salasõnaga krüpteeritud failidena e-postiga ja annab vastava salasõna DCCG käitajale telefonitsi. Samuti võib kasutada muid DCCG käitaja poolt kindlaksmääratud turvalisi kanaleid.

Registreerimise ja identimise käigus peab liikmesriik esitama kolm elektroonilist sertifikaati:

— liikmesriigi TLS-sertifikaat NBTLS;

— liikmesriigi üleslaadimissertifikaat NBUP;

— liikmesriigi CSCA-sertifikaat/sertifikaadid NBCSCA.

Kõik esitatud sertifikaadid peavad vastama punktis 5 esitatud nõuetele. DCCG käitaja kontrollib, et esitatud sertifikaat vastab punktis 5 esitatud nõuetele. Pärast identimist ja registreerimist teeb DCCG käitaja järgmist.

— Lisab NBCSCA sertifikaadi(d) usaldusloetellu, mis on allkirjastatud privaatvõtmega, mis vastab DCCGTA avalikule võtmele;

— lisab NBTLS sertifikaadi DCCG TLS otspunktide valgesse nimekirja;

— lisab NBUP sertifikaadi DCCG süsteemi;

— annab liikmesriigi käsutusse DCCGTA ja DCCGTLS digitaalsertifikaadi.

4.2. Sertimiskeskused, kehtivusajad ja uuendamine

Juhul kui liikmesriik soovib kasutada omaenese CSCAd, võivad CSCA-sertifikaadid olla iseallkirjastatud sertifikaadid. Need toimivad liikmesriigi ankurvõtmena ja seega peab liikmesriik CSCA-sertifikaadi avalikule võtmele vastavat privaatvõtit kindlalt kaitsma. Liikmesriigil soovitatakse oma CSCA jaoks kasutada vallassüsteemi, st arvutisüsteemi, mis ei ole ühendatud ühtegi võrku. Süsteemile juurdepääsuks tuleb kasutada mitut inimest nõudvat korda (näiteks järgides nn nelja silma põhimõtet). Pärast DSCde allkirjastamist kohaldatakse toimimiskontrolli, CSCA privaatvõtit sisaldavat süsteemi hoitakse turvaliselt ja juurdepääsu sellele kontrollitakse rangelt. CSCA privaatvõtme täiendavaks kaitseks võib kasutada füüsilisi turvamooduleid või kiipkaarte. Elektroonilistel sertifikaatidel on kehtivusaeg, mis sunnib sertifikaati uuendama. Uuendamist on vaja, et kasutada värskeid krüptovõtmeid ja kohandada võtmete pikkust, kui kasutatava krüptoalgoritmi turvalisust ohustavad uued edusammud andmetöötluse vallas või uued ründed. Kasutatakse kestmudelit (vt punkt 3.2).

Arvestades digitaalsete COVID-tõendite aastast kehtivust, soovitatakse järgmisi kehtivusaegu:

— CSCA: 4 aastat;

— DSC: 2 aastat;

— üleslaadimine: 1–2 aastat;

— TLS-kliendi autentimine: 1–2 aastat.

Õigeaegseks uuendamiseks soovitatakse privaatvõtmete puhul järgmisi kasutusaegu:

— CSCA: 1 aasta;

— DSC: 6 kuud.

Selleks et võimaldada sujuvat toimimist, peavad liikmesriigid looma uued üleslaadimissertifikaadid ja TLS-sertifikaadid õigeaegselt, näiteks kuu aega enne nende aegumist. CSCA sertifikaate ja DSCsid tuleks uuendada vähemalt kuu aega enne privaatvõtme kehtivuse lõppu (võttes arvesse vajalikke korralduslikke meetmeid). Liikmesriigid peavad esitama uuendatud CSCA, üleslaadimis- ja TLS-sertifikaadid DCCG käitajale. Aegunud sertifikaadid eemaldatakse valgest nimekirjast ja usaldusloetelust.

Liikmesriigid ja DCCG käitaja peavad ise jälgima oma sertifikaatide kehtivust. Puudub keskne üksus, kes peaks arvet sertifikaatide kehtivuse üle ja osalisi teavitaks.

4.3. Sertifikaatide tühistamine

Üldiselt saab elektroonilise sertifikaadi tühistada selle väljastanud sertimiskeskus, kasutades tühistatud sertifikaatide loendit või OCSP kehtivuskinnitusi. DCC süsteemi CSCAd peaksid esitama tühistatud sertifikaatide loendi. Isegi kui teised liikmesriigid neid tühistatud sertifikaatide loendeid praegu ei kasuta, tuleks need integreerida tulevaseks kasutuseks. Juhul kui CSCA otsustab tühistatud sertifikaatide loendeid mitte esitada, tuleb kõnealuse CSCA DSCsid uuendada, kui tühistatud sertifikaatide loendid muutuvad kohustuslikuks. Kontrollijad ei peaks DSCde valideerimiseks kasutama mitte OCSP kehtivuskinnitusi, vaid tühistatud sertifikaatide loendeid. On soovitatav, et riiklik tagateenistus tegeleb DCC lüüsist alla laaditud DSCde vajaliku valideerimisega ja edastab riiklikele DCC valideerijatele ainult usaldusväärsete ja valideeritud DSCde kogumi. DCC valideerijad ei peaks oma valideerimisprotsessi käigus tegelema DSC kehtivuse kontrolliga. Selle üks põhjus on kaitsta DCC omajate privaatsust, vältides mis tahes võimalust, et ühe konkreetse DSC kasutamist saaks jälgida sellega seotud OCSP kehtivuskinnituse kaudu.

Liikmesriigid saavad oma DSCd kehtivat üleslaadimis- ja TLS-sertifikaati kasutades DCCGst ise eemaldada. DSC eemaldamine tähendab, et kui liikmesriigid laadivad alla DSCde uuendatud loetelu, muutuvad kõik selle DSCga väljastatud DCCd kehtetuks. DSCdele vastava privaatvõtme materjali kaitse on eluliselt tähtis. Kui liikmesriigid peavad üleslaadimis- või TLS-sertifikaate uuendama, näiteks riikliku tagateenistuse rikkumise tõttu, peavad nad DCCG käitajat sellest teavitama. Siis saab DCCG käitaja mõjutatud sertifikaadilt usalduse ära võtta, näiteks eemaldades selle TLSi valgest nimekirjast. DCCG käitaja võib üleslaadimissertifikaadid DCCG andmebaasist eemaldada. Sellele üleslaadimissertifikaadile vastava privaatvõtmega allkirjastatud paketid kaotavad kehtivuse, kui riiklikud tagateenistused usalduse tühistatud sertifikaadilt ära võtavad. Juhul kui tühistada tuleb CSCA-sertifikaat, teavitavad liikmesriigid DCCG käitajat, samuti teisi liikmesriike, kellega neil on usaldussuhted. DCCG käitaja väljastab uue usaldusloetelu, milles asjaomast sertifikaati enam ei ole. Kõik selle CSCA väljastatud DSCd kaotavad kehtivuse, kui liikmesriigid oma tagateenistuse usaldusväärsete sertifikaatide ladu uuendavad. Juhul kui on vaja tühistada DCCGTLS sertifikaat või DCCGTA sertifikaat, peavad DCCG käitaja ja liikmesriik tegema koostööd, et luua uus usaldatav TLS-ühendus ja usaldusloetelu.

5. Sertifikaatide mallid

Selles punktis on esitatud nõuded ja suunised krüptograafia kohta, samuti teatavatele mallidele esitatavad nõuded. DCCG sertifikaatide kohta on käesolevas punktis määratletud sertifikaatide mallid.

5.1. Krüptograafilised nõuded

Krüptoalgoritmid ja TLSi šifrikomplektid võib valida vastavalt Saksamaa Infoturbe Liiduameti (BSI) või SOG-ISi soovitustele. Need soovitused on sarnased muude institutsioonide ja standardiorganisatsioonide soovitustega. Soovitused on esitatud tehnilistes suunistes TR 02102-1 ja TR 02102-2 (1) või SOG-ISi dokumendis „Agreed Cryptographic Mechanisms“ (2).

5.1.1. Nõuded DSC-le

Kehtivad I lisa punktis 3.2.2 esitatud nõudeid. Seega soovitatakse tungivalt, et dokumentide allkirjastajad kasutaksid elliptiliste kõverate digiallkirja algoritmi ja NIST-p-256 (nagu on kirjeldatud standardi (FIPS PUB 186–4) D lisas). Teistele elliptilistele kõveratele puudub tugi. DCC ruumipiirangute tõttu ei peaks liikmesriigid kasutama RSA-PSSi, ehkki see on lubatud kui algoritmi varuvariant. Juhul kui liikmesriik kasutab RSA-PSSi, peaks mooduli suurus olema 2048 või kõige enam 3072 bitti. DSC allkirja krüptograafilise räsifunktsiooni jaoks tuleb kasutada SHA-2, mille väljund on ≥ 256 bitti (vt ISO/IEC 10118-3:2004).

5.1.2. Nõuded seoses TLS-, üleslaadimis- ja CSCA-sertifikaatidega

DCCG kontekstis on peamised nõuded, mis esitatakse krüptoalgoritmidele ja võtmete pikkusele elektrooniliste sertifikaatide ja krüpteeritud allkirjade puhul, kokku võetud järgmises tabelis (2021. aasta seisuga).

Allkirja algoritm Võtme pikkus Räsifunktsioon EC-DSA Vähemalt 250 bitti SHA-2, mille väljund on ≥ 256 bitti RSA-PSS (soovituslik täidis) RSA-PKCS#1 v1.5 (pärandtäidis) Vähemalt 3000 bitine RSA-moodul (N), mille avalik eksponent e > 2^16 SHA-2, mille väljund on ≥ 256 bitti DSA Vähemalt 3000 bitti algarv p, 250 bitti võti q SHA-2, mille väljund on ≥ 256 bitti

EC-DSA soovituslik elliptiline kõver on NIST-p-256 tulenevalt selle laialdasest kasutusest.

5.2. CSCA sertifikaat (NBCSCA)

Järgmises tabelis antakse suuniseid NBCSCA sertifikaadi malli kohta, kui liikmesriik otsustab DCC süsteemi jaoks käitada omaenese CSCAd.

Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

Väli Väärtus Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<CSCAd käitav liikmesriik> Võtme kasutamise eesmärk Sertifikaatide allkirjastamine, tühistatud sertifikaatide loendi allkirjastamine (miinimum) Põhipiirangud CA = true, raja pikkuse piirang = 0

Subjekti nimi peab olema mittetühi ja nimetatud liikmesriigis kordumatu. Riigikood (c) peab langema kokku seda CSCA-sertifikaati kasutava liikmesriigiga. Sertifikaat peab sisaldama dokumendi RFC 5280 (3) kohast subjekti võtme identifikaatorit.

5.3. Dokumendi allkirjastaja sertifikaat (DSC)

Järgmises tabelis on esitatud suunised DSC kohta. Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

Väli Väärtus Sarjanumber Kordumatu sarjanumber Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<asjaomast DSCd kasutav liikmesriik> Võtme kasutamise eesmärk Digiallkiri (miinimum)

DSC peab olema allkirjastatud privaatvõtmega, mis vastab liikmesriigi poolt kasutatavale CSCA-sertifikaadile.

Kasutada tuleb järgmisi laiendeid:

— sertifikaat peab sisaldama asutuse võtme identifikaatorit, mis vastab väljastava CSCA-sertifikaadi subjekti võtme identifikaatorile;

— sertifikaat peaks sisaldama kordumatut subjekti võtme identifikaatorit (kooskõlas dokumendiga RFC 5280) (4).

Lisaks sellele peaks sertifikaat sisaldama tühistatud sertifikaatide loendi väljastamispunkti laiendit, mis viitab tühistatud sertifikaatide loendile, mille on esitanud DSC väljastanud CSCA.

DSC võib sisaldada laiendatud võtmekasutuslaiendit, milles on null või rohkem võtmekasutuse otstarbe tunnust, mis piiravad seda, millist liiki HCERTe asjaomane sertifikaat tohib kontrollida. Kui neid on üks või rohkem, võrdlevad kontrollijad võtit selle kontrolliks salvestatud HCERTiga. Selle jaoks on määratletud järgmised extendedKeyUsage väärtused.

Väli Väärtus extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 testimistõendite väljastajatele extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 vaktsineerimistõendite väljastajatele extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 paranemistõendite väljastajatele

Juhul kui võtmekasutuslaiend puudub (st puuduv laiend või null laiendit), võib asjaomast sertifikaati kasutada ükskõik mis liiki HCERTi valideerimiseks. Muudes dokumentides võidakse määratleda võtmekasutuslaiendis asjakohased täiendavad otstarbe tunnused, mida kasutatakse HCERTide valideerimiseks.

5.4. Üleslaadimissertifikaadid (NBUP)

Järgmises tabelis on esitatud suunised riikliku tagateenistuse üleslaadimissertifikaadi kohta. Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

Väli Väärtus Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<asjaomast üleslaadimissertifikaati kasutav liikmesriik> Võtme kasutamise eesmärk Digiallkiri (miinimum)

5.5. Riikliku tagateenistuse TLS-kliendi autentimine (NBTLS)

Järgmises tabelis on esitatud suunised riikliku tagateenistuse TLS-kliendi autentimissertifikaadi kohta. Rasvases kirjas kanded on kohustuslikud (peavad sertifikaadis olema), kaldkirjas kanded on soovituslikud (peaksid seal olema). Puuduvate väljade kohta ei ole soovitusi antud.

Väli Väärtus Subjekt cn=<mittetühi ja kordumatu üldnimi>, o=<pakkuja>, c=<NB liikmesriik> Võtme kasutamise eesmärk Digiallkiri (miinimum) Võtmekasutuslaiend Kliendi autentimine ( 1.3.6.1.5.5.7.3.2)

Samuti võib sertifikaat sisaldada võtmekasutuslaiendit serveri autentimine ( 1.3.6.1.5.5.7.3.1), kuid see ei ole nõutav.

5.6. Usaldusloetelu allkirjastamise sertifikaat (DCCGTA)

DCCG ankurvõtme sertifikaat on määratletud järgmises tabelis.

Väli Väärtus Subjekt cn = Rohelise digitõendi lüüs, (5) o=<pakkuja>, c=<riik> Võtme kasutamise eesmärk Digiallkiri (miinimum)

5.7. DCCG TLS serveri sertifikaadid (DCCGTLS)

DCCG TLS-sertifikaat on määratletud järgmises tabelis.

Väli Väärtus Subjekt cn=<DCCG täisdomeeninimi või IP-aadress>, o=<pakkuja>, c= <riik> SubjectAltName dNSName: <DCCG DNS-nimi> või iPAddress: <DCCG IP-aadress> Võtme kasutamise eesmärk Digiallkiri (miinimum) Võtmekasutuslaiend Serveri autentimine ( 1.3.6.1.5.5.7.3.1)

Samuti võib sertifikaat sisaldada võtmekasutuslaiendit kliendi autentimine ( 1.3.6.1.5.5.7.3.2), kuid see ei ole nõutav.

DCCG TLS-sertifikaadi väljastab avalikult usaldatav sertimiskeskus (sealhulgas kõigi peamiste brauserite ja operatsioonisüsteemide jaoks järgides CA/Browser Forumi põhinõudeid).

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

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

(3) rfc5280 (ietf.org)

(4) rfc5280 (ietf.org)

(5) Käesolevas kontekstis on jätkatud termini „roheline digitõend“ kasutamist termini „ELi digitaalne COVID-tõend“ asemel, kuna see on termin, mis on tõendisse püsikodeeritud ja selles kasutusele võetud enne, kui kaasseadusandjad otsustasid kasutada uut terminit.