02021D1073 — NL — 15.09.2022 — 004.001

---

Onderstaande tekst dient louter ter informatie en is juridisch niet bindend. De EU-instellingen zijn niet aansprakelijk voor de inhoud. Alleen de besluiten die zijn gepubliceerd in het Publicatieblad van de Europese Unie (te raadplegen in EUR-Lex) zijn authentiek. Deze officiële versies zijn rechtstreeks toegankelijk via de links in dit document

►B

UITVOERINGSBESLUIT (EU) 2021/1073 VAN DE COMMISSIE van 28 juni 2021 tot vaststelling van technische specificaties en regels voor de uitvoering van het bij Verordening (EU) 2021/953 van het Europees Parlement en de Raad vastgestelde vertrouwenskader voor het digitaal EU-covidcertificaat (Voor de EER relevante tekst) (PB L 230 van 30.6.2021, blz. 32)

Gewijzigd bij:

		Publicatieblad
		nr.	blz.	datum
►M1	UITVOERINGSBESLUIT (EU) 2021/2014 VAN DE COMMISSIE van 17 november 2021	L 410	180	18.11.2021
►M2	UITVOERINGSBESLUIT (EU) 2021/2301 VAN DE COMMISSIE van 21 december 2021	L 458	536	22.12.2021
►M3	UITVOERINGSBESLUIT (EU) 2022/483 VAN DE COMMISSIE van 21 maart 2022	L 98	84	25.3.2022
►M4	UITVOERINGSBESLUIT (EU) 2022/1516 VAN DE COMMISSIE van 8 september 2022	L 235	61	12.9.2022

---

▼B

UITVOERINGSBESLUIT (EU) 2021/1073 VAN DE COMMISSIE

van 28 juni 2021

tot vaststelling van technische specificaties en regels voor de uitvoering van het bij Verordening (EU) 2021/953 van het Europees Parlement en de Raad vastgestelde vertrouwenskader voor het digitaal EU-covidcertificaat

(Voor de EER relevante tekst)

Artikel 1

De technische specificaties voor het digitale EU-covidcertificaat, waarin de algemene datastructuur, de coderingsmechanismen en het transportcoderingsmechanisme in een machineleesbaar optisch formaat worden vastgesteld, zijn opgenomen in bijlage I.

Artikel 2

De regels voor het invullen van de in artikel 3, lid 1, van Verordening (EU) 2021/953 bedoelde certificaten zijn opgenomen in bijlage II bij dit besluit.

Artikel 3

De eisen inzake de gemeenschappelijke structuur van de unieke certificaatidentificatiecode zijn opgenomen in bijlage III.

▼M1

Artikel 4

De governanceregels voor publiekesleutelcertificaten met betrekking tot de gateway voor digitale EU-covidcertificaten ter ondersteuning van de interoperabiliteitsaspecten van het vertrouwenskader, zijn opgenomen in bijlage IV.

▼M1

Artikel 5

Bijlage V bij dit besluit bevat een gemeenschappelijke gecoördineerde gegevensstructuur voor de gegevens die moeten worden opgenomen in de in artikel 3, lid 1, van Verordening (EU) 2021/953 genoemde certificaten, met gebruikmaking van een JSON-schema (JavaScript Object Notation).

▼M3

Artikel 5 bis

Uitwisseling van lijsten van ingetrokken certificaten

Artikel 5 ter

Indiening van lijsten van ingetrokken certificaten door derde landen

Derde landen die COVID-19-certificaten afgeven waarvoor de Commissie krachtens artikel 3, lid 10, of artikel 8, lid 2, van Verordening (EU) 2021/953 een uitvoeringshandeling heeft vastgesteld, kunnen lijsten indienen van ingetrokken COVID-19-certificaten die onder een dergelijke uitvoeringshandeling vallen en die door de Commissie namens de gezamenlijke verwerkingsverantwoordelijken in de in artikel 5 bis bedoelde gateway moeten worden verwerkt, overeenkomstig de technische specificaties in bijlage I.

Artikel 5 quater

Governance van de verwerking van persoonsgegevens in de centrale gateway voor digitale EU-covidcertificaten

▼M1

Artikel 6

Dit besluit treedt in werking op de dag van de bekendmaking ervan in het Publicatieblad van de Europese Unie.

▼B

Dit besluit treedt in werking op de dag van de bekendmaking ervan in het Publicatieblad van de Europese Unie.

---

BIJLAGE I

FORMAAT EN VERTROUWENSBEHEER

Algemene datastructuur, coderingsmechanismen en transportcoderingsmechanisme in een machineleesbaar optisch formaat (hierna “QR” genoemd)

1.    Inleiding

De technische specificaties in deze bijlage omvatten een algemene datastructuur en coderingsmechanismen voor het digitale EU-covidcertificaat (hierna “DCC” genoemd). Zij hebben ook betrekking op een transportcoderingsmechanisme in een machineleesbaar optisch formaat (“QR”), dat op het scherm van een mobiel apparaat kan worden weergegeven of dat kan worden afgedrukt. De containerindelingen van het elektronisch gezondheidscertificaat zijn in deze specificaties generiek, maar worden in dit verband gebruikt om de DCC te dragen.

2.    Terminologie

Voor de toepassing van deze bijlage staat “afgevers” voor organisaties die deze specificaties gebruiken voor de afgifte van gezondheidscertificaten en “verificateurs” voor organisaties die gezondheidscertificaten als bewijs van de gezondheidsstatus aanvaarden. “Deelnemers” zijn afgevers en verificateurs. Sommige aspecten van deze bijlage moeten worden gecoördineerd tussen de deelnemers, zoals het beheer van een naamruimte en de verdeling van cryptografische sleutels. Aangenomen wordt dat een partij, hierna “secretariaat” genoemd, deze taken uitvoert.

3.    Containerindeling van het elektronisch gezondheidscertificaat

De containerindeling van het elektronisch gezondheidscertificaat (Electronic Health Certificate Container Format, hierna “HCERT” genoemd) is ontworpen als een uniform en gestandaardiseerd vehikel voor gezondheidscertificaten van verschillende afgevers (“afgevers”). Het doel van deze specificaties is de wijze waarop deze gezondheidscertificaten worden weergegeven, gecodeerd en ondertekend te harmoniseren en daardoor de interoperabiliteit te bevorderen.

Om een door eender welke afgever afgegeven DCC te kunnen lezen en interpreteren, is er een gemeenschappelijke datastructuur nodig en moet er overeenstemming zijn over de betekenis van elk dataveld van de payload. Met het oog op die interoperabiliteit wordt een gemeenschappelijke gecoördineerde datastructuur gedefinieerd aan de hand van een “JSON”-schema dat het kader van het DCC vormt.

3.1.    Structuur van de payload

De payload is gestructureerd en gecodeerd als een CBOR met een digitale COSE-handtekening. Dit staat algemeen bekend als een “CBOR Web Token” (CWT) en wordt gedefinieerd in RFC 8392 ( 1 ). De payload, zoals gedefinieerd in de volgende onderdelen, wordt getransporteerd in een hcert-claim.

De integriteit en authenticiteit van de herkomst van de payloaddata moeten door de verificateur kunnen worden geverifieerd. Om dit mechanisme mogelijk te maken, moet de afgever het CWT ondertekenen met behulp van een asymmetrische methode voor elektronische handtekeningen zoals gedefinieerd in de COSE-specificering (RFC 8152 ( 2 )).

3.2.    CWT-claims

3.2.1.    Overzicht van de CWT-structuur

Beschermde header

Payload

Handtekening

3.2.2.    Algoritme van de handtekening

De parameter “Algoritme Handtekening” (alg) geeft aan welk algoritme wordt gebruikt voor het aanmaken van de handtekening. Het moet voldoen aan of verder gaan dan de huidige, hieronder samengevatte SOG-IS-richtsnoeren.

Er worden een primair en een secundair algoritme bepaald. Het secundaire algoritme mag alleen worden gebruikt als het primaire algoritme niet aanvaardbaar is binnen de aan de afgever opgelegde regels en voorschriften.

Om de beveiliging van het systeem te waarborgen, moeten alle implementaties het secundaire algoritme omvatten. Om deze reden moeten zowel het primaire als het secundaire algoritme worden toegepast.

De door SOG-IS vastgestelde niveaus voor de primaire en secundaire algoritmen zijn:

Dit komt overeen met COSE-algoritmeparameter ES256.

Dit komt overeen met COSE-algoritmeparameter PS256.

3.2.3.    Sleutelidentificatiecode

De claim “sleutelidentificatiecode” (kid) vermeldt in welk documentondertekenaarscertificaat (“Document Signer Certificate” of “DSC”) de publieke sleutel zit die de verificateur moet gebruiken om de juistheid van de digitale handtekening te controleren. Het beheer van publiekesleutelcertificaten, met inbegrip van eisen inzake DSC’s, wordt beschreven in bijlage IV.

De claim “sleutelidentificatiecode” (kid) wordt door verificateurs gebruikt om de juiste publieke sleutel te selecteren uit een lijst van sleutels met betrekking tot de afgever die wordt vermeld in de claim afgever (iss). Verschillende sleutels kunnen om administratieve redenen en bij het uitvoeren van sleutelrollovers parallel worden gebruikt door een afgever. De sleutelidentificatiecode is geen beveiligingskritiek veld. Om die reden kan het, indien nodig, ook in een onbeschermde header worden geplaatst. Verificateurs moeten beide opties aanvaarden. Indien beide opties voorhanden zijn, moet de sleutelidentificatiecode in de beschermde header worden gebruikt.

Door de verkorting van de identificatiecode (omdat de ruimte beperkt is) is er een kleine maar niet onbestaande kans dat de algemene lijst van DSC’s die door een verificateur worden aanvaard, DSC’s met dubbele kid’s bevat. Daarom moet een verificateur alle DSC’s met die kid controleren.

3.2.4.    Afgever

