LIITE IV

JULKISEN AVAIMEN VARMENTEEN HALLINNOINTI

1. Johdanto

EU:n digitaalisten koronatodistusten allekirjoitusavainten suojattu ja luotettava vaihto jäsenvaltioiden välillä toteutetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän (DCCG) kautta. Se toimii julkisten avainten keskusrekisterinä. Yhdyskäytävän avulla jäsenvaltiot voivat julkaista julkiset avaimet, jotka vastaavat niitä yksityisiä avaimia, joita ne käyttävät digitaalisten koronatodistusten allekirjoittamiseen. Luottavat jäsenvaltiot voivat käyttää yhdyskäytävää ajantasaisen julkisen avaimen aineiston hakemiseen oikea-aikaisesti. Myöhemmässä vaiheessa yhdyskäytävä voidaan laajentaa jäsenvaltioiden toimittamien luotettavien lisätietojen vaihtoon. Ne voivat liittyä esimerkiksi digitaalisten koronatodistusten validointisääntöihin. Digitaalisten koronatodistusten kehyksen luottamusmallina on julkisen avaimen infrastruktuuri (PKI). Kukin jäsenvaltion pitää yllä yhtä tai useampaa kansallista juurivarmentajaa (CSCA), jonka varmenteet ovat suhteellisen pitkäikäisiä. Jäsenvaltion päätöksestä CSCA voi olla sama tai eri kuin koneluettavia matkustusasiakirjoja varten käytetty CSCA. CSCA myöntää julkisen avaimen varmenteita kansallisille, lyhytikäisille asiakirjan allekirjoittajille (eli digitaalisten koronatodistusten allekirjoittajille). Niitä kutsutaan nimellä asiakirjan allekirjoittajan varmenteet (DSC). CSCA toimii luottamusankkurina, jonka avulla luottavat jäsenvaltiot voivat käyttää CSCA-varmennetta säännöllisesti muuttuvien DSC-varmenteiden aitouden ja eheyden varmentamiseen. Kun varmenteet on validoitu, jäsenvaltiot voivat antaa niitä (tai vain niihin sisältyviä julkisia avaimia) digitaalisten koronatodistusten validointia koskeville hakemuksille. CSCA- ja DSC-varmenteiden lisäksi digitaalisten koronatodistusten yhdyskäytävä tukeutuu myös PKI-järjestelmään transaktioiden todentamisessa, tietojen allekirjoittamisessa, todentamisen perustana sekä keinona varmistaa jäsenvaltioiden ja yhdyskäytävän välisten tiedonsiirtokanavien eheys.

Digitaalisia allekirjoituksia voidaan käyttää tietojen eheyden ja aitouden saavuttamiseksi. Julkisen avaimen infrastruktuurit luovat luottamusta sitomalla julkiset avaimet todennettuihin henkilöllisyyksiin (tai myöntäjiin). Tämä on tarpeen, jotta muut osallistujat voivat tarkistaa tiedon alkuperän ja viestintäkumppanin henkilöllisyyden ja päättää luottamuksesta. Yhdyskäytävässä todentamiseen käytetään useita julkisen avaimen varmenteita. Tässä liitteessä määritellään, mitä julkisen avaimen varmenteita käytetään ja miten ne on suunniteltava laajan yhteentoimivuuden mahdollistamiseksi jäsenvaltioiden kesken. Siinä annetaan tarkempia tietoja tarvittavista julkisen avaimen varmenteista ja annetaan ohjeita varmenteiden malleista ja voimassaoloajoista niille jäsenvaltioille, jotka haluavat käyttää omaa CSCA:aan. Koska digitaalisten koronatodistusten on oltava todennettavissa määrätyn ajan (myöntämisestä voimassaolon päättymiseen), on tarpeen määritellä todentamismalli kaikille julkisen avaimen varmenteissa ja digitaalisissa koronatodistuksissa käytetyille allekirjoituksille.

2. Terminologia

Seuraavassa taulukossa esitetään tässä liitteessä käytetyt lyhenteet ja termit.

