À l’annexe I de la décision d’exécution (UE) 2021/1073, la section 9 suivante est ajoutée:
«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.»