02021D1073 — FI — 25.12.2021 — 002.001

Tämä asiakirja on ainoastaan dokumentoinnin apuväline eikä sillä ole oikeudellista vaikutusta. Unionin toimielimet eivät vastaa sen sisällöstä. Säädösten todistusvoimaiset versiot on johdanto-osineen julkaistu Euroopan unionin virallisessa lehdessä ja ne ovat saatavana EUR-Lexissä. Näihin virallisiin teksteihin pääsee suoraan tästä asiakirjasta siihen upotettujen linkkien kautta.

►B KOMISSION TÄYTÄNTÖÖNPANOPÄÄTÖS (EU) 2021/1073, annettu 28 päivänä kesäkuuta 2021, Euroopan parlamentin ja neuvoston asetuksella (EU) 2021/953 vahvistetun EU:n digitaalisen koronatodistuksen luottamuskehyksen täytäntöönpanoa koskevista teknisistä eritelmistä ja säännöistä (ETA:n kannalta merkityksellinen teksti) (EUVL L 230 30.6.2021, s. 32)

Muutettu:









▼B

KOMISSION TÄYTÄNTÖÖNPANOPÄÄTÖS (EU) 2021/1073,

annettu 28 päivänä kesäkuuta 2021,

Euroopan parlamentin ja neuvoston asetuksella (EU) 2021/953 vahvistetun EU:n digitaalisen koronatodistuksen luottamuskehyksen täytäntöönpanoa koskevista teknisistä eritelmistä ja säännöistä

(ETA:n kannalta merkityksellinen teksti)







1 artikla

EU:n digitaalisen koronatodistuksen tekniset eritelmät, joissa vahvistetaan yleinen tietorakenne, koodausmekanismit ja siirtokoodausmekanismi koneellisesti luettavassa optisessa muodossa, esitetään liitteessä I.

2 artikla

Asetuksen (EU) 2021/953 3 artiklan 1 kohdassa tarkoitettujen todistusten täyttämistä koskevat säännöt esitetään tämän päätöksen liitteessä II.

3 artikla

Yksilöllisen todistustunnuksen yhteistä rakennetta koskevat vaatimukset esitetään liitteessä III.

▼M1

4 artikla

Hallinnointisäännöt, joita sovelletaan julkisen avaimen varmenteisiin luottamuskehyksen yhteentoimivuusnäkökohtia tukevan EU:n digitaalisen koronatodistuksen yhdyskäytävän yhteydessä, esitetään liitteessä IV.

▼M1

5 artikla

Asetuksen (EU) 2021/953 3 artiklan 1 kohdassa tarkoitettuihin todistuksiin sisällytettävien tietojen yhteinen koordinoitu tietorakenne, jossa käytetään JSON-muotoa (JavaScript Object Notation), esitetään tämän päätöksen liitteessä V.

6 artikla

Tämä päätös tulee voimaan sinä päivänä, jona se julkaistaan Euroopan unionin virallisessa lehdessä.

▼B

Tämä päätös tulee voimaan sinä päivänä, jona se julkaistaan Euroopan unionin virallisessa lehdessä.









LIITE I

MUOTO JA LUOTTAMUKSEN HALLINTA

Yleinen tietorakenne, koodausmekanismit ja siirtokoodausmekanismi koneellisesti luettavassa optisessa muodossa (jäljempänä ’QR’)

1. Johdanto

Tässä liitteessä vahvistetut tekniset eritelmät sisältävät EU:n digitaalisen koronatodistuksen yleisen tietorakenteen ja koodausmekanismit. Niissä määritellään myös siirtokoodausmekanismi koneellisesti luettavassa optisessa muodossa (’QR’), joka voidaan näyttää mobiililaitteen kuvaruudulla tai tulostaa. Näissä eritelmissä kuvatut sähköisen terveystodistuksen säilömuodot ovat yleisiä, mutta tässä yhteydessä niitä käytetään digitaalisen koronatodistuksen esittämiseen.

2. Terminologia

Tässä liitteessä ’myöntäjillä’ tarkoitetaan organisaatioita, jotka käyttävät näitä eritelmiä terveystodistusten myöntämiseen, ja ’todentajilla’ organisaatioita, jotka hyväksyvät terveystodistukset todisteena terveydentilasta. ’Osallistujilla’ tarkoitetaan myöntäjiä ja todentajia. Osallistujien on koordinoitava joitakin tässä liitteessä esitettyjä näkökohtia, kuten nimitilan hallinnointia ja salausavainten jakelua. Oletetaan, että nämä tehtävät suorittaa osapuoli, jota kutsutaan jäljempänä ’sihteeristöksi’.

3. Sähköisen terveystodistuksen säilömuoto

Sähköisen terveystodistuksen säilömuoto (Electronic Health Certificate Container Format, HCERT) on suunniteltu siten, että se tarjoaa yhtenäisen ja standardoidun välineen eri myöntäjien terveystodistuksille. Näiden eritelmien tavoitteena on yhdenmukaistaa kyseisten terveystodistusten esitystapaa, koodausta ja allekirjoittamista yhteentoimivuuden helpottamiseksi.

Kyky lukea ja tulkita minkä tahansa myöntäjän myöntämää digitaalista koronatodistusta edellyttää yhteistä tietorakennetta ja yhteisymmärrystä hyötykuorman kunkin tietokentän merkityksestä. Yhteentoimivuuden helpottamiseksi yhteinen koordinoitu tietorakenne määritellään käyttämällä JSON-muotoa, joka muodostaa digitaalisen koronatodistuksen kehyksen.

3.1 Hyötykuorman rakenne

Hyötykuorma on jäsennelty ja koodattu tiiviiksi binääriobjektiesitykseksi (Concise Binary Object Representation, CBOR), jossa käytetään COSE-muotoista (CBOR Object Signing and Encryption) digitaalista allekirjoitusta. Tämä tunnetaan yleisesti nimellä ”CBOR Web Token” (CWT), ja se määritellään standardissa RFC 8392 ( 1 ). Seuraavissa kohdissa määritelty hyötykuorma siirretään hcert-väitteessä.

Todentajan on voitava todentaa hyötykuorman tietojen eheys ja aitous. Tämän mekanismin tarjoamiseksi myöntäjän on allekirjoitettava CWT käyttäen COSE-spesifikaatiossa (RFC 8152 ( 2 )) määriteltyä epäsymmetristä sähköistä allekirjoitusjärjestelmää.

3.2 CWT-väitteet

3.2.1 Yhteenveto CWT-rakenteesta

Suojattu otsikko

— Allekirjoitusalgoritmi (alg, tunniste 1)

— Avaimen tunniste (kid, tunniste 4)

Hyötykuorma

— Myöntäjä (iss, väiteavain 1, valinnainen, myöntäjän ISO 3166–1 alpha-2-koodi)

— Myönnetty (iat, väiteavain 6)

— Voimassaolon päättymisajankohta (exp, väiteavain 4)

— Terveystodistus (hcert, väiteavain -260)

— EU:n digitaalinen koronatodistus v1 (eu_DCC_v1, väiteavain 1)

Allekirjoitus

3.2.2 Allekirjoitusalgoritmi (Signature Algorithm)

Allekirjoitusalgoritmin (alg) parametri osoittaa, mitä algoritmia käytetään allekirjoituksen luomiseen. Sen on täytettävä tai ylitettävä nykyisten SOG-IS-suuntaviivojen vaatimukset, jotka esitetään tiivistetysti seuraavissa kohdissa.

Määritellään yksi ensisijainen ja yksi toissijainen algoritmi. Toissijaista algoritmia olisi käytettävä vain, jos ensisijainen algoritmi ei ole hyväksyttävissä myöntäjälle asetettujen sääntöjen ja määräysten mukaisesti.

Järjestelmän turvallisuuden varmistamiseksi kaikkiin toteutuksiin on sisällyttävä toissijainen algoritmi. Tästä syystä on otettava käyttöön sekä ensisijainen että toissijainen algoritmi.

Ensisijaisten ja toissijaisten algoritmien SOG-IS-tasot ovat seuraavat:

— Ensisijainen algoritmi: Ensisijainen algoritmi on ECDSA (Elliptic Curve Digital Signature Algorithm), sellaisena kuin se on määritelty standardin (ISO/IEC 14888–3:2006) 2.3 kohdassa, käyttäen standardin (FIPS PUB 186–4) lisäyksessä D (D.1.2.3) määriteltyjä P-256-parametreja yhdessä standardin (ISO/IEC 10118–3:2004) funktiossa 4 määritellyn SHA-256-hajautusalgoritmin kanssa.

Tämä vastaa COSE-algoritmin parametria ES256.

— Toissijainen algoritmi: Toissijainen algoritmi on RSASSA-PSS, sellaisena kuin se on määritelty standardissa (RFC 8230 ( 3 )) 2048-bitin moduluksella, yhdessä standardin (ISO/IEC 10118–3:2004) funktiossa 4 määritellyn SHA-256-hajautusalgoritmin kanssa.

Tämä vastaa COSE-algoritmin parametria PS256.