De claim “afgever” (iss) is een tekenreekswaarde die eventueel de ISO 3166-1 alpha-2-landcode kan bevatten van de entiteit die het gezondheidscertificaat afgeeft. Deze claim kan door een verificateur worden gebruikt om te bepalen welke reeks DSC’s moet worden gebruikt voor verificatie. De claim Key 1 wordt gebruikt om deze claim te identificeren.

3.2.5.    Vervaltijd

De claim “vervaltijd” (exp) bevat een tijdstempel in het NumericDate-formaat in gehele getallen (zoals gespecificeerd in RFC 8392 ( 4 ), deel 2), waarin wordt aangegeven tot wanneer deze specifieke handtekening voor de payload als geldig wordt beschouwd, waarna een verificateur de payload moet afwijzen omdat deze verlopen is. De parameter “vervaltijd” heeft tot doel de geldigheidstermijn van het gezondheidscertificaat te beperken. De claim Key 4 wordt gebruikt om deze claim te identificeren.

De vervaltijd mag niet langer zijn dan de geldigheidstermijn van het DSC.

3.2.6.    Afgegeven op

De claim “afgegeven op” (iat) bevat een tijdstempel in het NumericDate-formaat in gehele getallen (zoals gespecificeerd in RFC 8392 ( 5 ), deel 2), met vermelding van het tijdstip waarop het gezondheidscertificaat is aangemaakt.

De datum in het veld “afgegeven op” mag niet vallen vóór de geldigheidstermijn van het DSC.

Verificateurs kunnen aanvullende beleidslijnen toepassen om de geldigheid van het gezondheidscertificaat te beperken op basis van het tijdstip van afgifte. De claim Key 6 wordt gebruikt om deze claim te identificeren.

3.2.7.    Claim “gezondheidscertificaat”

De claim “gezondheidscertificaat” (hcert) is een JSON-object (RFC 7159 ( 6 )) dat de informatie over de gezondheidsstatus omvat. Er kunnen verschillende soorten gezondheidscertificaten bestaan onder dezelfde claim, waarvan de DCC er één is.

De JSON is uitsluitend bedoeld voor schematische doeleinden. Het weergaveformaat is CBOR, zoals gedefinieerd in (RFC 7049 ( 7 )). Applicatieontwikkelaars mogen in feite nooit het JSON-formaat decoderen of coderen naar en van het JSON-formaat, maar moeten de structuur in het geheugen gebruiken.

De te gebruiken Claim Key voor identificatie van deze claim is -260.

De strings in het JSON-object moeten worden genormaliseerd volgens Normalization Form Canonical Composition (NFC) zoals gedefinieerd in de Unicode-norm. Decodeertoepassingen moeten in deze opzichten echter ruim en robuust zijn, en de aanvaarding van elke redelijke omzetting wordt nadrukkelijk aangemoedigd. Indien tijdens het decoderen, of in latere vergelijkingsfuncties, niet-genormaliseerde data worden gevonden, moeten de implementaties zich gedragen alsof de input genormaliseerd is naar NFC.

4.    Serialisatie en creatie van de DCC-payload

Als serialisatiepatroon wordt het volgende schema gebruikt:

Het proces begint met het extraheren van data, bijvoorbeeld uit een opslagplaats voor gezondheidsdata (of een externe gegevensbron), waarbij de geëxtraheerde data worden gestructureerd volgens de gedefinieerde DCC-schema’s. In dit proces kunnen de omzetting naar het gedefinieerde dataformaat en de transformatie met het oog op menselijke leesbaarheid plaatsvinden voordat de serialisatie naar CBOR begint. De acroniemen van de claims worden in elk geval vóór serialisatie en na deserialisatie toegewezen aan de weergavenamen.

Facultatieve nationale data-inhoud is niet toegestaan in certificaten die zijn afgegeven op grond van Verordening (EU) 2021/953 ( 8 ). De data-inhoud is beperkt tot de gedefinieerde data-elementen in de minimale dataset zoals gespecificeerd in de bijlage bij Verordening (EU) 2021/953.

5.    Transportcodering

5.1.    Raw

Voor arbitraire data-interfaces mogen de HCERT-container en de payloads ervan ongewijzigd worden overgedragen, met gebruikmaking van elk mogelijk onderliggend, veilig en betrouwbaar 8-bit-datatransport. Deze interfaces kunnen NFC (Near Field Communication), bluetooth of overdracht via een toepassingslaagprotocol omvatten, bijvoorbeeld de overdracht van een HCERT van de afgever naar het mobiele apparaat van de houder.

Als de overdracht van de HCERT van de afgever naar de houder gebaseerd is op een interface voor uitsluitend weergave (bijvoorbeeld sms, e-mail), is de transportcodering Raw uiteraard niet van toepassing.

5.2.    Barcode

5.2.1.    Compressie van de payload (CWT)

Om de grootte te verminderen en de snelheid en betrouwbaarheid van het leesproces van de HCERT te verbeteren, wordt de CWT gecomprimeerd met behulp van ZLIB (RFC 1950 ( 9 )) en het Deflate-compressiemechanisme in het formaat zoals gedefinieerd in RFC 1951 ( 10 ).

5.2.2.    QR-2D-barcode

Om ervoor te zorgen dat beter kan worden gewerkt met oude apparatuur die is ontworpen voor ASCII-payloads, wordt de gecomprimeerde CWT gecodeerd als ASCII met gebruikmaking van Base45 alvorens te worden gecodeerd in een 2D-barcode.

Voor het genereren van de 2D-barcode wordt het QR-formaat gebruikt zoals gedefinieerd in (ISO/IEC 18004:2015). Een foutcorrectiepercentage van “Q” (ongeveer 25 %) wordt aanbevolen. Omdat gebruik wordt gemaakt van Base45, moet voor de QR-code alfanumerieke codering worden gebruikt (modus 2, aangegeven door de symbolen 0010).

Om verificateurs in staat te stellen het soort gecodeerde data te detecteren en het juiste decoderings- en verwerkingsschema te kiezen, moeten de met Base45 gecodeerde data (volgens deze specificatie) worden voorafgegaan door de Context-Identifier-string “HC1:”. Bij toekomstige versies van deze specificatie die gevolgen hebben voor de compatibiliteit met oudere systemen, moet een nieuwe context-ID worden gedefinieerd, waarbij “HC” moet worden gevolgd door een teken uit de tekenset [1-9A-Z]. Deze tekens moeten in die volgorde worden bepaald, d.w.z. eerst [1-9] en vervolgens [A-Z].

Er wordt aanbevolen de optische code op het presentatiemedium weer te geven met een diagonaal tussen 35 mm en 60 mm, om het gebruik ervan te vergemakkelijken met lezers met vaste optische onderdelen indien het presentatiemedium op het oppervlak van de lezer moet worden geplaatst.

Indien de optische code op papier wordt gedrukt met behulp van printers met lage resolutie (< 300 dpi), moet erop worden gelet dat elk symbool (punt) van de QR-code precies vierkant worden weergegeven. Niet-proportionele schaalverkleining zal in sommige rijen of kolommen van de QR-code tot rechthoekige symbolen leiden, wat de leesbaarheid in veel gevallen zal bemoeilijken.

6.    Formaat van vertrouwenslijsten (CSCA- en DSC-lijst)

Elke lidstaat moet een lijst van een of meer Country Signing Certificate Authorities (CSCA’s) en een lijst van alle geldige Document Signer Certificates (DSC’s) verstrekken en deze lijsten actueel houden.

6.1.    Vereenvoudigde CSCA/DSC

Vanaf deze versie van de specificaties gaan de lidstaten er niet vanuit dat informatie uit de lijst van ingetrokken certificaten (Certificate Revocation List — CRL) is gebruikt of dat de gebruiksperiode van de persoonlijke sleutel door de uitvoerders is gecontroleerd.

Het primaire geldigheidsmechanisme is daarentegen de aanwezigheid van het certificaat op de meest recente versie van die certificaatlijst.

6.2.    eMRTD-PKI van de ICAO en trustcentra

De lidstaten kunnen een afzonderlijke CSCA gebruiken, maar kunnen ook hun bestaande CSCA-certificaten en/of DSC’s voor eMRTD indienen, en kunnen er zelfs voor kiezen deze in te kopen bij (commerciële) trustcentra en die vervolgens in te dienen. Een DSC moet echter altijd worden ondertekend door de CSCA die door die lidstaat is aangewezen.

7.    Beveiligingsoverwegingen

Bij het ontwerpen van een regeling aan de hand van deze specificatie bepalen, analyseren en monitoren de lidstaten bepaalde beveiligingsaspecten.

Ten minste met de volgende aspecten moet rekening worden gehouden:

7.1.    Geldigheidstermijn HCERT-handtekening

De uitgever van HCERT’s moet de geldigheidsduur van de handtekening beperken door een termijn voor het verstrijken van de handtekening te specificeren. Dit houdt in dat de houder van een gezondheidscertificaat het periodiek moet vernieuwen.

De aanvaardbare geldigheidsduur kan worden bepaald op basis van praktische beperkingen. Een reiziger heeft bijvoorbeeld niet de mogelijkheid om het gezondheidscertificaat tijdens een buitenlandse reis te verlengen. Het is echter ook mogelijk dat een afgever het mogelijk acht dat de beveiliging op een of andere manier is gecompromitteerd, waardoor de afgever een DSC moet intrekken (waardoor alle gezondheidscertificaten die zijn afgegeven met gebruikmaking van de sleutel die nog binnen de geldigheidsperiode valt, ongeldig worden verklaard). De gevolgen van een dergelijke gebeurtenis kunnen worden beperkt door de sleutels van de afgever regelmatig te vernieuwen en met redelijke intervallen de vernieuwing van alle gezondheidscertificaten te eisen.

7.2.    Sleutelbeheer

Deze specificatie is sterk afhankelijk van sterke cryptografische mechanismen om de integriteit van data en de authenticatie van de oorsprong van de data te beveiligen. Daarom is het noodzakelijk de vertrouwelijkheid van de persoonlijke sleutels te waarborgen.

De vertrouwelijkheid van cryptografische sleutels kan op verschillende manieren in het gedrang komen. Enkele voorbeelden:

Om het risico op een zwak ondertekeningsalgoritme te beperken, waardoor de persoonlijke sleutels kunnen worden gecompromitteerd door cryptoanalyse, wordt met deze specificatie aanbevolen dat alle deelnemers voor noodgevallen een secundair ondertekeningsalgoritme toepassen op basis van andere parameters of een ander wiskundig probleem dan het primaire.

Wat de vermelde risico’s in verband met de besturingsomgevingen van de afgevers betreft, moeten risicobeperkende maatregelen worden genomen om een doeltreffende controle te waarborgen, zodat de persoonlijke sleutels worden gegenereerd, opgeslagen en gebruikt in HSM’s (Hardware Security Modules). Het gebruik van HSM’s voor het ondertekenen van gezondheidscertificaten wordt nadrukkelijk aangemoedigd.

Ongeacht of een afgever besluit HSM’s te gebruiken of niet, moet een schema voor sleutelrollovers worden vastgesteld waarbij de frequentie van de sleutelrollovers in verhouding staat tot de blootstelling van de sleutels aan externe netwerken, andere systemen en personeel. Een goed gekozen rolloverschema beperkt ook de risico’s in verband met ten onrechte afgegeven gezondheidscertificaten, waardoor een afgever dergelijke gezondheidscertificaten in batches kan intrekken door zo nodig een sleutel in te trekken.

7.3.    Validatie van inputdata

Deze specificaties kunnen worden gebruikt op een manier die inhoudt dat data van onbetrouwbare bronnen worden ontvangen in systemen die van missiekritische aard kunnen zijn. Om de risico’s in verband met deze aanvalsvector tot een minimum te beperken, moeten alle inputvelden naar behoren worden gevalideerd op basis van datatypes, -lengtes en -inhoud. De handtekening van de afgever wordt ook geverifieerd voordat de inhoud van het HCERT wordt verwerkt. De validatie van de handtekening van de afgever houdt echter in dat eerst de beschermde header van de afgever wordt geparseerd, waarbij een potentiële aanvaller kan proberen zorgvuldig gefabriceerde informatie in te voeren die bedoeld is om de beveiliging van het systeem in gevaar te brengen.

8.    Vertrouwensbeheer

Om de HCERT-handtekening te verifiëren, is een publieke sleutel nodig. De lidstaten maken deze publieke sleutels bekend. Uiteindelijk moet elke verificateur beschikken over een lijst van alle publieke sleutels die hij bereid is te vertrouwen (aangezien de publieke sleutel geen deel uitmaakt van het HCERT).

Het systeem bestaat uit (slechts) twee lagen; voor elke lidstaat een of meer landencertificaten waarmee telkens een of meer DSC’s worden ondertekend die dagelijks worden gebruikt.

De certificaten van de lidstaten worden CSCA’s genoemd (Country Signing Certificate Authority) en zijn (doorgaans) zelfondertekend. De lidstaten kunnen er meer dan één hebben (bijvoorbeeld in het geval van regionale decentralisatie). Deze CSCA-certificaten ondertekenen regelmatig de DSC’s (Document Signer Certificates) die worden gebruikt voor het ondertekenen van HCERT’s.

Het “secretariaat” is een functionele rol. Het verzamelt en publiceert de DSC’s van de lidstaten op regelmatige tijdstippen, nadat het deze heeft geverifieerd aan de hand van de lijst van CSCA-certificaten (die met andere middelen zijn overgedragen en geverifieerd).

De daaruit voortvloeiende lijst van DSC’s bevat dan de geaggregeerde reeks aanvaardbare publieke sleutels (en de bijbehorende sleutelidentificatiecodes) die verificateurs kunnen gebruiken om de handtekeningen via de HCERT’s te valideren. Verificateurs moeten deze lijst regelmatig ophalen en actualiseren.

Dergelijke lidstaatspecifieke lijsten kunnen worden omgezet in het door de lidstaat vastgestelde formaat. Het bestandsformaat van deze vertrouwenslijst kan dus variëren: het kan een ondertekend JWKS zijn (JWK-setindeling volgens RFC 7517 ( 11 ), deel 5) of een ander formaat dat specifiek is voor de in die lidstaat gebruikte technologie.

Ter wille van de eenvoud kunnen de lidstaten zowel hun bestaande CSCA-certificaten van hun eMRTD-systemen van de ICAO indienen of, zoals aanbevolen door de WHO, een specifiek certificaat voor dit gezondheidsgebied creëren.

8.1.    De sleutelidentificatiecode

De sleutelidentificatiecode (“key identifier” of “kid”) wordt berekend bij het samenstellen van de lijst van betrouwbare publieke sleutels van DSC’s en bestaat uit een afgekapte (eerste 8 bytes) SHA-256-vingerafdruk van het DSC die is gecodeerd in het DER-formaat (raw).

Verificateurs hoeven de sleutelidentificatiecode niet te berekenen op basis van het DSC en kunnen de sleutelidentificatiecode in het afgegeven gezondheidscertificaat direct matchen met de sleutelidentificatiecode op de vertrouwenslijst.

8.2.    Verschillen met het eMRTD-PKI-vertrouwensmodel van de ICAO

Hoewel er wordt voortgebouwd op beste praktijken van het eMRTD-PKI-vertrouwensmodel van de ICAO, wordt in het belang van de snelheid een aantal vereenvoudigingen aangebracht:

▼M3

9.    Intrekkingsoplossing

9.1.    DCC-intrekkingslijst (DRL)-provision

De gateway biedt eindpunten (“endpoints”) en functies voor het bijhouden en beheren van de intrekkingslijsten:

9.2.    Vertrouwensmodel

Alle verbindingen komen tot stand via het standaard DCCG-vertrouwensmodel door de NBTLS- en NBUP-certificaten (zie certificaatgovernance). Alle informatie wordt verpakt en geüpload door CMS-berichten om de integriteit te waarborgen.

9.3.    Batch-samenstelling

9.3.1.    Batch

Intrekkingslijsten bevatten één of meer vermeldingen en worden verpakt in batches die een reeks hashes en metadata bevatten. Een batch is onveranderlijk (“immutable”) en bevat een vervaldatum die aangeeft wanneer de batch kan worden gedeletet. De vervaldatum van alle items in de batch moet exact dezelfde zijn, wat betekent dat de batches moeten worden gegroepeerd per vervaldatum en per ondertekenende DSC (documentondertekenaarscertificaat). Batches bevatten maximaal 1 000 vermeldingen. Als een intrekkingslijst uit meer dan 1 000 vermeldingen bestaat, worden meer batches gemaakt. Een entry mag op hoogstens één batch voorkomen. De batch wordt verpakt in een CMS-structuur en door het NBup-certificaat van het uploadende land ondertekend.

9.3.2.    Batchindex

Als een batch is aangemaakt, wordt door de gateway een unieke ID toegewezen en wordt die automatisch aan de index toegevoegd. De batchindex wordt gerangschikt op datum van wijziging, in oplopende chronologische volgorde.

9.3.3.    Gateway

De gateway verwerkt intrekkingsbatches ongewijzigd: bijwerkingen of schrappingen zijn niet mogelijk, noch kan informatie aan de batches worden toegevoegd. De batches worden doorgezonden naar alle bevoegde landen (zie hoofdstuk 9.6).

De gateway monitort de vervaldata van de batches en deletet de vervallen batches. Nadat de batch is gedeletet, meldt de gateway een “HTTP 410 Gone” voor de gedeletete batch URL. De batch verschijnt derhalve in de batchindex als “deleted”.

9.4.    Hash types

De intrekkingslijst bevat hashes die verschillende soorten/attributen van intrekkingen kunnen betekenen. Deze soorten of attributen worden aangegeven bij de opstelling van de intrekkingslijsten. De huidige soorten zijn:

Alleen de eerste 128 bits van de hashes die als base64 strings zijn gecodeerd, komen in de batches terecht en worden gebruikt om het ingetrokken DCC te identificeren ( 12 ).

9.4.1.    Hash type: SHA256(DCC-ondertekening)

In dit geval wordt de hash berekend aan de hand van de bytes van de COSE_SIGN1-handtekening van de CWT. De formule voor de door de EC-DSA ondertekende certificaten gebruikt de r-waarde als input:

SHA256(r)

[vereist voor alle nieuwe implementaties]

9.4.2.    Hash type: SHA256(UCI)

In dit geval wordt de hash berekend aan de hand van de bytes van de UCI string die in UTF-8 is gecodeerd en geconverteerd naar een byte array.

[verouderd ( 13 ), maar ondersteund voor backwards compatibility]

9.4.3.    Hash type: SHA256(Issuing CountryCode+UCI)

In dit geval wordt de CountryCode gecodeerd als UTF-8 string die met de met een UTF-8 string gecodeerde UCI is samengevoegd. Dit wordt dan geconverteerd naar een byte array en gebruikt als input voor de hashfunctie.

[verouderd2, maar ondersteund voor backwards compatibility]

9.5.    API-structuur

9.5.1.    Provisioning API voor intrekkingsvermeldingen

9.5.1.1.   Doel

De API levert de intrekkingslijsten in batches inclusief een batchindex.

9.5.1.2.   Eindpunten

9.5.1.2.1.   Batch List Download Endpoint

De eindpunten volgen een eenvoudig ontwerp, en melden een lijst van batches met een kleine wrapper met metadata. De batches worden gerangschikt op datum in oplopende (chronologische) volgorde.

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

NB: De resultaten worden standaard beperkt tot 1 000 . Als de flag “more” op “true” staat, betekent dat dat er meer batches kunnen worden gedownload. Om meer items te downloaden, moet de client de If-Modified-Since header zetten op een datum die niet eerder valt dan de laatst ontvangen vermelding.

Het antwoord bevat een JSON array met de volgende structuur:

9.5.1.2.1.1.   Response Codes

Request Header

9.5.1.2.2.   Batch Download Endpoint

De batches bevatten een lijst van certificate identifiers:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

Het antwoord bevat een CMS met een handtekening die moet overeenkomen met het NBUP -certificaat van het land. Alle items in de JSON array hebben de volgende structuur:

9.5.1.2.2.1.   Entries