Termi Määritelmä Varmenne Eli julkisen avaimen varmenne. X.509 v3 -varmenne, joka sisältää yksikön julkisen avaimen CSCA Country Signing Certificate Authority; kansallinen juurivarmentaja DCC EU Digital COVID Certificate; EU:n digitaalinen koronatodistus. Allekirjoitettu digitaalinen asiakirja, joka sisältää tietoja rokotuksesta, testauksesta tai taudista parantumisesta DCCG EU Digital COVID Certificate Gateway. EU:n digitaalisen koronatodistuksen yhdyskäytävä. Tätä järjestelmää käytetään DSC-varmenteiden vaihtoon jäsenvaltioiden välillä DCCGTA DCCG:n luottamusankkurin varmenne. Vastaavaa yksityistä avainta käytetään kaikkien CSCA-varmenteiden luettelon allekirjoittamiseen verkon ulkopuolella DCCGTLS DCCG:n TLS-palvelinvarmenne DSC Document Signer Certificate; asiakirjan allekirjoittajan varmenne. Jäsenvaltion asiakirjojen allekirjoittajaviranomaisen (esimerkiksi järjestelmä, jolla on lupa allekirjoittaa digitaalisia koronatodistuksia) julkisen avaimen varmenne. Tämän varmenteen myöntää jäsenvaltion CSCA EC-DSA Elliptic Curve Digital Signature Algorithm; elliptisen käyrän digitaalinen allekirjoitusalgoritmi. Elliptisiin käyriin perustuva kryptografinen allekirjoitusalgoritmi Jäsenvaltio Euroopan unionin jäsenvaltio mTLS Keskinäinen TLS. Transport Layer Security (TLS) -protokolla, johon sisältyy molemminpuolinen todentaminen NB National Backend; jäsenvaltion kansallinen taustajärjestelmä NBCSCA Jäsenvaltion CSCA-varmenne (voi olla useampia kuin yksi) NBTLS Kansallisen taustajärjestelmän TLS-asiakkaan todennusvarmenne NBUP Varmenne, jota kansallinen taustajärjestelmä käyttää DCCG:hen ladattavien datapakettien allekirjoittamiseen PKI Public Key Infrastructure; julkisen avaimen järjestelmä. Julkisen avaimen varmenteisiin ja varmenneviranomaisiin perustuva luottamusmalli RSA Epäsymmetrinen salausalgoritmi, joka perustuu kokonaislukujen tekijöihin jakamiseen ja jota käytetään digitaalisissa allekirjoituksissa tai epäsymmetrisessä salauksessa

3. DCCG:n tietoliikennevirrat ja turvallisuuspalvelut

Tässä jaksossa esitetään yleiskatsaus DCCG-järjestelmän tietoliikennevirroista ja turvallisuuspalveluista. Siinä määritellään myös, mitä avaimia ja varmenteita käytetään suojaamaan tietoliikenne, ladatut tiedot, digitaaliset koronatodistukset ja allekirjoitettu luottamusluettelo, joka sisältää kaikki käyttöön otetut CSCA-varmenteet. DCCG toimii tietokeskuksena, joka mahdollistaa allekirjoitettujen datapakettien vaihdon jäsenvaltioille.

DCCG toimittaa järjestelmään ladatut datapaketit ”sellaisinaan”, eli DCCG ei lisää tai poista DSC-varmenteita vastaanottamistaan paketeista. Jäsenvaltioiden kansallisten taustajärjestelmien on voitava tarkistaa ladattujen tietojen eheys ja aitous päästä päähän. Tämän lisäksi kansalliset taustajärjestelmät ja DCCG käyttävät keskinäistä TLS-todennusta suojatun yhteyden luomiseksi. Tämä tehdään tietojenvaihdon allekirjoitusten lisäksi.

3.1 Todentaminen ja yhteyden luominen