3.2.3 Avaimen tunniste (Key Identifier)

Avaimen tunnistetta (kid) koskeva väite näyttää asiakirjan allekirjoittajan varmenteen (Document Signer Certificate, DSC). Se sisältää julkisen avaimen, jota todentajan on käytettävä digitaalisen allekirjoituksen oikeellisuuden tarkistamiseen. Julkisen avaimen varmenteiden hallinnointi, mukaan lukien DSC-varmenteita koskevat vaatimukset, kuvataan liitteessä IV.

Todentajat käyttävät avaimen tunnistetta (kid) koskevaa väitettä oikean julkisen avaimen valitsemiseen myöntäjään liittyvästä avainluettelosta, joka ilmoitetaan myöntäjää (Issuer, iss) koskevassa väitteessä. Myöntäjä voi käyttää samanaikaisesti useita avaimia hallinnollisista syistä ja uusiessaan avaimia. Avaimen tunniste ei ole turvallisuuden kannalta kriittinen kenttä. Tästä syystä se voidaan tarvittaessa sijoittaa suojaamattomaan otsikkoon. Todentajien on hyväksyttävä molemmat vaihtoehdot. Jos molemmat vaihtoehdot ovat mahdollisia, avaimen tunniste on sijoitettava suojattuun otsikkoon.

Koska tunnistetta on lyhennetty (kokorajoituksiin liittyvistä syistä), on olemassa pieni mutta nollaa suurempi mahdollisuus, että todentajan hyväksymä yleinen DSC-luettelo voi sisältää DSC-varmenteita, joissa on sama kid. Tästä syystä todentajan on tarkistettava kaikki DSC-varmenteet, joissa on kyseinen kid.

3.2.4 Myöntäjä (Issuer)

Myöntäjää (iss) koskeva väite on merkkijonoarvo, jossa voi valinnaisesti olla terveystodistuksen myöntävän tahon ISO 3166–1 alpha-2 -maakoodi. Todentaja voi käyttää tätä väitettä määrittääkseen, mitä DSC-varmenteita todentamisessa käytetään. Tämän väitteen yksilöimiseen käytetään väiteavainta 1.

3.2.5 Voimassaolon päättymisajankohta (Expiration Time)

Voimassaolon päättymisajankohtaa (exp) koskevassa väitteessä on oltava NumericDate-kokonaislukumuodossa oleva aikaleima (siten kuin se on määritelty standardin RFC 8392 ( 4 ) 2 kohdassa), josta käy ilmi, kuinka kauan kyseisen hyötykuorman allekirjoituksen on katsottava olevan voimassa, minkä jälkeen todentajan on hylättävä hyötykuorma vanhentuneena. Voimassaolon päättymistä koskevan parametrin tarkoituksena on rajoittaa terveystodistuksen voimassaoloaikaa. Tämän väitteen yksilöimiseen käytetään väiteavainta 4.

Voimassaolon päättymisajankohta ei saa ylittää DSC-varmenteen voimassaoloaikaa.

3.2.6 Myönnetty (Issued At)

Myönnetty (iat) -väitteessä on oltava NumericDate-kokonaislukumuodossa oleva aikaleima (siten kuin se on määritelty standardin RFC 8392 ( 5 ) 2 kohdassa), josta käy ilmi terveystodistuksen laatimisajankohta.

Myönnetty-kentän arvo ei saa olla aikaisempi kuin DSC-varmenteen voimassaoloaika.

Todentajat voivat soveltaa muita toimintaperiaatteita terveystodistuksen voimassaolon rajoittamiseksi myöntämisajankohdan perusteella. Tämän väitteen yksilöimiseen käytetään väiteavainta 6.

3.2.7 Terveystodistusta koskeva väite (Health Certificate Claim)

Terveystodistusta (hcert) koskeva väite on standardin (RFC 7159 ( 6 )) mukainen JSON-objekti, joka sisältää terveydentilaa koskevat tiedot. Saman väitteen nojalla voi olla olemassa useita erityyppisiä terveystodistuksia, joista digitaalinen koronatodistus on yksi.

JSON on tarkoitettu yksinomaan rakenteen määrittelyyn. Esitysmuoto on CBOR, siten kuin se on määritelty standardissa (RFC 7049 ( 7 )). Sovelluskehittäjät eivät välttämättä koskaan pura koodia JSON-muodosta tai koodaa sitä JNOS-muotoon, vaan käyttävät muistissa olevaa rakennetta.

Tämän väitteen yksilöimiseen käytetään väiteavainta -260.

JSON-objektin merkkijonot olisi normalisoitava Unicode-standardissa määritellyn NFC-muodon (Normalization Form Canonical Composition) mukaisesti. Koodauksenpurkusovellusten olisi kuitenkin oltava tässä suhteessa sallivia ja vakaita, ja kaikkien kohtuudella odotettavissa olevien muuntamistyyppien hyväksymistä suositellaan voimakkaasti. Jos koodin purkamisen aikana tai myöhemmissä vertailutoiminnoissa havaitaan normalisoimattomia tietoja, toteutusten olisi toimittava ikään kuin syöte olisi normalisoitu NFC-muotoon.

4. Digitaalisen koronatodistuksen hyötykuorman sarjoittaminen ja luominen

Sarjoitusmallina käytetään seuraavaa skeemaa:

Prosessi alkaa tietojen keräämisestä esimerkiksi terveystietorekisteristä (tai jostain ulkoisesta tietolähteestä), jolloin kerätyt tiedot jäsennetään digitaalisen koronatodistuksen määriteltyjen rakenteiden mukaisesti. Tässä prosessissa muuntaminen määriteltyyn tietomuotoon ja muuttaminen ihmisluettavaan muotoon voi tapahtua ennen kuin sarjoittaminen CBOR-muotoon alkaa. Väitteiden lyhenteet on joka tapauksessa yhdistettävä näyttönimeen ennen sarjoittamista ja sarjoituksen poistamisen jälkeen.

Valinnaista kansallista tietosisältöä ei sallita asetuksen (EU) 2021/953 ( 8 ) mukaisesti myönnetyissä todistuksissa. Tietosisältö rajoittuu asetuksen (EU) 2021/953 liitteessä täsmennettyjen vähimmäistietojoukkojen määriteltyihin tietoelementteihin.

5. Siirtokoodaus

5.1 Raaka

Satunnaisissa tietoliitännöissä HCERT-säilö ja sen hyötykuormat voidaan siirtää sellaisinaan käyttäen mitä tahansa pohjana olevaa 8-bittistä, turvallista ja luotettavaa tiedonsiirtoa. Näihin liitäntöihin voi sisältyä lähitiedonsiirto (Near-Field Communication, NFC), Bluetooth tai siirto sovelluskerroksen protokollan kautta, esimerkiksi HCERT:n siirtäminen myöntäjältä haltijan mobiililaitteeseen.

Jos HCERT:n siirtäminen myöntäjältä haltijalle perustuu pelkän esitystapakerroksen sisältävään rajapintaan (esim. tekstiviesti, sähköposti), raakaa siirtokoodausta ei tietenkään voida soveltaa.

5.2 Viivakoodi

5.2.1 Hyötykuorman (CWT) pakkaaminen

HCERT:n koon pienentämiseksi ja lukuprosessin nopeuden ja luotettavuuden parantamiseksi CWT pakataan ZLIB:llä (RFC 1950 ( 9 )) ja Deflate-pakkausmenetelmällä standardissa RFC 1951 ( 10 ) määritellyssä muodossa.

5.2.2 QR 2D -viivakoodi

Jotta voidaan hallita paremmin vanhoja laitteita, jotka on suunniteltu toimimaan ASCII-hyötykuormilla, pakattu CWT koodataan ASCII-muotoon käyttäen Base45-koodausta ennen kuin se koodataan 2D-viivakoodiksi.

2D-viivakoodin luomisessa käytetään standardissa (ISO/IEC 18004:2015) määriteltyä QR-formaattia. Virheenkorjaustasoksi suositellaan Q (noin 25 prosenttia). Koska käytetään Base45:a, QR-koodissa on käytettävä aakkosnumeerista koodausta (Mode 2, ilmaistaan symboleilla 0010).

Jotta todentajat pystyvät havaitsemaan koodattujen tietojen tyypin ja valitsemaan oikean koodinpurku- ja käsittelymenetelmän, (tämän eritelmän mukaisesti) Base45-koodatuille tiedoille on annettava etuliitteeksi kontekstitunnisterivi ”HC1:”. Tämän eritelmän tulevissa versioissa, jotka vaikuttavat yhteensopivuuteen taaksepäin, määritellään uusi kontekstitunniste, jossa ”HC”:tä seuraava merkki valitaan merkkijoukosta [1–9A-Z]. Lisäykset tehdään edellä olevassa järjestyksessä, eli ensin [1–9] ja sitten [A-Z].

Suositellaan, että optinen koodi renderoidaan esitysvälineessä siten, että sen läpimitta on 35–60 mm, jotta se soveltuu lukulaitteille, joissa on kiinteä optiikka ja joissa esitysväline on sijoitettava lukulaitteen pinnalle.