NB: Het entries object bevat momenteel alleen een hash, maar om compatibel te zijn met toekomstige wijzigingen is gekozen voor een object in plaats van een json array.

9.5.1.2.2.2.   Response Codes

9.5.1.2.2.3.   Response Headers

9.5.1.2.3.   Batch Upload Endpoint

De upload geschiedt langs hetzelfde eindpunt via POST Verb:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

De batch wordt ondertekend met het NBUP -certificaat. De gateway controleert of de handtekening door de NBUP is geplaatst voor het betrokken land. Als de handtekeningcontrole mislukt, dan gaat de upload niet door.

NB: Iedere batch is immutable en kan na de upload niet worden gewijzigd. Hij kan wel worden gedeletet. De ID van iedere gedeletete batch wordt opgeslagen, en een upload van een nieuwe batch met dezelfde ID wordt geweigerd.

9.5.1.2.4.   Batch Delete Endpoint

Een batch kan worden gedeletet langs hetzelfde eindpunt via DELETE Verb:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

of, omwille van de compabiliteit, naar het volgende eindpoint met de POST verb:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

9.6.    API Protection/AVG

Deze afdeling beschrijft implementatiemaatregelen om te voldoen aan Verordening (EU) 2021/953 inzake de verwerking van persoonsgegevens.

9.6.1.    Bestaande authenticatie

De gateway gebruikt momenteel het NBTLS -certificaat om de landen te authenticeren die met de gateway verbinden. Deze authenticatie kan worden gebruikt om de identiteit vast te stellen van het land dat met de gateway verbonden is. Die identiteit kan dan worden gebruikt om toegangscontrole te implementeren.

9.6.2.    Toegangscontrole

Om persoonsgegevens rechtmatig te kunnen verwerken, implementeert de gateway een mechanisme voor toegangscontrole.

De gateway implementeert een Access Control List in combinatie met Role Based Security. In dit kader worden twee tabellen bijgehouden: één tabel waarin wordt beschreven welke rollen welke operations op welke resources kunnen toepassen, en de andere waarin wordt beschreven welke rollen aan welke gebruikers (Users) worden toegewezen.

Drie rollen zijn vereist om de op grond van dit document vereiste controles te implementeren:

De volgende eindpunten controleren of de gebruiker de rol RevocationListReader heeft; zo ja, dan wordt toegang verleend, anders volgt een HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

De volgende eindpunten controleren of de gebruiker de rol RevocationUploader heeft; zo ja, dan wordt toegang verleend, anders volgt een HTTP 403 Forbidden:

POST/revocation-list

De volgende eindpunten controleren of de gebruiker de rol RevocationDeleter heeft; zo ja, dan wordt toegang verleend, anders volgt een HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

De gateway biedt ook een betrouwbare methode waarmee de beheerders de rollen die aan de gebruikers zijn gekoppeld, zodanig kunnen beheren dat de kans op menselijke fouten wordt beperkt zonder dat de functionele beheerders worden belast.

▼M1

---

BIJLAGE II

REGELS VOOR HET INVULLEN VAN HET DIGITALE EU-COVIDCERTIFICAAT

De algemene regels betreffende de in deze bijlage vastgestelde waardereeksen zijn bedoeld om interoperabiliteit op semantisch niveau te waarborgen en maken uniforme technische implementaties voor het digitale EU-covidcertificaat mogelijk. De elementen in deze bijlage mogen worden gebruikt voor de drie verschillende certificaten (vaccinatie/test/herstel), zoals bepaald in Verordening (EU) 2021/953. In deze bijlage worden alleen elementen vermeld waarvoor semantische standaardisering door middel van gecodeerde waardereeksen noodzakelijk is.

Voor de vertaling van de gecodeerde elementen in de nationale taal zijn de lidstaten verantwoordelijk.

Voor alle datavelden die niet in de volgende omschrijvingen van waardereeksen worden vermeld, wordt de codering omschreven in bijlage V.

Indien om welke reden dan ook de hieronder vermelde voorkeurscodesystemen niet kunnen worden gebruikt, mogen andere internationale codesystemen worden gebruikt en wordt advies gegeven over de wijze waarop de codes van het andere codesysteem aan het voorkeurscodesysteem kunnen worden gekoppeld. In uitzonderlijke gevallen mag als back-upmechanisme tekst (weergavenamen) worden gebruikt wanneer in de gedefinieerde waardereeksen geen geschikte code beschikbaar is.

Lidstaten die andere coderingen in hun systemen gebruiken, koppelen deze codes aan de beschreven waardereeksen. De lidstaten zijn verantwoordelijk voor dergelijke koppelingen.

►M4  Aangezien sommige waardereeksen op basis van de in deze bijlage opgenomen coderingssystemen, zoals die voor de codering van vaccins en antigeentests, vaak veranderen, worden deze bekendgemaakt en regelmatig bijgewerkt door de Commissie met steun van het e-gezondheidsnetwerk en het Gezondheidsbeveiligingscomité. ◄ De bijgewerkte waardereeksen worden gepubliceerd op de desbetreffende website van de Commissie en op de webpagina van het e-gezondheidsnetwerk. Er wordt een overzicht van de wijzigingen gegeven.

1.    Doelziekte of -ziekteverwekker/ziekte of ziekteverwekker waarvan de houder is hersteld: COVID-19 (SARS-CoV-2 of een van de varianten daarvan)

Te gebruiken in de certificaten 1, 2 en 3.

Er wordt gebruikgemaakt van de volgende code:

2.    COVID-19-vaccin of -profylaxe

Voorkeurscodesysteem: SNOMED CT- of ATC-classificatie.

Te gebruiken in certificaat 1.

Voorbeelden van codes die worden gebruikt uit de voorkeurscodesystemen zijn SNOMED CT-code 1119305005 (SARS-CoV-2-antigeenvaccin), 1119349007 (SARS-CoV-2-mRNA-vaccin) of J07BX03 (COVID-19-vaccins).

Een waardereeks met de codes die overeenkomstig de in dit deel vastgestelde codesystemen moeten worden gebruikt, wordt bekendgemaakt en regelmatig bijgewerkt door de Commissie met steun van het e-gezondheidsnetwerk. De waardereeks wordt uitgebreid wanneer nieuwe vaccintypen ontwikkeld en in gebruik worden genomen.

3.    COVID-19-vaccin

Voorkeurscodesystemen (in volgorde van voorkeur):

Naam van de waardereeks: vaccin.

Te gebruiken in certificaat 1.

Een voorbeeld van een code uit de voorkeurscodesystemen die wordt gebruikt is EU/1/20/1528 (Comirnaty). Een voorbeeld van de naam van het vaccin die als code moet worden gebruikt: Sputnik-V (staat voor Sputnik V).

Een waardereeks met de codes die overeenkomstig de in dit deel vastgestelde codesystemen moeten worden gebruikt, wordt bekendgemaakt en regelmatig bijgewerkt door de Commissie met steun van het e-gezondheidsnetwerk.

Vaccins worden gecodeerd met behulp van een bestaande code in de bekendgemaakte waardereeks, ook al lopen de namen ervan in verschillende landen uiteen. De reden hiervoor is dat er nog geen wereldwijd vaccinregister bestaat voor alle vaccins die momenteel worden gebruikt. Voorbeeld:

Indien dit in een specifiek geval niet mogelijk of raadzaam is, wordt in de gepubliceerde waardereeks een aparte code vermeld.

▼M4

Als een land dat gebruikmaakt van een digitaal EU-covidcertificaat (EU-DCC) besluit vaccinatiecertificaten af te geven aan deelnemers aan klinische proeven tijdens lopende klinische proeven, wordt het vaccingeneesmiddel gecodeerd volgens het patroon:

CT_clinical-trial-identifier

Wanneer de klinische proef is geregistreerd in het EU-register van klinische proeven (EUCTR), wordt het identificatienummer van de klinische proef uit dit register gebruikt. In andere gevallen mogen identificatienummers uit andere registers (zoals clinicaltrials.gov of Australian New Zealand Clinical Trials Registry) worden gebruikt.

Het identificatienummer van de klinische proef bevat een voorvoegsel waarmee het register van klinische proeven kan worden geïdentificeerd (zoals EUCTR voor het EU-register van klinische proeven, NCT voor clinicaltrials.gov, ACTRN voor het Australische/Nieuw-Zeelandse register van klinische proeven).

Wanneer de Commissie advies heeft ontvangen van het Gezondheidsbeveiligingscomité, het Europees Centrum voor ziektepreventie en -bestrijding (ECDC) of het Europees Geneesmiddelenbureau (EMA) wat betreft de aanvaarding van COVID-19-vaccins die klinisch worden getest, wordt dit advies gepubliceerd, hetzij als onderdeel van het document met de waardebepaling, hetzij afzonderlijk.

▼M1

4.    Handelsvergunninghouder of producent van het COVID-19-vaccin

Voorkeurscodesysteem:

Te gebruiken in certificaat 1.

Een voorbeeld van een code uit het voorkeurscodesysteem die wordt gebruikt is ORG-100001699 (AstraZeneca AB). Een voorbeeld van de naam van de organisatie die als code moet worden gebruikt: Sinovac-Biotech (staat voor Sinovac Biotech).

Een waardereeks met de codes die overeenkomstig de in dit deel vastgestelde codesystemen moeten worden gebruikt, wordt bekendgemaakt en regelmatig bijgewerkt door de Commissie met steun van het e-gezondheidsnetwerk.

Verschillende afdelingen van dezelfde handelsvergunninghouder of dezelfde producent gebruiken een bestaande code in de gepubliceerde waardereeks.

Als algemene regel geldt dat voor hetzelfde vaccinproduct de code wordt gebruikt die verwijst naar de handelsvergunninghouder in de EU, aangezien er nog geen internationaal overeengekomen register voor vaccinproducenten of handelsvergunninghouders bestaat. Voorbeelden:

Indien dit in een specifiek geval niet mogelijk of raadzaam is, wordt in de gepubliceerde waardereeks een aparte code vermeld.

▼M4

