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. 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).
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) 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, 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, 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) 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). 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. 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) et le mécanisme de compression Deflate, au format défini dans la RFC 1951.
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, 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.
9. Solution de révocation
9. 1. Établissement des listes de révocation de DCC (DCC Revocation List — DRL)
Le service passerelle fournit des points de terminaison (endpoints) et une fonctionnalité pour conserver et gérer les listes de révocation:
9. 2. Modèle de confiance
Toutes les connexions sont établies par le modèle de confiance type du DCCG par les certificats NBTLS et NBUP (voir gouvernance des certificats). Toutes les informations sont assemblées en paquet et chargées par messages CMS afin que leur intégrité soit garantie.
9. 3. Construction des lots
9. 3.1. Lot (Batch)
Chaque liste de révocation contient une ou plusieurs entrées et est assemblée en paquet par lots contenant un ensemble de hachages (hashes) et leurs métadonnées. Un lot est immuable (immutable) et définit une date d’expiration qui indique à quel moment le lot peut être supprimé. La date d’expiration de tous les éléments du lot doit être exactement la même, ce qui signifie que les lots doivent être regroupés par date d’expiration et par DSC signataire. Chaque lot contient au maximum 1 000 entrées. Si la liste de révocation comporte plus de 1 000 entrées, des lots multiples sont créés. Une entrée ne peut apparaître que dans un seul lot au maximum. Le lot est empaqueté dans une structure CMS et signé par le certificat NBUP du pays de chargement.
9. 3.2. Index des lots (Batch Index)
Lorsqu’un lot (batch) est créé, il se voit attribuer un ID unique par le service passerelle et est automatiquement ajouté dans l’index. L’index des lots indique les dates modifiées, par ordre chronologique ascendant.
9. 3.3. Comportement du service passerelle
Le service passerelle traite les lots de révocation sans aucune modification: il ne peut ni mettre à jour, ni supprimer les lots, ni y ajouter aucune information. Les lots sont transmis à tous les pays autorisés (voir chapitre 9.6).
Le service passerelle surveille activement les dates d’expiration des lots et supprime les lots ayant expiré. Une fois le lot supprimé, le service passerelle renvoie une réponse «HTTP 410 Gone» pour l’URL du lot supprimé. De ce fait, le lot apparaît dans l’index des lots comme étant «supprimé».
9. 4. Types de hachage (Hash Types)
La liste de révocation contient des hachages qui peuvent représenter différents attributs/types de révocation. Ces types ou attributs sont indiqués lors de l’établissement des listes de révocation. Les types actuels sont les suivants:
| Type | Attribut | Calcul du hachage
| SIGNATURE | DCC Signature | SHA256 of DCC Signature
| UCI | UCI (Unique Certificate Identifier) | SHA256 of UCI
| COUNTRYCODEUCI | Issuing Country Code + UCI | SHA256 of Issuing CountryCode + UCI
Seuls les 128 bits initiaux des hachages encodés en chaînes base64 (base64 strings) sont placés dans les lots et utilisés pour identifier le DCC révoqué.
9. 4.1. Type de hachage: SHA256 (Signature DCC)
Dans ce cas, le hachage est calculé sur les octets (bytes) de la signature COSE_SIGN1 venant du CWT. Pour les signatures RSA, la signature entière sera utilisée comme entrée. Pour les certificats signés EC-DSA, la formule utilise la valeur r comme entrée:
SHA256(r)
[nécessaire pour toutes les nouvelles mises en œuvre]
9. 4.2. Type de hachage: SHA256(UCI)
Dans ce cas, le hachage est calculé sur la chaîne UCI (UCI string) encodée en UTF-8 et convertie en un byte array.
[déconseillé, mais supporté pour des raisons de rétrocompatibilité]
9. 4.3. Type de hachage: SHA256(Issuing CountryCode+UCI)
Dans ce cas, CountryCode encodé en une chaîne UTF-8 (UTF-8 string) concaténé avec l’UCI encodé avec une chaîne UTF-8. Il est ensuite converti en un byte array et utilisé comme entrée pour la fonction de hachage.
[déconseillé2, mais supporté pour des raisons de rétrocompatibilité]
9. 5. Structure de l’API
9. 5.1. API fournissant les entrées de révocation
9. 5.1.1. Objectif
L’API fournit les entrées des listes de révocation par lots et comporte un index des lots.
9. 5.1.2. Points de terminaison (endpoints)
9. 5.1.2.1. Point de terminaison pour le téléchargement des listes de lots
Les points de terminaison suivent une conception simple et renvoient une liste de lots avec un petit wrapper fournissant des métadonnées (metadata). Les lots sont triés par date, par ordre (chronologique) ascendant:
/revocation-list
Verb: GET
Content-Type: application/json
Response: JSON Array
{
“more”:true|false,
“batches”:
[{
“batchId”: “{uuid}”,
“country”: “XY”,
“date”: “2021-11-01T00:00:00Z”
“deleted”: true | false
}, ..
]
}
Remarque: Le résultat est limité par défaut à 1 000. Si le drapeau «more» est paramétré sur «true», la réponse indique qu’il est possible de télécharger davantage de lots. Pour télécharger davantage d’éléments, le client doit régler l’en-tête (header) If-Modified-Since sur une date qui ne doit pas être antérieure à la dernière entrée reçue.
La réponse contient un JSON array dont la structure est la suivante:
| Champ | Définition
| more | Drapeau booléen qui indique qu’il y a davantage de lots.
| batches | Array avec les lots existants.
| batchId | https://fr.wikipedia.org/wiki/Universally_unique_identifier
| country | Code pays ISO 3166
| date | ISO 8601 Date UTC. Date à laquelle le lot a été ajouté ou supprimé.
| deleted | boolean. «True» si supprimé. Lorsque le drapeau «supprimé» est sélectionné, l’entrée peut être finalement retirée des résultats de la requête après 7 jours.
9. 5.1.2.1.1. Codes de réponse
| Code | Description
| 200 | Tout OK.
| 204 | Pas de contenu, si l’en-tête (header) «If-Modified-Since» n’a pas de correspondance.
En-tête de requête (Request Header)
| En-tête | Obligatoire | Description
| If-Modified-Since | Oui | Cet en-tête contient la dernière date téléchargée afin de n’obtenir que les résultats les plus récents. Lors de l’appel initial, l’en-tête devrait être réglé sur “2021-06-01T00:00:00Z”.
9. 5.1.2.2. Point de terminaison pour le téléchargement des lots
Les lots contiennent une liste d’identifiants de certificats:
/revocation-list/{batchId}
Verb: GET
Accepts: application/cms
Response:CMS with Content
{
“country”: “XY”,
“expires”: “2022-11-01T00:00:00Z”,
“kid”:“23S+33f=”,
“hashType”:“SIGNATURE”,
“entries”:[{
“hash”:“e2e2e2e2e2e2e2e2”
}, ..]
}
La réponse contient un CMS comportant une signature qui doit correspondre au certificat NBUP du pays. Tous les éléments du JSON array contiennent la structure suivante:
Remarques:
| Champ | Obligatoire | Type | Définition
| expires | Oui | String |
Date à laquelle l’élément peut être retiré.
ISO8601 Date/heure UTC
| country | Oui | String | Code pays ISO 3166
| hashType | Oui | String | Type de hachage des entrées fournies (voir Types de hachage)
| entries | Oui | JSON Object Array | Voir tableau Entrées
| kid | Oui | String |
KID encodé en base64 du DSC utilisé pour signer le DCC.
Si le KID n’est pas connu, la chaîne 'UNKNOWN_KID' (à l’exclusion des ') peut être utilisée.
— Les lots sont regroupés par date d’expiration et par DSC — tous les éléments expirent en même temps et ont été signés par la même clé.
— L’heure d’expiration est une date/heure en UTC parce que l’EUDCC est un système mondial et que nous devons utiliser une heure dépourvue d’ambiguïté.
— La date d’expiration d’un DCC définitivement révoqué est fixée à la date d’expiration du DSC correspondant utilisé pour signer le DCC ou à l’heure d’expiration du DCC révoqué (auquel cas les heures NumericDate/epoch utilisées sont considérées comme se trouvant dans le fuseau horaire UTC).
— Le système d’arrière-plan national (National Backend — NB:) supprime des éléments de leur liste de révocation lorsque la date d’expiration est atteinte.
— Le NB: peut retirer des éléments de leur liste de révocation si le kid utilisé pour signer le DCC est révoqué.
9. 5.1.2.2.1. Entrées
| Champ | Obligatoire | Type | Définition
| hash | Oui | String | 128 bits initiaux du hachage SHA256 encodés en une chaîne base64 (base64 string)
Remarque: L’objet des entrées ne contient actuellement qu’un hachage, mais c’est un objet qui a été choisi, plutôt qu’un JSON array, pour permettre la compatibilité avec les modifications à venir.
9. 5.1.2.2.2. Codes de réponse
| Code | Description
| 200 | Tout OK.
| 410 | Batch gone. Le lot peut être supprimé dans le système d’arrière-plan national.
9. 5.1.2.2.3. En-têtes de réponse
| En-tête | Description
| ETag | ID du lot
9. 5.1.2.3. Point de terminaison pour le chargement des lots
Le chargement est effectué sur le même point de terminaison au moyen du verbe (Verb) POST:
/revocation-list
Verb: POST
Accepts: application/cms
Request: CMS with Content
ContentType: application/cms
Content:
{
“country”: “XY”,
“expires”: “2022-11-01T00:00:00Z”,
“kid”:“23S+33f=”,
“hashType”:“SIGNATURE”,
“entries”:[{
“hash”:“e2e2e2e2e2e2e2e2”
}, ..]
}
Le lot est signé en utilisant le certificat NBUP. Le service passerelle vérifie que la signature a été réglée par le NBUP pour le pays concerné. Si la vérification de la signature échoue, le chargement échoue.
REMARQUE: Chaque lot est immuable (immutable) et ne peut pas être modifié après le chargement. Il peut toutefois être supprimé. L’ID de chaque lot supprimé est stocké, et tout chargement d’un nouveau lot portant le même ID est rejeté.
9. 5.1.2.4. Point de terminaison pour la suppression des lots
Un lot peut être supprimé sur le même point de terminaison au moyen du verbe (Verb) DELETE:
/revocation-list
Verb: DELETE
Accepts: application/cms
ContentType: application/cms
Request: CMS with Content
Content:
{
“batchId”: “...”
}
ou, pour des raisons de compatibilité, au point de terminaison suivant au moyen du verbe (Verb) POST:
/revocation-list/delete
Verb: POST
Accepts: application/cms
ContentType: application/cms
Request: CMS with Content
Content:
{
“batchId”: “...”
}
9. 6. Protection de l’API/RGPD
La présente section précise les mesures garantissant que la mise en œuvre respecte les dispositions du règlement (UE) 2021/953 en ce qui concerne le traitement des données à caractère personnel.
9. 6.1. Authentification existante
Le service passerelle utilise actuellement le certificat NBTLS pour authentifier les pays qui s’y connectent. Cette authentification peut être utilisée pour déterminer l’identité du pays connecté au service passerelle. Cette identité peut ensuite être utilisée pour mettre en œuvre le contrôle d’accès.
9. 6.2. Contrôle d’accès
Pour pouvoir traiter légalement des données à caractère personnel, le service passerelle met en œuvre un mécanisme de contrôle de l’accès.
Le système passerelle met en œuvre une liste de contrôle d’accès (Access Control List) combinée à une sécurité fondée sur les rôles (Role Based Security). Ce système implique de tenir deux tableaux, l’un indiquant quels rôles peuvent appliquer quelles opérations à quelles ressources, l’autre indiquant quels rôles sont attribués à quels utilisateurs.
La mise en œuvre des contrôles requis par le présent document nécessite les trois rôles suivants:
RevocationListReader
RevocationUploader
RevocationDeleter
Les points de terminaison (endpoints) suivants vérifient si l’utilisateur (User) dispose du rôle (Role) de RevocationListReader; s’ils effectuent la vérification, l’accès est accordé et, si ce n’est pas le cas, le système passerelle renvoie un HTTP 403 Forbidden:
GET/revocation-list/
GET/revocation-list/{batchId}
Les points de terminaison suivants vérifient si l’utilisateur dispose du rôle de RevocationUploader; s’ils effectuent la vérification, l’accès est accordé et, si ce n’est pas le cas, le système passerelle renvoie un HTTP 403 Forbidden:
POST/revocation-list
Les points de terminaison suivants vérifient si l’utilisateur dispose du rôle de RevocationDeleter; s’ils effectuent la vérification, l’accès est accordé et, si ce n’est pas le cas, le système passerelle renvoie un HTTP 403 Forbidden:
DELETE/revocation-list
POST/revocation-list/delete
Le service passerelle fournit également une méthode fiable permettant aux administrateurs de gérer les rôles liés aux utilisateurs de manière à réduire les risques d’erreurs humaines sans pour autant occasionner de charge pour les administrateurs fonctionnels.