DCCG:ssä käytetään TLS-salausprotokollaa ja molemminpuolista todentamista todennetun salatun kanavan luomiseen jäsenvaltion kansallisen taustajärjestelmän ja yhdyskäytäväympäristön välille. DCCG:llä on näin ollen TLS-palvelinvarmenne (DCCGTLS) ja kansallisilla taustajärjestelmillä TLS-asiakasvarmenne (NBTLS). Varmenteiden mallit esitetään jaksossa 5. Kukin kansallinen taustajärjestelmä voi antaa oman TLS-varmenteensa. Tämä varmenne lisätään hyväksyttyjen varmenteiden valkoiselle listalle, ja sen voi siten myöntää julkisesti luotettu varmenneviranomainen (esimerkiksi varmenneviranomainen, joka noudattaa CA Browser Forumin perusvaatimuksia) tai kansallinen varmenneviranomainen tai se voi olla itse allekirjoitettu. Kukin jäsenvaltio on vastuussa kansallisista tiedoistaan ja sen yksityisen avaimen suojaamisesta, jota käytetään yhteyden luomiseen DCCG:hen. ”Tuo oma varmenteesi” -toimintatapa edellyttää tarkasti määriteltyä rekisteröinti- ja tunnistusprosessia sekä 4.1, 4.2 ja 4.3 kohdassa selostettuja peruuttamis- ja uusimismenettelyjä. DCCG käyttää valkoista listaa, johon kansallisten taustajärjestelmien TLS-varmenteet lisätään niiden onnistuneen rekisteröinnin jälkeen. Ainoastaan sellaiset kansalliset taustajärjestelmät, jotka todentavat itsensä valkoiseen listaan sisältyvää varmennetta vastaavalla yksityisellä avaimella, voivat luoda suojatun yhteyden DCCG:hen. DCCG käyttää myös TLS-varmennetta, jonka avulla kansalliset taustajärjestelmät voivat tarkistaa, että ne todella muodostavat yhteyden ”todelliseen” DCCG:hen eivätkä johonkin DCCG:nä esiintyvään pahantahtoiseen tahoon. DCCG:n varmenne toimitetaan kansalliselle taustajärjestelmälle onnistuneen rekisteröinnin jälkeen. DCCGTLS-varmenne saadaan julkisesti luotetulta varmenneviranomaiselta (sisältyy kaikkiin tärkeimpiin selaimiin). Jäsenvaltioiden vastuulla on varmistaa, että niiden yhteys DCCG:hen on suojattu (esim. vertaamalla yhteydessä olevan palvelimen DCCGTLS- varmenteen sormenjälkeä rekisteröinnin jälkeen annettuun sormenjälkeen).

3.2 Kansalliset juurivarmentajat ja validointimalli

DCCG-kehykseen osallistuvien jäsenvaltioiden on käytettävä CSCA:a DSC-varmenteiden myöntämiseen. Jäsenvaltioilla voi olla useampi kuin yksi CSCA (esimerkiksi jos hallinto on hajautettu alueellisesti). Kukin jäsenvaltio voi joko käyttää olemassa olevia varmenneviranomaisia tai perustaa DCC-järjestelmää varten oman (mahdollisesti itse allekirjoitetun) varmenneviranomaisen.

Jäsenvaltioiden on esitettävä CSCA-varmenteensa DCCG-operaattorille virallisen liittymismenettelyn aikana. Kun jäsenvaltio on rekisteröity onnistuneesti (ks. lisätietoja kohdassa 4.1), DCCG-operaattori päivittää allekirjoitetun luottamusluettelon, joka sisältää kaikki DCC-järjestelmän aktiiviset CSCA-varmenteet. DCCG-operaattori käyttää erityistä epäsymmetristä avainparia luottamusluettelon ja varmenteiden allekirjoittamiseen verkon ulkopuolella. Yksityistä avainta ei tallenneta DCCG:n verkkojärjestelmään, joten verkkojärjestelmän vaarantuminen ei anna hyökkääjälle mahdollisuutta vaarantaa luottamusluetteloa. Vastaava luottamusankkurin varmenne DCCGTA annetaan kansallisille taustajärjestelmille liittymisprosessin aikana.

Jäsenvaltiot voivat hakea luottamusluettelon DCCG:stä todentamismenettelyjään varten. CSCA:lla tarkoitetaan DSC-varmenteita myöntävää varmenneviranomaista. Jäsenvaltioiden, jotka käyttävät monitasoista CA-hierarkiaa (esim. juuri-CA -> CSCA -> DSC), on ilmoitettava DSC-varmenteita myöntävä alemman tason varmenneviranomainen. Jos tässä tapauksessa jäsenvaltio käyttää olemassa olevaa varmenneviranomaista, DCC-järjestelmä jättää huomiotta kaiken CSCA:n yläpuolella olevan ja lisää valkoiselle listalle luottamusankkuriksi ainoastaan CSCA:n (vaikka se olisikin alemman tason varmenneviranomainen). ICAOn mallin tavoin tämä sallii täsmälleen kaksi tasoa – ’juuritason’ CSCA:n ja ’lehtitason’ DSC:n, jonka allekirjoittaa ainoastaan kyseinen CSCA.

Jos jäsenvaltio operoi omaa CSCA:taan, se vastaa kyseisen varmenneviranomaisen turvallisesta toiminnasta ja avainhallinnosta. CSCA toimii DSC-varmenteiden luottamusankkurina, minkä vuoksi CSCA:n yksityisen avaimen suojaaminen on olennaisen tärkeää DCC-ympäristön eheyden kannalta. DCC-järjestelmän PKI:n todennusmalli on kuorimalli, jonka mukaan kaikkien varmennepolun validoinnissa käytettävien varmenteiden on oltava voimassa tiettynä ajankohtana (eli allekirjoituksen validointihetkellä). Sen vuoksi sovelletaan seuraavia rajoituksia:

— CSCA ei saa myöntää varmenteita, jotka ovat voimassa pidempään kuin itse CA-varmenne;

— Asiakirjan allekirjoittaja ei saa allekirjoittaa asiakirjoja, jotka ovat voimassa pidempään kuin itse DSC-varmenne;

— Jäsenvaltioiden, jotka operoivat omaa CSCA:taan, on määriteltävä CSCA:n ja kaikkien myönnettyjen todistusten voimassaoloajat, ja niiden on huolehdittava varmenteiden uusimisesta.

Kohdassa 4.2 esitetään voimassaoloaikaa koskevia suosituksia.

3.3 Ladattujen tietojen eheys ja aitous

Kansalliset taustajärjestelmät voivat käyttää DCCG:tä digitaalisesti allekirjoitettujen datapakettien lataamiseen järjestelmästä ja järjestelmään onnistuneen molemminpuolisen todentamisen jälkeen. Alussa nämä datapaketit sisältävät jäsenvaltioiden DSC-varmenteet. Avainparia, jota kansallinen taustajärjestelmä käyttää DCCG-järjestelmään ladattujen datapakettien digitaaliseen allekirjoitukseen, kutsutaan kansallisen taustajärjestelmän latauksen allekirjoitusavainpariksi, ja vastaava julkisen avaimen varmenne on lyhyesti NBUP-varmenne. Kukin jäsenvaltio ottaa käyttöön oman NBUP-varmenteensa, joka voi olla itse allekirjoitettu tai jonka myöntää olemassa oleva varmenneviranomainen, kuten julkinen varmenneviranomainen (eli varmenneviranomainen, joka myöntää varmenteita CA Browser Forumin perusvaatimusten mukaisesti). NBUP-varmenteen on erottava kaikista muista jäsenvaltion käyttämistä varmenteista (eli CSCA-, TLS-asiakas- tai DSC-varmenteista).

Jäsenvaltioiden on toimitettava latausvarmenne DCCG-operaattorille ensimmäisen rekisteröintimenettelyn aikana (lisätietoja 4.1 kohdassa). Kukin jäsenvaltio on vastuussa kansallisista tiedoistaan, ja kunkin jäsenvaltion on suojattava yksityinen avain, jota käytetään latausten allekirjoittamiseen.

Muut jäsenvaltiot voivat todentaa allekirjoitetut datapaketit DCCG:n toimittamien latausvarmenteiden avulla. DCCG todentaa ladattujen tietojen aitouden ja eheyden kansallisen taustajärjestelmän latausvarmenteen avulla ennen niiden toimittamista muille jäsenvaltioille.

3.4 DCCG:n teknistä rakennetta koskevat vaatimukset

DCCG:n teknistä rakennetta koskevat vaatimukset ovat seuraavat:

— DCCG käyttää keskinäistä TLS-todennusta luodakseen todennetun salatun yhteyden kansallisiin taustajärjestelmiin. Sen vuoksi DCCG ylläpitää valkoista listaa rekisteröidyistä NBTLS-asiakasvarmenteista;

— DCCG käyttää kahta digitaalista varmennetta (DCCGTLS ja DCCGTA), joissa on kaksi erillistä avainparia. DCCGTA-avainparin yksityinen avain säilytetään verkon ulkopuolella (ei DCCG:n verkkoelementeissä);

— DCCG ylläpitää NBCSCA-varmenteiden luottamusluetteloa, joka on allekirjoitettu DCCGTA-varmenteen yksityisellä avaimella;

— Käytettävien salausten on täytettävä 5.1 kohdassa esitetyt vaatimukset.

4. Varmenteen elinkaaren hallinta

4.1 Kansallisten taustajärjestelmien rekisteröinti

Jäsenvaltioiden on rekisteröidyttävä DCCG-operaattorille voidakseen osallistua DCCG-järjestelmään. Tässä jaksossa kuvataan tekniset ja toiminnalliset menettelyt, joita on noudatettava kansallisen taustajärjestelmän rekisteröimiseksi.

DCCG-operaattorin ja jäsenvaltion on vaihdettava tietoja teknisistä yhteyshenkilöistä liittymisprosessia varten. Oletetaan, että tekniset yhteyshenkilöt ovat jäsenvaltionsa laillisesti hyväksymiä ja että henkilöllisyyden todistaminen/todentaminen tapahtuu muiden kanavien kautta. Todentaminen voidaan toteuttaa esimerkiksi siten, että jäsenvaltion tekninen yhteyshenkilö toimittaa varmenteet sähköpostitse salasanalla salattuina tiedostoina ja jakaa vastaavan salasanan DCCG-operaattorin kanssa puhelimitse. Myös muita DCCG-operaattorin määrittelemiä suojattuja kanavia voidaan käyttää.