Indien een land dat gebruikmaakt van het EU-DCC, besluit vaccinatiecertificaten af te geven aan deelnemers aan klinische proeven tijdens lopende klinische proeven, wordt de houder of fabrikant van de vergunning voor het in de handel brengen van het vaccin gecodeerd aan de hand van de waarde die hem is toegekend in de waardebepaling, indien beschikbaar. In andere gevallen wordt de houder of fabrikant van de vergunning voor het in de handel brengen van het vaccin gecodeerd volgens de regel als beschreven in deel 3 COVID-19-vaccin (CT_clinical-trial-identifier).

▼M1

5.    Volgnummer in een reeks doses alsook totale aantal doses in de reeks

Te gebruiken in certificaat 1.

Twee velden:

5.1.    Primaire-vaccinatiereeks

Wanneer de persoon doses van de primaire-vaccinatiereeks krijgt, dat wil zeggen de vaccinatiereeks die bedoeld is om in een eerste fase voldoende bescherming te bieden, staat (C) voor het totale aantal doses van de standaard primaire-vaccinatiereeks (bv. 1 of 2, afhankelijk van het toegediende type vaccin). Het is mogelijk om een kortere reeks (C=1) te gebruiken wanneer het door een lidstaat toegepaste vaccinatieprotocol voorziet in de toediening van één dosis van een in twee doses toe te dienen vaccin aan personen die reeds met SARS-CoV-2 besmet zijn geweest. Een voltooide primaire-vaccinatiereeks wordt dientengevolge aangegeven met N/C = 1. Bijvoorbeeld:

Wanneer de primaire-vaccinatiereeks wordt uitgebreid, bijvoorbeeld voor personen met een ernstig verzwakt immuunsysteem of wanneer het aanbevolen interval tussen de primaire doses niet in acht is genomen, worden dergelijke doses gecodeerd als aanvullende doses die onder rubriek 5.2 vallen.

▼M2

5.2.    Boosterdoses

Wanneer een persoon na de primaire vaccinatiereeks nog doses toegediend krijgt, worden die boosterdoses als volgt weergegeven in de desbetreffende certificaten:

De lidstaten passen de in dit punt vastgestelde coderingsregels uiterlijk op 1 februari 2022 toe.

Certificaten waarin de toediening van een boosterdosis na een primaire vaccinatiecyclus bestaande uit één dosis van een in één dosis toe te dienen vaccin zodanig is gecodeerd dat deze niet kan worden onderscheiden van de voltooiing van de primaire vaccinatiereeks, moeten door de lidstaten automatisch of op verzoek van de betrokkenen opnieuw worden afgegeven.

Voor de toepassing van deze bijlage worden aanvullende doses die worden toegediend voor een betere bescherming van personen van wie de immuunrespons na voltooiing van de standaard primaire vaccinatiereeks ontoereikend is, ook als “boosterdoses” beschouwd. Binnen het bij Verordening (EU) 2021/953 vastgestelde rechtskader kunnen de lidstaten maatregelen nemen om rekening te houden met de situatie van kwetsbare groepen die voorrang kunnen krijgen bij het toedienen van extra doses. Lidstaten die bijvoorbeeld besluiten alleen aanvullende doses toe te dienen aan specifieke subgroepen van de bevolking, kunnen overeenkomstig artikel 5, lid 1, van Verordening (EU) 2021/953 ervoor kiezen om alleen op verzoek en niet automatisch vaccinatiecertificaten af te geven waarin de toediening van dergelijke aanvullende doses wordt vermeld. Wanneer dergelijke maatregelen worden genomen, stellen de lidstaten de betrokkenen daarvan in kennis en delen zij tevens aan de betrokkenen mee dat ze gebruik kunnen blijven maken van het certificaat dat ze na voltooiing van de standaard primaire vaccinatiereeks hebben ontvangen.

▼M1

6.    Lidstaat of derde land waar het vaccin werd toegediend/waar de test werd uitgevoerd

Voorkeurscodesysteem: ISO 3166-landcodes.

Te gebruiken in de certificaten 1, 2 en 3.

