02021D1073 — NL — 18.11.2021 — 001.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:









▼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).

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

— Algoritme Handtekening (alg, label 1)

— Sleutelidentificatiecode (kid, label 4)

Payload

— Afgever (iss, claim key 1, facultatief, ISO 3166-1 alpha-2 van afgever)

— Afgegeven op (iat, claim key 6)

— Vervaltijd (exp, claim key 4)

— Gezondheidscertificaat (hcert, claim key -260)

— Digitaal EU-covidcertificaat v1 (eu_DCC_v1, claim key 1)

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:

— Primair algoritme: Het primaire algoritme is een elliptische krommealgoritme voor digitale handtekening (ECDSA), zoals gedefinieerd in (ISO/IEC 14888—3:2006) deel 2.3, waarbij gebruik wordt gemaakt van de P-256-parameters zoals gedefinieerd in aanhangsel D (D.1.2.3) bij (FIPS PUB 186-4) in combinatie met het SHA-256-hash-algoritme zoals gedefinieerd in (ISO/IEC 10118—3:2004) functie 4.

Dit komt overeen met COSE-algoritmeparameter ES256.

— Secundair algoritme: Het secundaire algoritme is RSASSA-PSS zoals gedefinieerd in (RFC 8230 ( 3 )) met een modulus van 2048 bits in combinatie met het SHA-256-hash-algoritme zoals gedefinieerd in (ISO/IEC 10118—3:2004) functie 4.

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:

— Het proces waarbij de sleutel wordt aangemaakt, kan gebreken vertonen, wat leidt tot zwakke sleutels.

— De sleutels kunnen worden onthuld door menselijke fouten.

— De sleutels kunnen worden gestolen door externe of interne daders.

— De sleutels kunnen worden berekend aan de hand van cryptoanalyse.

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:

— Een lidstaat kan meerdere CSCA-certificaten indienen.

— De geldigheidstermijn van het DSC (sleutelgebruik) kan eender welke lengte hebben, zolang deze de geldigheidstermijn van het CSCA-certificaat niet overschrijdt, en mag ontbreken.

— Het DSC mag beleidsidentificatiecodes (uitgebreide-sleutelgebruik) bevatten die specifiek zijn voor gezondheidscertificaten.

— De lidstaten kunnen ervoor kiezen gepubliceerde intrekkingen nooit te verifiëren, maar uitsluitend gebruik te maken van de DSC-lijsten die zij dagelijks van het secretariaat ontvangen of zelf samenstellen.

▼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.

Aangezien sommige waardereeksen op basis van de in deze bijlage opgenomen coderingssystemen, zoals die voor de codering van vaccins en snelle 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:







Code Weergave Naam codesysteem URL codesysteem OID codesysteem Versie codesysteem 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

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):

— het geneesmiddelenregister van de EU voor vaccins met EU-brede vergunning (vergunningsnummers);

— een wereldwijd vaccinregister, zoals een register dat door de Wereldgezondheidsorganisatie zou kunnen worden opgesteld;

— naam van het vaccin in andere gevallen. Indien de naam spaties bevat, worden deze vervangen door een koppelteken (-).

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:

— Voor het vaccin “COVID-19 Vaccine Moderna Intramuscular Injection”, de naam van het Spikevax-vaccin in Japan, moet code EU/1/20/1507 worden gebruikt, aangezien dat de naam van dit vaccin in de EU is.

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

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

Voorkeurscodesysteem:

— organisatiecode van het EMA (SPOR-systeem voor ISO IDMP);

— een wereldwijd register van handelsvergunninghouders of producenten van een vaccin, zoals een register dat door de Wereldgezondheidsorganisatie zou kunnen worden opgesteld;

— naam van de organisatie in andere gevallen. Indien de naam spaties bevat, worden deze vervangen door een koppelteken (-).

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:

— Voor de organisatie “Pfizer AG”, een handelsvergunninghouder voor het in Zwitserland gebruikte vaccin “Comirnaty”, moet code ORG-100030215 worden gebruikt die verwijst naar BioNTech Manufacturing GmbH, aangezien dat de handelsvergunninghouder van Comirnaty in de EU is.

— Voor de organisatie “Zuellig Pharma”, een handelsvergunninghouder voor het in de Filipijnen gebruikte vaccin Covid-19 Vaccine Moderna (Spikevax), moet code ORG-100031184 worden gebruikt die verwijst naar Moderna Biotech Spain S.L., aangezien dat de handelsvergunninghouder van Spikevax in de EU is.

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

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