Jäsenvaltion on annettava rekisteröinti- ja tunnistamisprosessin aikana kolme digitaalista varmennetta:

— Jäsenvaltion TLS-varmenne NBTLS

— Jäsenvaltion latausvarmenne NBUP

— Jäsenvaltion CSCA-varmenne(-varmenteet) NBCSCA

Kaikkien toimitettujen varmenteiden on oltava 5 jaksossa määriteltyjen vaatimusten mukaisia. DCCG-operaattori tarkistaa, että annettu varmenne on 5 jakson vaatimusten mukainen. Tunnistamisen ja rekisteröinnin jälkeen DCCG-operaattori

— lisää NBCSCA-varmenteen(-varmenteet) luottamusluetteloon, joka on allekirjoitettu DCCGTA:n julkista avainta vastaavalla yksityisellä avaimella;

— lisää NBTLS-varmenteen DCCG:n TLS-päätepisteen valkoiseen listaan;

— lisää NBUP-varmenteen DCCG-järjestelmään;

— toimittaa julkisen avaimen DCCGTA- ja DCCGTLS-varmenteen jäsenvaltiolle.

4.2 Varmenneviranomaiset, voimassaoloajat ja uusiminen

Jos jäsenvaltio haluaa käyttää omaa CSCA:aan, CSCA-varmenteet voivat olla itse allekirjoitettuja. Ne toimivat jäsenvaltion luottamusankkurina, ja siksi jäsenvaltion on suojattava vahvasti CSCA-varmenteen julkista avainta vastaava yksityinen avain. On suositeltavaa, että jäsenvaltiot käyttävät CSCA:aan offline-järjestelmää eli tietokonejärjestelmää, jota ei ole liitetty mihinkään verkkoon. Järjestelmään pääsemiseksi on käytettävä usean henkilön suorittamaa valvontaa (esimerkiksi kahden käsittelijän periaatteen mukaisesti). DSC-varmenteiden allekirjoittamisen jälkeen on sovellettava operatiivisia valvontatoimia, ja järjestelmä, jossa yksityistä CSCA-avainta pidetään, on tallennettava turvallisesti siten, että käyttöoikeuksia valvotaan tiukasti. CSCA:n yksityisen avaimen suojaamiseen voidaan käyttää myös laitteistoturvamoduuleja tai älykortteja. Digitaalisilla varmenteilla on voimassaoloaika, joka pakottaa uusimaan varmenteet. Uusiminen on tarpeen, jotta voidaan käyttää uusia salausavaimia ja mukauttaa avainkokoja laskentatehon parantuessa tai kun uudet hyökkäykset uhkaavat käytettävän salausalgoritmin turvallisuutta. Käytetään kuorimallia (ks. 3.2 kohta).

Digitaalisten koronatodistusten yhden vuoden voimassaoloaika huomioon ottaen suositellaan seuraavia voimassaoloaikoja:

— CSCA: 4 vuotta

— DSC: 2 vuotta

— Lataus: 1–2 vuotta

— TLS-asiakkaan todentaminen: 1–2 vuotta

Jotta uusiminen tapahtuisi hyvissä ajoin, yksityisille avaimille suositellaan seuraavia käyttöaikoja:

— CSCA: 1 vuosi

— DSC: 6 kuukautta

Jotta toiminta olisi sujuvaa, jäsenvaltioiden on luotava uusia latausvarmenteita ja TLS-varmenteita hyvissä ajoin, esimerkiksi kuukausi ennen niiden voimassaolon päättymistä. CSCA- ja DSC-varmenteet olisi uusittava vähintään kuukausi ennen yksityisen avaimen käytön päättymistä (ottaen huomioon tarvittavat operatiiviset menettelyt). Jäsenvaltioiden on toimitettava päivitetyt CSCA-, lataus- ja TLS-varmenteet DCCG-operaattorille. Vanhentuneet varmenteet poistetaan valkoisesta listasta ja luottamusluettelosta.

Jäsenvaltioiden ja DCCG-operaattorin on seurattava omien varmenteidensa voimassaoloa. Ei ole keskustahoa, joka pitää kirjaa varmenteiden voimassaolosta ja ilmoittaa siitä osallistujille.

4.3 Varmenteiden peruuttaminen