Jos optinen koodi painetaan paperille käyttäen matalaresoluutioisia (< 300 dpi) tulostimia, on huolehdittava siitä, että QR-koodin jokainen symboli (piste) on täsmälleen neliö. Ei-suhteellinen skaalaus johtaa siihen, että QR-koodin joillakin riveillä tai joissakin sarakkeissa on suorakulmaisia symboleja, mikä vaikeuttaa luettavuutta monissa tapauksissa.

6. Luottamusluettelon muoto (CSCA- ja DSC-luettelo)

Kunkin jäsenvaltion on toimitettava luettelo yhdestä tai useammasta kansallisesta juurivarmentajasta (Country Signing Certificate Authority, CSCA) ja luettelo kaikista voimassa olevista asiakirjan allekirjoittajan varmenteista (Document Signing Certificate, DSC) ja pidettävä luettelot ajan tasalla.

6.1 Yksinkertaistettu CSCA/DSC

Eritelmän tästä versiosta alkaen jäsenvaltiot eivät saa olettaa, että mitään varmenteiden sulkulistaa (Certificate Revocation List, CRL) koskevia tietoja käytetään tai että todentajat tarkistavat yksityisen avaimen käyttöajan.

Sen sijaan ensisijainen voimassaolon tarkistusmekanismi on se, että varmenne on merkitty kyseisen varmenneluettelon viimeisimpään versioon.

6.2 ICAOn eMRTD-matkustusasiakirjan PKI ja luottamuskeskukset

Jäsenvaltiot voivat käyttää erillistä CSCA-varmennetta, mutta ne voivat myös toimittaa olemassa olevat sirullisen koneluettavan matkustusasiakirjan (eMRTD) CSCA- ja/tai DSC-varmenteet, ja ne voivat jopa hankkia varmenteet (kaupallisilta) luottamuskeskuksilta ja toimittaa ne. Kyseisen jäsenvaltion ilmoittaman CSCA:n on kuitenkin aina allekirjoitettava kaikki DSC-varmenteet.

7. Turvallisuusnäkökohdat

Suunnitellessaan järjestelmää, jossa käytetään tätä eritelmää, jäsenvaltioiden on määriteltävä ja analysoitava tietyt turvallisuusnäkökohdat ja seurattava niitä.

Huomioon olisi otettava vähintään seuraavat seikat:

7.1 HCERT:n allekirjoituksen voimassaoloaika

HCERT:n myöntäjän on rajoitettava allekirjoituksen voimassaoloaikaa määrittämällä allekirjoituksen voimassaolon päättymisajankohta. Tämä edellyttää, että terveystodistuksen haltija uusii sen säännöllisin väliajoin.

Hyväksyttävä voimassaoloaika voidaan määritellä käytännön rajoitteiden perusteella. Esimerkiksi matkustajalla ei välttämättä ole mahdollisuutta uusia terveystodistusta ulkomaanmatkan aikana. Voi kuitenkin käydä myös niin, että myöntäjä näkee mahdollisuuden jonkinlaiseen turvallisuuden vaarantumiseen, mikä edellyttää, että myöntäjä peruuttaa DSC-varmenteen (mikä mitätöi kaikki kyseisellä avaimella myönnetyt terveystodistukset, vaikka todistusten voimassaoloaika ei ole vielä kulunut umpeen). Tällaisen tapahtuman seurauksia voidaan rajoittaa ottamalla säännöllisesti käyttöön uusia myöntäjän avaimia ja edellyttämällä kaikkien terveystodistusten uusimista kohtuullisin määräajoin.

7.2 Avainten hallinta

Tämä eritelmä perustuu suurelta osin vahvoihin salausmekanismeihin tietojen eheyden ja tietojen alkuperän todentamisen turvaamiseksi. Sen vuoksi on tarpeen säilyttää yksityisten avainten luottamuksellisuus.

Salausavainten luottamuksellisuus voi vaarantua useilla eri tavoilla, esimerkiksi seuraavasti:

— Avainten luomisprosessi voi olla virheellinen, mikä johtaa heikkoihin avaimiin.

— Avaimet voivat paljastua inhimillisen erehdyksen vuoksi.

— Ulkopuoliset tai sisäiset tunkeutujat voivat varastaa avaimet.

— Avaimet voidaan laskea kryptoanalyysilla.

Jotta voidaan vähentää riskiä, että allekirjoitusalgoritmi osoittautuu heikoksi ja mahdollistaa yksityisten avaimien vaarantumisen kryptoanalyysin avulla, tässä eritelmässä suositellaan, että kaikki osallistujat ottavat käyttöön varalla olevan toissijaisen allekirjoitusalgoritmin, joka perustuu erilaisiin parametreihin tai erilaiseen matemaattiseen ongelmaan kuin ensisijainen algoritmi.

Edellä mainittujen myöntäjien toimintaympäristöön liittyvien riskien osalta on toteutettava lieventäviä toimenpiteitä tehokkaan valvonnan varmistamiseksi, kuten yksityisten avainten luominen, tallentaminen ja käyttö laitteistoturvamoduuleissa (Hardware Security Module, HSM). HSM-laitteiden käyttö terveystodistusten allekirjoittamisessa on erittäin suositeltavaa.

Riippumatta siitä, päättääkö myöntäjä käyttää HSM-laitteita vai ei, olisi laadittava avainten uusimisaikataulu, jossa avainten uusimistiheys on oikeassa suhteessa avainten altistumiseen ulkoisille verkoille, muille järjestelmille ja henkilöstölle. Hyvin valittu uusimisaikataulu rajoittaa myös virheellisesti myönnettyihin terveystodistuksiin liittyviä riskejä ja antaa myöntäjälle mahdollisuuden peruuttaa tällaiset terveystodistukset tarvittaessa erissä kumoamalla avaimen.

7.3 Syöttötietojen validointi

Näitä eritelmiä voidaan käyttää tavalla, jossa tietoja vastaanotetaan epäluotetuista lähteistä järjestelmiin, jotka voivat olla tehtävän kannalta kriittisiä. Tähän hyökkäysvektoriin liittyvien riskien minimoimiseksi kaikki syöttökentät on validoitava asianmukaisesti tietotyyppien, pituuksien ja sisällön suhteen. Myös myöntäjän allekirjoitus on tarkistettava ennen HCERT:n sisällön käsittelyä. Myöntäjän allekirjoituksen validointi edellyttää kuitenkin, että ensin jäsennetään suojattu myöntäjän otsikko, johon mahdollinen hyökkääjä voi yrittää syöttää taitavasti suunniteltuja tietoja järjestelmän turvallisuuden vaarantamiseksi.

8. Luottamuksen hallinta

HCERT:n allekirjoituksen todentaminen edellyttää julkista avainta. Jäsenvaltioiden on asetettava nämä julkiset avaimet saataville. Viime kädessä jokaisella todentajalla on oltava luettelo kaikista julkisista avaimista, joihin se on halukas luottamaan (koska julkinen avain ei ole osa HCERT:ä).

Järjestelmä koostuu (vain) kahdesta kerroksesta: kunkin jäsenvaltion osalta yksi tai useampi maakohtainen varmenne, jolla kullakin allekirjoitetaan yksi tai useampi päivittäisessä toiminnassa käytettävä asiakirjan allekirjoittajan varmenne.

Jäsenvaltioiden varmenteita kutsutaan CSCA-varmenteiksi (Country Signing Certificate Authority), ja ne ovat (tyypillisesti) itse allekirjoitettuja. Jäsenvaltioilla voi olla niitä useampi kuin yksi (esimerkiksi jos hallinto on hajautettu alueellisesti). Näillä CSCA-varmenteilla allekirjoitetaan tavallisesti HCERT-todistusten allekirjoittamiseen käytettävät asiakirjan allekirjoittajan varmenteet (DSC).

”Sihteeristöllä” on toiminnallinen tehtävä. Se kokoaa ja julkaisee säännöllisesti jäsenvaltioiden DSC-varmenteet tarkastettuaan ne suhteessa CSCA-varmenteiden luetteloon (joka on toimitettu ja todennettu muulla tavoin).

Tuloksena saatavassa DSC-varmenneluettelossa on esitettävä kootut hyväksyttävät julkiset avaimet (ja vastaavat kid-tunnisteet), joita todentajat voivat käyttää validoidakseen HCERT-todistusten allekirjoitukset. Todentajien on haettava luettelo ja päivitettävä se säännöllisesti.

Näiden jäsenvaltiokohtaisten luettelojen muotoa voidaan mukauttaa kunkin jäsenvaltion kansallisten olosuhteiden mukaan. Tämän luottamusluettelon tiedostomuoto voi vaihdella; se voi olla esimerkiksi allekirjoitettu JWKS (standardin RFC 7517 ( 11 ) 5 jakson mukainen JWK Set -muoto) tai mikä tahansa muu kyseisessä jäsenvaltiossa käytetylle teknologialle ominainen muoto.