Te gebruiken in certificaat 1.

Twee velden:

1) aantal in een reeks vaccindoses van een COVID-19-vaccin (N);

2) totaal aantal doses in de vaccinatiereeks (C).

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:

— 1/1 staat voor de voltooiing van een primaire-vaccinatiecyclus met één dosis, of de voltooiing van een primaire-vaccinatiecyclus die bestaat uit één dosis van een in twee doses toe te dienen vaccin dat aan een herstelde persoon is toegediend overeenkomstig het door een lidstaat toegepaste vaccinatieprotocol;

— 2/2 staat voor de voltooiing van een primaire-vaccinatiereeks met twee doses.

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.

5.2. Aanvullende doses

Wanneer de persoon doses krijgt na de primaire-vaccinatiereeks, worden die extra doses (X) weergegeven in de desbetreffende certificaten door verhoging van het aantal toegediende doses (N) en het totale aantal doses (C) (resulterend in (N+X)/(C+X)). Bijvoorbeeld:

— 2/2 staat voor de toediening van een aanvullende dosis na een primaire-vaccinatiecyclus met één dosis, of de toediening van een aanvullende dosis na voltooiing van een primaire-vaccinatiecyclus bestaande uit één dosis van een in twee doses toe te dienen vaccin dat aan een herstelde persoon is toegediend overeenkomstig het door een lidstaat toegepaste vaccinatieprotocol;

— 3/3 staat voor de toediening van een aanvullende dosis na een primaire-vaccinatiereeks met twee doses.

Aanvullende doses die na voltooiing van de primaire-vaccinatiereeks worden toegediend, worden dientengevolge aangegeven met (N+X)/(C+X) = 1.

Uiterlijk op 31 december 2021 afgegeven vaccinatiecertificaten worden aanvaard, ook indien voor deze certificaten een andere regel wordt gevolgd voor het coderen van het aantal in een reeks doses of het totale aantal doses in de reeks. Daartoe kunnen technische maatregelen worden genomen.

Binnen het bij Verordening (EU) 2021/953 vastgestelde rechtskader kunnen de lidstaten maatregelen nemen om in te gaan op de situatie van kwetsbare groepen die bij voorrang aanvullende doses kunnen ontvangen. Indien een lidstaat bijvoorbeeld besluit alleen aanvullende doses toe te dienen aan specifieke subgroepen van de bevolking, kan die lidstaat 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 kunnen zij gebruik blijven maken van het certificaat dat is ontvangen na voltooiing van de standaard primaire-vaccinatiereeks.

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:







Code Weergave Naam codesysteem URL codesysteem OID codesysteem Versie codesysteem LP6464-4 Nucleïnezuureamplificatie met monsterdetectie LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Immunoassay-sneltest LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

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

Te gebruiken in certificaat 2.

De inhoud van de waardereeks omvat de selectie van snelle antigeentests zoals opgenomen in de gemeenschappelijke en geactualiseerde lijst van snelle 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

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:







Code Weergave Naam codesysteem URL codesysteem OID codesysteem Versie codesysteem 260415000 Niet geconstateerd SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Geconstateerd SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼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:

— Moduleerbaarheid: de mate waarin de code is samengesteld uit afzonderlijke bouwstenen die semantisch verschillende informatie bevatten;

— Menselijke interpreteerbaarheid: de mate waarin de code betekenisvol is voor of geïnterpreteerd kan worden door de menselijke lezer;

— Wereldwijd uniek; de identificatiecode van het land of de autoriteit wordt goed beheerd; en van elk land (elke autoriteit) wordt verwacht dat het zijn segment van de namespace goed beheert door nooit identificatiecodes te hergebruiken of opnieuw af te geven. De combinatie daarvan zorgt ervoor dat elke identificatiecode wereldwijd uniek is.

▼M1

3. Algemene eisen

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

1) Tekenset: alleen US-ASCII-alfanumerieke tekens in hoofdletters (“A” tot en met “Z”, “0” tot en met “9”) zijn toegestaan; met extra speciale tekens voor scheiding van RFC3986 ( 12 ), namelijk {“/”, “#”, “:”};

2) Maximumlengte: ontwerpers streven naar een lengte van 27-30 tekens ( 13 );

