Artikel 1

Artikel 58 van Verordening (EU) 2016/1628 wordt als volgt gewijzigd:

1)

Aan lid 5 wordt de volgende alinea toegevoegd: “Voor motoren van alle subcategorieën waarvoor de in bijlage III genoemde datum voor het in de handel brengen van fase V-motoren 1 januari 2020 is, met uitzondering van de in de tweede en derde alinea bedoelde motoren, wordt de overgangsperiode verlengd met negen maanden en wordt de in de eerste alinea bedoelde periode van 18 maanden verlengd met zes maanden.”.

2)	Aan lid 7 wordt het volgende punt toegevoegd: “e) 33 maanden na de in bijlage III genoemde toepasselijke datum voor het in de handel brengen van motoren, in het in lid 5, zesde alinea, genoemde geval.”.

Artikel 2

Deze verordening treedt in werking op de dag van de bekendmaking ervan in het Publicatieblad van de Europese Unie.

Artikel 1

Wijziging van Verordening (EU) 2020/1579

Verordening (EU) 2020/1579 wordt gewijzigd overeenkomstig deel A van de bijlage bij deze verordening.

Artikel 2

Wijziging van Verordening (EU) 2021/92

Verordening (EU) 2021/92 wordt gewijzigd overeenkomstig delen B en C van de bijlage bij deze verordening.

Artikel 3

Inwerkingtreding en toepassing

Deze verordening treedt in werking op de dag na die van de bekendmaking ervan in het Publicatieblad van de Europese Unie.

Artikel 1 is van toepassing met ingang van 1 januari 2021.

Artikel 2 is van toepassing met ingang van 1 juli 2021.

BIJLAGE

DEEL A

In de bijlage bij Verordening (EU) 2020/1579 wordt de vangstmogelijkhedentabel voor haring in de ICES-deelsectoren 30-31 vervangen door de volgende tabel:

DEEL B

Bijlage IA bij Verordening (EU) 2021/92 wordt als volgt gewijzigd:

1)

De vangstmogelijkhedentabel voor sprot en bijvangsten in de wateren van de Unie van ICES-sector 3a wordt vervangen door de volgende tabel: “Soort: Sprot en bijvangsten Sprattus sprattus Gebied: 3a (SPR/03A.) Denemarken 13 086  (1)  (2) Analytische TAC Duitsland 27  (1)  (2) Zweden 4 951  (1)  (2) Unie 18 064  (1)  (2)   TAC 19 529  (2)

2)

De vangstmogelijkhedentabel voor sprot en bijvangsten in de wateren van het Verenigd Koninkrijk en van de Unie van ICES-deelgebied 4 en de wateren van het Verenigd Koninkrijk van ICES-sector 2a wordt vervangen door: “Soort: Sprot en bijvangsten Sprattus sprattus Gebied: wateren van het Verenigd Koninkrijk en van de Unie van 4; wateren van het Verenigd Koninkrijk van 2a SPR/2Ac4-C België 993  (3)  (4) Analytische TAC Denemarken 78 553  (3)  (4) Duitsland 993  (3)  (4) Frankrijk 993  (3)  (4) Nederland 993  (3)  (4) Zweden 1 330  (3)  (4)  (5) Unie 83 855  (3)  (4) Noorwegen 0  (3) Faeröer 0  (3)  (6) Verenigd Koningrijk 3 331  (3)   TAC 87 186  (3)

3)

De tabel met de vangstmogelijkheden voor ansjovis in de ICES-deelgebieden 9 en 10 en in de wateren van de Unie van Cecaf 34.1.1 wordt vervangen door de volgende tabel: “Soort: Ansjovis Engraulis encrasicolus Gebied: 9 en 10; wateren van de Unie van Cecaf 34.1.1 (ANE/9/3411) Spanje 2 747  (7) Voorzorgs-TAC Portugal 2 997  (7) Unie 5 744  (7)   TAC 5 744  (7)

DEEL C

In bijlage VI bij Verordening (EU) 2021/92 wordt punt 6 wordt vervangen door:

“6.

Maximale capaciteit voor het kweken en mesten van blauwvintonijn voor elke lidstaat, en maximale hoeveelheid in het wild gevangen blauwvintonijn die elke lidstaat over zijn kweek- en mestbedrijven in het oostelijke deel van de Atlantische Oceaan en in de Middellandse Zee kan verdelen. Tabel A Maximale capaciteit voor het kweken en mesten van blauwvintonijn   Aantal bedrijven Capaciteit (in ton) Spanje 10 11 852 Italië 13 9 564 Griekenland 2 2 100 Cyprus 3 3 000 Kroatië 7 7 880 Malta 6 14 511 Tabel B (8) Maximale hoeveelheid in het wild gevangen blauwvintonijn (in ton) Spanje 6 850 Italië 1 739,5 Griekenland 785 Cyprus 2 195 Kroatië 2 947 Malta 10 260,5 Portugal 350

---