Yksinkertaisuuden vuoksi jäsenvaltiot voivat toimittaa olemassa olevat CSCA-varmenteensa ICAOn eMRTD-järjestelmistä tai luoda WHO:n suosituksen mukaisesti nimenomaan tätä terveydenhuollon toimialuetta koskevan varmenteen.

8.1 Avaimen tunniste (kid)

Avaimen tunniste (kid) lasketaan, kun laaditaan luotettujen julkisten avainten luettelo DSC-varmenteista, ja se koostuu DER-(raaka)muodossa koodatun DSC-varmenteen katkaistusta (ensimmäiset 8 bittiä) SHA-256-sormenjäljestä.

Todentajien ei tarvitse laskea kid-tunnistetta DSC-varmenteen perusteella, vaan ne voivat suoraan verrata myönnetyssä terveystodistuksessa käytettyä avaimen tunnistetta luottamusluettelossa olevaan kid-tunnisteeseen.

8.2 Erot ICAOn eMRTD:n PKI-luottamusmalliin

Nämä eritelmät perustuvat ICAOn eMRTD-matkustusasiakirjan PKI-luottamusmallia koskeviin parhaisiin käytäntöihin, mutta nopeuden vuoksi niihin on tehty joitain yksinkertaistuksia:

— Jäsenvaltio voi toimittaa useita CSCA-varmenteita.

— DSC-varmenteen (avaimen käytön) voimassaoloaika voi olla mikä tahansa aika, joka ei ylitä CSCA-varmenteen voimassaoloaikaa, tai se voidaan jättää pois.

— DSC-varmenne voi sisältää erityisesti terveystodistuksiin liittyviä käyttökäytäntöjen tunnisteita (laajennettu avaimen käyttö).

— Jäsenvaltiot voivat päättää olla tarkistamatta julkaistuja peruutuksia, vaan ne voivat sen sijaan käyttää pelkkiä DSC-luetteloja, jotka ne saavat päivittäin sihteeristöltä tai kokoavat itsensä.

▼M1









LIITE II

EU:N DIGITAALISEN KORONATODISTUKSEN TÄYTTÖOHJEET

Tässä liitteessä vahvistetuilla arvojoukkoja koskevilla yleisillä säännöillä pyritään varmistamaan yhteentoimivuus semanttisella tasolla ja mahdollistetaan EU:n digitaalisen koronatodistuksen yhdenmukainen tekninen toteutus. Tässä liitteessä olevia elementtejä voidaan käyttää asetuksen (EU) 2021/953 mukaisissa kolmessa eri tilanteessa (rokotus/testaus/taudista parantuminen). Tässä liitteessä luetellaan ainoastaan elementit, jotka edellyttävät semanttista standardointia koodattujen arvojoukkojen avulla.

Koodattujen elementtien kääntäminen kansalliselle kielelle on jäsenvaltioiden vastuulla.

Liitteessä V kuvataan kaikkien niiden tietokenttien koodaus, joita ei mainita seuraavissa arvojoukkojen kuvauksissa.

Jos jäljempänä lueteltuja suositeltavia koodijärjestelmiä ei jostain syystä voida käyttää, voidaan käyttää muita kansainvälisiä koodijärjestelmiä ja antaa ohjeita siitä, miten muiden koodijärjestelmien koodit vastaavat suositeltavaa koodijärjestelmää. Tekstiä (näyttönimiä) voidaan poikkeustapauksissa käyttää varamekanismina, jos määritellyissä arvojoukoissa ei ole saatavilla sopivaa koodia.

Jäsenvaltioiden, jotka käyttävät järjestelmissään muita koodeja, on määritettävä, kuinka nämä koodit liittyvät kuvattuihin arvojoukkoihin. Jäsenvaltiot vastaavat tällaisista määrityksistä.

Koska jotkin tässä liitteessä esitettyihin koodausjärjestelmiin perustuvat arvojoukot, kuten rokotteen ja antigeenipikatestin koodauksen arvojoukot, muuttuvat usein, komissio julkaisee ne ja päivittää niitä säännöllisesti sähköisten terveyspalvelujen verkoston ja terveysturvakomitean tuella. Päivitetyt arvojoukot julkaistaan asiaa koskevalla komission verkkosivustolla sekä sähköisten terveyspalvelujen verkoston verkkosivustolla. Muutoshistoria on esitettävä.

1. Kyseessä oleva tauti tai taudinaiheuttaja / Tauti tai taudinaiheuttaja, josta todistuksen haltija on parantunut: covid-19 (SARS-CoV-2 tai jokin sen muunnoksista)

Käytetään todistuksissa 1, 2 ja 3.

Käytettävä seuraavaa koodia:







Koodi Näyttö Koodijärjestelmän nimi Koodijärjestelmän URL Koodijärjestelmän OID Koodijärjestelmän versio 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

2. Covid-19-rokote tai -estolääkitys

Suositeltava koodijärjestelmä: SNOMED CT tai ATC-luokitus.

Käytetään todistuksessa 1.

Esimerkkejä suositeltavien koodijärjestelmien koodeista, joita on käytettävä, ovat SNOMED CT -koodi 1119305005 (SARS-CoV-2-antigeenirokote), 1119349007 (SARS-CoV-2-mRNA-rokote) tai J07BX03 (covid-19-rokotteet).

Komissio julkaisee sähköisten terveyspalvelujen verkoston tuella arvojoukon, jossa esitetään tässä jaksossa vahvistettujen koodijärjestelmien mukaisesti käytettävät koodit, ja päivittää sitä säännöllisesti. Arvojoukkoa on laajennettava, kun uusia rokotetyyppejä kehitetään ja otetaan käyttöön.

3. Covid-19-rokotevalmiste

Suositeltavat koodijärjestelmät (suosituimmuusjärjestyksessä):

— Unionin lääkerekisteri rokotteille, joilla on EU:n laajuinen myyntilupa (lupien numerot)

— Maailmanlaajuinen rokoterekisteri, jonka Maailman terveysjärjestö voisi perustaa

— Muissa tapauksissa rokotevalmisteen nimi. Jos nimi sisältää välilyöntejä, ne on korvattava yhdysmerkillä (-).

Arvojoukon nimi: Rokote.

Käytetään todistuksessa 1.

Esimerkki suositeltavien koodijärjestelmien koodista, jota on käytettävä, on EU/1/20/1528 (Comirnaty). Esimerkki koodina käytettävästä rokotteen nimestä: Sputnik-V (rokotteesta Sputnik V).

Komissio julkaisee sähköisten terveyspalvelujen verkoston tuella arvojoukon, jossa esitetään tässä jaksossa vahvistettujen koodijärjestelmien mukaisesti käytettävät koodit, ja päivittää sitä säännöllisesti.

Rokotteet koodataan julkaistuun arvojoukkoon sisältyvän olemassa olevan koodin avulla, vaikka niiden nimet olisivat erilaiset eri maissa. Tämä johtuu siitä, että vielä ei ole olemassa maailmanlaajuista rokoterekisteriä, joka kattaisi kaikki tällä hetkellä käytössä olevat rokotteet. Esimerkki:

— Rokotteesta ”Covid-19 Vaccine Moderna Intramuscular Injection”, joka on Spikevax-rokotteen nimi Japanissa, käytetään koodia EU/1/20/1507, koska se on tämän rokotteen nimi EU:ssa.

Jos tämä ei ole mahdollista tai suositeltavaa tietyssä tapauksessa, julkaistussa arvojoukossa annetaan erillinen koodi.

4. Covid-19-rokotteen myyntiluvan haltija tai valmistaja

Suositeltava koodijärjestelmä:

— EMA:n antama organisaation koodi (ISO IDMP-standardien mukainen SPOR-tietokanta)

— Rokotteen myyntiluvan haltijoiden tai valmistajien maailmanlaajuinen rekisteri, jonka Maailman terveysjärjestö voisi perustaa

— Muissa tapauksissa organisaation nimi. Jos nimi sisältää välilyöntejä, ne on korvattava yhdysmerkillä (-).

Käytetään todistuksessa 1.

Esimerkki suositeltavan koodijärjestelmän koodista, jota on käytettävä, on ORG-100001699 (AstraZeneca AB). Esimerkki koodina käytettävästä organisaation nimestä: Sinovac-Biotech (organisaatiosta Sinovac Biotech).

Komissio julkaisee sähköisten terveyspalvelujen verkoston tuella arvojoukon, jossa esitetään tässä jaksossa vahvistettujen koodijärjestelmien mukaisesti käytettävät koodit, ja päivittää sitä säännöllisesti.

Saman myyntiluvan haltijan tai valmistajan eri tytäryhtiöiden on käytettävä julkaistuun arvojoukkoon sisältyvää olemassa olevaa koodia.

Yleissääntönä on, että samasta rokotevalmisteesta on käytettävä koodia, joka viittaa sen myyntiluvan haltijaan EU:ssa, koska kansainvälisesti sovittua rokotteen valmistajien tai myyntiluvan haltijoiden rekisteriä ei ole vielä olemassa. Esimerkkejä:

— Yrityksestä ”Pfizer AG”, joka on Sveitsissä käytettävän rokotteen ”Comirnaty” myyntiluvan haltija, käytetään koodia ORG-100030215, joka viittaa yritykseen BioNTech Manufacturing GmbH, koska se on Comirnatyn myyntiluvan haltija EU:ssa.

— Yrityksestä ”Zuellig Pharma”, joka on Filippiineillä käytettävän rokotteen ”Covid-19 Vaccine Moderna (Spikevax)” myyntiluvan haltija, käytetään koodia ORG-100031184, joka viittaa yritykseen Moderna Biotech Spain S.L., koska se on Spikevaxin myyntiluvan haltija EU:ssa.

Jos tämä ei ole mahdollista tai suositeltavaa tietyssä tapauksessa, julkaistussa arvojoukossa annetaan erillinen koodi.

5. Annosnumero rokotussarjassa ja sarjarokotteen annosten kokonaismäärä

Käytetään todistuksessa 1.

Kaksi kenttää:

1) Covid-19-rokotteen annosnumero rokotussarjassa (N)

2) Rokotussarjaan sisältyvien annosten kokonaismäärä (C)

5.1 Ensimmäinen rokotussarja

Kun henkilö saa annoksia ensimmäisestä rokotussarjasta eli rokotussarjasta, jonka tarkoituksena on tarjota riittävä alkuvaiheen suoja, C vastaa tavanomaiseen ensimmäiseen rokotussarjaan sisältyvien annosten kokonaismäärää (esim. 1 tai 2 annetun rokotetyypin mukaan). Tähän sisältyy mahdollisuus käyttää lyhyempää sarjaa (C=1), kun jäsenvaltiossa sovellettavan rokotusohjelman mukaan henkilöille, jotka ovat aiemmin saaneet SARS-CoV-2-tartunnan, voidaan antaa yksi annos kahtena annoksena annettavaa rokotetta. Valmistunut ensimmäinen rokotussarja esitetään siten kaavalla N/C=1. Esimerkiksi:

— 1/1 tarkoittaa yhtenä annoksena annettavan ensimmäisen rokotussarjan loppuun saattamista tai sellaisen ensimmäisen sarjan loppuun saattamista, joka koostuu yhdestä annoksesta kahtena annoksena annettavaa rokotetta, joka on annettu taudista parantuneelle henkilölle jäsenvaltion soveltaman rokotusohjelman mukaisesti;

— 2/2 tarkoittaa kahtena annoksena annettavan ensimmäisen rokotussarjan loppuun saattamista.

Jos ensimmäistä rokotussarjaa täydennetään esimerkiksi henkilöille, joilla on vakavasti heikentynyt immuunijärjestelmä, tai jos ensimmäisten annosten välistä suositeltavaa aikaväliä ei ole noudatettu, tällaiset annokset on koodattava 5.2 kohdan mukaisina lisäannoksina.

▼M2

5.2. Tehosteannokset

Jos henkilö saa annoksia ensimmäisen rokotussarjan jälkeen, tällaiset tehosteannokset on otettava huomioon vastaavissa todistuksissa seuraavasti:

— 2/1 tarkoittaa tehosteannoksen antamista yhtenä annoksena annettavan ensimmäisen rokotussarjan jälkeen tai tehosteannoksen antamista sellaisen ensimmäisen sarjan jälkeen, joka koostuu yhdestä annoksesta kahtena annoksena annettavaa rokotetta, joka on annettu taudista parantuneelle henkilölle jäsenvaltion soveltaman rokotusohjelman mukaisesti. Tämän jälkeen ensimmäisen tehosteannoksen jälkeen annetut annokset (X) esitetään kaavalla (2+X)/(1) > 1 (esimerkiksi 3/1);

— 3/3 tarkoittaa tehosteannoksen antamista kahtena annoksena annettavan ensimmäisen rokotussarjan jälkeen. Tämän jälkeen ensimmäisen tehosteannoksen jälkeen annetut annokset (X) esitetään kaavalla (3+X)/(3+X) = 1 (esimerkiksi 4/4).

Jäsenvaltioiden on pantava tässä jaksossa vahvistetut koodaussäännöt täytäntöön viimeistään 1 päivänä helmikuuta 2022.

Jäsenvaltioiden on automaattisesti tai asianomaisten henkilöiden pyynnöstä myönnettävä uudelleen todistukset, joissa tehosteannoksen antaminen yhtenä annoksena annettavan ensimmäisen rokotussarjan jälkeen on koodattu siten, ettei sitä voida erottaa ensimmäisen rokotussarjan loppuun saattamisesta.

Tässä liitteessä olevien viittausten ”tehosteannoksiin” olisi katsottava tarkoittavan myös lisäannoksia, joita annetaan suojaamaan paremmin henkilöitä, joiden immuunivaste on riittämätön ensimmäisen perusrokotussarjan valmistumisen jälkeen. Jäsenvaltiot voivat asetuksella (EU) 2021/953 vahvistetun oikeudellisen kehyksen puitteissa toteuttaa toimenpiteitä puuttuakseen sellaisten haavoittuvassa asemassa olevien ryhmien tilanteeseen, jotka voivat saada lisäannoksia ensisijaisesti. Jos jäsenvaltio esimerkiksi päättää antaa lisäannoksia vain tietyille väestön alaryhmille, se voi asetuksen (EU) 2021/953 5 artiklan 1 kohdan mukaisesti valita, että rokotustodistuksia, joissa osoitetaan tällaisten lisäannosten antaminen, myönnetään vain pyynnöstä eikä automaattisesti. Jos tällaisia toimenpiteitä toteutetaan, jäsenvaltioiden on ilmoitettava asianomaisille henkilöille asiasta sekä siitä, että he voivat edelleen käyttää todistusta, joka on saatu ensimmäisen perusrokotussarjan valmistuttua.

▼M1

6. Jäsenvaltio tai kolmas maa, jossa rokote annettiin / testi tehtiin

Suositeltava koodijärjestelmä: ISO 3166 -maakoodit.

Käytetään todistuksissa 1, 2 ja 3.

Arvojoukon sisältö: täydellinen luettelo 2-kirjaimista koodeista, jotka ovat saatavilla FHIR-standardissa määriteltynä arvojoukkona (http://hl7.org/fhir/ValueSet/iso3166-1-2). Jos rokotuksen tai testin on tehnyt kansainvälinen organisaatio (kuten UNHCR tai WHO) eikä maasta ole saatavilla tietoja, on käytettävä organisaation koodia. Komissio julkaisee tällaiset lisäkoodit ja päivittää niitä säännöllisesti sähköisten terveyspalvelujen verkoston tuella.

7. Testin tyyppi

Käytetään todistuksessa 2 sekä todistuksessa 3, jos delegoidulla säädöksellä otetaan käyttöön tuki taudista parantumista koskevien todistusten myöntämiselle muiden testityyppien kuin NAAT-testin perusteella.

Seuraavia koodeja on käytettävä:







Koodi Näyttö Koodijärjestelmän nimi Koodijärjestelmän URL Koodijärjestelmän OID Koodijärjestelmän versio LP6464-4 Nukleiinihappotesti koettimen määrityksellä LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Nopea immuunimääritys LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

8. Käytetyn testin valmistaja ja myyntinimike (NAAT-testin osalta valinnainen)

Käytetään todistuksessa 2.

Arvojoukon sisällön muodostaa antigeenipikatestien valikoima, joka on lueteltu neuvoston suosituksen 2021/C 24/01 perusteella laaditussa ja terveysturvakomitean hyväksymässä covid-19-antigeenipikatestien yhteisessä päivitetyssä luettelossa. JRC ylläpitää luetteloa covid-19-taudin in vitro -diagnostiikkaan tarkoitettujen laitteiden ja testimenetelmien tietokannassa, joka on saatavilla osoitteessa: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

Tässä koodijärjestelmässä on käytettävä asianmukaisia kenttiä, kuten testilaitteen tunniste, testin nimi ja valmistaja, käyttäen JRC:n jäsenneltyä muotoa, joka on saatavilla osoitteessa: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9. Testin tulos

Käytetään todistuksessa 2.

Seuraavia koodeja on käytettävä:







Koodi Näyttö Koodijärjestelmän nimi Koodijärjestelmän URL Koodijärjestelmän OID Koodijärjestelmän versio 260415000 Ei havaittu SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Havaittu SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼B









LIITE III

YKSILÖLLISEN TODISTUSTUNNUKSEN YHTEINEN RAKENNE

1. Johdanto

Jokaisella EU:n digitaalisella koronatodistuksella on oltava yksilöllinen todistustunnus (Unique Certificate Identifier, UCI), joka tukee digitaalisten koronatodistusten yhteentoimivuutta. UCI-tunnistetta voidaan käyttää todistuksen todentamiseen. Jäsenvaltiot vastaavat UCI-tunnisteen täytäntöönpanosta. UCI-tunniste on keino tarkistaa todistuksen todenmukaisuus ja tarvittaessa linkittää se rekisteröintijärjestelmään (esim. IIS-rokotustietojärjestelmään). Näiden tunnisteiden on myös mahdollistettava jäsenvaltioiden (paperiset ja digitaaliset) vakuutukset siitä, että henkilöt on rokotettu tai testattu.

2. Yksilöllisen todistustunnuksen sisältö

UCI-tunnisteen on noudatettava yhteistä rakennetta ja muotoa, joilla helpotetaan ihmisen tekemää ja/tai koneellista tietojen tulkintaa, ja se voi liittyä esimerkiksi rokotusjäsenvaltioon, itse rokotteeseen ja jäsenvaltiokohtaiseen tunnisteeseen. Sillä varmistetaan, että jäsenvaltiot voivat muotoilla sen joustavasti tietosuojalainsäädäntöä täysimääräisesti noudattaen. Erillisten osien järjestys noudattaa määriteltyä hierarkiaa, joka mahdollistaa lohkojen myöhemmät muutokset säilyttäen samalla niiden rakenteellisen eheyden.

UCI-tunnisteen muodostamista koskevat mahdolliset ratkaisut muodostavat jatkumon, jossa modulaarisuus ja ihmisen tulkittavissa oleminen ovat kaksi tärkeintä vaihtelevaa parametria ja jossa on yksi perusominaisuus:

— Modulaarisuus: se, missä määrin koodi koostuu erillisistä rakenneosista, jotka sisältävät semanttisesti erilaisia tietoja

— Ihmisen tulkittavissa oleminen: se, missä määrin koodi on merkityksellinen sitä lukevalle ihmiselle tai tämän tulkittavissa

— Globaalisti ainutlaatuinen; maan tai viranomaisen tunnistetta hallinnoidaan hyvin, ja kunkin maan (viranomaisen) odotetaan hallinnoivan omaa nimiavaruuden segmenttiään hyvin siten, ettei tunnisteita koskaan kierrätetä tai annetaan uudelleen. Näiden yhdistelmällä varmistetaan, että jokainen tunniste on globaalisti ainulaatuinen.

▼M1

3. Yleiset vaatimukset

UCI-tunnisteiden on täytettävä seuraavat yleiset vaatimukset:

1) Merkistö: ainoastaan isot aakkosnumeeriset US-ASCII-merkit (A–Z, 0–9) ovat sallittuja; lisäksi erottimina voidaan käyttää standardin RFC3986 ( 12 ) mukaisia erikoismerkkejä, kuten ”/”,”#”,”:”;

