Machine Translated by Google

Réseau de cybersanté

Lignes directrices sur

Spécifications techniques
des certificats verts numériques
Tome 3

Code 2D interopérable

Variante 1.3
2021-04-21
Machine Translated by Google

Réseau de cybersanté

Le réseau eHealth est un réseau volontaire, créé en vertu de l'article 14 de la directive 2011/24/UE.
Il fournit une plate-forme des autorités compétentes des États membres chargées de la santé en ligne.

Adopté par le réseau eHealth le 21 avril 2021.

2
Machine Translated by Google

Réseau de cybersanté

TABLE DES MATIÈRES

TABLE DES MATIÈRES............................................... .................................................. ....... 3

TABLEAU DES TABLEAUX .................................................. .................................................. ............ 4

1 Introduction................................................. .................................................. ............... 5

1.1 Contexte ....................................................... .................................................. ............................... 5

1.2 Portée du document.................................................. .................................................. ............. 5

1.3 Interopérabilité internationale .................................................. ............................................... 5

2 Structures et formats de données .................................................. .................................................. 6

2.1 CBOR / COSE ....................................................... .................................................. ....................... 6

2.2 Algorithme de compression.................................................. .................................................. ..... 6

2.3 Versionnement du code 2D .................................................. .................................................. ............ 6

2.4 Identification de la clé publique utilisée.................................................. .............................................. 7

2.5 Noms des champs de données.............................................. .................................................. ................. 7

2.6 Contenu COSE / CBOR ................................................ .................................................. ........... 7

2.6.1 Structure du COSE.................................................. .................................................. ................ 7
2.6.2 En-tête de Valeurs
2.6.3 signature ..................................
communes de charge utile .................................................. ..................................
....... .................................................. 7
.....................................
8 2.6.4 Charge utile........ .................................................. .................................................. ................ 8

2.7 Contenu de données facultatif .................................................. .................................................. ......... 8

3 Sérialisation................................................................ .................................................. ................ 9

4 Feuille de route de mise en œuvre .................................................. ...........................................dix

3
Machine Translated by Google

Réseau de cybersanté

TABLE DES TABLES

Tableau 1ÿ: Exemple de contexte de données .................................. .................................... 6

Tableau 2 : Format THINGS ................................................ ................................................. 7
Tableau 3 : Format d'en-tête.................................................. ............................................... 8
Tableau 4 : Valeurs communes.................................................. .................................................. 8

Tableau 5 : Feuille de route.............................................. .................................................. ... dix

TABLE DES FIGURES

Figure 1 : Processus de sérialisation .................................................. .................................... 9

4
Machine Translated by Google

Réseau de cybersanté

1. Introduction

1.1 Contexte

Ce document spécifie une structure de données générique et des mécanismes de codage pour les certificats de santé
électroniques. Elle spécifie également un mécanisme de codage de transport dans un format optique lisible par machine
(QR), qui peut être affiché sur l'écran d'un appareil mobile ou imprimé sur une feuille de papier. Ce document doit être lu
conjointement avec le réseau eHealth (eHN)
Directives sur les spécifications techniques pour les certificats verts numériques (DGC), Volume 1. En cas de divergences
entre ce document et les Directives de l'eHN sur les spécifications techniques pour les DGC, Volume 1, cette dernière prévaut.

1.2 Portée du document

Le champ d'application du document comprend des définitions supplémentaires des structures de données, des encodages
et des formats pour la création d'un code 2D conçu pour fournir un véhicule uniforme et normalisé pour les certificats verts
de l'UE pour tous les émetteurs. L'objectif est d'harmoniser la manière dont les certificats verts européens sont représentés,
encodés et signés pour faciliter l'interopérabilité.

1.3 Interopérabilité internationale

Les solutions technologiques du certificat vert numérique devraient chercher à assurer l'interopérabilité avec les initiatives
mondiales pertinentes, en particulier l'Organisation mondiale de la santé (OMS) et l'Organisation de l'aviation civile
internationale (OACI). Cela peut inclure des fonctionnalités d'interopérabilité avec des codes-barres 2D conformes à d'autres
normes/formats internationaux reconnus, par exemple en permettant une conversion adéquate entre les formats de certificat.