3) Versieprefix: dit verwijst naar de versie van het UCI-schema. Het versieprefix is “01” voor deze versie van het document; het versieprefix bestaat uit twee cijfers;

4) Landprefix: de landcode is gespecificeerd volgens ISO 3166-1. Langere codes (bv. drie tekens en meer (bijvoorbeeld “UNHCR”) zijn gereserveerd voor toekomstig gebruik;

5) Suffix/checksum van de code: 5.1 De lidstaten gebruiken een checksum wanneer het waarschijnlijk is dat verzending, (menselijke) transcriptie of andere corrupties zich kunnen voordoen (d.w.z. bij gebruik in gedrukte vorm). 5.2 De checksum wordt niet gebruikt voor de validatie van het certificaat en maakt technisch gezien geen deel uit van de identificatiecode, maar wordt gebruikt om de integriteit van de code te verifiëren. Deze checksum is de samenvatting volgens ISO-7812-1 (LUHN-10) ( 14 ) van de volledige UCI in digitaal/draadformaat. De checksum wordt van de rest van de UCI gescheiden door een #-teken.

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 ( 15 ) 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.







Begrip Definities Certificaat Of publiekesleutelcertificaat. Een X.509-v3-certificaat dat de publieke sleutel van een entiteit bevat CSCA Country Signing Certificate Authority (nationale ondertekenende certificeringsautoriteit) DCC Digitaal EU-covidcertificaat Een ondertekend digitaal document met vaccinatie-, test- of herstelinformatie DCCG Gateway voor digitale EU-covidcertificaten. Dit systeem wordt gebruikt voor de uitwisseling van DSC’s tussen de lidstaten. DCCGTA Het vertrouwensankercertificaat van de DCCG. De overeenkomstige persoonlijke sleutel wordt gebruikt om de lijst van alle CSCA-certificaten offline te ondertekenen. DCCGTLS Het TLS-servercertificaat van de DCCG. DSC Document Signer Certificate (documentondertekenaarscertificaat). Het publiekesleutelcertificaat van de lidstaatautoriteit die documenten ondertekent (bijvoorbeeld een systeem dat DCC’s mag ondertekenen). Dit certificaat wordt afgegeven door de CSCA van de lidstaat. EC-DSA Elliptische krommealgoritme voor digitale handtekening. Een cryptografisch handtekeningalgoritme op basis van elliptische krommen Lidstaat Lidstaat van de Europese Unie mTLS Wederzijdse TLS. Het protocol inzake beveiliging op het niveau van de vervoerslaag (“Transport Layer Security Protocol”) met wederzijdse authenticatie NB Nationale backend van een lidstaat NBCSCA Het CSCA-certificaat van een lidstaat (kan meer dan één zijn) NBTLS Het TLS-cliëntauthenticatiecertificaat van een nationaal backend NBUP Het certificaat dat een nationale backend gebruikt om naar de DCCG geüploade datapakketten te ondertekenen PKI Publiekesleutelinfrastructuur. Vertrouwensmodel op basis van publiekesleutelcertificaten en certificeringsautoriteiten RSA Asymmetrisch cryptografisch algoritme op basis van ontbinding in gehele getallen dat wordt gebruikt voor digitale handtekeningen of asymmetrische versleuteling

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:

— De CSCA geeft geen certificaten af die langer geldig zijn dan het CA-certificaat zelf;

— De ondertekenaar van het document mag geen documenten ondertekenen die langer geldig zijn dan het DSC zelf;

— De lidstaten die hun eigen CSCA exploiteren, moeten de geldigheidstermijn voor hun CSCA en alle afgegeven certificaten vaststellen en zorgen voor de vernieuwing van certificaten.

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:

— De DCCG maakt gebruik van wederzijdse TLS-authenticatie om een geauthenticeerde versleutelde verbinding met de NB’s tot stand te brengen. De DCCG onderhoudt daarom een whitelist van geregistreerde NB TLS -cliëntcertificaten;

— De DCCG gebruikt twee digitale certificaten (DCCG TLS en DCCG TA ) met twee verschillende sleutelparen. De persoonlijke sleutel van het DCCG TA -sleutelpaar wordt offline bewaard (niet op de onlinecomponenten van de DCCG);

