Article premier

L’article 58 du règlement (UE) 2016/1628 est modifié comme suit:

1)

Au paragraphe 5, l’alinéa suivant est ajouté: «Pour les moteurs de toutes les sous-catégories dont la date de mise sur le marché des moteurs de la phase V énoncée à l’annexe III est le 1er janvier 2020, à l’exception des moteurs visés aux deuxième et troisième alinéas, la période de transition est prolongée de neuf mois et la période de dix-huit mois visée au premier alinéa est prolongée de six mois.»

2)	Au paragraphe 7, le point suivant est ajouté: «e) trente-trois mois à compter de la date applicable de mise sur le marché de moteurs énoncée à l’annexe III, dans le cas indiqué au paragraphe 5, sixième alinéa.»

Article 2

Le présent règlement entre en vigueur le jour de sa publication au Journal officiel de l’Union européenne.

Article premier

Modification du règlement (UE) 2020/1579

Le règlement (UE) 2020/1579 est modifié conformément à la partie A de l’annexe du présent règlement.

Article 2

Modification du règlement (UE) 2021/92

Le règlement (UE) 2021/92 est modifié conformément aux parties B et C de l’annexe du présent règlement.

Article 3

Entrée en vigueur et application

Le présent règlement entre en vigueur le jour suivant celui de sa publication au Journal officiel de l’Union européenne.

L’article 1er est applicable à partir du 1er janvier 2021.

L’article 2 est applicable à partir du 1er juillet 2021.

ANNEXE

PARTIE A

À l’annexe du règlement (UE) 2020/1579, le tableau des possibilités de pêche pour le hareng dans les sous-divisions CIEM 30 et 31 est remplacé par le tableau suivant:

PARTIE B

L’annexe I A du règlement (UE) 2021/92 est modifiée comme suit:

1)

Le tableau des possibilités de pêche pour le sprat et les prises accessoires associées dans les eaux de l’Union de la division CIEM 3a est remplacé par le tableau suivant: «Espèce: Sprat et prises accessoires associées Sprattus sprattus Zone: 3a (SPR/03A.) Danemark 13 086  (1)  (2) TAC analytique Allemagne 27  (1)  (2) Suède 4 951  (1)  (2) Union 18 064  (1)  (2)   TAC 19 529  (2)

2)

Le tableau des possibilités de pêche pour le sprat et les prises accessoires associées dans les eaux du Royaume-Uni et de l’Union de la sous-zone CIEM 4 et dans les eaux du Royaume-Uni de la division CIEM 2a est remplacé par le tableau suivant: «Espèce: Sprat et prises accessoires associées Sprattus sprattus Zone: Eaux du Royaume-Uni et de l’Union de la zone 4; eaux du Royaume-Uni de la zone 2a (SPR/2AC4-C) Belgique 993  (3)  (4) TAC analytique Danemark 78 553  (3)  (4) Allemagne 993  (3)  (4) France 993  (3)  (4) Pays-Bas 993  (3)  (4) Suède 1 330  (3)  (4)  (5) Union 83 855  (3)  (4) Norvège 0  (3) Îles Féroé 0  (3)  (6) Royaume-Uni 3 331  (3)   TAC 87 186  (3)

3)

Le tableau des possibilités de pêche pour l’anchois commun dans les sous-zones CIEM 9 et 10 et dans les eaux de l’Union de la division Copace 34.1.1 est remplacé par le tableau suivant: «Espèce: Anchois commun Engraulis encrasicolus Zone: 9 et 10; eaux de l’Union de la zone Copace 34.1.1 (ANE/9/3411) Espagne 2 747  (7) TAC de précaution Portugal 2 997  (7) Union 5 744  (7)   TAC 5 744  (7)

PARTIE C

À l’annexe VI du règlement (UE) 2021/92, le point 6 est remplacé par le texte suivant:

«6.

Capacité maximale d’élevage et d’engraissement de thon rouge pour chaque État membre et approvisionnement maximal en thons rouges capturés à l’état sauvage que chaque État membre peut attribuer à ses fermes dans l’Atlantique Est et en Méditerranée. Tableau A Capacité maximale d’élevage et d’engraissement de thon rouge   Nombre de fermes Capacité (en tonnes) Espagne 10 11 852 Italie 13 9 564 Grèce 2 2 100 Chypre 3 3 000 Croatie 7 7 880 Malte 6 14 511 Tableau B (8) Approvisionnement maximal en thons rouges capturés à l’état sauvage (en tonnes) Espagne 6 850 Italie 1 739,5 Grèce 785 Chypre 2 195 Croatie 2 947 Malte 10 260,5 Portugal 350

---