Yleisesti ottaen digitaaliset varmenteet myöntänyt varmenneviranomainen voi peruuttaa varmenteet käyttämällä varmenteiden sulkulistoja tai verkossa olevaa varmenteen statusprotokollaa (Online Certificate Status Protocol Responder, OCSP). DCC-järjestelmän CSCA:iden olisi toimitettava varmenteiden sulkulistat. Vaikka muut jäsenvaltiot eivät tällä hetkellä käytä näitä sulkulistoja, ne olisi integroitava tuleviin sovelluksiin. Jos CSCA päättää olla toimittamatta varmenteiden sulkulistoja, kyseisen CSCA:n DSC-varmenteet on uusittava, kun sulkulistoista tulee pakollisia. Todentajien ei pitäisi käyttää OCSP:tä DSC-varmenteiden validointiin, vaan niiden olisi käytettävä varmenteiden sulkulistoja. On suositeltavaa, että kansallinen taustajärjestelmä suorittaa DCCG-yhdyskäytävästä ladattujen DSC-varmenteiden tarvittavan validoinnin ja toimittaa edelleen kansallisille DCC-validoijille ainoastaan luotetun ja validoidun joukon DSC-varmenteita. DCC-validoijien ei pitäisi tehdä DSC-varmenteiden peruutuksia koskevia tarkastuksia validointiprosessissaan. Yksi syy tähän on digitaalisten koronatodistusten haltijoiden yksityisyyden suojaaminen välttämällä mahdollisuus, että OCSP-vastaaja voi valvoa tietyn DSC-varmenteen käyttöä.

Jäsenvaltiot voivat itse poistaa DSC-varmenteensa DCCG:stä käyttämällä voimassa olevia lataus- ja TLS-varmenteita. DSC-varmenteen poistaminen tarkoittaa, että kaikista kyseisellä DSC-varmenteella myönnetyistä digitaalisista koronatodistuksista tulee pätemättömiä, kun jäsenvaltiot hakevat päivitetyt DSC-luettelot. DSC-varmenteita vastaavan yksityisen avainaineiston suojaaminen on ratkaisevan tärkeää. Jäsenvaltioiden on ilmoitettava DCCG-operaattorille, jos niiden on peruutettava lataus- tai TLS-varmenteita esimerkiksi kansallisen taustajärjestelmän vaarantumisen vuoksi. DCCG-operaattori voi tämän jälkeen poistaa kyseessä olevaa varmennetta koskevan luottamuksen esimerkiksi poistamalla sen TLS:n valkoisesta listasta. DCCG-operaattori voi poistaa latausvarmenteen DCCG-tietokannasta. Tätä latausvarmennetta vastaavalla yksityisellä avaimella allekirjoitetuista paketeista tulee pätemättömiä, kun kansalliset taustajärjestelmät poistavat peruutetun latausvarmenteen luottamuksen. Jos CSCA-varmenne on peruutettava, jäsenvaltioiden on ilmoitettava asiasta DCCG-operaattorille ja muille jäsenvaltioille, joihin niillä on luottamussuhteita. DCCG-operaattori julkaisee uuden luottamusluettelon, johon kyseessä oleva varmenne ei enää sisälly. Kaikista tämän CSCA:n myöntämistä DSC-varmenteista tulee pätemättömiä, kun jäsenvaltiot päivittävät kansallisen taustajärjestelmänsä luottamussäilön. Jos DCCGTLS-varmenne tai DCCGTA-varmenne on peruutettava, DCCG-operaattorin ja jäsenvaltioiden on tehtävä yhteistyötä uuden luotetun TLS-yhteyden ja luottamusluettelon luomiseksi.

5. Varmenteiden mallit

Tässä jaksossa esitetään salausvaatimukset ja -ohjeet sekä varmenteiden malleja koskevat vaatimukset. DCCG-varmenteiden osalta tässä jaksossa määritellään varmenteiden mallit.

5.1 Salausvaatimukset

Salausalgoritmit ja TLS-salausohjelmat valitaan Saksan liittovaltion tietoturvaviraston (BSI) tai SOG-IS:n nykyisen suosituksen perusteella. Nämä suositukset sekä muiden elinten ja standardointiorganisaatioiden suositukset ovat samankaltaisia. Suositukset löytyvät teknisistä ohjeista TR 02102–1 ja TR 02102–2 (1) tai SOG-IS:n asiakirjasta Agreed Cryptographic Mechanisms (2).

5.1.1 DSC-varmennetta koskevat vaatimukset