— De DCCG onderhoudt een vertrouwenslijst van de NB CSCA -certificaten die is ondertekend met de persoonlijke sleutel van de DCCG TA ;

— De gebruikte cijfers moeten voldoen aan de eisen van deel 5 .1 .

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:

— Het TLS-certificaat NB TLS van de lidstaat

— Het uploadcertificaat NB UP van de lidstaat

— Het CSCA-certificaat/de CSCA-certificaten NB CSCA van de lidstaat

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:

— het NB CSCA -certificaat/de NB CSCA -certificaten toevoegen aan de vertrouwenslijst die is ondertekend met de persoonlijke sleutel die overeenstemt met de publieke sleutel van de DCCG TA ;

— het NB TLS -certificaat toevoegen aan de whitelist van het TLS-eindpunt van de DCCG;

— het NB UP -certificaat toevoegen aan het DCCG-systeem;

— de publiekesleutelcertificaten van de DCCG TA en DCCG TLS aan de lidstaat verstrekken.

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:

— CSCA: 4 jaar

— DSC: 2 jaar

— Upload: 1-2 jaar

— TLS-cliëntauthenticatie: 1-2 jaar

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

— CSCA: één jaar

— DSC: zes maanden

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 ( 16 ) of SOG-IS Agreed Cryptographic Mechanisms ( 17 ).

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):







Algoritme van de handtekening Grootte van de sleutel Hashfunctie EC-DSA Min. 250 bit SHA-2 met een outputlengte ≥ 256 bit RSA-PSS (aanbevolen opvulling) RSA-PKCS#1 v1.5 (oude opvulling) Min. 3000 bit RSA Modulus (N) met een publieke exponent e > 2^16 SHA-2 met een outputlengte ≥ 256 bit DSA Min. 3000 bit prime p, 250 bit sleutel q SHA-2 met een outputlengte ≥ 256 bit

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.







Veld Waarde Subject cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat die de CSCA exploiteert> Key usage certificate signing, CRL signing (minimaal) Basic Constraints CA = true, path length constraints = 0

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 ( 18 ).

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.







Veld Waarde Serial Number uniek serienummer Subject cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat die de DSC gebruikt> Key Usage digital signature (minimaal)

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:

— Het certificaat moet een Authority Key Identifier (AKI) bevatten die overeenstemt met de Subject Key Identifier (SKI) van het certificaat dat de CSCA afgeeft.

— Het certificaat moet een unieke subject key identifier bevatten (overeenkomstig RFC 5280 ( 19 )).

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:







Veld Waarde extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 voor afgevers van testcertificaten extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 voor afgevers van vaccinatiecertificaten extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 voor afgevers van herstelcertificaten

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.







Veld Waarde Subject cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat die dit uploadcertificaat gebruikt> Key Usage digital signature (minimaal)

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.







Veld Waarde Subject cn=<niet lege en unieke algemene naam>, o=<Provider>, c=<lidstaat aan de NB> Key Usage digital signature (minimaal) Extended key usage cliëntauthenticatie (1.3.6.1.5.5.7.3.2)

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.







Veld Waarde Subject cn = Digital Green Certificate Gateway (1) , o=<Provider>, c=<land> Key Usage digital signature (minimaal) ( 1 ) De terminologie van “Digital Green Certificate” in plaats van “EU Digital COVID Certificate” is in dit verband gehandhaafd omdat dit de terminologie is die in de broncode is opgenomen en in het certificaat is gebruikt voordat de medewetgevers nieuwe terminologie hebben vastgesteld.

5.7. DCCG-TLS-servercertificaten (DCCGTLS)

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







Veld Waarde Subject cn=<FQDN of IP-adres van de DCCG>, o=<Provider>, c= <land> SubjectAltName dNSName: <naam DCCG DNS> of iPAddress: <IP-adres DCCG> Key Usage digital signature (minimaal) Extended key usage server authentication (1.3.6.1.5.5.7.3.1)

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.

3. Gemeenschappelijke structuren en algemene eisen

Er wordt geen digitaal EU-covidcertificaat afgegeven indien vanwege ontbrekende informatie niet alle gegevensvelden correct kunnen worden ingevuld in overeenstemming met 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”:<versiegegevens>,

“nam”:{

<informatie over de naam van de persoon>

},

“dob”:<geboortedatum>,

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

{<vaccinatiedosis of test- of herstelinformatie, één vermelding>}

]

}

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