2) Enimmäispituus: suunnittelijoiden olisi pyrittävä tavoittelemaan 27–30 merkin pituutta ( 13 );

3) Version etuliite: tällä viitataan UCI-rakenteen versioon. Asiakirjan tämän version etuliite on ”01”; version etuliite koostuu kahdesta numerosta;

4) Maan etuliite: maakoodi määritellään standardissa ISO 3166-1. Pidemmät koodit (esim. kolme merkkiä ja enemmän (esimerkiksi ”UNHCR”)) varataan myöhempään käyttöön;

5) Koodin jälkiliite / tarkistussumma: 5.1 Jäsenvaltiot voivat käyttää tarkistussummaa, kun on todennäköistä, että tunniste voidaan siirtää tai kopioida (ihmisen toimesta) tai siihen voidaan puuttua muulla tavoin (eli kun tunnistetta käytetään tulosteena). 5.2 Tarkistussummaa ei saa käyttää todistuksen validoimiseen, eikä se ole teknisesti osa tunnistetta, vaan sitä käytetään koodin eheyden todentamiseen. Tarkistussumman on oltava ISO-7812-1 (LUHN-10) ( 14 ) -kooste koko UCI-tunnisteesta digitaalisessa/langallisessa siirtomuodossa. Tarkistussumma erotetaan muusta UCI-tunnisteesta merkillä ”#”.

Yhteensopivuus taaksepäin on varmistettava: jäsenvaltioiden, jotka ajan mittaan muuttavat tunnisteidensa rakennetta (pääversiossa, joka on tällä hetkellä v1), on varmistettava, että kaksi samanlaista tunnistetta vastaavat samaa rokotustodistusta/-vakuutusta. Toisin sanoen jäsenvaltiot eivät voi kierrättää tunnisteita.

▼B

4. Rokotustodistusten yksilöllisten todistustunnusten vaihtoehdot

Sähköisen terveydenhuollon verkoston laatimissa todennettavissa olevia rokotustodistuksia ja yhteentoimivuuden perustekijöitä koskevissa suuntaviivoissa ( 15 ) esitetään jäsenvaltioille ja muille osapuolille erilaisia vaihtoehtoja, joita voidaan soveltaa samanaikaisesti eri jäsenvaltioissa. Jäsenvaltiot voivat käyttää tällaisia eri vaihtoehtoja UCI-rakenteen eri versioissa.









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ä NB TLS -asiakasvarmenteista;

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

— DCCG ylläpitää NB CSCA -varmenteiden luottamusluetteloa, joka on allekirjoitettu DCCG TA -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 NB TLS

— Jäsenvaltion latausvarmenne NB UP

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

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ää NB CSCA -varmenteen(-varmenteet) luottamusluetteloon, joka on allekirjoitettu DCCG TA :n julkista avainta vastaavalla yksityisellä avaimella;

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

— lisää NB UP -varmenteen DCCG-järjestelmään;

— toimittaa julkisen avaimen DCCG TA - ja DCCG TLS -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 ( 16 ) tai SOG-IS:n asiakirjasta Agreed Cryptographic Mechanisms ( 17 ).

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 ( 18 ) 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 ( 19 ) 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 (1) , o=<Tarjoaja>, c=<maa> Key Usage digital signature (vähintään) ( 1 ) 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.

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

▼M1









LIITE V

JSON-MUOTO (JAVASCRIPT OBJECT NOTATION)

1. Johdanto

Tässä liitteessä määritellään EU:n digitaalisen koronatodistuksen tekninen tietorakenne, joka esitetään JSON-muotona. Asiakirjassa annetaan yksittäisiä tietokenttiä koskevia erityisohjeita.

2. JSON-muodon sijainti ja versiot

EU:n digitaalisen koronatodistuksen ainoa autenttinen virallinen JSON-muoto on saatavilla osoitteessa: https://github.com/ehn-dcc-development/ehn-dcc-schema. Muut sijainnit eivät ole autenttisia, mutta niitä voidaan käyttää tulevien tarkistusten valmisteluun.

Ilmoitetussa URL-osoitteessa esitetään oletusarvoisesti tämän liitteen mukainen nykyinen käytössä oleva versio, jota kaikki maat tukevat.

Tuleva seuraava versio, jota kaikkien maiden on tuettava tiettyyn päivämäärään mennessä, esitetään ilmoitetussa URL-osoitteessa version tunnisteen avulla, joka kuvataan tarkemmin Readme-tiedostossa.

3. Yhteiset rakenteet ja yleiset vaatimukset

EU:n digitaalista koronatodistusta ei myönnetä, jos kaikkia tietokenttiä ei voida täyttää oikein tämän eritelmän mukaisesti, koska tietoja puuttuu. Tätä ei saa tulkita niin, että se vaikuttaisi jäsenvaltioiden velvollisuuteen myöntää EU:n digitaalisia rokotustodistuksia.

Kaikkien kenttien tiedot voidaan antaa käyttämällä kaikkia UTF-8-merkkijärjestelmällä koodattuja UNICODE 13.0 -merkkejä, paitsi jos merkit on nimenomaisesti rajattu arvojoukkoihin tai suppeampiin merkkijoukkoihin.

Yhteinen rakenne on seuraava:

"JSON":{

"ver":<versiotiedot>,

"nam":{

<henkilön nimitiedot>

},

"dob":<syntymäaika>,

"v" or "t" or "r":[

{<rokoteannosta tai testiä tai taudista parantumista koskevat tiedot, yksi merkintä>}

]

}

Tarkempia tietoja yksittäisistä ryhmistä ja kentistä annetaan seuraavissa osioissa.

3.1 Versio