Sovelletaan liitteessä I olevassa 3.2.2 kohdassa säädettyjä vaatimuksia. Siksi on erittäin suositeltavaa, että asiakirjan allekirjoittajat käyttävät elliptisen käyrän digitaalista allekirjoitusalgoritmia (ECDSA) NIST-p-256-käyrällä (siten kuin se on määritelty standardin FIPS PUB 186–4 lisäyksessä D). Muita elliptisiä käyriä ei tueta. Digitaaliseen koronatodistukseen liittyvien tilarajoitusten vuoksi jäsenvaltioiden ei pitäisi käyttää RSA-PSS-allekirjoitusmenetelmää, vaikka se olisikin sallittu vara-algoritmina. Jos jäsenvaltiot käyttävät RSA-PSS-menetelmää, niiden olisi käytettävä moduluskokoa 2048 tai enintään 3072 bittiä. SHA-2-algoritimia, jonka tuloksen pituus ≥ 256 bittiä, on käytettävä DSC-allekirjoituksen salauksen tiivistefunktiona (ks. ISO/IEC 10118–3:2004).

5.1.2 TLS-, lataus- ja CSCA-varmennetta koskevat vaatimukset

DCCG:n yhteydessä käytettävien digitaalisten varmenteiden ja salattujen allekirjoitusten osalta salausalgoritmeja ja avaimen pituutta koskevat keskeiset vaatimukset esitetään tiivistetysti seuraavassa taulukossa (vuodesta 2021 alkaen):

Allekirjoitusalgoritmi Avaimen koko Tiivistefunktio EC-DSA Vähintään 250 bittiä SHA-2; tiivisteen pituus ≥ 256 bittiä RSA-PSS (suositeltu täyte) RSA-PKCS#1 v1.5 (vanha täyte) Vähintään 3000 bitin RSA Modulus (N) julkisella eksponentilla e > 2^16 SHA-2; tiivisteen pituus ≥ 256 bittiä DSA Vähintään 3000 bitin alkuluku p, 250 bitin avain q SHA-2; tiivisteen pituus ≥ 256 bittiä

EC-DSA:n suositeltava elliptinen käyrä on NIST-p-256 sen laajan käytön vuoksi.

5.2 CSCA-varmenne (NBCSCA)

Seuraavassa taulukossa annetaan ohjeita NBCSCA-varmenteen mallista, jos jäsenvaltio päättää käyttää omaa CSCA:aan DCC-järjestelmää varten.

Lihavoidut merkinnät ovat pakollisia (niiden on sisällyttävä varmenteeseen), kursivoidut merkinnät ovat suositeltavia (niiden olisi sisällyttävä varmenteeseen). Puuttuvia kenttiä varten ei ole määritelty suosituksia.

Kenttä Arvo Subject cn=<ei-tyhjä ja yksilöivä yleisnimi>, o=<Tarjoaja>, c=<CSCA:ta käyttävä jäsenvaltio> Key usage certificate signing, CRL signing (vähintään) Basic Constraints CA = true, path length constraints = 0

Aiheen nimen on oltava ei-tyhjä ja yksilöivä kyseisessä jäsenvaltiossa. Maakoodin c on vastattava sitä jäsenvaltiota, joka käyttää tätä CSCA-varmennetta. Varmenteessa on oltava standardin RFC 5280 (3) mukainen yksilöivä aihe-avaimen tunniste (Subject Key Identifier, SKI).

5.3 Asiakirjan allekirjoittajan varmenne (DSC)

Seuraavassa taulukossa annetaan DSC-varmennetta koskevia ohjeita. Lihavoidut merkinnät ovat pakollisia (niiden on sisällyttävä varmenteeseen), kursivoidut merkinnät ovat suositeltavia (niiden olisi sisällyttävä varmenteeseen). Puuttuvia kenttiä varten ei ole määritelty suosituksia.

Kenttä Arvo Serial Number unique serial number Subject cn=<ei-tyhjä ja yksilöivä yleisnimi>, o=<Tarjoaja>, c=<tätä DSC:tä käyttävä jäsenvaltio> Key Usage digital signature (vähintään)

DSC-varmenne on allekirjoitettava jäsenvaltion käyttämää CSCA-varmennetta vastaavalla yksityisellä avaimella.

Seuraavia laajennuksia on käytettävä:

— Varmenteessa on oltava viranomaisen avaimen tunniste (Authority Key Identifier, AKI), joka vastaa myöntävän CSCA-varmenteen aihe-avaimen tunnistetta (SKI).

— Varmenteessa olisi oltava yksilöivä aihe-avaimen tunniste (standardin RFC 5280 (4) mukaisesti).

Varmenteen olisi lisäksi sisällettävä CRL-jakelupisteen laajennus, joka viittaa DSC-varmenteen myöntäneen CSCA:n toimittamaan varmenteiden sulkulistaan (CRL).