3.1. Versie

Er wordt informatie over de versie verstrekt. De vermelding van versies is gebaseerd op Semantic Versioning (semverm: 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.







ID veld Naam veld Instructies ver Versie schema Stemt overeen met de identificatiecode van de voor de productie van het EUDCC gebruikte schemaversie. Voorbeeld: “ver”:“1.3.0”

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.







ID veld Naam veld Instructies nam/fn Achternaam/-namen Achternaam/-namen van de houder Exact 1 (één) niet-leeg veld wordt vermeld, waarin alle achternamen zijn opgegeven. In het geval van meerdere achternamen worden deze door een spatie gescheiden. Gecombineerde namen met koppeltekens of soortgelijke tekens, moeten echter dezelfde blijven. Voorbeelden: “fn”:“Musterfrau-Gößinger” “fn”:“Musterfrau-Gößinger Müller” nam/fnt Gestandaardiseerde achternaam/-namen Achternaam/-namen van de houder, getranslitereerd volgens dezelfde conventie als in de machineleesbare reisdocumenten van de houder (zoals de regels van ICAO Doc 9303 deel 3). Exact 1 (één) niet-leeg veld wordt vermeld, met uitsluitend de tekens A-Z en <. Maximumlengte: 80 tekens (volgens specificatie ICAO 9303 ). Voorbeelden: “fnt”:“MUSTERFRAU<GOESSINGER” “fnt”:“MUSTERFRAU<GOESSINGER<MUELLER” nam/gn Voornaam/-namen Voornaam/-namen van de houder. Indien de houder geen voornamen heeft, wordt het veld overgeslagen. In alle andere gevallen wordt exact 1 (één) niet-leeg veld vermeld, waarin alle voornamen zijn opgegeven. In het geval van meerdere voornamen worden deze door een spatie gescheiden. Voorbeeld: “gn”:“Isolde Erika” nam/gnt Gestandaardiseerde voornaam/-namen Voornaam/-namen van de houder, getranslitereerd volgens dezelfde conventie als die welke wordt gebruikt in de machineleesbare reisdocumenten van de houder (zoals de regels van ICAO Doc 9303 deel 3). Indien de houder geen voornamen heeft, wordt het veld overgeslagen. In alle andere gevallen wordt exact 1 (één) niet-leeg veld vermeld, met uitsluitend de tekens A-Z en <. Maximumlengte: 80 tekens. Voorbeeld: “gnt”:“ISOLDE<ERIKA” dob Geboortedatum Geboortedatum van de DCC-houder. Volledige of gedeeltelijke datum zonder tijd, beperkt tot het bereik 1900-01-01 t/m 2099-12-31. Exact 1 (één) niet-leeg veld wordt vermeld indien de volledige of gedeeltelijke geboortedatum bekend is. Indien de geboortedatum zelfs niet gedeeltelijk bekend is, bevat het veld een lege string “”. Dit moet overeenkomen met de informatie in de reisdocumenten. Indien er informatie over de geboortedatum beschikbaar is, wordt een van de volgende ISO 8601-formaten gebruikt. Andere opties worden niet ondersteund. JJJJ-MM-DD JJJJ-MM JJJJ (De verificateursapp kan ontbrekende delen van de geboortedatum tonen aan de hand van de XX-conventie zoals die welke wordt gebruikt in machineleesbare reisdocumenten, bv. 1990-XX-XX.) Voorbeelden: “dob”:“1979-04-14” “dob”:“1901-08” “dob”:“1939” “dob”:“”

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.







ID groep Naam groep Vermeldingen v Vaccinatiegroep Bevat, indien aanwezig, exact 1 (één) vermelding die exact 1 (één) vaccinatiedosis (één dosis) beschrijft. t Testgroep Bevat, indien aanwezig, exact 1 (één) vermelding die exact 1 (één) testresultaat beschrijft. r Herstelgroep Bevat, indien aanwezig, exact 1 (één) vermelding die 1 (één) herstelverklaring beschrijft.

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.







ID veld Naam veld Instructies v/tg Doelziekte of ziekteverwekker: COVID-19 (SARS-CoV of een van de varianten daarvan) Een gecodeerde waarde uit de waardereeks disease-agent-targeted.json. Deze waarde heeft één vermelding, nl. 840539006, de code voor COVID-19 uit SNOMED CT (GPS). Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “tg”:“840539006” v/vp COVID-19-vaccin of -profylaxe Het gebruikte type vaccin of profylaxe. Een gecodeerde waarde uit de waardereeks vaccine-prophylaxis.json. De waardereeks wordt gedistribueerd via de EUDCC-gateway. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “vp”:“1119349007” (een SARS-CoV-2 mRNA-vaccin) v/mp COVID-19-vaccinproduct Geneesmiddel dat voor deze specifieke vaccinatiedosis is gebruikt. Een gecodeerde waarde uit de waardereeks vaccine-medicinal-product.json. De waardereeks wordt gedistribueerd via de EUDCC-gateway. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “mp”:“EU/1/20/1528” (Comirnaty) v/ma Handelsvergunninghouder of producent van het COVID-19-vaccin Handelsvergunninghouder of producent, indien er geen handelsvergunninghouder aanwezig is. Een gecodeerde waarde uit de waardereeks vaccine-mah-manf.json. De waardereeks wordt gedistribueerd via de EUDCC-gateway. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “ma”:“ORG-100030215” (Biontech Manufacturing GmbH) v/dn Nummer in een reeks doses Volgnummer (positief geheel getal) van de tijdens deze vaccinatiegebeurtenis toegediende dosis. 1 voor de eerste dosis, 2 voor de tweede dosis enz. Meer specifieke regels zijn opgenomen in punt 5 van bijlage II. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeelden: “dn”:“1” (eerste dosis) “dn”:“2” (tweede dosis) “dn”:“3” (derde dosis) v/sd Het totale aantal doses in de reeks Totaal aantal doses (positief geheel getal) in de vaccinatiereeks. Meer specifieke regels zijn opgenomen in punt 5 van bijlage II. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeelden: “sd”:“1” (in geval van een primaire-vaccinatiecyclus met één dosis) “sd”:“2” (in geval van primaire-vaccinatiecyclus met twee doses of voor een aanvullende dosis na een primaire-vaccinatiecyclus met één dosis) “sd”:“3” (bv. in geval van aanvullende doses na een primaire-vaccinatiereeks met twee doses) v/dt Vaccinatiedatum De datum waarop de beschreven dosis is toegediend, in het formaat JJJJ-MM-DD (volledige datum zonder tijd). Andere formaten worden niet ondersteund. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “dt”:“2021-03-28” v/co Lidstaat of derde land waar het vaccin werd toegediend Land uitgedrukt als tweelettercode overeenkomstig ISO3166 (AANBEVOLEN) of een verwijzing naar een internationale organisatie die verantwoordelijk is voor de vaccinatiegebeurtenis (zoals UNHCR of WHO). Een gecodeerde waarde uit de waardereeks country-2-codes.json. De waardereeks wordt gedistribueerd via de EUDCC-gateway. Exact 1 (één) veld wordt vermeld. Voorbeeld: “co”:“CZ” “co”:“UNHCR” v/is Afgever van het certificaat Naam van de organisatie die het certificaat heeft afgegeven. Identificatiecodes zijn toegestaan als onderdeel van de naam, maar het wordt aanbevolen deze niet afzonderlijk te gebruiken, dus zonder de naam als tekst. Max. 80 UTF-8-tekens. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “is”:“Ministerie van Volksgezondheid van de Slowaakse Republiek” “is”:“Vaccinatiecentrum Zuid District 3” v/ci Unieke certificaatidentificatiecode Unieke certificaatidentificatiecode (UVCI) zoals gespecificeerd in https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf Vermelding van de checksum is facultatief. Het prefix “URN:UVCI:” mag worden toegevoegd. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeelden: “ci”:“URN:UVCI:01:NL:187/37512422923” “ci”:“URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B”

4.2. Testcertificaat

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







ID veld Naam veld Instructies t/tg Doelziekte of ziekteverwekker: COVID-19 (SARS-CoV of een van de varianten daarvan) Een gecodeerde waarde uit de waardereeks disease-agent-targeted.json. Deze waarde heeft één vermelding, nl. 840539006, de code voor COVID-19 uit SNOMED CT (GPS). Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “tg”:“840539006” t/tt Type test Het type test dat is gebruikt, op basis van het materiaal waarop de test betrekking heeft. Een gecodeerde waarde uit de waardereeks test-type.json (gebaseerd op LOINC). Waarden buiten de waardereeks zijn niet toegestaan. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “tt”:“LP6464-4” (Nucleïnezuureamplificatie met monsterdetectie) “tt”:“LP217198-3” (Immunoassay-sneltest) t/nm Naam van de test (alleen PCR-tests) De naam van de gebruikte nucleïnezuuramplificatietest (NAAT). De naam moet de naam van de fabrikant van de test en de handelsnaam van de test bevatten, gescheiden door een komma. Voor NAAT: het veld is facultatief. Voor RAT: het veld wordt niet gebruikt, aangezien de naam van de test indirect wordt verstrekt via de identificatiecode van het testapparaat (t/ma). Indien verstrekt, mag het veld niet leeg zijn. Voorbeeld: “nm”:“ELITechGroup, SARS-CoV-2 ELITe MGB® Kit” t/ma Identificatiecode van het testapparaat (alleen snelle antigeentests) Identificatiecode van het testapparaat voor snelle antigeentest (RAT) uit de JRC-database. Waardereeks (gemeenschappelijke lijst van het Gezondheidsbeveiligingscomité): — Alle snelle antigeentests op de gemeenschappelijke lijst van het Gezondheidsbeveiligingscomité (door mensen leesbaar). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (machineleesbaar, waarden van het veld id_device in de lijst vormen de waardereeks). In EU-/EER-landen geven afgevers alleen certificaten af voor tests die tot de op dat moment geldige waardereeks behoren. De waardereeks wordt om de 24 uur bijgewerkt. Waarden buiten de vastgestelde waardereeks mogen worden gebruikt in door derde landen afgegeven certificaten, maar de identificatiecodes moeten nog steeds uit de JRC-database afkomstig zijn. Het gebruik van andere identificatiecodes, zoals die welke rechtstreeks door de testfabrikanten worden verstrekt, is niet toegestaan. Verificateurs detecteren waarden die niet behoren tot de actuele waardereeks en merken certificaten die daarvan zijn voorzien aan als ongeldig. Indien een identificatiecode uit de waardreeks waarden wordt verwijderd, kunnen certificaten waarin deze is opgenomen maximaal 72 uur na de datum van verwijdering worden aanvaard. De waardereeks wordt gedistribueerd via de EUDCC-gateway. Voor RAT: exact 1 (één) niet-leeg veld wordt vermeld. Voor NAAT: het veld wordt niet gebruikt, zelfs niet als de NAAT-identificatiecode beschikbaar is in de JRC-databank. Voorbeeld: “ma”:“344” (SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc Datum en tijdstip van de monsterneming Datum en tijdstip waarop het monster is genomen. De tijd moet informatie over de tijdzone bevatten. De waarde mag geen betrekking hebben op het tijdstip waarop het testresultaat tot stand is gekomen. Exact 1 (één) niet-leeg veld wordt vermeld. Er wordt een van de volgende ISO 8601-formaten gebruikt. Andere opties worden niet ondersteund. JJJJ-MM-DDTuu:mm:ssZ JJJJ-MM-DDTuu:mm:ss[+-]uu JJJJ-MM-DDTuu:mm:ss[+-]uumm JJJJ-MM-DDTuu:mm:ss[+-]uu:mm Voorbeelden: “sc”:“2021-08-20T10:03:12Z” (UTC-tijd) “sc”:“2021-08-20T12:03:12+02” (CEST-tijd) “sc”:“2021-08-20T12:03:12+0200” (CEST-tijd) “sc”:“2021-08-20T12:03:12+02:00” (CEST-tijd) t/tr Testresultaat Het resultaat van de test. Een gecodeerde waarde uit de waardereeks test-result.json (gebaseerd op SNOMED CT, GPS). Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “tr”:“260415000” (Niet geconstateerd) t/tc Testcentrum of -faciliteit Naam van de actor die de test heeft uitgevoerd. Identificatiecodes zijn toegestaan als onderdeel van de naam, maar het wordt aanbevolen deze niet afzonderlijk te gebruiken, dus zonder de naam als tekst. Max. 80 UTF-8-tekens. Eventuele extra tekens moeten worden afgebroken. De naam is niet geschikt voor automatische verificatie. Voor NAAT-tests: exact 1 (één) niet-leeg veld wordt vermeld. Voor RAT-tests: het veld is facultatief. Indien verstrekt, is dit veld niet leeg. Voorbeeld: “tc”:“Testcentrum west regio 245” t/co Lidstaat of derde land waar de test werd afgenomen Land uitgedrukt als tweelettercode overeenkomstig ISO3166 (AANBEVOLEN) of een verwijzing naar een internationale organisatie die verantwoordelijk is voor het afnemen van de test (zoals UNHCR of WHO). Dit is een gecodeerde waarde uit de waardereeks country-2-codes.json. De waardereeks wordt gedistribueerd via de EUDCC-gateway. Exact 1 (één) veld wordt vermeld. Voorbeelden: “co”:“CZ” “co”:“UNHCR” t/is Afgever van het certificaat Naam van de organisatie die het certificaat heeft afgegeven. Identificatiecodes zijn toegestaan als onderdeel van de naam, maar het wordt aanbevolen deze niet afzonderlijk te gebruiken, dus zonder de naam als tekst. Max. 80 UTF-8-tekens. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeelden: “is”:“Ministerie van Volksgezondheid van de Slowaakse Republiek” “is”:“Gezondheidsautoriteit noord-west” t/ci Unieke certificaatidentificatiecode Unieke certificaatidentificatiecode (UVCI) zoals gespecificeerd in vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Vermelding van de checksum is facultatief. Het prefix “URN:UVCI:” mag worden toegevoegd. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeelden: “ci”:“URN:UVCI:01:NL:187/37512422923” “ci”:“URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B”

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.







ID veld Naam veld Instructies r/tg Ziekte of ziekteverwekker waarvan de houder is hersteld: COVID-19 (SARS-CoV-2 of een van de varianten daarvan) Een gecodeerde waarde uit de waardereeks disease-agent-targeted.json. Deze waarde heeft één vermelding, nl. 840539006, de code voor COVID-19 uit SNOMED CT (GPS). Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “tg”:“840539006” r/fr Datum van het eerste positieve NAAT-testresultaat van de houder De datum waarop een monster voor de NAAT-test met een positief resultaat is genomen, in het formaat JJJJ-MM-DD (volledige datum zonder tijd). Andere formaten worden niet ondersteund. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “fr”:“2021-05-18” r/co Lidstaat of derde land waar de test werd afgenomen Land uitgedrukt als tweelettercode overeenkomstig ISO3166 (AANBEVOLEN) of een verwijzing naar een internationale organisatie die verantwoordelijk is voor het afnemen van de test (zoals UNHCR of WHO). Dit is een gecodeerde waarde uit de waardereeks country-2-codes.json. De waardereeks wordt gedistribueerd via de EUDCC-gateway. Exact 1 (één) veld wordt vermeld. Voorbeelden: “co”:“CZ” “co”:“UNHCR” r/is Afgever van het certificaat Naam van de organisatie die het certificaat heeft afgegeven. Identificatiecodes zijn toegestaan als onderdeel van de naam, maar het wordt aanbevolen deze niet afzonderlijk te gebruiken, dus zonder de naam als tekst. Max. 80 UTF-8-tekens. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “is”:“Ministerie van Volksgezondheid van de Slowaakse Republiek” “is”:“Centraal universitair ziekenhuis” r/df Certificaat geldig vanaf De eerste datum waarop het certificaat geldig wordt geacht. De datum mag niet vroeger zijn dan de datum berekend als r/fr + 11 dagen. De datum wordt opgegeven in het formaat JJJJ-MM-DD (volledige datum zonder tijd). Andere formaten worden niet ondersteund. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “df”:“2021-05-29” r/du Certificaat geldig tot en met De uiterste datum waarop het certificaat geldig wordt geacht, toegewezen door de afgever. De datum mag niet later zijn dan de datum berekend als r/fr + 180 dagen. De datum wordt opgegeven in het formaat JJJJ-MM-DD (volledige datum zonder tijd). Andere formaten worden niet ondersteund. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeeld: “du”:“2021-11-14” r/ci Unieke certificaatidentificatiecode Unieke certificaatidentificatiecode (UVCI) zoals gespecificeerd in vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Vermelding van de checksum is facultatief. Het prefix “URN:UVCI:” mag worden toegevoegd. Exact 1 (één) niet-leeg veld wordt vermeld. Voorbeelden: “ci”:“URN:UVCI:01:NL:187/37512422923” “ci”: “URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B