Articolo 1

L’articolo 58 del regolamento (UE) 2016/1628 è così modificato:

1)

al paragrafo 5 è aggiunto il comma seguente: «Per i motori di tutte le sottocategorie per i quali la data di cui all’allegato III per l’immissione sul mercato dei motori della fase V è il 1o gennaio 2020, a eccezione dei motori di cui al secondo comma e al terzo comma, il periodo di transizione è prorogato di nove mesi e il periodo di 18 mesi di cui al primo comma è prorogato di sei mesi.»;

2)	al paragrafo 7 è aggiunta la lettera seguente: «e) 33 mesi a decorrere dalla data applicabile all’immissione sul mercato dei motori di cui all’allegato III, nel caso di cui al paragrafo 5, sesto comma.».

Articolo 2

Il presente regolamento entra in vigore il giorno della pubblicazione nella Gazzetta ufficiale dell’Unione europea.

Articolo 1

Modifica del regolamento (UE) 2020/1579

Il regolamento (UE) 2020/1579 è modificato come indicato nella parte A dell’allegato del presente regolamento.

Articolo 2

Modifica del regolamento (UE) 2021/92

Il regolamento (UE) 2021/92 è modificato come indicato nelle parti B e C dell’allegato del presente regolamento.

Articolo 3

Entrata in vigore e applicazione

Il presente regolamento entra in vigore il giorno successivo alla pubblicazione nella Gazzetta ufficiale dell’Unione europea.

L’articolo 1 si applica a decorrere dal 1o gennaio 2021.

L’articolo 2 si applica a decorrere dal 1o luglio 2021.

ALLEGATO

PARTE A

Nell’allegato del regolamento (UE) 2020/1579, la tabella sulle possibilità di pesca relative all’aringa nelle sottodivisioni CIEM 30-31 è sostituita dalla seguente:

PARTE B

L’allegato IA del regolamento (UE) 2021/92 è così modificato:

1)

la tabella sulle possibilità di pesca relative allo spratto e alle catture accessorie connesse nelle acque dell’Unione della divisione CIEM 3a è sostituita dalla seguente: «Specie: Spratto e catture accessorie connesse Sprattus sprattus Zona: 3a (SPR/03 A.) Danimarca 13 086  (1)  (2) TAC analitico Germania 27  (1)  (2) Svezia 4 951  (1)  (2) Unione 18 064  (1)  (2)   TAC 19 529  (2)

2)

la tabella sulle possibilità di pesca relative allo spratto e alle catture accessorie connesse nelle acque del Regno Unito e nelle acque dell’Unione della sottozona CIEM 4 e nelle acque del Regno Unito della divisione CIEM 2a è sostituita dalla seguente: «Specie: Spratto e catture accessorie connesse Sprattus sprattus Zona: Acque del Regno Unito e acque dell’Unione della zona 4; acque del Regno Unito della zona 2a (SPR/2AC4-C) Belgio 993  (3)  (4) TAC analitico Danimarca 78 553  (3)  (4) Germania 993  (3)  (4) Francia 993  (3)  (4) Paesi Bassi 993  (3)  (4) Svezia 1 330  (3)  (4)  (5) Unione 83 855  (3)  (4) Norvegia 0  (3) Isole Fær Øer 0  (3)  (6) Regno Unito 3 331  (3)   TAC 87 186  (3)

3)

la tabella sulle possibilità di pesca relative all’acciuga nelle sottozone CIEM 9 e 10 e nelle acque dell’Unione della divisione Copace 34.1.1 è sostituita dalla seguente: «Specie: Acciuga Engraulis encrasicolus Zona: 9 e 10; acque dell’Unione della zona Copace 34.1.1 (ANE/9/3411) Spagna 2 747  (7) TAC precauzionale Portogallo 2 997  (7) Unione 5 744  (7)   TAC 5 744  (7)

PARTE C

Nell’allegato VI del regolamento (UE) 2021/92 il punto 6 è sostituito dal seguente:

«6.

Capacità massima di allevamento e di ingrasso del tonno rosso per ciascuno Stato membro e quantitativo massimo di catture di tonno rosso selvatico che ciascuno Stato membro può assegnare ai propri allevamenti nell’Atlantico orientale e nel Mediterraneo. Tabella A Capacità massima di allevamento e di ingrasso del tonno rosso   Numero di allevamenti Capacità (in tonnellate) Spagna 10 11 852 Italia 13 9 564 Grecia 2 2 100 Cipro 3 3 000 Croazia 7 7 880 Malta 6 14 511 Tabella B  (8) Quantitativo massimo di catture di tonno rosso selvatico (in tonnellate) Spagna 6 850 Italia 1 739,5 Grecia 785 Cipro 2 195 Croazia 2 947 Malta 10 260,5 Portogallo 350

---