DSC voi sisältää laajennettua avaimen käyttöä koskevan laajennuksen, jossa on nolla tai useampia avaimen käyttökäytäntöjen tunnisteita, jotka rajoittavat niitä HCERT-tyyppejä, joita tällä varmenteella saa todentaa. Jos tunnisteita on yksi tai useampi, todentajien on todennettava avaimen käyttö suhteessa tallennettuun HCERT-todistukseen. Tätä varten määritellään seuraavat extendedKeyUsage-arvot:

Kenttä Arvo extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 Testaustodistusten myöntäjille extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 Rokotustodistusten myöntäjille extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 Parantumistodistusten myöntäjille

Jos avaimen käytön laajennuksia ei ole (eli ei laajennuksia tai nolla laajennusta), tätä varmennetta voidaan käyttää minkä tahansa tyyppisen HCERT-todistuksen validoimiseen. Muissa asiakirjoissa voidaan määritellä HCERT-todistusten validoinnissa käytettäviä asiaankuuluvia laajennettujen avaimen käyttökäytäntöjen tunnisteita.

5.4 Latausvarmenteet (NBUP)

Seuraavassa taulukossa annetaan kansallisen taustajärjestelmän latausvarmennetta koskevia ohjeita. Lihavoidut merkinnät ovat pakollisia (niiden on sisällyttävä varmenteeseen), kursivoidut merkinnät ovat suositeltavia (niiden olisi sisällyttävä varmenteeseen). Puuttuvia kenttiä varten ei ole määritelty suosituksia.

Kenttä Arvo Subject cn=<ei-tyhjä ja yksilöivä yleisnimi>, o=<Tarjoaja>, c=<tätä latausvarmennetta käyttävä jäsenvaltio> Key Usage digital signature (vähintään)

5.5 Kansallisen taustajärjestelmän TLS-asiakkaan todentaminen (NBTLS)

Seuraavassa taulukossa annetaan kansallisen taustajärjestelmän TLS-asiakkaan todentamisvarmennetta koskevia ohjeita. Lihavoidut merkinnät ovat pakollisia (niiden on sisällyttävä varmenteeseen), kursivoidut merkinnät ovat suositeltavia (niiden olisi sisällyttävä varmenteeseen). Puuttuvia kenttiä varten ei ole määritelty suosituksia.

Kenttä Arvo Subject cn=<ei-tyhjä ja yksilöivä yleisnimi>, o=<Tarjoaja>, c=<taustajärjestelmän jäsenvaltio> Key Usage digital signature (vähintään) Extended key usage client authentication (1.3.6.1.5.5.7.3.2)

Varmenne voi sisältää myös palvelimen todentamista (1.3.6.1.5.5.7.3.1) koskevan laajennetun avaimen käytön, mutta sitä ei vaadita.

5.6 Luottamusluettelon allekirjoitusvarmenne (DCCGTA)

Seuraavassa taulukossa määritellään DCCG:n luottamusankkurin varmenne.

Kenttä Arvo Subject cn = Digital Green Certificate Gateway (5) , o=<Tarjoaja>, c=<maa> Key Usage digital signature (vähintään)

5.7 DCCG:n TLS-palvelinvarmenteet (DCCGTLS)

Seuraavassa taulukossa määritellään DCCG:n TLS-palvelinvarmenne.

Kenttä Arvo Subject cn=<DCCG:n FQDN tai IP-osoite>, o=<Tarjoaja>, c= <maa> SubjectAltName dNSName: <DCCG:n DNS-nimi> tai iPAddress: <DCCG:n IP-osoite> Key Usage digital signature (vähintään) Extended Key usage server authentication (1.3.6.1.5.5.7.3.1)

Varmenne voi sisältää myös asiakkaan todentamista (1.3.6.1.5.5.7.3.2) koskevan laajennetun avaimen käytön, mutta sitä ei vaadita.

DCCG:n TLS-varmenteen myöntää julkisesti luotettu varmenneviranomainen (sisältyy kaikkiin tärkeimpiin selaimiin ja käyttöjärjestelmiin CA Browser Forumin perusvaatimusten mukaisesti).

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

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

(3) rfc5280 (ietf.org)

(4) rfc5280 (ietf.org)

(5) Tässä yhteydessä käytetään edelleen ilmausta ”digitaalinen vihreä todistuta” ilmauksen ”EU:n digitaalinen koronatodistus” sijasta, koska tämä terminologia on kovakoodattu ja otettu käyttöön todistuksessa ennen kuin lainsäätäjät päättivät uudesta terminologiasta.