(1)  Maximaal 5 % van het quotum mag bestaan uit bijvangsten van wijting en schelvis (OTH/*03A.). Uit hoofde van deze bepaling op het quotum in mindering gebrachte bijvangsten van wijting en schelvis en overeenkomstig artikel 15, lid 8, van Verordening (EU) nr. 1380/2013 op het quotum in mindering gebrachte bijvangsten van soorten mogen samen niet hoger zijn dan 9 % van het quotum.

(2)  Dit quotum mag alleen worden gevangen van 1 juli 2021 tot en met 30 juni 2022. Van deze quota mogen overdrachten plaatsvinden naar wateren van het Verenigd Koninkrijk en van de Unie van 2a en 4. Deze overdrachten worden evenwel vooraf aan de Commissie en het Verenigd Koninkrijk gemeld.”.

(3)  Dit quotum mag alleen worden gevangen van 1 juli 2021 tot en met 30 juni 2022.

(4)  Maximaal 2 % van het quotum mag bestaan uit bijvangsten van wijting (OTH/*2AC4C). Uit hoofde van deze bepaling op het quotum in mindering gebrachte bijvangsten van wijting en overeenkomstig artikel 15, lid 8, van Verordening (EU) nr. 1380/2013 op het quotum in mindering gebrachte bijvangsten van soorten mogen samen niet hoger zijn dan 9 % van het quotum.

(5)  Inclusief zandspieringen.

(6)  Mag tot 4 % bijvangsten van haring bevatten.”.

(7)  Dit quotum mag alleen worden gevangen van 1 juli 2021 tot en met 30 september 2021.”.

(8)  De capaciteit van Portugal van 500 ton voor het kweken wordt gedekt door de onbenutte capaciteit van de Unie die is opgenomen in tabel A.”.

Artikel 1

Onderwerp en toepassingsgebied

Bij deze verordening worden bijzondere ziektebestrijdingsmaatregelen vastgesteld in verband met infectie met het nodulaire-dermatosevirus (LSDV) die de lidstaten gedurende een beperkte periode moeten toepassen in gebieden op hun grondgebied waar:

a)	een uitbraak van die ziekte is bevestigd;

b)	geen uitbraak van die ziekte is bevestigd, maar waar zij besluiten overeenkomstig de voorschriften van deze verordening tegen die ziekte te vaccineren.

De in deze verordening vastgestelde bijzondere ziektebestrijdingsmaatregelen zijn van toepassing op runderen en bijproducten en levende producten die van dergelijke runderen zijn verkregen, en komen bovenop de ziektebestrijdingsmaatregelen die van toepassing zijn op de beschermings-, bewakings- en extra beperkingszones die door de bevoegde autoriteit van een lidstaat zijn ingesteld naar aanleiding van een uitbraak van infectie met het LSDV, overeenkomstig artikel 21, lid 1, van Gedelegeerde Verordening (EU) 2020/687.

Artikel 2

Definities

Voor de toepassing van deze verordening gelden de definities van Gedelegeerde Verordening (EU) 2020/687.

Daarnaast gelden tevens de volgende definities:

1)	“rund”: een dier dat behoort tot de hoefdiersoorten in de geslachten Bison, Bos (met inbegrip van de ondergeslachten Bos, Bibos, Novibos en Poephagus) en Bubalus (met inbegrip van het ondergeslacht Anoa), alsook kruisingen van die soorten;

2)

“beperkingszone I”: een nauwkeurig afgebakend geografisch deel van het grondgebied van een lidstaat: a) dat buiten een gebied ligt waar een uitbraak van infectie met het LSDV is bevestigd; b) waar overeenkomstig artikel 3, lid 2, wordt gevaccineerd tegen infectie met het LSDV; c) dat al dan niet in deel I van bijlage I is opgenomen; d) dat onderworpen is aan de in de artikelen 3 tot en met 6 bedoelde bijzondere ziektebestrijdingsvoorschriften;

3)

“beperkingszone II”: een nauwkeurig afgebakend geografisch deel van het grondgebied van een lidstaat: a) waarbinnen een uitbraak van infectie met het LSDV is bevestigd; b) waar overeenkomstig artikel 3, lid 1, wordt gevaccineerd tegen infectie met het LSDV; c) dat al dan niet in deel II van bijlage I is opgenomen; d) dat onderworpen is aan de in de artikelen 3 tot en met 6 bedoelde bijzondere ziektebestrijdingsvoorschriften.

Artikel 3

Instelling van beperkingszones I en II

Artikel 4

Verbod op verplaatsingen in beperkingszones I en II

Artikel 5

Opneming van beperkingszone II in deel II van bijlage I

Zodra om epidemiologische redenen een gebied van een lidstaat dat geheel of gedeeltelijk door een overeenkomstig artikel 3, lid 1, ingestelde beperkingszone II wordt bestreken, in deel II van bijlage I wordt opgenomen, handelt de bevoegde autoriteit onmiddellijk als volgt:

a)	zij past de grenzen van de initiële beperkingszone II aan, zodat deze overeenstemt met de in die bijlage beschreven beperkingszone II;

b)	zij breidt de in artikel 3, lid 1, punt b), bedoelde vaccinatie en de verbodsbepalingen van artikel 4, lid 1, uit tot de in die bijlage omschreven beperkingszone II.

Artikel 6

Opneming van beperkingszone I in deel I van bijlage I

Artikel 7

Afwijkingen van het verbod op verplaatsingen van zendingen runderen uit beperkingszone I

In afwijking van het verbod van artikel 4, lid 2, punt a), mag de bevoegde autoriteit toestemming verlenen voor verplaatsingen van zendingen runderen uit inrichtingen in beperkingszone I naar:

a)

beperkingszones I of II in dezelfde of een andere lidstaat, mits aan elk van de volgende voorwaarden is voldaan: i) de runderen in de zending zijn ten minste 28 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd en bevinden zich volgens de instructies van de fabrikant van het vaccin op die datum nog in de immuniteitsperiode; ii) alle andere runderen die in dezelfde inrichting van oorsprong worden gehouden als de runderen in de zending, zijn ten minste 28 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd en bevinden zich volgens de instructies van de fabrikant van het vaccin op die datum nog in de immuniteitsperiode of bevinden zich op de datum van verzending nog in de immuniteitsperiode als gevolg van een eerdere vaccinatie of maternale immuniteit; iii) de runderen in de zending zijn sinds hun geboorte of gedurende een ononderbroken periode van ten minste 28 dagen vóór de datum van verzending in de inrichting van oorsprong gehouden; en iv) de bevoegde autoriteit verricht: — een klinisch onderzoek van alle runderen die in de inrichting van oorsprong van dergelijke zendingen worden gehouden, met inbegrip van de runderen in dergelijke zendingen, en het resultaat daarvan is gunstig; — indien nodig, een laboratoriumonderzoek van runderen die worden gehouden in de inrichting van oorsprong van dergelijke zendingen, met inbegrip van de runderen in dergelijke zendingen, en het resultaat daarvan is gunstig;

b)

elke bestemming — met inbegrip van gebieden buiten beperkingszones, andere beperkingszones I of beperkingszones II — in dezelfde lidstaat of in andere lidstaten, indien naast de voorwaarden van punt a), ii), iii) en iv), van dit artikel alle volgende voorwaarden worden vervuld: i) de runderen in de zending zijn ten minste 60 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd en bevinden zich volgens de instructies van de fabrikant van het vaccin op de datum van verzending nog in de immuniteitsperiode; ii) er hebben zich in een straal van ten minste 20 km rond de inrichting van oorsprong van dergelijke zendingen gedurende een periode van ten minste drie maanden vóór de datum van verzending geen uitbraken van infectie met het LSDV voorgedaan, en iii) alle runderen die in een straal van 50 km rond de inrichting van oorsprong van de zending worden gehouden, zijn ten minste 60 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd of gehervaccineerd en bevinden zich op die datum volgens de instructies van de fabrikant van het vaccin nog in de immuniteitsperiode of genieten op die datum nog maternale immuniteit;

c)

elke bestemming — met inbegrip van gebieden buiten beperkingszones, andere beperkingszones I of beperkingszones II — in andere lidstaten of gebieden in derde landen, indien naast de voorwaarden van punt a) van dit artikel de volgende voorwaarden worden vervuld: i) de dieren voldoen aan alle diergezondheidsgaranties, gebaseerd op de positieve uitkomst van een risicobeoordeling van de maatregelen tegen de verspreiding van infectie met het LSDV die door de bevoegde autoriteit van de lidstaat van oorsprong zijn vereist en door de bevoegde autoriteiten van de lidstaten van doorgang en bestemming vóór de datum van verzending van de dieren zijn goedgekeurd; ii) er hebben zich gedurende een periode van ten minste drie maanden vóór de datum van verzending in een straal van ten minste 20 km rond de inrichting van oorsprong van dergelijke zendingen geen bevestigde uitbraken van infectie met het LSDV voorgedaan, en iii) alle runderen die in een straal van 50 km rond de inrichting van oorsprong van de zending worden gehouden, zijn ten minste 60 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd of gehervaccineerd en bevinden zich op die datum volgens de instructies van de fabrikant van het vaccin nog in de immuniteitsperiode of genieten op die datum nog maternale immuniteit.

Artikel 8

Afwijkingen van het verbod op verplaatsingen van zendingen runderen uit beperkingszone II

In afwijking van het verbod van artikel 4, lid 1, punt a), mag de bevoegde autoriteit toestemming verlenen voor verplaatsingen van zendingen runderen uit inrichtingen in beperkingszone II naar:

a)

elke bestemming — met inbegrip van gebieden buiten beperkingszones, andere beperkingszones I, andere beperkingszones II in dezelfde lidstaat en in andere lidstaten, indien aan elk van de volgende voorwaarden wordt voldaan: i) de runderen in de zending voldoen aan alle diergezondheidsgaranties, gebaseerd op de positieve uitkomst van een risicobeoordeling van de maatregelen tegen de verspreiding van infectie met het LSDV die door de bevoegde autoriteit van de lidstaat van oorsprong zijn vereist en vóór de datum van verzending van de dieren met de bevoegde autoriteiten van de lidstaten van doorgang of bestemming zijn overeengekomen; ii) de runderen in de zending zijn ten minste 28 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd en bevinden zich op die datum volgens de instructies van de fabrikant van het vaccin nog in de immuniteitsperiode; iii) alle andere runderen die in dezelfde inrichting van oorsprong worden gehouden als de runderen in de zending, zijn ten minste 28 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd en bevinden zich volgens de instructies van de fabrikant van het vaccin op die datum nog in de immuniteitsperiode of bevinden zich op die datum nog in de immuniteitsperiode als gevolg van een eerdere vaccinatie of maternale immuniteit; iv) de bevoegde autoriteit verricht: — een klinisch onderzoek van alle runderen die in de inrichting van oorsprong van dergelijke zendingen worden gehouden, met inbegrip van de runderen in dergelijke zendingen, en het resultaat daarvan is gunstig; — indien nodig, een laboratoriumonderzoek van runderen die worden gehouden in de inrichting van oorsprong van dergelijke zendingen, met inbegrip van de runderen in dergelijke zendingen, en het resultaat daarvan is gunstig; v) de runderen hebben sinds hun geboorte, of gedurende een periode van ten minste 28 dagen vóór de datum van verzending, verbleven in een inrichting waar in de drie maanden voorafgaand aan de datum van verzending in een straal van ten minste 20 km geen uitbraak van infectie met het LSDV is bevestigd; vi) alle runderen in een straal van 50 km rond de inrichting van oorsprong van de zending zijn ten minste 60 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd of gehervaccineerd volgens de regels voor vaccinatieprogramma’s van bijlage II en bevinden zich volgens de instructies van de fabrikant van het vaccin nog in de immuniteitsperiode of genieten nog maternale immuniteit;

b)

elke bestemming binnen een andere beperkingszone II in dezelfde lidstaat, mits aan elk van de volgende voorwaarden is voldaan: i) alle andere runderen die in de inrichting van oorsprong van dergelijke zendingen worden gehouden, zijn ten minste 28 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd en bevinden zich volgens de instructies van de fabrikant van het vaccin op die datum nog in de immuniteitsperiode of bevinden zich op die datum nog in de immuniteitsperiode als gevolg van een eerdere vaccinatie of maternale immuniteit, en ii) de runderen zijn ten minste 28 dagen vóór de datum van verzending tegen infectie met het LSDV gevaccineerd en bevinden zich volgens de instructies van de fabrikant van het vaccin op die datum nog in de immuniteitsperiode, of zijn niet-gevaccineerde nakomelingen jonger dan vier maanden van moederdieren die ten minste 28 dagen voor de worp zijn gevaccineerd, en bevonden zich op de datum van de worp nog in de door de fabrikant van het vaccin vermelde immuniteitsperiode, en mogen naar een andere inrichting worden verplaatst.

Artikel 9

Specifieke voorwaarden voor het verlenen van toestemming voor verplaatsingen van zendingen runderen uit beperkingszones I en II naar een slachthuis buiten die zones op het grondgebied van dezelfde lidstaat met het oog op onmiddellijke slacht

In afwijking van de verbodsbepalingen van artikel 4, lid 2, punt a), en artikel 4, lid 1, punt a), van deze verordening kan de bevoegde autoriteit van de lidstaat toestemming verlenen voor verplaatsingen van zendingen runderen uit beperkingszones I en II naar een slachthuis buiten die zones op het grondgebied van dezelfde lidstaat, mits de runderen worden verplaatst met het oog op onmiddellijke slacht overeenkomstig de algemene voorwaarden van artikel 28, lid 2 tot en met lid 5, en artikel 28, lid 7, van Gedelegeerde Verordening (EU) 2020/687.

Artikel 10

Afwijkingen van het verbod op verplaatsingen van zendingen sperma, eicellen en embryo’s van runderen uit beperkingszones I en II

Artikel 11

Afwijkingen van het verbod op de verplaatsingen van niet-verwerkte dierlijke bijproducten van runderen uit beperkingszones I

In afwijking van het verbod van artikel 4, lid 2, punt c), mag de bevoegde autoriteit van een lidstaat toestemming verlenen voor verplaatsingen van zendingen niet-verwerkte dierlijke bijproducten van runderen uit inrichtingen in beperkingszone I naar:

a)	elke bestemming in dezelfde lidstaat of elke bestemming in beperkingszones I of II in een andere lidstaat;

b)

in het geval van zendingen huiden, elke bestemming in een gebied van dezelfde of een andere lidstaat of een derde land, mits aan de volgende voorwaarden is voldaan: i) de behandelde huiden hebben een van de in punt 28, b) tot en met e), van bijlage I bij Verordening (EU) nr. 142/2011 van de Commissie (10) bedoelde behandelingen ondergaan, hetzij ii) de behandelde huiden hebben een van de in afdeling XIV, hoofdstuk I, punt 4, b), ii), van bijlage III bij Verordening (EG) nr. 853/2004 van het Europees Parlement en de Raad (11) vastgestelde behandelingen ondergaan, en na behandeling zijn de nodige voorzorgen genomen om herbesmetting met ziekteverwekkers te voorkomen.

Artikel 12

Afwijking van het verbod op de verplaatsingen van zendingen niet-verwerkte dierlijke bijproducten van runderen uit beperkingszones II

In afwijking van het verbod van artikel 4, lid 1, punt c), mag de bevoegde autoriteit van een lidstaat toestemming verlenen voor verplaatsingen van zendingen niet-verwerkte dierlijke bijproducten van runderen uit inrichtingen in beperkingszone II naar:

a)

in het geval van andere niet-verwerkte dierlijke bijproducten dan huiden, elke bestemming in dezelfde lidstaat of elke bestemming in beperkingszones I of II in een andere lidstaat, mits de niet-verwerkte dierlijke bijproducten onder officieel toezicht van de bevoegde autoriteiten worden verzonden met het oog op verwerking of verwijdering in een overeenkomstig artikel 24 van Verordening (EG) nr. 1069/2009 van het Europees Parlement en de Raad (12) erkend bedrijf;

b)

in het geval van huiden van runderen: i) elke bestemming in beperkingszone II van dezelfde of een andere lidstaat, mits het gaat om voor menselijke consumptie bestemde ongelooide en onbehandelde huiden of om onbehandelde huiden die onder officieel toezicht van de bevoegde autoriteiten worden verzonden om te worden verwerkt of verwijderd in een erkend bedrijf; ii) elke bestemming in dezelfde of een andere lidstaat, mits aan de voorwaarden van artikel 11, punt b), wordt voldaan;

c)	in het geval van colostrum, melk en zuivelproducten, elke bestemming in een gebied in dezelfde of een andere lidstaat, mits zij een risicobeperkende behandeling voor infectie met het LSDV hebben ondergaan, zoals vastgesteld in bijlage VII bij Gedelegeerde Verordening (EU) 2020/687.

Artikel 13

Verplichtingen van exploitanten ten aanzien van diergezondheidscertificaten voor verplaatsingen van zendingen runderen uit beperkingszones I en II buiten die zones

Exploitanten verplaatsen zendingen runderen uit beperkingszones I en II, slechts buiten die zones binnen dezelfde lidstaat of naar een andere lidstaat in de gevallen die worden bestreken in de artikelen 7, 8 en 9 van deze verordening, indien de te verplaatsen dieren vergezeld gaan van het diergezondheidscertificaat zoals bedoeld in artikel 73 van Gedelegeerde Verordening (EU) 2020/688 van de Commissie (13), dat ten minste een van de volgende verklaringen bevat dat aan de voorschriften van deze verordening is voldaan:

a)	“Runderen uit beperkingszone I overeenkomstig de bijzondere bestrijdingsmaatregelen tegen infectie met het LSDV, als vastgesteld in artikel 7 van Uitvoeringsverordening (EU) 2021/1070 van de Commissie.”;

b)	“Runderen uit beperkingszone II overeenkomstig de bijzondere bestrijdingsmaatregelen tegen infectie met het LSDV, als vastgesteld in artikel 8 van Uitvoeringsverordening (EU) 2021/1070 van de Commissie.”;

c)	“Runderen uit beperkingszone I of II overeenkomstig de bijzondere bestrijdingsmaatregelen tegen infectie met het LSDV, als vastgesteld in artikel 9 van Uitvoeringsverordening (EU) 2021/1070 van de Commissie.”.

In geval van verplaatsingen van de zendingen zoals bedoeld in het eerste lid van dit artikel binnen dezelfde lidstaat kan de bevoegde autoriteit echter besluiten dat geen diergezondheidscertificaat hoeft te worden uitgereikt, zoals bedoeld in artikel 143, lid 2, tweede alinea, van Verordening (EU) 2016/429.

Artikel 14

Verplichtingen van exploitanten ten aanzien van diergezondheidscertificaten voor verplaatsingen van zendingen levende producten, verkregen van runderen uit inrichtingen in beperkingszones I en II buiten die zones

Exploitanten verplaatsen zendingen levende producten, verkregen van runderen uit beperkingszones I en II, slechts buiten die zones binnen dezelfde lidstaat of naar een andere lidstaat overeenkomstig artikel 10 van deze verordening indien die zendingen vergezeld gaan van een diergezondheidscertificaat zoals bedoeld in artikel 161, lid 4, van Verordening (EU) 2016/429, dat ten minste een van de volgende verklaringen bevat dat aan de voorschriften van deze verordening is voldaan:

a)

“Levende producten … (sperma, eicellen en/of embryo’s, aangeven wat van toepassing is), verkregen van runderen die in beperkingszone I worden gehouden overeenkomstig bijzondere bestrijdingsmaatregelen voor infectie met het LSDV als vastgesteld in artikel 10 van Uitvoeringsverordening (EU) 2021/1070 van de Commissie.”;

b)

“Levende producten … (sperma, eicellen en/of embryo’s, aangeven wat van toepassing is), verkregen van runderen die in beperkingszone II worden gehouden overeenkomstig bijzondere bestrijdingsmaatregelen voor infectie met het LSDV als vastgesteld in artikel 10 van Uitvoeringsverordening (EU) 2021/1070 van de Commissie.”.

In geval van verplaatsingen van de zendingen zoals bedoeld in het eerste lid van dit artikel binnen dezelfde betrokken lidstaat kan de bevoegde autoriteit echter besluiten dat geen diergezondheidscertificaat hoeft te worden uitgereikt zoals bedoeld in artikel 161, lid 2, tweede alinea, van Verordening (EU) 2016/429.

Artikel 15

Verplichtingen van exploitanten ten aanzien van diergezondheidscertificaten voor verplaatsingen van zendingen niet-verwerkte dierlijke bijproducten van runderen uit beperkingszones I en II buiten die zones

Exploitanten verplaatsen zendingen niet-verwerkte dierlijke bijproducten van runderen uit beperkingszones I en II slechts buiten die zones binnen dezelfde lidstaat of naar een andere lidstaat in de gevallen die worden bestreken door artikel 12 indien die zendingen vergezeld gaan van:

a)	een handelsdocument zoals bedoeld in hoofdstuk III van bijlage VIII bij Verordening (EU) nr. 142/2011, en

b)	een diergezondheidscertificaat zoals bedoeld in artikel 22, lid 5, van Gedelegeerde Verordening (EU) 2020/687.

In geval van verplaatsingen van de zendingen zoals bedoeld in het eerste lid van dit artikel binnen dezelfde lidstaat kan de bevoegde autoriteit echter besluiten dat geen diergezondheidscertificaat wordt uitgereikt zoals bedoeld in artikel 22, lid 6, van Gedelegeerde Verordening (EU) 2020/687.

Artikel 16

Aanvullende algemene voorwaarden met betrekking tot het vervoermiddel dat wordt gebruikt voor de verplaatsing van zendingen runderen en niet-verwerkte dierlijke bijproducten uit beperkingszones I en II buiten die zones

De bevoegde autoriteit van de lidstaat verleent slechts toestemming voor verplaatsingen van zendingen runderen en niet-verwerkte dierlijke bijproducten uit beperkingszones I en II buiten die zones indien de voor het vervoer van die zendingen gebruikte vervoermiddelen aan de volgende voorwaarden voldoen:

a)

in het geval van het vervoer van runderen geldt dat de vervoermiddelen: i) aan de voorschriften van artikel 24, lid 1, van Gedelegeerde Verordening (EU) 2020/687 voldoen, en ii) worden gereinigd en ontsmet overeenkomstig artikel 24, lid 2, van Gedelegeerde Verordening (EU) 2020/687 onder controle of toezicht van de bevoegde autoriteit van de lidstaat;

b)	zij bevatten uitsluitend levende dieren, niet-verwerkte dierlijke bijproducten of onbehandelde huiden met dezelfde gezondheidsstatus.

Artikel 17

Verplichtingen van de bevoegde autoriteit van de inrichting van oorsprong met betrekking tot kanalisatieprocedures

Artikel 18

Verplichtingen van de bevoegde autoriteit van de plaats van bestemming met betrekking tot kanalisatieprocedures

De bevoegde autoriteit van de plaats van bestemming die een kanalisatieprocedure volgt, handelt als volgt:

a)	zij bevestigt elke aankomst bij de bevoegde autoriteit van de plaats van oorsprong;

b)	zij zorgt ervoor dat de runderen ten minste gedurende de in bijlage II bij Gedelegeerde Verordening (EU) 2020/687 vastgestelde monitoringperiode voor infectie met het LSDV in de inrichting van bestemming blijven, behalve wanneer de inrichting van bestemming een slachthuis is;

c)

zij zorgt ervoor dat na het lossen van de levende dieren of niet-verwerkte dierlijke bijproducten het vervoermiddel en de andere uitrusting die voor het vervoer zijn gebruikt, in een afgesloten ruimte van de plaats van bestemming onder toezicht van de officiële dierenarts in hun geheel worden gereinigd, ontsmet en behandeld met toegelaten insecticiden die doeltreffend zijn tegen bekende vectoren van infectie met het LSDV.

Artikel 19

Verplichtingen van de lidstaat van de plaats van oorsprong van de zendingen runderen, levende producten of niet-verwerkte dierlijke bijproducten betreffende informatie aan de Commissie en de lidstaten voor op basis van risicobeoordelingen toegestane afwijkingen

Wanneer de bevoegde autoriteit op basis van de positieve uitkomst van een risicobeoordeling van de maatregelen tegen de verspreiding van infectie met het LSDV als bedoeld in de artikelen 7, 8 of 10 toestemming verleent voor verplaatsingen van zendingen runderen of levende producten, stelt de lidstaat van de plaats van oorsprong de Commissie en de andere lidstaten onmiddellijk in kennis van de diergezondheidsgaranties en van de goedkeuring door de bevoegde autoriteiten van de plaats van de inrichting van bestemming.

Artikel 20

Inwerkingtreding en toepassingsdatum

Deze verordening treedt in werking op de dag na die van de bekendmaking ervan in het Publicatieblad van de Europese Unie.

Zij is van toepassing tot en met 21 april 2023.

BIJLAGE I

BEPERKINGSZONES I EN II

(zoals bedoeld in artikel 3)

DEEL I

Beperkingszone I

1.   Bulgarije:

Het gehele grondgebied van Bulgarije

2.   Griekenland:

A.

De volgende regio’s in Griekenland: — regio Attica — regio Centraal-Griekenland — regio Centraal-Macedonië — regio Kreta — regio Oost-Macedonië en Thracië — regio Epirus — regio Ionische Eilanden, met uitzondering van de regionale eenheid Kerkyra — regio noordelijke Egeïsche Zee, met uitzondering van de regionale eenheid Limnos — regio Peloponnesos — regio zuidelijke Egeïsche Zee — regio Thessalië — regio West-Griekenland — regio West-Macedonië

B.	De volgende regionale eenheden in Griekenland: — regionale eenheid Limnos — regionale eenheid Kerkyra

DEEL II

Beperkingszone II

Geen

BIJLAGE II

VOORSCHRIFTEN VOOR VACCINATIEPROGRAMMA’S IN VERBAND MET INFECTIE MET HET NODULAIRE-DERMATOSEVIRUS

(zoals bedoeld in artikel 3)

DEEL I

Informatie die in het vaccinatieprogramma als bedoeld in artikel 3 moet worden opgenomen

Wanneer een lidstaat vaccineert tegen infectie met het LSDV, moet die vaccinatie worden uitgevoerd volgens een vaccinatieprogramma dat ten minste de volgende informatie bevat:

a)	de beschrijving en de resultaten van de overeenkomstig de criteria van artikel 46, lid 2, van Verordening (EU) 2016/429 uitgevoerde beoordeling, met inbegrip van de epidemiologische situatie en andere relevante informatie die als basis voor de beoordeling is gebruikt;

b)	de belangrijkste doelstellingen en streefcijfers in verband met de gekozen vaccinatiestrategie en het vaccinatieprogramma;

c)	de gedetailleerde geografische beschrijving van het vaccinatiegebied waar vaccinatie moet plaatsvinden en de locatie van de inrichtingen waar runderen worden gehouden die moeten worden gevaccineerd, inclusief kaarten;

d)	de autoriteit die verantwoordelijk is voor het toedienen van het vaccin aan de runderen;

e)	het systeem voor toezicht op de toediening van het vaccin;

f)	het aantal inrichtingen in de beperkingszone waar runderen worden gehouden en, indien verschillend, het aantal inrichtingen waar vaccinatie moet plaatsvinden;

g)	het geschatte aantal runderen en de categorie en leeftijd van de te vaccineren dieren;

h)	de beoogde duur van de vaccinatie, vanaf het begin van de vaccinatie tot het einde van de bewaking die na de vaccinatie zal plaatsvinden;

i)	de samenvatting van de kenmerken van het vaccin, waaronder de naam van het product en de naam van de fabrikant, en de wijzen van toediening;

j)	de vermelding, in voorkomend geval, dat het een vaccin betreft dat krachtens artikel 110, leden 2 en 3, van Verordening (EU) 2019/6 van het Europees Parlement en de Raad (1) wordt gebruikt;

k)	de methoden om de doeltreffendheid van de vaccinatie te beoordelen;

l)	de toe te passen hygiëne- en biobeveiligingsvoorschriften;

m)	het registratiesysteem voor de vaccinatie;

n)	andere aspecten die relevant zijn voor de specifieke situatie.

DEEL II

Minimumvereisten voor vaccinatieprogramma’s tegen infectie met het LSDV als bedoeld in artikel 3

De vaccinatieprogramma’s tegen infectie met het LSDV moeten in overeenstemming zijn met de volgende technische voorschriften:

a)	vaccinatie van alle runderen, ongeacht hun geslacht, leeftijd en drachtigheids- of productiestatus, in de beperkingszones I en II waar vaccinatie moet worden uitgevoerd;

b)	vaccinatie van de nakomelingen van gevaccineerde runderen ouder dan vier maanden volgens de instructies van de fabrikant van het gebruikte vaccin;

c)	hervaccinatie van alle runderen volgens de instructies van de fabrikant;

d)	opname van de gegevens voor elk gevaccineerd rund door de bevoegde autoriteit in het daartoe bestemde onlinegegevensbestand dat met het centrale gegevensbestand is verbonden, overeenkomstig artikel 42 van Verordening (EU) 2019/2035 van het Europees Parlement en de Raad (2);

e)	instelling van een gebied met verhoogde bewaking van ten minste 20 km rond de beperkingszones I en II waar vaccinatie plaatsvindt, waar verscherpte bewaking is en de bevoegde autoriteit toezicht houdt op de verplaatsing van runderen;

f)	vaccinatiegraad van ten minste 95 % van de beslagen, die ten minste 75 % van de runderpopulatie vertegenwoordigen.

DEEL III

Voorlopige informatie die aan de Commissie en de andere lidstaten moet worden verstrekt voordat met vaccinatie als bedoeld in artikel 3, lid 3, wordt begonnen

Lidstaten die vaccineren tegen nodulaire dermatose, moeten de Commissie en de andere lidstaten de volgende informatie verstrekken voordat met de vaccinatie wordt begonnen:

a)	een korte uitleg waarom met de vaccinatie wordt begonnen;

b)	de te vaccineren soorten runderen;

c)	het geschatte aantal te vaccineren runderen;

d)	de geschatte duur van de vaccinatie;

e)	het type en de handelsnaam van het gebruikte vaccin, waarbij moet worden aangegeven of het een vaccin betreft dat krachtens artikel 110, leden 2 en 3, van Verordening (EU) 2019/6 zal worden gebruikt;

f)	een beschrijving van het geschatte vaccinatiegebied.

---

(1)  Verordening (EU) 2019/6 van het Europees Parlement en de Raad van 11 december 2018 betreffende diergeneesmiddelen en tot intrekking van Richtlijn 2001/82/EG (PB L 4 van 7.1.2019, blz. 43).

(2)  Gedelegeerde Verordening (EU) 2019/2035 van de Commissie van 28 juni 2019 tot aanvulling van Verordening (EU) 2016/429 van het Europees Parlement en de Raad wat betreft regels voor inrichtingen waar landdieren worden gehouden en broederijen, alsmede voor de traceerbaarheid van bepaalde gehouden landdieren en broedeieren (PB L 314 van 5.12.2019, blz. 115).

Artikel 1

In artikel 4 van Uitvoeringsverordening (EU) 2021/442 wordt de tweede alinea vervangen door:

Artikel 2

In artikel 3 van Uitvoeringsverordening (EU) 2021/521 wordt de tweede alinea vervangen door:

Artikel 3

Deze verordening treedt in werking op 1 juli 2021.

Artikel 1

In afwijking van de artikelen 2, 3 en 4 van Besluit 2013/471/EU hebben begunstigden die een vergadering elektronisch op afstand bijwonen, indien COVID-19-gerelateerde beperkende maatregelen de mogelijkheid bemoeilijken om een fysieke vergadering te organiseren of een vergadering fysiek bij te wonen, slechts recht op een dagvergoeding die is vastgesteld op 145 EUR.

Artikel 2

Het Comité stelt uiterlijk op 2 september 2021 nadere bepalingen ter uitvoering van artikel 1 vast.

Artikel 3

Uiterlijk op 2 januari 2022 en vervolgens om de zes maanden dient het Comité bij de Raad een evaluatieverslag in over de toepassing van dit besluit, en met name over de gevolgen ervan voor de begroting en de aanhoudende aanwezigheid van COVID-19-gerelateerde reisproblemen of beperkende maatregelen die de mogelijkheid bemoeilijken om fysieke vergaderingen te organiseren of vergaderingen fysiek bij te wonen.

Artikel 4

Dit besluit treedt in werking op de dag na die van de bekendmaking ervan in het Publicatieblad van de Europese Unie.

Artikel 1

De technische specificaties voor het digitale EU-covidcertificaat, waarin de algemene datastructuur, de coderingsmechanismen en het transportcoderingsmechanisme in een machineleesbaar optisch formaat worden vastgesteld, zijn opgenomen in bijlage I.

Artikel 2

De regels voor het invullen van de in artikel 3, lid 1, van Verordening (EU) 2021/953 bedoelde certificaten zijn opgenomen in bijlage II bij dit besluit.

Artikel 3

De eisen inzake de gemeenschappelijke structuur van de unieke certificaatidentificatiecode zijn opgenomen in bijlage III.

Artikel 4

De governanceregels voor publiekesleutelcertificaten met betrekking tot de gateway voor digitale EU-covidcertificaten ter ondersteuning van de interoperabiliteitsaspecten van het vertrouwenskader, zijn opgenomen in bijlage IV.

BIJLAGE I

FORMAAT EN VERTROUWENSBEHEER

Algemene datastructuur, coderingsmechanismen en transportcoderingsmechanisme in een machineleesbaar optisch formaat (hierna “QR” genoemd)

1.   Inleiding

De technische specificaties in deze bijlage omvatten een algemene datastructuur en coderingsmechanismen voor het digitale EU-covidcertificaat (hierna “DCC” genoemd). Zij hebben ook betrekking op een transportcoderingsmechanisme in een machineleesbaar optisch formaat (“QR”), dat op het scherm van een mobiel apparaat kan worden weergegeven of dat kan worden afgedrukt. De containerindelingen van het elektronisch gezondheidscertificaat zijn in deze specificaties generiek, maar worden in dit verband gebruikt om de DCC te dragen.

2.   Terminologie

Voor de toepassing van deze bijlage staat “afgevers” voor organisaties die deze specificaties gebruiken voor de afgifte van gezondheidscertificaten en “verificateurs” voor organisaties die gezondheidscertificaten als bewijs van de gezondheidsstatus aanvaarden. “Deelnemers” zijn afgevers en verificateurs. Sommige aspecten van deze bijlage moeten worden gecoördineerd tussen de deelnemers, zoals het beheer van een naamruimte en de verdeling van cryptografische sleutels. Aangenomen wordt dat een partij, hierna “secretariaat” genoemd, deze taken uitvoert.

3.   Containerindeling van het elektronisch gezondheidscertificaat

De containerindeling van het elektronisch gezondheidscertificaat (Electronic Health Certificate Container Format, hierna “HCERT” genoemd) is ontworpen als een uniform en gestandaardiseerd vehikel voor gezondheidscertificaten van verschillende afgevers (“afgevers”). Het doel van deze specificaties is de wijze waarop deze gezondheidscertificaten worden weergegeven, gecodeerd en ondertekend te harmoniseren en daardoor de interoperabiliteit te bevorderen.

Om een door eender welke afgever afgegeven DCC te kunnen lezen en interpreteren, is er een gemeenschappelijke datastructuur nodig en moet er overeenstemming zijn over de betekenis van elk dataveld van de payload. Met het oog op die interoperabiliteit wordt een gemeenschappelijke gecoördineerde datastructuur gedefinieerd aan de hand van een “JSON”-schema dat het kader van het DCC vormt.

3.1.   Structuur van de payload

De payload is gestructureerd en gecodeerd als een CBOR met een digitale COSE-handtekening. Dit staat algemeen bekend als een “CBOR Web Token” (CWT) en wordt gedefinieerd in RFC 8392 (1). De payload, zoals gedefinieerd in de volgende onderdelen, wordt getransporteerd in een hcert-claim.

De integriteit en authenticiteit van de herkomst van de payloaddata moeten door de verificateur kunnen worden geverifieerd. Om dit mechanisme mogelijk te maken, moet de afgever het CWT ondertekenen met behulp van een asymmetrische methode voor elektronische handtekeningen zoals gedefinieerd in de COSE-specificering (RFC 8152 (2)).

3.2.   CWT-claims

3.2.1.   Overzicht van de CWT-structuur

Beschermde header

—	Algoritme Handtekening (alg, label 1)

—	Sleutelidentificatiecode (kid, label 4)

Payload

—	Afgever (iss, claim key 1, facultatief, ISO 3166-1 alpha-2 van afgever)

—	Afgegeven op (iat, claim key 6)

—	Vervaltijd (exp, claim key 4)

—	Gezondheidscertificaat (hcert, claim key -260)

—	Digitaal EU-covidcertificaat v1 (eu_DCC_v1, claim key 1)

Handtekening

3.2.2.   Algoritme van de handtekening

De parameter “Algoritme Handtekening” (alg) geeft aan welk algoritme wordt gebruikt voor het aanmaken van de handtekening. Het moet voldoen aan of verder gaan dan de huidige, hieronder samengevatte SOG-IS-richtsnoeren.

Er worden een primair en een secundair algoritme bepaald. Het secundaire algoritme mag alleen worden gebruikt als het primaire algoritme niet aanvaardbaar is binnen de aan de afgever opgelegde regels en voorschriften.

Om de beveiliging van het systeem te waarborgen, moeten alle implementaties het secundaire algoritme omvatten. Om deze reden moeten zowel het primaire als het secundaire algoritme worden toegepast.

De door SOG-IS vastgestelde niveaus voor de primaire en secundaire algoritmen zijn:

—

Primair algoritme: Het primaire algoritme is een elliptische krommealgoritme voor digitale handtekening (ECDSA), zoals gedefinieerd in (ISO/IEC 14888—3:2006) deel 2.3, waarbij gebruik wordt gemaakt van de P-256-parameters zoals gedefinieerd in aanhangsel D (D.1.2.3) bij (FIPS PUB 186-4) in combinatie met het SHA-256-hash-algoritme zoals gedefinieerd in (ISO/IEC 10118—3:2004) functie 4.

Dit komt overeen met COSE-algoritmeparameter ES256.

—	Secundair algoritme: Het secundaire algoritme is RSASSA-PSS zoals gedefinieerd in (RFC 8230 (3)) met een modulus van 2048 bits in combinatie met het SHA-256-hash-algoritme zoals gedefinieerd in (ISO/IEC 10118—3:2004) functie 4.

Dit komt overeen met COSE-algoritmeparameter PS256.

3.2.3.   Sleutelidentificatiecode

De claim “sleutelidentificatiecode” (kid) vermeldt in welk documentondertekenaarscertificaat (“Document Signer Certificate” of “DSC”) de publieke sleutel zit die de verificateur moet gebruiken om de juistheid van de digitale handtekening te controleren. Het beheer van publiekesleutelcertificaten, met inbegrip van eisen inzake DSC’s, wordt beschreven in bijlage IV.

De claim “sleutelidentificatiecode” (kid) wordt door verificateurs gebruikt om de juiste publieke sleutel te selecteren uit een lijst van sleutels met betrekking tot de afgever die wordt vermeld in de claim afgever (iss). Verschillende sleutels kunnen om administratieve redenen en bij het uitvoeren van sleutelrollovers parallel worden gebruikt door een afgever. De sleutelidentificatiecode is geen beveiligingskritiek veld. Om die reden kan het, indien nodig, ook in een onbeschermde header worden geplaatst. Verificateurs moeten beide opties aanvaarden. Indien beide opties voorhanden zijn, moet de sleutelidentificatiecode in de beschermde header worden gebruikt.

Door de verkorting van de identificatiecode (omdat de ruimte beperkt is) is er een kleine maar niet onbestaande kans dat de algemene lijst van DSC’s die door een verificateur worden aanvaard, DSC’s met dubbele kid’s bevat. Daarom moet een verificateur alle DSC’s met die kid controleren.

3.2.4.   Afgever

De claim “afgever” (iss) is een tekenreekswaarde die eventueel de ISO 3166-1 alpha-2-landcode kan bevatten van de entiteit die het gezondheidscertificaat afgeeft. Deze claim kan door een verificateur worden gebruikt om te bepalen welke reeks DSC’s moet worden gebruikt voor verificatie. De claim Key 1 wordt gebruikt om deze claim te identificeren.

3.2.5.   Vervaltijd

De claim “vervaltijd” (exp) bevat een tijdstempel in het NumericDate-formaat in gehele getallen (zoals gespecificeerd in RFC 8392 (4), deel 2), waarin wordt aangegeven tot wanneer deze specifieke handtekening voor de payload als geldig wordt beschouwd, waarna een verificateur de payload moet afwijzen omdat deze verlopen is. De parameter “vervaltijd” heeft tot doel de geldigheidstermijn van het gezondheidscertificaat te beperken. De claim Key 4 wordt gebruikt om deze claim te identificeren.

De vervaltijd mag niet langer zijn dan de geldigheidstermijn van het DSC.

3.2.6.   Afgegeven op

De claim “afgegeven op” (iat) bevat een tijdstempel in het NumericDate-formaat in gehele getallen (zoals gespecificeerd in RFC 8392 (5), deel 2), met vermelding van het tijdstip waarop het gezondheidscertificaat is aangemaakt.

De datum in het veld “afgegeven op” mag niet vallen vóór de geldigheidstermijn van het DSC.

Verificateurs kunnen aanvullende beleidslijnen toepassen om de geldigheid van het gezondheidscertificaat te beperken op basis van het tijdstip van afgifte. De claim Key 6 wordt gebruikt om deze claim te identificeren.

3.2.7.   Claim “gezondheidscertificaat”

De claim “gezondheidscertificaat” (hcert) is een JSON-object (RFC 7159 (6)) dat de informatie over de gezondheidsstatus omvat. Er kunnen verschillende soorten gezondheidscertificaten bestaan onder dezelfde claim, waarvan de DCC er één is.

De JSON is uitsluitend bedoeld voor schematische doeleinden. Het weergaveformaat is CBOR, zoals gedefinieerd in (RFC 7049 (7)). Applicatieontwikkelaars mogen in feite nooit het JSON-formaat decoderen of coderen naar en van het JSON-formaat, maar moeten de structuur in het geheugen gebruiken.

De te gebruiken Claim Key voor identificatie van deze claim is -260.

De strings in het JSON-object moeten worden genormaliseerd volgens Normalization Form Canonical Composition (NFC) zoals gedefinieerd in de Unicode-norm. Decodeertoepassingen moeten in deze opzichten echter ruim en robuust zijn, en de aanvaarding van elke redelijke omzetting wordt nadrukkelijk aangemoedigd. Indien tijdens het decoderen, of in latere vergelijkingsfuncties, niet-genormaliseerde data worden gevonden, moeten de implementaties zich gedragen alsof de input genormaliseerd is naar NFC.

4.   Serialisatie en creatie van de DCC-payload

Als serialisatiepatroon wordt het volgende schema gebruikt:

Het proces begint met het extraheren van data, bijvoorbeeld uit een opslagplaats voor gezondheidsdata (of een externe gegevensbron), waarbij de geëxtraheerde data worden gestructureerd volgens de gedefinieerde DCC-schema’s. In dit proces kunnen de omzetting naar het gedefinieerde dataformaat en de transformatie met het oog op menselijke leesbaarheid plaatsvinden voordat de serialisatie naar CBOR begint. De acroniemen van de claims worden in elk geval vóór serialisatie en na deserialisatie toegewezen aan de weergavenamen.

Facultatieve nationale data-inhoud is niet toegestaan in certificaten die zijn afgegeven op grond van Verordening (EU) 2021/953 (8). De data-inhoud is beperkt tot de gedefinieerde data-elementen in de minimale dataset zoals gespecificeerd in de bijlage bij Verordening (EU) 2021/953.

5.   Transportcodering

5.1.   Raw

Voor arbitraire data-interfaces mogen de HCERT-container en de payloads ervan ongewijzigd worden overgedragen, met gebruikmaking van elk mogelijk onderliggend, veilig en betrouwbaar 8-bit-datatransport. Deze interfaces kunnen NFC (Near Field Communication), bluetooth of overdracht via een toepassingslaagprotocol omvatten, bijvoorbeeld de overdracht van een HCERT van de afgever naar het mobiele apparaat van de houder.

Als de overdracht van de HCERT van de afgever naar de houder gebaseerd is op een interface voor uitsluitend weergave (bijvoorbeeld sms, e-mail), is de transportcodering Raw uiteraard niet van toepassing.

5.2.   Barcode

5.2.1.   Compressie van de payload (CWT)

Om de grootte te verminderen en de snelheid en betrouwbaarheid van het leesproces van de HCERT te verbeteren, wordt de CWT gecomprimeerd met behulp van ZLIB (RFC 1950 (9)) en het Deflate-compressiemechanisme in het formaat zoals gedefinieerd in RFC 1951 (10).

5.2.2.   QR-2D-barcode

Om ervoor te zorgen dat beter kan worden gewerkt met oude apparatuur die is ontworpen voor ASCII-payloads, wordt de gecomprimeerde CWT gecodeerd als ASCII met gebruikmaking van Base45 alvorens te worden gecodeerd in een 2D-barcode.

Voor het genereren van de 2D-barcode wordt het QR-formaat gebruikt zoals gedefinieerd in (ISO/IEC 18004:2015). Een foutcorrectiepercentage van “Q” (ongeveer 25 %) wordt aanbevolen. Omdat gebruik wordt gemaakt van Base45, moet voor de QR-code alfanumerieke codering worden gebruikt (modus 2, aangegeven door de symbolen 0010).

Om verificateurs in staat te stellen het soort gecodeerde data te detecteren en het juiste decoderings- en verwerkingsschema te kiezen, moeten de met Base45 gecodeerde data (volgens deze specificatie) worden voorafgegaan door de Context-Identifier-string “HC1:”. Bij toekomstige versies van deze specificatie die gevolgen hebben voor de compatibiliteit met oudere systemen, moet een nieuwe context-ID worden gedefinieerd, waarbij “HC” moet worden gevolgd door een teken uit de tekenset [1-9A-Z]. Deze tekens moeten in die volgorde worden bepaald, d.w.z. eerst [1-9] en vervolgens [A-Z].

Er wordt aanbevolen de optische code op het presentatiemedium weer te geven met een diagonaal tussen 35 mm en 60 mm, om het gebruik ervan te vergemakkelijken met lezers met vaste optische onderdelen indien het presentatiemedium op het oppervlak van de lezer moet worden geplaatst.

Indien de optische code op papier wordt gedrukt met behulp van printers met lage resolutie (< 300 dpi), moet erop worden gelet dat elk symbool (punt) van de QR-code precies vierkant worden weergegeven. Niet-proportionele schaalverkleining zal in sommige rijen of kolommen van de QR-code tot rechthoekige symbolen leiden, wat de leesbaarheid in veel gevallen zal bemoeilijken.

6.   Formaat van vertrouwenslijsten (CSCA- en DSC-lijst)

Elke lidstaat moet een lijst van een of meer Country Signing Certificate Authorities (CSCA’s) en een lijst van alle geldige Document Signer Certificates (DSC’s) verstrekken en deze lijsten actueel houden.

6.1.   Vereenvoudigde CSCA/DSC

Vanaf deze versie van de specificaties gaan de lidstaten er niet vanuit dat informatie uit de lijst van ingetrokken certificaten (Certificate Revocation List — CRL) is gebruikt of dat de gebruiksperiode van de persoonlijke sleutel door de uitvoerders is gecontroleerd.

Het primaire geldigheidsmechanisme is daarentegen de aanwezigheid van het certificaat op de meest recente versie van die certificaatlijst.

6.2.   eMRTD-PKI van de ICAO en trustcentra

De lidstaten kunnen een afzonderlijke CSCA gebruiken, maar kunnen ook hun bestaande CSCA-certificaten en/of DSC’s voor eMRTD indienen, en kunnen er zelfs voor kiezen deze in te kopen bij (commerciële) trustcentra en die vervolgens in te dienen. Een DSC moet echter altijd worden ondertekend door de CSCA die door die lidstaat is aangewezen.

7.   Beveiligingsoverwegingen

Bij het ontwerpen van een regeling aan de hand van deze specificatie bepalen, analyseren en monitoren de lidstaten bepaalde beveiligingsaspecten.

Ten minste met de volgende aspecten moet rekening worden gehouden:

7.1.   Geldigheidstermijn HCERT-handtekening

De uitgever van HCERT’s moet de geldigheidsduur van de handtekening beperken door een termijn voor het verstrijken van de handtekening te specificeren. Dit houdt in dat de houder van een gezondheidscertificaat het periodiek moet vernieuwen.

De aanvaardbare geldigheidsduur kan worden bepaald op basis van praktische beperkingen. Een reiziger heeft bijvoorbeeld niet de mogelijkheid om het gezondheidscertificaat tijdens een buitenlandse reis te verlengen. Het is echter ook mogelijk dat een afgever het mogelijk acht dat de beveiliging op een of andere manier is gecompromitteerd, waardoor de afgever een DSC moet intrekken (waardoor alle gezondheidscertificaten die zijn afgegeven met gebruikmaking van de sleutel die nog binnen de geldigheidsperiode valt, ongeldig worden verklaard). De gevolgen van een dergelijke gebeurtenis kunnen worden beperkt door de sleutels van de afgever regelmatig te vernieuwen en met redelijke intervallen de vernieuwing van alle gezondheidscertificaten te eisen.

7.2.   Sleutelbeheer

Deze specificatie is sterk afhankelijk van sterke cryptografische mechanismen om de integriteit van data en de authenticatie van de oorsprong van de data te beveiligen. Daarom is het noodzakelijk de vertrouwelijkheid van de persoonlijke sleutels te waarborgen.

De vertrouwelijkheid van cryptografische sleutels kan op verschillende manieren in het gedrang komen. Enkele voorbeelden:

—	Het proces waarbij de sleutel wordt aangemaakt, kan gebreken vertonen, wat leidt tot zwakke sleutels.

—	De sleutels kunnen worden onthuld door menselijke fouten.

—	De sleutels kunnen worden gestolen door externe of interne daders.

—	De sleutels kunnen worden berekend aan de hand van cryptoanalyse.

Om het risico op een zwak ondertekeningsalgoritme te beperken, waardoor de persoonlijke sleutels kunnen worden gecompromitteerd door cryptoanalyse, wordt met deze specificatie aanbevolen dat alle deelnemers voor noodgevallen een secundair ondertekeningsalgoritme toepassen op basis van andere parameters of een ander wiskundig probleem dan het primaire.

Wat de vermelde risico’s in verband met de besturingsomgevingen van de afgevers betreft, moeten risicobeperkende maatregelen worden genomen om een doeltreffende controle te waarborgen, zodat de persoonlijke sleutels worden gegenereerd, opgeslagen en gebruikt in HSM’s (Hardware Security Modules). Het gebruik van HSM’s voor het ondertekenen van gezondheidscertificaten wordt nadrukkelijk aangemoedigd.

Ongeacht of een afgever besluit HSM’s te gebruiken of niet, moet een schema voor sleutelrollovers worden vastgesteld waarbij de frequentie van de sleutelrollovers in verhouding staat tot de blootstelling van de sleutels aan externe netwerken, andere systemen en personeel. Een goed gekozen rolloverschema beperkt ook de risico’s in verband met ten onrechte afgegeven gezondheidscertificaten, waardoor een afgever dergelijke gezondheidscertificaten in batches kan intrekken door zo nodig een sleutel in te trekken.

7.3.   Validatie van inputdata

Deze specificaties kunnen worden gebruikt op een manier die inhoudt dat data van onbetrouwbare bronnen worden ontvangen in systemen die van missiekritische aard kunnen zijn. Om de risico’s in verband met deze aanvalsvector tot een minimum te beperken, moeten alle inputvelden naar behoren worden gevalideerd op basis van datatypes, -lengtes en -inhoud. De handtekening van de afgever wordt ook geverifieerd voordat de inhoud van het HCERT wordt verwerkt. De validatie van de handtekening van de afgever houdt echter in dat eerst de beschermde header van de afgever wordt geparseerd, waarbij een potentiële aanvaller kan proberen zorgvuldig gefabriceerde informatie in te voeren die bedoeld is om de beveiliging van het systeem in gevaar te brengen.

8.   Vertrouwensbeheer

Om de HCERT-handtekening te verifiëren, is een publieke sleutel nodig. De lidstaten maken deze publieke sleutels bekend. Uiteindelijk moet elke verificateur beschikken over een lijst van alle publieke sleutels die hij bereid is te vertrouwen (aangezien de publieke sleutel geen deel uitmaakt van het HCERT).

Het systeem bestaat uit (slechts) twee lagen; voor elke lidstaat een of meer landencertificaten waarmee telkens een of meer DSC’s worden ondertekend die dagelijks worden gebruikt.

De certificaten van de lidstaten worden CSCA’s genoemd (Country Signing Certificate Authority) en zijn (doorgaans) zelfondertekend. De lidstaten kunnen er meer dan één hebben (bijvoorbeeld in het geval van regionale decentralisatie). Deze CSCA-certificaten ondertekenen regelmatig de DSC’s (Document Signer Certificates) die worden gebruikt voor het ondertekenen van HCERT’s.

Het “secretariaat” is een functionele rol. Het verzamelt en publiceert de DSC’s van de lidstaten op regelmatige tijdstippen, nadat het deze heeft geverifieerd aan de hand van de lijst van CSCA-certificaten (die met andere middelen zijn overgedragen en geverifieerd).

De daaruit voortvloeiende lijst van DSC’s bevat dan de geaggregeerde reeks aanvaardbare publieke sleutels (en de bijbehorende sleutelidentificatiecodes) die verificateurs kunnen gebruiken om de handtekeningen via de HCERT’s te valideren. Verificateurs moeten deze lijst regelmatig ophalen en actualiseren.

Dergelijke lidstaatspecifieke lijsten kunnen worden omgezet in het door de lidstaat vastgestelde formaat. Het bestandsformaat van deze vertrouwenslijst kan dus variëren: het kan een ondertekend JWKS zijn (JWK-setindeling volgens RFC 7517 (11), deel 5) of een ander formaat dat specifiek is voor de in die lidstaat gebruikte technologie.

Ter wille van de eenvoud kunnen de lidstaten zowel hun bestaande CSCA-certificaten van hun eMRTD-systemen van de ICAO indienen of, zoals aanbevolen door de WHO, een specifiek certificaat voor dit gezondheidsgebied creëren.

8.1.   De sleutelidentificatiecode

De sleutelidentificatiecode (“key identifier” of “kid”) wordt berekend bij het samenstellen van de lijst van betrouwbare publieke sleutels van DSC’s en bestaat uit een afgekapte (eerste 8 bytes) SHA-256-vingerafdruk van het DSC die is gecodeerd in het DER-formaat (raw).

Verificateurs hoeven de sleutelidentificatiecode niet te berekenen op basis van het DSC en kunnen de sleutelidentificatiecode in het afgegeven gezondheidscertificaat direct matchen met de sleutelidentificatiecode op de vertrouwenslijst.

8.2.   Verschillen met het eMRTD-PKI-vertrouwensmodel van de ICAO

Hoewel er wordt voortgebouwd op beste praktijken van het eMRTD-PKI-vertrouwensmodel van de ICAO, wordt in het belang van de snelheid een aantal vereenvoudigingen aangebracht:

—	Een lidstaat kan meerdere CSCA-certificaten indienen.

—	De geldigheidstermijn van het DSC (sleutelgebruik) kan eender welke lengte hebben, zolang deze de geldigheidstermijn van het CSCA-certificaat niet overschrijdt, en mag ontbreken.

—	Het DSC mag beleidsidentificatiecodes (uitgebreide-sleutelgebruik) bevatten die specifiek zijn voor gezondheidscertificaten.

—	De lidstaten kunnen ervoor kiezen gepubliceerde intrekkingen nooit te verifiëren, maar uitsluitend gebruik te maken van de DSC-lijsten die zij dagelijks van het secretariaat ontvangen of zelf samenstellen.

---

(1)  rfc8392 (ietf.org)

(2)  rfc8152 (ietf.org)

(3)  rfc8230 (ietf.org)

(4)  rfc8392 (ietf.org)

(5)  rfc8392 (ietf.org)

(6)  rfc7159 (ietf.org)

(7)  rfc7049 (ietf.org)

(8)  Verordening (EU) 2021/953 van het Europees Parlement en de Raad van 14 juni 2021 betreffende een kader voor de afgifte, verificatie en aanvaarding van interoperabele COVID-19-vaccinatie-, test- en herstelcertificaten (digitaal EU-COVID-certificaat) teneinde het vrije verkeer tijdens de COVID-19-pandemie te faciliteren (PB L 211 van 15.6.2021, blz. 1).

(9)  rfc1950 (ietf.org)

(10)  rfc1951 (ietf.org)

(11)  rfc7517 (ietf.org)

BIJLAGE II

REGELS VOOR HET INVULLEN VAN HET DIGITALE EU-COVIDCERTIFICAAT

De algemene regels betreffende de in deze bijlage vastgestelde waardereeksen zijn bedoeld om interoperabiliteit op semantisch niveau te waarborgen en moeten uniforme technische implementaties voor het DCC mogelijk maken. De elementen in deze bijlage mogen worden gebruikt voor de drie verschillende certificaten (vaccinatie/test/herstel), zoals vermeld in Verordening (EU) 2021/953. In deze bijlage worden alleen elementen vermeld waarvoor semantische standaardisering door middel van gecodeerde waardereeksen noodzakelijk is.

Voor de vertaling van de gecodeerde elementen in de nationale taal valt zijn de lidstaten verantwoordelijk.

Voor alle datavelden die niet in de volgende omschrijvingen van waardereeksen worden vermeld, wordt codering in UTF-8 aanbevolen (naam, testcentrum, certificaatafgever). Voor datavelden met kalenderdata (geboortedatum, vaccinatiedatum, datum van monsterneming, datum van eerste positieve testresultaat, geldigheidstermijn van het certificaat) wordt codering volgens ISO 8601 aanbevolen.

Indien om welke reden dan ook de hieronder vermelde voorkeurscodesystemen niet kunnen worden gebruikt, mogen andere internationale codesystemen worden gebruikt en moet advies worden gegeven over de wijze waarop de codes van het andere codesysteem aan het voorkeurscodesysteem kunnen worden gekoppeld. In uitzonderlijke gevallen mag als back-upmechanisme tekst (weergavenamen) worden gebruikt wanneer in de gedefinieerde waardereeksen geen geschikte code beschikbaar is.

Lidstaten die andere coderingen in hun systemen gebruiken, moeten deze codes koppelen aan de beschreven waardereeksen. De lidstaten zijn verantwoordelijk voor dergelijke koppelingen.

De waardereeksen worden regelmatig door de Commissie bijgewerkt met de steun van het e-gezondheidsnetwerk en het Gezondheidsbeveiligingscomité. De bijgewerkte waardereeksen worden gepubliceerd op de desbetreffende website van de Commissie en op de webpagina van het e-gezondheidsnetwerk. Er moet een overzicht van de wijzigingen worden gegeven.

1.   Doelziekte of -ziekteverwekker/ziekte of ziekteverwekker waarvan de houder zich heeft hersteld: COVID-19 (SARS-CoV-2 of een van de varianten daarvan)

Voorkeurscodesysteem: SNOMED CT.

Te gebruiken in de certificaten 1, 2 en 3

De geselecteerde codes verwijzen naar COVID-19 of, indien meer gedetailleerde informatie over de genetische variant van SARS-CoV-2 nodig is, naar deze varianten indien die gedetailleerde informatie om epidemiologische redenen nodig is.

Een voorbeeld van een code die moet worden gebruikt, is SNOMED CT-code 840539006 (COVID-19).

2.   COVID-19-vaccin of -profylaxe;

Voorkeurscodesysteem: SNOMED CT- of ATC-classificatie.

Te gebruiken in certificaat 1.

Voorbeelden van codes die moeten worden gebruikt uit de voorkeurscodesystemen zijn SNOMED CT-code 1119305005 (SARS-CoV-2-antigeenvaccin), 1119349007 (SARS-CoV-2-mRNA-vaccin) of J07BX03 (COVID-19-vaccins). De waardereeks moet worden uitgebreid wanneer nieuwe vaccintypes worden ontwikkeld en in gebruik worden genomen.

3.   COVID-19-vaccin

Voorkeurscodesystemen (in volgorde van voorkeur):

—	Het geneesmiddelenregister van de EU voor vaccins met EU-brede vergunning (vergunningsnummers)

—	Een wereldwijd vaccinregister, zoals een register dat door de Wereldgezondheidsorganisatie zou kunnen worden opgesteld

—	Naam van het vaccin in andere gevallen. Indien de naam spaties bevat, moeten deze worden vervangen door een koppelteken (-).

Naam van de waardereeks: vaccin.

Te gebruiken in certificaat 1.

Een voorbeeld van een code uit de voorkeurscodesystemen die moet worden gebruikt is EU/1/20/1528 (Comirnaty). Een voorbeeld van de naam van het vaccin die als code moet worden gebruikt: Sputnik-V (staat voor Sputnik V).

4.   Handelsvergunninghouder of producent van het COVID-19-vaccin

Voorkeurscodesysteem:

—	Organisatiecode van het EMA (SPOR-systeem voor ISO IDMP)

—	Een wereldwijd register van handelsvergunninghouders of producenten van een vaccin, zoals een register dat door de Wereldgezondheidsorganisatie zou kunnen worden opgesteld

—	Naam van de organisatie in andere gevallen. Indien de naam spaties bevat, moeten deze worden vervangen door een koppelteken (-).

Te gebruiken in certificaat 1.

Een voorbeeld van een code uit het voorkeurscodesysteem die moet worden gebruikt is ORG-100001699 (AstraZeneca AB). Een voorbeeld van de naam van de organisatie die als code moet worden gebruikt: Sinovac-Biotech (staat voor Sinovac Biotech).

5.   Volgnummer in een reeks doses alsook totale aantal doses in de reeks

Te gebruiken in certificaat 1.

Twee velden:

1)	Aantal in een cyclus toegediende dosissen

2)	Aantal verwachte dosissen voor een volledige cyclus (specifiek voor een persoon op het moment van toediening)

Zo zal bij 1/1 of 2/2 de cyclus als voltooid worden voorgesteld, met inbegrip van optie 1/1 voor vaccins met twee dosissen, maar waarvoor het door de lidstaat toegepaste protocol erin bestaat één dosis toe te dienen aan burgers die met COVID-19 zijn gediagnosticeerd vóór hun vaccinatie. Het totale aantal dosissen in de cyclus moet worden aangegeven op basis van de informatie die beschikbaar is op het moment dat de dosis wordt toegediend. Als voor een specifiek vaccin bijvoorbeeld een derde prik (booster) nodig is op het moment van de laatst toegediende prik, moet dit in het tweede veldnummer worden weergegeven (bijvoorbeeld 2/3, 3/3 enz.).

6.   Lidstaat of derde land waar het vaccin werd toegediend/waar de test werd uitgevoerd

Voorkeurscodesysteem: ISO 3166-landcodes.

Te gebruiken in de certificaten 1, 2 en 3

Inhoud van de waardereeks: de volledige lijst van 2-lettercodes, beschikbaar als een in FHIR gedefinieerde waardereeks (http://hl7.org/fhir/ValueSet/iso3166-1-2)

7.   Type test

Voorkeurscodesysteem: LOINC.

Te gebruiken in certificaten 2 en 3 indien ondersteuning voor de afgifte van herstelcertificaten op basis van andere soorten tests dan NAAT wordt ingevoerd bij een gedelegeerde handeling.

De codes in deze waardereeks verwijzen naar de testmethode en moeten worden gekozen om ten minste de NAAT-tests te scheiden van de RAT-tests als bedoeld in Verordening (EU) 2021/953.

Een voorbeeld van een code uit het voorkeurscodesysteem die moet worden gebruikt is LP217198-3 (immunoassay-sneltest).

8.   Fabrikant en handelsnaam van de gebruikte test (facultatief voor NAAT-test)

Voorkeurscodesysteem: Lijst van het Gezondheidsbeveiligingscomité met snelle antigeentests zoals bijgehouden door het JRC (database van middelen voor in-vitrodiagnostiek en testmethoden voor COVID-19).

Te gebruiken in certificaat 2.

De inhoud van de waardereeks omvat de selectie van snelle antigeentests zoals opgenomen in de gemeenschappelijke en geactualiseerde lijst van snelle antigeentests voor COVID-19, vastgesteld op basis van Aanbeveling 2021/C 24/01 van de Raad en goedgekeurd door het Gezondheidsbeveiligingscomité. De lijst wordt door het JRC bijgehouden in de database van middelen voor in-vitrodiagnostiek en testmethoden voor COVID-19 op: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

Voor dit codesysteem moeten relevante velden, zoals de identificatiecode van het testapparaat, de naam van de test en de fabrikant worden gebruikt volgens het gestructureerde formaat van het JRC dat beschikbaar is op https://covid-19-diagnostics.jrc.ec.europa.eu/devices.

9.   Testresultaat

Voorkeurscodesysteem: SNOMED CT.

Te gebruiken in certificaat 2.

Aan de hand van de gekozen codes moet een onderscheid kunnen worden gemaakt tussen positieve en negatieve testresultaten (al dan niet gedetecteerd). Aanvullende waarden (bijv. onbepaald) kunnen worden toegevoegd indien de gebruiksomstandigheden dit vereisen.

Voorbeelden van codes uit de voorkeurscodesystemen die moeten worden gebruikt, zijn 260415000 (niet gedetecteerd) en 260373001 (gedetecteerd).

BIJLAGE III

GEMEENSCHAPPELIJKE STRUCTUUR VAN DE UNIEKE CERTIFICAATIDENTIFICATIECODE

1.   Inleiding

Elk digitaal EU-covidcertificaat (DCC) bevat een unieke certificeringsidentificatiecode (UCI) ter ondersteuning van de interoperabiliteit van de DCC’s. De UCI kan worden gebruikt om het certificaat te verifiëren. De lidstaten zijn verantwoordelijk voor de implementatie van de UCI. De UCI is een middel om de waarheidsgetrouwheid van het certificaat te verifiëren en, indien van toepassing, te koppelen aan een registratiesysteem (bijvoorbeeld een IIS). Op basis van deze identificatiecodes moeten de lidstaten ook (op papier en digitaal) kunnen vaststellen dat personen gevaccineerd of getest zijn.

2.   Samenstelling van de unieke certificaatidentificatiecode

De UCI volgt een gemeenschappelijke structuur en een gemeenschappelijk formaat die de menselijke en/of machinale interpretatie van informatie vergemakkelijken en kan betrekking hebben op elementen zoals de lidstaat van vaccinatie, het vaccin zelf en een lidstaatspecifieke identificatiecode. De UCI biedt de lidstaten flexibiliteit bij het opstellen ervan, met volledige inachtneming van de wetgeving inzake gegevensbescherming. De volgorde van de afzonderlijke elementen volgt een vastgestelde hiërarchie die toekomstige wijzigingen van de blokken mogelijk maakt met behoud van de structurele integriteit ervan.

De mogelijke oplossingen voor de samenstelling van de UCI vormen een spectrum waarin de twee belangrijkste onderscheidende parameters de moduleerbaarheid en de menselijke interpreteerbaarheid zijn en er één fundamenteel kenmerk is:

—	Moduleerbaarheid: de mate waarin de code is samengesteld uit afzonderlijke bouwstenen die semantisch verschillende informatie bevatten;

—	Menselijke interpreteerbaarheid: de mate waarin de code betekenisvol is voor of geïnterpreteerd kan worden door de menselijke lezer;

—

Wereldwijd uniek; de identificatiecode van het land of de autoriteit wordt goed beheerd; en van elk land (elke autoriteit) wordt verwacht dat het zijn segment van de namespace goed beheert door nooit identificatiecodes te hergebruiken of opnieuw af te geven. De combinatie daarvan zorgt ervoor dat elke identificatiecode wereldwijd uniek is.

3.   Algemene eisen

Met betrekking tot de UCI moet aan de volgende overkoepelende eisen worden voldaan:

1)	Tekenset: alleen US-ASCII-alfanumerieke tekens in hoofdletters (“A” tot en met “Z”, “0” tot en met “9”) zijn toegestaan; met extra speciale tekens voor scheiding van RFC3986 (1) (2), namelijk {“/”, “#”, “:”};

2)	Maximumlengte: ontwerpers moeten streven naar een lengte van 27-30 tekens (3);

3)	Versieprefix: dit verwijst naar de versie van het UCI-schema. Het versieprefix is “01” voor deze versie van het document; het versieprefix bestaat uit twee cijfers;

4)	Landprefix: de landcode is gespecificeerd volgens ISO 3166-1. Langere codes (bv. 3 tekens en meer (bijvoorbeeld “UNHCR”) zijn gereserveerd voor toekomstig gebruik;

5)

Suffix/checksum van de code: 5.1. De lidstaten moeten een checksum gebruiken wanneer het waarschijnlijk is dat verzending, (menselijke) transcriptie of andere corrupties zich kunnen voordoen (d.w.z. bij gebruik in gedrukte vorm). 5.2. De checksum mag niet worden gebruikt voor de validatie van het certificaat en maakt technisch gezien geen deel uit van de identificatiecode, maar wordt gebruikt om de integriteit van de code te verifiëren. Deze checksum moet de samenvatting volgens ISO-7812-1 (LUHN-10) (4) zijn van de volledige UCI in digitaal/draadformaat. De checksum wordt van de rest van de UCI gescheiden door een #-teken.

Er moet worden gezorgd voor compatibiliteit met oudere systemen: lidstaten die na verloop van tijd de structuur van hun identificatiecodes wijzigen (in de hoofdversie, momenteel vastgesteld op v1), zorgen ervoor dat twee identieke identificatiecodes voor hetzelfde vaccinatiecertificaat/dezelfde verklaring staan. Of, met andere woorden, de lidstaten kunnen identificatiecodes niet hergebruiken.

4.   Opties voor unieke identificatiecodes voor vaccinatiecertificaten

De richtsnoeren van het e-gezondheidsnetwerk inzake verifieerbare vaccinatiecertificaten en basisinteroperabiliteitselementen (5) biedt de lidstaten en andere partijen verschillende opties die mogelijk naast elkaar kunnen bestaan. De lidstaten kunnen dergelijke verschillende opties gebruiken in verschillende versies van het UCI-schema.

---

(1)  rfc3986 (ietf.org)

(2)  Velden zoals geslacht, identificatienummer van de batch/partij, vaccinatiecentrum, identificatiecode gezondheidswerker, volgende vaccinatiedatum zijn mogelijk niet nodig voor andere doeleinden dan medisch gebruik.

(3)  Voor de implementatie met QR-codes kunnen de lidstaten overwegen een extra reeks tekens met een totale lengte van 72 tekens (met inbegrip van de 27-30 van de identificatiecode zelf) te gebruiken om andere informatie over te brengen. Het is aan de lidstaten om deze informatie nader te omschrijven.

(4)  Het “Luhn mod N”-algoritme is een uitbreiding van het Luhn-algoritme (ook bekend als het mod 10-algoritme), dat voor numerieke codes werkt en bijvoorbeeld wordt gebruikt voor de berekening van de checksum van kredietkaarten. Met de extensie kan het algoritme werken met sequenties van waarden in om het even welke basis (in dit geval alfanumerieke tekens).

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

BIJLAGE IV

BEHEER VAN PUBLIEKESLEUTELCERTIFICATEN

1.   Inleiding

De beveiligde en betrouwbare uitwisseling van handtekeningsleutels voor digitale EU-covidcertificaten (DCC’s) tussen de lidstaten gebeurt via de gateway voor digitale EU-covidcertificaten (DCCG), die fungeert als centraal register voor de publieke sleutels. Met de DCCG kunnen de lidstaten de publieke sleutels publiceren die overeenkomen met de persoonlijke sleutels die zij gebruiken om digitale EU-covidcertificaten te ondertekenen. De lidstaten kunnen de DCCG gebruiken om tijdig actueel publiekesleutelmateriaal op te halen. Later kan de DCCG worden uitgebreid om betrouwbare aanvullende informatie uit te wisselen die de lidstaten verstrekken, zoals validatieregels voor DCC’s. Het vertrouwensmodel van het DCC-kader is een publiekesleutelinfrastructuur (Public Key Infrastructure, PKI). Elke lidstaat heeft een of meer Country Signing Certificate Authorities (CSCA’s), waarvan de certificaten relatief lang blijven bestaan. De lidstaten kunnen beslissen of de CSCA gelijk is aan of verschillend is van de CSCA die voor machineleesbare reisdocumenten wordt gebruikt. De CSCA geeft publiekesleutelcertificaten af voor de nationale, tijdelijke documentondertekenaars (d.w.z. ondertekenaars voor DCC’s), die Document Signer Certificates (DSC’s) worden genoemd. De CSCA fungeert als een vertrouwensanker zodat de lidstaten de CSCA kunnen gebruiken om de authenticiteit en integriteit van de regelmatig veranderende DSC’s te valideren. Na validatie kunnen de lidstaten hun DCC-validatietoepassingen voorzien van deze certificaten (of alleen de daarin vervatte publieke sleutels). Naast de CSCA’s en DSC’s vertrouwt de DCCG ook op PKI om transacties te authenticeren, data te ondertekenen, als basis voor authenticatie en als middel om de integriteit van de communicatiekanalen tussen de lidstaten en de DCCG te waarborgen.

Digitale handtekeningen kunnen worden gebruikt voor de integriteit en authenticiteit van de gegevens. Publiekesleutelinfrastructuren zorgen voor vertrouwen omdat ze publieke sleutels koppelen aan geverifieerde afgevers. Dit is noodzakelijk om andere deelnemers in staat te stellen de herkomst van de data en de identiteit van de communicatiepartner te controleren en te beslissen of deze te vertrouwen zijn. In de DCCG worden meerdere PKI-certificaten gebruikt om de authenticiteit te verifiëren. In deze bijlage wordt bepaald welke publiekesleutelcertificaten worden gebruikt en hoe deze moeten worden ontworpen om een brede interoperabiliteit tussen de lidstaten mogelijk te maken. Deze bijlage biedt meer details over de noodzakelijke publiekesleutelcertificaten en bevat richtsnoeren over certificaatmodellen en geldigheidstermijnen voor lidstaten die hun eigen CSCA willen exploiteren. Aangezien DCC’s voor een bepaald tijdsbestek verifieerbaar zijn (vanaf het moment van de afgifte tot wanneer ze na een bepaalde tijd vervallen), moet een verificatiemodel worden vastgesteld voor alle handtekeningen die op de publiekesleutelcertificaten en de DCC’s worden toegepast.

2.   Terminologie

De volgende tabel bevat de in deze bijlage gebruikte afkortingen en terminologie.

Begrip	Definities
Certificaat	Of publiekesleutelcertificaat. Een X.509-v3-certificaat dat de publieke sleutel van een entiteit bevat
CSCA	Country Signing Certificate Authority (nationale ondertekenende certificeringsautoriteit)
DCC	Digitaal EU-covidcertificaat Een ondertekend digitaal document met vaccinatie-, test- of herstelinformatie
DCCG	Gateway voor digitale EU-covidcertificaten. Dit systeem wordt gebruikt voor de uitwisseling van DSC’s tussen de lidstaten.
DCCGTA	Het vertrouwensankercertificaat van de DCCG. De overeenkomstige persoonlijke sleutel wordt gebruikt om de lijst van alle CSCA-certificaten offline te ondertekenen.
DCCGTLS	Het TLS-servercertificaat van de DCCG.
DSC	Document Signer Certificate (documentondertekenaarscertificaat). Het publiekesleutelcertificaat van de lidstaatautoriteit die documenten ondertekent (bijvoorbeeld een systeem dat DCC’s mag ondertekenen). Dit certificaat wordt afgegeven door de CSCA van de lidstaat.
EC-DSA	Elliptische krommealgoritme voor digitale handtekening. Een cryptografisch handtekeningalgoritme op basis van elliptische krommen
Lidstaat	Lidstaat van de Europese Unie
mTLS	Wederzijdse TLS. Het protocol inzake beveiliging op het niveau van de vervoerslaag (“Transport Layer Security Protocol”) met wederzijdse authenticatie
NB	Nationale backend van een lidstaat
NBCSCA	Het CSCA-certificaat van een lidstaat (kan meer dan één zijn)
NBTLS	Het TLS-cliëntauthenticatiecertificaat van een nationaal backend
NBUP	Het certificaat dat een nationale backend gebruikt om naar de DCCG geüploade datapakketten te ondertekenen
PKI	Publiekesleutelinfrastructuur. Vertrouwensmodel op basis van publiekesleutelcertificaten en certificeringsautoriteiten
RSA	Asymmetrisch cryptografisch algoritme op basis van ontbinding in gehele getallen dat wordt gebruikt voor digitale handtekeningen of asymmetrische versleuteling

3.   DCCG-communicatiestromen en -beveiligingsdiensten

In dit deel wordt een overzicht gegeven van de communicatiestromen en beveiligingsdiensten in het DCCG-systeem. Hier wordt ook bepaald welke sleutels en certificaten worden gebruikt om de communicatie, de geüploade informatie, de DCC’s en een ondertekende vertrouwenslijst met alle geïntroduceerde CSCA-certificaten te beschermen. De DCCG fungeert als dataknooppunt dat de uitwisseling van ondertekende datapakketten door de lidstaten mogelijk maakt.

Geüploade datapakketten worden ongewijzigd door de DCCG verstrekt, wat betekent dat de DCCG geen DSC’s toevoegt of verwijdert uit de pakketten die hij ontvangt. De nationale backend (NB) van de lidstaten wordt in staat gesteld de integriteit en authenticiteit van de geüploade gegevens end-to-end te verifiëren. Daarnaast zullen nationale backends en de DCCG gebruikmaken van wederzijdse TLS-authenticatie om een beveiligde verbinding tot stand te brengen. Dit komt bovenop de handtekeningen in de uitgewisselde data.

3.1.   Authenticatie en maken van verbinding

De DCCG maakt gebruik van Transport Layer Security (TLS) met wederzijdse authenticatie om een geauthenticeerd versleuteld kanaal tot stand te brengen tussen de nationale backend (NB) van de lidstaat en de gatewayomgeving. De DCCG beschikt derhalve over een TLS-servercertificaat, afgekort DCCGTLS, en de nationale backends hebben een TLS-cliëntcertificaat, afgekort NBTLS. De modellen voor de certificaten zijn opgenomen in deel 5. Elke nationale backend kan zijn eigen TLS-certificaat verstrekken. Dit certificaat wordt uitdrukkelijk op de whitelist geplaatst en kan dus worden afgegeven door een openbaar vertrouwde certificeringsautoriteit (bijvoorbeeld een certificeringsautoriteit die voldoet aan de basisvereisten van het CA Browser Forum), door een nationale certificeringsautoriteit of door zelfondertekening. Elke lidstaat is verantwoordelijk voor zijn nationale gegevens en voor de bescherming van de persoonlijke sleutel die wordt gebruikt om de verbinding met de DCCG tot stand te brengen. Voor de BYOC-aanpak (“bring your own certificate”) is een duidelijk omschreven registratie- en identificatieprocedure nodig, evenals intrekkings- en hernieuwingsprocedures, zoals beschreven in delen 4.1, 4.2 en 4.3. De DCCG gebruikt een whitelist waaraan de TLS-certificaten van NB’s worden toegevoegd nadat ze succesvol geregistreerd zijn. Alleen NB’s die zichzelf authenticeren met een persoonlijke sleutel die overeenkomt met een certificaat op de whitelist, kunnen een beveiligde verbinding met de DCCG tot stand brengen. De DCCG zal ook een TLS-certificaat gebruiken dat de NB’s in staat stelt na te gaan of zij daadwerkelijk een verbinding met de “echte” DCCG tot stand brengen en niet met een kwaadwillige entiteit die zich als DCCG voordoet. Het certificaat van de DCCG wordt na succesvolle registratie aan de NB’s verstrekt. Het DCCGTLS-certificaat wordt afgegeven door een openbaar vertrouwde CA (opgenomen in alle belangrijke browsers). Het is de verantwoordelijkheid van de lidstaten om na te gaan of hun verbinding met de DCCG beveiligd is (bijvoorbeeld door de vingerafdruk van het DCCGTLS-certificaat van de server waarmee verbinding is gemaakt, te vergelijken met het certificaat dat na registratie werd verstrekt).

3.2.   CSCA’s en validatiemodel

De lidstaten die deelnemen aan het DCCG-kader moeten een CSCA gebruiken om de DSC’s af te geven. De lidstaten kunnen meer dan één CSCA hebben (bijvoorbeeld in het geval van regionale decentralisatie). Elke lidstaat kan gebruikmaken van bestaande certificeringsautoriteiten of speciaal voor het DCC-systeem een (eventueel zelfondertekende) certificeringsautoriteit opzetten.

De lidstaten moeten hun CSCA-certificaat/-certificaten aan de DCCG-exploitant overleggen in het kader van de officiële onboardingprocedure. Na succesvolle registratie van de lidstaat (zie deel 4.1 voor meer informatie) werkt de DCCG-exploitant een ondertekende vertrouwenslijst bij met alle CSCA-certificaten die actief zijn in het DCC-kader. De DCCG-exploitant gebruikt een specifiek asymmetrisch sleutelpaar om de vertrouwenslijst en de certificaten in een offline omgeving te ondertekenen. De persoonlijke sleutel wordt niet opgeslagen in het online DCCG-systeem, zodat een aanvaller die het onlinesysteem binnendringt de vertrouwenslijst niet in gevaar kan brengen. Het overeenkomstige vertrouwensankercertificaat DCCGTA wordt tijdens het onboardingproces aan de nationale backends verstrekt.

De lidstaten kunnen voor hun verificatieprocedures de vertrouwenslijst opvragen bij de DCCG. De CSCA wordt gedefinieerd als de certificeringsautoriteit die DSC’s afgeeft; daarom moeten lidstaten die gebruikmaken van een meerlagige CA-hiërarchie (bijvoorbeeld basis-CA -> CSCA -> DSC’s) zorgen voor de ondergeschikte certificeringsautoriteit die de DSC’s afgeeft. Als een lidstaat in dat geval gebruikmaakt van een bestaande certificeringsautoriteit, zal het DCC-systeem alles boven de CSCA negeren en alleen de CSCA als vertrouwensanker toestaan (ook al is het een ondergeschikte CA). Dit is zo omdat het ICAO-model slechts precies 2 niveaus toestaat — een basis-CSCA (“root”) en een eind-DSC (“leaf”), ondertekend door alleen die CSCA.

Indien een lidstaat zijn eigen CSCA exploiteert, is de lidstaat verantwoordelijk voor de beveiligde werking en het beveiligde sleutelbeheer van deze CA. De CSCA fungeert als vertrouwensanker voor DSC’s, en daarom is het beschermen van de persoonlijke sleutel van de CSCA van essentieel belang voor de integriteit van de DCC-omgeving. Het verificatiemodel in de DCC-PKI volgt het shell-model, dat bepaalt dat alle certificaten bij de validatie van het certificaatpad op een bepaald tijdstip geldig moeten zijn (d.w.z. het moment van validatie van de handtekening). Daarom zijn de volgende beperkingen van toepassing:

—	De CSCA geeft geen certificaten af die langer geldig zijn dan het CA-certificaat zelf;

—	De ondertekenaar van het document mag geen documenten ondertekenen die langer geldig zijn dan het DSC zelf;

—	De lidstaten die hun eigen CSCA exploiteren, moeten de geldigheidstermijn voor hun CSCA en alle afgegeven certificaten vaststellen en zorgen voor de vernieuwing van certificaten.

Deel 4.2 bevat aanbevelingen voor geldigheidstermijnen.

3.3.   Integriteit en authenticiteit van geüploade data

Nationale backends kunnen de DCCG gebruiken om digitaal ondertekende datapakketten na succesvolle wederzijdse authenticatie te uploaden en te downloaden. In het begin bevatten deze datapakketten de DSC’s van de lidstaten. Het sleutelpaar dat door de nationale backend wordt gebruikt voor het digitaal ondertekenen van geüploade datapakketten in het DCCG-systeem, wordt het uploadsleutelpaar van de nationale backend genoemd en het bijbehorende publiekesleutelcertificaat wordt afgekort tot NBUP-certificaat. Elke lidstaat brengt zijn eigen NBUP-certificaat mee, dat zelf kan worden ondertekend of dat kan worden afgegeven door een bestaande certificeringsautoriteit, bijvoorbeeld een openbare certificeringsautoriteit (d.w.z. een certificeringsautoriteit die een certificaat afgeeft in overeenstemming met de basisvereisten van het CAB-Forum). Het NBUP-certificaat is verschillend van alle andere door de lidstaat gebruikte certificaten (d.w.z. CSCA, TLS-cliënt of DSC’s).

De lidstaten moeten het uploadcertificaat aan de DCCG-operator verstrekken tijdens de eerste registratieprocedure (zie deel 4.1voor meer informatie). Elke lidstaat is verantwoordelijk voor zijn nationale gegevens en voor de bescherming van de persoonlijke sleutel die wordt gebruikt voor het ondertekenen van de uploads.

Andere lidstaten kunnen de ondertekende datapakketten verifiëren met behulp van de door de DCCG verstrekte uploadcertificaten. De DCCG verifieert de authenticiteit en integriteit van de geüploade data aan de hand van het uploadcertificaat van de NB alvorens deze aan andere lidstaten te verstrekken.

3.4.   Eisen inzake de technische DCCG-architectuur

Dit zijn de eisen inzake de technische DCCG-architectuur:

—	De DCCG maakt gebruik van wederzijdse TLS-authenticatie om een geauthenticeerde versleutelde verbinding met de NB’s tot stand te brengen. De DCCG onderhoudt daarom een whitelist van geregistreerde NBTLS-cliëntcertificaten;

—	De DCCG gebruikt twee digitale certificaten (DCCGTLS en DCCGTA) met twee verschillende sleutelparen. De persoonlijke sleutel van het DCCGTA-sleutelpaar wordt offline bewaard (niet op de onlinecomponenten van de DCCG);

—	De DCCG onderhoudt een vertrouwenslijst van de NBCSCA-certificaten die is ondertekend met de persoonlijke sleutel van de DCCGTA;

—	De gebruikte cijfers moeten voldoen aan de eisen van deel 5.1.

4.   Beheer van de certificatenlevenscyclus

4.1.   Registratie van nationale backends

De lidstaten moeten zich registreren bij de DCCG-exploitant om aan het DCCG-systeem deel te nemen. In dit deel wordt de technische en operationele procedure beschreven die moet worden gevolgd om een nationale backend te registreren.

De DCCG-exploitant en de lidstaat moeten informatie uitwisselen over technische contactpersonen voor het onboardingproces. Aangenomen wordt dat de technische contactpersonen geautoriseerd worden door hun lidstaat en dat identificatie/authenticatie via andere kanalen plaatsvindt. De authenticatie kan bijvoorbeeld worden bereikt wanneer de technische contactpersoon van een lidstaat de certificaten als met een wachtwoord versleutelde bestanden via e-mail verstrekt en het bijbehorende wachtwoord telefonisch met de DCCG-operator deelt. Ook andere door de DCCG-exploitant gedefinieerde beveiligde kanalen mogen worden gebruikt.

De lidstaat moet drie digitale certificaten verstrekken tijdens het registratie- en identificatieproces:

—	Het TLS-certificaat NBTLS van de lidstaat

—	Het uploadcertificaat NBUP van de lidstaat

—	Het CSCA-certificaat/de CSCA-certificaten NBCSCA van de lidstaat

Alle verstrekte certificaten moeten voldoen aan de eisen van deel 5. De DCCG-exploitant controleert of het verstrekte certificaat voldoet aan de eisen van deel 5. Na de identificatie en registratie moet de DCCG-exploitant:

—	het NBCSCA-certificaat/de NBCSCA-certificaten toevoegen aan de vertrouwenslijst die is ondertekend met de persoonlijke sleutel die overeenstemt met de publieke sleutel van de DCCGTA;

—	het NBTLS-certificaat toevoegen aan de whitelist van het TLS-eindpunt van de DCCG;

—	het NBUP-certificaat toevoegen aan het DCCG-systeem;

—	de publiekesleutelcertificaten van de DCCGTA en DCCGTLS aan de lidstaat verstrekken.

4.2.   Certificeringsautoriteiten, geldigheidstermijnen en vernieuwing

Indien een lidstaat zijn eigen CSCA wil exploiteren, kunnen de CSCA-certificaten zelfondertekende certificaten zijn. Zij fungeren als vertrouwensanker van de lidstaat en daarom moet de lidstaat de persoonlijke sleutel die overeenkomt met de publieke sleutel van de CSCA degelijk beschermen. Het strekt tot aanbeveling dat de lidstaten voor hun CSCA een offlinesysteem gebruiken, d.w.z. een computersysteem dat op geen enkel netwerk is aangesloten. Voor de toegang tot het systeem moet gebruik worden gemaakt van meerpersoonscontrole (bijvoorbeeld volgens het twee-paar-ogenprincipe). Na het ondertekenen van DSC’s moeten operationele controles worden uitgevoerd en moet het systeem dat de persoonlijke sleutel van de CSCA bevat veilig worden opgeslagen met strenge toegangscontroles. Hardwarebeveiligingsmodules of smartcards kunnen worden gebruikt om de persoonlijke sleutel van de CSCA verder te beschermen. Digitale certificaten omvatten een geldigheidstermijn waardoor vernieuwing van de certificaten nodig is. Vernieuwing is noodzakelijk om nieuwe cryptografische sleutels te gebruiken en de omvang van de sleutels aan te passen wanneer nieuwe berekeningsmethoden of nieuwe aanvallen een bedreiging vormen voor de beveiliging van het gebruikte cryptografische algoritme. Het shell-model is van toepassing (zie deel 3.2).

De volgende geldigheidstermijnen worden aanbevolen, gezien de geldigheidsduur van één jaar voor digitale EU-covidcertificaten:

—	CSCA: 4 jaar

—	DSC: 2 jaar

—	Upload: 1-2 jaar

—	TLS-cliëntauthenticatie: 1-2 jaar

Voor een tijdige vernieuwing worden voor de persoonlijke sleutels de volgende gebruiksperioden aanbevolen:

—	CSCA: één jaar

—	DSC: zes maanden

Voor een vlotte werking moeten de lidstaten tijdig nieuwe uploadcertificaten en TLS-certificaten creëren, bijvoorbeeld één maand voor de vervaldatum. CSCA-certificaten en DSC’s moeten ten minste één maand voor het einde van het gebruik van de persoonlijke sleutel worden vernieuwd (rekening houdend met de noodzakelijke operationele procedures). De lidstaten moeten geactualiseerde CSCA-, upload- en TLS-certificaten verstrekken aan de DCCG-exploitant. Verlopen certificaten worden van de whitelist en de vertrouwenslijst verwijderd.

De lidstaten en de DCCG-exploitant moeten de geldigheid van hun eigen certificaten bijhouden. Er is geen centrale entiteit die de geldigheid van het certificaat bijhoudt en de deelnemers informeert.

4.3.   Intrekking van certificaten

In het algemeen kunnen digitale certificaten door de afgevende CA worden ingetrokken met behulp van certificaatintrekkingslijsten of een OCSP-responder (Online Certificate Status Protocol). CSCA’s voor het DCC-systeem moeten certificaatintrekkingslijsten (CRL’s) verstrekken. Ook als andere lidstaten deze CRL’s momenteel niet gebruiken, moeten zij voor toekomstige toepassingen worden geïntegreerd. Indien een CSCA beslist geen CRL’s te verstrekken, moeten de DSC’s van deze CSCA worden vernieuwd zodra CRL’s verplicht worden. Verificateurs dienen voor de validatie van de DSC’s niet OCSP, maar CRL’s te gebruiken. Het strekt tot aanbeveling dat de nationale backend de noodzakelijke validatie van uit de DCCG gedownloade DSC’s uitvoert, en alleen een reeks betrouwbare en gevalideerde DSC’s doorstuurt naar nationale DSC-validators. DCC-validators mogen in hun validatieproces geen intrekkingscontroles uitvoeren op DSC’s. Eén reden hiervoor is dat op die manier de privacy van DCC-houders wordt beschermd door elke kans te vermijden dat het gebruik van een bepaalde DSC kan worden gecontroleerd door de bijbehorende OCSP-responder.

De lidstaten kunnen hun DSC’s uit de DCCG verwijderen met behulp van hun eigen geldige upload- en TLS-certificaten. Het verwijderen van een DSC betekent dat alle DCC’s die met de DSC in kwestie zijn afgegeven, ongeldig worden wanneer de lidstaten de bijgewerkte DSC-lijsten ophalen. Het is cruciaal dat persoonlijkesleutelmaterialen die overeenkomen met DSC’s worden beschermd. De lidstaten moeten de DCCG-exploitant ervan in kennis stellen wanneer zij upload- of TLS-certificaten moeten intrekken, bijvoorbeeld omdat de nationale backend gecompromitteerd is. De DCCG-exploitant kan dan de vertrouwensrelatie voor het betrokken certificaat verwijderen, bijvoorbeeld door deze van de TLS-whitelist te schrappen. De DCCG-exploitant kan de uploadcertificaten uit de DCCG-databank verwijderen. Pakketten die zijn ondertekend met de persoonlijke sleutel die met dit uploadcertificaat overeenstemt, worden ongeldig wanneer nationale backends de vertrouwensrelatie van het ingetrokken uploadcertificaat verwijderen. Indien een CSCA-certificaat moet worden ingetrokken, stellen de lidstaten de DCCG-exploitant en andere lidstaten waarmee zij een vertrouwensrelatie hebben, hiervan in kennis. De DCCG-exploitant stelt dan een nieuwe vertrouwenslijst op waarin het betrokken certificaat niet meer is opgenomen. Alle door deze CSCA afgegeven DSC’s worden ongeldig wanneer de lidstaten hun nationale backendvertrouwensarchief updaten. Indien het DCCGTLS-certificaat of het DCCGTA-certificaat moet worden ingetrokken, moeten de DCCG-exploitant en de lidstaten samenwerken om een nieuwe vertrouwde TLS-verbinding en vertrouwenslijst tot stand te brengen.

5.   Certificaatmodellen

In dit deel worden de cryptografische eisen en richtsnoeren uiteengezet, alsmede de eisen inzake certificaatmodellen. Met betrekking tot de DCCG-certificaten worden in dit deel de certificaatmodellen gedefinieerd.

5.1.   Cryptografische eisen

Cryptografische algoritmen en TLS-coderingssuites worden gekozen op basis van de huidige aanbeveling van het Duitse federale bureau voor informatiebeveiliging (BSI) of SOG-IS. Deze aanbevelingen zijn vergelijkbaar met die van andere instellingen en normalisatie-organisaties. De aanbevelingen staan in de technische richtsnoeren TR 02102-1 en TR 02102-2 (1) of SOG-IS Agreed Cryptographic Mechanisms (2).

5.1.1.   Eisen inzake de DSC

De eisen van bijlage I, deel 3.2.2, zijn van toepassing. Daarom wordt ten zeerste aanbevolen dat documentondertekenaars gebruikmaken van het elliptische krommealgoritme voor digitale handtekening (ECDSA) met NIST-p-256 (zoals gedefinieerd in aanhangsel D bij FIPS PUB 186-4). Andere elliptische krommen worden niet ondersteund. Vanwege de beperkte ruimte van de DCC mogen de lidstaten geen RSA-PSS gebruiken, zelfs niet als reservealgoritme. Indien lidstaten RSA-PSS gebruiken, moeten zij een modulusgrootte van 2048 of maximaal 3072 bit gebruiken. SHA-2 met een outputlengte van ≥ 256 bits wordt gebruikt als cryptografische hashfunctie (zie ISO/IEC 10118-3:2004) voor de DSC-handtekening.

5.1.2.   Eisen inzake TLS-, upload- en CSCA-certificaten

Voor digitale certificaten en cryptografische handtekeningen in de context van DCCG zijn de belangrijkste eisen inzake cryptografische algoritmen en sleutellengte samengevat in de volgende tabel (vanaf 2021):

Algoritme van de handtekening	Grootte van de sleutel	Hashfunctie
EC-DSA	Min. 250 bit	SHA-2 met een outputlengte ≥ 256 bit
RSA-PSS (aanbevolen opvulling) RSA-PKCS#1 v1.5 (oude opvulling)	Min. 3000 bit RSA Modulus (N) met een publieke exponent e > 2^16	SHA-2 met een outputlengte ≥ 256 bit
DSA	Min. 3000 bit prime p, 250 bit sleutel q	SHA-2 met een outputlengte ≥ 256 bit

De aanbevolen elliptische kromme voor EC-DSA is NIST-p-256 vanwege de wijdverbreide toepassing ervan.

5.2.   CSCA-certificaat (NBCSCA)

De volgende tabel bevat richtsnoeren voor het model van het NBCSCA-certificaat voor het geval dat een lidstaat besluit zijn eigen CSCA voor het DCC-systeem te exploiteren.

Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

Veld	Waarde
Subject	cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat die de CSCA exploiteert>
Key usage	certificate signing, CRL signing (minimaal)
Basic Constraints	CA = true, path length constraints = 0

Het subject-veld mag niet leeg zijn en moet uniek zijn binnen de gespecificeerde lidstaat. De landcode (c) moet overeenkomen met de lidstaat die dit CSCA-certificaat zal gebruiken. Het certificaat moet een unieke subject key identifier (SKI) bevatten overeenkomstig RFC 5280 (3).

5.3.   Document Signer Certificate (DSC)

De volgende tabel bevat richtsnoeren voor het DSC. Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

Veld	Waarde
Serial Number	uniek serienummer
Subject	cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat die de DSC gebruikt>
Key Usage	digital signature (minimaal)

De DSC moet worden ondertekend met de persoonlijke sleutel die overeenstemt met een CSCA-certificaat dat door de lidstaat wordt gebruikt.

De volgende extensies moeten worden gebruikt:

—	Het certificaat moet een Authority Key Identifier (AKI) bevatten die overeenstemt met de Subject Key Identifier (SKI) van het certificaat dat de CSCA afgeeft.

—	Het certificaat moet een unieke subject key identifier bevatten (overeenkomstig RFC 5280 (4)).

Bovendien moet het certificaat de extensie voor CRL-distributiepunten bevatten die verwijst naar de certificaatintrekkingslijst (CRL) die wordt verstrekt door de CSCA die de DSC heeft afgegeven.

De DSC kan een extensie voor uitgebreide-sleutelgebruik met nul of meer identificatiecodes voor sleutelgebruiksbeleid bevatten die de soorten HCERT’s die dit certificaat mag verifiëren, beperken. Indien een of meer verificateurs aanwezig zijn, verifiëren zij het sleutelgebruik aan de hand van het opgeslagen HCERT. Hiervoor zijn de volgende extendedKeyUsage-waarden gedefinieerd:

Veld	Waarde
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.1 voor afgevers van testcertificaten
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.2 voor afgevers van vaccinatiecertificaten
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.3 voor afgevers van herstelcertificaten

Bij ontbreken van een extensie voor uitgebreide-sleutelgebruik (d.w.z. geen uitbreidingen of nuluitbreidingen), kan dit certificaat worden gebruikt om elk type HCERT te valideren. In andere documenten kunnen relevante aanvullende beleidsidentificatiecodes voor uitgebreide-sleutelgebruik worden gedefinieerd die worden gebruikt bij de validatie van HCERT’s.

5.4.   Uploadcertificaten (NBUP)

De volgende tabel bevat richtsnoeren voor het uploadcertificaat van nationale backends. Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

Veld	Waarde
Subject	cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat die dit uploadcertificaat gebruikt>
Key Usage	digital signature (minimaal)

5.5.   TLS-cliëntauthenticatiecertificaat van nationale backends (NBTLS)

De volgende tabel bevat richtsnoeren voor het TLS-cliëntauthenticatiecertificaat van nationale backends. Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

Veld	Waarde
Subject	cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat aan de NB>
Key Usage	digital signature (minimaal)
Extended key usage	cliëntauthenticatie (1.3.6.1.5.5.7.3.2)

Het certificaat kan ook het uitgebreide-sleutelgebruik server authentication (1.3.6.1.5.5.7.3.1) bevatten, maar dit is niet vereist.

5.6.   Handtekeningcertificaat voor vertrouwenslijst (DCCGTA)

In de volgende tabel wordt het DCCG-vertrouwensankercertificaat gedefinieerd.

Veld	Waarde
Subject	cn = Digital Green Certificate Gateway  (5) , o=<Provider>, c=<land>
Key Usage	digital signature (minimaal)

5.7.   DCCG-TLS-servercertificaten (DCCGTLS)

In de volgende tabel wordt het DCCG-TLS-certificaat gedefinieerd.

Veld	Waarde
Subject	cn=<FQDN of IP-adres van de DCCG>, o=<Provider>, c= <land>
SubjectAltName	dNSName: <naam DCCG DNS> of iPAddress: <IP-adres DCCG>
Key Usage	digital signature (minimaal)
Extended key usage	server authentication (1.3.6.1.5.5.7.3.1)

Het certificaat kan ook het uitgebreide-sleutelgebruik client authentication (1.3.6.1.5.5.7.3.2) bevatten, maar dit is niet vereist.

Het TLS-certificaat van de DCCG wordt afgegeven door een algemeen betrouwbare certificeringsautoriteit (opgenomen in alle belangrijke browsers en besturingssystemen, volgens de basisvereisten van het CAB-forum).

---

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

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

(3)  rfc5280 (ietf.org)

(4)  rfc5280 (ietf.org)

(5)  De terminologie van “Digital Green Certificate” in plaats van “EU Digital COVID Certificate” is in dit verband gehandhaafd omdat dit de terminologie is die in de broncode is opgenomen en in het certificaat is gebruikt voordat de medewetgevers nieuwe terminologie hebben vastgesteld.