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 ou dans les mécanismes cryptographiques approuvés du SOG-IS.
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.
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.
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, 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é