Inhoud van de waardereeks: de volledige lijst van tweelettercodes, beschikbaar als een in FHIR gedefinieerde waardereeks (http://hl7.org/fhir/ValueSet/iso3166-1-2). Indien de vaccinatie of de test is uitgevoerd door een internationale organisatie (zoals UNHCR of WHO) en er geen informatie over het land beschikbaar is, wordt er een code voor de organisatie gebruikt. Deze aanvullende codes worden gepubliceerd en regelmatig bijgewerkt door de Commissie met steun van het e-gezondheidsnetwerk.

7.    Type test

Te gebruiken in certificaten 2 en 3 indien ondersteuning voor de afgifte van herstelcertificaten op basis van andere soorten tests dan NAAT wordt ingevoerd bij een gedelegeerde handeling.

De volgende codes worden gebruikt:

▼M4

De code LP217198-3 (immunoassay-sneltest) wordt gebruikt om zowel snelle antigeentests als in een laboratoriumomgeving uitgevoerde antigeentests aan te geven.

▼M1

8.    Fabrikant en handelsnaam van de gebruikte test (facultatief voor NAAT-test)

Te gebruiken in certificaat 2.

▼M4

De inhoud van de waardereeks omvat de selectie van antigeentests zoals opgenomen in de gemeenschappelijke en geactualiseerde lijst van antigeentests voor COVID-19, vastgesteld op basis van Aanbeveling 2021/C 24/01 van de Raad en goedgekeurd door het Gezondheidsbeveiligingscomité. De lijst wordt door het JRC bijgehouden in de database van middelen voor in-vitrodiagnostiek en testmethoden voor COVID-19 op: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

▼M1

Voor dit codesysteem worden relevante velden, zoals de identificatiecode van het testapparaat, de naam van de test en de fabrikant gebruikt volgens het gestructureerde formaat van het JRC dat beschikbaar is op https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9.    Testresultaat

Te gebruiken in certificaat 2.

Er wordt gebruikgemaakt van de volgende codes:

▼B

---

BIJLAGE III

GEMEENSCHAPPELIJKE STRUCTUUR VAN DE UNIEKE CERTIFICAATIDENTIFICATIECODE

1.    Inleiding

Elk digitaal EU-covidcertificaat (DCC) bevat een unieke certificeringsidentificatiecode (UCI) ter ondersteuning van de interoperabiliteit van de DCC’s. De UCI kan worden gebruikt om het certificaat te verifiëren. De lidstaten zijn verantwoordelijk voor de implementatie van de UCI. De UCI is een middel om de waarheidsgetrouwheid van het certificaat te verifiëren en, indien van toepassing, te koppelen aan een registratiesysteem (bijvoorbeeld een IIS). Op basis van deze identificatiecodes moeten de lidstaten ook (op papier en digitaal) kunnen vaststellen dat personen gevaccineerd of getest zijn.

2.    Samenstelling van de unieke certificaatidentificatiecode

De UCI volgt een gemeenschappelijke structuur en een gemeenschappelijk formaat die de menselijke en/of machinale interpretatie van informatie vergemakkelijken en kan betrekking hebben op elementen zoals de lidstaat van vaccinatie, het vaccin zelf en een lidstaatspecifieke identificatiecode. De UCI biedt de lidstaten flexibiliteit bij het opstellen ervan, met volledige inachtneming van de wetgeving inzake gegevensbescherming. De volgorde van de afzonderlijke elementen volgt een vastgestelde hiërarchie die toekomstige wijzigingen van de blokken mogelijk maakt met behoud van de structurele integriteit ervan.

De mogelijke oplossingen voor de samenstelling van de UCI vormen een spectrum waarin de twee belangrijkste onderscheidende parameters de moduleerbaarheid en de menselijke interpreteerbaarheid zijn en er één fundamenteel kenmerk is:

▼M1

3.    Algemene eisen

Met betrekking tot de UCI wordt aan de volgende overkoepelende eisen voldaan:

Er wordt gezorgd voor compatibiliteit met oudere systemen: lidstaten die na verloop van tijd de structuur van hun identificatiecodes wijzigen (in de hoofdversie, momenteel vastgesteld op v1), zorgen ervoor dat twee identieke identificatiecodes voor hetzelfde vaccinatiecertificaat/dezelfde verklaring staan. Of, met andere woorden, de lidstaten kunnen identificatiecodes niet hergebruiken.

▼B

4.    Opties voor unieke identificatiecodes voor vaccinatiecertificaten

De richtsnoeren van het e-gezondheidsnetwerk inzake verifieerbare vaccinatiecertificaten en basisinteroperabiliteitselementen ( 17 ) biedt de lidstaten en andere partijen verschillende opties die mogelijk naast elkaar kunnen bestaan. De lidstaten kunnen dergelijke verschillende opties gebruiken in verschillende versies van het UCI-schema.

---

BIJLAGE IV

BEHEER VAN PUBLIEKESLEUTELCERTIFICATEN

1.    Inleiding

De beveiligde en betrouwbare uitwisseling van handtekeningsleutels voor digitale EU-covidcertificaten (DCC’s) tussen de lidstaten gebeurt via de gateway voor digitale EU-covidcertificaten (DCCG), die fungeert als centraal register voor de publieke sleutels. Met de DCCG kunnen de lidstaten de publieke sleutels publiceren die overeenkomen met de persoonlijke sleutels die zij gebruiken om digitale EU-covidcertificaten te ondertekenen. De lidstaten kunnen de DCCG gebruiken om tijdig actueel publiekesleutelmateriaal op te halen. Later kan de DCCG worden uitgebreid om betrouwbare aanvullende informatie uit te wisselen die de lidstaten verstrekken, zoals validatieregels voor DCC’s. Het vertrouwensmodel van het DCC-kader is een publiekesleutelinfrastructuur (Public Key Infrastructure, PKI). Elke lidstaat heeft een of meer Country Signing Certificate Authorities (CSCA’s), waarvan de certificaten relatief lang blijven bestaan. De lidstaten kunnen beslissen of de CSCA gelijk is aan of verschillend is van de CSCA die voor machineleesbare reisdocumenten wordt gebruikt. De CSCA geeft publiekesleutelcertificaten af voor de nationale, tijdelijke documentondertekenaars (d.w.z. ondertekenaars voor DCC’s), die Document Signer Certificates (DSC’s) worden genoemd. De CSCA fungeert als een vertrouwensanker zodat de lidstaten de CSCA kunnen gebruiken om de authenticiteit en integriteit van de regelmatig veranderende DSC’s te valideren. Na validatie kunnen de lidstaten hun DCC-validatietoepassingen voorzien van deze certificaten (of alleen de daarin vervatte publieke sleutels). Naast de CSCA’s en DSC’s vertrouwt de DCCG ook op PKI om transacties te authenticeren, data te ondertekenen, als basis voor authenticatie en als middel om de integriteit van de communicatiekanalen tussen de lidstaten en de DCCG te waarborgen.

Digitale handtekeningen kunnen worden gebruikt voor de integriteit en authenticiteit van de gegevens. Publiekesleutelinfrastructuren zorgen voor vertrouwen omdat ze publieke sleutels koppelen aan geverifieerde afgevers. Dit is noodzakelijk om andere deelnemers in staat te stellen de herkomst van de data en de identiteit van de communicatiepartner te controleren en te beslissen of deze te vertrouwen zijn. In de DCCG worden meerdere PKI-certificaten gebruikt om de authenticiteit te verifiëren. In deze bijlage wordt bepaald welke publiekesleutelcertificaten worden gebruikt en hoe deze moeten worden ontworpen om een brede interoperabiliteit tussen de lidstaten mogelijk te maken. Deze bijlage biedt meer details over de noodzakelijke publiekesleutelcertificaten en bevat richtsnoeren over certificaatmodellen en geldigheidstermijnen voor lidstaten die hun eigen CSCA willen exploiteren. Aangezien DCC’s voor een bepaald tijdsbestek verifieerbaar zijn (vanaf het moment van de afgifte tot wanneer ze na een bepaalde tijd vervallen), moet een verificatiemodel worden vastgesteld voor alle handtekeningen die op de publiekesleutelcertificaten en de DCC’s worden toegepast.

2.    Terminologie

De volgende tabel bevat de in deze bijlage gebruikte afkortingen en terminologie.

3.    DCCG-communicatiestromen en -beveiligingsdiensten

In dit deel wordt een overzicht gegeven van de communicatiestromen en beveiligingsdiensten in het DCCG-systeem. Hier wordt ook bepaald welke sleutels en certificaten worden gebruikt om de communicatie, de geüploade informatie, de DCC’s en een ondertekende vertrouwenslijst met alle geïntroduceerde CSCA-certificaten te beschermen. De DCCG fungeert als dataknooppunt dat de uitwisseling van ondertekende datapakketten door de lidstaten mogelijk maakt.

Geüploade datapakketten worden ongewijzigd door de DCCG verstrekt, wat betekent dat de DCCG geen DSC’s toevoegt of verwijdert uit de pakketten die hij ontvangt. De nationale backend (NB) van de lidstaten wordt in staat gesteld de integriteit en authenticiteit van de geüploade gegevens end-to-end te verifiëren. Daarnaast zullen nationale backends en de DCCG gebruikmaken van wederzijdse TLS-authenticatie om een beveiligde verbinding tot stand te brengen. Dit komt bovenop de handtekeningen in de uitgewisselde data.

3.1.    Authenticatie en maken van verbinding

De DCCG maakt gebruik van Transport Layer Security (TLS) met wederzijdse authenticatie om een geauthenticeerd versleuteld kanaal tot stand te brengen tussen de nationale backend (NB) van de lidstaat en de gatewayomgeving. De DCCG beschikt derhalve over een TLS-servercertificaat, afgekort DCCGTLS, en de nationale backends hebben een TLS-cliëntcertificaat, afgekort NBTLS. De modellen voor de certificaten zijn opgenomen in deel 5. Elke nationale backend kan zijn eigen TLS-certificaat verstrekken. Dit certificaat wordt uitdrukkelijk op de whitelist geplaatst en kan dus worden afgegeven door een openbaar vertrouwde certificeringsautoriteit (bijvoorbeeld een certificeringsautoriteit die voldoet aan de basisvereisten van het CA Browser Forum), door een nationale certificeringsautoriteit of door zelfondertekening. Elke lidstaat is verantwoordelijk voor zijn nationale gegevens en voor de bescherming van de persoonlijke sleutel die wordt gebruikt om de verbinding met de DCCG tot stand te brengen. Voor de BYOC-aanpak (“bring your own certificate”) is een duidelijk omschreven registratie- en identificatieprocedure nodig, evenals intrekkings- en hernieuwingsprocedures, zoals beschreven in delen 4.1, 4.2 en 4.3. De DCCG gebruikt een whitelist waaraan de TLS-certificaten van NB’s worden toegevoegd nadat ze succesvol geregistreerd zijn. Alleen NB’s die zichzelf authenticeren met een persoonlijke sleutel die overeenkomt met een certificaat op de whitelist, kunnen een beveiligde verbinding met de DCCG tot stand brengen. De DCCG zal ook een TLS-certificaat gebruiken dat de NB’s in staat stelt na te gaan of zij daadwerkelijk een verbinding met de “echte” DCCG tot stand brengen en niet met een kwaadwillige entiteit die zich als DCCG voordoet. Het certificaat van de DCCG wordt na succesvolle registratie aan de NB’s verstrekt. Het DCCGTLS-certificaat wordt afgegeven door een openbaar vertrouwde CA (opgenomen in alle belangrijke browsers). Het is de verantwoordelijkheid van de lidstaten om na te gaan of hun verbinding met de DCCG beveiligd is (bijvoorbeeld door de vingerafdruk van het DCCGTLS-certificaat van de server waarmee verbinding is gemaakt, te vergelijken met het certificaat dat na registratie werd verstrekt).

3.2.    CSCA’s en validatiemodel

De lidstaten die deelnemen aan het DCCG-kader moeten een CSCA gebruiken om de DSC’s af te geven. De lidstaten kunnen meer dan één CSCA hebben (bijvoorbeeld in het geval van regionale decentralisatie). Elke lidstaat kan gebruikmaken van bestaande certificeringsautoriteiten of speciaal voor het DCC-systeem een (eventueel zelfondertekende) certificeringsautoriteit opzetten.

De lidstaten moeten hun CSCA-certificaat/-certificaten aan de DCCG-exploitant overleggen in het kader van de officiële onboardingprocedure. Na succesvolle registratie van de lidstaat (zie deel 4.1 voor meer informatie) werkt de DCCG-exploitant een ondertekende vertrouwenslijst bij met alle CSCA-certificaten die actief zijn in het DCC-kader. De DCCG-exploitant gebruikt een specifiek asymmetrisch sleutelpaar om de vertrouwenslijst en de certificaten in een offline omgeving te ondertekenen. De persoonlijke sleutel wordt niet opgeslagen in het online DCCG-systeem, zodat een aanvaller die het onlinesysteem binnendringt de vertrouwenslijst niet in gevaar kan brengen. Het overeenkomstige vertrouwensankercertificaat DCCGTA wordt tijdens het onboardingproces aan de nationale backends verstrekt.

De lidstaten kunnen voor hun verificatieprocedures de vertrouwenslijst opvragen bij de DCCG. De CSCA wordt gedefinieerd als de certificeringsautoriteit die DSC’s afgeeft; daarom moeten lidstaten die gebruikmaken van een meerlagige CA-hiërarchie (bijvoorbeeld basis-CA -> CSCA -> DSC’s) zorgen voor de ondergeschikte certificeringsautoriteit die de DSC’s afgeeft. Als een lidstaat in dat geval gebruikmaakt van een bestaande certificeringsautoriteit, zal het DCC-systeem alles boven de CSCA negeren en alleen de CSCA als vertrouwensanker toestaan (ook al is het een ondergeschikte CA). Dit is zo omdat het ICAO-model slechts precies 2 niveaus toestaat — een basis-CSCA (“root”) en een eind-DSC (“leaf”), ondertekend door alleen die CSCA.

Indien een lidstaat zijn eigen CSCA exploiteert, is de lidstaat verantwoordelijk voor de beveiligde werking en het beveiligde sleutelbeheer van deze CA. De CSCA fungeert als vertrouwensanker voor DSC’s, en daarom is het beschermen van de persoonlijke sleutel van de CSCA van essentieel belang voor de integriteit van de DCC-omgeving. Het verificatiemodel in de DCC-PKI volgt het shell-model, dat bepaalt dat alle certificaten bij de validatie van het certificaatpad op een bepaald tijdstip geldig moeten zijn (d.w.z. het moment van validatie van de handtekening). Daarom zijn de volgende beperkingen van toepassing:

Deel 4.2 bevat aanbevelingen voor geldigheidstermijnen.

3.3.    Integriteit en authenticiteit van geüploade data

Nationale backends kunnen de DCCG gebruiken om digitaal ondertekende datapakketten na succesvolle wederzijdse authenticatie te uploaden en te downloaden. In het begin bevatten deze datapakketten de DSC’s van de lidstaten. Het sleutelpaar dat door de nationale backend wordt gebruikt voor het digitaal ondertekenen van geüploade datapakketten in het DCCG-systeem, wordt het uploadsleutelpaar van de nationale backend genoemd en het bijbehorende publiekesleutelcertificaat wordt afgekort tot NBUP-certificaat. Elke lidstaat brengt zijn eigen NBUP-certificaat mee, dat zelf kan worden ondertekend of dat kan worden afgegeven door een bestaande certificeringsautoriteit, bijvoorbeeld een openbare certificeringsautoriteit (d.w.z. een certificeringsautoriteit die een certificaat afgeeft in overeenstemming met de basisvereisten van het CAB-Forum). Het NBUP-certificaat is verschillend van alle andere door de lidstaat gebruikte certificaten (d.w.z. CSCA, TLS-cliënt of DSC’s).

De lidstaten moeten het uploadcertificaat aan de DCCG-operator verstrekken tijdens de eerste registratieprocedure (zie deel 4.1voor meer informatie). Elke lidstaat is verantwoordelijk voor zijn nationale gegevens en voor de bescherming van de persoonlijke sleutel die wordt gebruikt voor het ondertekenen van de uploads.

Andere lidstaten kunnen de ondertekende datapakketten verifiëren met behulp van de door de DCCG verstrekte uploadcertificaten. De DCCG verifieert de authenticiteit en integriteit van de geüploade data aan de hand van het uploadcertificaat van de NB alvorens deze aan andere lidstaten te verstrekken.

3.4.    Eisen inzake de technische DCCG-architectuur

Dit zijn de eisen inzake de technische DCCG-architectuur:

4.    Beheer van de certificatenlevenscyclus

4.1.    Registratie van nationale backends

De lidstaten moeten zich registreren bij de DCCG-exploitant om aan het DCCG-systeem deel te nemen. In dit deel wordt de technische en operationele procedure beschreven die moet worden gevolgd om een nationale backend te registreren.

De DCCG-exploitant en de lidstaat moeten informatie uitwisselen over technische contactpersonen voor het onboardingproces. Aangenomen wordt dat de technische contactpersonen geautoriseerd worden door hun lidstaat en dat identificatie/authenticatie via andere kanalen plaatsvindt. De authenticatie kan bijvoorbeeld worden bereikt wanneer de technische contactpersoon van een lidstaat de certificaten als met een wachtwoord versleutelde bestanden via e-mail verstrekt en het bijbehorende wachtwoord telefonisch met de DCCG-operator deelt. Ook andere door de DCCG-exploitant gedefinieerde beveiligde kanalen mogen worden gebruikt.

De lidstaat moet drie digitale certificaten verstrekken tijdens het registratie- en identificatieproces:

Alle verstrekte certificaten moeten voldoen aan de eisen van deel 5. De DCCG-exploitant controleert of het verstrekte certificaat voldoet aan de eisen van deel 5. Na de identificatie en registratie moet de DCCG-exploitant:

4.2.    Certificeringsautoriteiten, geldigheidstermijnen en vernieuwing

Indien een lidstaat zijn eigen CSCA wil exploiteren, kunnen de CSCA-certificaten zelfondertekende certificaten zijn. Zij fungeren als vertrouwensanker van de lidstaat en daarom moet de lidstaat de persoonlijke sleutel die overeenkomt met de publieke sleutel van de CSCA degelijk beschermen. Het strekt tot aanbeveling dat de lidstaten voor hun CSCA een offlinesysteem gebruiken, d.w.z. een computersysteem dat op geen enkel netwerk is aangesloten. Voor de toegang tot het systeem moet gebruik worden gemaakt van meerpersoonscontrole (bijvoorbeeld volgens het twee-paar-ogenprincipe). Na het ondertekenen van DSC’s moeten operationele controles worden uitgevoerd en moet het systeem dat de persoonlijke sleutel van de CSCA bevat veilig worden opgeslagen met strenge toegangscontroles. Hardwarebeveiligingsmodules of smartcards kunnen worden gebruikt om de persoonlijke sleutel van de CSCA verder te beschermen. Digitale certificaten omvatten een geldigheidstermijn waardoor vernieuwing van de certificaten nodig is. Vernieuwing is noodzakelijk om nieuwe cryptografische sleutels te gebruiken en de omvang van de sleutels aan te passen wanneer nieuwe berekeningsmethoden of nieuwe aanvallen een bedreiging vormen voor de beveiliging van het gebruikte cryptografische algoritme. Het shell-model is van toepassing (zie deel 3.2).

De volgende geldigheidstermijnen worden aanbevolen, gezien de geldigheidsduur van één jaar voor digitale EU-covidcertificaten:

Voor een tijdige vernieuwing worden voor de persoonlijke sleutels de volgende gebruiksperioden aanbevolen:

Voor een vlotte werking moeten de lidstaten tijdig nieuwe uploadcertificaten en TLS-certificaten creëren, bijvoorbeeld één maand voor de vervaldatum. CSCA-certificaten en DSC’s moeten ten minste één maand voor het einde van het gebruik van de persoonlijke sleutel worden vernieuwd (rekening houdend met de noodzakelijke operationele procedures). De lidstaten moeten geactualiseerde CSCA-, upload- en TLS-certificaten verstrekken aan de DCCG-exploitant. Verlopen certificaten worden van de whitelist en de vertrouwenslijst verwijderd.

De lidstaten en de DCCG-exploitant moeten de geldigheid van hun eigen certificaten bijhouden. Er is geen centrale entiteit die de geldigheid van het certificaat bijhoudt en de deelnemers informeert.

4.3.    Intrekking van certificaten

In het algemeen kunnen digitale certificaten door de afgevende CA worden ingetrokken met behulp van certificaatintrekkingslijsten of een OCSP-responder (Online Certificate Status Protocol). CSCA’s voor het DCC-systeem moeten certificaatintrekkingslijsten (CRL’s) verstrekken. Ook als andere lidstaten deze CRL’s momenteel niet gebruiken, moeten zij voor toekomstige toepassingen worden geïntegreerd. Indien een CSCA beslist geen CRL’s te verstrekken, moeten de DSC’s van deze CSCA worden vernieuwd zodra CRL’s verplicht worden. Verificateurs dienen voor de validatie van de DSC’s niet OCSP, maar CRL’s te gebruiken. Het strekt tot aanbeveling dat de nationale backend de noodzakelijke validatie van uit de DCCG gedownloade DSC’s uitvoert, en alleen een reeks betrouwbare en gevalideerde DSC’s doorstuurt naar nationale DSC-validators. DCC-validators mogen in hun validatieproces geen intrekkingscontroles uitvoeren op DSC’s. Eén reden hiervoor is dat op die manier de privacy van DCC-houders wordt beschermd door elke kans te vermijden dat het gebruik van een bepaalde DSC kan worden gecontroleerd door de bijbehorende OCSP-responder.

De lidstaten kunnen hun DSC’s uit de DCCG verwijderen met behulp van hun eigen geldige upload- en TLS-certificaten. Het verwijderen van een DSC betekent dat alle DCC’s die met de DSC in kwestie zijn afgegeven, ongeldig worden wanneer de lidstaten de bijgewerkte DSC-lijsten ophalen. Het is cruciaal dat persoonlijkesleutelmaterialen die overeenkomen met DSC’s worden beschermd. De lidstaten moeten de DCCG-exploitant ervan in kennis stellen wanneer zij upload- of TLS-certificaten moeten intrekken, bijvoorbeeld omdat de nationale backend gecompromitteerd is. De DCCG-exploitant kan dan de vertrouwensrelatie voor het betrokken certificaat verwijderen, bijvoorbeeld door deze van de TLS-whitelist te schrappen. De DCCG-exploitant kan de uploadcertificaten uit de DCCG-databank verwijderen. Pakketten die zijn ondertekend met de persoonlijke sleutel die met dit uploadcertificaat overeenstemt, worden ongeldig wanneer nationale backends de vertrouwensrelatie van het ingetrokken uploadcertificaat verwijderen. Indien een CSCA-certificaat moet worden ingetrokken, stellen de lidstaten de DCCG-exploitant en andere lidstaten waarmee zij een vertrouwensrelatie hebben, hiervan in kennis. De DCCG-exploitant stelt dan een nieuwe vertrouwenslijst op waarin het betrokken certificaat niet meer is opgenomen. Alle door deze CSCA afgegeven DSC’s worden ongeldig wanneer de lidstaten hun nationale backendvertrouwensarchief updaten. Indien het DCCGTLS-certificaat of het DCCGTA-certificaat moet worden ingetrokken, moeten de DCCG-exploitant en de lidstaten samenwerken om een nieuwe vertrouwde TLS-verbinding en vertrouwenslijst tot stand te brengen.

5.    Certificaatmodellen

In dit deel worden de cryptografische eisen en richtsnoeren uiteengezet, alsmede de eisen inzake certificaatmodellen. Met betrekking tot de DCCG-certificaten worden in dit deel de certificaatmodellen gedefinieerd.

5.1.    Cryptografische eisen

Cryptografische algoritmen en TLS-coderingssuites worden gekozen op basis van de huidige aanbeveling van het Duitse federale bureau voor informatiebeveiliging (BSI) of SOG-IS. Deze aanbevelingen zijn vergelijkbaar met die van andere instellingen en normalisatie-organisaties. De aanbevelingen staan in de technische richtsnoeren TR 02102-1 en TR 02102-2 ( 18 ) of SOG-IS Agreed Cryptographic Mechanisms ( 19 ).

5.1.1.    Eisen inzake de DSC

De eisen van bijlage I, deel 3.2.2, zijn van toepassing. Daarom wordt ten zeerste aanbevolen dat documentondertekenaars gebruikmaken van het elliptische krommealgoritme voor digitale handtekening (ECDSA) met NIST-p-256 (zoals gedefinieerd in aanhangsel D bij FIPS PUB 186-4). Andere elliptische krommen worden niet ondersteund. Vanwege de beperkte ruimte van de DCC mogen de lidstaten geen RSA-PSS gebruiken, zelfs niet als reservealgoritme. Indien lidstaten RSA-PSS gebruiken, moeten zij een modulusgrootte van 2048 of maximaal 3072 bit gebruiken. SHA-2 met een outputlengte van ≥ 256 bits wordt gebruikt als cryptografische hashfunctie (zie ISO/IEC 10118-3:2004) voor de DSC-handtekening.

5.1.2.    Eisen inzake TLS-, upload- en CSCA-certificaten

Voor digitale certificaten en cryptografische handtekeningen in de context van DCCG zijn de belangrijkste eisen inzake cryptografische algoritmen en sleutellengte samengevat in de volgende tabel (vanaf 2021):

De aanbevolen elliptische kromme voor EC-DSA is NIST-p-256 vanwege de wijdverbreide toepassing ervan.

5.2.    CSCA-certificaat (NBCSCA)

De volgende tabel bevat richtsnoeren voor het model van het NBCSCA-certificaat voor het geval dat een lidstaat besluit zijn eigen CSCA voor het DCC-systeem te exploiteren.

Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

Het subject-veld mag niet leeg zijn en moet uniek zijn binnen de gespecificeerde lidstaat. De landcode (c) moet overeenkomen met de lidstaat die dit CSCA-certificaat zal gebruiken. Het certificaat moet een unieke subject key identifier (SKI) bevatten overeenkomstig RFC 5280 ( 20 ).

5.3.    Document Signer Certificate (DSC)

De volgende tabel bevat richtsnoeren voor het DSC. Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

De DSC moet worden ondertekend met de persoonlijke sleutel die overeenstemt met een CSCA-certificaat dat door de lidstaat wordt gebruikt.

De volgende extensies moeten worden gebruikt:

Bovendien moet het certificaat de extensie voor CRL-distributiepunten bevatten die verwijst naar de certificaatintrekkingslijst (CRL) die wordt verstrekt door de CSCA die de DSC heeft afgegeven.

De DSC kan een extensie voor uitgebreide-sleutelgebruik met nul of meer identificatiecodes voor sleutelgebruiksbeleid bevatten die de soorten HCERT’s die dit certificaat mag verifiëren, beperken. Indien een of meer verificateurs aanwezig zijn, verifiëren zij het sleutelgebruik aan de hand van het opgeslagen HCERT. Hiervoor zijn de volgende extendedKeyUsage-waarden gedefinieerd:

Bij ontbreken van een extensie voor uitgebreide-sleutelgebruik (d.w.z. geen uitbreidingen of nuluitbreidingen), kan dit certificaat worden gebruikt om elk type HCERT te valideren. In andere documenten kunnen relevante aanvullende beleidsidentificatiecodes voor uitgebreide-sleutelgebruik worden gedefinieerd die worden gebruikt bij de validatie van HCERT’s.

5.4.    Uploadcertificaten (NBUP)

De volgende tabel bevat richtsnoeren voor het uploadcertificaat van nationale backends. Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

5.5.    TLS-cliëntauthenticatiecertificaat van nationale backends (NBTLS)

De volgende tabel bevat richtsnoeren voor het TLS-cliëntauthenticatiecertificaat van nationale backends. Vetgedrukte delen zijn verplicht (moeten in het certificaat worden opgenomen), cursieve delen worden aanbevolen (zouden erin moeten worden opgenomen). Voor ontbrekende velden zijn geen aanbevelingen vastgesteld.

Het certificaat kan ook het uitgebreide-sleutelgebruik server authentication (1.3.6.1.5.5.7.3.1) bevatten, maar dit is niet vereist.

5.6.    Handtekeningcertificaat voor vertrouwenslijst (DCCGTA)

In de volgende tabel wordt het DCCG-vertrouwensankercertificaat gedefinieerd.

5.7.    DCCG-TLS-servercertificaten (DCCGTLS)

In de volgende tabel wordt het DCCG-TLS-certificaat gedefinieerd.

Het certificaat kan ook het uitgebreide-sleutelgebruik client authentication (1.3.6.1.5.5.7.3.2) bevatten, maar dit is niet vereist.

Het TLS-certificaat van de DCCG wordt afgegeven door een algemeen betrouwbare certificeringsautoriteit (opgenomen in alle belangrijke browsers en besturingssystemen, volgens de basisvereisten van het CAB-forum).

▼M1

---

BIJLAGE V

JSON-SCHEMA (JAVASCRIPT-OBJECTNOTATION)

1.    Inleiding

In deze bijlage wordt de technische datastructuur voor de digitale EU-covidcertificaten (EUDCC) vastgesteld, die wordt weergegeven als JSON-schema. Het document bevat specifieke instructies met betrekking tot de afzonderlijke datavelden.

2.    Locatie en versies van het JSON-schema

Het gezaghebbende officiële JSON-schema voor EUDCC is beschikbaar op https://github.com/ehn-dcc-development/ehn-dcc-schema. Andere locaties zijn niet gezaghebbend, maar kunnen worden gebruikt om toekomstige herzieningen voor te bereiden.

De huidige versie, zoals uiteengezet in deze bijlage en ondersteund door alle landen die momenteel in productie zijn, wordt standaard weergegeven op de aangegeven URL.

De aanstaande volgende versie die door alle landen op een bepaalde datum moet worden ondersteund, wordt op de URL weergegeven door middel van versie-tagging die in het readme-bestand gedetailleerd wordt beschreven.

▼M3

3.    Gemeenschappelijke structuren en algemene eisen

Er wordt geen digitaal EU-covidcertificaat afgegeven indien vanwege ontbrekende informatie niet alle datavelden correct kunnen worden ingevuld conform deze specificatie. Dit doet geen afbreuk aan de verplichting van de lidstaten om digitale EU-covidcertificaten af te geven.

In alle velden mag informatie worden verstrekt met gebruikmaking van de volledige reeks UNICODE 13.0-tekens die zijn gecodeerd met UTF-8, tenzij dat specifiek beperkt is tot waardereeksen of kleinere reeksen tekens.

De gemeenschappelijke structuur is als volgt:

“JSON”:{

“ver”:<versie-informatie>,

“nam”:{

<persoonnaaminformatie>

},

“dob”:<geboortedatum>,

“v” of “t” of “r”:[

{<vaccinatiedosis of test of herstelinformatie, één entry>}

]

}

Nadere informatie over de afzonderlijke groepen en velden is te vinden in de volgende hoofdstukken.

Als in de regels is bepaald dat een veld moet worden overgeslagen, houdt dat in dat het leeg is en dat de naam noch de waarde van het veld in de inhoud is toegestaan.

3.1.    Versie

Er wordt informatie over de versie verstrekt. De vermelding van versies is gebaseerd op Semantic Versioning (semver: https://semver.org). Tijdens de productie is de versie een van de officieel vrijgegeven versies (huidige versie of een van de oudere versies die officieel zijn vrijgegeven). Zie JSON Schema location voor meer informatie.

3.2.    Naam en geboortedatum van de persoon

De naam van de persoon is de officiële volledige naam van de persoon, overeenkomend met de in reisdocumenten vermelde naam. De identificatiecode van de structuur is nam. De naam van exact 1 (één) persoon wordt vermeld.

3.3.    Groepen voor specifieke informatie betreffende het type certificaat

Het JSON-schema ondersteunt drie groepen vermeldingen die specifieke informatie betreffende het type certificaat bevatten. Elk EUDCC bevat exact 1 (één) groep. Lege groepen zijn niet toegestaan.

▼M1

4.    Specifieke informatie betreffende het type certificaat

4.1.    Vaccinatiecertificaat

De vaccinatiegroep, indien aanwezig, bevat exact 1 (één) vermelding die exact één vaccinatiegebeurtenis (één dosis) beschrijft. Alle elementen van de vaccinatiegroep zijn verplicht, lege waarden worden niet ondersteund.

4.2.    Testcertificaat

De testgroep, indien aanwezig, bevat exact 1 (één) vermelding die exact één testresultaat beschrijft.

4.3.    Herstelcertificaat

De herstelgroep, indien aanwezig, bevat exact 1 (één) vermelding die exact één herstelverklaring beschrijft. Alle elementen van de herstelgroep zijn verplicht, lege waarden worden niet ondersteund.

▼M3

---

BIJLAGE VI

VERANTWOORDELIJKHEDEN VAN DE LIDSTATEN ALS GEZAMENLIJKE VERWERKINGSVERANTWOORDELIJKEN VOOR DE GATEWAY VOOR DIGITALE EU-COVIDCERTIFICATEN INZAKE DE UITWISSELING VAN INTREKKINGSLIJSTEN VAN HET EU-DCC

AFDELING 1

Onderafdeling 1

Verdeling van verantwoordelijkheden

Onderafdeling 2

Verantwoordelijkheden en rollen voor het behandelen van verzoeken en voor het informeren van betrokkenen

AFDELING 2

Beheer van beveiligingsincidenten, met inbegrip van inbreuken in verband met persoonsgegevens

AFDELING 3

Gegevensbeschermingseffectbeoordeling

---

BIJLAGE VII

VERANTWOORDELIJKHEDEN VAN DE COMMISSIE ALS GEGEVENSVERWERKER VOOR DE GATEWAY VOOR DIGITALE EU-COVIDCERTIFICATEN TER ONDERSTEUNING VAN DE UITWISSELING VAN INTREKKINGSLIJSTEN VAN HET EU-DCC

De Commissie:

---

( 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 ) Verordening (EU) 2021/953 van het Europees Parlement en de Raad van 14 juni 2021 betreffende een kader voor de afgifte, verificatie en aanvaarding van interoperabele COVID-19-vaccinatie-, test- en herstelcertificaten (digitaal EU-COVID-certificaat) teneinde het vrije verkeer tijdens de COVID-19-pandemie te faciliteren (PB L 211 van 15.6.2021, blz. 1).

( 9 ) rfc1950 (ietf.org)

( 10 ) rfc1951 (ietf.org)

( 11 ) rfc7517 (ietf.org)

( 12 ) Zie ook 9.5.1.2 voor nadere API-beschrijvingen.

( 13 ) Verouderd betekent dat deze feature niet in nieuwe implementaties terugkomt, maar voor een bepaalde termijn wordt ondersteund voor nieuwe implementaties.

( 14 ) rfc3986 (ietf.org)

( 15 ) Voor de implementatie met QR-codes kunnen de lidstaten overwegen een extra reeks tekens met een totale lengte van 72 tekens (met inbegrip van de 27-30 van de identificatiecode zelf) te gebruiken om andere informatie over te brengen. Het is aan de lidstaten om deze informatie nader te omschrijven.

( 16 ) Het “Luhn mod N”-algoritme is een uitbreiding van het Luhn-algoritme (ook bekend als het mod 10-algoritme), dat voor numerieke codes werkt en bijvoorbeeld wordt gebruikt voor de berekening van de checksum van kredietkaarten. Met de extensie kan het algoritme werken met sequenties van waarden in om het even welke basis (in dit geval alfanumerieke tekens).

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

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

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

( 20 ) rfc5280 (ietf.org)

( 21 ) rfc5280 (ietf.org)