(1)  Fino al 5 % del contingente può essere costituito da catture accessorie di merlano ed eglefino (OTH/*03 A.). Le catture accessorie di merlano ed eglefino imputate al contingente ai sensi della presente disposizione e le catture accessorie di specie imputate al contingente a norma dell’articolo 15, paragrafo 8, del regolamento (UE) n. 1380/2013 non superano complessivamente il 9 % del contingente.

(2)  Questo contingente può essere pescato soltanto dal 1o luglio 2021 al 30 giugno 2022. Possono essere effettuati trasferimenti di questo contingente verso le acque del Regno Unito e dell’Unione delle zone 2a e 4. Tuttavia, tali trasferimenti sono preventivamente comunicati alla Commissione e al Regno Unito.»;

(3)  Il contingente può essere pescato soltanto dal 1o luglio 2021 al 30 giugno 2022.

(4)  Fino al 2 % del contingente può essere costituito da catture accessorie di merlano (OTH/*2AC4C). Le catture accessorie di merlano imputate al contingente ai sensi della presente disposizione e le catture accessorie di specie imputate al contingente a norma dell’articolo 15, paragrafo 8, del regolamento (UE) n. 1380/2013 non superano complessivamente il 9 % del contingente.

(5)  Incluso il cicerello.

(6)  Può contenere fino al 4 % di catture accessorie di aringa.»;

(7)  Il contingente può essere pescato soltanto dal 1o luglio 2021 al 30 settembre 2021.».

(8)  La capacità di allevamento del Portogallo di 500 tonnellate è coperta dalla capacità inutilizzata dell’Unione di cui alla tabella A.».

Articolo 1

Oggetto e ambito di applicazione

Il presente regolamento stabilisce misure speciali di controllo delle malattie relative all'infezione da virus della dermatite nodulare contagiosa (LSDV) da applicarsi per un periodo di tempo limitato da parte degli Stati membri nelle aree del proprio territorio in cui:

a)	sia stato confermato un focolaio di tale malattia;

b)	non sia stato confermato un focolaio di tale malattia, ma lo Stato interessato decida di eseguire la vaccinazione contro tale malattia ai sensi delle norme di cui al presente regolamento.

Le misure speciali di controllo delle malattie di cui al presente regolamento si applicano ai bovini, ai sottoprodotti e al materiale germinale ottenuti da tali bovini; esse si aggiungono alle misure di controllo delle malattie applicabili alle zone di protezione, alle zone di sorveglianza e alle ulteriori zone soggette a restrizioni Istituite dall'autorità competente di uno Stato membro in seguito alla presenza di un focolaio di infezione da LSDV, conformemente all'articolo 21, paragrafo 1, del regolamento delegato (UE) 2020/687.

Articolo 2

Definizioni

Ai fini del presente regolamento si applicano le definizioni di cui al regolamento delegato (UE) 2020/687.

Si applicano inoltre le definizioni seguenti:

1)	«bovino», un animale di una delle specie di ungulati appartenenti ai generi Bison, Bos (compresi i sottogeneri Bos, Bibos, Novibos e Poephagus) e Bubalus (compreso il sottogenere Anoa) nonché un animale derivato dall'incrocio di tali specie;

2)

«zona soggetta a restrizioni I», una parte del territorio di uno Stato membro con una delimitazione geografica precisa: a) situata all'esterno di un'area in cui sia stato confermato un focolaio di infezione da LSDV; b) in cui la vaccinazione contro l'infezione da LSDV sia eseguita in conformità dell'articolo 3, paragrafo 2; c) elencata o non elencata nella parte I dell'allegato I; d) soggetta alle norme speciali di controllo delle malattie di cui agli articoli da 3 a 6.

3)

«zona soggetta a restrizioni II», una parte del territorio di uno Stato membro con una delimitazione geografica precisa: a) comprendente un'area in cui sia stato confermato un focolaio di infezione da LSDV; b) in cui la vaccinazione contro l'infezione da LSDV sia eseguita in conformità dell'articolo 3, paragrafo 1; c) elencata o non elencata nella parte II dell'allegato I; d) soggetta alle norme speciali di controllo delle malattie di cui agli articoli da 3 a 6.

Articolo 3

Istituzione di zone soggette a restrizioni I e II

Articolo 4

Divieti di movimenti nelle zone soggette a restrizioni I e II

Articolo 5

Inclusione della zona soggetta a restrizioni II nell'allegato I, parte II

Qualora, per ragioni epidemiologiche, un'area di uno Stato membro compresa in tutto o in parte in una zona soggetta a restrizioni II, istituita ai sensi dell'articolo 3, paragrafo 1, venga inclusa nell'allegato I, parte II, immediatamente l'autorità competente:

a)	modifica i confini della zona soggetta a restrizioni II iniziale per garantire che essa corrisponda alla zona soggetta a restrizioni II descritta in tale allegato;

b)	estende la vaccinazione di cui all'articolo 3, paragrafo 1, lettera b), e i divieti di cui all'articolo 4, paragrafo 1, alla zona soggetta a restrizioni II descritta in tale allegato.

Articolo 6

Inclusione della zona soggetta a restrizioni I nell'allegato I, parte I

Articolo 7

Deroghe al divieto di movimenti di partite di bovini da una zona soggetta a restrizioni I

In deroga al divieto di cui all'articolo 4, paragrafo 2, lettera a), l'autorità competente può autorizzare i movimenti di partite di bovini da stabilimenti situati in una zona soggetta a restrizioni I verso:

a)

una zona soggetta a restrizioni I o II dello stesso Stato membro o di un altro Stato membro, purché siano soddisfatte tutte le seguenti condizioni: i) i bovini compresi nella partita devono essere stati vaccinati contro l'infezione da LSDV almeno 28 giorni prima della data di spedizione e trovarsi ancora, a tale data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino; ii) tutti gli altri bovini detenuti nello stesso stabilimento di origine dei bovini compresi nella partita devono essere stati vaccinati contro l'infezione da LSDV almeno 28 giorni prima della data di spedizione e trovarsi ancora, a tale data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino, oppure trovarsi ancora, alla data di spedizione, nel periodo di immunità indotto dalla vaccinazione precedente o dall'immunità materna; iii) i bovini compresi nella partita devono essere detenuti nel proprio stabilimento di origine sin dalla nascita oppure per un periodo ininterrotto di almeno 28 giorni prima della data di spedizione; e iv) l'autorità competente effettua: — un esame clinico, con esito favorevole, di tutti i bovini detenuti nello stabilimento di origine di tali partite, compresi i bovini facenti parte di tali partite; — se necessario, un esame di laboratorio, con esito favorevole, dei bovini detenuti nello stabilimento di origine di tali partite, compresi i bovini facenti parte di tali partite;

b)

qualsiasi luogo di destinazione, comprese le aree al di fuori delle zone soggette a restrizioni, altre zone soggette a restrizioni I o zone soggette a restrizioni II, nello stesso Stato membro o in altri Stati membri qualora, oltre alle condizioni di cui alla lettera a), punti ii), iii) e iv) del presente articolo, siano soddisfatte tutte le seguenti condizioni: i) i bovini compresi nella partita devono essere stati vaccinati contro l'infezione da LSDV almeno 60 giorni prima della data di spedizione e trovarsi ancora, a tale data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino; ii) in un raggio di almeno 20 km intorno allo stabilimento di origine di tali partite, non si sono registrati focolai di infezione da LSDV per un periodo di almeno tre mesi prima della data di spedizione; e iii) tutti i bovini detenuti in un raggio di 50 km intorno allo stabilimento di origine della partita devono essere stati vaccinati o rivaccinati contro l'infezione da LSDV almeno 60 giorni prima della data di spedizione e trovarsi ancora, a tale data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino o essere protetti dall'immunità materna;

c)

qualsiasi luogo di destinazione, comprese le aree al di fuori delle zone soggette a restrizioni, altre zone soggette a restrizioni I o zone soggette a restrizioni II, in altri Stati membri o territori di paesi terzi qualora, oltre alle condizioni di cui alla lettera a) del presente articolo, siano soddisfatte tutte le seguenti condizioni: i) gli animali devono soddisfare eventuali garanzie in materia di salute animale in base all'esito favorevole di una valutazione dei rischi relativa alle misure contro la diffusione dell'infezione da LSDV richieste dall'autorità competente dello Stato membro di origine e approvate dall'autorità competente degli Stati membri di destinazione e passaggio prima della data di spedizione; ii) non devono essere stati confermati focolai di infezione da LSDV entro un raggio di almeno 20 km intorno allo stabilimento di origine di tali partite per un periodo di almeno tre mesi prima della data di spedizione; e iii) tutti i bovini detenuti nel raggio di 50 km intorno allo stabilimento di origine della partita devono essere stati vaccinati o rivaccinati contro l'infezione da LSDV almeno 60 giorni prima della data di spedizione e trovarsi ancora, a tale data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino o essere protetti dall'immunità materna.

Articolo 8

Deroghe al divieto di movimenti di partite di bovini da una zona soggetta a restrizioni II

In deroga al divieto di cui all'articolo 4, paragrafo 1, lettera a), l'autorità competente può autorizzare i movimenti di partite di bovini da stabilimenti situati in una zona soggetta a restrizioni II verso:

a)

qualsiasi luogo di destinazione, comprese le aree al di fuori delle zone soggette a restrizioni, zone soggette a restrizioni I, altre zone soggette a restrizioni II, nello stesso Stato membro e in altri Stati membri, purché siano soddisfatte tutte le seguenti condizioni: i) i bovini compresi nella partita devono soddisfare eventuali garanzie in materia di salute animale in base all'esito favorevole di una valutazione dei rischi relativa alle misure contro la diffusione dell'infezione da LSDV richieste dall'autorità competente dello Stato membro del luogo di origine e concordate con l'autorità competente degli Stati membri di destinazione o passaggio prima della data di spedizione; ii) i bovini compresi nella partita devono essere stati vaccinati contro l'infezione da LSDV almeno 28 giorni prima della data di spedizione e trovarsi ancora, a tale data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino; iii) tutti gli altri bovini detenuti nello stesso stabilimento di origine dei bovini compresi nella partita devono essere stati vaccinati contro l'infezione da LSDV almeno 28 giorni prima della data di spedizione e trovarsi ancora, a tale data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino, oppure trovarsi ancora, a tale data, nel periodo di immunità indotto dalla vaccinazione precedente o dall'immunità materna; iv) l'autorità competente effettua: — un esame clinico, con esito favorevole, di tutti i bovini detenuti nello stabilimento di origine di tali partite, compresi i bovini facenti parte di tali partite; — se necessario, un esame di laboratorio, con esito favorevole, dei bovini detenuti nello stabilimento di origine di tali partite, compresi i bovini facenti parte di tali partite; v) i bovini devono essere rimasti sin dalla nascita, o per un periodo di almeno 28 giorni prima della data di spedizione, in uno stabilimento in cui, in un raggio di almeno 20 km, non sia stato confermato nessun focolaio di infezione da LSDV nei tre mesi precedenti la data di spedizione; vi) tutti i bovini in un raggio di 50 km intorno allo stabilimento di origine della partita devono essere stati vaccinati o rivaccinati contro l'infezione da LSDV, conformemente alle norme per i piani di vaccinazione di cui all'allegato II, almeno 60 giorni prima della data di spedizione e trovarsi ancora nel periodo di immunità conformemente alle istruzioni del produttore del vaccino o essere protetti dall'immunità materna;

b)

qualsiasi luogo di destinazione situato in un'altra zona soggetta a restrizioni II dello stesso Stato membro purché siano soddisfatte tutte le seguenti condizioni: i) tutti gli altri bovini detenuti nello stabilimento di origine di tali partite devono essere stati vaccinati contro l'infezione da LSDV almeno 28 giorni prima della data di spedizione e a tale data devono trovarsi ancora nel periodo di immunità conformemente alle istruzioni del produttore del vaccino o nel periodo di immunità indotto dalla vaccinazione precedente o dall'immunità materna; e ii) i bovini devono essere stati vaccinati contro l'infezione da LSDV almeno 28 giorni prima della data di spedizione e trovarsi ancora, a quella data, nel periodo di immunità conformemente alle istruzioni del produttore del vaccino, a meno che non si tratti di animali non vaccinati di età inferiore a quattro mesi, nati da femmine vaccinate almeno 28 giorni prima del parto, che erano ancora nel periodo di immunità indicato dal produttore del vaccino alla data del parto, e possono essere spostati in un altro stabilimento.

Articolo 9

Condizioni specifiche per autorizzare i movimenti di partite di bovini provenienti da zone soggette a restrizioni I e II verso un macello al di fuori di tali zone, situato nel territorio dello stesso Stato membro, ai fini della macellazione immediata

In deroga ai divieti di cui all'articolo 4, paragrafo 1, lettera a), e paragrafo 2, lettera a), del presente regolamento, l'autorità competente dello Stato membro può autorizzare movimenti di partite di bovini da zone soggette a restrizioni I e II verso un macello al di fuori di tali zone, situato nel territorio dello stesso Stato membro, purché i bovini siano spostati ai fini della macellazione immediata conformemente alle condizioni generali di cui all'articolo 28, paragrafi da 2 a 5, e paragrafo 7, del regolamento delegato (UE) 2020/687.

Articolo 10

Deroghe ai divieti di movimenti di partite di sperma, ovuli ed embrioni di bovini dalle zone soggette a restrizioni I e II

Articolo 11

Deroga al divieto di movimenti di partite di sottoprodotti di origine animale non trasformati ottenuti da bovini provenienti da zone soggette a restrizioni I

In deroga al divieto di cui all'articolo 4, paragrafo 2, lettera c), l'autorità competente di uno Stato membro può autorizzare i movimenti di partite di sottoprodotti di origine animale non trasformati ottenuti da bovini provenienti da stabilimenti situati in una zona soggetta a restrizioni I verso:

a)	qualsiasi luogo di destinazione situato nello stesso Stato membro o verso qualsiasi luogo di destinazione situato nelle zone soggette a restrizioni I o II in un altro Stato membro;

b)

nel caso di partite di pelli, qualsiasi luogo di destinazione situato in qualsiasi area dello stesso Stato membro, o di un altro Stato membro o di un paese terzo, purché sia soddisfatta una delle seguenti condizioni: i) le pelli trattate siano state sottoposte a uno dei trattamenti di cui all'allegato I, punto 28, lettere da b) a e), del regolamento (UE) n. 142/2011 della Commissione (10); oppure ii) le pelli trattate siano state sottoposte a uno dei trattamenti di cui all'allegato III, sezione XIV, capitolo I, punto 4, lettera b), punto II), del regolamento (CE) n. 853/2004 del Parlamento europeo e del Consiglio (11), e siano state trattate con tutte le precauzioni atte ad evitare la ricontaminazione da parte di agenti patogeni dopo il trattamento.

Articolo 12

Deroga al divieto di movimenti di partite di sottoprodotti di origine animale non trasformati ottenuti da bovini provenienti da zone soggette a restrizioni II

In deroga al divieto di cui all'articolo 4, paragrafo 1, lettera c), l'autorità competente di uno Stato membro può autorizzare i movimenti di partite di sottoprodotti di origine animale non trasformati ottenuti da bovini provenienti dagli stabilimenti situati in una zona soggetta a restrizioni II verso:

a)

nel caso di sottoprodotti di origine animale non trasformati diversi da pelli, qualsiasi luogo di destinazione situato nello stesso Stato membro oppure qualsiasi luogo di destinazione situato in zone soggette a restrizioni I o II di un altro Stato membro, purché i sottoprodotti di origine animale non trasformati siano spediti sotto la supervisione ufficiale delle autorità competenti per la trasformazione o lo smaltimento in un impianto riconosciuto in conformità dell'articolo 24 del regolamento (CE) n. 1069/2009 del Parlamento europeo e del Consiglio (12);

b)

nel caso di pelli di bovini: i) qualsiasi luogo di destinazione situato in una zona soggetta a restrizioni II dello stesso Stato membro oppure di un altro Stato membro purché si tratti di pelli gregge non trattate destinate al consumo umano o di pelli non trattate spedite sotto la supervisione ufficiale delle autorità competenti per la trasformazione o lo smaltimento in un impianto riconosciuto; ii) qualsiasi luogo di destinazione situato nello stesso Stato membro o in un altro Stato membro purché siano soddisfatte le condizioni di cui all'articolo 11, lettera b);

c)

nel caso di colostro, latte e prodotti lattiero-caseari, qualsiasi luogo di destinazione situato in qualsiasi area dello stesso Stato membro o di un altro Stato membro, purché siano stati sottoposti a un trattamento di riduzione dei rischi per l'infezione da LSDV, di cui all'allegato VII del regolamento delegato (UE) 2020/687.

Articolo 13

Obblighi degli operatori per quanto riguarda i certificati sanitari per i movimenti di partite di bovini dalle zone soggette a restrizioni I e II verso aree al di fuori di tali zone

Gli operatori spostano partite di bovini dalle zone soggette a restrizioni I e II verso aree al di fuori di tali zone all'interno dello stesso Stato membro o in un altro Stato membro nei casi contemplati agli articoli 7, 8 e 9 del presente regolamento unicamente se gli animali da spostare sono accompagnati da un certificato sanitario di cui all'articolo 73 del regolamento delegato (UE) 2020/688 della Commissione (13) che contiene almeno uno dei seguenti attestati di conformità alle prescrizioni di cui al presente regolamento:

a)	«Bovini provenienti da una zona soggetta a restrizioni I in conformità delle misure speciali di controllo relative all'infezione da LSDV di cui all'articolo 7 del regolamento di esecuzione (UE) 2021/1070 della Commissione.».

b)	«Bovini provenienti da una zona soggetta a restrizioni II in conformità delle misure speciali di controllo relative all'infezione da LSDV di cui all'articolo 8 del regolamento di esecuzione (UE) 2021/1070 della Commissione.».

c)	«Bovini provenienti da una zona soggetta a restrizioni I o II in conformità delle misure speciali di controllo relative all'infezione da LSDV di cui all'articolo 9 del regolamento di esecuzione (UE) 2021/1070 della Commissione.».

In caso di movimenti di partite di cui al primo comma del presente articolo all'interno dello stesso Stato membro, l'autorità competente può tuttavia decidere che non deve essere rilasciato un certificato sanitario di cui all'articolo 143, paragrafo 2, secondo comma, del regolamento (UE) 2016/429.

Articolo 14

Obblighi degli operatori per quanto riguarda i certificati sanitari per i movimenti di partite di materiale germinale ottenuto da bovini provenienti da stabilimenti situati nelle zone soggette a restrizioni I e II verso aree al di fuori di tali zone

Gli operatori spostano partite di materiale germinale, ottenuto da bovini, dalle zone soggette a restrizioni I e II verso aree al di fuori di tali zone all'interno dello stesso Stato membro o in un altro Stato membro in conformità dell'articolo 10 del presente regolamento, unicamente se tali partite sono accompagnate da un certificato sanitario di cui all'articolo 161, paragrafo 4, del regolamento (UE) 2016/429 che contiene almeno uno dei seguenti attestati di conformità alle prescrizioni di cui al presente regolamento:

a)

«Materiale germinale … (sperma, ovuli e/o embrioni, indicare la dicitura appropriata) ottenuto da bovini detenuti in una zona soggetta a restrizioni I in conformità delle misure speciali di controllo relative all'infezione da LSDV di cui all'articolo 10 del regolamento di esecuzione (UE) 2021/1070.».

b)

«Materiale germinale … (sperma, ovuli e/o embrioni, indicare la dicitura appropriata) ottenuto da bovini detenuti in una zona soggetta a restrizioni II in conformità delle misure speciali di controllo relative all'infezione da LSDV di cui all'articolo 10 del regolamento di esecuzione (UE) 2021/1070.».

In caso di movimenti di partite di cui al primo comma del presente articolo all'interno dello stesso Stato membro, l'autorità competente può tuttavia decidere che non deve essere rilasciato un certificato sanitario di cui all'articolo 161, paragrafo 2, secondo comma, del regolamento (UE) 2016/429.

Articolo 15

Obblighi degli operatori per quanto riguarda i certificati sanitari per i movimenti di partite di sottoprodotti di origine animale non trasformati ottenuti da bovini provenienti dalle zone soggette a restrizioni I e II verso aree al di fuori di tali zone

Gli operatori spostano partite di sottoprodotti di origine animale non trasformati ottenuti da bovini provenienti dalle zone soggette a restrizioni I e II verso aree al di fuori di tali zone all'interno dello stesso Stato membro o in un altro Stato membro nei casi contemplati all'articolo 12 unicamente se tali partite sono accompagnate da:

a)	un documento commerciale di cui all'allegato VIII, capo III, del regolamento (UE) n. 142/2011; e

b)	un certificato sanitario di cui all'articolo 22, paragrafo 5, del regolamento delegato (UE) 2020/687.

In caso di movimenti di partite di cui al primo comma del presente articolo all'interno dello stesso Stato membro, l'autorità competente può tuttavia decidere che non sia rilasciato un certificato sanitario di cui all'articolo 22, paragrafo 6, del regolamento delegato (UE) 2020/687.

Articolo 16

Condizioni generali supplementari relative ai mezzi di trasporto utilizzati per i movimenti di partite di bovini e sottoprodotti di origine animale non trasformati dalle zone soggette a restrizioni I e II verso aree al di fuori di tali zone

L'autorità competente dello Stato membro autorizza i movimenti di partite di bovini e di sottoprodotti di origine animale non trasformati dalle zone soggette a restrizioni I e II verso aree al di fuori di tali zone unicamente se i mezzi di trasporto utilizzati per i movimenti di tali partite:

a)

nel caso di trasporto di bovini, i mezzi di trasporto: i) soddisfano le prescrizioni di cui all'articolo 24, paragrafo 1, del regolamento delegato (UE) 2020/687; e ii) sono puliti e disinfettati conformemente all'articolo 24, paragrafo 2, del regolamento delegato (UE) 2020/687 sotto il controllo o sotto la supervisione dell'autorità competente dello Stato membro;

b)	comprendono soltanto animali o sottoprodotti di origine animale non trasformati o pelli non trattate aventi lo stesso status sanitario.

Articolo 17

Obblighi dell'autorità competente dello stabilimento di origine in materia di procedure di incanalamento

Articolo 18

Obblighi dell'autorità competente del luogo di destinazione in materia di procedure di incanalamento

L'autorità competente del luogo di destinazione in seguito a una procedura di incanalamento:

a)	conferma ciascun arrivo all'autorità competente del luogo di origine;

b)	provvede affinché i bovini restino nello stabilimento di destinazione almeno per la durata del periodo di monitoraggio dell'infezione da LSDV di cui all'allegato II del regolamento delegato (UE) 2020/687, tranne qualora lo stabilimento di destinazione sia un macello;

c)

provvede affinché dopo lo scarico dei bovini o dei sottoprodotti di origine animale non trasformati il mezzo di trasporto e qualsiasi altra attrezzatura utilizzata per il trasporto dei bovini o dei sottoprodotti di origine animale non trasformati siano completamente puliti, disinfettati e trattati con insetticidi autorizzati efficaci contro i vettori noti dell'infezione da LSDV all'interno di un'area chiusa del luogo di destinazione sotto la supervisione del veterinario ufficiale.

Articolo 19

Obblighi dello Stato membro del luogo di origine delle partite di bovini, del materiale germinale o dei sottoprodotti di origine animale non trasformati, per quanto riguarda le informazioni da comunicare alla Commissione e agli Stati membri per le deroghe concesse in base alle valutazioni dei rischi

Qualora l'autorità competente autorizzi movimenti di partite di bovini o materiale germinale sulla base dell'esito favorevole di una valutazione dei rischi delle misure contro la diffusione dell'infezione da LSDV di cui agli articoli 7, 8 o 10, lo Stato membro del luogo di origine informa immediatamente la Commissione e gli altri Stati membri in merito alle garanzie in materia di sanità animale e all'approvazione da parte delle autorità competenti del luogo dello stabilimento di destinazione.

Articolo 20

Entrata in vigore e data di applicazione

Il presente regolamento entra in vigore il giorno successivo alla pubblicazione nella Gazzetta ufficiale dell'Unione europea.

Esso si applica fino al 21 aprile 2023.

ALLEGATO I

ZONE SOGGETTE A RESTRIZIONI I e II

(di cui all'articolo 3)

PARTE I

Zona soggetta a restrizioni I

1.   Bulgaria:

L'intero territorio della Bulgaria

2.   Grecia:

A.

Le regioni seguenti della Grecia: — regione dell'Attica — regione della Grecia centrale — regione della Macedonia centrale — regione di Creta — regione della Macedonia orientale e Tracia — regione dell'Epiro — regione delle isole ioniche, esclusa l'unità regionale di Kerkyra — regione dell'Egeo settentrionale, esclusa l'unità regionale di Limnos — regione del Peloponneso — regione dell'Egeo meridionale — regione della Tessaglia — regione della Grecia occidentale — regione della Macedonia occidentale

B.	Le seguenti unità regionali della Grecia: — unità regionale di Limnos — unità regionale di Kerkyra

PARTE II

Zona soggetta a restrizioni II

Nessuna

ALLEGATO II

NORME PER I PIANI DI VACCINAZIONE RIGUARDANTI L'INFEZIONE DA VIRUS DELLA DERMATITE NODULARE CONTAGIOSA

(di cui all'articolo 3)

PARTE I

Informazioni che devono figurare nel piano di vaccinazione di cui all'articolo 3

Qualora uno Stato membro esegua vaccinazioni contro l'infezione da LSDV, tali vaccinazioni sono eseguite in conformità di un piano di vaccinazione contenente almeno le informazioni seguenti:

a)	la descrizione e i risultati della valutazione svolta conformemente ai criteri di cui all'articolo 46, paragrafo 2, del regolamento (UE) 2016/429, comprese la situazione epidemiologica e altre informazioni pertinenti utilizzate come base per la valutazione;

b)	i principali obiettivi e fini della strategia di vaccinazione scelta e del piano di vaccinazione;

c)	la descrizione geografica dettagliata della zona di vaccinazione in cui si deve eseguire la vaccinazione e l'ubicazione degli stabilimenti che detengono bovini da vaccinare, corredata di mappe;

d)	l'autorità responsabile per la somministrazione del vaccino ai bovini;

e)	il sistema di supervisione della somministrazione del vaccino;

f)	il numero di stabilimenti che detengono bovini situati nella zona soggetta a restrizioni e il numero di stabilimenti in cui eseguire le vaccinazioni, se i due dati non coincidono;

g)	il numero stimato di bovini, le relative categorie e l'età degli animali da vaccinare;

h)	la durata prevista della vaccinazione, dall'inizio della vaccinazione alla fine della sorveglianza svolta dopo la vaccinazione;

i)	la sintesi delle caratteristiche del vaccino, compresi il nome del prodotto e il nome del produttore nonché le modalità di somministrazione;

j)	indicare se il vaccino è impiegato in conformità dell'articolo 110, paragrafi 2 e 3, del regolamento (UE) 2019/6 del Parlamento europeo e del Consiglio (1);

k)	i metodi per valutare l'efficacia della vaccinazione;

l)	le norme in materia di igiene e biosicurezza da applicare;

m)	il sistema di conservazione della documentazione sulla vaccinazione;

n)	altri aspetti pertinenti per la situazione specifica.

PARTE II

Prescrizioni minime per i piani di vaccinazione contro l'infezione da LSDV di cui all'articolo 3

I piani di vaccinazione contro l'infezione da LSDV sono conformi alle seguenti prescrizioni tecniche:

a)	vaccinazione di tutti i bovini indipendentemente dal sesso, dall'età e dalla situazione gestativa o produttiva nelle zone soggette a restrizioni I e II in cui si deve eseguire la vaccinazione;

b)	vaccinazione degli animali nati da bovini vaccinati di età superiore a quattro mesi, conformemente alle istruzioni del produttore del vaccino impiegato;

c)	rivaccinazione di tutti i bovini conformemente alle istruzioni del produttore;

d)	inserimento, da parte dell'autorità competente, dei dati di ciascun bovino vaccinato nell'apposita banca dati online connessa con la banca dati centrale istituita conformemente all'articolo 42 del regolamento (UE) 2019/2035 del Parlamento europeo e del Consiglio (2);

e)	istituzione di una zona di sorveglianza rafforzata di almeno 20 km attorno alle zone soggette a restrizioni I e II in cui è eseguita la vaccinazione, ove la sorveglianza è intensificata e gli spostamenti di bovini sono sottoposti a controlli da parte dell'autorità competente;

f)	copertura vaccinale pari almeno al 95 % degli allevamenti, corrispondente almeno al 75 % della popolazione bovina.

PARTE III

Informazioni preliminari da comunicare alla Commissione e agli altri Stati membri prima di avviare la vaccinazione, di cui all'articolo 3, paragrafo 3

Gli Stati membri che eseguono la vaccinazione contro la dermatite nodulare contagiosa comunicano le informazioni seguenti alla Commissione e agli altri Stati membri prima di avviare la vaccinazione:

a)	una breve giustificazione per l'avvio della vaccinazione;

b)	le specie dei bovini da vaccinare;

c)	il numero stimato dei bovini da vaccinare;

d)	la durata prevista della vaccinazione;

e)	il tipo e la denominazione commerciale del vaccino applicato precisando se il vaccino debba essere impiegato conformemente all'articolo 110, paragrafi 2 e 3, del regolamento (UE) 2019/6;

f)	una descrizione della zona di vaccinazione stimata.

---

(1)  Regolamento (UE) 2019/6 del Parlamento europeo e del Consiglio, dell'11 dicembre 2018, relativo ai medicinali veterinari e che abroga la direttiva 2001/82/CE (GU L 4 del 7.1.2019, pag. 43).

(2)  Regolamento delegato (UE) 2019/2035 della Commissione, del 28 giugno 2019, che integra il regolamento (UE) 2016/429 del Parlamento europeo e del Consiglio per quanto riguarda le norme relative agli stabilimenti che detengono animali terrestri e agli incubatoi nonché alla tracciabilità di determinati animali terrestri detenuti e delle uova da cova (GU L 314 del 5.12.2019, pag. 115).

Articolo 1

All’articolo 4 del regolamento di esecuzione (UE) 2021/442, il secondo comma è sostituito dal seguente:

Articolo 2

All’articolo 3 del regolamento di esecuzione (UE) 2021/521, il secondo comma è sostituito dal seguente:

Articolo 3

Il presente regolamento entra in vigore il 1o luglio 2021.

Articolo 1

In deroga agli articoli 2, 3 e 4 della decisione 2013/471/UE, qualora le misure restrittive connesse alla COVID-19 compromettano la possibilità di organizzare una riunione o assistervi di persona, i beneficiari che partecipano alla riunione a distanza per via elettronica hanno diritto soltanto a un’indennità giornaliera di 145 EUR.

Articolo 2

Il Comitato adotta disposizioni dettagliate che attuano l’articolo 1 entro il 2 settembre 2021.

Articolo 3

Entro il 2 gennaio 2022 e successivamente ogni sei mesi, il Comitato presenta al Consiglio una relazione di valutazione sull’applicazione della presente decisione e, in particolare, sulla sua incidenza sul bilancio, nonché sul persistere di difficoltà di viaggio legate alla COVID-19 o di relative misure restrittive che compromettano la possibilità di organizzare riunioni o parteciparvi di persona.

Articolo 4

La presente decisione entra in vigore il giorno successivo alla pubblicazione nella Gazzetta ufficiale dell’Unione europea.

Articolo 1

Le specifiche tecniche del certificato COVID digitale dell’UE che stabiliscono la struttura dei dati generici, i meccanismi di codifica e il meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente sono stabilite nell’allegato I.

Articolo 2

Le norme per la compilazione dei certificati di cui all’articolo 3, paragrafo 1, del regolamento (UE) 2021/953 sono stabilite nell’allegato II della presente decisione.

Articolo 3

I requisiti che stabiliscono la struttura comune dell’identificativo univoco del certificato sono stabiliti nell’allegato III.

Articolo 4

Le norme di governance applicabili ai certificati a chiave pubblica in relazione al gateway per i certificati COVID digitali dell’UE a sostegno degli aspetti di interoperabilità del quadro di fiducia sono stabilite nell’allegato IV.

ALLEGATO I

FORMATO E GESTIONE DELLA FIDUCIA

Struttura dei dati generici, meccanismi di codifica e meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente (di seguito «Q R»)

1.   Introduzione

Le specifiche tecniche di cui al presente allegato contengono una struttura dei dati generici e meccanismi di codifica per il certificato COVID digitale dell’UE (Digital COVID Certificate — «DCC»). Specificano inoltre un meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente («QR») che possa essere visualizzato sullo schermo di un dispositivo mobile o stampato. I formati contenitore dei certificati sanitari elettronici delle presenti specifiche sono generici, ma in questo contesto sono utilizzati per trasportare il DCC.

2.   Terminologia

Ai fini del presente allegato, per «emittenti» si intendono le organizzazioni che utilizzano le presenti specifiche per rilasciare i certificati sanitari e per «verificatori» si intendono le organizzazioni che accettano i certificati sanitari come prova dello stato sanitario. Per «partecipanti» si intendono gli emittenti e i verificatori. Alcuni aspetti indicati nel presente allegato devono essere coordinati tra i partecipanti, come la gestione di uno spazio dei nomi e la distribuzione delle chiavi crittografiche. Si presume che una parte, in appresso denominata «segretariato», svolga tali compiti.

3.   Formato contenitore dei certificati sanitari elettronici

Il formato contenitore dei certificati sanitari elettronici (Electronic Health Certificate Container Format — «HCERT») è concepito per fornire un veicolo uniforme e standardizzato per i certificati sanitari dei diversi emittenti («emittenti»). L’obiettivo delle presenti specifiche è armonizzare il modo in cui tali certificati sanitari sono rappresentati, codificati e firmati allo scopo di agevolare l’interoperabilità.

La capacità di leggere e interpretare un DCC rilasciato da qualsiasi emittente richiede una struttura comune dei dati e un accordo sul significato di ciascun campo di dati del carico utile. Per agevolare tale interoperabilità, è definita una struttura comune coordinata dei dati mediante l’uso di uno schema «JSON» che costituisce il quadro del DCC.

3.1.   Struttura del carico utile

Il carico utile è strutturato e codificato come CBOR con firma digitale COSE. Questo è comunemente noto come «CBOR Web Token» (CWT) ed è definito in RFC 8392 (1). Il carico utile, quale definito nelle sezioni che seguono, è trasportato in una richiesta hcert.

L’integrità e l’autenticità dell’origine dei dati del carico utile devono essere verificabili dal verificatore. Per fornire questo meccanismo, l’emittente deve firmare il CWT utilizzando uno schema di firma elettronica asimmetrica quale definito nella specifica COSE (RFC 8152 (2)).

3.2.   Richieste CWT

3.2.1.   Panoramica della struttura CWT

Intestazione protetta

—	Algoritmo di firma (alg, etichetta 1)

—	Identificativo della chiave (kid, etichetta 4)

Carico utile

—	Emittente (iss, chiave di richiesta 1, facoltativo, ISO 3166-1 alpha-2 dell’emittente)

—	Momento del rilascio (iat, chiave di richiesta 6)

—	Termine di scadenza (exp, chiave di richiesta 4)

—	Certificato sanitario (hcert, chiave di richiesta -260)

—	Certificato COVID digitale dell’UE v1 (eu_DCC_v1, chiave di richiesta 1)

Firma

3.2.2.   Algoritmo di firma

Il parametro dell’algoritmo di firma (alg) indica l’algoritmo utilizzato per creare la firma. Deve rispettare o superare gli attuali orientamenti del SOGIS sintetizzati nei paragrafi seguenti.

Sono definiti un algoritmo primario e un algoritmo secondario. L’algoritmo secondario dovrebbe essere utilizzato solo se l’algoritmo primario non è accettabile nell’ambito delle norme e dei regolamenti imposti all’emittente.

Al fine di garantire la sicurezza del sistema, tutte le implementazioni devono incorporare l’algoritmo secondario. Per questo motivo, sia l’algoritmo primario che quello secondario devono essere implementati.

I livelli stabiliti dal SOGIS per gli algoritmi primari e secondari sono i seguenti.

—

Algoritmo primario: l’algoritmo primario è l’algoritmo di firma digitale su curva ellittica (Elliptic Curve Digital Signature Algorithm — ECDSA) quale definito nella sezione 2.3 (ISO/IEC 14888–3:2006) utilizzando i parametri P–256 definiti nell’appendice D (D.1.2.3) di (FIPS PUB 186-4) in combinazione con l’algoritmo hash SHA–256 quale definito nella funzione 4 (ISO/IEC 10118–3:2004).

Questo corrisponde al parametro dell’algoritmo COSE ES256.

—	Algoritmo secondario: l’algoritmo secondario è RSASSA-PSS quale definito in (RFC 8230 (3)) con un modulo di 2048 bit in combinazione con l’algoritmo hash SHA–256 quale definito nella funzione 4 (ISO/IEC 10118–3:2004).

Questo corrisponde al parametro dell’algoritmo COSE PS256.

3.2.3.   Identificativo della chiave

La richiesta Identificativo della chiave (kid) indica il certificato di firma digitale (Document Signer Certificate — DSC) contenente la chiave pubblica che il verificatore deve utilizzare per controllare la correttezza della firma digitale. Nell’allegato IV è descritta la governance dei certificati a chiave pubblica, compresi i requisiti per i DSC.

La richiesta Identificativo della chiave (kid) è utilizzata dai verificatori per selezionare la chiave pubblica corretta da un elenco di chiavi relative all’emittente indicato nella richiesta Emittente (iss). Un emittente può utilizzare diverse chiavi in parallelo per motivi amministrativi e quando effettua i rinnovi delle chiavi. L’identificativo della chiave non è un campo critico per la sicurezza. Per questo motivo, se necessario, può anche essere collocato in un’intestazione non protetta. I verificatori devono accettare entrambe le opzioni. Se entrambe le opzioni sono presenti, deve essere utilizzato l’identificativo della chiave nell’intestazione protetta.

A causa dell’accorciamento dell’identificativo (per motivi di limitazione delle dimensioni) vi è una probabilità molto bassa, ma non inesistente, che l’elenco generale dei DSC accettati da un verificatore possa contenere DSC con kid doppi. Per questo motivo il verificatore deve controllare tutti i DSC con tale kid.

3.2.4.   Emittente

La richiesta Emittente (iss) è un valore di stringa che può facoltativamente riportare il codice paese ISO 3166-1 alpha-2 del soggetto che ha rilasciato il certificato sanitario. Tale richiesta può essere utilizzata da un verificatore per individuare la serie di DSC da utilizzare per la verifica. La chiave di richiesta 1 è utilizzata per identificare questa richiesta.

3.2.5.   Termine di scadenza

La richiesta Termine di scadenza (exp) deve contenere una marcatura temporale nel formato NumericDate intero (come specificato in RFC 8392 (4), sezione 2) che indichi per quanto tempo quella particolare firma sul carico utile è considerata valida e decorso il quale il verificatore deve rifiutare il carico utile come scaduto. Il parametro del termine di scadenza ha lo scopo di imporre un limite al periodo di validità del certificato sanitario. La chiave di richiesta 4 è utilizzata per identificare questa richiesta.

Il termine di scadenza non deve cadere oltre il periodo di validità del DSC.

3.2.6.   Momento del rilascio

La richiesta Momento del rilascio (iat) deve contenere una marcatura temporale nel formato NumericDate intero (come specificato in RFC 8392 (5), sezione 2) indicante il momento in cui è stato creato il certificato sanitario.

Il campo Momento del rilascio non deve indicare una data anteriore al periodo di validità del DSC.

I verificatori possono applicare policy aggiuntive allo scopo di limitare la validità del certificato sanitario in base al momento del rilascio. La chiave di richiesta 6 è utilizzata per identificare questa richiesta.

3.2.7.   Richiesta Certificato sanitario

La richiesta Certificato sanitario (hcert) è un oggetto JSON (RFC 7159 (6)) contenente le informazioni sullo stato sanitario. Nell’ambito della stessa richiesta possono esistere diversi tipi di certificato sanitario, tra cui il DCC.

Il formato JSON serve esclusivamente per finalità di schema. Il formato di rappresentazione è CBOR, come definito in (RFC 7049 (7)). Gli sviluppatori di applicazioni non possono in realtà mai decodificare o codificare da e verso il formato JSON, bensì utilizzano la struttura in-memory.

La chiave di richiesta da utilizzare per identificare questa richiesta è -260.

Le stringhe dell’oggetto JSON dovrebbero essere normalizzate secondo la Normalization Form Canonical Composition (NFC) definita nello standard Unicode. Le applicazioni di decodifica dovrebbero tuttavia essere permissive e solide in relazione a questi aspetti ed è fortemente incoraggiata l’accettazione di qualsiasi tipo di conversione ragionevole. Se durante la decodifica o nelle successive funzioni di confronto si riscontrano dati non normalizzati, le implementazioni dovrebbero comportarsi come se l’immissione fosse normalizzata NFC.

4.   Serializzazione e creazione del carico utile DCC

Come modello di serializzazione si utilizza lo schema seguente:

Il processo inizia con l’estrazione dei dati, ad esempio da un archivio di dati sanitari (o da qualche fonte di dati esterna), e con la strutturazione dei dati estratti secondo gli schemi DCC definiti. In questo processo, la conversione nel formato di dati definito e la trasformazione per la leggibilità da parte dell’uomo possono aver luogo prima dell’inizio della serializzazione CBOR. Gli acronimi delle richieste sono in ogni caso mappati ai nomi visualizzati prima della serializzazione e dopo la deserializzazione.

Non sono consentiti contenuti di dati nazionali facoltativi nei certificati rilasciati a norma del regolamento (UE) 2021/953 (8). Il contenuto di dati è limitato agli elementi di dati definiti nella serie minima di dati specificata nell’allegato del regolamento (UE) 2021/953.

5.   Codifiche di trasporto

5.1.   Codifica grezza

Per le interfacce di dati arbitrari, il contenitore HCERT e i suoi carichi utili possono essere trasferiti tal quali, utilizzando qualsiasi trasporto di dati sottostante sicuro e affidabile a 8 bit. Queste interfacce possono comprendere la comunicazione di prossimità (Near-Field Communication — NFC), il Bluetooth o il trasferimento attraverso un protocollo di livello applicazione, ad esempio il trasferimento di un HCERT dall’emittente al dispositivo mobile del titolare.

Se il trasferimento dell’HCERT dall’emittente al titolare si basa su un’interfaccia di sola presentazione (ad esempio SMS, e-mail), la codifica di trasporto grezza non è ovviamente applicabile.

5.2.   Codice a barre

5.2.1.   Compressione del carico utile (CWT)

Per ridurre le dimensioni e migliorare la velocità e l’affidabilità nel processo di lettura dell’HCERT, il CWT è compresso utilizzando ZLIB (RFC 1950 (9)) e il meccanismo di compressione Deflate nel formato definito in RFC 1951 (10).

5.2.2.   Codice a barre 2D QR

Ai fini di una migliore gestione delle apparecchiature preesistenti progettate per funzionare sui carichi utili ASCII, il CWT compresso è codificato come ASCII utilizzando Base45 prima di essere codificato in un codice a barre 2D.

Il formato QR quale definito nella norma (ISO/IEC 18004:2015) è utilizzato per la generazione di codici a barre 2D. Si raccomanda un tasso di correzione degli errori di «Q» (circa il 25 %). Poiché si utilizza Base45, il codice QR deve utilizzare la codifica alfanumerica (modalità 2, indicata dai simboli 0010).

Affinché i verificatori siano in grado di rilevare il tipo di dati codificati e di selezionare il sistema adeguato di decodifica e trattamento, i dati codificati Base45 (secondo la presente specifica) hanno come prefisso la stringa dell’identificativo di contesto «HC1:». Le versioni future della presente specifica che incidono sulla retrocompatibilità definiranno un nuovo identificativo di contesto, mentre il carattere che segue «HC» sarà tratto dalla serie di caratteri [1-9 A-Z]. L’ordine degli incrementi è definito in tale ordine, ossia prima [1-9] e successivamente [A-Z].

Si raccomanda di rendere il codice ottico sul supporto di presentazione con dimensioni della diagonale comprese tra 35 mm e 60 mm per i lettori con ottica fissa in cui i supporti di presentazione devono essere collocati sulla superficie del lettore.

Se il codice ottico è stampato su carta con stampanti a bassa risoluzione (< 300 dpi), si deve prestare attenzione a rappresentare ciascun simbolo (punto) del codice QR esattamente quadrato. Se il ridimensionamento non sarà proporzionale, alcune righe o colonne del codice QR avranno simboli rettangolari, il che in molti casi ostacolerà la leggibilità.

6.   Formato dell’elenco di fiducia (elenco di CSCA e DSC)

Ciascuno Stato membro è tenuto a fornire un elenco di una o più autorità nazionali di certificazione (Country Signing Certificate Authority — CSCA) e un elenco di tutti i certificati di firma digitale (DSC) validi e a mantenere tali elenchi aggiornati.

6.1.   CSCA/DSC semplificati

A partire da questa versione delle specifiche, gli Stati membri non presumono che siano utilizzate informazioni relative all’elenco dei certificati revocati (Certificate Revocation List — CRL) o che il periodo di utilizzo della chiave privata sia verificato dagli attuatori.

Il meccanismo di validità principale è invece la presenza del certificato nella versione più recente dell’elenco dei certificati.

6.2.   Infrastruttura a chiave pubblica eMRTD conforme ICAO e centri protezione

Gli Stati membri possono ricorrere a una CSCA distinta, ma possono anche presentare i loro certificati CSCA e/o DSC eMRTD esistenti; inoltre possono anche scegliere di procurarseli presso centri protezione (commerciali) e di presentare questi ultimi. Tuttavia qualsiasi DSC deve sempre essere firmato dalla CSCA presentata da tale Stato membro.

7.   Considerazioni in materia di sicurezza

Nel progettare uno schema basato su questa specifica, gli Stati membri individuano, analizzano e monitorano taluni aspetti legati alla sicurezza.

Dovrebbero essere presi in considerazione almeno gli aspetti seguenti.

7.1.   Periodo di validità della firma HCERT

L’emittente degli HCERT è tenuto a limitare il periodo di validità della firma specificando un termine di scadenza. Ciò impone al titolare di un certificato sanitario di rinnovarlo periodicamente.

Il periodo di validità accettabile può essere determinato da vincoli pratici. Ad esempio, un viaggiatore potrebbe non avere la possibilità di rinnovare il certificato sanitario durante un viaggio all’estero. Tuttavia può anche accadere che un emittente stia valutando la possibilità di una qualche forma di compromissione della sicurezza che gli impone di ritirare un DSC (invalidando tutti i certificati sanitari rilasciati utilizzando tale chiave ancora entro il loro periodo di validità). Le conseguenze di un tale evento possono essere limitate effettuando una regolare rotazione delle chiavi emittente e richiedendo il rinnovo di tutti i certificati sanitari a intervalli ragionevoli.

7.2.   Gestione delle chiavi

Questa specifica si basa in larga misura su solidi meccanismi crittografici che garantiscono l’integrità dei dati e l’autenticazione dell’origine dei dati. È pertanto necessario mantenere la riservatezza delle chiavi private.

La riservatezza delle chiavi crittografiche può essere compromessa in vari modi, ad esempio:

—	il processo di generazione delle chiavi può essere viziato, con conseguente debolezza delle chiavi;

—	le chiavi possono essere rivelate per errore umano;

—	le chiavi possono essere rubate da soggetti esterni o interni;

—	le chiavi possono essere calcolate mediante crittoanalisi.

Al fine di mitigare i rischi che l’algoritmo di firma sia debole e consenta di compromettere le chiavi private mediante crittoanalisi, questa specifica raccomanda a tutti i partecipanti di implementare un algoritmo di firma secondario di riserva, basato su parametri diversi o su un problema matematico diverso da quello primario.

Per quanto riguarda i rischi menzionati relativi agli ambienti operativi degli emittenti, sono attuate misure di mitigazione per garantire un controllo efficace, in modo da generare, memorizzare e utilizzare le chiavi private nei moduli di sicurezza hardware (Hardware Security Model — HSM). L’uso di HSM per la firma dei certificati sanitari è fortemente incoraggiato.

Indipendentemente dal fatto che un emittente decida di utilizzare gli HSM o no, è opportuno stabilire un calendario dei rinnovi delle chiavi la cui frequenza sia proporzionata all’esposizione delle chiavi a reti esterne, altri sistemi e personale. Un calendario dei rinnovi ben scelto limita inoltre i rischi associati ai certificati sanitari rilasciati erroneamente, consentendo all’emittente di revocare tali certificati in lotti, ritirando una chiave, se necessario.

7.3.   Convalida dei dati immessi

Queste specifiche possono essere utilizzate in modo da implicare il ricevimento di dati da fonti non fidate in sistemi che possono essere di natura critica. Per ridurre al minimo i rischi associati a questo vettore di attacco, tutti i campi di immissione devono essere debitamente convalidati in termini di tipi di dati, lunghezze e contenuto. Prima di qualsiasi trattamento del contenuto dell’HCERT è verificata anche la firma dell’emittente. Tuttavia la convalida della firma dell’emittente implica innanzitutto l’analisi dell’intestazione protetta dell’emittente, nella quale un potenziale aggressore potrebbe tentare di iniettare informazioni accuratamente preparate per compromettere la sicurezza del sistema.

8.   Gestione della fiducia

La firma dell’HCERT richiede una chiave pubblica da verificare. Gli Stati membri mettono a disposizione tali chiavi pubbliche. In ultima analisi, ogni verificatore deve disporre di un elenco di tutte le chiavi pubbliche di cui intende fidarsi (dato che la chiave pubblica non fa parte dell’HCERT).

Il sistema è costituito (solo) da due livelli; per ciascuno Stato membro, uno o più certificati di livello nazionale che firmano ognuno uno o più certificati di firma digitale utilizzati nelle operazioni quotidiane.

I certificati degli Stati membri sono denominati certificati dell’autorità nazionale di certificazione (CSCA) e sono (di norma) autofirmati. Gli Stati membri possono averne più di una (ad esempio, in caso di decentramento regionale). Questi certificati CSCA firmano regolarmente i certificati di firma digitale (DSC) utilizzati per firmare gli HCERT.

Il «segretariato» svolge un ruolo funzionale. Esso aggrega e pubblica periodicamente i DSC degli Stati membri, dopo averli verificati sulla base dell’elenco dei certificati CSCA (che sono stati trasmessi e verificati con altri mezzi).

L’elenco risultante dei DSC fornisce quindi la serie aggregata di chiavi pubbliche accettabili (e i relativi identificativi) che i verificatori possono utilizzare per convalidare le firme sugli HCERT. I verificatori devono estrarre e aggiornare regolarmente questo elenco.

Tali elenchi specifici degli Stati membri possono essere adattati nel formato per il proprio contesto nazionale. Pertanto il formato di file di questo elenco di fiducia può variare; ad esempio può trattarsi di un formato JWKS firmato (formato JWK Set per RFC 7517 (11), sezione 5) o di qualsiasi altro formato specifico per la tecnologia utilizzata in tale Stato membro.

Al fine di garantire la semplicità, gli Stati membri possono presentare i loro certificati CSCA esistenti generati dai rispettivi sistemi eMRTD conformi ICAO o, come raccomandato dall’OMS, crearne uno specifico per questo settore sanitario.

8.1.   Identificativo della chiave (kid)

L’identificativo della chiave (kid) è calcolato quando si costruisce l’elenco delle chiavi pubbliche fidate dei DSC ed è costituito da un’impronta digitale SHA-256 troncata (primi 8 byte) del DSC codificato nel formato (grezzo) DER.

I verificatori non sono tenuti a calcolare l’identificativo della chiave sulla base del DSC e possono far collimare direttamente l’identificativo della chiave nel certificato sanitario rilasciato con quello figurante nell’elenco di fiducia.

8.2.   Differenze rispetto al modello di fiducia dell’infrastruttura a chiave pubblica eMRTD conforme ICAO

Nonostante la modellizzazione sulle migliori pratiche del modello di fiducia dell’infrastruttura a chiave pubblica (Public Key Infrastructure — PKI) eMRTD conforme ICAO, è necessario introdurre una serie di semplificazioni nell’interesse della velocità:

—	uno Stato membro può presentare più certificati CSCA;

—	il periodo di validità del DSC (utilizzo della chiave) può essere fissato a una durata non superiore a quella del certificato CSCA e può essere assente;

—	il DSC può contenere identificativi di policy (utilizzo esteso della chiave) specifici dei certificati sanitari;

—	gli Stati membri possono scegliere di non effettuare mai alcuna verifica delle revoche pubblicate e di affidarsi esclusivamente agli elenchi di DSC che ricevono quotidianamente dal segretariato o che compilano essi stessi.

---

(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)  Regolamento (UE) 2021/953 del Parlamento europeo e del Consiglio, del 14 giugno 2021, su un quadro per il rilascio, la verifica e l’accettazione di certificati interoperabili di vaccinazione, di test e di guarigione in relazione alla COVID-19 (certificato COVID digitale dell’UE) per agevolare la libera circolazione delle persone durante la pandemia di COVID-19 (GU L 211 del 15.6.2021, pag. 1).

(9)  rfc1950 (ietf.org).

(10)  rfc1951 (ietf.org).

(11)  rfc7517 (ietf.org).

ALLEGATO II

NORME PER LA COMPILAZIONE DEL CERTIFICATO COVID DIGITALE DELL’UE

Le norme generali relative alle serie di valori stabilite nel presente allegato mirano a garantire l’interoperabilità a livello semantico e consentono implementazioni tecniche uniformi per il DCC. Gli elementi contenuti nel presente allegato possono essere utilizzati per i tre diversi scenari (vaccinazione/test/guarigione) previsti dal regolamento (UE) 2021/953. Nel presente allegato sono elencati solo gli elementi che richiedono una standardizzazione semantica mediante serie di valori codificati.

La traduzione degli elementi codificati nella lingua nazionale è di competenza degli Stati membri.

Per tutti i campi di dati non menzionati nelle seguenti descrizioni delle serie di valori, si raccomanda la codifica in UTF-8 (nome, centro in cui è stato effettuato il test, soggetto che ha rilasciato il certificato). Si raccomanda di codificare i campi di dati contenenti date (data di nascita, data di vaccinazione, data del prelievo del campione, data del primo risultato positivo al test, date di validità del certificato) secondo la norma ISO 8601.

Se per qualsiasi motivo non è possibile utilizzare i sistemi di codici preferiti elencati di seguito, possono essere utilizzati altri sistemi di codici internazionali ed è opportuno predisporre suggerimenti su come mappare i codici dell’altro sistema di codici al sistema di codici preferito. Il testo (nomi visualizzati) può essere utilizzato in casi eccezionali come meccanismo di backup quando nelle serie di valori definite non è disponibile un codice adeguato.

Gli Stati membri che utilizzano altri codici nei loro sistemi dovrebbero mappare tali codici alle serie di valori descritte. Gli Stati membri sono responsabili di tali mappature.

La Commissione aggiorna regolarmente le serie di valori con il sostegno della rete eHealth e del comitato per la sicurezza sanitaria. Le serie di valori aggiornate sono pubblicate sul pertinente sito web della Commissione e sulla pagina web della rete eHealth. Dovrebbe essere fornita una cronologia delle modifiche.

1.   Malattia o agente in questione/malattia o agente da cui il titolare è guarito: COVID-19 (SARS-CoV-2 o una delle sue varianti)

Sistema di codici preferito: SNOMED CT.

Da utilizzare nei certificati 1, 2 e 3.

I codici selezionati fanno riferimento alla COVID-19 o, se sono necessarie informazioni più dettagliate sulla variante genetica del SARS-CoV-2, a tali varianti laddove tali informazioni dettagliate siano necessarie per motivi epidemiologici.

Un esempio di codice da utilizzare è il codice SNOMED CT 840539006 (COVID-19).

2.   Vaccino o profilassi anti COVID-19

Sistema di codici preferito: SNOMED CT o classificazione ATC.

Da utilizzare nel certificato 1.

Esempi di codici da utilizzare, tratti dai sistemi di codici preferiti, sono il codice SNOMED CT 1119305005 (vaccino antigenico contro il SARS-CoV-2), 1119349007 (vaccino a mRNA contro il SARS-CoV-2) o J07BX03 (vaccini anti COVID-19). La serie di valori dovrebbe essere estesa man mano che vengono sviluppati e messi in uso nuovi tipi di vaccini.

3.   Medicinale vaccinale anti COVID-19

Sistemi di codici preferiti (in ordine di preferenza):

—	registro dell’Unione dei medicinali per i vaccini con autorizzazione a livello dell’UE (numeri di autorizzazione);

—	un registro globale dei vaccini come quello che potrebbe essere istituito dall’Organizzazione mondiale della sanità;

—	nome del medicinale vaccinale negli altri casi. Se il nome comprende spazi vuoti, questi devono essere sostituiti da un trattino (-).

Nome della serie di valori: Vaccino.

Da utilizzare nel certificato 1.

Un esempio di codice da utilizzare, tratto dai sistemi di codici preferiti, è EU/1/20/1528 (Comirnaty). Esempio di nome del vaccino da utilizzare come codice: Sputnik-V (che sta per Sputnik V).

4.   Titolare dell’autorizzazione all’immissione in commercio del vaccino anti COVID-19 o fabbricante del vaccino

Sistema di codici preferito:

—	codice organismo dell’EMA (sistema SPOR per ISO IDMP);

—	un registro globale dei titolari dell’autorizzazione all’immissione in commercio dei vaccini o dei fabbricanti di vaccini, come quello che potrebbe essere istituito dall’Organizzazione mondiale della sanità;

—	nome dell’organismo negli altri casi. Se il nome comprende spazi vuoti, questi devono essere sostituiti da un trattino (-).

Da utilizzare nel certificato 1.

Un esempio di codice da utilizzare, tratto dal sistema di codici preferito, è ORG-100001699 (AstraZeneca AB). Esempio di nome dell’organismo da utilizzare come codice: Sinovac-Biotech (che sta per Sinovac Biotech).

5.   Numero in una serie di dosi e numero complessivo di dosi di una serie

Da utilizzare nel certificato 1.

Due campi:

1)	numero di dosi somministrate in un ciclo;

2)	numero di dosi previste per un ciclo completo (specifiche per una persona al momento della somministrazione).

Ad esempio, 1/1 o 2/2 indicherà che il ciclo è stato completato; l’opzione 1/1 si utilizza anche per i vaccini che prevedono due dosi, ma per i quali il protocollo applicato dallo Stato membro prevede di somministrare una dose ai cittadini cui sia stata diagnosticata la COVID-19 prima della vaccinazione. Il numero complessivo di dosi di una serie dovrebbe essere indicato in base alle informazioni disponibili al momento della somministrazione della dose. Ad esempio, se un vaccino specifico richiede un terzo richiamo al momento dell’ultima somministrazione, ciò dovrà essere rispecchiato dal numero nel secondo campo (ad esempio 2/3, 3/3 ecc.).

6.   Stato membro o paese terzo in cui è stato somministrato il vaccino/effettuato il test

Sistema di codici preferito: codici paese secondo la norma ISO 3166.

Da utilizzare nei certificati 1, 2 e 3.

Contenuto della serie di valori: l’elenco completo dei codici a 2 lettere, disponibile come serie di valori secondo la definizione in FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2).

7.   Tipo di test

Sistema di codici preferito: LOINC.

Da utilizzare nel certificato 2, e nel certificato 3 qualora mediante un atto delegato sia introdotto il sostegno per il rilascio di certificati di guarigione basati su tipi di test diversi dai test di amplificazione dell’acido nucleico (NAAT).

I codici di questa serie di valori si riferiscono al metodo di test e sono selezionati almeno per distinguere i test NAAT dai test antigenici rapidi (RAT), come indicato nel regolamento (UE) 2021/953.

Un esempio di codice da utilizzare, tratto dal sistema di codici preferito, è LP217198-3 (immunodosaggio rapido).

8.   Fabbricante e denominazione commerciale del test utilizzato (facoltativo per i test NAAT)

Sistema di codici preferito: elenco dei test antigenici rapidi del CSS, tenuto dal JRC (banca dati dei dispositivi diagnostici in vitro e dei metodi di test COVID-19).

Da utilizzare nel certificato 2.

Il contenuto della serie di valori comprende la selezione del test antigenico rapido elencato nell’elenco comune e aggiornato dei test antigenici rapidi per la COVID-19, stabilito sulla base della raccomandazione 2021/C 24/01 del Consiglio e approvato dal comitato per la sicurezza sanitaria. L’elenco è tenuto dal JRC nella banca dati dei dispositivi diagnostici in vitro e dei metodi di test COVID-19 all’indirizzo seguente: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

Per questo sistema di codici devono essere utilizzati campi pertinenti quali l’identificativo del dispositivo diagnostico, il nome del test e il fabbricante, secondo il formato strutturato del JRC disponibile all’indirizzo https://covid-19-diagnostics.jrc.ec.europa.eu/devices.

9.   Risultato del test

Sistema di codici preferito: SNOMED CT.

Da utilizzare nel certificato 2.

I codici selezionati consentono di distinguere tra risultati positivi e negativi al test (rilevato o non rilevato). Se i casi d’uso lo richiedono, possono essere aggiunti altri valori (ad esempio, indeterminato).

Esempi di codici da utilizzare, tratti dal sistema di codici preferito, sono 260415000 (non rilevato) e 260373001 (rilevato).

ALLEGATO III

STRUTTURA COMUNE DELL’IDENTIFICATIVO UNIVOCO DEL CERTIFICATO

1.   Introduzione

Ciascun certificato COVID digitale dell’UE (DCC) include un identificativo univoco del certificato (Unique Certificate Identifier — UCI) che sostiene l’interoperabilità dei DCC. L’UCI può essere utilizzato per verificare il certificato. Gli Stati membri sono responsabili della sua attuazione. L’UCI è un mezzo per verificare la veridicità del certificato e, se del caso, per collegarsi a un sistema di registrazione (ad esempio, un sistema informativo sulla vaccinazione). Questi identificativi consentono inoltre agli Stati membri di affermare (su supporto cartaceo e digitale) che le persone sono state vaccinate o sottoposte a test.

2.   Composizione dell’identificativo univoco del certificato

L’UCI segue una struttura e un formato comuni che agevolano l’interpretazione delle informazioni da parte dell’uomo e/o della macchina e può riguardare elementi quali lo Stato membro di vaccinazione, il vaccino stesso e l’identificativo specifico di uno Stato membro. Garantisce agli Stati membri la flessibilità necessaria per la sua formattazione, nel pieno rispetto della legislazione in materia di protezione dei dati. L’ordine dei distinti elementi segue una gerarchia definita che può consentire future modifiche dei blocchi, mantenendone nel contempo l’integrità strutturale.

Le possibili soluzioni per la composizione dell’UCI formano uno spettro in cui la modularità e l’interpretabilità da parte dell’uomo costituiscono i due principali parametri di diversificazione e una caratteristica fondamentale:

—	modularità: la misura in cui il codice è composto da blocchi costitutivi distinti che contengono informazioni semanticamente diverse;

—	interpretabilità da parte dell’uomo: la misura in cui il codice è significativo o può essere interpretato da un lettore umano;

—

univocità a livello mondiale: l’identificativo del paese o dell’autorità è ben gestito e ogni paese (autorità) è tenuto a gestire adeguatamente il proprio segmento nello spazio dei nomi senza riciclare o riemettere gli identificativi. Questa combinazione garantisce che ciascun identificativo sia univoco a livello mondiale.

3.   Requisiti generali

In relazione all’UCI dovrebbero essere soddisfatti i requisiti generali seguenti:

1)	serie di caratteri: sono ammessi solo caratteri alfanumerici US-ASCII maiuscoli (da «A» a «Z», da «0» a «9»), con caratteri speciali aggiuntivi per la separazione da RFC 3986 (1) , (2), vale a dire {«/», «#», «:»};

2)	lunghezza massima: i programmatori dovrebbero cercare di rispettare una lunghezza di 27-30 caratteri (3);

3)	prefisso della versione: si riferisce alla versione dello schema UCI. Il prefisso della versione è «01» per questa versione del documento ed è composto da due cifre;

4)	prefisso del paese: il codice paese è specificato dalla norma ISO 3166-1. Codici più lunghi (ad esempio 3 e più caratteri come nel caso di «UNHCR») sono riservati all’uso futuro;

5)

suffisso del codice/somma di controllo. 5.1. Gli Stati membri dovrebbero utilizzare una somma di controllo quando è probabile che si verifichino la trasmissione, la trascrizione (umana) o altre forme di corruzione (vale a dire l’utilizzo in forma stampata). 5.2. La somma di controllo non deve essere utilizzata per convalidare il certificato e non fa tecnicamente parte dell’identificativo, bensì è utilizzata per verificare l’integrità del codice. Tale somma di controllo deve essere la sintesi secondo la norma ISO 7812-1 (LUHN-10) (4) dell’intero UCI in formato di trasporto digitale/elettronico. La somma di controllo è separata dal resto dell’UCI da un carattere «#».

Occorre garantire la retrocompatibilità: gli Stati membri che nel corso del tempo modificano la struttura dei loro identificativi (nella versione principale, attualmente fissata a v1) sono tenuti a garantire che due identificativi identici rappresentino la stessa dichiarazione/lo stesso certificato di vaccinazione. In altre parole, gli Stati membri non possono riciclare gli identificativi.

4.   Opzioni per gli identificativi univoci dei certificati per i certificati di vaccinazione

Gli orientamenti della rete eHealth per i certificati di vaccinazione verificabili e gli elementi fondamentali di interoperabilità (5) prevedono diverse opzioni a disposizione degli Stati membri e di altre parti che possono coesistere tra i diversi Stati membri. Gli Stati membri possono utilizzare tali diverse opzioni in versioni diverse dello schema UCI.

---

(1)  rfc3986 (ietf.org).

(2)  Campi quali il genere, il numero di lotto, il centro di somministrazione, l’identificazione dell’operatore sanitario, la data della prossima vaccinazione possono non essere necessari per scopi diversi dall’uso medico.

(3)  Per l’implementazione con codici QR, gli Stati membri potrebbero prendere in considerazione la possibilità di utilizzare una serie supplementare di caratteri fino a una lunghezza totale di 72 caratteri (compresi i 27-30 caratteri dell’identificativo stesso) per trasmettere altre informazioni. Spetta agli Stati membri definire la specifica di tali informazioni.

(4)  L’algoritmo di Luhn mod N è un’estensione dell’algoritmo di Luhn (noto anche come algoritmo mod 10) che funziona per i codici numerici ed è utilizzato ad esempio per calcolare la somma di controllo delle carte di credito. L’estensione consente all’algoritmo di funzionare con sequenze di valori su qualsiasi base (nel nostro caso caratteri alfa).

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

ALLEGATO IV

GOVERNANCE DEI CERTIFICATI A CHIAVE PUBBLICA

1.   Introduzione

Lo scambio sicuro e fidato delle chiavi di firma per i certificati COVID digitali dell’UE (DCC) tra gli Stati membri è realizzato dal gateway per i certificati COVID digitali dell’UE (Digital COVID Certificate Gateway — DCCG), che funge da archivio centrale per le chiavi pubbliche. Con il DCCG, gli Stati membri sono abilitati a pubblicare le chiavi pubbliche corrispondenti alle chiavi private che utilizzano per firmare i certificati COVID digitali. Gli Stati membri che se ne avvalgono possono utilizzare il DCCG per estrarre in tempo utile materiale aggiornato relativo alle chiavi pubbliche. Successivamente, il DCCG potrà essere esteso allo scambio di informazioni supplementari affidabili fornite dagli Stati membri, come le norme di convalida per i DCC. Il modello di fiducia del quadro DCC è un’infrastruttura a chiave pubblica (PKI). Ciascuno Stato membro mantiene una o più autorità nazionali di certificazione (CSCA) i cui certificati hanno una durata di vita relativamente lunga. A seguito della decisione dello Stato membro, la CSCA può essere uguale o diversa dalla CSCA utilizzata per i documenti di viaggio leggibili a macchina. La CSCA rilascia certificati a chiave pubblica per i firmatari di documenti nazionali di breve durata (ossia i firmatari dei DCC), denominati certificati di firma digitale (DSC). La CSCA agisce come un’ancora di fiducia in modo che gli Stati membri che se ne avvalgono possano utilizzare il certificato CSCA per convalidare l’autenticità e l’integrità dei DSC che cambiano regolarmente. Una volta effettuata la convalida, gli Stati membri possono fornire tali certificati (o solo le chiavi pubbliche in essi contenute) alle loro applicazioni di convalida dei DCC. Oltre alle CSCA e ai DSC, il DCCG si avvale anche della PKI per autenticare le transazioni, firmare i dati, come base per l’autenticazione e come mezzo per garantire l’integrità dei canali di comunicazione tra gli Stati membri e il DCCG.

Le firme digitali possono essere utilizzate per garantire l’integrità e l’autenticità dei dati. Le infrastrutture a chiave pubblica creano fiducia legando le chiavi pubbliche a identità verificate (o emittenti). Ciò è necessario per consentire agli altri partecipanti di verificare l’origine dei dati e l’identità del partner della comunicazione e di decidere in merito alla fiducia. Per l’autenticità, nel DCCG sono utilizzati diversi certificati a chiave pubblica. Il presente allegato definisce quali certificati a chiave pubblica sono utilizzati e come devono essere concepiti al fine di consentire un’ampia interoperabilità tra gli Stati membri. Esso fornisce maggiori dettagli sui necessari certificati a chiave pubblica, nonché orientamenti sui modelli di certificato e sui periodi di validità per gli Stati membri che intendono gestire una propria CSCA. Poiché i DCC devono essere verificabili per un periodo di tempo definito (a partire dal rilascio, scadono dopo un determinato periodo di tempo), è necessario definire un modello di verifica per tutte le firme applicate sui certificati a chiave pubblica e sui DCC.

2.   Terminologia

La tabella seguente riporta le abbreviazioni e la terminologia utilizzate in tutto il presente allegato.

Termine	Definizione
Certificato	O certificato a chiave pubblica. Un certificato X.509 v3 contenente la chiave pubblica di un’entità.
CSCA	Autorità nazionale di certificazione
DCC	Certificato COVID digitale dell’UE. Un documento digitale firmato contenente informazioni sulla vaccinazione, sul test o sulla guarigione.
DCCG	Gateway per i certificati COVID digitali dell’UE. Questo sistema è utilizzato per scambiare DSC tra gli Stati membri.
DCCGTA	Il certificato dell’ancora di fiducia del DCCG. La chiave privata corrispondente è utilizzata per firmare l’elenco di tutti i certificati CSCA off-line.
DCCGTLS	Il certificato del server TLS del DCCG
DSC	Certificato di firma digitale. Il certificato a chiave pubblica dell’autorità preposta alla firma dei documenti di uno Stato membro (ad esempio un sistema autorizzato a firmare i DCC). Tale certificato è rilasciato dalla CSCA dello Stato membro.
EC-DSA	Algoritmo di firma digitale su curva ellittica. Un algoritmo di firma crittografica basato su curve ellittiche.
Stato membro	Stato membro dell’Unione europea
mTLS	TLS reciproco. Il protocollo Transport Layer Security con autenticazione reciproca.
NB:	Back-end nazionale di uno Stato membro
NBCSCA	Il certificato CSCA di uno Stato membro (potrebbe essere più di uno)
NBTLS	Il certificato di autenticazione del client TLS di un back-end nazionale
NBUP	Il certificato utilizzato da un back-end nazionale per firmare pacchetti di dati caricati sul DCCG
PKI	Infrastruttura a chiave pubblica. Modello di fiducia basato su certificati a chiave pubblica e autorità di certificazione.
RSA	Algoritmo crittografico asimmetrico basato sulla fattorizzazione dei numeri interi utilizzato per le firme digitali o per la cifratura asimmetrica

3.   Flussi di comunicazione e servizi di sicurezza DCCG

Questa sezione fornisce una panoramica dei flussi di comunicazione e dei servizi di sicurezza nel sistema DCCG. Definisce inoltre quali chiavi e certificati sono utilizzati per proteggere la comunicazione, le informazioni caricate, i DCC e un elenco di fiducia firmato contenente tutti i certificati CSCA di cui è stato effettuato l’on-boarding. Il DCCG funge da hub di dati che consente lo scambio di pacchetti di dati firmati per gli Stati membri.

I pacchetti di dati caricati sono forniti dal DCCG «tal quali», il che significa che il DCCG non aggiunge né cancella i DSC dai pacchetti ricevuti. Il back-end nazionale (NB) degli Stati membri è abilitato a verificare l’integrità e l’autenticità end-to-end dei dati caricati. Inoltre i back-end nazionali e il DCCG utilizzeranno l’autenticazione TLS reciproca per stabilire una connessione sicura in aggiunta alle firme contenute nei dati scambiati.

3.1.   Autenticazione e creazione di connessioni

Il DCCG utilizza il protocollo Transport Layer Security (TLS) con autenticazione reciproca per stabilire un canale criptato autenticato tra il back-end nazionale (NB) dello Stato membro e l’ambiente gateway. Pertanto il DCCG detiene un certificato del server TLS, abbreviato DCCGTLS, mentre i back-end nazionali detengono un certificato del client TLS, abbreviato NBTLS. I modelli di certificato sono forniti nella sezione 5. Ogni back-end nazionale può fornire il proprio certificato TLS. Tale certificato sarà esplicitamente inserito in una lista bianca e potrà quindi essere rilasciato da un’autorità di certificazione pubblicamente riconosciuta (ad esempio un’autorità di certificazione che segue i requisiti di base del CA/Browser Forum), da un’autorità nazionale di certificazione o potrà essere autofirmato. Ciascuno Stato membro è responsabile dei propri dati nazionali e della protezione della chiave privata utilizzata per stabilire la connessione con il DCCG. L’approccio «presenta il tuo certificato» richiede una procedura ben definita di registrazione e identificazione, nonché procedure di revoca e rinnovo come descritto nelle sezioni 4.1, 4.2 e 4.3. Il DCCG utilizza una lista bianca in cui vengono aggiunti i certificati TLS dei back-end nazionali dopo l’avvenuta registrazione. Solo i back-end nazionali che si autenticano con una chiave privata corrispondente a un certificato della lista bianca possono stabilire una connessione sicura con il DCCG. Il DCCG utilizzerà anche un certificato TLS che consenta ai back-end nazionali di verificare che stiano effettivamente stabilendo una connessione con il «vero» DCCG e non con qualche entità malevola che si fa passare per il DCCG. Il certificato del DCCG sarà fornito ai back-end nazionali una volta effettuata la registrazione. Il certificato DCCGTLS sarà rilasciato da un’autorità di certificazione pubblicamente riconosciuta (anche in tutti i principali browser). Spetta agli Stati membri verificare che la loro connessione al DCCG sia sicura (ad esempio, controllando l’impronta digitale del certificato DCCGTLS del server collegato rispetto a quella fornita dopo la registrazione).

3.2.   Autorità nazionali di certificazione e modello di convalida

Gli Stati membri che partecipano al quadro DCCG sono tenuti ad avvalersi di una CSCA per il rilascio dei DSC. Gli Stati membri possono avere più di una CSCA, ad esempio in caso di decentramento regionale. Ciascuno Stato membro può avvalersi delle autorità di certificazione esistenti oppure istituire un’apposita autorità di certificazione (eventualmente autofirmata) per il sistema DCC.

Gli Stati membri devono presentare il certificato o i certificati CSCA all’operatore del DCCG durante la procedura ufficiale di on-boarding. Dopo l’avvenuta registrazione dello Stato membro (cfr. la sezione 4.1 per maggiori dettagli), l’operatore del DCCG aggiornerà un elenco di fiducia firmato contenente tutti i certificati CSCA attivi nel quadro del DCC. L’operatore del DCCG utilizzerà un’apposita coppia di chiavi asimmetriche per firmare l’elenco di fiducia e i certificati in ambiente off-line. La chiave privata non sarà memorizzata nel sistema DCCG on line per evitare che una compromissione del sistema on line consenta a un aggressore di compromettere l’elenco di fiducia. Il corrispondente certificato dell’ancora di fiducia DCCGTA sarà fornito ai back-end nazionali durante la procedura di on-boarding.

Gli Stati membri possono recuperare l’elenco di fiducia dal DCCG per le loro procedure di verifica. La CSCA è definita come l’autorità di certificazione che rilascia i DSC, per cui gli Stati membri che utilizzano una gerarchia di autorità di certificazione a più livelli (ad esempio, autorità di certificazione radice -> CSCA -> DSC) devono indicare l’autorità di certificazione subordinata che rilascia i DSC. In questo caso, se uno Stato membro si avvale di un’autorità di certificazione esistente, il sistema DCC ignorerà tutto ciò che è al di sopra della CSCA e inserirà nella lista bianca solo la CSCA come ancora di fiducia (anche se si tratta di un’autorità di certificazione subordinata). Ciò è dovuto al fatto che nel modello ICAO sono consentiti solo 2 livelli: una CSCA «radice» e un DSC «foglia» firmato solo da tale CSCA.

Nel caso in cui uno Stato membro gestisca la propria CSCA, tale Stato membro è responsabile del funzionamento sicuro e della gestione delle chiavi di tale autorità. La CSCA funge da ancora di fiducia per i DSC e pertanto la protezione della chiave privata della CSCA è essenziale per l’integrità dell’ambiente DCC. Il modello di verifica nella PKI DCC è il modello a strati, in base al quale tutti i certificati nella convalida del percorso del certificato devono essere validi in un determinato momento (ossia al momento della convalida della firma). Si applicano pertanto le restrizioni seguenti:

—	la CSCA non rilascia certificati con periodo di validità superiore a quello del certificato dell’autorità di certificazione stesso;

—	il firmatario del documento non firma documenti con periodo di validità superiore a quello del DSC stesso;

—	gli Stati membri che gestiscono la propria CSCA sono tenuti a definire i periodi di validità della loro CSCA e di tutti i certificati rilasciati e devono provvedere al loro rinnovo.

La sezione 4.2 contiene raccomandazioni per i periodi di validità.

3.3.   Integrità e autenticità dei dati caricati

I back-end nazionali possono utilizzare il DCCG per caricare e scaricare pacchetti di dati firmati digitalmente dopo l’avvenuta autenticazione reciproca. All’inizio, questi pacchetti di dati contengono i DSC degli Stati membri. La coppia di chiavi utilizzata dal back-end nazionale per la firma digitale dei pacchetti di dati caricati nel sistema DCCG è denominata coppia di chiavi di firma per il caricamento da parte del back-end nazionale e il corrispondente certificato a chiave pubblica è abbreviato con certificato NBUP. Ciascuno Stato membro presenta il proprio certificato NBUP, che può essere autofirmato o rilasciato da un’autorità di certificazione esistente, come un’autorità pubblica di certificazione (ossia un’autorità di certificazione che rilascia certificati conformemente ai requisiti di base del CA/Browser Forum). Il certificato NBUP è diverso da qualsiasi altro certificato utilizzato dallo Stato membro (ossia CSCA, client TLS o DSC).

Gli Stati membri devono fornire il certificato di caricamento all’operatore del DCCG durante la procedura di registrazione iniziale (cfr. la sezione 4.1 per maggiori dettagli). Ciascuno Stato membro è responsabile dei propri dati nazionali ed è tenuto a proteggere la chiave privata utilizzata per firmare i caricamenti.

Gli altri Stati membri possono verificare i pacchetti di dati firmati utilizzando i certificati di caricamento forniti dal DCCG. Il DCCG verifica l’autenticità e l’integrità dei dati caricati con il certificato di caricamento del back-end nazionale prima che siano forniti agli altri Stati membri.

3.4.   Requisiti relativi all’architettura tecnica del DCCG

I requisiti relativi all’architettura tecnica del DCCG sono i seguenti:

—	il DCCG utilizza l’autenticazione TLS reciproca per stabilire una connessione criptata autenticata con i back-end nazionali. Pertanto il DCCG tiene una lista bianca dei certificati del client NBTLS registrati;

—	il DCCG utilizza due certificati digitali (DCCGTLS e DCCGTA) con due coppie di chiavi distinte. La chiave privata della coppia di chiavi DCCGTA è mantenuta off-line (non sulle componenti on line del DCCG);

—	il DCCG tiene un elenco di fiducia dei certificati NBCSCA firmati con la chiave privata DCCGTA;

—	le cifrature utilizzate devono soddisfare i requisiti della sezione 5.1.

4.   Gestione del ciclo di vita del certificato

4.1.   Registrazione dei back-end nazionali

Per partecipare al sistema DCCG, gli Stati membri devono registrarsi presso l’operatore del DCCG. Questa sezione descrive la procedura tecnica e operativa da seguire per registrare un back-end nazionale.

L’operatore del DCCG e lo Stato membro devono scambiarsi informazioni sui referenti tecnici per la procedura di on-boarding. Si presume che i referenti tecnici siano legittimati dai rispettivi Stati membri e che l’identificazione/autenticazione avvenga attraverso altri canali. Ad esempio, l’autenticazione può essere ottenuta quando il referente tecnico di uno Stato membro fornisce i certificati sotto forma di file criptati con password via e-mail e condivide la password corrispondente con l’operatore del DCCG per telefono. Possono essere utilizzati anche altri canali sicuri definiti dall’operatore del DCCG.

Lo Stato membro deve fornire tre certificati digitali durante il processo di registrazione e identificazione:

—	il certificato TLS dello Stato membro NBTLS;

—	il certificato di caricamento dello Stato membro NBUP;

—	il certificato o i certificati CSCA dello Stato membro NBCSCA.

Tutti i certificati forniti devono soddisfare i requisiti definiti nella sezione 5. L’operatore del DCCG verificherà che il certificato fornito sia conforme ai requisiti della sezione 5. Dopo l’identificazione e la registrazione, l’operatore del DCCG:

—	aggiunge il certificato o i certificati NBCSCA all’elenco di fiducia firmato con la chiave privata che corrisponde alla chiave pubblica DCCGTA;

—	aggiunge il certificato NBTLS alla lista bianca dell’endpoint TLS del DCCG;

—	aggiunge il certificato NBUP al sistema DCCG;

—	fornisce allo Stato membro il certificato a chiave pubblica DCCGTA e DCCGTLS.

4.2.   Autorità di certificazione, periodi di validità e rinnovo

Nel caso in cui uno Stato membro intenda gestire la propria CSCA, i certificati CSCA possono essere autofirmati. Essi fungono da ancora di fiducia dello Stato membro e pertanto lo Stato membro deve proteggere con forza la chiave privata corrispondente alla chiave pubblica del certificato CSCA. Si raccomanda agli Stati membri di utilizzare un sistema off-line per la loro CSCA, ossia un sistema informatico non connesso ad alcuna rete. Per accedere al sistema si utilizza un controllo multi-persona (ad esempio, secondo il principio del doppio controllo). Dopo la firma dei DSC sono effettuati controlli operativi e il sistema che detiene la chiave CSCA privata è conservato in condizioni di sicurezza con forti controlli d’accesso. Per proteggere ulteriormente la chiave CSCA privata si possono utilizzare moduli di sicurezza hardware o carte intelligenti. I certificati digitali contengono un periodo di validità che impone il rinnovo del certificato. Il rinnovo è necessario per utilizzare nuove chiavi crittografiche e per adattare le dimensioni delle chiavi nel caso di nuovi miglioramenti nel calcolo o quando nuovi attacchi minacciano la sicurezza dell’algoritmo crittografico utilizzato. Si applica il modello a strati (cfr. la sezione 3.2).

Data la validità di un anno dei certificati COVID digitali, si raccomandano i periodi di validità seguenti:

—	CSCA: 4 anni

—	DSC: 2 anni

—	Caricamento: 1-2 anni

—	Autenticazione del client TLS: 1-2 anni

Ai fini di un rinnovo tempestivo, si raccomandano i periodi di utilizzo seguenti per le chiavi private:

—	CSCA: 1 anno

—	DSC: 6 mesi

Gli Stati membri devono creare tempestivamente nuovi certificati di caricamento e certificati TLS, ad esempio un mese prima della scadenza, al fine di consentire il corretto funzionamento. I certificati CSCA e i DSC dovrebbero essere rinnovati almeno un mese prima della fine dell’utilizzo della chiave privata (tenendo conto delle necessarie procedure operative). Gli Stati membri devono fornire certificati CSCA, certificati di caricamento e TLS aggiornati all’operatore del DCCG. I certificati scaduti sono rimossi dalla lista bianca e dall’elenco di fiducia.

Gli Stati membri e l’operatore del DCCG devono tenere traccia della validità dei propri certificati. Non esiste un’entità centrale che tenga traccia della validità dei certificati e che informi i partecipanti.

4.3.   Revoca dei certificati

In generale, i certificati digitali possono essere revocati dall’autorità di certificazione che li ha rilasciati utilizzando elenchi dei certificati revocati o il responder Online Certificate Status Protocol (OCSP). Le CSCA per il sistema DCC dovrebbero fornire elenchi dei certificati revocati (CRL). Anche se tali CRL non sono attualmente utilizzati da altri Stati membri, essi dovrebbero essere integrati per le applicazioni future. Se una CSCA decide di non fornire CRL, i DSC di tale CSCA dovranno essere rinnovati quando i CRL diventeranno obbligatori. Per la convalida dei DSC, i verificatori non dovrebbero utilizzare l’OCSP ma i CRL. Si raccomanda che il back-end nazionale esegua la necessaria convalida dei DSC scaricati dal DCCG e che trasmetta ai validatori DCC nazionali solo una serie di DSC fidati e convalidati. I validatori DCC non dovrebbero effettuare alcun controllo delle revoche dei DSC nel loro processo di convalida. Uno dei motivi è proteggere la vita privata dei titolari di DCC evitando ogni possibilità che l’uso di un determinato DSC possa essere monitorato dal suo responder OCSP associato.

Gli Stati membri possono rimuovere autonomamente i propri DSC dal DCCG utilizzando certificati di caricamento e TLS validi. Rimuovendo un DSC, tutti i DCC rilasciati con tale DSC non saranno più validi quando gli Stati membri estrarranno gli elenchi di DSC aggiornati. La protezione del materiale relativo alle chiavi private corrispondenti ai DSC è fondamentale. Gli Stati membri sono tenuti a informare l’operatore del DCCG quando devono revocare i certificati di caricamento o TLS, ad esempio a causa della compromissione del back-end nazionale. L’operatore del DCCG può quindi togliere la fiducia per il certificato in questione, ad esempio rimuovendolo dalla lista bianca TLS. L’operatore del DCCG può rimuovere i certificati di caricamento dalla banca dati del DCCG. I pacchetti firmati con la chiave privata corrispondente a questo certificato di caricamento non saranno più validi quando i back-end nazionali toglieranno la fiducia per il certificato di caricamento revocato. Qualora un certificato CSCA debba essere revocato, gli Stati membri informano l’operatore del DCCG e gli altri Stati membri con cui hanno rapporti di fiducia. L’operatore del DCCG rilascerà un nuovo elenco di fiducia in cui il certificato in questione non sarà più presente. Tutti i DSC rilasciati da tale CSCA non saranno più validi nel momento in cui gli Stati membri aggiorneranno il trust store del loro back-end nazionale. Nel caso in cui il certificato DCCGTLS o il certificato DCCGTA debba essere revocato, l’operatore del DCCG e gli Stati membri devono collaborare per stabilire una nuova connessione TLS fidata e un nuovo elenco di fiducia.

5.   Modelli di certificato

Questa sezione stabilisce i requisiti crittografici, i relativi orientamenti e i requisiti dei modelli di certificato. Per i certificati del DCCG, questa sezione definisce i modelli di certificato.

5.1.   Requisiti crittografici

Gli algoritmi crittografici e le suite di cifratura TLS sono scelti sulla base delle attuali raccomandazioni dell’Ufficio federale tedesco per la sicurezza delle informazioni (BSI) o del SOGIS. Tali raccomandazioni e le raccomandazioni di altre istituzioni e organismi di normazione sono simili. Le raccomandazioni sono contenute negli orientamenti tecnici TR 02102-1 e TR 02102-2 (1) o nei meccanismi crittografici concordati dal SOGIS (2).

5.1.1.   Requisiti relativi al DSC

Si applicano i requisiti di cui all’allegato I, sezione 3.2.2. Si raccomanda pertanto vivamente ai firmatari dei documenti di utilizzare l’algoritmo di firma digitale su curva ellittica (ECDSA) con NIST-p-256 (come definito nell’appendice D di FIPS PUB 186-4). Altre curve ellittiche non sono supportate. A causa dei limiti di spazio del DCC, gli Stati membri non dovrebbero utilizzare l’algoritmo RSA-PSS, anche se consentito come algoritmo di riserva. Nel caso in cui gli Stati membri utilizzino l’algoritmo RSA-PSS, dovrebbero utilizzare un modulo di dimensioni pari a 2048 o al massimo 3072 bit. L’algoritmo SHA-2 con una lunghezza di output ≥ 256 bit è utilizzato come funzione di hash crittografico (cfr. ISO/IEC 10118-3:2004) per la firma del DSC.

5.1.2.   Requisiti per certificati TLS, di caricamento e CSCA

Per i certificati digitali e le firme crittografiche nel contesto del DCCG, i principali requisiti relativi agli algoritmi crittografici e alla lunghezza della chiave sono riassunti nella tabella seguente (a partire dal 2021):

Algoritmo di firma	Dimensioni della chiave	Funzione di hash
EC-DSA	Min. 250 bit	SHA-2 con lunghezza di output ≥ 256 bit
RSA-PSS (riempimento raccomandato) RSA-PKCS#1 v1.5 (riempimento preesistente)	Modulo RSA (N) da min. 3000 bit con esponente pubblico e > 2^16	SHA-2 con lunghezza di output ≥ 256 bit
DSA	Numero primo p da min. 3000 bit, chiave q da 250 bit	SHA-2 con lunghezza di output ≥ 256 bit

La curva ellittica raccomandata per l’algoritmo EC-DSA è NIST-p-256 a causa della sua applicazione diffusa.

5.2.   Certificato CSCA (NBCSCA)

La tabella seguente fornisce indicazioni sul modello di certificato NBCSCA se uno Stato membro decide di gestire la propria CSCA per il sistema DCC.

Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

Campo	Valore
Subject (Soggetto)	cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro che gestisce la CSCA>
Key usage (Utilizzo della chiave)	certificate signing (firma del certificato), CRL signing (firma del CRL) (come minimo)
Basic Constraints (Limitazioni di base)	CA = true (vero), path length constraints (limiti di lunghezza del percorso) = 0

Il nome del soggetto deve essere univoco e non vuoto all’interno dello Stato membro specificato. Il codice paese (c) deve corrispondere allo Stato membro che si avvarrà di questo certificato CSCA. Il certificato deve contenere un identificativo della chiave del soggetto (Subject Key Identifier — SKI) univoco conformemente a RFC 5280 (3).

5.3.   Certificato di firma digitale (DSC)

La tabella seguente fornisce indicazioni sul DSC. Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

Campo	Valore
Serial Number (Numero di serie)	numero di serie univoco
Subject (Soggetto)	cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro che utilizza il DSC>
Key Usage (Utilizzo della chiave)	digital signature (firma digitale) (come minimo)

Il DSC deve essere firmato con la chiave privata corrispondente a un certificato CSCA utilizzato dallo Stato membro.

Devono essere utilizzate le estensioni seguenti:

—	il certificato deve contenere un identificativo della chiave dell’autorità (Authority Key Identifier — AKI) corrispondente all’identificativo della chiave del soggetto (SKI) del certificato della CSCA emittente;

—	il certificato dovrebbe contenere un identificativo della chiave del soggetto univoco (conformemente a RFC 5280 (4)).

Inoltre il certificato dovrebbe contenere l’estensione del punto di distribuzione del CRL che indica l’elenco dei certificati revocati (CRL) fornito dalla CSCA che ha rilasciato il DSC.

Il DSC può contenere un’estensione dell’utilizzo esteso della chiave con zero o più identificativi di policy sull’utilizzo della chiave che limitano i tipi di HCERT che il certificato è autorizzato a verificare. In presenza di una o più estensioni, i verificatori verificano l’utilizzo della chiave confrontandola con l’HCERT memorizzato. A tal fine sono definiti i valori extendedKeyUsage (utilizzo esteso della chiave) seguenti:

Campo	Valore
extendedKeyUsage (utilizzo esteso della chiave)	1.3.6.1.4.1.1847.2021.1.1 per i soggetti che rilasciano certificati di test
extendedKeyUsage (utilizzo esteso della chiave)	1.3.6.1.4.1.1847.2021.1.2 per i soggetti che rilasciano certificati di vaccinazione
extendedKeyUsage (utilizzo esteso della chiave)	1.3.6.1.4.1.1847.2021.1.3 per i soggetti che rilasciano certificati di guarigione

In mancanza di un’estensione dell’utilizzo della chiave (ossia nessuna estensione o zero estensioni), questo certificato può essere utilizzato per convalidare qualsiasi tipo di HCERT. Altri documenti possono definire ulteriori identificativi di policy sull’utilizzo esteso della chiave utilizzati per la convalida degli HCERT.

5.4.   Certificati di caricamento (NBUP)

La tabella seguente fornisce indicazioni per il certificato di caricamento del back-end nazionale. Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

Campo	Valore
Subject (Soggetto)	cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro che utilizza il certificato di caricamento>
Key Usage (Utilizzo della chiave)	digital signature (firma digitale) (come minimo)

5.5.   Autenticazione del client TLS del back-end nazionale (NBTLS)

La tabella seguente fornisce indicazioni per il certificato di autenticazione del client TLS del back-end nazionale. Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

Campo	Valore
Subject (Soggetto)	cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro sul back-end nazionale>
Key Usage (Utilizzo della chiave)	digital signature (firma digitale) (come minimo)
Extended key usage (Utilizzo esteso della chiave)	client authentication (autenticazione del client) (1.3.6.1.5.5.7.3.2)

Il certificato può, ma non necessariamente deve, contenere anche server authentication (autenticazione del server) (1.3.6.1.5.5.7.3.1) per l’utilizzo esteso della chiave.

5.6.   Certificato di firma dell’elenco di fiducia (DCCGTA)

La tabella seguente definisce il certificato dell’ancora di fiducia del DCCG.

Campo	Valore
Subject (Soggetto)	cn = Digital Green Certificate Gateway (gateway per i certificati verdi digitali) (5) , o=<fornitore>, c=<paese>
Key Usage (Utilizzo della chiave)	digital signature (firma digitale) (come minimo)

5.7.   Certificati del server TLS del DCCG (DCCGTLS)

La tabella seguente definisce il certificato TLS del DCCG.

Campo	Valore
Subject (Soggetto)	cn=<FQDN o indirizzo IP del DCCG>, o=<fornitore>, c=<paese>
SubjectAltName (Nome alternativo del soggetto)	dNSName: <nome DNS del DCCG> o iPAddress: <indirizzo IP del DCCG>
Key Usage (Utilizzo della chiave)	digital signature (firma digitale) (come minimo)
Extended Key usage (Utilizzo esteso della chiave)	server authentication (autenticazione del server) (1.3.6.1.5.5.7.3.1)

Il certificato può, ma non necessariamente deve, contenere anche client authentication (autenticazione del client) (1.3.6.1.5.5.7.3.2) per l’utilizzo esteso della chiave.

Il certificato TLS del DCCG è rilasciato da un’autorità di certificazione pubblicamente riconosciuta (anche in tutti i principali browser e sistemi operativi, conformemente ai requisiti di base del CA/Browser Forum).

---

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

(2)  SOGIS - Supporting documents (sogis.eu).

(3)  rfc5280 (ietf.org).

(4)  rfc5280 (ietf.org).

(5)  La terminologia «certificato verde digitale» anziché «certificato COVID digitale dell’UE» è stata mantenuta in questo contesto perché è questa la terminologia che è stata codificata in modo fisso e utilizzata nel certificato prima che i colegislatori decidessero di modificarla.