(1)  Jusqu’à 5 % du quota peuvent être constitués de prises accessoires de merlan et d’églefin (OTH/*03A.). Les prises accessoires de merlan et d’églefin imputées sur le quota conformément à la présente disposition et les prises accessoires d’espèces imputées sur le quota conformément à l’article 15, paragraphe 8, du règlement (UE) no 1380/2013 ne dépassent pas, au total, 9 % du quota.

(2)  Ce quota ne peut être pêché que du 1er juillet 2021 au 30 juin 2022. Des transferts de ce quota peuvent être effectués vers les eaux du Royaume-Uni et de l’Union des zones 2a et 4. Toutefois, ces transferts sont notifiés au préalable à la Commission et au Royaume-Uni.»

(3)  Le quota peut être pêché uniquement du 1er juillet 2021 au 30 juin 2022.

(4)  Jusqu’à 2 % du quota peuvent être constitués de prises accessoires de merlan (OTH/*2AC4C). Les prises accessoires de merlan imputées sur le quota conformément à la présente disposition et les prises accessoires d’espèces imputées sur le quota conformément à l’article 15, paragraphe 8, du règlement (UE) no 1380/2013 ne dépassent pas, au total, 9 % du quota.

(5)  Y compris le lançon.

(6)  Peut contenir jusqu’à 4 % de prises accessoires de hareng.»

(7)  Le quota peut être pêché uniquement du 1er juillet 2021 au 30 septembre 2021.»

(8)  La capacité d’élevage du Portugal, qui atteint 500 tonnes, est couverte par la capacité inutilisée de l’Union figurant dans le tableau A.».

Article premier

Objet et champ d’application

Le présent règlement établit des mesures spéciales de lutte contre l’infection par le virus de la dermatose nodulaire contagieuse (DNC) qui doivent être appliquées pendant une période limitée par les États membres dans les zones de leur territoire où:

a)	un foyer de cette maladie a été confirmé;

b)	aucun foyer de cette maladie n’a été confirmé, mais ils décident de procéder à la vaccination contre cette maladie conformément aux dispositions du présent règlement.

Les mesures spéciales de lutte contre la maladie prévues par le présent règlement s’appliquent aux bovins, aux sous-produits et aux produits germinaux issus de ces bovins, en sus des mesures de lutte contre la maladie applicables aux zones de protection et de surveillance et aux autres zones réglementées établies par l’autorité compétente d’un État membre à la suite de l’apparition d’un foyer d’infection par le virus de la DNC, conformément à l’article 21, paragraphe 1, du règlement délégué (UE) 2020/687.

Article 2

Définitions

Aux fins du présent règlement, les définitions figurant dans le règlement délégué (UE) 2020/687 s’appliquent.

Les définitions suivantes s’appliquent également:

1)	«bovin»: un animal de l’une des espèces d’ongulés appartenant aux genres Bison, Bos (y compris les sous-genres Bos, Bibos, Novibos, Poephagus) et Bubalus (y compris le sous-genre Anoa) ainsi qu’un animal issu d’un croisement de ces espèces;

2)

«zone réglementée I»: une partie du territoire d’un État membre répondant à une délimitation géographique précise: a) située en dehors d’une zone où un foyer d’infection par le virus de la DNC a été confirmé; b) où la vaccination contre l’infection par le virus de la DNC est pratiquée conformément à l’article 3, paragraphe 2; c) figurant ou non à l’annexe I, partie I; d) soumise aux dispositions spéciales de lutte contre la maladie prévues aux articles 3 à 6;

3)

«zone réglementée II»: une partie du territoire d’un État membre répondant à une délimitation géographique précise: a) qui comprend une zone où un foyer d’infection par le virus de la DNC a été confirmé; b) où la vaccination contre l’infection par le virus de la DNC est pratiquée conformément à l’article 3, paragraphe 1; c) figurant ou non à l’annexe I, partie II; d) soumise aux dispositions spéciales de lutte contre la maladie prévues aux articles 3 à 6.

Article 3

Établissement des zones réglementées I et II

Article 4

Interdictions de mouvements dans les zones réglementées I et II

Article 5

Inscription d’une zone réglementée II à l’annexe I, partie II

Lorsque, pour des raisons épidémiologiques, une zone d’un État membre couverte totalement ou partiellement par une zone réglementée II établie conformément à l’article 3, paragraphe 1 est inscrite à l’annexe I, partie II, l’autorité compétente:

a)	adapte immédiatement les limites de la zone réglementée II initiale de manière à ce qu’elle corresponde à la zone réglementée II décrite dans ladite annexe;

b)	étend immédiatement la vaccination prévue à l’article 3, paragraphe 1, point b), et les interdictions prévues à l’article 4, paragraphe 1, à la zone réglementée II décrite dans ladite annexe.

Article 6

Inscription d’une zone réglementée I à l’annexe I, partie I

Article 7

Dérogations à l’interdiction de mouvements d’envois de bovins au départ d’une zone réglementée I

Par dérogation à l’interdiction prévue à l’article 4, paragraphe 2, point a), l’autorité compétente peut autoriser les mouvements d’envois de bovins au départ d’établissements situés dans une zone réglementée I vers:

a)

une zone réglementée I ou II du même État membre ou d’un autre État membre, pourvu que toutes les conditions suivantes soient remplies: i) les bovins de l’envoi ont été vaccinés contre l’infection par le virus de la DNC au moins vingt-huit jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date; ii) tous les autres bovins détenus dans le même établissement d’origine que les bovins de l’envoi ont été vaccinés contre l’infection par le virus de la DNC au moins vingt-huit jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date ou se trouvent encore dans la période d’immunité induite par une vaccination antérieure ou par l’immunité maternelle à la date d’expédition; iii) les bovins de l’envoi ont été détenus dans leur établissement d’origine depuis leur naissance ou pendant une période continue d’au moins vingt-huit jours avant la date d’expédition; et iv) l’autorité compétente effectue: — un examen clinique, avec des résultats favorables, de tous les bovins détenus dans l’établissement d’origine de ces envois, y compris les bovins de ces envois, — si nécessaire, un examen en laboratoire, avec des résultats favorables, des bovins détenus dans l’établissement d’origine de ces envois, y compris les bovins de ces envois;

b)

toute destination — y compris des zones situées en dehors des zones réglementées, d’autres zones réglementées I ou des zones réglementées II — dans le même État membre ou dans d’autres États membres, si, outre les conditions énoncées aux points a) ii), a) iii) et a) iv), du présent article, toutes les conditions suivantes sont remplies: i) les bovins de l’envoi ont été vaccinés contre l’infection par le virus de la DNC au moins soixante jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à la date d’expédition; ii) dans un rayon d’au moins 20 km autour de l’établissement d’origine de ces envois, aucun foyer d’infection par le virus de la DNC n’est apparu au cours d’une période d’au moins trois mois avant la date d’expédition; et iii) tous les bovins détenus dans un rayon de 50 km autour de l’établissement d’origine de l’envoi ont été vaccinés ou revaccinés contre l’infection par le virus de la DNC au moins soixante jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date ou couverts par l’immunité maternelle;

c)

toute destination — y compris des zones situées en dehors des zones réglementées, d’autres zones réglementées I ou des zones réglementées II — dans d’autres États membres ou des territoires dans des pays tiers, si, outre les conditions énoncées au point a) du présent article, les conditions suivantes sont remplies: i) les animaux offrent toutes les garanties sur le plan zoosanitaire, sur la base du résultat favorable d’une évaluation des risques portant sur les mesures de lutte contre la propagation de l’infection par le virus de la DNC exigée par l’autorité compétente de l’État membre d’origine et approuvée par l’autorité compétente des États membres de passage ou de destination, avant la date d’expédition; ii) il n’y a eu aucun foyer confirmé d’infection par le virus de la DNC dans un rayon d’au moins 20 km autour de l’établissement d’origine de ces envois pendant une période d’au moins trois mois avant la date d’expédition; et iii) tous les bovins détenus dans un rayon de 50 km autour de l’établissement d’origine de l’envoi ont été vaccinés ou revaccinés contre l’infection par le virus de la DNC au moins soixante jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date ou couverts par l’immunité maternelle.

Article 8

Dérogations aux interdictions de mouvements d’envois de bovins au départ d’une zone réglementée II

Par dérogation à l’interdiction prévue à l’article 4, paragraphe 1, point a), l’autorité compétente peut autoriser les mouvements d’envois de bovins au départ d’établissements situés dans une zone réglementée II vers:

a)

toute destination, y compris des zones situées en dehors des zones réglementées, des zones réglementées I, d’autres zones réglementées II, dans le même État membre et d’autres États membres, pourvu que toutes les conditions suivantes soient remplies: i) les bovins de l’envoi offrent toutes les garanties sur le plan zoosanitaire, sur la base du résultat favorable d’une évaluation des risques portant sur les mesures de lutte contre la propagation de l’infection par le virus de la DNC exigée par l’autorité compétente de l’État membre d’origine et approuvée par l’autorité compétente des États membres de destination ou de passage, avant la date d’expédition; ii) les bovins de l’envoi ont été vaccinés contre l’infection par le virus de la DNC au moins vingt-huit jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date; iii) tous les autres bovins détenus dans le même établissement d’origine que les bovins de l’envoi ont été vaccinés contre l’infection par le virus de la DNC au moins vingt-huit jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date ou se trouvent encore dans la période d’immunité induite par une vaccination antérieure ou par l’immunité maternelle à cette date; iv) l’autorité compétente effectue: — un examen clinique, avec des résultats favorables, de tous les bovins détenus dans l’établissement d’origine de ces envois, y compris les bovins de ces envois, — si nécessaire, un examen en laboratoire, avec des résultats favorables, des bovins détenus dans l’établissement d’origine de ces envois, y compris les bovins de ces envois; v) les bovins ont séjourné depuis leur naissance, ou pendant une période d’au moins vingt-huit jours avant la date d’expédition, dans un établissement où, dans un rayon d’au moins 20 km, aucun foyer d’infection par le virus de la DNC n’a été confirmé au cours des trois mois précédant la date d’expédition; vi) tous les bovins dans un rayon de 50 km autour de l’établissement d’origine de l’envoi ont été vaccinés ou revaccinés contre l’infection par le virus de la DNC, conformément aux règles relatives aux plans de vaccination figurant à l’annexe II, au moins soixante jours avant la date d’expédition, et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin ou couverts par l’immunité maternelle;

b)

toute destination située dans une autre zone réglementée II du même État membre, pourvu que toutes les conditions suivantes soient remplies: i) tous les autres bovins détenus dans l’établissement d’origine de ces envois ont été vaccinés contre l’infection par le virus de la DNC au moins vingt-huit jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date ou se trouvent encore dans la période d’immunité induite par une vaccination antérieure ou par l’immunité maternelle à cette date; et ii) les bovins ont été vaccinés contre l’infection par le virus de la DNC au moins vingt-huit jours avant la date d’expédition et se trouvent encore dans la période d’immunité conformément aux instructions du fabricant du vaccin à cette date, ou sont des descendants non vaccinés âgés de moins de quatre mois, nés de mères vaccinées au moins vingt-huit jours avant la parturition qui se trouvaient encore dans la période d’immunité à la date de la parturition selon le fabricant du vaccin, et peuvent être déplacés vers un autre établissement.

Article 9

Conditions spécifiques relatives à l’autorisation de mouvements d’envois de bovins effectués à partir de zones réglementées I et II à destination d’un abattoir situé en dehors de ces zones, sur le territoire du même État membre, en vue d’un abattage immédiat

Par dérogation aux interdictions prévues à l’article 4, paragraphe 2, point a), et à l’article 4, paragraphe 1, point a), du présent règlement, l’autorité compétente de l’État membre peut autoriser les mouvements d’envois de bovins effectués à partir de zones réglementées I et II à destination d’un abattoir situé en dehors de ces zones, sur le territoire du même État membre, pourvu que les bovins soient déplacés en vue d’un abattage immédiat dans le respect des conditions générales énoncées à l’article 28, paragraphes 2 à 5, et à l’article 28, paragraphe 7, du règlement délégué (UE) 2020/687.

Article 10

Dérogations à l’interdiction des mouvements d’envois de sperme, d’ovules et d’embryons de bovins au départ des zones réglementées I et II

Article 11

Dérogations à l’interdiction des mouvements de sous-produits animaux non transformés issus de bovins au départ de zones réglementées I

Par dérogation à l’interdiction prévue à l’article 4, paragraphe 2, point c), l’autorité compétente d’un État membre peut autoriser les mouvements d’envois de sous-produits animaux non transformés issus de bovins au départ d’établissements situés dans une zone réglementée I vers:

a)	toute destination située dans le même État membre ou toute destination située dans des zones réglementées I ou II d’un autre État membre;

b)

dans le cas d’envois de cuirs et de peaux, toute destination située dans une zone du même État membre ou d’un autre État membre ou pays tiers, pourvu que l’une des conditions suivantes soit remplie: i) les cuirs et peaux traités ont été soumis à l’un des traitements visés à l’annexe I, point 28 b) à 28 e), du règlement (UE) no 142/2011 de la Commission (10); ou ii) les cuirs et peaux traités ont été soumis à l’un des traitements prévus à l’annexe III, section XIV, chapitre I, point (4) b) ii), du règlement (CE) no 853/2004 du Parlement européen et du Conseil (11), et ont fait l’objet de toutes les précautions nécessaires pour éviter une recontamination par des agents pathogènes après le traitement.

Article 12

Dérogation à l’interdiction des mouvements d’envois de sous-produits animaux non transformés issus de bovins au départ de zones réglementées II

Par dérogation à l’interdiction prévue à l’article 4, paragraphe 1, point c), l’autorité compétente d’un État membre peut autoriser les mouvements d’envois de sous-produits animaux non transformés issus de bovins au départ d’établissements situés dans une zone réglementée II vers:

a)

dans le cas de sous-produits animaux non transformés autres que les cuirs et les peaux, toute destination située dans le même État membre ou toute destination située dans des zones réglementées I ou II d’un autre État membre, à condition que les sous-produits animaux non transformés soient expédiés sous la surveillance officielle des autorités compétentes en vue de leur transformation ou de leur élimination dans une usine agréée conformément à l’article 24 du règlement (CE) no 1069/2009 du Parlement européen et du Conseil (12);

b)

dans le cas de cuirs et peaux de bovins: i) toute destination située dans une zone réglementée II du même État membre ou d’un autre État membre, pourvu qu’il s’agisse de cuirs et de peaux bruts non traités destinés à la consommation humaine ou de cuirs et de peaux non traités expédiés sous la surveillance officielle des autorités compétentes pour être transformés ou éliminés dans une usine agréée; ii) toute destination située dans le même État membre ou dans un autre État membre, pourvu que les conditions prévues à l’article 11, point b), soient remplies;

c)

dans le cas du colostrum, du lait et de produits laitiers, toute destination située dans une zone du même État membre ou d’un autre État membre, pourvu qu’ils aient été soumis à un traitement d’atténuation des risques d’infection par le virus de la DNC, conformément à l’annexe VII du règlement délégué (UE) 2020/687.

Article 13

Obligations des opérateurs en matière de certificats zoosanitaires pour les mouvements d’envois de bovins provenant de zones réglementées I et II en dehors de ces zones

Les opérateurs ne déplacent les envois de bovins en provenance de zones réglementées I et II en dehors de ces zones au sein du même État membre ou vers un autre État membre dans les cas régis par les articles 7, 8 et 9 du présent règlement que si les animaux à déplacer sont accompagnés du certificat zoosanitaire prévu à l’article 73 du règlement délégué (UE) 2020/688 de la Commission (13) comprenant au moins une des attestations suivantes de conformité avec les exigences prévues par le présent règlement:

a)	«Bovins provenant d’une zone réglementée I en conformité avec les mesures spéciales de lutte contre l’infection par le virus de la DNC prévues à l’article 7 du règlement d’exécution (UE) 2021/1070 de la Commission.»;

b)	«Bovins provenant d’une zone réglementée II en conformité avec les mesures spéciales de lutte contre l’infection par le virus de la DNC prévues à l’article 8 du règlement d’exécution (UE) 2021/1070 de la Commission.»;

c)	«Bovins provenant d’une zone réglementée I ou II en conformité avec les mesures spéciales de lutte contre l’infection par le virus de la DNC prévues à l’article 9 du règlement d’exécution (UE) 2021/1070 de la Commission.».

Néanmoins, dans les cas de mouvements d’envois visés au premier alinéa du présent article au sein du même État membre, l’autorité compétente peut décider qu’un certificat zoosanitaire ne doit pas être délivré, conformément à l’article 143, paragraphe 2, deuxième alinéa, du règlement (UE) 2016/429.

Article 14

Obligations des opérateurs en matière de certificats zoosanitaires pour les mouvements d’envois de produits germinaux issus de bovins provenant d’établissements situés dans des zones réglementées I et II en dehors de ces zones

Les opérateurs ne déplacent les envois de produits germinaux issus de bovins en provenance de zones réglementées I et II en dehors de ces zones au sein du même État membre ou vers un autre État membre conformément à l’article 10 du présent règlement que si ces envois sont accompagnés du certificat zoosanitaire visé à l’article 161, paragraphe 4, du règlement (UE) 2016/429 comprenant au moins une des attestations suivantes de conformité avec les exigences prévues par le présent règlement:

a)

«Produits germinaux … (indiquer, selon le cas, sperme, ovules et/ou embryons) issus de bovins détenus dans une zone réglementée I en conformité avec les mesures spéciales de lutte contre l’infection par le virus de la DNC prévues à l’article 10 du règlement d’exécution (UE) 2021/1070 de la Commission.»;

b)	«Produits germinaux … (indiquer, selon le cas, sperme, ovules et/ou embryons) issus de bovins détenus dans une zone réglementée II en conformité avec les mesures spéciales de lutte contre le virus de la DNC prévues à l’article 10 du règlement d’exécution (UE) 2021/1070 de la Commission.».

Néanmoins, dans les cas de mouvements d’envois visés au premier alinéa du présent article au sein du même État membre, l’autorité compétente peut décider qu’un certificat zoosanitaire ne doit pas être délivré, conformément à l’article 161, paragraphe 2, deuxième alinéa, du règlement (UE) 2016/429.

Article 15

Obligations des opérateurs en matière de certificats zoosanitaires pour les mouvements d’envois de sous-produits animaux non transformés issus de bovins provenant de zones réglementées I et II en dehors de ces zones

Les opérateurs ne déplacent les envois de sous-produits animaux non transformés issus de bovins en provenance de zones réglementées I et II en dehors de ces zones au sein du même État membre ou vers un autre État membre dans les cas régis par l’article 12 que si ces envois sont accompagnés:

a)	du document commercial visé à l’annexe VIII, chapitre III, du règlement (UE) no 142/2011; et

b)	du certificat zoosanitaire visé à l’article 22, paragraphe 5, du règlement délégué (UE) 2020/687.

Néanmoins, dans les cas de mouvements d’envois visés au premier alinéa du présent article au sein du même État membre, l’autorité compétente peut décider qu’un certificat zoosanitaire ne doit pas être délivré, conformément à l’article 22, paragraphe 6, du règlement délégué (UE) 2020/687.

Article 16

Conditions générales supplémentaires relatives aux moyens de transport utilisés pour les mouvements d’envois de bovins et de sous-produits animaux non transformés en provenance de zones réglementées I et II en dehors de ces zones

L’autorité compétente de l’État membre autorise les mouvements d’envois de bovins et de sous-produits animaux non transformés en provenance de zones réglementées I et II en dehors de ces zones uniquement si les moyens de transport utilisés pour les mouvements de ces envois:

a)

en cas de transport de bovins: i) sont conformes aux exigences énoncées à l’article 24, paragraphe 1, du règlement délégué (UE) 2020/687; et ii) sont nettoyés et désinfectés conformément à l’article 24, paragraphe 2, du règlement délégué (UE) 2020/687, sous le contrôle ou la surveillance de l’autorité compétente de l’État membre;

b)	contiennent uniquement des animaux ou des sous-produits animaux non transformés ou des cuirs et des peaux non traités ayant le même statut sanitaire.

Article 17

Obligations de l’autorité compétente de l’établissement d’origine en ce qui concerne les procédures d’acheminement

Article 18

Obligations de l’autorité compétente du lieu de destination en ce qui concerne les procédures d’acheminement

L’autorité compétente du lieu de destination suivant une procédure d’acheminement:

a)	confirme chaque arrivée à l’autorité compétente du lieu d’origine;

b)	veille à ce que les bovins restent dans l’établissement de destination pendant au moins la durée de la période de surveillance pour l’infection par le virus de la DNC prévue à l’annexe II du règlement délégué (UE) 2020/687, sauf lorsque l’établissement de destination est un abattoir;

c)

veille à ce que, après le déchargement des bovins ou des sous-produits animaux non transformés, le moyen de transport et tout autre matériel utilisé durant leur transport soient intégralement nettoyés, désinfectés et traités avec des insecticides autorisés qui sont efficaces contre les vecteurs connus du virus de la DNC dans une enceinte fermée du lieu de destination, sous la surveillance d’un vétérinaire officiel.

Article 19

Obligations de l’État membre du lieu d’origine des envois de bovins, de produits germinaux ou de sous-produits animaux non transformés en ce qui concerne les informations à fournir à la Commission et aux États membres pour des dérogations accordées sur la base d’évaluations des risques

Lorsque l’autorité compétente autorise les mouvements d’envois de bovins ou de produits germinaux sur la base du résultat favorable d’une évaluation des risques portant sur les mesures de lutte contre la propagation de l’infection par le virus de la DNC, conformément à l’article 7, 8 ou 10, l’État membre du lieu d’origine informe immédiatement la Commission et les autres États membres des garanties zoosanitaires et de l’approbation par les autorités compétentes du lieu de l’établissement de destination.

Article 20

Entrée en vigueur et période d’application

Le présent règlement entre en vigueur le jour suivant celui de sa publication au Journal officiel de l’Union européenne.

Il est applicable jusqu’au 21 avril 2023.

ANNEXE I

ZONES RÉGLEMENTÉES I et II

(visées à l’article 3)

PARTIE I

Zone réglementée I

1.   Bulgarie:

L’intégralité du territoire bulgare

2.   Grèce:

A.

Les régions grecques suivantes: — Région de l’Attique — Région de la Grèce centrale — Région de la Macédoine centrale — Région de la Crète — Région de la Macédoine orientale et de la Thrace — Région de l’Épire — Région des îles Ioniennes, à l’exception de l’unité régionale de Kerkyra — Région de l’Égée septentrionale, à l’exception de l’unité régionale de Limnos — Région du Péloponnèse — Région de l’Égée méridionale — Région de la Thessalie — Région de la Grèce occidentale — Région de la Macédoine occidentale

B.	Les unités régionales grecques suivantes: — Unité régionale de Limnos — Unité régionale de Kerkyra

PARTIE II

Zone réglementée II

Néant

ANNEXE II

RÈGLES APPLICABLES AUX PLANS DE VACCINATION CONCERNANT L’INFECTION PAR LE VIRUS DE LA DERMATOSE NODULAIRE CONTAGIEUSE

(visées à l’article 3)

PARTIE I

Informations qui doivent figurer dans le plan de vaccination (visées à l’article 3)

Lorsqu’un État membre procède à la vaccination contre l’infection par le virus de la dermatose nodulaire contagieuse, cette vaccination doit être effectuée conformément à un plan de vaccination contenant au moins les informations suivantes:

a)	la description et les résultats de l’évaluation effectuée conformément aux critères énoncés à l’article 46, paragraphe 2, du règlement (UE) 2016/429, y compris la situation épidémiologique et d’autres informations pertinentes servant de base à l’évaluation;

b)	les principaux objectifs et cibles de la stratégie de vaccination choisie et du plan de vaccination;

c)	la description géographique détaillée de la zone de vaccination dans laquelle la vaccination doit être pratiquée et l’emplacement des établissements détenant des bovins à vacciner, y compris sur des cartes;

d)	l’autorité responsable de l’administration du vaccin aux bovins;

e)	le système de supervision de l’administration du vaccin;

f)	le nombre d’établissements détenant des bovins situés dans la zone réglementée et, s’il diffère, le nombre d’établissements à vacciner;

g)	le nombre estimé de bovins, leurs catégories et l’âge des animaux à vacciner;

h)	la durée prévue de la vaccination, du début de la vaccination jusqu’à la fin de la surveillance effectuée après la vaccination;

i)	le résumé des caractéristiques du vaccin, y compris le nom du produit et le nom du fabricant, ainsi que les voies d’administration;

j)	une mention de l’utilisation ou non du vaccin conformément à l’article 110, paragraphes 2 et 3, du règlement (UE) 2019/6 du Parlement européen et du Conseil (1);

k)	les méthodes d’évaluation de l’efficacité de la vaccination;

l)	les règles d’hygiène et de biosécurité à appliquer;

m)	le système d’enregistrement des données relatives à la vaccination;

n)	tout autre élément utile au regard des spécificités de la situation.

PARTIE II

Exigences minimales relatives aux plans de vaccination contre l’infection par le virus de la dermatose nodulaire contagieuse visées à l’article 3

Les plans de vaccination contre l’infection par le virus de la dermatose nodulaire contagieuse doivent remplir les exigences techniques suivantes:

a)	vaccination de tous les bovins, indépendamment de leur sexe, de leur âge et de leur état de gestation ou de production dans les zones réglementées I et II, où la vaccination doit être pratiquée;

b)	vaccination de la progéniture de bovins vaccinés âgée de plus de quatre mois, conformément aux instructions du fabricant du vaccin utilisé;

c)	revaccination de tous les bovins conformément aux instructions du fabricant;

d)	saisie par l’autorité compétente des données de chaque bovin vacciné dans la base de données en ligne spéciale reliée à la base de données centrale établie conformément à l’article 42 du règlement délégué (UE) 2019/2035 de la Commission (2);

e)	établissement d’une zone de surveillance accrue d’au moins 20 km autour des zones réglementées I et II, dans lesquelles la vaccination est pratiquée, dans laquelle une surveillance renforcée doit être effectuée et le déplacement des bovins doit être soumis à des contrôles par l’autorité compétente;

f)	couverture vaccinale d’au moins 95 % des troupeaux représentant au moins 75 % de la population de bovins.

PARTIE III

Informations préliminaires à fournir à la Commission et aux autres États membres avant le commencement de la vaccination, conformément à l’article 3, paragraphe 3

Les États membres qui pratiquent la vaccination contre la dermatose nodulaire contagieuse communiquent les informations suivantes à la Commission et aux autres États membres avant de commencer la vaccination:

a)	une brève justification du commencement de la vaccination;

b)	les espèces bovines à vacciner;

c)	le nombre estimé de bovins à vacciner;

d)	la durée estimée de la vaccination;

e)	le type et la dénomination commerciale du vaccin utilisé, en indiquant si le vaccin doit être utilisé conformément à l’article 110, paragraphes 2 et 3, du règlement (UE) 2019/6;

f)	une description de la zone de vaccination estimée.

---

(1)  Règlement (UE) 2019/6 du Parlement européen et du Conseil du 11 décembre 2018 relatif aux médicaments vétérinaires et abrogeant la directive 2001/82/CE (JO L 4 du 7.1.2019, p. 43).

(2)  Règlement délégué (UE) 2019/2035 de la Commission du 28 juin 2019 complétant le règlement (UE) 2016/429 du Parlement européen et du Conseil en ce qui concerne les règles relatives aux établissements détenant des animaux terrestres et aux couvoirs ainsi qu’à la traçabilité de certains animaux terrestres détenus et des œufs à couver (JO L 314 du 5.12.2019, p. 115).

Article premier

À l’article 4 du règlement d’exécution (UE) 2021/442, le deuxième alinéa est remplacé par le texte suivant:

Article 2

À l’article 3 du règlement d’exécution (UE) 2021/521, le deuxième alinéa est remplacé par le texte suivant:

Article 3

Le présent règlement entre en vigueur le 1er juillet 2021.

Article premier

Par dérogation aux articles 2, 3 et 4 de la décision 2013/471/UE, lorsque des mesures restrictives liées à la COVID-19 compromettent la possibilité d’organiser une réunion physique ou d’y participer, les bénéficiaires qui assistent à la réunion à distance par voie électronique n’ont droit qu’à une indemnité journalière fixée à 145 EUR.

Article 2

Le Comité adopte les modalités d’application de l’article 1er au plus tard le 2 septembre 2021.

Article 3

Au plus tard le 2 janvier 2022 et tous les six mois par la suite, le Comité soumet au Conseil un rapport d’évaluation sur l’application de la présente décision, et notamment sur son incidence budgétaire ainsi que sur la persistance de difficultés de déplacement liées à la COVID-19 ou des mesures restrictives connexes qui compromettent la possibilité d’organiser des réunions physiques ou d’y assister physiquement.

Article 4

La présente décision entre en vigueur le jour suivant celui de sa publication au Journal officiel de l’Union européenne.

Article premier

Les spécifications techniques relatives au certificat COVID numérique de l’UE établissant la structure des données générique, les mécanismes d’encodage et le mécanisme d’encodage de transport dans un format optique lisible par machine figurent à l’annexe I.

Article 2

Les règles à suivre pour compléter les certificats visés à l’article 3, paragraphe 1, du règlement (UE) 2021/953 figurent à l’annexe II de la présente décision.

Article 3

Les exigences définissant la structure commune de l’identifiant unique du certificat figurent à l’annexe III.

Article 4

Les règles de gouvernance applicables aux certificats de clé publique en ce qui concerne le service passerelle pour le certificat COVID numérique de l’UE prenant en charge les aspects d’interopérabilité du cadre de confiance figurent à l’annexe IV.

ANNEXE I

FORMAT ET GESTION DE LA CONFIANCE

Structure de données générique, mécanismes d’encodage et mécanisme d’encodage de transport dans un format optique lisible par machine (ci-après dénommé «QR»)

1.   Introduction

Les spécifications techniques décrites dans la présente annexe contiennent une structure de données générique et des mécanismes d’encodage pour le certificat COVID numérique de l’UE (EU Digital COVID Certificate — DCC). Elles définissent également un mécanisme d’encodage de transport dans un format optique lisible par machine (Quick Response — QR), qui peut être affiché sur l’écran d’un appareil mobile ou être imprimé. Les formats du conteneur du certificat sanitaire électronique figurant dans les présentes spécifications sont génériques, mais, dans ce contexte, ils servent à porter le DCC.

2.   Terminologie

Aux fins de la présente annexe, on entend par «émetteurs» les organismes qui utilisent les présentes spécifications pour délivrer des certificats sanitaires et par «vérificateurs» les organismes acceptant les certificats sanitaires comme preuve du statut sanitaire. On entend par «participants» les émetteurs et les vérificateurs. Certains aspects définis dans la présente annexe, tels que la gestion d’un espace de noms et la distribution des clés cryptographiques, doivent faire l’objet d’une coordination entre les participants. Il est supposé qu’une partie, ci-après dénommée le «secrétariat», accomplit ces tâches.

3.   Format du conteneur du certificat sanitaire électronique

Le format du conteneur du certificat sanitaire électronique (Electronic Health Certificate — «HCERT») est conçu pour fournir un véhicule uniforme et normalisé pour les certificats sanitaires délivrés par les différents émetteurs (ci-après les «émetteurs»). Les présentes spécifications ont pour objet d’harmoniser la manière dont ces certificats sanitaires sont représentés, encodés et signés dans le but d’en faciliter l’interopérabilité.

La capacité de lire et d’interpréter un DCC délivré par un émetteur requiert une structure de données commune et un accord sur la signification de chaque champ de données de la charge utile. Pour faciliter cette interopérabilité, on définit une structure de données commune coordonnée en utilisant un schéma «JSON» qui constitue le cadre du DCC.

3.1.   Structure de la charge utile

La charge utile est structurée et encodée au format CBOR (Concise Binary Object Representation — représentation concise d’objet binaire) avec une signature numérique au format COSE (CBOR Object Signing and Encryption — signature et chiffrement d’objet en représentation concise d’objet binaire). Cette structure est communément appelée «jeton CBOR pour la toile» (CBOR Web Token — CWT) et est définie dans la RFC 8392 (1). La charge utile, telle que définie dans les sections suivantes, est transportée dans une revendication hcert.

L’intégrité et l’authenticité de l’origine des données de la charge utile doivent être vérifiables par le vérificateur. Pour permettre ce mécanisme, l’émetteur doit signer le CWT au moyen d’un système de signature électronique asymétrique tel que défini dans la spécification COSE (RFC 8152 (2)).

3.2.   Revendications CWT

3.2.1.   Vue d’ensemble de la structure CWT

En-tête protégé

—	Algorithme de signature (alg, étiquette 1)

—	Identifiant de clé (Key Identifier — ci-après «kid», étiquette 4)

Charge utile

—	Émetteur (Issuer — ci-après «iss», clé de revendication 1, facultatif, ISO 3166-1 alpha-2 de l’émetteur)

—	Délivré le (Issued At — ci-après «iat», clé de revendication 6)

—	Délai d’expiration (exp, clé de revendication 4)

—	Certificat sanitaire (hcert, clé de revendication -260)

—	Certificat COVID numérique de l’UE v1 (eu_DCC_v1, clé de revendication 1)

Signature

3.2.2.   Algorithme de signature

Le paramètre de l’algorithme de signature (alg) indique quel algorithme est utilisé pour créer la signature. Il doit respecter voire être plus strict que les lignes directrices actuelles du groupe des hauts fonctionnaires pour la sécurité des systèmes d’information (SOG-IS) résumées dans les paragraphes suivants.

Un algorithme primaire et un algorithme secondaire sont définis. L’algorithme secondaire ne devrait être utilisé que si l’algorithme primaire n’est pas acceptable dans le cadre des règles et réglementations imposées à l’émetteur.

Afin de garantir la sécurité du système, toutes les mises en œuvre doivent intégrer l’algorithme secondaire. C’est pourquoi tant l’algorithme primaire que l’algorithme secondaire doivent être mis en œuvre.

Les niveaux définis par le SOG-IS pour les algorithmes primaire et secondaire sont les suivants:

—

Algorithme primaire: l’algorithme primaire est l’algorithme de signature numérique à courbe elliptique (Elliptic Curve Digital Signature Algorithm — ECDSA) tel que défini à la section 2.3 de la norme (ISO/IEC 14888–3:2006), utilisant les paramètres P–256 définis à l’appendice D (D.1.2.3) de la norme (FIPS PUB 186–4) en combinaison avec l’algorithme de hachage SHA–256 tel que défini dans la fonction 4 de la norme (ISO/IEC 10118–3:2004).

Cela correspond au paramètre ES256 de l’algorithme COSE.

—	Algorithme secondaire: l’algorithme secondaire est le RSASSA-PSS tel que défini dans la (RFC 8230 (3)) avec un modulus de 2048 bits en combinaison avec l’algorithme de hachage SHA–256 tel que défini dans la fonction 4 de la norme (ISO/IEC 10118–3:2004).

Cela correspond au paramètre de l’algorithme COSE: PS256.

3.2.3.   Identifiant de clé

La revendication d’identifiant de clé (kid) indique le certificat de signataire de documents (DSC) contenant la clé publique qui doit être utilisé par le vérificateur pour vérifier l’exactitude de la signature numérique. La gouvernance des certificats de clé publique, y compris les exigences applicables aux DSC, est décrite à l’annexe IV.

La revendication d’identifiant de clé (kid) est utilisée par les vérificateurs pour sélectionner la bonne clé publique à partir d’une liste de clés appartenant à l’émetteur indiqué dans la revendication d’émetteur (iss). Plusieurs clés peuvent être utilisées parallèlement par un émetteur pour des raisons administratives et lors de la reconduction des clés. L’identifiant de clé n’est pas un champ critique pour la sécurité. Pour cette raison, il peut également être placé dans un en-tête non protégé si nécessaire. Les vérificateurs doivent accepter les deux options. Si les deux options sont présentes, c’est l’identifiant de clé dans l’en-tête protégé qu’il y a lieu d’utiliser.

En raison du raccourcissement de l’identifiant (pour des raisons de limitation de la taille), la probabilité est faible, mais pas nulle, que la liste globale des certificats de signataire de documents (Document Signer Certificates — DSC) acceptés par un vérificateur puisse contenir des DSC avec un double kid. C’est la raison pour laquelle le vérificateur doit vérifier tous les DSC présentant ce kid.

3.2.4.   Émetteur

La revendication d’émetteur (iss) est une valeur de chaîne qui peut, à titre facultatif, contenir le code pays ISO 3166-1 alpha-2 de l’entité délivrant le certificat sanitaire. Cette revendication peut être utilisée par un vérificateur pour identifier la série de DSC à utiliser pour la vérification. La clé de revendication 1 est utilisée pour identifier cette revendication.

3.2.5.   Délai d’expiration

La revendication de délai d’expiration (exp) doit contenir un horodatage au format date numérique (comme précisé dans la RFC 8392 (4), section 2) indiquant la période pendant laquelle cette signature particulière sur la charge utile doit être considérée comme valide, après quoi un vérificateur doit rejeter la charge utile considérée comme ayant expiré. L’objectif du paramètre d’expiration est d’imposer une limite à la durée de validité du certificat sanitaire. La clé de revendication 4 est utilisée pour identifier cette revendication.

Le délai d’expiration ne doit pas dépasser la période de validité du DSC.

3.2.6.   Délivré le

La revendication «délivré le» (iat) doit contenir un horodatage au format date numérique (comme précisé dans la RFC 8392 (5), section 2) indiquant la date à laquelle le certificat sanitaire a été créé.

Le champ «délivré le» ne doit pas contenir une date antérieure à la période de validité du DSC.

Les vérificateurs peuvent appliquer des mesures supplémentaires dans le but de limiter la validité du certificat sanitaire en fonction de la date de délivrance. La clé de revendication 6 est utilisée pour identifier cette revendication.

3.2.7.   Revendication de certificat sanitaire

La revendication de certificat sanitaire (hcert) est un objet JSON (RFC 7159 (6)) contenant les informations relatives au statut sanitaire. Plusieurs types de certificat sanitaire peuvent exister sous la même revendication, le DCC en étant un.

Le format JSON sert uniquement pour les schémas. Le format de représentation est le CBOR, tel que défini dans la (RFC 7049 (7)). Il se peut que les développeurs des applications ne décodent ou n’encodent jamais vers et depuis le format JSON et qu’ils utilisent la structure en mémoire.

La clé de revendication à utiliser pour identifier cette revendication est -260.

Les chaînes de l’objet JSON doivent être normalisées conformément à la composition canonique des formes de normalisation (Normalisation Form Canonical Composition — NFC) définie dans la norme Unicode. Les applications de décodage devraient toutefois être permissives et robustes à ces égards, et l’acceptation de tout type de conversion raisonnable est fortement encouragée. Si des données non normalisées sont trouvées au cours du décodage ou dans le cadre de fonctions de comparaisons ultérieures, les mises en œuvre devraient se comporter comme si les données entrées étaient normalisées conformément à la NFC.

4.   Sérialisation et création de la charge utile du DCC

En ce qui concerne la structure de sérialisation, la séquence suivante est utilisée:

Le processus commence par l’extraction de données, par exemple à partir d’un répertoire de données de santé (ou d’une source externe de données), structurant les données extraites conformément aux schémas de DCC définis. Lors de ce processus, la conversion au format de données défini et la transformation pour la lisibilité humaine peuvent avoir lieu avant le début de la sérialisation vers le format CBOR. Les abréviations (acronymes) des revendications doivent correspondre, dans tous les cas, aux noms d’affichage avant la sérialisation et après la désérialisation.

Le contenu des données nationales facultatives n’est pas autorisé dans les certificats délivrés conformément au règlement (UE) 2021/953 (8). Le contenu des données est limité aux éléments de données définis dans l’ensemble minimal de données spécifié dans le règlement (UE) 2021/953.

5.   Encodages de transport

5.1.   Brut

Pour les interfaces de données arbitraires, le conteneur du HCERT et ses charges utiles peuvent être transférés tels quels, en utilisant n’importe quel transport de données sous-jacent, sûr et fiable à 8 bits. Ces interfaces peuvent comprendre une communication en champ proche (Near-Field Communication — NFC), un Bluetooth ou un transfert via un protocole de couche application, par exemple le transfert d’un HCERT de l’émetteur vers l’appareil mobile du titulaire.

Si le transfert du HCERT de l’émetteur vers le titulaire est basé sur une interface de présentation uniquement (par exemple, SMS, courrier électronique), l’encodage de transport brut n’est évidemment pas applicable.

5.2.   Code-barres

5.2.1.   Compression de la charge utile (CWT)

Afin de réduire la taille et d’améliorer la vitesse et la fiabilité du processus de lecture du HCERT, le CWT doit être comprimé, en utilisant le ZLIB (RFC 1950 (9)) et le mécanisme de compression Deflate, au format défini dans la RFC 1951 (10).

5.2.2.   Code-barres QR 2D

Afin de mieux gérer les équipements anciens conçus pour fonctionner sur des charges utiles ASCII, le CWT comprimé est encodé au format ASCII à l’aide de Base45 avant d’être encodé en un code-barres 2D.

Le format QR tel que défini dans la norme (ISO/IEC 18004:2015) doit être utilisé pour la génération du code-barres 2D. Un taux de correction d’erreur de «Q» (environ 25 %) est recommandé. Étant donné que Base45 est utilisé, le code QR doit utiliser l’encodage alphanumérique (mode 2, indiqué par les symboles 0010).

Afin que les vérificateurs puissent détecter le type de données encodées et sélectionner le système de décodage et de traitement approprié, les données encodées avec Base45 (conformément à la présente spécification) doivent avoir pour préfixe la chaîne d’identifiant de contexte «HC1:». Les versions futures de la présente spécification ayant une incidence sur la compatibilité rétrospective devront définir un nouvel identifiant de contexte, tandis que le caractère suivant la mention «HC» devra être tiré du jeu de caractères [1-9A-Z]. L’ordre des augmentations est défini selon cette séquence, c’est-à-dire d’abord [1-9], puis [A-Z].

Il est recommandé de faire apparaître le code optique sur le média de présentation avec une diagonale comprise entre 35 mm et 60 mm, afin de prendre en compte les lecteurs à optique fixe pour lesquels le média de présentation doit être placé à la surface du lecteur.

Si le code optique est imprimé sur papier à l’aide d’une imprimante à basse résolution (< 300 dpi), il faut veiller à ce que la forme carrée de chaque symbole (point) du code QR soit parfaitement respectée. Si l’échelle n’est pas proportionnelle, certaines lignes ou colonnes du QR comporteront des symboles rectangulaires, ce qui nuira à la lisibilité dans de nombreux cas.

6.   Format des listes de confiance (trust lists) (listes de CSCA et de DSC)

Chaque État membre est tenu de fournir une liste mentionnant une ou plusieurs autorités nationales de signature de certificats (Country Signing Certificate Authorities — CSCA) et une liste de tous les certificats de signataire de documents (Document Signer Certificates — DSC) valides, et de tenir ces listes à jour.

6.1.   Simplification relative aux CSCA/DSC

À partir de la présente version des spécifications, les États membres ne peuvent présumer que les informations relatives aux listes de révocation de certificat (Certificate Revocation List — CRL) puissent être utilisées, ou que la période d’utilisation des clés privées puisse être vérifiée par les responsables de la mise en œuvre.

Le principal mécanisme de validation consistera plutôt dans le fait que le certificat figure dans la version la plus récente de cette liste de certificats.

6.2.   Infrastructure à clé publique (ICP) des DVLMe (OACI) et centres de confiance

Les États membres peuvent avoir recours à une CSCA distincte, mais peuvent également communiquer leurs certificats CSCA de DVLMe et/ou DSC existants; ils peuvent même choisir de se procurer ceux-ci auprès de centres de confiance (commerciaux) et les communiquer. Toutefois, un DSC doit toujours être signé par la CSCA communiquée par cet État membre.

7.   Considérations de sécurité

Lors de la conception d’un système fondé sur la présente spécification, les États membres identifient, analysent et contrôlent certains éléments liés à la sécurité.

Les éléments qui devraient être pris en considération sont au minimum les suivants:

7.1.   Durée de validité de la signature du HCERT

L’émetteur du HCERT est tenu de limiter la durée de validité de la signature en précisant le délai d’expiration de la signature. Le titulaire d’un certificat sanitaire est ainsi tenu de le renouveler périodiquement.

La durée de validité acceptable peut être déterminée par des contraintes pratiques. Par exemple, un voyageur peut ne pas avoir la possibilité de renouveler le certificat sanitaire au cours d’un voyage à l’étranger. Toutefois, il se peut également qu’un émetteur envisage la possibilité d’une quelconque compromission de la sécurité l’obligeant à retirer un DSC (ce qui invalide tous les certificats sanitaires délivrés au moyen de la clé dont la validité se situe encore dans leur période de validité). Les conséquences d’un tel événement peuvent être limitées en procédant régulièrement à la reconduction des clés de l’émetteur et en exigeant le renouvellement de tous les certificats sanitaires, à intervalles raisonnables.

7.2.   Gestion des clés

La présente spécification repose largement sur des mécanismes cryptographiques solides pour garantir l’intégrité des données et l’authentification de l’origine des données. Il est donc nécessaire de préserver la confidentialité des clés privées.

La confidentialité des clés cryptographiques peut être compromise de différentes manières, par exemple:

—	le processus de génération des clés peut être déficient, donnant lieu à des clés fragiles,

—	les clés peuvent être vulnérables du fait d’une erreur humaine,

—	les clés peuvent être volées par des délinquants externes ou internes,

—	les clés peuvent être calculées à l’aide d’une analyse cryptographique.

Afin d’atténuer les risques liés à une éventuelle faiblesse de l’algorithme de signature, exposant les clés privées à une compromission par analyse cryptographique, la présente spécification recommande à tous les participants de mettre en œuvre un algorithme de signature secondaire de secours, fondé sur des paramètres différents ou un problème mathématique différent de celui du primaire.

En ce qui concerne les risques mentionnés liés aux modalités de fonctionnement des émetteurs, des mesures d’atténuation visant à garantir un contrôle efficace doivent être mises en œuvre, de manière à générer, stocker et utiliser les clés privées dans des modules matériels de sécurité (Hardware Security Modules — HSM). Il est vivement recommandé d’utiliser des HSM pour la signature des certificats sanitaires.

Indépendamment de la question de savoir si un émetteur décide d’utiliser ou non des HSM, il convient d’établir un calendrier de reconduction de clés dans lequel la fréquence des reconductions est proportionnelle à la vulnérabilité des clés aux réseaux externes, aux autres systèmes et au personnel. Un calendrier de reconduction bien choisi limite également les risques associés aux certificats sanitaires délivrés par erreur, car il permet à un émetteur de révoquer ces certificats par lots, en procédant au retrait d’une clé, si nécessaire.

7.3.   Validation des données d’entrée

Les présentes spécifications peuvent être utilisées d’une manière qui implique de recevoir des données provenant de sources non fiables versées dans des systèmes qui peuvent être essentiels à la mission concernée. Afin de minimiser les risques associés à ce vecteur d’attaque, tous les champs d’entrée doivent être correctement validés par type, longueur et contenu des données. La signature de l’émetteur doit également être vérifiée avant tout traitement du contenu du HCERT. Toutefois, la validation de la signature de l’émetteur implique de parcourir d’abord l’en-tête protégé de l’émetteur, dans lequel un assaillant potentiel peut tenter d’injecter des informations soigneusement conçues pour compromettre la sécurité du système.

8.   Gestion de la confiance

La signature du HCERT nécessite une clé publique à vérifier. Les États membres doivent mettre ces clés publiques à disposition. En fin de compte, chaque vérificateur doit disposer d’une liste de toutes les clés publiques auxquelles il est disposé à accorder sa confiance (étant donné que la clé publique ne fait pas partie du HCERT).

Le système se compose de (seulement) deux couches; pour chaque État membre, un ou plusieurs certificats au niveau du pays, qui signent chacun un ou plusieurs certificats de signataire de documents qui sont utilisés dans les opérations quotidiennes.

Les certificats des États membres sont appelés certificats des autorités nationales de signature de certificats (CSCA) et sont (généralement) des certificats autosignés. Les États membres peuvent en avoir plusieurs (par exemple, en cas de décentralisation régionale). Ces certificats CSCA signent régulièrement les certificats de signataire de documents (DSC) utilisés pour signer les HCERT.

Le «secrétariat» joue un rôle fonctionnel. Il doit agréger et publier régulièrement les DSC des États membres, après les avoir vérifiés par rapport à la liste des certificats CSCA (qui ont été transmis et vérifiés par d’autres moyens).

La liste des certificats DSC qui en résulte doit ensuite fournir l’ensemble agrégé de clés publiques acceptables (et les kids correspondants) que les vérificateurs peuvent utiliser pour valider les signatures sur les HCERT. Les vérificateurs sont tenus d’aller chercher et de mettre à jour régulièrement cette liste.

Ces listes par État membre peuvent être adaptées au format convenant à la situation nationale. Ainsi, le format de fichier de cette liste de confiance (trust list) peut varier; par exemple, il peut s’agir d’un JWKS signé (format JWK conformément à la RFC 7517 (11), section 5) ou de tout autre format spécifique à la technologie utilisée dans cet État membre.

Pour garantir la simplicité du processus, les États membres peuvent à la fois communiquer leurs certificats CSCA existants à partir de leurs systèmes de DVLMe conformes aux normes de l’OACI ou, comme l’OMS le recommande, créer un système spécifiquement pour ce domaine de la santé.

8.1.   Identifiant de clé (kids)

L’identifiant de clé (kid) est calculé lors de l’établissement de la liste des clés publiques de confiance à partir des DSC et consiste en une empreinte SHA-256 tronquée (8 premiers octets) du DSC encodée au format DER (brut).

Les vérificateurs n’ont pas besoin de calculer le kid sur la base du DSC et peuvent directement mettre l’identifiant de clé figurant dans le certificat sanitaire délivré en correspondance avec le kid figurant sur la trust list.

8.2.   Différences par rapport au modèle de confiance de l’ICP des DVLMe (OACI)

Bien que fondé sur les meilleures pratiques du modèle de confiance de l’ICP des DVLMe de l’OACI, il convient de simplifier quelque peu le modèle dans un souci de rapidité:

—	l’État membre peut soumettre plusieurs certificats CSCA,

—	la période de validité du DSC (utilisation de la clé) peut être fixée à n’importe quelle durée ne dépassant pas celle du certificat CSCA et peut être absente,

—	le DSC peut contenir des identifiants de politique (utilisation étendue de la clé) qui sont propres aux certificats sanitaires,

—	les États membres peuvent choisir de ne jamais procéder à une vérification des révocations publiées et de se baser simplement sur les listes de DSC qu’ils obtiennent quotidiennement du secrétariat ou compilent eux-mêmes.

---

(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)  Règlement (UE) 2021/953 du Parlement européen et du Conseil du 14 juin 2021 relatif à un cadre pour la délivrance, la vérification et l’acceptation de certificats COVID-19 interopérables de vaccination, de test et de rétablissement (certificat COVID numérique de l’UE) afin de faciliter la libre circulation pendant la pandémie de COVID-19, JO L 211 du 15.6.20211, p. 1.

(9)  rfc1950 (ietf.org).

(10)  rfc1951 (ietf.org).

(11)  rfc7517 (ietf.org).

ANNEXE II

RÈGLES POUR COMPLÉTER LE CERTIFICAT COVID NUMÉRIQUE DE L’UE

Les règles générales concernant les ensembles de valeurs établies dans la présente annexe visent à assurer l’interopérabilité au niveau sémantique et permettent des mises en œuvre techniques uniformes pour le DCC. Les éléments figurant dans la présente annexe peuvent être utilisés pour les trois contextes différents (vaccination/test/rétablissement), tels que prévus par le règlement (UE) 2021/953. Seuls les éléments nécessitant une normalisation sémantique au moyen d’ensembles de valeurs codées sont énumérés dans la présente annexe.

La traduction des éléments codés dans la langue nationale relève de la responsabilité des États membres.

Pour tous les champs de données non mentionnés dans les descriptions des ensembles de valeurs ci-dessous, un encodage au format UTF-8 est recommandé (nom, centre de test, émetteur du certificat). Il est recommandé d’encoder les champs de données contenant les dates (date de naissance, date de vaccination, date du prélèvement de l’échantillon, date du premier résultat de test positif, dates de validité du certificat) conformément à la norme ISO 8601.

Si, pour une raison quelconque, les systèmes de codes privilégiés énumérés ci-dessous ne peuvent pas être utilisés, il est possible d’avoir recours à d’autres systèmes de codes internationaux et il y a lieu d’établir des orientations sur la manière de faire correspondre les codes de l’autre système à ceux du système privilégié. Le texte (les noms d’affichage) peut être utilisé, dans des cas exceptionnels, comme mécanisme de sauvegarde lorsque aucun code approprié n’est disponible dans les ensembles de valeurs définis.

Les États membres qui utilisent d’autres codages dans leurs systèmes devraient mettre ces codes en correspondance avec les ensembles de valeurs décrits. Les États membres sont responsables de ces éventuelles mises en correspondance.

Les ensembles de valeurs sont régulièrement mis à jour par la Commission avec le soutien du réseau «Santé en ligne» et du comité de sécurité sanitaire. Les ensembles de valeurs mis à jour sont publiés sur le site web concerné de la Commission, ainsi que sur la page web du réseau «Santé en ligne». Un historique des changements devrait être fourni.

1.   Maladie ou agent ciblé/Maladie ou agent dont le titulaire s’est rétabli: COVID-19 (SARS-CoV-2 ou un de ses variants)

Système de codes privilégié: SNOMED CT (nomenclature systématisée des termes cliniques en médecine).

À utiliser dans les certificats 1, 2 et 3.

Les codes sélectionnés doivent mentionner la COVID-19 ou, si des informations plus détaillées sur le variant génétique du SARS-CoV-2 sont nécessaires, mentionner ce variant dans le cas où ces informations détaillées sont indispensables pour des raisons épidémiologiques.

Un exemple de code à utiliser est le code SNOMED CT 840539006 (COVID-19).

2.   Vaccin ou prophylaxie contre la COVID-19

Système de codes privilégié: SNOMED CT ou classification ATC (système de classification anatomique, thérapeutique et chimique).

À utiliser dans le certificat 1.

Des exemples de codes à utiliser issus des systèmes de codes privilégiés sont les codes SNOMED CT 1119305005 (vaccin antigénique SARS-CoV-2), 1119349007 (vaccin à ARNm SARS-CoV-2) ou J07BX03 (vaccins covid-19). L’ensemble de valeurs devrait être étendu lorsque de nouveaux types de vaccins sont mis au point et utilisés.

3.   Médicament vaccinal contre la COVID-19

Systèmes de codes privilégiés (par ordre de préférence):

—	registre des médicaments de l’Union européenne pour les vaccins bénéficiant d’une autorisation à l’échelle de l’Union (numéros d’autorisation),

—	un registre mondial des vaccins, tel que celui qui pourrait être établi par l’Organisation mondiale de la santé,

—	nom du médicament vaccinal dans les autres cas. Si le nom inclut des espaces blancs, il convient de remplacer ceux-ci par un trait d’union (–).

Nom de l’ensemble de valeurs: vaccin.

À utiliser dans le certificat 1.

Un exemple de code à utiliser, issu des systèmes de codes privilégiés, est EU/1/20/1528 (Comirnaty). Exemple de nom de vaccin à utiliser comme code: Sputnik–V (correspondant à Sputnik V).

4.   Titulaire de l’autorisation de mise sur le marché ou fabricant du vaccin contre la COVID-19

Système de codes privilégié:

—	code d’organisation provenant de l’Agence européenne des médicaments (EMA) [système concernant les substances, produits, organisations et référentiels (SPOR) pour les normes ISO IDMP],

—	un registre mondial des titulaires d’autorisations de mise sur le marché ou des fabricants de vaccins, tel que celui qui pourrait être établi par l’Organisation mondiale de la santé,

—	nom de l’organisation dans les autres cas. Si le nom inclut des espaces blancs, il convient de remplacer ceux-ci par un trait d’union (–).

À utiliser dans le certificat 1.

Un exemple de code à utiliser, issu des systèmes de codes privilégiés, est ORG-100001699 (AstraZeneca AB). Exemple de nom d’organisation à utiliser comme code: Sinovac–Biotech (correspondant à Sinovac Biotech).

5.   Nombre dans une série de doses ainsi que nombre total de doses dans la série

À utiliser dans le certificat 1.

Deux champs:

1)	nombre de doses administrées en un cycle

2)	nombre de doses attendues pour un cycle complet (spécifique pour une personne au moment de l’administration)

Par exemple, 1/1 ou 2/2 indiquera que le cycle est achevé; y compris l’option 1/1 pour les vaccins comprenant deux doses, mais pour lesquels le protocole appliqué par l’État membre consiste à administrer une dose aux citoyens chez lesquels la COVID-19 a été diagnostiquée avant la vaccination. Le nombre total de doses dans la série devrait être indiqué tel qu’il ressort des informations disponibles au moment de l’administration de la dose. Par exemple, si, lors de la dernière injection en date, il s’avère qu’un vaccin spécifique nécessite une troisième injection (rappel), le second chiffre du champ doit l’indiquer (par exemple 2/3, 3/3, etc.).

6.   État membre ou pays tiers dans lequel le vaccin a été administré/le test a été effectué

Système de codes privilégié: codes pays ISO 3166.

À utiliser dans les certificats 1, 2 et 3.

Contenu de l’ensemble de valeurs: la liste complète des codes à 2 lettres, disponible sous la forme d’un ensemble de valeurs défini dans la spécification FHIR (Fast Healthcare Interoperability Resources — ressources d’interopérabilité rapide des soins de santé) (http://hl7.org/fhir/ValueSet/iso3166-1-2)

7.   Type de test

Système de codes privilégié: nomenclature LOINC (Logical Observation Identifiers Names and Codes — codes et noms d’identifiants d’observation logique).

À utiliser dans le certificat 2 et le certificat 3 si le soutien à la délivrance de certificats de rétablissement sur la base de types de test autres que le NAAT (nucleic acid amplification test — test d’amplification des acides nucléiques) est instauré par un acte délégué.

Les codes figurant dans cet ensemble de valeurs doivent faire référence à la méthode de test et être sélectionnés au minimum pour établir une distinction entre les tests NAAT et les tests RAT (rapid antigen test — test rapide de détection d’antigènes) comme indiqué dans le règlement (UE) 2021/953.

Un exemple de code à utiliser, issu des systèmes de codes privilégiés, est LP217198-3 (immunodosage rapide).

8.   Nom du fabricant et dénomination commerciale du test utilisé (facultatifs pour les tests NAAT)

Système de codes privilégié: liste, établie par le comité de sécurité sanitaire (CSS), des tests rapides de détection d’antigènes, mise à jour par le JRC (base de données sur les dispositifs de diagnostic in vitro et les méthodes de dépistage de la COVID-19).

À utiliser dans le certificat 2.

Le contenu de l’ensemble de valeurs doit inclure la sélection d’un test rapide de détection d’antigènes figurant sur la liste commune et actualisée des tests rapides de détection d’antigènes pour le diagnostic de la COVID-19, établie sur la base de la recommandation du Conseil publiée au JO C 24 du 22.1.2021, p. 1, et approuvée par le comité de sécurité sanitaire. La liste est mise à jour par le JRC dans la base de données sur les dispositifs de diagnostic in vitro et les méthodes de dépistage de la COVID-19 à l’adresse suivante: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

Pour ce système de codes, il convient d’utiliser des champs pertinents tels que l’identifiant du dispositif de test, le nom du test et du fabricant, en respectant le format structuré du JRC disponible à l’adresse suivante: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9.   Résultat du test

Système de codes privilégié: SNOMED CT.

À utiliser dans le certificat 2.

Les codes sélectionnés doivent permettre de faire la distinction entre les résultats de test positifs et négatifs (détectés ou non détectés). Des valeurs supplémentaires (telles que «indéterminé») peuvent être ajoutées si les cas d’utilisation le requièrent.

Des exemples de codes à utiliser, issus du système de codes privilégié, sont 260415000 (non détectés) et 260373001 (détectés).

ANNEXE III

STRUCTURE COMMUNE DE L’IDENTIFIANT UNIQUE DU CERTIFICAT

1.   Introduction

Chaque certificat COVID numérique de l’UE comporte un identifiant unique du certificat (unique certificate identifier — UCI) qui favorise l’interopérabilité des DCC. L’UCI peut être utilisé pour vérifier le certificat. Les États membres sont chargés de la mise en œuvre de l’UCI. L’UCI est un moyen de vérifier l’authenticité du certificat et, le cas échéant, d’établir un lien vers un système d’enregistrement, par exemple, un système d’information sur la vaccination (immunisation information system — IIS). Cet identifiant doit également permettre aux États membres d’attester (sur papier et par voie numérique) que des personnes ont été vaccinées ou testées.

2.   Composition de l’identifiant unique du certificat

L’UCI doit avoir une structure et un format communs facilitant l’interprétabilité des informations par l’homme et/ou par la machine et peut porter sur des éléments tels que l’État membre de vaccination, le vaccin lui-même et un identifiant propre à l’État membre. Cela assure aux États membres une certaine souplesse pour le formater, en respectant pleinement la législation en matière de protection des données. L’ordre des différents éléments suit une hiérarchie définie qui peut permettre de modifier les blocs à l’avenir sans nuire à l’intégrité structurelle.

Les solutions possibles pour la composition de l’UCI constituent un spectre dans lequel la modularité et l’interprétabilité par l’homme sont les deux principaux paramètres de diversification et une caractéristique fondamentale:

—	modularité: la mesure dans laquelle le code est composé de blocs constitutifs distincts contenant des informations sémantiquement différentes,

—	interprétabilité par l’homme: la mesure dans laquelle le code est porteur de sens ou peut être interprété par le lecteur humain,

—

unique à l’échelle mondiale; l’identifiant du pays ou de l’autorité est bien géré; et chaque pays (autorité) est censé bien gérer son segment de l’espace de noms en ne recyclant jamais les identifiants et en ne les réassignant pas. La combinaison de ces éléments garantit que chaque identifiant est unique à l’échelle mondiale.

3.   Exigences générales

En ce qui concerne l’UCI, les exigences à respecter sont les suivantes:

1)	Jeu de caractères: seuls les caractères alphanumériques US-ASCII majuscules («A» à «Z», «0» à «9») sont autorisés, avec des caractères spéciaux supplémentaires séparateurs selon la RFC3986 (1) (2), à savoir {’/’,’#’,’:’}.

2)	Longueur maximale: pour les concepteurs, l’objectif devrait être une longueur de 27 à 30 caractères (3).

3)	Préfixe de version: fait référence à la version du schéma UCI. Le préfixe de version est «01» pour la présente version du document; le préfixe de version est composé de deux chiffres.

4)	Préfixe du pays: le code pays est spécifié par la norme ISO 3166-1. Les codes plus longs [c’est-à-dire 3 caractères et plus (par exemple, «UNHCR»)] sont réservés à une utilisation future.

5)

Suffixe de code/Somme de contrôle 5.1. Les États membres devraient utiliser une somme de contrôle lorsqu’une transmission, une transcription (humaine) ou une autre forme de corruption peuvent se produire (c’est-à-dire en cas d’utilisation en version imprimée). 5.2. La somme de contrôle ne doit pas être utilisée pour valider le certificat et ne fait pas techniquement partie de l’identifiant, mais sert à vérifier l’intégrité du code. Cette somme de contrôle devrait être le résumé ISO 7812-1 (LUHN-10) (4) de l’UCI entier au format de transport filaire/numérique. La somme de contrôle est séparée du reste de l’UCI par un caractère «#».

Il convient de veiller à la compatibilité rétrospective: les États membres qui, au fil du temps, modifient la structure de leurs identifiants (dans la version principale, actuellement fixée à v1) doivent veiller à ce que deux identifiants identiques représentent le même certificat ou la même déclaration de vaccination. En d’autres termes, les États membres ne peuvent pas recycler les identifiants.

4.   Options en matière d’identifiants uniques pour les certificats de vaccination

Les lignes directrices du réseau «Santé en ligne» concernant les certificats de vaccination vérifiables et les éléments d’interopérabilité de base (5) offrent aux États membres et à d’autres parties diverses options qui peuvent coexister entre différents États membres. Les États membres peuvent déployer ces diverses options dans différentes versions du schéma UCI.

---

(1)  rfc3986 (ietf.org).

(2)  Les champs correspondant, par exemple, au sexe, au numéro de lot, au centre d’administration, à l’identification du professionnel de santé ou à la prochaine date de vaccination peuvent ne pas être nécessaires à des fins autres que médicales.

(3)  Pour la mise en œuvre avec des codes QR, les États membres pourraient envisager d’utiliser un jeu supplémentaire de caractères d’une longueur maximale totale de 72 caractères (y compris les 27 à 30 caractères de l’identifiant proprement dit) pour transmettre d’autres informations. Il appartient aux États membres de définir les spécifications de ces informations.

(4)  L’algorithme Luhn mod N est une extension de l’algorithm de Luhn (aussi appelé algorithme mod 10) utilisé pour les codes numériques, qui sert par exemple à calculer les sommes de contrôle des numéros de cartes de crédit. L’extension permet à l’algorithme de fonctionner avec des séquences de valeurs dans n’importe quelle base (en l’occurrence, des caractères alphabétiques).

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

ANNEXE IV

GOUVERNANCE DES CERTIFICATS DE CLÉ PUBLIQUE

1.   Introduction

L’échange sécurisé et fiable de clés de signature pour les certificats COVID numériques de l’UE (Digital COVID certificates, DCC) entre les États membres s’effectue par l’intermédiaire du service passerelle des certificats COVID numériques de l’UE (Digital COVID Certificate Gateway, DCCG), qui sert de répertoire central des clés publiques. Le DCCG donne aux États membres les moyens de publier les clés publiques correspondant aux clés privées qu’ils utilisent pour signer des certificats COVID numériques. Les États membres utilisateurs peuvent avoir recours au DCCG pour obtenir en temps voulu des clés publiques actualisées. Par la suite, le DCCG pourra être étendu pour permettre l’échange d’informations supplémentaires fiables fournies par les États membres, telles que des règles de validation concernant les DCC. Le modèle de confiance du cadre DCC est une infrastructure à clé publique (ICP). Chaque État membre a une ou plusieurs autorités nationales de signature de certificats (CSCA), dont les certificats ont une durée de vie relativement longue. Selon la décision de l’État membre, il peut s’agir d’une CSCA identique à celle utilisée pour les documents de voyage lisibles par machine ou d’une autorité différente. La CSCA délivre des certificats de clé publique pour les signataires de documents nationaux (c’est-à-dire les signataires des DCC), dont la durée de vie est brève, qui sont appelés certificats de signataire de documents (DSC). La CSCA joue un rôle d’ancre de confiance, de sorte que les États membres utilisateurs peuvent utiliser le certificat CSCA pour valider l’authenticité et l’intégrité des DSC qui changent régulièrement. Une fois la validation effectuée, les États membres peuvent fournir ces certificats (ou uniquement les clés publiques qu’ils contiennent) à leurs applications de validation des DCC. Outre les CSCA et les DSC, le DCCG utilise également les ICP pour authentifier les transactions, signer les données, comme base d’authentification et comme moyen de garantir l’intégrité des canaux de communication entre les États membres et le DCCG.

Les signatures numériques peuvent être utilisées pour garantir l’intégrité et l’authenticité des données. Les ICP établissent la confiance en associant des clés publiques à des identités vérifiées (ou des émetteurs). Cela est nécessaire pour permettre aux autres participants de vérifier l’origine des données et l’identité de l’interlocuteur et de décider s’ils peuvent leur accorder leur confiance. Le DCCG fait appel à des certificats de clé publique multiples à des fins d’authenticité. La présente annexe définit les certificats de clé publique utilisés et la manière dont ils doivent être conçus pour permettre une large interopérabilité entre les États membres. Elle fournit davantage de détails sur les certificats de clé publique nécessaires ainsi que des orientations sur les modèles de certificats et les périodes de validité pour les États membres qui souhaitent avoir leur propre CSCA. Étant donné que les DCC doivent être vérifiables pendant un laps de temps déterminé (à compter de la délivrance, expiration après un certain délai), il est nécessaire de définir un modèle de vérification pour toutes les signatures apposées sur les certificats de clé publique et les DCC.

2.   Terminologie

Le tableau suivant contient les abréviations et la terminologie utilisées dans la présente annexe.

Terme	Définition
Certificat	Ou certificat de clé publique. Certificat X.509 v3 contenant la clé publique d’une entité
CSCA	Autorité nationale de signature de certificats
DCC	Certificat COVID numérique de l’UE. Document numérique signé contenant des informations sur la vaccination, les tests ou le rétablissement
DCCG	Service passerelle du certificat COVID numérique de l’UE. Système utilisé pour l’échange de DSC entre les États membres.
DCCGTA	Certificat d’ancre de confiance du DCCG. La clé privée correspondante est utilisée pour signer la liste de tous les certificats CSCA hors ligne.
DCCGTLS	Certificat de serveur TLS (Transport Layer Security — Sécurité de la couche de transport) du DCCG.
DSC	Certificat de signataire de documents. Certificat de clé publique de l’autorité de signature des documents d’un État membre (par exemple, un système autorisé à signer des DCC). Ce certificat est délivré par la CSCA de l’État membre.
ECDSA	Algorithme de signature numérique à courbe elliptique. Algorithme de signature cryptographique reposant sur les courbes elliptiques
État membre	État membre de l’Union européenne
mTLS	TLS mutuels. Protocole de sécurité de la couche de transport avec authentification mutuelle
NB	Système d’arrière-plan national d’un État membre
NBCSCA	Certificat CSCA d’un État membre (il peut y en avoir plus d’un)
NBTLS	Certificat d’authentification client TLS d’un système d’arrière-plan national
NBUP	Certificat utilisé par un système d’arrière-plan national pour signer des paquets de données qui sont téléversés dans le DCCG
ICP	Infrastructure à clé publique. Modèle de confiance reposant sur les certificats de clé publique et les autorités de certification
RSA	Algorithme de cryptographie asymétrique reposant sur la factorisation des nombres entiers, utilisé pour les signatures numériques ou le chiffrement asymétrique

3.   Flux de communication et services de sécurité du DCCG

La présente section donne un aperçu des flux de communication et des services de sécurité dans le système du DCCG. Elle définit également les clés et certificats utilisés pour protéger la communication, les informations téléversées, les DCC et une trust list signée qui contient tous les certificats CSCA enrôlés. Le DCCG fonctionne comme une plateforme de données qui permet l’échange de paquets de données signés pour les États membres.

Les paquets de données téléversés sont fournis par le DCCG «en l’état», ce qui signifie que le DCCG n’ajoute ni ne supprime aucun DSC des paquets qu’il reçoit. Le système d’arrière-plan national (national backend — NB) des États membres est en mesure de vérifier l’intégrité et l’authenticité de bout en bout des données téléversées. En outre, les systèmes d’arrière-plan nationaux et le DCCG utiliseront l’authentification mutuelle TLS pour établir une connexion sécurisée. Ces mesures s’ajoutent aux signatures figurant dans les données échangées.

3.1.   Authentification et établissement de la connexion

Le DCCG utilise le protocole TLS avec authentification mutuelle pour établir un canal crypté authentifié entre le système d’arrière-plan national de l’État membre (NB) et l’environnement du service passerelle. Par conséquent, le DCCG détient un certificat de serveur TLS, dit «DCCGTLS», et les systèmes d’arrière-plan nationaux détiennent un certificat client TLS — appelé NBTLS. Les modèles de certificat sont fournis à la section 5. Tous les systèmes d’arrière-plan nationaux peuvent fournir leur propre certificat TLS. Ce certificat sera explicitement placé sur liste blanche et il peut par conséquent être délivré par une autorité de certification publique de confiance (par exemple, une autorité de certification qui respecte les exigences de base du CA/Browser Forum), par une autorité nationale de certification ou être autosigné. Chaque État membre est responsable de ses données nationales et de la protection de la clé privée utilisée pour établir la connexion avec le DCCG. L’approche «Apporter son propre certificat» requiert une procédure d’enregistrement et d’identification bien définie, ainsi que des procédures de révocation et de renouvellement, qui sont décrites aux sections 4.1, 4.2 et 4.3. Le DCCG utilise une liste blanche sur laquelle les certificats TLS des NB sont inscrits lorsque leur enregistrement a été effectué avec succès. Seuls les NB qui s’authentifient au moyen d’une clé privée correspondant à un certificat figurant sur la liste blanche peuvent établir une connexion sécurisée avec le DCCG. Le DCCG utilisera également un certificat TLS qui permet aux NB de vérifier qu’ils établissent effectivement une connexion avec le «véritable» DCCG et non avec une entité malveillante qui se fait passer pour le DCCG. Le certificat du DCCG sera fourni aux NB après un enregistrement effectué avec succès. Le certificat DCCGTLS sera délivré par une autorité de certification publique de confiance (incluse dans tous les principaux navigateurs). Il incombe aux États membres de vérifier que leur connexion au DCCG est sécurisée (par exemple, en vérifiant l’empreinte digitale du certificat DCCGTLS du serveur auquel ils sont connectés par rapport à celle qui a été fournie après l’enregistrement).

3.2.   Autorités nationales de signature de certificats et modèle de validation

Les États membres participant au cadre DCCG doivent faire appel à une CSCA pour délivrer les DSC. Un État membre peut avoir plusieurs CSCA (par exemple, en cas de décentralisation régionale). Chaque État membre peut soit avoir recours aux autorités de certification existantes, soit mettre en place une autorité de certification spécifique (éventuellement autosignée) pour le système de DCC.

Les États membres doivent présenter leur(s) certificat(s) CSCA à l’exploitant du DCCG lors de la procédure officielle d’enrôlement. Après l’enregistrement réussi de l’État membre (voir la section 4.1 pour plus de détails), l’exploitant du DCCG mettra à jour une trust list signée contenant tous les certificats CSCA actifs dans le cadre du DCC. L’exploitant du DCCG utilisera une paire de clés asymétriques dédiée pour signer la trust list et les certificats dans un environnement hors ligne. La clé privée ne sera pas stockée dans le système du DCCG en ligne, afin qu’un attaquant ne puisse pas compromettre la trust list si le système en ligne est compromis. Le certificat d’ancre de confiance correspondant DCCGTA sera fourni aux systèmes d’arrière-plan nationaux lors du processus d’enrôlement.

Les États membres peuvent obtenir la trust list auprès du DCCG pour leurs procédures de vérification. La CSCA est définie comme l’autorité de certification (CA) qui délivre des DSC, c’est pourquoi les États membres qui utilisent une hiérarchie d’autorités de certification à plusieurs niveaux (par exemple, CA racine — > CSCA — > DSC) doivent fournir l’autorité de certification subordonnée qui délivre les DSC. Dans ce cas, si un État membre fait appel à une autorité de certification existante, le système de DCC fera abstraction de tout ce qui se trouve au-dessus de la CSCA et ne placera sur la liste blanche que la CSCA en tant qu’ancre de confiance (même s’il s’agit d’une CA subordonnée). C’est le modèle de l’OACI, qui n’autorise que 2 niveaux — une CSCA «racine» et un DSC «feuille» signé par cette seule CSCA.

Si un État membre exploite sa propre CSCA, il est responsable du fonctionnement sécurisé et de la gestion des clés de cette autorité. La CSCA joue le rôle d’ancre de confiance pour les DSC et, par conséquent, la protection de la clé privée de la CSCA est essentielle pour l’intégrité de l’environnement du DCC. Le modèle de vérification dans l’ICP des DCC est le modèle shell, qui prévoit que tous les certificats présents dans la validation du chemin du certificat doivent être valables à un moment précis (c’est-à-dire au moment de la validation de la signature). Par conséquent, les restrictions suivantes s’appliquent:

—	la CSCA ne doit pas délivrer de certificats dont la durée de validité est supérieure à celle du certificat de la CA lui-même;

—	le signataire de documents ne doit pas signer de documents dont la durée de validité est supérieure à celle du DSC proprement dit;

—	les États membres qui exploitent leur propre CSCA doivent définir des périodes de validité pour leur CSCA et tous les certificats délivrés, et ils doivent prendre soin de renouveler les certificats.

La section 4.2 contient des recommandations concernant les périodes de validité.

3.3.   Intégrité et authenticité des données téléversées

Les systèmes d’arrière-plan nationaux peuvent utiliser le DCCG pour téléverser et télécharger des paquets de données signés numériquement après une authentification mutuelle réussie. Au début, ces paquets de données contiennent les DSC des États membres. La paire de clés utilisée par le système d’arrière-plan national pour la signature numérique des paquets de données téléversés dans le système du DCCG est appelée «paire de clés du système d’arrière-plan national pour signature de téléversement» et on désigne le certificat de clé publique correspondant par l’abréviation NBUP. Chaque État membre apporte son propre certificat NBUP, qui peut être autosigné ou délivré par une autorité de certification existante, telle qu’une autorité de certification publique (c’est-à-dire une autorité de certification qui délivre des certificats conformément aux exigences de base du CA/Browser Forum). Le certificat NBUP doit être différent de tous les autres certificats utilisés par l’État membre (certificats CSCA, client TLS ou DSC).

Les États membres doivent fournir le certificat de téléversement à l’exploitant du DCCG au cours de la procédure d’enregistrement initiale (voir la section 4.1 pour plus de détails). Chaque État membre est responsable de ses données nationales et doit assurer la protection de la clé privée utilisée pour signer les téléversements.

D’autres États membres peuvent vérifier les paquets de données signés à l’aide des certificats de téléversement fournis par le DCCG. Le DCCG vérifie l’authenticité et l’intégrité des données téléversées au moyen du certificat de téléversement du NB avant que les données ne soient fournies aux autres États membres.

3.4.   Exigences relatives à l’architecture technique du DCCG

Les exigences relatives à l’architecture technique du DCCG sont les suivantes:

—	le DCCG utilise l’authentification TLS mutuelle pour établir une connexion cryptée authentifiée avec les NB. Par conséquent, le DCCG tient à jour une liste blanche de certificats clients NBTLS enregistrés,

—	le DCCG utilise deux certificats numériques (DCCGTLS et DCCGTA) avec deux paires de clés distinctes. La clé privée de la paire de clés DCCGTA est conservée hors ligne (et non sur les composants en ligne du DCCG),

—	le DCCG tient à jour une trust list des certificats NBCSCA signée avec la clé privée DCCGTA,

—	le chiffrement utilisé doit satisfaire aux exigences de la section 5.1.

4.   Gestion du cycle de vie des certificats

4.1.   Enregistrement des systèmes d’arrière-plan nationaux

Les États membres doivent s’enregistrer auprès de l’exploitant du DCCG pour participer au système du DCCG. La présente section décrit la procédure technique et opérationnelle qui doit être suivie pour enregistrer un système d’arrière-plan national.

L’exploitant du DCCG et l’État membre doivent échanger des informations sur les personnes à contacter pour des questions techniques sur le processus d’enrôlement. Il est présumé que ces personnes de contact bénéficient d’une habilitation de leur État membre et que leur identification/authentification est effectuée par d’autres canaux. Par exemple, l’authentification peut être réalisée lorsque la personne chargée des contacts techniques d’un État membre fournit par courriel les certificats sous forme de fichiers cryptés par mot de passe et communique par téléphone à l’exploitant du DCCG le mot de passe correspondant. D’autres canaux sécurisés définis par l’exploitant du DCCG peuvent également être utilisés.

L’État membre doit fournir trois certificats numériques au cours du processus d’enregistrement et d’identification:

—	le certificat TLS de l’État membre NBTLS

—	le certificat de téléversement de l’État membre NBUP

—	le(s) certificat(s) CSCA de l’État membre NBCSCA

Tous les certificats fournis doivent respecter les exigences définies à la section 5. L’exploitant du DCCG vérifiera que le certificat fourni satisfait aux exigences de la section 5. Après l’identification et l’enregistrement, l’exploitant du DCCG:

—	ajoute le(s) certificat(s) NBCSCA à la trust list signée au moyen de la clé privée correspondant à la clé publique DCCGTA;

—	ajoute le certificat NBTLS à la liste blanche du point de terminaison TLS du DCCG;

—	ajoute le certificat NBUP au système du DCCG;

—	fournit le certificat de clé publique DCCGTA et DCCGTLS à l’État membre.

4.2.   Autorités de certification, périodes de validité et renouvellement

Si un État membre souhaite exploiter sa propre CSCA, les certificats CSCA peuvent être des certificats autosignés. Ils jouent le rôle d’ancre de confiance de l’État membre et, par conséquent, l’État membre doit prendre des mesures robustes pour protéger la clé privée correspondant à la clé publique du certificat CSCA. Il est recommandé aux États membres d’utiliser un système hors ligne pour leur CSCA, c’est-à-dire un système informatique qui n’est connecté à aucun réseau. L’accès au système doit être soumis à un contrôle multiple (par exemple, selon le principe des quatre yeux). Après la signature des DSC, des contrôles opérationnels doivent être appliqués et le système qui détient la clé CSCA privée doit être stocké en toute sécurité et faire l’objet de contrôles d’accès rigoureux. Des modules de sécurité matériels ou des cartes intelligentes peuvent être utilisés pour renforcer la protection de la clé privée CSCA. Les certificats numériques prévoient une période de validité qui impose de respecter le renouvellement des certificats. Le renouvellement est nécessaire pour utiliser de nouvelles clés cryptographiques et adapter les tailles de clés lorsque de nouveaux progrès dans le domaine du calcul ou de nouvelles attaques menacent la sécurité de l’algorithme de cryptographie utilisé. Le modèle shell s’applique (voir section 3.2).

Sur la base d’une durée de validité d’un an pour les certificats COVID numériques, les durées de validité recommandées sont les suivantes:

—	CSCA: 4 ans

—	DSC: 2 ans

—	téléversement: 1-2 ans

—	authentification du client TLS: 1-2 ans

Pour que le renouvellement puisse avoir lieu en temps voulu, les périodes d’utilisation recommandées pour les clés privées sont les suivantes:

—	CSCA: 1 an

—	DSC: 6 mois

Les États membres doivent créer de nouveaux certificats de téléversement et de nouveaux certificats TLS en temps voulu, par exemple un mois avant la date d’expiration, afin de garantir un fonctionnement harmonieux. Les certificats CSCA et les DSC devraient être renouvelés au moins un mois avant que l’utilisation de la clé privée ne prenne fin (en tenant compte des procédures opérationnelles nécessaires). Les États membres doivent fournir à l’exploitant du DCCG des certificats CSCA, des certificats de téléversement et des certificats TLS actualisés. Les certificats périmés doivent être retirés de la liste blanche et de la trust list.

Les États membres et l’exploitant du DCCG doivent assurer le suivi de la validité de leurs propres certificats. Il n’existe pas d’entité centrale qui assure le suivi de la validité des certificats et en informe les participants.

4.3.   Révocation de certificats

En général, les certificats numériques peuvent être révoqués par leur autorité de certification émettrice au moyen des listes de révocation des certificats ou du protocole de vérification des certificats en ligne (Online Certificate Status Protocol Responder — service OCSP). Les CSCA pour le système de DCC devraient fournir des listes de révocation de certificats (CRL). Même si ces CRL ne sont pas utilisées actuellement par les autres États membres, elles devaient être intégrées en prévision d’applications futures. Si une CSCA décide de ne pas fournir de CRL, les DSC de cette CSCA devront être renouvelés lorsque les CRL deviendront obligatoires. Pour la validation des DSC, les vérificateurs devraient utiliser les CRL et non le service OCSP. Il est recommandé que le système d’arrière-plan national procède à la validation nécessaire des DSC téléchargés à partir du DCCG et ne transmette aux validateurs de DCC nationaux qu’une série de DSC dignes de confiance et validés. Les validateurs des DCC ne devraient pas effectuer de contrôle de révocation sur les DSC dans le cadre de leur processus de validation. Cela correspond, notamment, au souci de protéger la vie privée des titulaires de DCC en prévenant tout risque que l’utilisation d’un DSC donné puisse être surveillée par le service OCSP qui lui est associé.

Les États membres peuvent retirer leurs DSC du DCCG de leur propre initiative en utilisant des certificats de téléversement et des certificats TLS valides. Lorsqu’un DSC est supprimé, tous les DCC délivrés avec ce DSC deviendront invalides lorsque les États membres consulteront les listes de DSC actualisées. La protection des clés privées correspondant aux DSC est cruciale. Les États membres doivent informer l’exploitant du DCCG lorsqu’ils doivent révoquer des certificats de téléversement ou TLS, par exemple en raison d’une compromission du système d’arrière-plan national. L’exploitant du DCCG peut alors retirer la confiance accordée au certificat concerné, par exemple en le supprimant de la liste blanche TLS. L’exploitant du DCCG peut supprimer les certificats de téléversement de la base de données DCCG. Les paquets signés avec la clé privée correspondant à ce certificat de téléversement deviendront invalides lorsque les systèmes d’arrière-plan nationaux retireront la confiance accordée au certificat de téléversement révoqué. Si un certificat CSCA doit être révoqué, les États membres doivent en informer l’exploitant du DCCG ainsi que les autres États membres avec lesquels ils entretiennent des relations de confiance. L’exploitant du DCCG publiera une nouvelle trust list sur laquelle le certificat concerné ne figurera plus. Tous les DSC émis par cette CSCA deviendront invalides lorsque les États membres mettront à jour leur magasin de confiance d’arrière-plan national. Si le certificat DCCGTLS ou le certificat DCCGTA doit être révoqué, l’exploitant du DCCG et les États membres doivent collaborer pour établir une nouvelle connexion TLS de confiance ainsi qu’une nouvelle trust list.

5.   Modèles de certificats

La présente section énonce des exigences et fournit des orientations en ce qui concerne la cryptographie et établit également des exigences relatives aux modèles de certificat. Pour ce qui concerne les certificats DCCG, la présente section définit les modèles de certificats.

5.1.   Exigences cryptographiques

Les algorithmes de cryptographie et les suites cryptographiques TLS seront choisis sur la base des recommandations en vigueur de l’Office fédéral allemand de la sécurité de l’information (BSI) ou du SOG-IS.Ces recommandations et celles d’autres institutions et organismes de normalisation sont similaires. Les recommandations figurent dans les orientations techniques TR 02102-1 et TR 02102-2 (1) ou dans les mécanismes cryptographiques approuvés du SOG-IS (2).

5.1.1.   Exigences relatives au DSC

Les exigences prévues à l’annexe I, section 3.2.2 sont applicables. Par conséquent, il est vivement recommandé aux signataires de documents d’utiliser l’algorithme de signature numérique à courbe elliptique (ECDSA) avec la courbe NIST-p-256 (telle que définie à l’appendice D de la norme FIPS PUB 186-4). Les autres courbes elliptiques ne sont pas prises en charge. En raison des contraintes d’espace imposées par le DCC, les États membres ne devraient pas utiliser le RSA-PSS, même s’il est autorisé en tant qu’algorithme de secours. Si les États membres ont recours au RSA-PSS, ils doivent utiliser un modulus d’une taille de 2048 ou 3072 bits au maximum. SHA-2 avec une valeur de sortie d’une longueur ≥ 256 bits doit être utilisé comme fonction de hachage cryptographique (voir ISO/IEC 10118-3: 2004) pour la signature du DSC.

5.1.2.   Exigences relatives aux certificats TLS, de téléversement et CSCA

Pour les certificats numériques et les signatures cryptographiques dans le contexte du DCCG, les principales exigences relatives aux algorithmes cryptographiques et à la longueur des clés sont résumées dans le tableau suivant (à partir de 2021):

Algorithme de signature	Taille de la clé	Fonction de hachage
ECDSA	Min. 250 bits	SHA-2 avec une valeur de sortie d’une longueur ≥ 256 bits
RSA-PSS (bourrage recommandé) RSA-PKCS # 1 v1.5 (versions antérieures pour bourrage)	Min. 3000 bits modulus RSA n avec exposant public e > 2 ^ 16	SHA-2 avec une valeur de sortie d’une longueur ≥ 256 bits
DSA	Min. 3000 bits nombre premier p, 250 bits clé q	SHA-2 avec une valeur de sortie d’une longueur ≥ 256 bits

La courbe elliptique recommandée pour l’ECDSA est la NIST-p-256 car elle est largement utilisée.

5.2.   Certificat CSCA (NBCSCA)

Le tableau suivant fournit des indications sur le modèle de certificat NBCSCA si un État membre décide d’exploiter sa propre CSCA pour le système de DCC.

Les mentions en gras sont obligatoires (à inclure obligatoirement dans le certificat), les mentions en italiques sont recommandées (il est recommandé de les inclure). Pour les champs absents, aucune recommandation n’est formulée.

Champ	Valeur
Subject	cn=<nom commun unique et non vide>, o=<Prestataire>, c=<État membre exploitant la CSCA>
Key usage	certificate signing, CRL signing (au minimum)
Basic Constraints	CA = true, path length constraints = 0

Le nom du sujet doit être non vide et unique dans l’État membre considéré. Le code pays (c) doit correspondre à l’État membre qui utilisera ce certificat CSCA. Le certificat doit contenir un identifiant de clé du sujet (SKI) unique conforme à la RFC 5280 (3).

5.3.   Certificat de signataire de documents (DSC)

Le tableau suivant fournit des orientations sur le DSC. Les mentions en gras sont obligatoires (à inclure obligatoirement dans le certificat), les mentions en italiques sont recommandées (il est recommandé de les inclure). Pour les champs absents, aucune recommandation n’est formulée.

Champ	Valeur
Serial Number	numéro de série unique
Subject	cn=<nom commun unique et non vide>, o=<Prestataire>, c=<État membre utilisant ce DSC>
Key Usage	digital signature (au minimum)

Le DSC doit être signé avec la clé privée correspondant à un certificat CSCA utilisé par l’État membre.

Les extensions suivantes doivent être utilisées:

—	le certificat doit contenir un identifiant de clé de l’autorité (AKI) correspondant à l’identifiant de clé du sujet (SKI) du certificat de la CSCA émettrice,

—	le certificat doit contenir un identifiant de clé du sujet (SKI) unique conforme à la RFC 5280 (4).

En outre, le certificat doit contenir l’extension du point de distribution de la CRL qui renvoie à la liste de révocation de certificats (CRL) fournie par la CSCA qui a émis le DSC.

Le DSC peut contenir une extension EKU (extended key usage — utilisation étendue de la clé) avec zéro ou plusieurs identifiants de la politique d’utilisation des clés qui limitent les types de HCERT que ce certificat est autorisé à vérifier. Si un ou plusieurs identifiants sont présents, les vérificateurs vérifient l’utilisation de la clé par rapport au HCERT stocké. Les valeurs d’utilisation étendue de la clé suivantes sont définies à cet effet:

Champ	Valeur
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.1 pour les émetteurs «tests»
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.2 pour les émetteurs «vaccination»
extendedKeyUsage	1.3.6.1.4.1.1847.2021.1.3 pour les émetteurs «rétablissement»

En l’absence d’extension d’utilisation de la clé (c’est-à-dire pas d’extension ou zéro extension), ce certificat peut être utilisé pour valider tout type de HCERT. D’autres identifiants de politique d’utilisation étendue de la clé pertinents utilisés avec la validation des HCERT peuvent être définis par d’autres documents.

5.4.   Certificats de téléversement (NBUP)

Le tableau suivant fournit des orientations pour le certificat de téléversement du système d’arrière-plan national. Les mentions en gras sont obligatoires (à inclure obligatoirement dans le certificat), les mentions en italiques sont recommandées (il est recommandé de les inclure). Pour les champs absents, aucune recommandation n’est formulée.

Champ	Valeur
Subject	cn=<nom commun unique et non vide>, o=<Prestataire>, c=<État membre utilisant ce certificat de téléversement>
Key Usage	digital signature (au minimum)

5.5.   Certificat d’authentification client TLS du système d’arrière-plan national (NBTLS)

Le tableau suivant fournit des orientations pour le certificat d’authentification client TLS du système d’arrière-plan national. Les mentions en gras sont obligatoires (à inclure obligatoirement dans le certificat), les mentions en italiques sont recommandées (il est recommandé de les inclure). Pour les champs absents, aucune recommandation n’est formulée.

Champ	Valeur
Subject	cn=<nom commun unique et non vide>, o=<Prestataire>, c=<État membre sur le NB>
Key Usage	digital signature (au minimum)
Extended key usage	client authentication (1.3.6.1.5.5.7.3.2)

Le certificat peut également contenir le server authentication (1.3.6.1.5.5.7.3.1) de l’utilisation étendue de la clé, mais ce n’est pas obligatoire.

5.6.   Certificat de signature de la trust list (DCCGTA)

Le tableau suivant définit le certificat d’ancre de confiance du DCCG.

Champ	Valeur
Subject	cn = Digital Green Certificate Gateway  (5) , o=<Prestataire>, c=<pays>
Key Usage	digital signature (au minimum)

5.7.   Certificats de serveur TLS du DCCG (DCCGTLS)

Le tableau suivant définit le certificat TLS du DCCG.

Champ	Valeur
Subject	cn=<FQDN ou adresse IP du DCCG>, o=<Prestataire>, c= <pays>
SubjectAltName	dNSName: <Nom DCCG DNS> ou iPAddress: <adresse IP DCCG>
Key Usage	digital signature (au minimum)
Extended key usage	server authentication (1.3.6.1.5.5.7.3.1)

Le certificat peut également contenir le client authentication (1.3.6.1.5.5.7.3.2) de l’utilisation étendue de la clé, mais ce n’est pas obligatoire.

Le certificat TLS du DCCG doit être délivré par une autorité de certification de confiance publique (incluse dans tous les principaux navigateurs et systèmes d’exploitation, conformé

---

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

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

(3)  rfc5280 (ietf.org).

(4)  rfc5280 (ietf.org).

(5)  Le terme «Digital Green Certificate» au lieu de «EU Digital COVID Certificate» a été conservé dans ce contexte, car c’est cette terminologie qui a été codifiée et déployée dans le certificat avant que les colégislateurs ne s’accordent sur un nouveau terme.

«(3)

[…] Elle interdit également la vente, la fourniture, le transfert ou l’exportation d’équipements, de technologies et de logiciels […] En outre, elle introduit de nouvelles restrictions commerciales concernantles produits pétroliers, le chlorure de potassium (“potasse”) et les biens utilisés pour la production ou la fabrication de produits du tabac. […]»,

«(3)

[…] Elle interdit également la vente, la fourniture, le transfert ou l’exportation d’équipements, de technologies ou de logiciels […] En outre, elle introduit de nouvelles restrictions commerciales concernant les produits pétroliers, le chlorure de potassium (“potasse”) et les biens utilisés pour la production ou la fabrication de produits du tabac. […]».