Versiotiedot on annettava. Versioinnissa käytetään semanttista versiointia (semver: https://semver.org). Käytössä olevan version on oltava jokin virallisesti julkaistu versio (nykyinen versio tai jokin vanhemmista virallisesti julkaistuista versioista). Ks. lisätietoja kohdassa JSON Schema location.







Kentän tunniste Kentän nimi Ohjeet ver Skeeman versio On vastattava EU:n digitaalisen koronatodistuksen tuottamiseen käytetyn skeemaversion tunnistetta. Esimerkki: "ver":"1.3.0"

3.2 Henkilön nimi ja syntymäaika

Henkilön nimi on henkilön virallinen täydellinen nimi, joka vastaa matkustusasiakirjoissa ilmoitettua nimeä. Rakenteen tunniste on nam. On annettava täsmälleen 1 (yksi) henkilön nimi.







Kentän tunniste Kentän nimi Ohjeet nam/fn Sukunimi/-nimet Haltijan sukunimi/-nimet. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä, jossa on kaikki sukunimet. Jos sukunimiä on useita, ne erotetaan toisistaan välilyönnillä. Yhdysnimien, jotka sisältävät yhdysmerkkejä tai vastaavia merkkejä, on kuitenkin pysyttävä muuttumattomina. Esimerkkejä: "fn":"Musterfrau-Gößinger" "fn":"Musterfrau-Gößinger Müller" nam/fnt Sukunimi/-nimet vakiomuodossa Haltijan sukunimi/-nimet, jotka on translitteroitu käyttäen samaa käytäntöä kuin haltijan koneellisesti luettavissa matkustusasiakirjoissa (kuten ICAOn asiakirjan 9303 osassa 3 määritellyt säännöt). On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä, joka sisältää ainoastaan merkkejä A-Z ja <. Enimmäispituus: 80 merkkiä (ICAO 9303 -spesifikaatioiden mukaisesti). Esimerkkejä: "fnt":"MUSTERFRAU<GOESSINGER" "fnt":"MUSTERFRAU<GOESSINGER<MUELLER" nam/gn Etunimi/-nimet Haltijan etunimi/-nimet. Jos haltijalla ei ole etunimiä, kenttä on ohitettava. Kaikissa muissa tapauksissa on annettava täsmälleen 1 (yksi) ei-tyhjä kenttä, jossa on kaikki etunimet. Jos etunimiä on useita, ne erotetaan toisistaan välilyönnillä. Esimerkki: "gn":"Isolde Erika" nam/gnt Etunimi/-nimet vakiomuodossa Haltijan etunimi/-nimet, jotka on translitteroitu käyttäen samaa käytäntöä kuin haltijan koneellisesti luettavissa matkustusasiakirjoissa (kuten ICAOn asiakirjan 9303 osassa 3 määritellyt säännöt). Jos haltijalla ei ole etunimiä, kenttä on ohitettava. Kaikissa muissa tapauksissa on annettava täsmälleen 1 (yksi) ei-tyhjä kenttä, joka sisältää ainoastaan merkkejä A-Z ja <. Enimmäispituus: 80 merkkiä. Esimerkki: "gnt":"ISOLDE<ERIKA" dob Syntymäaika Haltijan syntymäaika Täydellinen tai osittainen päivämäärä ilman kellonaikaa rajattuna aikavälille 1900-01-01 – 2099-12-31. Jos täydellinen tai osittainen syntymäaika on tiedossa, on annattava täsmälleen 1 (yksi) ei-tyhjä kenttä. Jos syntymäaika ei ole edes osittain tiedossa, kenttä asetetaan tyhjäksi merkkijonoksi "". Tämän olisi vastattava matkustusasiakirjoissa annettuja tietoja. Jos syntymäaikaa koskevat tiedot ovat saatavilla, on käytettävä jotakin seuraavista ISO 8601 -formaateista. Muita vaihtoehtoja ei tueta. VVVV-KK-PP VVVV-KK VVVV (Todentajasovellus voi näyttää syntymäajan puuttuvat osat käyttämällä koneellisesti luettavissa matkustusasiakirjoissa käytettyä XX-käytäntöä, esim. 1990-XX-XX.) Esimerkkejä: "dob":"1979-04-14" "dob":"1901-08" "dob":"1939" "dob":""

3.3 Todistustyyppikohtaisten tietojen ryhmät

JSON-muoto tukee kolmea merkintäryhmää, jotka sisältävät todistustyyppikohtaisia tietoja. Kussakin EU:n digitaalisessa koronatodistuksessa on oltava täsmälleen 1 (yksi) ryhmä. Tyhjät ryhmät eivät ole sallittuja.







Ryhmän tunniste Ryhmän nimi Merkinnät v Rokotusryhmä Jos on saatavilla, sen on sisällettävä täsmälleen 1 (yksi) merkintä, jossa kuvataan täsmälleen 1 (yksi) rokoteannos (yksi annos). t Testausryhmä Jos on saatavilla, sen on sisällettävä täsmälleen 1 (yksi) merkintä, jossa kuvataan täsmälleen 1 (yksi) testitulos. r Parantunut taudista -ryhmä Jos on saatavilla, sen on sisällettävä täsmälleen 1 (yksi) merkintä, jossa kuvataan täsmälleen 1 (yksi) ilmoitus taudista parantumisesta.

4. Todistustyyppikohtaiset tiedot

4.1 Rokotustodistus

Jos rokotusryhmä on saatavilla, sen on sisällettävä täsmälleen 1 (yksi) merkintä, jossa kuvataan täsmälleen 1 (yksi) rokotustapahtuma (yksi annos). Kaikki rokotusryhmän osat ovat pakollisia, tyhjiä arvoja ei tueta.







Kentän tunniste Kentän nimi Ohjeet v/tg Kyseessä oleva tauti tai taudinaiheuttaja: covid-19 (SARS-CoV-2 tai jokin sen muunnoksista) Koodattu arvo arvojoukosta disease-agent-targeted.json. Tässä arvojoukossa on vain yksi merkintä 840539006, joka on covid-19:n koodi SNOMED CT (GPS) -järjestelmässä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "tg":"840539006" v/vp Covid-19-rokote tai -estolääkitys Käytetyn rokotteen tai estolääkityksen tyyppi. Koodattu arvo arvojoukosta vaccine-prophylaxis.json. Arvojoukko jaetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän kautta. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "vp":"1119349007" (SARS-CoV-2-mRNA-rokote) v/mp Covid-19-rokotevalmiste Tässä nimenomaisessa rokoteannoksessa käytetty rokotevalmiste. Koodattu arvo arvojoukosta vaccine-medicinal-product.json. Arvojoukko jaetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän kautta. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "mp":"EU/1/20/1528" (Comirnaty) v/ma Covid-19-rokotteen myyntiluvan haltija tai valmistaja Myyntiluvan haltija tai valmistaja, jos myyntiluvan haltijaa ei ole. Koodattu arvo arvojoukosta vaccine-mah-manf.json. Arvojoukko jaetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän kautta. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "ma":"ORG-100030215" (Biontech Manufacturing GmbH) v/dn Annosnumero rokotussarjassa Tässä rokotustapahtumassa annetun annoksen järjestysnumero (positiivinen kokonaisluku). 1 ensimmäisestä annoksesta, 2 toisesta annoksesta jne. Tarkempia sääntöjä annetaan liitteessä II olevassa 5 kohdassa. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkkejä: "dn":"1" (ensimmäinen annos) "dn":"2" (toinen annos) "dn":"3" (kolmas annos) v/sd Sarjarokotteen annosten kokonaismäärä Rokotussarjaan sisältyvien annosten kokonaismäärä (positiivinen kokonaisluku). Tarkempia sääntöjä annetaan liitteessä II olevassa 5 kohdassa. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkkejä: "sd":"1" (yhtenä annoksena annettava ensimmäinen rokotussarja) "sd":"2" (kahtena annoksena annettava ensimmäinen rokotussarja tai yhtenä annoksena annetun ensimmäisen rokotussarjan jälkeen annettu lisäannos) "sd":"3" (esim. kahtena annoksena annetun ensimmäisen rokotussarjan jälkeen annettu lisäannos) v/dt Rokotuspäivä Päivämäärä, jona kuvattu annos on saatu, muodossa VVVV-KK-PP (täydellinen päivämäärä ilman kellonaikaa). Muita muotoja ei tueta. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "dt":"2021-03-28" v/co Jäsenvaltio tai kolmas maa, jossa rokote annettiin Maa ilmaistuna 2-kirjaimisena ISO3166-koodina (SUOSITELTU) tai viittaus rokotustapahtumasta vastaavaan kansainväliseen organisaatioon (kuten UNHCR:ään tai WHO:hon). Koodattu arvo arvojoukosta country-2-codes.json. Arvojoukko jaetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän kautta. On annettava täsmälleen 1 (yksi) kenttä. Esimerkki: "co":"CZ" "co":"UNHCR" v/is Todistuksen myöntäjä Todistuksen myöntäneen organisaation nimi. Tunnisteet sallitaan osana nimeä, mutta niitä ei suositella käytettäväksi yksinään ilman tekstimuotoista nimeä. Enintään 80 UTF-8 merkkiä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "is":"Ministry of Health of the Czech Republic" "is":"Vaccination Centre South District 3" v/ci Yksilöllinen todistustunnus Yksilöllinen todistustunnus, joka on määritelty asiakirjassa https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf. Tarkistussumman käyttö on vapaaehtoista. Etuliite "URN:UVCI:" voidaan lisätä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkkejä: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2 Testaustodistus

Jos testausryhmä on saatavilla, sen on sisällettävä täsmälleen 1 (yksi) merkintä, jossa kuvataan täsmälleen yksi testitulos.







Kentän tunniste Kentän nimi Ohjeet t/tg Testattu tauti tai taudinaiheuttaja: covid-19 (SARS-CoV-2 tai jokin sen muunnoksista) Koodattu arvo arvojoukosta disease-agent-targeted.json. Tässä arvojoukossa on vain yksi merkintä 840539006, joka on covid-19:ta koodi SNOMED CT (GPS) -järjestelmässä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "tg":"840539006" t/tt Testin tyyppi Käytetyn testin tyyppi testin kohteena olevan materiaalin perusteella. Koodattu arvo arvojoukosta test-type.json (perustuu LOINC-järjestelmään). Arvojoukon ulkopuoliset arvot eivät ole sallittuja. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "tt":"LP6464-4" (Nukleiinihappotesti koettimen määrityksellä) "tt":"LP217198-3" (Nopea immuunimääritys) t/nm Testin nimi (ainoastaan nukleiinihappotestit) Käytetyn nukleiinihappotestin (NAAT-testin) nimi. Nimen olisi sisällettävä testin valmistajan nimi ja testin kaupallinen nimi pilkulla erotettuna. NAAT-testi: kenttä on valinnainen. RAT-testi: kenttää ei saa käyttää, koska testin nimi ilmoitetaan epäsuorasti testilaitteen tunnisteen (t/ma) avulla. Kun arvo ilmoitetaan, kenttä ei saa olla tyhjä. Esimerkki: "nm":"ELITechGroup, SARS-CoV-2 ELITe MGB® Kit" t/ma Testilaitteen tunniste (ainoastaan antigeenipikatestit) Antigeenipikatestin (RAT) laitetunniste JRC:n tietokannasta. Arvojoukko (terveysturvakomitean yhteinen luettelo): — All Rapid antigen tests in HSC common list (ihmisen luettavissa). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (koneellisesti luettava, kentän id_device arvot sisältyvät arvojoukon luetteloon). EU-/ETA-maissa todistusten myöntäjät saavat myöntää todistuksia ainoastaan testeistä, jotka kuuluvat kulloinkin voimassa olevaan arvojoukkoon. Arvojoukko on päivitettävä 24 tunnin välein. Arvojoukon ulkopuolisia arvoja voidaan käyttää kolmansien maiden myöntämissä todistuksissa, mutta tunnisteiden on silti oltava peräisin JRC:n tietokannasta. Muiden tunnisteiden, kuten testien valmistajien suoraan antamien tunnisteiden, käyttö ei ole sallittua. Todentajien on havaittava arvot, jotka eivät kuulu ajantasaiseen arvojoukkoon, ja näytettävä niitä sisältävät todistukset pätemättömiä. Jos tunniste poistetaan arvojoukosta, todistukset, joihin se sisältyy, voidaan hyväksyä enintään 72 tunnin ajan poistamispäivästä. Arvojoukko jaetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän kautta. RAT-testi: on annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. NAAT-testi: kenttää ei saa käyttää, vaikka NAAT-testitunniste olisi saatavilla JRC:n tietokannassa. Esimerkki: "ma":"344" (SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc Testinäytteen ottopäivä ja -aika Päivämäärä ja kellonaika, jolloin testinäyte on otettu. Ajan on sisällettävä tieto aikavyöhykkeestä. Arvo ei saa tarkoittaa ajankohtaa, jolloin testitulos on tuotettu. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. On käytettävä jotakin seuraavista ISO 8601 -formaateista. Muita vaihtoehtoja ei tueta. VVVV-KK-PPThh:mm:ssZ VVVV-KK-PPThh:mm:ss[+-]hh VVVV-KK-PPThh:mm:ss[+-]hhmm VVVV-KK-PPThh:mm:ss[+-]hh:mm Esimerkkejä: "sc":"2021-08-20T10:03:12Z" (UTC-aika) "sc":"2021-08-20T12:03:12+02" (CEST-aika) "sc":"2021-08-20T12:03:12+0200" (CEST-aika) "sc":"2021-08-20T12:03:12+02:00" (CEST-aika) t/tr Testin tulos Testin tulos. Koodattu arvo arvojoukosta test-result.json (perustuu SNOMED CT, GPS -järjestelmään). On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "tr":"260415000" (Ei havaittu) t/tc Testauskeskus tai -asema. Testin suorittaneen toimijan nimi. Tunnisteet sallitaan osana nimeä, mutta niitä ei suositella käytettäväksi yksinään ilman tekstimuotoista nimeä. Enintään 80 UTF-8 merkkiä. Mahdolliset lisämerkit olisi lyhennettävä. Nimeä ei ole tarkoitettu automaattista todentamista varten. NAAT-testi: on annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. RAT-testi: kenttä on valinnainen. Jos arvo ilmoitetaan, kenttä ei saa olla tyhjä. Esimerkki: "tc":"Test centre west region 245" t/co Jäsenvaltio tai kolmas maa, jossa testi tehtiin Maa ilmaistuna 2-kirjaimisena ISO3166-koodina (SUOSITELTU) tai viittaus testin suorittamisesta vastaavaan kansainväliseen organisaatioon (kuten UNHCR:ään tai WHO:hon). Tämän on oltava koodattu arvo arvojoukosta country-2-codes.json. Arvojoukko jaetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän kautta. On annettava täsmälleen 1 (yksi) kenttä. Esimerkkejä: "co":"CZ" "co":"UNHCR" t/is Todistuksen myöntäjä Todistuksen myöntäneen organisaation nimi. Tunnisteet sallitaan osana nimeä, mutta niitä ei suositella käytettäväksi yksinään ilman tekstimuotoista nimeä. Enintään 80 UTF-8 merkkiä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkkejä: "is":"Ministry of Health of the Czech Republic" "is":"North-West region health authority" t/ci Yksilöllinen todistustunnus Yksilöllinen todistustunnus, joka on määritelty asiakirjassa vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Tarkistussumman käyttö on vapaaehtoista. Etuliite "URN:UVCI:" voidaan lisätä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkkejä: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.3 Todistus taudista parantumisesta

Jos parantunut taudista -ryhmä on saatavilla, sen on sisällettävä täsmälleen 1 (yksi) merkintä, jossa kuvataan täsmälleen yksi ilmoitus taudista parantumisesta. Kaikki parantunut taudista -ryhmän osat ovat pakollisia, tyhjiä arvoja ei tueta.







Kentän tunniste Kentän nimi Ohjeet r/tg Tauti tai taudinaiheuttaja, josta todistuksen haltija on parantunut: covid-19 (SARS-CoV-2 tai jokin sen muunnoksista) Koodattu arvo arvojoukosta disease-agent-targeted.json. Tässä arvojoukossa on vain yksi merkintä 840539006, joka on covid-19:ta koodi SNOMED CT (GPS) -järjestelmässä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "tg":"840539006" r/fr Todistuksen haltijan NAAT-testissä antaman ensimmäisen positiivisen näytteen päivämäärä Päivämäärä, jona positiivisen tuloksen tuottava NAAT-testinäyte otettiin, muodossa VVVV-KK-PP (täydellinen päivämäärä ilman kellonaikaa). Muita muotoja ei tueta. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "fr":"2021-05-18" r/co Jäsenvaltio tai kolmas maa, jossa testi tehtiin Maa ilmaistuna 2-kirjaimisena ISO3166-koodina (SUOSITELTU) tai viittaus testin suorittamisesta vastaavaan kansainväliseen organisaatioon (kuten UNHCR:ään tai WHO:hon). Tämän on oltava koodattu arvo arvojoukosta country-2-codes.json. Arvojoukko jaetaan EU:n digitaalisen koronatodistuksen yhdyskäytävän kautta. On annettava täsmälleen 1 (yksi) kenttä. Esimerkkejä: "co":"CZ" "co":"UNHCR" r/is Todistuksen myöntäjä Todistuksen myöntäneen organisaation nimi. Tunnisteet sallitaan osana nimeä, mutta niitä ei suositella käytettäväksi yksinään ilman tekstimuotoista nimeä. Enintään 80 UTF-8 merkkiä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "is":"Ministry of Health of the Czech Republic" "is":"Central University Hospital" r/df Todistuksen voimassaolon alkamisajankohta Ensimmäinen päivä, jona todistuksen katsotaan olevan voimassa. Päivämäärä ei saa olla aikaisempi kuin päivämäärä, joka lasketaan seuraavasti: r/fr + 11 päivää. Päivämäärä on annettava muodossa VVVV-KK-PP (täydellinen päivämäärä ilman kellonaikaa). Muita muotoja ei tueta. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "df":"2021-05-29" r/du Todistuksen voimassaolon päättymisajankohta Todistuksen myöntäjän määrittämä viimeinen päivä, jona todistuksen katsotaan olevan voimassa. Päivämäärä ei saa olla myöhäisempi kuin päivämäärä, joka lasketaan seuraavasti: r/fr + 180 päivää. Päivämäärä on annettava muodossa VVVV-KK-PP (täydellinen päivämäärä ilman kellonaikaa). Muita muotoja ei tueta. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkki: "du":"2021-11-14" r/ci Yksilöllinen todistustunnus Yksilöllinen todistustunnus, joka on määritelty asiakirjassa vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Tarkistussumman käyttö on vapaaehtoista. Etuliite "URN:UVCI:" voidaan lisätä. On annettava täsmälleen 1 (yksi) ei-tyhjä kenttä. Esimerkkejä: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"