Articolul 1

Articolul 58 din Regulamentul (UE) 2016/1628 se modifică după cum urmează:

1.

La alineatul (5) se adaugă următorul paragraf: „Pentru motoarele din toate subcategoriile pentru care data stabilită în anexa III pentru introducerea pe piață a motoarelor din etapa V este 1 ianuarie 2020, cu excepția motoarelor menționate la al doilea și al treilea paragraf, perioada de tranziție se prelungește cu nouă luni, iar perioada de 18 luni menționată la primul paragraf se prelungește cu șase luni.”

2.	La alineatul (7) se adaugă următoarea literă: „(e) 33 de luni de la data aplicabilă pentru introducerea pe piață a motoarelor prevăzute în anexa III, în situația menționată la alineatul (5) al șaselea paragraf.”

Articolul 2

Prezentul regulament intră în vigoare la data publicării în Jurnalul Oficial al Uniunii Europene.

Articolul 1

Modificarea Regulamentului (UE) 2020/1579

Regulamentul (UE) 2020/1579 se modifică în conformitate cu partea A din anexa la prezentul regulament.

Articolul 2

Modificarea Regulamentului (UE) 2021/92

Regulamentul (UE) 2021/92 se modifică în conformitate cu părțile B și C din anexa la prezentul regulament.

Articolul 3

Intrare în vigoare și aplicare

Prezentul regulament intră în vigoare în ziua următoare datei publicării în Jurnalul Oficial al Uniunii Europene.

Articolul 1 se aplică de la 1 ianuarie 2021.

Articolul 2 se aplică de la 1 iulie 2021.

ANEXĂ

PARTEA A

În anexa la Regulamentul (UE) 2020/1579, tabelul cu posibilitățile de pescuit pentru hering în subdiviziunile ICES 30-31 se înlocuiește cu următorul tabel:

PARTEA B

Anexa IA la Regulamentul (UE) 2021/92 se modifică după cum urmează:

1.

Tabelul referitor la posibilitățile de pescuit pentru șprot și capturi accidentale asociate în apele Uniunii din diviziunea ICES 3a se înlocuiește cu următorul tabel: „Specia: Șprot și capturi accidentale asociate Sprattus sprattus Zona: 3a (SPR/03A.) Danemarca 13 086  (1)  (2) TAC analitică” Germania 27  (1)  (2) Suedia 4 951  (1)  (2) Uniune 18 064  (1)  (2)   TAC 19 529  (2)

2.

Tabelul referitor la posibilitățile de pescuit pentru șprot și capturi accidentale asociate în apele Regatului Unit și apele Uniunii din subzona ICES 4 și în apele Regatului Unit din diviziunea ICES 2a se înlocuiește cu următorul tabel: „Specia: Șprot și capturi accidentale asociate Sprattus sprattus Zona: apele Regatului Unit și apele Uniunii din subzona 4; apele Regatului Unit din diviziunea 2a (SPR/2AC4-C) Belgia 993  (3)  (4) TAC analitică Danemarca 78 553  (3)  (4) Germania 993  (3)  (4) Franța 993  (3)  (4) Țările de Jos 993  (3)  (4) Suedia 1 330  (3)  (4)  (5) Uniune 83 855  (3)  (4) Norvegia 0  (3) Insulele Feroe 0  (3)  (6) Regatul Unit 3 331  (3)   TAC 87 186  (3)

3.

Tabelul referitor la posibilitățile de pescuit pentru hamsie în subzonele ICES 9 și 10 și în apele Uniunii din diviziunea CECAF 34.1.1 se înlocuiește cu următorul tabel: „Specia: Hamsie Engraulis encrasicolus Zona: 9 și 10; apele Uniunii din zona CECAF 34.1.1 (ANE/9/3411) Spania 2 747  (7) TAC de precauție Portugalia 2 997  (7) Uniune 5 744  (7)   TAC 5 744  (7)

PARTEA C

În anexa VI la Regulamentul (UE) 2021/92, punctul 6 se înlocuiește cu următorul text:

„6.

Capacitatea maximă de creștere și de îngrășare a tonului roșu pentru fiecare stat membru și volumul maxim al intrărilor de ton roșu sălbatic capturat pe care fiecare stat membru îl poate repartiza fermelor sale piscicole din estul Oceanului Atlantic și din Marea Mediterană Tabelul A Capacitatea maximă de creștere și de îngrășare a tonului roșu   Număr de ferme Capacitate (în tone) Spania 10 11 852 Italia 13 9 564 Grecia 2 2 100 Cipru 3 3 000 Croația 7 7 880 Malta 6 14 511 Tabelul B  (8) Volumul maxim al intrărilor de ton roșu sălbatic capturat (în tone) Spania 6 850 Italia 1 739,5 Grecia 785 Cipru 2 195 Croația 2 947 Malta 10 260,5 Portugalia 350

---