5
Machine Translated by Google

Réseau de cybersanté

2 Structures et formats de données

2.1 CBOR / COSE

Pour optimiser l'empreinte du code 2D, les objets sont encodés en tant qu'objet CBOR1. Pour garantir l'intégrité des
données, la signature et le cryptage d'objet CBOR2 sont utilisés. Pour utiliser CBOR, il faut tenir compte des règles de
sérialisation recommandées3 .

Il est important de s'assurer lors de la conversion des conseils dans le CBOR RFC4 .

Il faut s'assurer que toutes les clés d'un objet JSON sont encodées en UTF-8.

Outre le(s) nom(s) et prénom(s) du titulaire encodés en UTF-8, le code-barres 2D doit inclure un deuxième ensemble de
champs du même nom encodés en ASCII conformément au document OACI 9303 partie 35 . Le nom personnel encodé en
ASCII doit correspondre au nom figurant sur le document de voyage délivré au titulaire.

Comme décrit dans la DSC-Spec, le format CWT est utilisé pour établir un format de conteneur standard pour les certificats
verts. Il faut s'assurer que ce type de revendications standard définies n'est pas rompu par des revendications personnalisées
ou retapé par différents types de données.

2.2 Algorithme de compression

Pour compresser les objets de données COSE, l'algorithme de compression zlib est utilisé.

2.3 Versionnement du code 2D

Dans les cas d'utilisation productifs, de nombreux codes 2D différents avec des hypothèses différentes peuvent être
scannés par le vérificateur. Pour s'assurer que le contexte du code scanné est toujours clair pour le traitement (par exemple,
schéma utilisé, ensembles de valeurs à ce moment, règles, etc.), un préfixe de contexte est établi pour représenter
différentes versions.

Le champ de version est exprimé sous la forme d'une valeur de chaîneÿ:

Valeur de la version Version

HC1 Certificat sanitaire Version 1
HC2 Certificat sanitaire Version 2
.. …

Tableau 1ÿ: Exemple de contexte de données

Chaque contexte correspond à un document de découverte, qui est fourni via la DGCG ou
back-ends. Le contexte peut être défini spécifiquement par chaque pays ou par le Réseau eSanté.

1
https://tools.ietf.org/html/rfc8949
2
https://tools.ietf.org/html/rfc8152
3 https://tools.ietf.org/html/rfc8949#section-4
4
https://tools.ietf.org/html/rfc8949#section-6
5 https://www.icao.int/publications/Documents/9303_p3_cons_en.pdf

6
Machine Translated by Google

Réseau de cybersanté

Pour fournir ce contexte aux lecteurs optiques, il est attaché au code-barres encodé avant le code QR
Génération:

[version] Encodage Base45

L'encodage de base45 est décrit dans un projet IETF6 .

2.4 Identification de la clé publique utilisée

Lors de l'analyse d'un objet CBOR par un scanner de code, l'algorithme de vérification doit correspondre efficacement au
matériel cryptographique utilisé. À cette fin et en vue des futurs scénarios décentralisés, la clé cryptographique utilisée doit
être identifiable de manière unique par un vérificateur. Ceci est réalisé en insérant le champ "kid" dans l'en-tête COSE.
L'identifiant de clé est défini comme les 8 premiers octets tronqués d'un hachage SHA256. L'allégation «ÿenfantÿ» peut
également être utilisée dans le concept JWK.

2.5 Noms des champs de données

Pour économiser autant d'octets que possible dans le code 2D, chaque nom de champ doit être réduit à des acronymes.
Par exemple, sujet à "sous" ou émetteur à "iss".

Les noms de champs sélectionnés doivent être uniquement sur le contexte sélectionné, sinon les traductions
de noms de champs sont beaucoup plus difficiles à réaliser.

2.6 Contenu COSE / CBOR

2.6.1 Structure des CHOSES

Une structure COSE contient un objet protégé, non protégé et charge utile dans un tableau CBOR défini dans la structure
de base de la RFC81527 .

Nom CBOR Majeur Type 2 2 Taper

protégé 22 bstr
signature bstr
de charge bstr
utile non protégée vide