(1)  Până la 5 % din cotă poate consta în capturi accidentale de merlan și de eglefin (OTH/*03A.). Capturile accidentale de merlan și eglefin deduse din cotă în conformitate cu prezenta dispoziție și capturile accidentale de specii deduse din cotă în conformitate cu prezenta dispoziție din cotă în temeiul articolului 15 alineatul (8) din Regulamentul (UE) nr. 1380/2013 nu depășesc, în total, 9 % din cotă.

(2)  Această cotă poate fi pescuită doar între 1 iulie 2021 și 30 iunie 2022. Se pot realiza transferuri din această cotă către apele Regatului Unit și apele Uniunii din zonele 2a și 4. Cu toate acestea, orice transfer de acest gen trebuie comunicat în prealabil Comisiei și Regatului Unit.”

(3)  Cota poate fi pescuită doar între 1 iulie 2021 și 30 iunie 2022.

(4)  Până la 2 % din cotă poate consta în capturi accidentale de merlan (OTH/*2AC4C). Capturile accidentale de merlan deduse din cotă în conformitate cu prezenta dispoziție și capturile accidentale de specii deduse din cotă în temeiul articolului 15 alineatul (8) din Regulamentul (UE) nr. 1380/2013 nu depășesc, în total, 9 % din cotă.

(5)  Inclusiv uva.

(6)  Poate conține maximum 4 % capturi accidentale de hering.”

(7)  Cota poate fi pescuită doar între 1 iulie 2021 și 30 septembrie 2021.”

(8)  Capacitatea de creștere a Portugaliei, de 500 de tone, este acoperită de capacitatea neutilizată a Uniunii înscrisă în tabelul A.”

Articolul 1

Obiect și domeniu de aplicare

Prezentul regulament stabilește măsuri speciale de control al bolilor pentru combaterea infecției cu virusul dermatozei nodulare contagioase (VDNC) care trebuie aplicate pentru o perioadă limitată de timp de către toate statele membre în zonele din teritoriul lor unde:

(a)	a fost confirmat un focar al bolii respective;

(b)	nu a fost confirmat un focar al bolii respective, dar decid să efectueze vaccinarea împotriva bolii respective în conformitate cu normele stabilite în prezentul regulament.

Măsurile speciale de control al bolilor stabilite în prezentul regulament se aplică bovinelor și subproduselor și materialului germinativ obținute de la bovinele respective și vin în completarea măsurilor speciale de control al bolilor aplicabile în zonele de protecție, zonele de supraveghere, și zonele suplimentare de restricții instituite de autoritatea competentă dintr-un stat membru ulterior apariției unui focar de infecție cu VDNC, în conformitate cu articolul 21 alineatul (1) din Regulamentul delegat (UE) 2020/687.

Articolul 2

Definiții

În sensul prezentului regulament, se aplică definițiile stabilite în Regulamentul delegat (UE) 2020/687.

În plus, se aplică și următoarele definiții:

1.	„bovină” înseamnă un animal din speciile de ungulate care aparțin speciilor Bison, Bos (inclusiv subgenul Bos, Bibos, Novibos, Poephagus) și Bubalus (inclusiv subgenul Anoa) și descendenții rezultați din încrucișările acestor specii;

2.

„zonă de restricții de categoria I” înseamnă o parte din teritoriul unui stat membru, având o delimitare geografică precisă: (a) situată în afara unei zone în care a fost confirmat un focar de infecție cu VDNC; (b) în care vaccinarea împotriva infecției cu VDNC se efectuează în conformitate cu articolul 3 alineatul (2); (c) enumerată sau nu în anexa I partea I; (d) care face obiectul normelor speciale de control al bolilor prevăzute la articolele 3-6;

3.

„zonă de restricții de categoria II” înseamnă o parte din teritoriul unui stat membru, având o delimitare geografică precisă: (a) care include o zonă în care a fost confirmat un focar de infecție cu VDNC; (b) în care vaccinarea împotriva infecției cu VDNC se efectuează în conformitate cu articolul 3 alineatul (1); (c) enumerată sau nu în anexa I partea II; (d) care face obiectul normelor speciale de control al bolilor prevăzute la articolele 3-6.

Articolul 3

Stabilirea zonelor de restricții de categoria I și II

Articolul 4

Interdicții de circulație în zonele de restricții de categoria I și II

Articolul 5

Includerea zonei de restricții de categoria II în anexa I partea II

În cazul în care, din motive epidemiologice, o zonă a unui stat membru acoperită total sau parțial de o zonă de restricții de categoria II stabilită în conformitate cu articolul 3 alineatul (1) este inclusă în partea II din anexa I, autoritatea competentă va acționa imediat pentru:

(a)	a adapta limitele zonei de restricții inițiale de categoria II pentru a se asigura că aceasta corespunde zonei de restricții de categoria II descrise în anexa respectivă;

(b)	a extinde vaccinarea prevăzută la articolul 3 alineatul (1) litera (b) și interdicțiile prevăzute la articolul 4 alineatul (1) la zona de restricții de categoria II descrisă în anexa respectivă.

Articolul 6

Includerea zonei de restricții de categoria I în anexa I partea I

Articolul 7

Derogări de la interdicția de circulație a transporturilor de bovine din zona de restricții de categoria I

Prin derogări de la interdicția prevăzută la articolul 4 alineatul (2) litera (a), autoritatea competentă poate autoriza circulația transporturilor de bovine din unități situate în zona de restricții de categoria I către:

(a)

o zonă de restricții de categoria I sau II din același stat membru sau din alt stat membru, dacă sunt îndeplinite toate condițiile următoare: (i) bovinele transportate trebuie să fi fost vaccinate împotriva infecției cu VDNC cu cel puțin 28 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la acea dată; (ii) toate celelalte bovine deținute în aceeași unitate de origine ca bovinele transportate trebuie să fi fost vaccinate împotriva infecției cu VDNC cu cel puțin 28 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la acea dată sau să se afle în perioada de imunitate indusă de vaccinarea anterioară sau de imunitatea maternă la data expedierii; (iii) bovinele transportate trebuie să fi fost ținute în unitatea de origine de la naștere sau pentru o perioadă continuă de cel puțin 28 de zile înainte de data expedierii; și (iv) autoritatea competentă efectuează: — o examinare clinică, cu rezultate favorabile, a tuturor bovinelor deținute în unitatea de origine a transporturilor respective, inclusiv a bovinelor transportate; — dacă este necesar, un examen de laborator, cu rezultate favorabile, al bovinelor deținute în unitatea de origine a transporturilor respective, inclusiv al bovinelor transportate;

(b)

orice destinație - inclusiv zonele din afara zonelor de restricții, alte zone de restricții de categoria I, zone de restricții de categoria II – din același stat membru sau din alte state membre, dacă, pe lângă condițiile prevăzute la litera (a) punctele (ii), (iii) și (iv) din prezentul articol, sunt îndeplinite toate condițiile următoare: (i) bovinele transportate trebuie să fi fost vaccinate împotriva infecției cu VDNC cu cel puțin 60 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la data expedierii; (ii) pe o rază de cel puțin 20 km în jurul unității de origine a unor astfel de transporturi nu au existat focare de infecție cu VDNC în cursul unei perioade de cel puțin trei luni înainte de data expedierii; și (iii) toate bovinele deținute pe o rază de 50 km în jurul unității de origine a transportului trebuie să fi fost vaccinate sau revaccinate împotriva infecției cu VDNC cel puțin 60 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la acea dată sau în perioada de imunitate maternă;

(c)

orice destinație – inclusiv zonele din afara zonelor de restricții, alte zone de restricții de categoria I sau zone de restricții de categoria II – din alte state membre sau din teritorii din țări terțe, în cazul în care, pe lângă condițiile prevăzute la litera (a) din prezentul articol, sunt îndeplinite condițiile următoare: (i) animalele trebuie să îndeplinească orice garanții în materie de sănătate animală, pe baza unui rezultat favorabil al unei evaluări a riscurilor privind măsurile de combatere a răspândirii infecției cu VDNC, care a fost solicitată de autoritatea competentă din statul membru de origine și aprobată de autoritatea competentă din statele membre de destinație și de tranzit, înainte de data expedierii; (ii) trebuie să nu fi existat focare confirmate de infecție cu VDNC pe o rază de cel puțin 20 km în jurul unității de origine a unor astfel de transporturi în cursul unei perioade de cel puțin trei luni înainte de data expedierii; și (iii) toate bovinele deținute pe o rază de 50 km în jurul unității de origine a transportului trebuie să fi fost vaccinate sau revaccinate împotriva infecției cu VDNC cel puțin 60 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la acea dată sau în perioada de imunitate maternă.

Articolul 8

Derogări de la interdicțiile de circulație a transporturilor de bovine din zona de restricții de categoria II

Prin derogări de la interdicția prevăzută la articolul 4 alineatul (1) litera (a), autoritatea competentă poate autoriza circulația transporturilor de bovine din unități aflate în zona de restricții de categoria II către:

(a)

orice destinație, inclusiv zonele situate în afara zonelor de restricții, zonele de restricții de categoria I, alte zone de restricții de categoria II din același stat membru și din alte state membre, sub rezerva îndeplinirii cumulative a următoarelor condiții: (i) bovinele transportate trebuie să îndeplinească orice garanții în materie de sănătate animală, pe baza unui rezultat favorabil al unei evaluări a riscurilor privind măsurile de combatere a răspândirii infecției cu VDNC, care a fost solicitată de autoritatea competentă din statul membru de origine și convenită cu autoritatea competentă din statele membre de destinație și de tranzit, înainte de data expedierii; (ii) bovinele transportate trebuie să fi fost vaccinate împotriva infecției cu VDNC cu cel puțin 28 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la acea dată; (iii) toate celelalte bovine deținute în aceeași unitate de origine ca bovinele transportate trebuie să fi fost vaccinate împotriva infecției cu VDNC cu cel puțin 28 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la acea dată sau să se afle în perioada de imunitate indusă de vaccinarea anterioară sau de imunitatea maternă la acea dată; (iv) autoritatea competentă efectuează: — o examinare clinică, cu rezultate favorabile, a tuturor bovinelor deținute în unitatea de origine a transporturilor respective, inclusiv a bovinelor transportate; — dacă este necesar, un examen de laborator, cu rezultate favorabile, al bovinelor deținute în unitatea de origine a transporturilor respective, inclusiv al bovinelor transportate; (v) bovinele trebuie să fi fost ținute, de la naștere sau pe o perioadă de cel puțin 28 de zile înainte de data expedierii, într-o unitate în care, pe o rază de cel puțin 20 km, nu s-a confirmat niciun focar de infecție cu VDNC pe parcursul ultimelor trei luni anterioare datei de expediere; (vi) toate bovinele aflate pe o rază de 50 km în jurul unității de origine a transportului trebuie să fi fost vaccinate sau revaccinate împotriva infecției cu VDNC, în conformitate cu normele privind planurile de vaccinare prevăzute în anexa II, cel puțin 60 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului sau în perioada de imunitate maternă;

(b)

orice destinație situată în altă zonă de restricții de categoria II a aceluiași stat membru, cu condiția ca toate condițiile următoare să fie îndeplinite: (i) toate celelalte bovine deținute în unitatea de origine a transporturilor respective trebuie să fi fost vaccinate împotriva infecției cu VDNC cu cel puțin 28 de zile înainte de data expedierii și să se afle în perioada de imunitate în conformitate cu instrucțiunile producătorului vaccinului la acea dată sau să se afle în perioada de imunitate indusă de vaccinarea anterioară sau de imunitatea maternă la acea dată; și (ii) bovinele trebuie să fi fost vaccinate împotriva infecției cu VDNC cu cel puțin 28 de zile înainte de data expedierii și să se afle în perioada de imunitate conform instrucțiunilor producătorului vaccinului la acea dată sau să fie descendenți nevaccinați cu vârsta mai mică de patru luni, născuți de femele vaccinate cu cel puțin 28 de zile înainte de parturiție, care se aflau în perioada de imunitate conform producătorului vaccinului la data de parturiție și pot fi deplasate către o altă unitate.

Articolul 9

Condiții specifice pentru autorizarea circulației transporturilor de bovine din zonele de restricții de categoria I și II către un abator din afara acestor zone, situat pe teritoriul aceluiași stat membru în vederea sacrificării imediate

Prin derogări de la interdicțiile prevăzute la articolul 4 alineatul (2) litera (a) și articolul 4 alineatul (1) litera (a) din prezentul regulament, autoritatea competentă din statul membru poate autoriza circulația transporturilor de bovine dinspre zonele de restricții de categoria I și II către un abator din afara acestor zone, situat pe teritoriul aceluiași stat membru, cu condiția ca bovinele să fie deplasate în vederea sacrificării imediate în conformitate cu articolul 28 alineatele (2)-(5) și cu articolul 28 alineatul (7) din Regulamentul delegat (UE) 2020/687.

Articolul 10

Derogări de la interdicția privind circulația transporturilor de material seminal, ovule și embrioni provenind de la bovine din zonele de restricții de categoria I și II

Articolul 11

Derogări de la interdicția de circulație a subproduselor de origine animală neprelucrate obținute de la bovine din zonele de restricții de categoria I

Prin derogare de la interdicția prevăzută la articolul 4 alineatul (2) litera (c), autoritatea competentă dintr-un stat membru poate autoriza circulația transporturilor de subproduse de origine animală neprelucrate obținute de la bovine din unitățile situate în zona de restricții de categoria I către:

(a)	orice destinație situată în același stat membru sau către orice destinație situată în zonele de restricții de categoria I sau II dintr-un alt stat membru;

(b)

în cazul transporturilor de piei, orice destinație situată în orice zonă din același sau din alt stat membru ori către o țară terță, cu condiția să se respecte una din următoarele condiții: (i) pieile tratate au fost supuse unuia dintre tratamentele menționate la punctul 28 literele (b)-(e) din anexa I la Regulamentul (UE) nr. 142/2011 al Comisiei (10); sau (ii) pieile tratate au fost supuse unuia dintre tratamentele prevăzute la punctul (4) litera (b) subpunctul (ii) din capitolul I al secțiunii XIV din anexa III la Regulamentul (CE) nr. 853/2004 al Parlamentului European și al Consiliului (11) și au fost supuse tuturor măsurilor de precauție pentru a se evita recontaminarea cu agenți patogeni după tratament.

Articolul 12

Derogare de la interdicția de circulație a transporturilor de subproduse de origine animală neprelucrate obținute de la bovine din zonele de restricții de categoria II

Prin derogare de la interdicția prevăzută la articolul 4 alineatul (1) litera (c), autoritatea competentă dintr-un stat membru poate autoriza circulația transporturilor de subproduse de origine animală neprelucrate obținute de la bovine din unitățile situate în zona de restricții de categoria II către:

(a)

în cazul subproduselor de origine animală neprelucrate, altele decât pieile, orice destinație situată în același stat membru sau orice destinație situată în zonele de restricții de categoria I sau II dintr-un alt stat membru, cu condiția ca subprodusele de origine animală neprelucrate să fie expediate sub supravegherea oficială a autorităților competente în vederea prelucrării sau a eliminării într-o instalație autorizată în conformitate cu articolul 24 din Regulamentul (CE) nr. 1069/2009 al Parlamentului European și al Consiliului (12);

(b)

în cazul pieilor de bovine: (i) orice destinație situată în zona de restricții de categoria II din același sau alt stat membru, cu condiția să fie piei brute netratate și piei destinate consumului uman sau piei netratate expediate sub supravegherea oficială a autorităților competente în vederea prelucrării sau a eliminării într-o instalație autorizată; (ii) orice destinație situată în același stat membru sau în alt stat membru, cu condiția să fie îndeplinite condițiile prevăzute la articolul 11 litera (b);

(c)

în cazul colostrului, al laptelui și al produselor lactate, orice destinație situată în orice zonă a aceluiași stat membru sau a altui stat membru, cu condiția ca acestea să fi fost supuse unui tratament de atenuare a riscurilor pentru infecția cu VDNC, astfel cum se prevede în anexa VII la Regulamentul delegat (UE) 2020/687.

Articolul 13

Obligațiile operatorilor în materie de certificate de sănătate animală pentru circulația transporturilor de bovine din zone de restricții de categoria I și II, în afara acestor zone

Operatorii deplasează transporturi de bovine deținute în zone de restricții de categoria I și II, în afara acestor zone, pe teritoriul aceluiași stat membru sau către un alt stat membru, în cazurile care fac obiectul articolelor 7, 8 și 9 din prezentul regulament, numai dacă animalele care urmează să fie deplasate sunt însoțite de un certificat de sănătate animală, astfel cum se prevede la articolul 73 din Regulamentul delegat (UE) 2020/688 al Comisiei (13) și care conține cel puțin unul dintre următoarele elemente care atestă respectarea cerințelor prevăzute în prezentul regulament:

(a)	„Bovine provenite din zona de restricții în conformitate cu măsurile speciale de control pentru combaterea infecției cu VDNC prevăzute la articolul 7 din Regulamentul de punere în aplicare (UE) 2021/1070.”;

(b)	„Bovine provenite din zona de restricții de categoria II în conformitate cu măsurile speciale de control pentru combaterea infecției cu VDNC prevăzute la articolul 8 din Regulamentul de punere în aplicare (UE) 2021/1070.”;

(c)	„Bovine provenite dintr-o zonă de restricții I sau II în conformitate cu măsurile speciale de control pentru combaterea infecției cu VDNC prevăzute la articolul 9 din Regulamentul de punere în aplicare (UE) 2021/1070.”

Cu toate acestea, în cazul circulației transporturilor menționate la primul alineat de la prezentul articol pe teritoriul aceluiași stat membru, autoritatea competentă poate decide că nu este necesară eliberarea unui certificat de sănătate animală astfel cum se menționează la al doilea subparagraf de la articolul 143 alineatul (2) din Regulamentul (UE) 2016/429.

Articolul 14

Obligațiile operatorilor în materie de certificate de sănătate animală pentru circulația transporturilor de material germinativ obținut de la bovine deținute în unități situate în zone de restricții de categoria I și II, în afara acestor zone

Operatorii deplasează transporturi de material germinativ obținut de la bovine din zone de restricții de categoria I și II, în afara acestor zone, pe teritoriul aceluiași stat membru sau către un alt stat membru, în conformitate cu articolul 10 din prezentul regulament, numai dacă transporturile respective sunt însoțite de un certificat de sănătate animală, astfel cum se prevede la articolul 161 alineatul (4) din Regulamentul (UE) 2016/429 și care conține cel puțin unul dintre următoarele elemente care atestă respectarea cerințelor prevăzute în prezentul regulament:

(a)

„Materialul germinativ … (material seminal, ovule și/sau embrioni, se menționează după caz) obținute de la bovine deținute în zona de restricții de categoria I în conformitate cu măsurile speciale de control pentru combaterea infecției cu VDNC prevăzute la articolul 10 din Regulamentul de punere în aplicare (UE) 2021/1070.”;

(b)

„Materialul germinativ … (material seminal, ovule și/sau embrioni, se menționează după caz) obținute de la bovine deținute în zona de restricții de categoria II în conformitate cu măsurile speciale de control pentru combaterea infecției cu VDNC prevăzute la articolul 10 din Regulamentul de punere în aplicare (UE) 2021/1070.”

Cu toate acestea, în cazul circulației transporturilor menționate la primul alineat de la prezentul articol pe teritoriul aceluiași stat membru, autoritatea competentă poate decide că nu este necesară eliberarea unui certificat de sănătate animală astfel cum se menționează la al doilea subparagraf din articolul 161 alineatul (2) din Regulamentul (UE) 2016/429.

Articolul 15

Obligațiile operatorilor în materie de certificate de sănătate animală pentru circulația transporturilor de subproduse de origine animală neprelucrate obținute de la bovine deținute în zone de restricții de categoria I și II, în afara acestor zone

Operatorii deplasează transporturi de subproduse de origine animală neprelucrate obținute de la bovine deținute în zone de restricții de categoria I și II, în afara acestor zone, pe teritoriul aceluiași stat membru sau către un alt stat membru în cazurile care fac obiectul articolului 12, numai dacă aceste transporturi sunt însoțite de:

(a)	un document comercial menționat la capitolul III din anexa VIII la Regulamentul (UE) nr. 142/2011; și

(b)	un certificat de sănătate animală, astfel cum se menționează la articolul 22 alineatul (5) din Regulamentul delegat (UE) 2020/687;

Cu toate acestea, în cazul circulației transporturilor menționate la primul paragraf de la prezentul articol pe teritoriul aceluiași stat membru, autoritatea competentă poate decide că nu este necesară eliberarea unui certificat de sănătate animală, astfel cum se menționează la articolul 22 alineatul (6) din Regulamentul delegat (UE) 2020/687.

Articolul 16

Condiții generale suplimentare cu privire la mijloacele de transport folosite pentru circulația transporturilor de bovine și subproduse de origine animală neprelucrate din zone de restricții de categoria I și II, în afara acestor zone

Autoritatea competentă din statul membru autorizează circulația transporturilor de bovine și subproduse de origine animală neprelucrate din zone de restricții de categoria I și II, în afara acestor zone numai dacă mijloacele de transport folosite pentru deplasarea acestor transporturi:

(a)

în cazul transportului bovinelor, mijloacele de transport: (i) respectă cerințele prevăzute la articolul 24 alineatul (1) din Regulamentul delegat (UE) 2020/687; și (ii) sunt curățate și dezinfectate în conformitate cu articolul 24 alineatul (2) din Regulamentul delegat (UE) 2020/687 sub controlul sau supravegherea autorității competente din statul membru;

(b)	includ numai animale sau subproduse de origine animală neprelucrate ori piei netratate cu același statut sanitar.

Articolul 17

Obligațiile autorității competente a unității de origine cu privire la procedurile de transport

Articolul 18

Obligațiile autorității competente de la locul de destinație în ceea ce privește procedurile de transport

Autoritatea competentă de la locul de destinație, în urma unei proceduri de transport:

(a)	confirmă fiecare sosire autorității competente de la locul de origine;

(b)	se asigură că bovinele rămân în unitatea de destinație cel puțin pe durata perioadei de monitorizare a infecției cu VDNC, prevăzută în anexa II la Regulamentul delegat (UE) 2020/687, cu excepția cazului în care unitatea de destinație este un abator;

(c)

se asigură că, după descărcarea bovinelor sau a subproduselor de origine animală neprelucrate, mijloacele de transport și orice alte echipamente utilizate în timpul transportului bovinelor sau al subproduselor de origine animală neprelucrate sunt curățate, dezinfectate și tratate în întregime cu insecticide autorizate care sunt eficiente împotriva vectorilor cunoscuți ai infecției cu VDNC, într-o zonă închisă de la locul de destinație, sub supravegherea medicului veterinar oficial.

Articolul 19

Obligațiile statului membru de origine în ceea ce privește transporturile de bovine, de material germinativ sau de subproduse de origine animală neprelucrate în ceea ce privește informarea Comisiei și a statelor membre cu privire la derogările acordate pe baza evaluărilor riscurilor

În cazul în care autoritatea competentă autorizează circulația transporturilor de bovine sau de material germinativ pe baza rezultatului favorabil al unei evaluări a riscurilor privind măsurile de combatere a răspândirii infecției cu VDNC, astfel cum se menționează la articolele 7, 8 sau 10, statul membru de origine informează imediat Comisia și celelalte state membre despre garanțiile în materie de sănătate animală și despre aprobarea acordată de către autoritățile competente ale unității de destinație.

Articolul 20

Intrarea în vigoare și data aplicării

Prezentul regulament intră în vigoare în ziua următoare datei publicării în Jurnalul Oficial al Uniunii Europene.

Se aplică până la 21 aprilie 2023.

ANEXA I

ZONE DE RESTRICȚII DE CATEGORIA I ȘI II

[astfel cum se menționează la articolul 3]

PARTEA I

Zona de restricții de categoria I

1.   Bulgaria:

Întregul teritoriu al Bulgariei

2.   Grecia:

A.

Următoarele regiuni din Grecia: — Regiunea Attica — Regiunea Grecia Centrală — Regiunea Macedonia Centrală — Regiunea Creta — Regiunea Macedonia de Est și Tracia — Regiunea Epirus — Regiunea Insulele Ionice, exclusiv unitatea regională Kerkyra — Regiunea Egeea de Nord, exclusiv unitatea regională Limnos — Regiunea Peloponez — Regiunea Egeea de Sud — Regiunea Tesalia — Regiunea Grecia de Vest — Regiunea Macedonia de Vest

B.	Următoarele unități regionale din Grecia: — Unitatea regională Limnos — Unitatea regională Kerkyra

PARTEA II

Zona de restricții de categoria II

Nu există

ANEXA II

NORME PRIVIND PLANURILE DE VACCINARE REFERITOARE LA INFECȚIA CU VIRUSUL DERMATOZEI NODULARE CONTAGIOASE

[astfel cum se menționează la articolul 3]

PARTEA I

Informații care trebuie incluse în planul de vaccinare, astfel cum se menționează la articolul 3

În cazul în care un stat membru efectuează vaccinarea împotriva infecției cu VDNC, vaccinarea se efectuează în conformitate cu un plan de vaccinare care conține cel puțin următoarele informații:

(a)	descrierea și rezultatele evaluării efectuate în conformitate cu criteriile prevăzute la articolul 46 alineatul (2) din Regulamentul (UE) 2016/429, inclusiv situația epidemiologică și alte informații relevante utilizate ca bază pentru evaluare;

(b)	principalele obiective și ținte ale strategiei de vaccinare alese și ale planului de vaccinare;

(c)	descrierea geografică detaliată a zonei de vaccinare în care urmează să se efectueze vaccinarea și amplasarea unităților care dețin bovine care urmează să fie vaccinate, inclusiv hărți;

(d)	autoritatea responsabilă de administrarea vaccinului la bovine;

(e)	sistemul de supraveghere a administrării vaccinului;

(f)	numărul de unități care dețin bovine situate în zona de restricții și numărul de unități care urmează să fie vaccinate, dacă acestea sunt diferite;

(g)	numărul estimat de bovine, categoriile acestora și vârsta animalelor care urmează să fie vaccinate;

(h)	durata preconizată a vaccinării, de la începutul vaccinării până la sfârșitul supravegherii efectuate după vaccinare;

(i)	rezumatul caracteristicilor vaccinului, inclusiv denumirea produsului și numele producătorului, precum și căile de administrare;

(j)	indică dacă vaccinul este utilizat în conformitate cu articolul 110 alineatele (2) și (3) din Regulamentul (UE) 2019/6 al Parlamentului European și al Consiliului (1);

(k)	metodele de evaluare a eficacității vaccinării;

(l)	normele de igienă și de biosecuritate care trebuie aplicate;

(m)	sistemul de evidență a vaccinării;

(n)	alte aspecte relevante pentru situația specifică.

PARTEA II

Cerințe minime pentru planurile de vaccinare împotriva infecției cu VDNC, astfel cum se menționează la articolul 3

Planurile de vaccinare împotriva infecției cu VDNC trebuie să respecte următoarele cerințe tehnice:

(a)	vaccinarea tuturor bovinelor, indiferent de sex, vârstă și stare gestațională sau productivă, în zonele de restricții de categoria I și II unde trebuie pusă în aplicare vaccinarea;

(b)	vaccinarea descendenților bovinelor vaccinate cu vârsta mai mare de patru luni, în conformitate cu instrucțiunile producătorului vaccinului utilizat;

(c)	revaccinarea tuturor bovinelor în conformitate cu instrucțiunile producătorului;

(d)

introducerea datelor referitoare la fiecare animal vaccinat din specia bovină de către autoritatea competentă, în baza de date online dedicată, conectată cu baza de date centrală instituită în conformitate cu articolul 42 din Regulamentul (UE) 2019/2035 al Parlamentului European și al Consiliului (2);

(e)	crearea unei zone de supraveghere extinse de cel puțin 20 km în jurul zonelor de restricții de categoria I și II în care se efectuează vaccinarea, în care se asigură supraveghere intensificată, iar circulația bovinelor este supusă unor controale de către autoritatea competentă;

(f)	o acoperire vaccinală de cel puțin 95 % din efective, reprezentând cel puțin 75 % din populația de animale.

PARTEA III

Informații preliminare care trebuie furnizate Comisiei și celorlalte state membre înainte de începerea vaccinării, astfel cum se menționează la articolul 3 punctul 3

Statele membre care aplică vaccinarea împotriva dermatozei nodulare contagioase furnizează următoarele informații Comisiei și celorlalte state membre înainte de începerea vaccinării:

(a)	o scurtă justificare pentru începerea vaccinării;

(b)	speciile de bovine care urmează să fie vaccinate;

(c)	numărul estimat de bovine care urmează să fie vaccinate;

(d)	durata estimată a vaccinării;

(e)	tipul și denumirea comercială a vaccinului aplicat, indicând dacă vaccinul urmează să fie utilizat în conformitate cu articolul 110 alineatele (2) și (3) din Regulamentul (UE) 2019/6;

(f)	o descriere a zonei de vaccinare estimate.

---

(1)  Regulamentul (UE) 2019/6 al Parlamentului European și al Consiliul din 11 decembrie 2018 privind produsele medicinale veterinare și de abrogare a Directivei 2001/82/CE (JO L 4, 7.1.2019, p. 43).

(2)  Regulamentul delegat (UE) 2019/2035 al Comisiei din 28 iunie 2019 de completare a Regulamentului (UE) 2016/429 al Parlamentului European și al Consiliului în ceea ce privește normele pentru unitățile care dețin animale terestre și incubatoare, precum și pentru trasabilitatea anumitor animale terestre deținute și a ouălor pentru incubație (JO L 314, 5.12.2019, p. 115).

Articolul 1

La articolul 4 din Regulamentul de punere în aplicare (UE) 2021/442, al doilea paragraf se înlocuiește cu următorul text:

Articolul 2

La articolul 3 din Regulamentul de punere în aplicare (UE) 2021/521, al doilea paragraf se înlocuiește cu următorul text:

Articolul 3

Prezentul regulament intră în vigoare la 1 iulie 2021.

Articolul 1

Prin derogare de la articolele 2, 3 și 4 din Decizia 2013/471/UE, în cazul în care măsurile restrictive legate de COVID-19 compromit posibilitatea de a organiza o reuniune sau de a participa fizic la aceasta, beneficiarii care participă la reuniune la distanță prin mijloace electronice au dreptul numai la o diurnă stabilită la 145 EUR.

Articolul 2

Comitetul adoptă dispoziții detaliate de punere în aplicare a articolului 1 până la 2 septembrie 2021.

Articolul 3

Până la 2 ianuarie 2022 și, ulterior, la fiecare șase luni, Comitetul prezintă Consiliului un raport de evaluare privind aplicarea prezentei decizii și, în special, privind impactul său bugetar, precum și privind existența în continuare a dificultăților de călătorie legate de COVID-19 sau de măsurile restrictive conexe care compromit posibilitatea de a organiza reuniuni sau de a participa fizic la acestea.

Articolul 4

Prezenta decizie intră în vigoare în ziua următoare datei publicării în Jurnalul Oficial al Uniunii Europene.

Articolul 1

Specificațiile tehnice pentru certificatul digital al UE privind COVID care stabilesc structura datelor generice, mecanismele de codare și mecanismul de codare pentru transport într-un format optic care poate fi citit automat sunt stabilite în anexa I.

Articolul 2

Regulile de completare a certificatelor menționate la articolul 3 alineatul (1) din Regulamentul (UE) 2021/953 sunt stabilite în anexa II la prezenta decizie.

Articolul 3

Cerințele care stabilesc structura comună a identificatorului unic al certificatului sunt stabilite în anexa III.

Articolul 4

Normele de guvernanță aplicabile certificatelor de chei publice în legătură cu gateway-ul pentru certificatul digital al UE privind COVID care sprijină aspectele de interoperabilitate ale cadrului de încredere sunt prevăzute în anexa IV.

ANEXA I

FORMATUL ȘI GESTIONAREA CADRULUI DE ÎNCREDERE

Structura datelor generice, mecanismele de codare și mecanismul de codare pentru transport într-un format optic care poate fi citit automat (denumit în continuare „QR”)

1.   Introducere

Specificațiile tehnice stabilite în prezenta anexă conțin o structură a datelor generice și mecanisme de codare pentru certificatul digital al UE privind COVID („DCC”). Acestea specifică, de asemenea, un mecanism de codare pentru transport într-un format optic care poate fi citit automat („QR”) și care poate fi afișat pe ecranul unui dispozitiv mobil sau imprimat. Formatele container ale certificatului de sănătate electronic aferente specificațiilor menționate sunt generice, dar, în acest context, sunt utilizate pentru a purta DCC.

2.   Terminologie

În sensul prezentei anexe, „emitenți” înseamnă organismele care utilizează aceste specificații pentru emiterea certificatelor de sănătate și „verificatori” înseamnă organismele care acceptă certificatele de sănătate ca dovadă a stării de sănătate. „Participanți” înseamnă emitenții și verificatorii. Unele aspecte prevăzute în prezenta anexă, cum ar fi gestionarea unui spațiu de nume și distribuirea cheilor de criptare, trebuie să facă obiectul coordonării între participanți. Se presupune că una dintre părți, denumită în continuare „secretariatul”, îndeplinește aceste sarcini.

3.   Formatul container al certificatului de sănătate electronic

Formatul container al certificatului de sănătate electronic (Electronic Health Certificate Container Format – HCERT) este conceput pentru a asigura un vehicul uniform și standardizat pentru certificatele de sănătate eliberate de diferiți emitenți („emitenții”). Obiectivul prezentelor specificații este de a armoniza modul în care certificatele de sănătate sunt reprezentate, codate și semnate, cu scopul de a facilita interoperabilitatea.

Capacitatea de a citi și interpreta un DCC, indiferent care este emitentul său, necesită o structură de date comună și ajungerea la un acord cu privire la semnificația fiecărui câmp de date al sarcinii utile. Pentru a facilita o astfel de interoperabilitate, se definește o structură de date comună coordonată, prin utilizarea unei scheme JSON (JavaScript Object Notation – notarea obiectelor în JavaScript), care constituie cadrul DCC.

3.1.   Structura sarcinii utile

Sarcina utilă este structurată și codată sub formă de CBOR (Concise Binary Object Representation – reprezentarea concisă a obiectelor binare), cu o semnătură digitală în formatul COSE (CBOR Object Signing and Encryption – semnarea și criptarea de obiecte utilizând CBOR). Aceasta este cunoscută sub denumirea de „token web CBOR” (CWT) și este definită în RFC 8392 (1). Sarcina utilă, astfel cum este definită în secțiunile următoare, este transportată într-o revendicare hcert.

Integritatea și autenticitatea originii datelor privind sarcina utilă trebuie să poată fi verificate de verificator. Pentru a furniza acest mecanism, emitentul trebuie să semneze CWT utilizând un sistem asimetric de semnătură electronică, astfel cum este definit în specificația privind COSE (RFC 8152 (2)).

3.2.   Revendicări CWT

3.2.1.   Prezentare generală a structurii CWT

Antet protejat

—	Algoritmul de semnătură (alg, eticheta 1)

—	Identificatorul cheii (kid, eticheta 4)

Sarcină utilă

—	Emitentul (iss, cheia de revendicare 1, opțional, ISO 3166-1 alpha-2 al emitentului)

—	Emis la (iat, cheia de revendicare 6)

—	Momentul expirării (exp, cheia de revendicare 4)

—	Certificatul de sănătate (hcert, cheia de revendicare -260)

—	Certificatul digital al UE privind COVID v1 (eu_DCC_v1, cheia de revendicare 1)

Semnătură

3.2.2.   Algoritmul de semnătură

Parametrul algoritmului de semnătură (alg) indică algoritmul care a fost utilizat pentru crearea semnăturii. Acesta trebuie să respecte sau chiar să depășească orientările actuale ale SOG-IS (Senior Officials Group Information Systems Security – Grupul înalților funcționari pentru securitatea sistemelor informatice), astfel cum sunt rezumate în paragrafele următoare.

Se definesc un algoritm primar și unul secundar. Algoritmul secundar ar trebui utilizat numai în cazul în care algoritmul primar nu este acceptabil conform normelor și reglementărilor impuse emitentului.

Pentru a asigura securitatea sistemului, ar trebui ca toate punerile în aplicare să includă algoritmul secundar. Din acest motiv, trebuie aplicat atât algoritmul primar, cât și cel secundar.

Nivelurile stabilite de SOG-IS pentru algoritmul primar și pentru cel secundar sunt următoarele:

—

Algoritmul primar: algoritmul primar este algoritmul de semnătură digitală bazat pe curbe eliptice (Elliptic Curve Digital Signature Algorithm – ECDSA), astfel cum este definit în secțiunea 2.3 din (ISO/IEC 14888-3: 2006), utilizând parametrii P-256 definiți în apendicele D (D.1.2.3) la (FIPS PUB 186-4), în combinație cu algoritmul de distribuire (hash) SHA-256, astfel cum este definit în funcția 4 din (ISO/IEC 10118-3: 2004).

Acesta corespunde parametrului ES256 al algoritmului COSE.

—	Algoritmul secundar: algoritmul secundar este RSASSA-PSS, astfel cum este definit în (RFC 8230 (3)), cu un modul de 2048 biți, în combinație cu algoritmul de distribuire (hash) SHA-256, astfel cum este definit în funcția 4 din (ISO/IEC 10118-3: 2004).

Acesta corespunde algoritmului COSE, parametrul PS256.

3.2.3.   Identificatorul cheii

Revendicarea privind identificatorul cheii (kid) indică certificatul de semnatar de documente (DSC) care conține cheia publică pe care verificatorul trebuie să o utilizeze atunci când verifică dacă semnătura digitală este corectă. Guvernanța certificatelor de cheie publică, inclusiv cerințele pentru DSC-uri, este descrisă în anexa IV.

Revendicarea privind identificatorul cheii (kid) este utilizată de verificatori pentru selectarea cheii publice corecte dintr-o listă de chei aferente emitentului indicat în revendicarea privind emitentul (iss). Un emitent poate utiliza în paralel mai multe chei, din motive administrative și atunci când efectuează reînnoirea cheilor. Identificatorul cheii nu este un câmp critic din punctul de vedere al securității. Din acest motiv, el poate fi plasat și într-un antet neprotejat, dacă este necesar. Verificatorii trebuie să accepte ambele opțiuni. În cazul în care sunt prezente ambele opțiuni, trebuie utilizat identificatorul cheii din antetul protejat.

Din cauza scurtării identificatorului (din motive de limitare a dimensiunii), există o șansă redusă, dar nu egală cu zero, ca lista globală a DSC-urilor (Document Signer Certificates – certificate ale semnatarilor de documente) acceptate de un verificator să conțină DSC-uri cu același kid. Din acest motiv, verificatorul trebuie să verifice toate DSC-urile cukid-ul respectiv.

3.2.4.   Emitent

Revendicarea privind emitentul (iss) este o valoare de tip șir care poate conține codul de țară ISO 3166-1 alpha-2 al entității care eliberează certificatul de sănătate. Această revendicare poate fi utilizată de un verificator pentru a identifica setul de DSC-uri care urmează să fie utilizate pentru verificare. Pentru a identifica această revendicare se utilizează cheia de revendicare 1.

3.2.5.   Momentul expirării

Revendicarea privind momentul expirării (exp) trebuie să conțină o marcă temporală în formatul de tip număr întreg NumericDate (astfel cum se specifică în RFC 8392 (4), secțiunea 2), care indică perioada de valabilitate a acestei semnături specifice asupra sarcinii utile, după încheierea căreia verificatorul trebuie să respingă sarcina utilă ca fiind expirată. Scopul parametrului de expirare este de a impune o limită la perioada de valabilitate a certificatului de sănătate. Pentru a identifica această revendicare se utilizează cheia de revendicare 4.

Momentul expirării nu trebuie să depășească perioada de valabilitate a DSC.

3.2.6.   Emis la

Revendicarea „emis la” (iat) trebuie să conțină o marcă temporală în formatul de tip număr întreg NumericDate (astfel cum se specifică în RFC 8392 (5), secțiunea 2), indicând momentul în care a fost creat certificatul de sănătate.

Câmpul „emis la” nu trebuie să conțină o dată anterioară perioadei de valabilitate a DSC.

Verificatorii pot să aplice și alte politici cu scopul de a limita valabilitatea certificatului de sănătate în funcție de momentul emiterii. Pentru a identifica această revendicare se utilizează cheia de revendicare 6.

3.2.7.   Revendicarea privind certificatul de sănătate

Revendicarea privind certificatul de sănătate (hcert) este un obiect JSON (RFC 7159 (6)) care conține informații privind starea de sănătate. În cadrul aceleiași revendicări pot exista mai multe tipuri de certificate de sănătate, printre care și DCC.

Formatul JSON este utilizat exclusiv pentru scheme. Formatul de reprezentare este CBOR, astfel cum este definit în (RFC 7049 (7)). Este posibil ca, în realitate, dezvoltatorii de aplicații să nu decodeze sau să codeze niciodată în și din format JSON, ci să utilizeze în schimb structura integrată în memorie.

Pentru a identifica această revendicare se utilizează cheia de revendicare -260.

Șirurile din obiectul JSON ar trebui normalizate în conformitate cu forma de normalizare NFC (Normalization Form Canonical Composition - forma de normalizare cu compunere canonică) definită în standardul Unicode. Cu toate acestea, aplicațiile de decodare ar trebui să fie permisive și robuste în aceste privințe, iar acceptarea oricărui tip de conversie rezonabilă este puternic încurajată. În cazul în care, în timpul decodării sau în funcțiile de comparare ulterioară, se descoperă date nenormalizate, punerile în aplicare ar trebui să se comporte ca și cum datele de intrare ar fi normalizate pentru NFC.

4.   Serializarea și crearea sarcinii utile a DCC

Ca model de serializare, se utilizează următoarea schemă:

Procesul începe cu extragerea de date, de exemplu, dintr-un registru de date privind sănătatea (sau dintr-o sursă de date externă), structurând datele extrase în conformitate cu schemele DCC definite. În acest proces, conversia în formatul de date definit și transformarea pentru a permite lizibilitatea umană pot avea loc înainte de începerea serializării în format CBOR. Acronimele revendicărilor trebuie puse în corespondență, în fiecare caz, cu denumirile de afișare înainte de serializare și după deserializare.

Conținutul opțional de date naționale nu este permis în certificatele eliberate în conformitate cu Regulamentul (UE) nr. 2021/953 (8). Conținutul datelor se limitează la elementele de date definite în setul minim de date specificat în anexa la Regulamentul 2021/953.

5.   Codările pentru transport

5.1.   Forma brută

Pentru interfețele de date arbitrare, formatul container al certificatului HCERT și sarcinile sale utile pot fi transferate ca atare, utilizând orice tip de transport de date subiacent sigur și fiabil cu 8 biți. Interfețele respective pot include comunicarea în câmp apropiat (Near-Field Communication – NFC), Bluetooth sau transfer prin intermediul unui protocol privind nivelul de aplicație, de exemplu transferul unui certificat HCERT de la emitent către dispozitivul mobil al unui titular.

În cazul în care transferul certificatului HCERT de la emitent către titular se bazează pe o interfață exclusiv de prezentare (de exemplu, SMS sau e-mail), codarea pentru transport brută nu este, în mod evident, aplicabilă.

5.2.   Codul de bare

5.2.1.   Compresia sarcinii utile (CWT)

Pentru a reduce dimensiunea și a îmbunătăți viteza și fiabilitatea procesului de citire a certificatelor HCERT, CWT trebuie comprimat utilizând formatul ZLIB (RFC 1950 (9)) și mecanismul de compresie Deflate, în formatul definit în RFC 1951 (10).

5.2.2.   Codul de bare QR 2D

Pentru a gestiona mai bine echipamentele tradiționale concepute să funcționeze pe sarcini utile ASCII (American Standard Code for Information Interchange – Codul standard american pentru schimbul de informații), CWT comprimat este codificat ca ASCII cu ajutorul schemei de codare Base45, înainte de a fi codat într-un cod de bare 2D.

Pentru generarea de coduri de bare 2D trebuie utilizat formatul QR, astfel cum este definit în (ISO/IEC 18004:2015). Se recomandă o rată de corecție a erorilor egală cu „Q” (de aproximativ 25 %). Deoarece se utilizează Base45, codul QR trebuie să utilizeze codarea alfanumerică (modul 2, indicat de simbolurile 0010).

Pentru ca verificatorii să poată detecta tipul de date codate și să selecteze schema corespunzătoare de decodare și prelucrare, datele codate cu ajutorul schemei de codare Base45 (în conformitate cu prezenta specificație) trebuie să fie precedate de identificatorul de context sub formă de șir „HC1:”. Versiunile viitoare ale prezentei specificații de natură să afecteze compatibilitatea inversă vor defini un nou identificator de context, iar caracterul care urmează după literele „HC” trebuie selectat din setul de caractere [1-9A-Z]. Ordinea incrementelor este definită în această ordine, și anume mai întâi [1-9] și apoi [A-Z].

Se recomandă ca, în cadrul mediului de prezentare, codul optic să aibă o diagonală cuprinsă între 35 mm și 60 mm, pentru a permite utilizarea de cititoare cu elemente optice fixe pentru care mediul de prezentare trebuie amplasat pe suprafața cititorului.

În cazul în care codul optic este imprimat pe hârtie cu ajutorul unei imprimante cu rezoluție mică (< 300 dpi), trebuie să se acorde atenție reprezentării cu precizie a fiecărui simbol (punct) al codului QR, astfel încât acesta să aibă formă pătrată. Scalarea neproporțională va face ca unele rânduri sau coloane din QR să aibă simboluri dreptunghiulare, ceea ce, în multe cazuri, va afecta lizibilitatea.

6.   Formatul listelor de încredere (lista CSCA și lista DSC)

Fiecare stat membru trebuie să furnizeze o listă cuprinzând una sau mai multe autorități naționale de certificare pentru semnătură (CSCA) și o listă a tuturor certificatelor de semnatar de documente (DSC) în termen de valabilitate, și să asigure actualizarea acestor liste.

6.1.   CSCA/DSC simplificate

Începând cu versiunea curentă a specificațiilor, statele membre nu trebuie să pornească de la prezumția că informațiile din lista certificatelor revocate (CRL) sunt utilizate sau că perioada de utilizare a cheii private este verificată de către entitățile care asigură punerea în aplicare.

În schimb, mecanismul principal de verificare a perioadei de valabilitate este prezența certificatului pe cea mai recentă versiune a respectivei liste de certificate.

6.2.   Documentul de călătorie electronic cu citire optică (eMRTD) și certificatul de cheie publică PKI ale Organizației Aviației Civile Internaționale (OACI) și centrele de încredere

Statele membre pot utiliza o CSCA separată, dar pot, de asemenea, să transmită certificatele eMRTD emise de CSCA existentă și/sau DSC-urile deja existente și pot alege chiar să achiziționeze certificate de la centre de încredere (comerciale) și să le transmită. Cu toate acestea, orice DSC trebuie să fie întotdeauna semnat de CSCA prezentată de statul membru respectiv.

7.   Considerente de securitate

Atunci când proiectează o schemă care utilizează această specificație, statele membre trebuie să identifice, să analizeze și să monitorizeze anumite aspecte legate de securitate.

Trebuie luate în considerare cel puțin următoarele aspecte:

7.1.   Perioada de valabilitate a semnăturii certificatelor HCERT

Emitentul certificatului HCERT trebuie să limiteze perioada de valabilitate a semnăturii prin specificarea momentului la care expiră semnătura. Prin urmare, titularul unui certificat de sănătate este obligat să îl reînnoiască periodic.

Perioada de valabilitate acceptabilă poate fi determinată de constrângeri practice. De exemplu, este posibil ca un călător să nu aibă posibilitatea de a-și reînnoi certificatul de sănătate în timpul unei călătorii în străinătate. Cu toate acestea, se poate întâmpla, de asemenea, ca un emitent să ia în considerare posibilitatea ca securitatea să fie compromisă, emitentul fiind nevoit să retragă un DSC (invalidând toate certificatele de sănătate eliberate cu ajutorul cheii respective care sunt încă valabile). Consecințele unui astfel de eveniment pot fi limitate prin reînnoirea periodică a cheilor emitenților și prin impunerea reînnoirii tuturor certificatelor de sănătate într-un interval rezonabil.

7.2.   Gestionarea cheilor

Prezenta specificație se bazează în mare măsură pe mecanisme criptografice solide, menite să asigure integritatea datelor și autentificarea originii datelor. Prin urmare, este necesar să se mențină confidențialitatea cheilor private.

Confidențialitatea cheilor criptografice poate fi compromisă în mai multe moduri, de exemplu:

—	procesul de generare a cheilor poate fi defectuos, având ca rezultat chei slabe;

—	cheile pot fi expuse din cauza unei erori umane;

—	cheile pot fi furate de infractori externi sau interni.

—	cheile pot fi calculate cu ajutorul criptanalizei.

Pentru a atenua riscurile de a se constata că algoritmul de semnare este slab și permite compromiterea cheilor prin criptanaliză, prezenta specificație recomandă ca toți participanții să aplice un algoritm de semnătură secundar, de rezervă, bazat pe parametri diferiți sau pe o problemă matematică diferită față de cea pentru algoritmul primar.

În ceea ce privește riscurile menționate legate de mediile de operare ale emitenților, trebuie puse în aplicare măsuri de atenuare care să asigure un control eficace, astfel încât să se genereze, să se stocheze și să se utilizeze cheile private din modulele de securitate hardware (HSM). Se încurajează puternic utilizarea modulelor HSM pentru semnarea certificatelor de sănătate.

Indiferent dacă un emitent decide să utilizeze sau nu modulele HSM, ar trebui stabilit un calendar de reînnoire a cheilor care să prevadă o frecvență a reînnoirii cheilor proporțională cu expunerea cheilor la rețele externe, la alte sisteme și la personal. Un calendar de reînnoire bine ales limitează, totodată, riscurile asociate certificatelor de sănătate eliberate în mod eronat, prin faptul că îi permite unui emitent să revoce aceste certificate de sănătate pe loturi, prin retragerea unei chei, dacă acest lucru se dovedește necesar.

7.3.   Validarea datelor de intrare

Prezentele specificații pot fi utilizate într-un mod care implică primirea de date din surse nefiabile în sisteme care pot fi esențiale pentru îndeplinirea misiunii stabilite. Pentru a reduce la minimum riscurile asociate acestui vector de atac, toate câmpurile de intrare trebuie să fie validate în mod corespunzător, în funcție de tipul, lungimea și conținutul datelor. Înainte de prelucrarea conținutului certificatului HCERT, trebuie verificată, de asemenea, semnătura emitentului. Cu toate acestea, validarea semnăturii emitentului implică analizarea prealabilă a antetului protejat al emitentului, în care un potențial atacator poate încerca să introducă informații atent formulate, concepute pentru a compromite securitatea sistemului.

8.   Gestionarea încrederii

Semnătura certificatului HCERT necesită o cheie publică pentru a fi verificată. Statele membre trebuie să pună la dispoziție aceste chei publice. În ultimă instanță, fiecare verificator trebuie să aibă o listă a tuturor cheilor publice în care este dispus să aibă încredere (având în vedere faptul că o cheie publică nu face parte din certificatul HCERT).

Sistemul este format din (numai) două niveluri: pentru fiecare stat membru, unul sau mai multe certificate la nivel de țară, fiecare dintre acestea servind la semnarea unuia sau a mai multor certificate de semnatar de documente, care sunt utilizate în operațiunile zilnice.

Certificatele statelor membre se numesc certificate ale autorităților naționale de certificare pentru semnătură (CSCA) și sunt (de regulă) certificate autosemnate. Un stat membru poate avea mai multe astfel de certificate (de exemplu, în cazul deconcentrării regionale). Aceste certificate CSCA semnează periodic certificatele de semnatar de documente (DSC) utilizate pentru semnarea certificatelor HCERT.

„Secretariatul” este un rol funcțional. Acesta trebuie să agrege și să publice periodic DSC-urile statelor membre, după ce verifică dacă acestea se regăsesc în lista certificatelor CSCA (care au fost transmise și verificate prin alte mijloace).

Lista de certificate DSC rezultată trebuie să furnizeze apoi setul agregat de chei publice acceptabile (și kid-urile corespunzătoare) pe care verificatorii le pot utiliza pentru a valida semnăturile pentru certificatele HCERT. Verificatorii trebuie să obțină și să actualizeze această listă în mod regulat.

Aceste liste specifice fiecărui stat membru pot fi adaptate în formatul corespunzător situației existente la nivel național. Din acest motiv, formatul fișierului acestei liste de încredere poate varia, de exemplu, poate fi un JWKS semnat (format pentru seturi de chei web JSON conform RFC 7517 (11) secțiunea 5) sau orice alt format specific tehnologiei utilizate în statul membru respectiv.

Pentru a asigura simplitatea, statele membre pot fie să își transmită certificatele CSCA existente din sistemele lor eMRTD conforme cu normele OACI, fie, în conformitate cu recomandările OMS, să creeze un certificat specific pentru acest domeniu al sănătății.

8.1.   Identificatorul cheii (kid)

Identificatorul cheii (kid) se calculează atunci când se elaborează lista cheilor publice de încredere pe baza certificatelor DSC și constă într-o amprentă digitală SHA-256 trunchiată (primii 8 byți) a DSC, codificată în format DER (brut).

Verificatorii nu trebuie să calculeze kid-ul pe baza certificatului DSC; ei pot corela direct identificatorul cheii din certificatul de sănătate emis cu kid-ul de pe lista de încredere.

8.2.   Diferențe față de modelul de încredere eMRTD PKI al OACI

Deși se bazează pe cele mai bune practici ale modelului de încredere eMRTD PKI al OACI, din motive de rapiditate, în prezenta specificație trebuie efectuate o serie de simplificări:

—	Un stat membru poate prezenta mai multe certificate CSCA.

—	Perioada de valabilitate a DSC (utilizarea cheii) poate fi stabilită la orice durată, atât timp cât aceasta nu depășește certificatul CSCA, și poate să lipsească.

—	DSC poate să conțină identificatori ai politicilor (utilizarea extinsă a cheii) care sunt specifici certificatelor de sănătate.

—	Statele membre pot alege să nu efectueze niciodată verificări ale revocărilor publicate și să se bazeze exclusiv pe listele DSC pe care le primesc zilnic de la secretariat sau le compilează ele însele.

---

(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)  Regulamentul (UE) 2021/953 al Parlamentului European și al Consiliului din 14 iunie 2021 privind cadrul pentru eliberarea, verificarea și acceptarea certificatelor interoperabile de vaccinare, testare și vindecare de COVID-19 (certificatul digital al UE privind COVID) pentru a facilita libera circulație pe durata pandemiei de COVID-19, JO L 211, 15.6.2021, p. 1.

(9)  rfc1950 (ietf.org)

(10)  rfc1951 (ietf.org)

(11)  rfc7517 (ietf.org)

ANEXA II

REGULI DE COMPLETARE A CERTIFICATULUI DIGITAL AL UE PRIVIND COVID

Regulile generale privind seturile de valori stabilite în prezenta anexă au scopul de a asigura interoperabilitatea la nivel semantic și trebuie să permită punerea în aplicare tehnică uniformă pentru DCC. Elementele cuprinse în prezenta anexă pot fi utilizate pentru cele trei contexte diferite (vaccinare/testare/vindecare), astfel cum se prevede în Regulamentul (UE) 2021/953. Numai elementele pentru care este necesară standardizarea semantică prin seturi de valori codate sunt enumerate în prezenta anexă.

Responsabilitatea pentru traducerea elementelor codate în limba națională le revine statelor membre.

Pentru toate câmpurile de date care nu sunt menționate în următoarele descrieri ale seturilor de valori, se recomandă codarea în format UTF-8 (nume, centru de testare, emitentul certificatului). Se recomandă codificarea câmpurilor de date care conțin date calendaristice (data nașterii, data vaccinării, data prelevării probei testate, data primului rezultat pozitiv al testului, datele corespunzătoare perioadei de valabilitate a certificatului) în conformitate cu standardul ISO 8601.

În cazul în care, dintr-un motiv oarecare, nu pot fi utilizate sistemele de coduri preferate enumerate mai jos, pot fi utilizate alte sisteme de coduri internaționale și ar trebui elaborate recomandări privind punerea în corespondență a codurilor din celelalte sisteme de coduri cu sistemul de coduri preferat. Textul (denumirile de afișare) poate fi utilizat, în cazuri excepționale, ca mecanism de rezervă, atunci când în seturile de valori definite nu este disponibil niciun cod adecvat.

Statele membre care utilizează alte coduri în sistemele lor ar trebui să pună în corespondență aceste coduri cu seturile de valori descrise. Statele membre sunt responsabile pentru orice astfel de puneri în corespondență.

Seturile de valori trebuie actualizate periodic de către Comisie, cu sprijinul rețelei de e-sănătate și al Comitetului pentru securitate sanitară. Seturile de valori actualizate trebuie publicate pe site-ul relevant al Comisiei, precum și pe pagina web a rețelei de e-sănătate. Ar trebui furnizat un istoric al modificărilor.

1.   Boala sau agentul vizat/boala sau agentul de care s-a vindecat titularul: COVID-19 (SARS-CoV-2 sau una dintre variantele sale)

Sistemul de coduri preferat: SNOMED CT.

A se utiliza în certificatele 1, 2 și 3.

Codurile selectate trebuie să menționeze COVID-19 sau, în cazul în care sunt necesare informații mai detaliate privind varianta genetică a SARS-CoV-2, varianta respectivă, dacă aceste informații detaliate sunt necesare din motive epidemiologice.

Un exemplu de cod care ar trebui utilizat este codul SNOMED CT 840539006 (COVID-19).

2.   Vaccinul împotriva COVID-19 sau metodele profilactice împotriva COVID-19

Sistemul de coduri preferat: SNOMED CT sau clasificarea ATC (anatomică, terapeutică și chimică).

A se utiliza în certificatul 1.

Exemple de coduri care ar trebui utilizate din sistemele de coduri preferate sunt codul SNOMED CT 1119305005 (vaccin antigenic împotriva SARS-CoV-2), 1119349007 (vaccin de tip ARNm împotriva SARS-CoV-2) sau J07BX03 (vaccinuri împotriva COVID-19). Setul de valori ar trebui extins atunci când se dezvoltă și se introduc noi tipuri de vaccinuri.

3.   Medicamentul reprezentând vaccinul împotriva COVID-19

Sistemele de coduri preferate (în ordinea preferințelor):

—	Registrul UE al medicamentelor reprezentând vaccinuri autorizate la nivelul întregii UE (numerele autorizațiilor)

—	Un registru mondial al vaccinurilor, precum cel care ar putea fi instituit de Organizația Mondială a Sănătății

—	Denumirea medicamentului reprezentând vaccinul în alte cazuri. Dacă denumirea include spații albe, acestea ar trebui înlocuite cu o cratimă (-).

Denumirea setului de valori: vaccin.

A se utiliza în certificatul 1.

Din sistemul de coduri preferat, un exemplu de cod care ar trebui utilizat este EU/1/20/1528 (Comirnaty). Un exemplu de denumire a vaccinului care poate fi utilizată drept cod: Sputnik-V (pentru Sputnik V).

4.   Deținătorul autorizației de comercializare sau producătorul vaccinului împotriva COVID-19

Sistemul de coduri preferat:

—	Codul organizației furnizat de Agenția Europeană pentru Medicamente (sistemul SPOR pentru ISO IDMP)

—	Un registru mondial al deținătorilor de autorizații de comercializare sau al producătorilor de vaccinuri, precum cel care ar putea fi instituit de Organizația Mondială a Sănătății

—	Denumirea organizației, în celelalte cazuri. Dacă denumirea include spații albe, acestea ar trebui înlocuite cu o cratimă (-).

A se utiliza în certificatul 1.

Din sistemul de coduri preferat, un exemplu de cod care ar trebui utilizat este ORG-100001699 (AstraZeneca AB). Un exemplu de denumire a organizației care poate fi utilizată drept cod: Sinovac-Biotech (pentru Sinovac Biotech).

5.   Numărul dintr-o serie de doze, precum și numărul total de doze din serie

A se utiliza în certificatul 1.

Două câmpuri:

(1)	numărul de doze administrate într-un ciclu

(2)	numărul de doze preconizate pentru un ciclu complet (specific fiecărei persoane la momentul administrării)

De exemplu, 1/1, 2/2 înseamnă că ciclul este complet; la fel și opțiunea 1/1 pentru vaccinurile care includ două doze, dar pentru care protocolul aplicat de statul membru este de a administra o singură doză cetățenilor care au fost diagnosticați cu COVID-19 înainte de vaccinare. Numărul total de doze dintr-o serie ar trebui indicat conform informațiilor disponibile la momentul administrării dozei. De exemplu, dacă un anumit vaccin necesită o a treia doză (rapel), trebuie ca, în momentul în care se administrează ultima doză, al doilea număr al câmpului să reflecte acest lucru (de exemplu 2/3, 3/3 etc.).

6.   Statul membru sau țara terță în care s-a administrat vaccinul/s-a efectuat testul

Sistemul de coduri preferat: codurile ISO 3166 ale țărilor.

A se utiliza în certificatele 1, 2 și 3.

Conținutul setului de valori: lista completă a codurilor de 2 litere, disponibilă ca set de valori definit în FHIR (Fast Healthcare Interoperability Resources – resurse rapide de interoperabilitate în domeniul sănătății) (http://hl7.org/fhir/ValueSet/iso3166-1-2)

7.   Tipul testului

Sistemul de coduri preferat: LOINC.

A se utiliza în certificatul 2 și în certificatul 3 în cazul în care se introduce, printr-un act delegat, posibilitatea de a elibera certificate de vindecare pe baza altor tipuri de teste decât NAAT (nucleic acid amplification technique – tehnica amplificării acidului nucleic).

Codurile din acest set de valori trebuie să facă referire la metoda de realizare a testului și trebuie selectate astfel încât să asigure cel puțin distincția dintre testele NAAT și testele RAT (testele antigenice rapide), astfel cum se prevede în Regulamentul (UE) 2021/953.

Din sistemul de coduri preferat, un exemplu de cod care ar trebui utilizat este LP217198-3 (Rapid immunoassay – test imunologic rapid).

8.   Producătorul și denumirea comercială a testului utilizat (opționale pentru testul NAAT)

Sistemul de coduri preferat: lista de teste antigenice rapide a Comitetului pentru securitate sanitară, gestionată de JRC (baza de date despre dispozitivele și metodele de testare in vitro vizând diagnosticarea COVID-19).

A se utiliza în certificatul 2.

Setului de valori trebuie să includă selectarea testului antigenic rapid, astfel cum este menționat în lista comună actualizată a testelor antigenice rapide pentru COVID-19, stabilită pe baza Recomandării 2021/C 24/01 a Consiliului și aprobată de Comitetul pentru securitate sanitară. Lista este actualizată de JRC în baza de date despre dispozitivele și metodele de testare in vitro vizând diagnosticarea COVID-19, la adresa: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

Pentru acest sistem de coduri, trebuie să se utilizeze câmpuri relevante precum identificatorul dispozitivului de testare, denumirea testului și a producătorului, în formatul structurat al JRC, disponibil la adresa https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9.   Rezultatul testului

Sistemul de coduri preferat: SNOMED CT.

A se utiliza în certificatul 2.

Codurile selectate trebuie să permită distincția între rezultatele pozitive și cele negative ale testelor (detectat sau nedetectat). Se pot adăuga și alte valori (de exemplu, nedeterminat) dacă pe parcursul utilizării apar cazuri care impun acest lucru.

Din sistemul de coduri preferat, exemplele de coduri care ar trebui utilizate sunt 260415000 (nedetectat) și 260373001 (detectat).

ANEXA III

STRUCTURA COMUNĂ A IDENTIFICATORULUI UNIC AL CERTIFICATULUI

1.   Introducere

Fiecare certificat digital al UE privind COVID (DCC) trebuie să includă un identificator unic al certificatului (UCI) care asigură interoperabilitatea DCC-urilor. UCI poate fi utilizat pentru a verifica certificatul. Responsabilitatea punerii în aplicare a UCI le revine statelor membre. Identificatorul UCI este un mijloc de verificare a veridicității certificatului și, după caz, de conectare la un sistem de înregistrare (de exemplu, un sistem de informații privind imunizarea). De asemenea, acești identificatori trebuie să le permită statelor membre să ateste (pe suport de hârtie și în format digital) că persoanele au fost vaccinate sau testate.

2.   Compoziția identificatorului unic al certificatului

Identificatorul UCI trebuie să urmeze o structură și un format comune care facilitează interpretabilitatea informațiilor de către om și/sau mașină și care se pot referi la elemente precum statul membru de vaccinare, vaccinul în sine și un identificator specific pentru fiecare stat membru. UCI asigură faptul că statele membre dispun de flexibilitate în ceea ce privește configurarea sa, cu respectarea deplină a legislației privind protecția datelor. Ordinea elementelor separate urmează o ierarhie definită care poate permite modificări viitoare ale componentelor, menținând în același timp integritatea structurală a identificatorului.

Soluțiile posibile pentru compoziția UCI formează un spectru în cadrul căruia modularitatea și interpretabilitatea umană reprezintă cei doi parametri principali de diversificare și o caracteristică fundamentală:

—	Modularitatea: măsura în care codul este format din componente distincte care conțin informații diferite din punct de vedere semantic

—	Interpretabilitatea umană: măsura în care codul este semnificativ sau poate fi interpretat de cititorul uman

—

Unic la nivel mondial; identificatorul țării sau al autorității este bine gestionat și se preconizează că fiecare țară (autoritate) își va gestiona în mod corespunzător segmentul din spațiul de nume, fără să recurgă vreodată la reciclarea sau reemiterea identificatorilor. Combinația dintre aceste elemente asigură faptul că fiecare identificator este unic la nivel mondial.

3.   Cerințe generale

Următoarele cerințe generale ar trebui să fie îndeplinite în ceea ce privește identificatorul UCI:

(1)	setul de caractere: sunt permise numai caracterele alfanumerice US-ASCII majuscule (de la „A” la „Z”, de la „0” la „9”), cu caractere speciale suplimentare pentru separare în conformitate cu RFC3986 (1) (2), și anume {„/”, „#”, „:”};

(2)	lungimea maximă: proiectanții ar trebui să își propună ca obiectiv o lungime de 27-30 de caractere (3);

(3)	prefixul versiunii: acesta se referă la versiunea schemei UCI. Prefixul versiunii este „01” pentru prezenta versiune a documentului; prefixul versiunii este compus din două cifre;

(4)	prefixul țării: codul de țară este specificat în ISO 3166-1. Codurile mai lungi [de exemplu, de 3 caractere și mai mult (de exemplu, „UNHCR”)] sunt rezervate pentru o utilizare viitoare;

(5)

Sufixul codului/suma de verificare. 5.1. Statele membre ar trebui să utilizeze o sumă de verificare atunci când este probabil să apară erori de transmisie, de transcriere (umană) sau alte tipuri de deteriorare a datelor (cu alte cuvinte, atunci când sunt utilizate în format tipărit). 5.2. Suma de verificare nu trebuie să fie utilizată pentru validarea certificatului și nu face parte, din punct de vedere tehnic, din identificator, ci este utilizată pentru a verifica integritatea codului. Această sumă de verificare ar trebui să fie rezumatul conform standardului ISO-7812-1 (LUHN-10) (4) al întregului UCI în format digital/de reprezentare a datelor în vederea transportului. Suma de verificare este separată de restul UCI printr-un caracter „#”.

Ar trebui să se asigure compatibilitatea inversă: statele membre care schimbă, în timp, structura identificatorilor lor (în versiunea principală, stabilită în prezent ca fiind v1) trebuie să se asigure că doi identificatori identici reprezintă același certificat/mențiune de vaccinare. Cu alte cuvinte, statele membre nu pot recicla identificatorii.

4.   Opțiuni privind identificatorii unici ai certificatului pentru certificatele de vaccinare

Orientările rețelei de e-sănătate privind certificatele verificabile de vaccinare și elementele de interoperabilitate de bază (5) prevăd diferite opțiuni aflate la dispoziția statelor membre și a altor părți care pot coexista între diferitele state membre. Statele membre pot introduce astfel de opțiuni diferite în diferite versiuni ale schemei UCI.

---

(1)  rfc3986 (ietf.org)

(2)  Este posibil ca anumite câmpuri precum sexul, numărul lotului, centrul de administrare, identificarea personalului medico-sanitar, data următoarei vaccinări să nu fie necesare decât în scopuri medicale.

(3)  Pentru punerea în aplicare cu coduri QR, statele membre ar putea lua în considerare un set suplimentar de caractere, cu o lungime totală de până la 72 de caractere (inclusiv cele 27-30 ale identificatorului propriu-zis) pentru a transmite alte informații. Precizarea acestor informații ține de competența statelor membre.

(4)  Algoritmul Luhn mod N este o extensie a algoritmului Luhn (cunoscut și sub denumirea de algoritm mod 10) care funcționează pentru coduri numerice și este utilizat, de exemplu, pentru calcularea sumei de verificare a cardurilor de credit. Extensia îi permite algoritmului să funcționeze cu secvențe de valori în orice bază (în cazul nostru, caractere alfa).

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

ANEXA IV

GUVERNANȚA CERTIFICATELOR CU CHEIE PUBLICĂ

1.   Introducere

Schimbul securizat și fiabil de chei de semnătură pentru certificatele digitale ale UE privind COVID (DCC) între statele membre este realizat cu ajutorul Gateway-ului pentru certificatele digitale ale UE privind COVID (DCCG), care funcționează ca un registru central pentru cheile publice. Prin intermediul DCCG, statele membre sunt împuternicite să publice cheile publice corespunzătoare cheilor private pe care le utilizează pentru a semna certificatele digitale privind COVID. Statele membre care se bazează pe DCCG pot utiliza portalul pentru a obține în timp util materiale actualizate privind cheile publice. Ulterior, DCCG poate fi extins pentru a face schimb de informații suplimentare fiabile furnizate de statele membre, cum ar fi normele de validare pentru DCC-uri. Modelul de încredere al cadrului DCC este o infrastructură de chei publice (Public Key Infrastructure – PKI). Fiecare stat membru deține una sau mai multe autorități naționale de certificare pentru semnătură (CSCA), ale căror certificate au o durată de viață relativ lungă. În funcție de decizia statului membru, CSCA poate fi aceeași cu CSCA utilizată pentru documentele de călătorie care pot fi citite automat sau poate fi diferită. CSCA emite certificate de cheie publică pentru semnatarii de documente naționale cu durată scurtă de viață (și anume, semnatarii pentru DCC-uri), care sunt denumite certificate de semnatar de documente (DSC). CSCA acționează ca o ancoră de încredere, care le permite statelor membre care se bazează pe aceasta să utilizeze certificatul CSCA pentru a valida autenticitatea și integritatea DSC-urilor, care suferă modificări periodice. Odată ce validarea a fost efectuată, statele membre pot folosi aceste certificate (sau doar cheile publice pe care le conțin) pentru aplicațiile lor de validare a DCC. Pe lângă CSCA și DSC, DCCG se bazează, de asemenea, pe infrastructurile de chei publice (PKI) pentru autentificarea tranzacțiilor, semnarea datelor, ca bază pentru autentificare și ca mijloc de asigurare a integrității canalelor de comunicare dintre statele membre și DCCG.

Semnăturile digitale pot fi utilizate pentru a se asigura integritatea și autenticitatea datelor. Infrastructurile de chei publice creează încredere prin asocierea obligatorie a unor chei publice cu anumite identități verificate (sau emitenți verificați). Acest lucru este necesar pentru a le permite celorlalți participanți să verifice originea datelor și identitatea partenerului de comunicare și să decidă dacă pot avea încredere în acestea. În cadrul DCCG se utilizează mai multe certificate de cheie publică pentru autenticitate. Prezenta anexă definește certificatele de cheie publică utilizate și modul în care acestea trebuie concepute astfel încât să permită o interoperabilitate largă între statele membre. Aceasta oferă mai multe detalii cu privire la certificatele de cheie publică necesare și oferă îndrumări cu privire la modelele de certificate și perioadele de valabilitate pentru statele membre care doresc să opereze propria lor CSCA. Întrucât DCC-urile trebuie să poată fi verificate pentru un interval de timp definit (începând de la emitere, expiră după o anumită perioadă de timp), este necesar să se definească un model de verificare pentru toate semnăturile aplicate pe certificatele de cheie publică și pe DCC.

2.   Terminologie

Tabelul următor conține abrevierile și terminologia utilizate în prezenta anexă.

Termen	Definiție
Certificat	Sau certificat de cheie publică. Un certificat X.509 v3 care conține cheia publică a unei entități
CSCA	Autoritate Națională de Certificare pentru Semnătură
DCC	Certificatul digital al UE privind COVID. Un document digital semnat care conține informații despre vaccinare, testare sau vindecare
DCCG	Gateway-ul pentru certificatele digitale ale UE privind COVID. Acest sistem este utilizat pentru schimbul de DSC-uri între statele membre
DCCGTA	Certificatul de ancoră de încredere (Trust Anchor) al DCCG. Cheia privată corespunzătoare este utilizată pentru a semna lista tuturor certificatelor CSCA offline
DCCGTLS	Certificatul de server TLS (Transport Layer Security – securitatea nivelurilor de transport) de server eliberat de DCCG.
DSC	Certificatul de semnatar de documente. Certificatul de cheie publică al autorității de semnare a documentelor dintr-un stat membru (de exemplu, un sistem autorizat să semneze DCC-urile). Acest certificat este eliberat de CSCA a statului membru
EC-DSA	Algoritmul de semnătură digitală bazat pe curbe eliptice. Un algoritm de semnătură criptografică bazat pe curbe eliptice
Stat membru	Statul membru al Uniunii Europene
mTLS	TLS reciproc. Protocolul de securitate pe nivelul de transport cu autentificare reciprocă
NB	Sistemul back-end național al unui stat membru
NBCSCA	Certificatul CSCA al unui stat membru (pot exista mai multe)
NBTLS	Certificatul de autentificare TLS la nivel de client aferent unui sistem back-end național
NBUP	Certificatul pe care un sistem back-end național îl utilizează pentru a semna pachete de date care sunt încărcate în DCCG
PKI	Infrastructura de chei publice. Model de încredere bazat pe certificate de cheie publică și pe autorități de certificare
RSA	Algoritmul criptografic asimetric bazat pe factorizarea numerelor întregi, utilizat pentru semnăturile digitale sau pentru criptarea asimetrică

3.   Fluxurile de comunicații și serviciile de securitate ale DCCG

Prezenta secțiune oferă o imagine de ansamblu asupra fluxurilor de comunicații și a serviciilor de securitate din cadrul sistemului DCCG. Acesta definește, de asemenea, cheile și certificatele utilizate pentru a proteja comunicarea, informațiile încărcate, DCC-urile și o listă de încredere semnată care conține toate certificatele CSCA integrate. DCCG funcționează ca un centru de date care face posibil schimbul de pachete de date semnate pentru statele membre.

Pachetele de date încărcate sunt furnizate de DCCG „ca atare”, ceea ce înseamnă că DCCG nu adaugă și nu șterge DSC-uri din pachetele pe care le primește. Sistemul back-end național (NB) al statelor membre trebuie să fie abilitat să verifice integritatea și autenticitatea datelor încărcate de la un capăt la altul. În plus, sistemele back-end naționale și DCCG vor utiliza autentificarea TLS reciprocă pentru a stabili o conexiune securizată. Aceasta este în plus față de semnăturile incluse în datele care fac obiectul schimbului.

3.1.   Autentificarea și stabilirea conexiunii

DCCG utilizează protocolul de securitate pe nivelul de transport (Transport Layer Security – TLS) cu autentificare reciprocă pentru a crea un canal criptat autentificat între sistemul back-end național al statului membru (NB) și mediul gateway-ului. Prin urmare, DCCG deține un certificat de server TLS, abreviat DCCGTLS, iar sistemele back-end naționale dețin un certificat de client TLS – abreviat NBTLS. Modelele de certificate sunt furnizate în secțiunea 5. Fiecare sistem back-end național poate furniza propriul certificat TLS. Acest certificat va fi inclus în mod explicit în lista albă și, prin urmare, poate fi eliberat de o autoritate de certificare de încredere publică (de exemplu, o autoritate de certificare care respectă cerințele de bază ale Forumului autorităților de certificare și al furnizorilor de browsere – Forumul CA/Browser) ori de o autoritate națională de certificare sau poate fi autosemnat. Fiecare stat membru este responsabil de datele sale naționale și de protecția cheii private utilizate pentru stabilirea conexiunii cu DCCG. Abordarea „adu-ți propriul certificat” necesită o procedură de înregistrare și identificare bine definită, precum și proceduri de revocare și de reînnoire, astfel cum sunt descrise în secțiunile 4.1, 4.2 și 4.3. DCCG utilizează o listă albă pe care sunt adăugate certificatele TLS ale sistemelor back-end naționale după ce au fost înregistrate cu succes. Numai sistemele back-end naționale care se autentifică cu o cheie privată ce corespunde unui certificat inclus în lista albă pot stabili o conexiune sigură cu DCCG. DCCG va utiliza, de asemenea, un certificat TLS care să le permită sistemelor back-end naționale să verifice dacă stabilesc într-adevăr o conexiune cu DCCG „reală” și nu cu o entitate răuvoitoare care se prezintă drept DCCG. Certificatul DCCG va fi furnizat sistemelor back-end naționale după ce au fost înregistrate cu succes. Certificatul DCCGTLS va fi emis de o autoritate de certificare de încredere publică (inclusă în toate browserele importante). Responsabilitatea de a verifica dacă au stabilit o conexiune sigură cu DCCG (de exemplu, prin compararea amprentei digitale a certificatului DCCGTLS al serverului la care s-au conectat cu amprenta furnizată după înregistrare) le revine statelor membre.

3.2.   Autoritățile naționale de certificare pentru semnătură și modelul de validare

Statele membre care participă la cadrul DCCG trebuie să utilizeze o CSCA pentru emiterea DSC-urilor. Un stat membru poate avea mai multe CSCA, de exemplu, în cazul deconcentrării regionale. Fiecare stat membru poate fie să utilizeze autoritățile de certificare existente, fie să înființeze o autoritate de certificare specială (eventual autosemnată) pentru sistemul DCC.

Statele membre trebuie să își prezinte certificatul (certificatele) CSCA operatorului DCCG în timpul procedurii oficiale de integrare. După înregistrarea cu succes a statului membru (a se vedea secțiunea 4.1 pentru mai multe detalii), operatorul DCCG va actualiza o listă de încredere semnată cuprinzând toate certificatele CSCA care sunt active în cadrul DCC. Operatorul DCCG va utiliza o pereche specială de chei asimetrice pentru a semna lista de încredere și certificatele într-un mediu offline. Cheia privată nu va fi stocată în sistemul DCCG online, astfel încât compromiterea sistemului online să nu îi permită unui atacator să compromită lista de încredere. Certificatul de ancoră de încredere DCCGTA corespunzător va fi furnizat sistemelor back-end naționale în timpul procesului de integrare.

Statele membre pot obține lista de încredere de pe gateway-ul DCCG pentru procedurile lor de verificare. CSCA este definită ca fiind autoritatea de certificare care eliberează DSC-urile; prin urmare, statele membre care utilizează o ierarhie pe mai multe niveluri a autorităților de certificare (de exemplu, Root CA –> CSCA –> DSC) trebuie să indice autoritatea de certificare subordonată care eliberează DSC-urile. În acest caz, dacă un stat membru utilizează o autoritate de certificare existentă, atunci sistemul DCC va face abstracție de tot ceea ce se află deasupra CSCA și va include în lista albă doar CSCA ca ancoră de încredere (chiar dacă este o autoritate de certificare subordonată). Acest lucru se explică prin faptul că modelul OACI permite doar două niveluri – o CSCA „rădăcină” și un DSC „frunză” semnat doar de CSCA respectivă.

În cazul în care un stat membru operează propria CSCA, acel stat membru este responsabil de funcționarea și gestionarea cheilor respectivei autorități de certificare în condiții de siguranță. CSCA acționează ca ancoră de încredere pentru DSC-uri și, prin urmare, protejarea cheii private a CSCA este esențială pentru integritatea mediului DCC. Modelul de verificare din infrastructura de cheie privată a DCC este modelul shell, care prevede că toate certificatele prezente în validarea traseului certificatelor trebuie să fie valabile la un anumit moment (și anume, la momentul validării semnăturii). Prin urmare, se aplică următoarele restricții:

—	CSCA nu trebuie să emită certificate a căror perioadă de valabilitate o depășește pe cea a certificatului autorității de certificare;

—	semnatarul de documente nu trebuie să semneze documente a căror perioadă de valabilitate o depășește pe cea a DSC;

—	statele membre care operează propria lor CSCA trebuie să definească perioade de valabilitate pentru CSCA respectivă și toate certificatele eliberate și trebuie să se ocupe de reînnoirea certificatelor.

Secțiunea 4.2 conține recomandări privind perioadele de valabilitate.

3.3.   Integritatea și autenticitatea datelor încărcate

Sistemele back-end naționale pot utiliza DCCG pentru a încărca și a descărca pachete de date semnate digital după autentificarea reciprocă reușită. La început, aceste pachete de date conțin DSC-urile statelor membre. Perechea de chei care este utilizată de sistemul back-end național pentru semnătura digitală a pachetelor de date încărcate în sistemul DCCG se numește pereche de chei pentru semnătura de încărcare a sistemului back-end național, iar denumirea abreviată a certificatului de cheie publică corespunzător este certificatul NBUP. Fiecare stat membru își aduce propriul certificat NBUP, care poate fi autosemnat sau emis de o autoritate de certificare existentă, cum ar fi o autoritate de certificare publică (și anume, o autoritate de certificare care eliberează certificatul în conformitate cu cerințele de bază ale forumului CA/Browser). Certificatul NBUP trebuie să fie diferit de orice alt certificat utilizat de statul membru respectiv (și anume de CSCA, de certificatul TLS de client sau de DSC-uri).

Statele membre trebuie să furnizeze certificatul de încărcare operatorului DCCG în timpul procedurii inițiale de înregistrare (a se vedea secțiunea 4.1 pentru mai multe detalii). Fiecare stat membru este responsabil de datele sale naționale și trebuie să protejeze cheia privată utilizată pentru semnarea încărcărilor.

Celelalte state membre pot verifica pachetele de date semnate cu ajutorul certificatelor de încărcare furnizate de DCCG. DCCG verifică autenticitatea și integritatea datelor încărcate, comparându-le cu certificatul de încărcare al sistemului back-end național, înainte ca datele să fie furnizate altor state membre.

3.4.   Cerințe privind arhitectura tehnică a DCCG

Cerințele privind arhitectura tehnică a DCCG sunt următoarele:

—	DCCG utilizează autentificarea TLS reciprocă pentru a stabili o conexiune criptată autentificată cu sistemele back-end naționale. Prin urmare, DCCG actualizează periodic lista albă a certificatelor de client NBTLS înregistrate;

—	DCCG utilizează două certificate digitale (DCCGTLS și DCCGTA), cu două perechi de chei distincte. Cheia privată a perechii de chei DCCGTA se actualizează offline (nu pe componentele online ale DCCG);

—	DCCG actualizează periodic lista de încredere a certificatelor NBCSCA, care este semnată cu cheia privată DCCGTA;

—	criptarea utilizată trebuie să îndeplinească cerințele prevăzute în secțiunea 5.1.

4.   Gestionarea ciclului de viață a certificatelor

4.1.   Înregistrarea sistemelor back-end naționale

Pentru a participa la sistemul DCCG, statele membre trebuie să se înregistreze la operatorul DCCG. Prezenta secțiune descrie procedura tehnică și operațională care trebuie urmată pentru a înregistra un sistem back-end național.

Operatorul DCCG și statul membru trebuie să facă schimb de informații privind persoanele de contact pentru aspecte tehnice legate de procesul de integrare. Se presupune că persoanele de contact pentru aspecte tehnice sunt legitimate de statele lor membre și că identificarea/autentificarea se efectuează prin intermediul altor canale. De exemplu, autentificarea poate fi realizată atunci când persoana de contact pentru aspecte tehnice a unui stat membru transmite prin e-mail certificatele sub formă de fișiere criptate, cu parolă, și comunică telefonic parola corespunzătoare operatorului DCCG. De asemenea, pot fi utilizate și alte canale securizate definite de operatorul DCCG.

Statul membru trebuie să furnizeze trei certificate digitale în timpul procesului de înregistrare și identificare:

—	certificatul TLS de tip NBTLS al statului membru

—	certificatul de încărcare de tip NBUP al statului membru

—	certificatul (certificatele) CSCA de tip NBCSCA al(e) statului membru

Toate certificatele furnizate trebuie să respecte cerințele definite în secțiunea 5. Operatorul DCCG va verifica dacă certificatul transmis respectă cerințele din secțiunea 5. După identificare și înregistrare, operatorul DCCG:

—	adaugă certificatul (certificatele) NBCSCA pe lista de încredere semnată cu cheia privată care corespunde cheii publice DCCGTA;

—	adaugă certificatul NLSTLS pe lista albă a punctului final TLS din cadrul DCCG;

—	adaugă certificatul NBUP în sistemul DCCG;

—	furnizează statului membru certificatul DCCGTA și certificatul de cheie publică DCCGTLS.

4.2.   Autoritățile de certificare, perioadele de valabilitate și reînnoirea

În cazul în care un stat membru dorește să opereze propria sa CSCA, certificatele CSCA pot fi certificate autosemnate. Acestea acționează ca ancoră de încredere a statului membru și, prin urmare, statul membru trebuie să protejeze cu fermitate cheia privată corespunzătoare cheii publice a certificatului CSCA. Se recomandă ca statele membre să utilizeze un sistem offline pentru CSCA-urile proprii, și anume un sistem informatic care nu este conectat la nicio rețea. Pentru a avea acces la sistem, trebuie utilizată o metodă de control care presupune mai multe persoane (de exemplu, urmând principiul celor patru ochi). După semnarea DSC-urilor, trebuie efectuate controale operaționale, iar sistemul care deține cheia privată a CSCA se stochează în condiții de siguranță, cu controale stricte al accesului. Pentru a asigura o protecție suplimentară a cheii private a CSCA se pot utiliza module de securitate hardware sau carduri inteligente. Certificatele digitale cuprind o perioadă de valabilitate care impune reînnoirea certificatelor. Reînnoirea este necesară pentru a utiliza noi chei criptografice și pentru a adapta dimensiunile cheilor atunci când apar noi îmbunătățiri ale tehnicii de calcul sau atunci când noi atacuri amenință securitatea algoritmului criptografic utilizat. Se aplică modelul shell (a se vedea secțiunea 3.2).

Se recomandă următoarele perioade de valabilitate, având în vedere valabilitatea de un an a certificatelor digitale privind COVID:

—	CSCA: 4 ani

—	DSC: 2 ani

—	Certificate de încărcare: 1-2 ani

—	Certificate TLS de autentificare la nivel de client: 1-2 ani

Pentru o reînnoire în timp util, se recomandă următoarele perioade de utilizare pentru cheile private:

—	CSCA: 1 an

—	DSC: 6 luni

Statele membre trebuie să creeze noi certificate de încărcare și noi certificate TLS în timp util, de exemplu, cu o lună înainte de expirare, pentru a permite buna funcționare a certificatelor respective. Ar trebui ca certificatele CSCA și DSC-urile să fie reînnoite cu cel puțin o lună înainte de încheierea perioadei de utilizare a cheii private (având în vedere procedurile operaționale necesare). Statele membre trebuie să îi furnizeze operatorului DCCG certificate CSCA, certificate de încărcare și certificate TLS actualizate. Certificatele expirate trebuie eliminate de pe lista albă și de pe lista de încredere.

Statele membre și operatorul DCCG trebuie să urmărească valabilitatea propriilor certificate. Nu există nicio entitate centrală care să țină evidența valabilității certificatelor și să informeze participanții.

4.3.   Revocarea certificatelor

În general, certificatele digitale pot fi revocate de autoritatea de certificare emitentă prin utilizarea listelor certificatelor revocate sau de respondentul la Protocolul de verificare online a stării certificatelor (Online Certificate Status Protocol – OCSP). Ar trebui ca CSCA-urile pentru sistemul DCC să furnizeze liste ale certificatelor revocate (CRL). Chiar dacă aceste liste nu sunt utilizate în prezent de alte state membre, ar trebui ca ele să fie integrate în aplicațiile viitoare. În cazul în care o CSCA decide să nu furnizeze liste ale certificatelor revocate, certificatele DSC ale respectivei CSCA vor trebui reînnoite atunci când listele certificatelor revocate vor deveni obligatorii. Verificatorii nu ar trebui să utilizeze protocolul OCSP pentru validarea DSC-urilor, ci listele certificatelor revocate. Se recomandă ca sistemul back-end național să efectueze validarea necesară a DSC-urilor descărcate de pe gateway-ul DCC și să transmită mai departe validatorilor naționali ai DCC-urilor doar un set de DSC-uri de încredere și validate. Ar trebui ca validatorii DCC să nu efectueze nicio verificare a revocării în ceea ce privește DSC în cadrul procesului lor de validare. Unul dintre motive este protejarea vieții private a deținătorilor DCC-urilor prin evitarea oricărei posibilități ca utilizarea unei anumite DSC să poată fi monitorizată de către respondentul OCSP asociat.

Statele membre își pot elimina DSC-urile din DCCG pe cont propriu, utilizând certificate de încărcare și certificate TLS valabile. Eliminarea unui DSC înseamnă că toate DCC-urile eliberate cu acest certificat își pierd valabilitatea în momentul în care statele membre obțin listele DSC actualizate. Este esențial să se asigure protecția materialelor de cheie privată corespunzătoare DSC-urilor. Statele membre trebuie să informeze operatorul DCCG atunci când sunt nevoite să revoce certificate de încărcare sau certificate TLS, de exemplu din cauza compromiterii sistemului back-end național. Operatorul DCCG poate apoi să retragă încrederea acordată certificatului afectat, de exemplu, prin eliminarea acestuia de pe lista albă a TLS. Operatorul DCCG poate elimina certificatele de încărcare din baza de date a DCCG. Pachetele semnate cu cheia privată corespunzătoare respectivelor certificate de încărcare își pierd valabilitatea în momentul în care sistemul back-end național retrage încrederea acordată certificatelor de încărcare revocate. În cazul în care un certificat CSCA trebuie revocat, statele membre trebuie să informeze operatorul DCCG, precum și alte state membre cu care au relații de încredere. Operatorul DCCG va emite o nouă listă de încredere, pe care certificatul afectat nu va mai figura. Toate DSC-urile emise de respectiva CSCA își pierd valabilitatea în momentul în care statele membre își actualizează registrul de încredere („trust store”) back-end național. În cazul în care certificatul DCCGTLS sau certificatul DCCGTA trebuie revocate, operatorul DCCG și statele membre trebuie să colaboreze pentru a stabili o nouă listă de conexiuni TLS de încredere și o nouă listă de încredere.

5.   Modele de certificate

Prezenta secțiune stabilește cerințe și îndrumări criptografice, precum și cerințe privind modelele de certificate. De asemenea, aceasta definește modelele de certificate pentru certificatele DCCG.

5.1.   Cerințe criptografice

Algoritmii criptografici și suitele de cifrare TLS trebuie alese pe baza recomandării actuale a Biroului federal german pentru securitatea informațiilor (BSI) sau a Comitetului consultativ privind securitatea sistemelor informatice (Advisory Committee on information systems security, SOG-IS). Aceste recomandări sunt similare cu recomandările altor instituții și organizații de standardizare. Recomandările pot fi găsite în orientările tehnice TR 02102-1 și TR 02102-2 (1) sau în mecanismele criptografice convenite în cadrul SOG-IS (2).

5.1.1.   Cerințe privind DSC

Trebuie aplicate cerințele prevăzute în anexa I, secțiunea 3.2.2. Prin urmare, se recomandă insistent ca semnatarii de documente să utilizeze algoritmul de semnătură digitală bazat pe curbe eliptice (ECDSA) cu NIST-p-256 (astfel cum este definit în apendicele D la standardul federal de prelucrare a informațiilor FIPS PUB 186-4). Nu sunt acceptate alte curbe eliptice. Din cauza restricțiilor de spațiu ale DCC, statele membre nu ar trebui să utilizeze algoritmul RSA-PSS, chiar dacă utilizarea acestuia ca algoritm alternativ este permisă. În cazul în care statele membre utilizează algoritmul RSA-PSS, acestea ar trebui să utilizeze o dimensiune a modulului de 2048 biți sau de maximum 3072 biți. Pentru semnătura DSC trebuie utilizat, ca funcție de distribuire (hash) criptografică, algoritmul hash securizat SHA-2 cu o lungime a rezultatului ≥ 256 biți (a se vedea ISO/IEC 10118-3:2004).

5.1.2.   Cerințe privind certificatele TLS, certificatele de încărcare și certificatele CSCA

Pentru certificatele digitale și semnăturile criptografice în contextul DCCG, principalele cerințele privind algoritmii criptografici și lungimea cheii sunt rezumate în următorul tabel (în 2021):

Algoritmul de semnătură	Dimensiunea cheii	Funcția de distribuire (hash)
EC-DSA	Min. 250 biți	SHA-2 cu o lungime a rezultatului ≥ 256 biți
RSA-PSS (padding recomandat) RSA-PKCS #1 v1.5 (padding tradițional)	O dimensiune a modulului (N) RSA de min. 3000 biți, cu un exponent public > 2^16	SHA-2 cu o lungime a rezultatului ≥ 256 biți
DSA	Numărul prim p de min. 3000 biți, cheia q de 250 biți	SHA-2 cu o lungime a rezultatului ≥ 256 biți

Curba eliptică recomandată pentru EC-DSA este NIST-p-256, datorită punerii sale în aplicare pe scară largă.

5.2.   Certificatul CSCA (NBCSCA)

Tabelul următor oferă îndrumări cu privire la modelul de certificat NBCSCA, în cazul în care un stat membru decide să opereze propria CSCA pentru sistemul DCC.

Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

Câmp	Valoare
Subiect	cn = <denumire comună unică ce nu poate fi lăsată necompletată>, o = <furnizor>, c = <statul membru care operează CSCA>
Utilizarea cheii	semnarea certificatului, semnarea CRL (cel puțin)
Restricții de bază	CA = adevărat, restricții de lungime a traseului = 0

Denumirea subiectului nu trebuie să fie lăsată necompletată și trebuie să fie unică în statul membru specificat. Codul de țară (c) trebuie să corespundă statului membru care va utiliza certificatul CSCA. Certificatul trebuie să conțină un identificator unic al cheii subiectului (SKI), în conformitate cu RFC 5280 (3).

5.3.   Certificatul de semnatar de documente (DSC)

Tabelul următor oferă îndrumări cu privire la DSC. Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

Câmp	Valoare
Nr. de serie	numărul de serie unic
Subiect	cn = <denumire comună unică ce nu poate fi lăsată necompletată>, o = <furnizor>, c = <statul membru care utilizează acest DSC>
Utilizarea cheii	semnătură digitală (cel puțin)

DSC trebuie să fie semnat cu cheia privată care corespunde unui certificat CSCA utilizat de statul membru.

Se utilizează următoarele extensii:

—	Certificatul trebuie să conțină un identificator pentru cheia publică a autorității (Authority Key Identifier – AKI) care corespunde identificatorului cheii subiectului (Subject Key Identifier – SKI) al certificatului CSCA emitente

—	Certificatul ar trebui să conțină un identificator unic al cheii subiectului (în conformitate cu RFC 5280 (4)).

În plus, ar trebui ca certificatul să conțină extensia punctului de distribuție a CRL care trimite la lista certificatelor revocate (CRL) furnizată de CSCA care a emis DSC.

DSC poate conține o extensie de utilizare extinsă a cheii cu zero sau mai mulți identificatori ai politicii de utilizare a cheii care limitează tipurile de certificate HCERT pe care acest certificat este autorizat să le verifice. În cazul în care sunt prezenți unul sau mai mulți identificatori, verificatorii trebuie să verifice utilizarea cheii prin comparație cu certificatul HCERT stocat. În acest scop, pentru câmpul extendedKeyUsage sunt definite următoarele valori:

Câmp	Valoare
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.1 pentru emitenții de certificate de testare
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.2 pentru emitenții de certificate de vaccinare
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.3 pentru emitenții de certificate de vindecare

În absența oricărei extensii a utilizării cheii (adică fără extensii sau cu extensii având valoarea zero), acest certificat poate fi utilizat pentru a valida orice tip de certificat HCERT. Alte documente pot defini și alți identificatori relevanți ai politicii de utilizare extinsă a cheii folosiți la validarea certificatelor HCERT.

5.4.   Certificate de încărcare (NBUP)

Tabelul următor oferă îndrumări cu privire la certificatul de încărcare pentru sistemul back-end național. Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

Câmp	Valoare
Subiect	cn = <denumire comună unică ce nu poate fi lăsată necompletată>, o = <furnizor>, c = <statul membru care utilizează acest certificat de încărcare>
Utilizarea cheii	semnătură digitală (cel puțin)

5.5.   Certificatul de autentificare TLS la nivel de client aferent unui sistem back-end național (NBTLS)

Tabelul următor oferă îndrumări cu privire la certificatul de autentificare TLS la nivel de client aferent unui sistem back-end național. Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

Câmp	Valoare
Subiect	cn = <denumire comună unică ce nu poate fi lăsată necompletată>, o = <furnizor>, c = <statul membru în sistemul back-end național>
Utilizarea cheii	semnătură digitală (cel puțin)
Utilizarea extinsă a cheii	autentificare la nivel de client (1.3.6.1.5.5.7.3.2)

Certificatul poate conține, de asemenea, autentificarea la nivel de server (1.3.6.1.5.5.7.3.1) aferentă utilizării extinse a cheii, dar aceasta nu este necesară.

5.6.   Certificatul de semnătură pentru lista de încredere (DCCGTA)

Următorul tabel definește certificatul pentru ancora de încredere a DCCG.

Câmp	Valoare
Subiect	cn = Gateway-ul pentru adeverințele electronice verzi  (5) , o = <furnizor>, c = <țară>
Utilizarea cheii	semnătură digitală (cel puțin)

5.7.   Certificatele de server TLS ale DCCG (DCCGTLS)

Următorul tabel definește certificatul TLS al DCCG.

Câmp	Valoare
Subiect	CN = < FQDN (Fully Qualified Domain Name – numele de domeniu complet calificat) sau adresa IP a DCCG >, o = <furnizor>, c = <țară>
SubjectAltName	dNSName: < denumirea DNS al DCCG>sau iPAddress: <adresa IP a DCCG>
Utilizarea cheii	semnătură digitală (cel puțin)
Utilizarea extinsă a cheii	autentificare la nivel de server (1.3.6.1.5.5.7.3.1)

Certificatul poate conține, de asemenea, autentificarea la nivel de client (1.3.6.1.5.5.7.3.2) aferentă utilizării extinse a cheii, dar aceasta nu este necesară.

Certificatul TLS al DCCG trebuie eliberat de o autoritate de certificare de încredere publică (inclusă în toate browserele și sistemele de operare importante, în conformitate cu cerințele de bază ale forumului CA/Browser).

---

(1)  BSI - Orientări tehnice TR-02102 (bund.de)

(2)  SOG-IS - documente justificative (sogis.eu).

(3)  rfc5280 (ietf.org)

(4)  rfc5280 (ietf.org)

(5)  În acest context a fost menținut termenul „adeverință electronică verde” în loc de „certificat digital al UE privind COVID”, deoarece acesta este termenul care a fost integrat și utilizat în certificat înainte ca colegiuitorii să decidă să folosească un nou termen.