Tableau 2 : Format THINGS

La charge utile "nil" n'est pas autorisée pour ce code 2D et doit être rejetée. Le choix de placer l'enfant dans l'en-tête protégé
ou non protégé est laissé à l'émetteur, tous les vérificateurs doivent accepter les deux.

2.6.2 En-tête de signature

L'en-tête de COSE contient l'algorithme utilisé et l'identifiant de la cléÿ:

Nom Major CBOR Placement Saisissez la valeur La description

Taper Dans l'en-tête
enfant protégé nint -7/-37 (ES256) Champ d'algorithme
d'algue 14 protégé tableau 8 premiers octets de Identificateur de clé
la valeur de hachage

6 https://datatracker.ietf.org/doc/draft-faltstrom-base45/
7
https://tools.ietf.org/html/rfc8152#section-3.1

7
Machine Translated by Google

Réseau de cybersanté

Tableau 3 : Format d'en-tête

Plus d'informations sur les en-têtes COSE et les valeurs des algorithmes peuvent être trouvées sur la page IANA8 .

2.6.3 Valeurs communes de charge utile

L'ensemble de données commun pour tous les types d'objets CBOR est défini comme le tableau suivantÿ:

Prétendre Nom Major CBOR Taper La description

Clé Taper
2 bstr Émetteur de la DGC
1 manger 2 bstr Date de délivrance de la DGC
6 4 exp -260 2 bstr Date d'expiration de la DGC
hcert 5 carte Charge utile du DGC
(Vac,Tst,Rec)

Tableau 4 : Valeurs communes

La syntaxe est conforme à la CWT RFC83929 et au volume 1 des spécifications techniques du Digital
Green Certificate.

2.6.4 Charge utile

L'allégation «ÿHCERTÿ» est définie comme conteneur pour différents types de certificats (par exemple, vaccins, test
et récupération) par le réseau eHealth10,11 (voir les directives du réseau eHealth sur les spécifications techniques
pour les certificats verts numériques, volumeÿ1).

Le contenu des données suivant le règlement DGC et le schéma de la charge utile pour le code-barres 2D
sont définis dans les directives du réseau eHealth sur les ensembles de valeurs pour les certificats verts
numériques.

2.7 Contenu de données facultatif

Le contenu facultatif des données nationales n'est pas autorisé. 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.

8https://www.iana.org/assignments/cose/cose.xhtml
9https://tools.ietf.org/html/rfc8392
10https://ec.europa.eu/health/sites/health/files/ehealth/docs/vaccination-proof_interoperability
guidelines_en.pdf
11https://ec.europa.eu/health/sites/health/files/ehealth/docs/citizen_recovery-interoperable
certificates_en.pdf

8
Machine Translated by Google

Réseau de cybersanté

3 Sérialisation

Comme modèle de sérialisation, le schéma suivant est utiliséÿ:

Figure 1 : Processus de sérialisation12

Le processus doit toujours commencer par un fichier JSON, par exemple à partir d'un référentiel de données de santé (des
sources de données externes sont facultatives), qui correspond aux schémas DGC définis. Après ce contrôle, une
transformation de la lisibilité humaine peut être traitée avant le démarrage de la sérialisation vers CBOR. Au cours de ce
processus, il peut être décidé si une lisibilité humaine est utile ou non. Les acronymes des revendications doivent être
mappés dans tous les cas aux noms d'affichage avant la sérialisation et après la désérialisation.

Il ne doit pas être envisagé de remplacer le contenu du champ par des informations de métadonnées (par exemple
11 pour une valeur) en octets sécurisés lors de la compression. Il doit toujours y avoir des valeurs clairement
définies.

12
https://github.com/ehn-digital-green-development/hcert-spec

9
Machine Translated by Google

Réseau de cybersanté

4 Feuille de route de mise en œuvre

Caractéristique Version attendue

CBOR / COSE 1.0
Signatures ECDSA 1.0

Encodage de code QR 1.0

Structures de données initiales 1.0
Encodage du code aztèque Versions ultérieures

Encodage de code Datamatrix Versions ultérieures

Tableau 5ÿ: Feuille de route

dix