(integrato dall'art. 1 della Dec. (UE) 2022/483)

FORMATO E GESTIONE DELLA FIDUCIA

Struttura dei dati generici, meccanismi di codifica e meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente (di seguito «Q R»)

1. Introduzione

Le specifiche tecniche di cui al presente allegato contengono una struttura dei dati generici e meccanismi di codifica per il certificato COVID digitale dell'UE (Digital COVID Certificate - «DCC»). Specificano inoltre un meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente («QR») che possa essere visualizzato sullo schermo di un dispositivo mobile o stampato. I formati contenitore dei certificati sanitari elettronici delle presenti specifiche sono generici, ma in questo contesto sono utilizzati per trasportare il DCC.

2. Terminologia

Ai fini del presente allegato, per «emittenti» si intendono le organizzazioni che utilizzano le presenti specifiche per rilasciare i certificati sanitari e per «verificatori» si intendono le organizzazioni che accettano i certificati sanitari come prova dello stato sanitario. Per «partecipanti» si intendono gli emittenti e i verificatori. Alcuni aspetti indicati nel presente allegato devono essere coordinati tra i partecipanti, come la gestione di uno spazio dei nomi e la distribuzione delle chiavi crittografiche. Si presume che una parte, in appresso denominata «segretariato», svolga tali compiti.

3. Formato contenitore dei certificati sanitari elettronici

Il formato contenitore dei certificati sanitari elettronici (Electronic Health Certificate Container Format - «HCERT») è concepito per fornire un veicolo uniforme e standardizzato per i certificati sanitari dei diversi emittenti («emittenti»). L'obiettivo delle presenti specifiche è armonizzare il modo in cui tali certificati sanitari sono rappresentati, codificati e firmati allo scopo di agevolare l'interoperabilità.

La capacità di leggere e interpretare un DCC rilasciato da qualsiasi emittente richiede una struttura comune dei dati e un accordo sul significato di ciascun campo di dati del carico utile. Per agevolare tale interoperabilità, è definita una struttura comune coordinata dei dati mediante l'uso di uno schema «JSON» che costituisce il quadro del DCC.

3.1. Struttura del carico utile

Il carico utile è strutturato e codificato come CBOR con firma digitale COSE. Questo è comunemente noto come «CBOR Web Token» (CWT) ed è definito in RFC 8392 [1]. Il carico utile, quale definito nelle sezioni che seguono, è trasportato in una richiesta hcert.

L'integrità e l'autenticità dell'origine dei dati del carico utile devono essere verificabili dal verificatore. Per fornire questo meccanismo, l'emittente deve firmare il CWT utilizzando uno schema di firma elettronica asimmetrica quale definito nella specifica COSE (RFC 8152 [2]).

3.2. Richieste CWT

3.2.1. Panoramica della struttura CWT

Intestazione protetta

- Algoritmo di firma (alg, etichetta 1)

- Identificativo della chiave (kid, etichetta 4)

Carico utile

- Emittente (iss, chiave di richiesta 1, facoltativo, ISO 3166-1 alpha-2 dell'emittente)

- Momento del rilascio (iat, chiave di richiesta 6)

- Termine di scadenza (exp, chiave di richiesta 4)

- Certificato sanitario (hcert, chiave di richiesta -260)

- Certificato COVID digitale dell'UE v1 (eu_DCC_v1, chiave di richiesta 1)

Firma

3.2.2. Algoritmo di firma

Il parametro dell'algoritmo di firma (alg) indica l'algoritmo utilizzato per creare la firma. Deve rispettare o superare gli attuali orientamenti del SOGIS sintetizzati nei paragrafi seguenti.

Sono definiti un algoritmo primario e un algoritmo secondario. L'algoritmo secondario dovrebbe essere utilizzato solo se l'algoritmo primario non è accettabile nell'ambito delle norme e dei regolamenti imposti all'emittente.

Al fine di garantire la sicurezza del sistema, tutte le implementazioni devono incorporare l'algoritmo secondario. Per questo motivo, sia l'algoritmo primario che quello secondario devono essere implementati.

I livelli stabiliti dal SOGIS per gli algoritmi primari e secondari sono i seguenti.

- Algoritmo primario: l'algoritmo primario è l'algoritmo di firma digitale su curva ellittica (Elliptic Curve Digital Signature Algorithm - ECDSA) quale definito nella sezione 2.3 (ISO/IEC 14888-3:2006) utilizzando i parametri P-256 definiti nell'appendice D (D.1.2.3) di (FIPS PUB 186-4) in combinazione con l'algoritmo hash SHA-256 quale definito nella funzione 4 (ISO/IEC 10118-3:2004).

Questo corrisponde al parametro dell'algoritmo COSE ES256.

- Algoritmo secondario: l'algoritmo secondario è RSASSA-PSS quale definito in (RFC 8230 [3]) con un modulo di 2048 bit in combinazione con l'algoritmo hash SHA-256 quale definito nella funzione 4 (ISO/IEC 10118-3:2004).

Questo corrisponde al parametro dell'algoritmo COSE PS256.

3.2.3. Identificativo della chiave

La richiesta Identificativo della chiave (kid) indica il certificato di firma digitale (Document Signer Certificate - DSC) contenente la chiave pubblica che il verificatore deve utilizzare per controllare la correttezza della firma digitale. Nell'allegato IV è descritta la governance dei certificati a chiave pubblica, compresi i requisiti per i DSC.

La richiesta Identificativo della chiave (kid) è utilizzata dai verificatori per selezionare la chiave pubblica corretta da un elenco di chiavi relative all'emittente indicato nella richiesta Emittente (iss). Un emittente può utilizzare diverse chiavi in parallelo per motivi amministrativi e quando effettua i rinnovi delle chiavi. L'identificativo della chiave non è un campo critico per la sicurezza. Per questo motivo, se necessario, può anche essere collocato in un'intestazione non protetta. I verificatori devono accettare entrambe le opzioni. Se entrambe le opzioni sono presenti, deve essere utilizzato l'identificativo della chiave nell'intestazione protetta.

A causa dell'accorciamento dell'identificativo (per motivi di limitazione delle dimensioni) vi è una probabilità molto bassa, ma non inesistente, che l'elenco generale dei DSC accettati da un verificatore possa contenere DSC con kid doppi. Per questo motivo il verificatore deve controllare tutti i DSC con tale kid.

3.2.4. Emittente

La richiesta Emittente (iss) è un valore di stringa che può facoltativamente riportare il codice paese ISO 3166-1 alpha-2 del soggetto che ha rilasciato il certificato sanitario. Tale richiesta può essere utilizzata da un verificatore per individuare la serie di DSC da utilizzare per la verifica. La chiave di richiesta 1 è utilizzata per identificare questa richiesta.

3.2.5. Termine di scadenza

La richiesta Termine di scadenza (exp) deve contenere una marcatura temporale nel formato NumericDate intero (come specificato in RFC 8392 [4], sezione 2) che indichi per quanto tempo quella particolare firma sul carico utile è considerata valida e decorso il quale il verificatore deve rifiutare il carico utile come scaduto. Il parametro del termine di scadenza ha lo scopo di imporre un limite al periodo di validità del certificato sanitario. La chiave di richiesta 4 è utilizzata per identificare questa richiesta.

Il termine di scadenza non deve cadere oltre il periodo di validità del DSC.

3.2.6. Momento del rilascio

La richiesta Momento del rilascio (iat) deve contenere una marcatura temporale nel formato NumericDate intero (come specificato in RFC 8392 [5], sezione 2) indicante il momento in cui è stato creato il certificato sanitario.

Il campo Momento del rilascio non deve indicare una data anteriore al periodo di validità del DSC.

I verificatori possono applicare policy aggiuntive allo scopo di limitare la validità del certificato sanitario in base al momento del rilascio. La chiave di richiesta 6 è utilizzata per identificare questa richiesta.

3.2.7. Richiesta Certificato sanitario

La richiesta Certificato sanitario (hcert) è un oggetto JSON (RFC 7159 [6]) contenente le informazioni sullo stato sanitario. Nell'ambito della stessa richiesta possono esistere diversi tipi di certificato sanitario, tra cui il DCC.

Il formato JSON serve esclusivamente per finalità di schema. Il formato di rappresentazione è CBOR, come definito in (RFC 7049 [7]). Gli sviluppatori di applicazioni non possono in realtà mai decodificare o codificare da e verso il formato JSON, bensì utilizzano la struttura in-memory.

La chiave di richiesta da utilizzare per identificare questa richiesta è -260.

Le stringhe dell'oggetto JSON dovrebbero essere normalizzate secondo la Normalization Form Canonical Composition (NFC) definita nello standard Unicode. Le applicazioni di decodifica dovrebbero tuttavia essere permissive e solide in relazione a questi aspetti ed è fortemente incoraggiata l'accettazione di qualsiasi tipo di conversione ragionevole. Se durante la decodifica o nelle successive funzioni di confronto si riscontrano dati non normalizzati, le implementazioni dovrebbero comportarsi come se l'immissione fosse normalizzata NFC.

4. Serializzazione e creazione del carico utile DCC

Come modello di serializzazione si utilizza lo schema seguente:

Il processo inizia con l'estrazione dei dati, ad esempio da un archivio di dati sanitari (o da qualche fonte di dati esterna), e con la strutturazione dei dati estratti secondo gli schemi DCC definiti. In questo processo, la conversione nel formato di dati definito e la trasformazione per la leggibilità da parte dell'uomo possono aver luogo prima dell'inizio della serializzazione CBOR. Gli acronimi delle richieste sono in ogni caso mappati ai nomi visualizzati prima della serializzazione e dopo la deserializzazione.

Non sono consentiti contenuti di dati nazionali facoltativi nei certificati rilasciati a norma del regolamento (UE) 2021/953 [8]. Il contenuto di dati è limitato agli elementi di dati definiti nella serie minima di dati specificata nell'allegato del regolamento (UE) 2021/953.

5. Codifiche di trasporto

5.1. Codifica grezza

Per le interfacce di dati arbitrari, il contenitore HCERT e i suoi carichi utili possono essere trasferiti tal quali, utilizzando qualsiasi trasporto di dati sottostante sicuro e affidabile a 8 bit. Queste interfacce possono comprendere la comunicazione di prossimità (Near-Field Communication - NFC), il Bluetooth o il trasferimento attraverso un protocollo di livello applicazione, ad esempio il trasferimento di un HCERT dall'emittente al dispositivo mobile del titolare.

Se il trasferimento dell'HCERT dall'emittente al titolare si basa su un'interfaccia di sola presentazione (ad esempio SMS, e-mail), la codifica di trasporto grezza non è ovviamente applicabile.

5.2. Codice a barre

5.2.1. Compressione del carico utile (CWT)

Per ridurre le dimensioni e migliorare la velocità e l'affidabilità nel processo di lettura dell'HCERT, il CWT è compresso utilizzando ZLIB (RFC 1950 [9]) e il meccanismo di compressione Deflate nel formato definito in RFC 1951 [10].

5.2.2. Codice a barre 2D QR

Ai fini di una migliore gestione delle apparecchiature preesistenti progettate per funzionare sui carichi utili ASCII, il CWT compresso è codificato come ASCII utilizzando Base45 prima di essere codificato in un codice a barre 2D.

Il formato QR quale definito nella norma (ISO/IEC 18004:2015) è utilizzato per la generazione di codici a barre 2D. Si raccomanda un tasso di correzione degli errori di «Q» (circa il 25 %). Poiché si utilizza Base45, il codice QR deve utilizzare la codifica alfanumerica (modalità 2, indicata dai simboli 0010).

Affinché i verificatori siano in grado di rilevare il tipo di dati codificati e di selezionare il sistema adeguato di decodifica e trattamento, i dati codificati Base45 (secondo la presente specifica) hanno come prefisso la stringa dell'identificativo di contesto «HC1:». Le versioni future della presente specifica che incidono sulla retrocompatibilità definiranno un nuovo identificativo di contesto, mentre il carattere che segue «HC» sarà tratto dalla serie di caratteri [1-9 A-Z]. L'ordine degli incrementi è definito in tale ordine, ossia prima [1-9] e successivamente [A-Z].

Si raccomanda di rendere il codice ottico sul supporto di presentazione con dimensioni della diagonale comprese tra 35 mm e 60 mm per i lettori con ottica fissa in cui i supporti di presentazione devono essere collocati sulla superficie del lettore.

Se il codice ottico è stampato su carta con stampanti a bassa risoluzione (< 300 dpi), si deve prestare attenzione a rappresentare ciascun simbolo (punto) del codice QR esattamente quadrato. Se il ridimensionamento non sarà proporzionale, alcune righe o colonne del codice QR avranno simboli rettangolari, il che in molti casi ostacolerà la leggibilità.

6. Formato dell'elenco di fiducia (elenco di CSCA e DSC)

Ciascuno Stato membro è tenuto a fornire un elenco di una o più autorità nazionali di certificazione (Country Signing Certificate Authority - CSCA) e un elenco di tutti i certificati di firma digitale (DSC) validi e a mantenere tali elenchi aggiornati.

6.1. CSCA/DSC semplificati

A partire da questa versione delle specifiche, gli Stati membri non presumono che siano utilizzate informazioni relative all'elenco dei certificati revocati (Certificate Revocation List - CRL) o che il periodo di utilizzo della chiave privata sia verificato dagli attuatori.

Il meccanismo di validità principale è invece la presenza del certificato nella versione più recente dell'elenco dei certificati.

6.2. Infrastruttura a chiave pubblica eMRTD conforme ICAO e centri protezione

Gli Stati membri possono ricorrere a una CSCA distinta, ma possono anche presentare i loro certificati CSCA e/o DSC eMRTD esistenti; inoltre possono anche scegliere di procurarseli presso centri protezione (commerciali) e di presentare questi ultimi. Tuttavia qualsiasi DSC deve sempre essere firmato dalla CSCA presentata da tale Stato membro.

7. Considerazioni in materia di sicurezza

Nel progettare uno schema basato su questa specifica, gli Stati membri individuano, analizzano e monitorano taluni aspetti legati alla sicurezza.

Dovrebbero essere presi in considerazione almeno gli aspetti seguenti.

7.1. Periodo di validità della firma HCERT

L'emittente degli HCERT è tenuto a limitare il periodo di validità della firma specificando un termine di scadenza. Ciò impone al titolare di un certificato sanitario di rinnovarlo periodicamente.

Il periodo di validità accettabile può essere determinato da vincoli pratici. Ad esempio, un viaggiatore potrebbe non avere la possibilità di rinnovare il certificato sanitario durante un viaggio all'estero. Tuttavia può anche accadere che un emittente stia valutando la possibilità di una qualche forma di compromissione della sicurezza che gli impone di ritirare un DSC (invalidando tutti i certificati sanitari rilasciati utilizzando tale chiave ancora entro il loro periodo di validità). Le conseguenze di un tale evento possono essere limitate effettuando una regolare rotazione delle chiavi emittente e richiedendo il rinnovo di tutti i certificati sanitari a intervalli ragionevoli.

7.2. Gestione delle chiavi

Questa specifica si basa in larga misura su solidi meccanismi crittografici che garantiscono l'integrità dei dati e l'autenticazione dell'origine dei dati. E' pertanto necessario mantenere la riservatezza delle chiavi private.

La riservatezza delle chiavi crittografiche può essere compromessa in vari modi, ad esempio:

- il processo di generazione delle chiavi può essere viziato, con conseguente debolezza delle chiavi;

- le chiavi possono essere rivelate per errore umano;

- le chiavi possono essere rubate da soggetti esterni o interni;

- le chiavi possono essere calcolate mediante crittoanalisi.

Al fine di mitigare i rischi che l'algoritmo di firma sia debole e consenta di compromettere le chiavi private mediante crittoanalisi, questa specifica raccomanda a tutti i partecipanti di implementare un algoritmo di firma secondario di riserva, basato su parametri diversi o su un problema matematico diverso da quello primario.

Per quanto riguarda i rischi menzionati relativi agli ambienti operativi degli emittenti, sono attuate misure di mitigazione per garantire un controllo efficace, in modo da generare, memorizzare e utilizzare le chiavi private nei moduli di sicurezza hardware (Hardware Security Model - HSM). L'uso di HSM per la firma dei certificati sanitari è fortemente incoraggiato.

Indipendentemente dal fatto che un emittente decida di utilizzare gli HSM o no, è opportuno stabilire un calendario dei rinnovi delle chiavi la cui frequenza sia proporzionata all'esposizione delle chiavi a reti esterne, altri sistemi e personale. Un calendario dei rinnovi ben scelto limita inoltre i rischi associati ai certificati sanitari rilasciati erroneamente, consentendo all'emittente di revocare tali certificati in lotti, ritirando una chiave, se necessario.

7.3. Convalida dei dati immessi

Queste specifiche possono essere utilizzate in modo da implicare il ricevimento di dati da fonti non fidate in sistemi che possono essere di natura critica. Per ridurre al minimo i rischi associati a questo vettore di attacco, tutti i campi di immissione devono essere debitamente convalidati in termini di tipi di dati, lunghezze e contenuto. Prima di qualsiasi trattamento del contenuto dell'HCERT è verificata anche la firma dell'emittente. Tuttavia la convalida della firma dell'emittente implica innanzitutto l'analisi dell'intestazione protetta dell'emittente, nella quale un potenziale aggressore potrebbe tentare di iniettare informazioni accuratamente preparate per compromettere la sicurezza del sistema.

8. Gestione della fiducia

La firma dell'HCERT richiede una chiave pubblica da verificare. Gli Stati membri mettono a disposizione tali chiavi pubbliche. In ultima analisi, ogni verificatore deve disporre di un elenco di tutte le chiavi pubbliche di cui intende fidarsi (dato che la chiave pubblica non fa parte dell'HCERT).

Il sistema è costituito (solo) da due livelli; per ciascuno Stato membro, uno o più certificati di livello nazionale che firmano ognuno uno o più certificati di firma digitale utilizzati nelle operazioni quotidiane.

I certificati degli Stati membri sono denominati certificati dell'autorità nazionale di certificazione (CSCA) e sono (di norma) autofirmati. Gli Stati membri possono averne più di una (ad esempio, in caso di decentramento regionale). Questi certificati CSCA firmano regolarmente i certificati di firma digitale (DSC) utilizzati per firmare gli HCERT.

Il «segretariato» svolge un ruolo funzionale. Esso aggrega e pubblica periodicamente i DSC degli Stati membri, dopo averli verificati sulla base dell'elenco dei certificati CSCA (che sono stati trasmessi e verificati con altri mezzi).

L'elenco risultante dei DSC fornisce quindi la serie aggregata di chiavi pubbliche accettabili (e i relativi identificativi) che i verificatori possono utilizzare per convalidare le firme sugli HCERT. I verificatori devono estrarre e aggiornare regolarmente questo elenco.

Tali elenchi specifici degli Stati membri possono essere adattati nel formato per il proprio contesto nazionale. Pertanto il formato di file di questo elenco di fiducia può variare; ad esempio può trattarsi di un formato JWKS firmato (formato JWK Set per RFC 7517 [11], sezione 5) o di qualsiasi altro formato specifico per la tecnologia utilizzata in tale Stato membro.

Al fine di garantire la semplicità, gli Stati membri possono presentare i loro certificati CSCA esistenti generati dai rispettivi sistemi eMRTD conformi ICAO o, come raccomandato dall'OMS, crearne uno specifico per questo settore sanitario.

8.1. Identificativo della chiave (kid)

L'identificativo della chiave (kid) è calcolato quando si costruisce l'elenco delle chiavi pubbliche fidate dei DSC ed è costituito da un'impronta digitale SHA-256 troncata (primi 8 byte) del DSC codificato nel formato (grezzo) DER.

I verificatori non sono tenuti a calcolare l'identificativo della chiave sulla base del DSC e possono far collimare direttamente l'identificativo della chiave nel certificato sanitario rilasciato con quello figurante nell'elenco di fiducia.

8.2. Differenze rispetto al modello di fiducia dell'infrastruttura a chiave pubblica eMRTD conforme ICAO

Nonostante la modellizzazione sulle migliori pratiche del modello di fiducia dell'infrastruttura a chiave pubblica (Public Key Infrastructure - PKI) eMRTD conforme ICAO, è necessario introdurre una serie di semplificazioni nell'interesse della velocità:

- uno Stato membro può presentare più certificati CSCA;

- il periodo di validità del DSC (utilizzo della chiave) può essere fissato a una durata non superiore a quella del certificato CSCA e può essere assente;

- il DSC può contenere identificativi di policy (utilizzo esteso della chiave) specifici dei certificati sanitari;

- gli Stati membri possono scegliere di non effettuare mai alcuna verifica delle revoche pubblicate e di affidarsi esclusivamente agli elenchi di DSC che ricevono quotidianamente dal segretariato o che compilano essi stessi.

9. SOLUZIONE DI REVOCA

9.1. Fornitura dell'elenco dei certificati COVID digitali revocati (DRL - DCC Revocation List)

Il gateway fornisce le funzionalità e gli endpoint per conservare e gestire gli elenchi dei certificati revocati:

9.2. Modello di fiducia

Tutte le connessioni sono stabilite dal modello di fiducia standard del DCCG mediante i certificati NBTLS e NBUP (cfr. governance dei certificati). Tutte le informazioni sono suddivise in pacchetti e caricate mediante messaggi CMS per garantirne l'integrità.

9.3. Costruzione dei batch (lotti)

9.3.1. Batch

Ogni elenco dei certificati revocati contiene una o più voci ed è raggruppato in batch contenenti una serie di hash e i relativi metadati. Un batch è immutabile e definisce una data di scadenza che indica quando il batch può essere cancellato. La data di scadenza di tutti gli elementi del batch deve essere esattamente la stessa, il che significa che i batch devono essere raggruppati per data di scadenza e per DSC di firma. Ciascun batch contiene al massimo 1 000 voci. Se l'elenco dei certificati revocati comprende più di 1 000 voci, si creano più batch. Una voce può essere presente in al massimo un batch. Il batch è suddiviso in pacchetti in una struttura CMS e firmato dal certificato NBup del paese che lo carica.

9.3.2. Indice dei batch

Al momento della sua creazione il batch è automaticamente aggiunto all'indice e il gateway gli attribuisce un ID unico. L'indice dei batch è ordinato in base alla data di modifica, in ordine cronologico ascendente.

9.3.3. Comportamento del gateway

Il gateway tratta i batch di revoca senza modificarli: non può aggiornare, né rimuovere, né aggiungere informazioni ai batch. I batch sono inoltrati a tutti i paesi autorizzati (cfr. capo 9.6).

Il gateway osserva attivamente le date di scadenza dei batch ed elimina i batch scaduti. Dopo la cancellazione del batch, il gateway invia una risposta «HTTP 410 Gone» per l'URL del batch cancellato. Pertanto il batch figura nell'indice dei batch come «deleted» («cancellato»).

9.4. Tipi di hash

L'elenco dei certificati revocati contiene hash che possono rappresentare diversi tipi/attributi di revoca. Tali tipi o attributi sono indicati al momento della fornitura degli elenchi dei certificati revocati. I tipi attuali sono:

.

Solo i primi 128 bit degli hash codificati come stringhe in base64 sono inseriti nei batch e utilizzati per identificare il DCC revocato [12].

9.4.1. Tipo di hash: SHA256(DCC Signature)

In questo caso l'hash è calcolato sui byte della firma COSE_SIGN1 dal CWT. Per le firme RSA l'intera firma sarà usata come input. La formula per i certificati firmati con EC-DSA utilizza il valore r come input:

SHA256(r)

[necessario per tutte le nuove implementazioni]

9.4.2. Tipo di hash: SHA256(UCI)

In questo caso l'hash è calcolato sulla stringa UCI codificata in UTF-8 e convertita in un array di byte.

[deprecato [13], ma supportato per motivi di retrocompatibilità]

9.4.3. Tipo di hash: SHA256(Issuing CountryCode+UCI)

In questo caso il CountryCode codificato come stringa UTF-8 è concatenato con l'UCI codificato con una stringa UTF-8. Esso è quindi convertito in array di byte e utilizzato come input della funzione di hash.

[deprecato², ma supportato per motivi di retrocompatibilità]

9.5. Struttura API

9.5.1. API per la fornitura delle voci di revoca

9.5.1.1. Finalità

Le voci dell'elenco dei certificati revocati sono fornite dall'API in batch comprendenti un indice dei batch.

9.5.1.2. Endpoint

9.5.1.2.1. Endpoint di scaricamento dell'elenco dei batch

Gli endpoint sono di semplice concezione e restituiscono un elenco di batch insieme a un piccolo wrapper che fornisce i metadati. I batch sono ordinati per data in ordine (cronologico) ascendente:

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array 

{ 

"more":true|false, 

"batches": 

[{ 

"batchId": "{uuid}", 

"country": "XY", 

"date": "2021-11-01T00:00:00Z" 

"deleted": true | false 

},.. 

] 

}

Nota: Il risultato è limitato a 1 000 per impostazione predefinita. Se il flag «more» è impostato su «true», la risposta indica che sono disponibili più batch per lo scaricamento. Per scaricare più elementi, il client deve impostare nell'intestazione (header) If-Modified-Since una data non anteriore all'ultima voce ricevuta.

La risposta contiene un array JSON con la seguente struttura:

.

9.5.1.2.1.1. Codici di risposta

.

Intestazione della richiesta

.

9.5.1.2.2. Endpoint di scaricamento dei batch

I batch contengono un elenco degli identificativi dei certificati:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content 

{ 

"country": "XY", 

"expires": "2022-11-01T00:00:00Z", 

"kid":"23S+33f=", 

"hashType":"SIGNATURE", 

"entries":[{ 

"hash":"e2e2e2e2e2e2e2e2" 

},..] 

}

La risposta contiene un CMS che comprende una firma che deve corrispondere al certificato NBUP del paese. Tutti gli elementi nell'array JSON presentano la seguente struttura:

.

- I batch sono raggruppati per data di scadenza e DSC: tutti gli elementi scadono contemporaneamente e sono stati firmati con la stessa chiave.

- Il termine di scadenza è espresso da data/ora UTC perché l'EU-DCC è un sistema globale e non devono esserci ambiguità temporali.

- La data di scadenza di un DCC revocato in via permanente è fissata alla data di scadenza del corrispondente DSC utilizzato per firmare il DCC o al Termine di scadenza del DCC revocato (nel qual caso si considera che gli orari indicati in NumericDate/epoch siano nel fuso orario UTC).

- Il back-end nazionale (NB) elimina gli elementi dall'elenco dei certificati revocati una volta raggiunta la data di scadenza.

- L'NB può rimuovere elementi dall'elenco dei certificati revocati nel caso in cui il kid usato per firmare il DCC sia revocato.

9.5.1.2.2.1. Voci

.

Nota: l'oggetto delle voci contiene attualmente solo un hash, ma per essere compatibile con le modifiche future è stato scelto un oggetto invece di un array json.

9.5.1.2.2.2. Codici di risposta

.

9.5.1.2.2.3. Intestazioni della risposta

.

9.5.1.2.3. Endpoint di caricamento dei batch

Il caricamento è effettuato sullo stesso endpoint tramite una richiesta POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content: 

{ 

"country": "XY", 

"expires": "2022-11-01T00:00:00Z", 

"kid":"23S+33f=", 

"hashType":"SIGNATURE", 

"entries":[{ 

"hash":"e2e2e2e2e2e2e2e2" 

},..] 

}

Il batch viene firmato utilizzando il certificato NBUP. Il gateway verifica che la firma sia stata impostata dall"NBUP per il paese in questione. Se il controllo della firma non dà esito positivo, il caricamento non va a buon fine.

NOTA: ogni batch è immutabile e non può essere modificato dopo il caricamento. Esso può tuttavia essere cancellato. Viene memorizzato l'ID di ogni batch cancellato e viene rifiutato il caricamento di un nuovo batch con lo stesso identificativo.

9.5.1.2.4. Endpoint di cancellazione dei batch

Un batch può essere cancellato sullo stesso endpoint tramite richiesta DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

{ 

"batchId": "..." 

}

oppure, per motivi di compatibilità, al seguente endpoint con richiesta POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content: 

{ 

"batchId": "..." 

}

9.6. Protezione API/GDPR

La presente sezione specifica le misure di attuazione per conformarsi alle disposizioni del regolamento 2021/953 per quanto riguarda il trattamento dei dati personali.

9.6.1. Autenticazione esistente

Attualmente il gateway utilizza il certificato NBTLS per autenticare i paesi collegati al gateway. Tale autenticazione può essere utilizzata per determinare l'identità del paese collegato al gateway. Tale identità può quindi essere utilizzata per implementare il controllo degli accessi.

9.6.2. Controllo degli accessi

Per poter trattare i dati personali lecitamente, il gateway implementa un meccanismo di controllo degli accessi.

Il gateway implementa un elenco di controllo degli accessi combinato con la sicurezza basata sui ruoli. Tale schema prevede il mantenimento di due tabelle: una tabella descrive quali Ruoli possono applicare quali Operazioni a quali Risorse, mentre un'altra tabella descrive quali Ruoli sono assegnati a quali Utenti.

Al fine di implementare i controlli richiesti dal presente documento, sono necessari tre Ruoli, ossia: 

RevocationListReader 

RevocationUploader 

RevocationDeleter

I seguenti endpoint verificano se l'Utente (User) ha il Ruolo (Role) RevocationListReader; se sì, l'accesso viene concesso, in caso contrario viene restituita una risposta HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

I seguenti endpoint verificano se l'Utente ha il Ruolo RevocationUploader; se sì, l'accesso viene concesso, in caso contrario viene restituita una risposta HTTP 403 Forbidden:

POST/revocation-list

I seguenti endpoint verificano se l'Utente ha il Ruolo RevocationDeleter; se sì, l'accesso viene concesso, in caso contrario viene restituita una risposta HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Il gateway fornisce inoltre un metodo affidabile mediante il quale gli amministratori possono gestire i Ruoli collegati agli Utenti in modo da ridurre la probabilità di errori umani senza gravare sugli amministratori funzionali.

________________

[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] Regolamento (UE) 2021/953 del Parlamento europeo e del Consiglio, del 14 giugno 2021, su un quadro per il rilascio, la verifica e l'accettazione di certificati interoperabili di vaccinazione, di test e di guarigione in relazione alla COVID-19 (certificato COVID digitale dell'UE) per agevolare la libera circolazione delle persone durante la pandemia di COVID-19 (GU L 211 del 15.6.2021).

[9] rfc1950 (ietf.org).

[10] rfc1951 (ietf.org).

[11] rfc7517 (ietf.org).

[12] Cfr. anche il punto 9.5.1.2 per le descrizioni dettagliate dell'API.

[13] Deprecato significa che questa caratteristica non è presa in considerazione per le nuove implementazioni, ma è supportata per le quelle esistenti per un periodo di tempo ben definito. 

(sostituito dall'art. 1 della Dec. (UE) 2021/2014, modificato dall'art. 1 della Dec. (UE) 2021/2301 e modificato e integrato dall'art. 1 della Dec. (UE) 2022/1516)

NORME PER LA COMPILAZIONE DEL CERTIFICATO COVID DIGITALE DELL'UE

Le norme generali relative alle serie di valori stabilite nel presente allegato mirano a garantire l'interoperabilità a livello semantico e consentono implementazioni tecniche uniformi per il certificato COVID digitale dell'UE. Gli elementi contenuti nel presente allegato possono essere utilizzati per i tre diversi scenari (vaccinazione/test/guarigione) previsti dal regolamento (UE) 2021/953. Nel presente allegato sono elencati solo gli elementi che richiedono una standardizzazione semantica mediante serie di valori codificati.

La traduzione degli elementi codificati nella lingua nazionale è di competenza degli Stati membri.

Per tutti i campi di dati non menzionati nelle seguenti descrizioni delle serie di valori, la codifica è descritta nell'allegato V.

Se per qualsiasi motivo non è possibile utilizzare i sistemi di codici preferiti elencati di seguito, possono essere utilizzati altri sistemi di codici internazionali e sono predisposti suggerimenti su come mappare i codici dell'altro sistema di codici al sistema di codici preferito. Il testo (nomi visualizzati) può essere utilizzato in casi eccezionali come meccanismo di backup quando nelle serie di valori definite non è disponibile un codice adeguato.

Gli Stati membri che utilizzano altri codici nei loro sistemi mappano tali codici alle serie di valori descritte. Gli Stati membri sono responsabili di tali mappature.

Poiché alcune serie di valori basate sui sistemi di codifica di cui al presente allegato, come quelle per la codifica dei vaccini e dei test antigenici, cambiano spesso, esse sono pubblicate e aggiornate regolarmente dalla Commissione con il sostegno della rete eHealth e del comitato per la sicurezza sanitaria. Le serie di valori aggiornate sono pubblicate sul pertinente sito web della Commissione e sulla pagina web della rete eHealth. E' fornita una cronologia delle modifiche.

1. Malattia o agente in questione/malattia o agente da cui il titolare è guarito: COVID-19 (SARS-CoV-2 o una delle sue varianti)

Da utilizzare nei certificati 1, 2 e 3.

Deve essere utilizzato il codice seguente:

.

2. Vaccino o profilassi anti COVID-19

Sistema di codici preferito: SNOMED CT o classificazione ATC.

Da utilizzare nel certificato 1.

Esempi di codici da utilizzare, tratti dai sistemi di codici preferiti, sono il codice SNOMED CT 1119305005 (vaccino antigenico contro il SARS-CoV-2), 1119349007 (vaccino a mRNA contro il SARS-CoV-2) o J07BX03 (vaccini anti COVID-19).

La Commissione pubblica e aggiorna regolarmente, con il sostegno della rete eHealth, una serie di valori che fissa i codici da utilizzare conformemente ai sistemi di codici stabiliti nella presente sezione. La serie di valori sarà estesa man mano che vengono sviluppati e messi in uso nuovi tipi di vaccini.

3. Medicinale vaccinale anti COVID-19

Sistemi di codici preferiti (in ordine di preferenza):

- registro dell'Unione dei medicinali per i vaccini con autorizzazione a livello dell'UE (numeri di autorizzazione);

- un registro globale dei vaccini come quello che potrebbe essere istituito dall'Organizzazione mondiale della sanità;

- nome del medicinale vaccinale negli altri casi. Se il nome comprende spazi vuoti, questi devono essere sostituiti da un trattino (-).

Nome della serie di valori: vaccino.

Da utilizzare nel certificato 1.

Un esempio di codice da utilizzare, tratto dai sistemi di codici preferiti, è EU/1/20/1528 (Comirnaty). Esempio di nome del vaccino da utilizzare come codice: Sputnik-V (che sta per Sputnik V).

La Commissione pubblica e aggiorna regolarmente, con il sostegno della rete eHealth, una serie di valori che fissa i codici da utilizzare conformemente ai sistemi di codici stabiliti nella presente sezione.

I vaccini sono codificati utilizzando un codice esistente nella serie di valori pubblicata, anche se i loro nomi sono diversi nei vari paesi. Il motivo è che non esiste ancora un registro globale dei vaccini che copra tutti i vaccini attualmente in uso. Esempio:

- per il vaccino "COVID-19 Vaccine Moderna Intramuscular Injection", che è il nome del vaccino Spikevax in Giappone, utilizzare il codice EU/1/20/1507, che corrisponde al nome di tale vaccino nell'UE.

Qualora ciò non sia possibile o consigliabile in un caso specifico, sarà fornito un codice distinto nella serie di valori pubblicata.

Se un paese che utilizza il certificato COVID digitale dell'UE ("EU DCC") decide di rilasciare certificati di vaccinazione ai partecipanti a sperimentazioni cliniche durante le sperimentazioni cliniche in corso, il medicinale vaccinale è codificato secondo il modello

CT_clinical-trial-identifier

Se la sperimentazione clinica è stata registrata nel registro UE delle sperimentazioni cliniche (EU-CTR), si utilizza l'identificativo della sperimentazione clinica di tale registro. Negli altri casi possono essere utilizzati gli identificativi degli altri registri (ad esempio clinicaltrials.gov o Australian New Zealand Clinical Trials Registry).

L'identificativo della sperimentazione clinica comprende un prefisso che corrisponde al registro delle sperimentazioni cliniche (ad esempio EUCTR per il registro UE delle sperimentazioni cliniche, NCT per clinicaltrials.gov, ACTRN per l'Australian New Zealand Clinical Trials Registry).

Qualora la Commissione abbia ricevuto orientamenti dal comitato per la sicurezza sanitaria, dal Centro europeo per la prevenzione e il controllo delle malattie (ECDC) o dall'Agenzia europea per i medicinali (EMA) in merito all'accettazione dei certificati rilasciati per un vaccino anti COVID-19 in fase di sperimentazione clinica, tali orientamenti sono pubblicati come parte del documento della serie di valori o separatamente.

4. Titolare dell'autorizzazione all'immissione in commercio del vaccino anti COVID-19 o fabbricante del vaccino

Sistema di codici preferito:

- codice organismo dell'EMA (sistema SPOR per ISO IDMP);

- un registro globale dei titolari dell'autorizzazione all'immissione in commercio dei vaccini o dei fabbricanti dei vaccini, come quello che potrebbe essere istituito dall'Organizzazione mondiale della sanità;

- nome dell'organismo negli altri casi. Se il nome comprende spazi vuoti, questi devono essere sostituiti da un trattino (-).

Da utilizzare nel certificato 1.

Un esempio di codice da utilizzare, tratto dal sistema di codici preferito, è ORG-100001699 (AstraZeneca AB). Esempio di nome dell'organismo da utilizzare come codice: Sinovac-Biotech (che sta per Sinovac Biotech).

La Commissione pubblica e aggiorna regolarmente, con il sostegno della rete eHealth, una serie di valori che fissa i codici da utilizzare conformemente ai sistemi di codici stabiliti nella presente sezione.

Succursali diverse dello stesso titolare dell'autorizzazione all'immissione in commercio o dello stesso fabbricante devono utilizzare un codice esistente nella serie di valori pubblicata.

Come regola generale, per lo stesso prodotto vaccinale è utilizzato il codice che si riferisce al titolare dell'autorizzazione all'immissione in commercio nell'UE, in quanto non esiste ancora un registro del fabbricante o del titolare dell'autorizzazione all'immissione in commercio concordato a livello internazionale per i vaccini. Esempi:

- per l'organizzazione "Pfizer AG", che è il titolare dell'autorizzazione all'immissione in commercio del vaccino "Comirnaty" utilizzato in Svizzera, utilizzare il codice ORG-100030215 che fa riferimento a BioNTech Manufacturing GmbH, che corrisponde al titolare dell'autorizzazione all'immissione in commercio di Comirnaty nell'UE;

- per l'organizzazione "Zuellig Pharma", che è il titolare dell'autorizzazione all'immissione in commercio del vaccino "Covid-19 Vaccine Moderna (Spikevax)" utilizzato nelle Filippine, utilizzare il codice ORG-100031184 che fa riferimento a Moderna Biotech Spain S.L., che corrisponde al titolare dell'autorizzazione all'immissione in commercio di Spikevax nell'UE.

Qualora ciò non sia possibile o consigliabile in un caso specifico, sarà fornito un codice distinto nella serie di valori pubblicata.

Se un paese che utilizza l'EU DCC decide di rilasciare certificati di vaccinazione ai partecipanti a sperimentazioni cliniche durante le sperimentazioni cliniche in corso, il titolare dell'autorizzazione all'immissione in commercio del vaccino o fabbricante del vaccino è codificato utilizzando il valore per esso designato nella serie di valori, se disponibile. Negli altri casi, il titolare dell'autorizzazione all'immissione in commercio del vaccino o fabbricante del vaccino è codificato utilizzando la regola descritta alla sezione 3, Medicinale vaccinale [(CT_clinical-trial-identifier).

5. Numero in una serie di dosi e numero complessivo di dosi di una serie

Da utilizzare nel certificato 1.

Due campi:

1) numero in una serie di dosi di vaccino di un vaccino anti COVID-19 (N);

2) numero complessivo di dosi di una serie di vaccinazione (C).

5.1. Serie di vaccinazione primaria

Se la persona riceve dosi della serie di vaccinazione primaria, ovvero la serie di vaccinazione destinata a fornire sufficiente protezione nella fase iniziale, (C) rispecchia il numero complessivo di dosi della serie di vaccinazione primaria standard (ad esempio 1 o 2, a seconda del tipo di vaccino somministrato). Ciò include la possibilità di utilizzare una serie più breve (C = 1) se il protocollo di vaccinazione applicato da uno Stato membro prevede la somministrazione di un'unica dose di un vaccino bidose a persone che sono state precedentemente infettate da SARS-CoV-2. Una serie completa di vaccinazione primaria è quindi indicata con N/C = 1. Ad esempio:

- 1/1 indica il completamento di un ciclo di vaccinazione primaria monodose o il completamento di un ciclo di vaccinazione primaria consistente in una dose di un vaccino bidose somministrata a una persona guarita in linea con il protocollo di vaccinazione applicato da uno Stato membro;

- 2/2 indica il completamento di una serie di vaccinazione primaria che prevede due dosi.

Se la serie di vaccinazione primaria viene estesa, ad esempio per le persone con sistema immunitario fortemente indebolito, o se non è stato rispettato l'intervallo raccomandato tra le dosi primarie, qualsiasi siffatta dose è codificata come dose aggiuntiva rientrante nella sezione 5.2.

5.2. Dosi di richiamo

Se la persona riceve dosi di richiamo successivamente al ciclo di vaccinazione primario, tali dosi sono indicate nei certificati corrispondenti come segue:

- 2/1 indica la somministrazione di una dose di richiamo successivamente a un ciclo di vaccinazione primario monodose, o la somministrazione di una dose di richiamo dopo il completamento di un ciclo di vaccinazione primario consistente in una dose di un vaccino bidose somministrata a una persona guarita in linea con il protocollo di vaccinazione applicato da uno Stato membro. In seguito, le dosi (X) somministrate dopo la prima dose di richiamo sono indicate con (2 + X)/(1) > 1 (ad esempio 3/1);

- 3/3 indica la somministrazione di una dose di richiamo successivamente a un ciclo di vaccinazione primario bidose. In seguito, le dosi (X) somministrate dopo la prima dose di richiamo sono indicate con (3 + X)/(3 + X) = 1 (ad esempio 4/4).

Gli Stati membri applicano le regole di codifica di cui alla presente sezione entro il 1° febbraio 2022.

Gli Stati membri rilasciano nuovamente, automaticamente o su richiesta delle persone interessate, i certificati in cui la somministrazione di una dose di richiamo successivamente a un ciclo di vaccinazione primario monodose sia codificata in modo tale da non poter essere distinta dal completamento del ciclo di vaccinazione primario.

Ai fini del presente allegato, i riferimenti alle "dosi di richiamo" riguardano anche le dosi addizionali somministrate per proteggere meglio le persone che sviluppano una risposta immunitaria inadeguata dopo il completamento del ciclo di vaccinazione primario standard. Nell'ambito del quadro giuridico istituito dal regolamento (UE) 2021/953, gli Stati membri possono adottare misure per affrontare la situazione dei gruppi vulnerabili che possono ricevere dosi addizionali in via prioritaria. Ad esempio, se uno Stato membro decide di somministrare dosi addizionali solo a sottogruppi specifici della popolazione, può scegliere, a norma dell'articolo 5, paragrafo 1, del regolamento (UE) 2021/953, di rilasciare certificati di vaccinazione comprovanti la somministrazione di tali dosi addizionali solo su richiesta e non automaticamente. Nel caso in cui vengano adottate tali misure, gli Stati membri informano gli interessati al riguardo e del fatto che possono continuare ad utilizzare il certificato ricevuto dopo il completamento del ciclo di vaccinazione primario standard.

6. Stato membro o paese terzo in cui è stato somministrato il vaccino/effettuato il test

Sistema di codici preferito: codici paese secondo la norma ISO 3166.

Da utilizzare nei certificati 1, 2 e 3.

Contenuto della serie di valori: l'elenco completo dei codici a due lettere, disponibile come serie di valori secondo la definizione in FHIR (http://hl7.org/fhir/ValueSet/iso3166-1-2). Se la vaccinazione o il test sono stati effettuati da un'organizzazione internazionale (come l'UNHCR o l'OMS) e non sono disponibili informazioni sul paese, è utilizzato un codice per l'organizzazione. La Commissione, con il sostegno della rete eHealth, pubblica e aggiorna periodicamente tali codici aggiuntivi.

7. Tipo di test

Da utilizzare nel certificato 2, e nel certificato 3 qualora mediante un atto delegato sia introdotto il sostegno per il rilascio di certificati di guarigione basati su tipi di test diversi dai test di amplificazione dell'acido nucleico (NAAT).

Devono essere utilizzati i codici seguenti:

.

Il codice LP217198-3 (immunodosaggio rapido) deve essere utilizzato per indicare sia i test antigenici rapidi sia i saggi antigenici di laboratorio.

8. Fabbricante e denominazione commerciale del test utilizzato (facoltativo per i test NAAT)

Da utilizzare nel certificato 2.

Il contenuto della serie di valori comprende la selezione del test antigenico elencato nell'elenco comune e aggiornato dei test antigenici per la COVID-19, stabilito sulla base della raccomandazione 2021/C 24/01 del Consiglio e approvato dal comitato per la sicurezza sanitaria. L'elenco è tenuto dal JRC nella banca dati dei dispositivi diagnostici in vitro e dei metodi di test COVID-19 all'indirizzo seguente: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat. L'elenco è tenuto dal JRC nella banca dati dei dispositivi diagnostici in vitro e dei metodi di test COVID-19 all'indirizzo seguente: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

Per questo sistema di codici devono essere utilizzati campi pertinenti quali l'identificativo del dispositivo diagnostico, il nome del test e il fabbricante, secondo il formato strutturato del JRC disponibile all'indirizzo: https://covid-19-diagnostics.jrc.ec.europa.eu/devices.

9. Risultato del test

Da utilizzare nel certificato 2.

Devono essere utilizzati i codici seguenti:

.

(modificato dall'art. 1 della Dec. (UE) 2021/2014)

STRUTTURA COMUNE DELL'IDENTIFICATIVO UNIVOCO DEL CERTIFICATO

1. Introduzione

Ciascun certificato COVID digitale dell'UE (DCC) include un identificativo univoco del certificato (Unique Certificate Identifier - UCI) che sostiene l'interoperabilità dei DCC. L'UCI può essere utilizzato per verificare il certificato. Gli Stati membri sono responsabili della sua attuazione. L'UCI è un mezzo per verificare la veridicità del certificato e, se del caso, per collegarsi a un sistema di registrazione (ad esempio, un sistema informativo sulla vaccinazione). Questi identificativi consentono inoltre agli Stati membri di affermare (su supporto cartaceo e digitale) che le persone sono state vaccinate o sottoposte a test.

2. Composizione dell'identificativo univoco del certificato

L'UCI segue una struttura e un formato comuni che agevolano l'interpretazione delle informazioni da parte dell'uomo e/o della macchina e può riguardare elementi quali lo Stato membro di vaccinazione, il vaccino stesso e l'identificativo specifico di uno Stato membro. Garantisce agli Stati membri la flessibilità necessaria per la sua formattazione, nel pieno rispetto della legislazione in materia di protezione dei dati. L'ordine dei distinti elementi segue una gerarchia definita che può consentire future modifiche dei blocchi, mantenendone nel contempo l'integrità strutturale.

Le possibili soluzioni per la composizione dell'UCI formano uno spettro in cui la modularità e l'interpretabilità da parte dell'uomo costituiscono i due principali parametri di diversificazione e una caratteristica fondamentale:

- modularità: la misura in cui il codice è composto da blocchi costitutivi distinti che contengono informazioni semanticamente diverse;

- interpretabilità da parte dell'uomo: la misura in cui il codice è significativo o può essere interpretato da un lettore umano;

- univocità a livello mondiale: l'identificativo del paese o dell'autorità è ben gestito e ogni paese (autorità) è tenuto a gestire adeguatamente il proprio segmento nello spazio dei nomi senza riciclare o riemettere gli identificativi. Questa combinazione garantisce che ciascun identificativo sia univoco a livello mondiale.

3. Requisiti generali

In relazione all'UCI sono soddisfatti i requisiti generali seguenti:

1) serie di caratteri: sono ammessi solo caratteri alfanumerici US-ASCII maiuscoli (da "A" a "Z", da "0" a "9"), con caratteri speciali aggiuntivi per la separazione da RFC3986 [*1], vale a dire {'/','#',':'};

2) lunghezza massima: i programmatori cercano di rispettare una lunghezza di 27-30 caratteri [*2];

3) prefisso della versione: si riferisce alla versione dello schema UCI. Il prefisso della versione è "01" per questa versione del documento ed è composto da due cifre;

4) prefisso del paese: il codice paese è specificato dalla norma ISO 3166-1. Codici più lunghi (ad esempio tre e più caratteri come nel caso di "UNHCR") sono riservati all'uso futuro;

5) suffisso del codice/somma di controllo:

5.1 gli Stati membri possono utilizzare una somma di controllo quando è probabile che si verifichino la trasmissione, la trascrizione (umana) o altre forme di corruzione (vale a dire l'utilizzo in forma stampata);

5.2 la somma di controllo non deve essere utilizzata per convalidare il certificato e non fa tecnicamente parte dell'identificativo, bensì è utilizzata per verificare l'integrità del codice. Tale somma di controllo è la sintesi secondo la norma ISO 7812-1 (LUHN-10) [*3] dell'intero UCI in formato di trasporto digitale/elettronico. La somma di controllo è separata dal resto dell'UCI da un carattere "#".

Occorre garantire la retrocompatibilità: gli Stati membri che nel corso del tempo modificano la struttura dei loro identificativi (nella versione principale, attualmente fissata a v1) sono tenuti a garantire che due identificativi identici rappresentino la stessa dichiarazione/lo stesso certificato di vaccinazione. In altre parole, gli Stati membri non possono riciclare gli identificativi.

4. Opzioni per gli identificativi univoci dei certificati per i certificati di vaccinazione

Gli orientamenti della rete eHealth per i certificati di vaccinazione verificabili e gli elementi fondamentali di interoperabilità [5] prevedono diverse opzioni a disposizione degli Stati membri e di altre parti che possono coesistere tra i diversi Stati membri. Gli Stati membri possono utilizzare tali diverse opzioni in versioni diverse dello schema UCI.

________________

[1] rfc3986 (ietf.org).

[2] Campi quali il genere, il numero di lotto, il centro di somministrazione, l'identificazione dell'operatore sanitario, la data della prossima vaccinazione possono non essere necessari per scopi diversi dall'uso medico.

[3] Per l'implementazione con codici QR, gli Stati membri potrebbero prendere in considerazione la possibilità di utilizzare una serie supplementare di caratteri fino a una lunghezza totale di 72 caratteri (compresi i 27-30 caratteri dell'identificativo stesso) per trasmettere altre informazioni. Spetta agli Stati membri definire la specifica di tali informazioni.

[4] L'algoritmo di Luhn mod N è un'estensione dell'algoritmo di Luhn (noto anche come algoritmo mod 10) che funziona per i codici numerici ed è utilizzato ad esempio per calcolare la somma di controllo delle carte di credito. L'estensione consente all'algoritmo di funzionare con sequenze di valori su qualsiasi base (nel nostro caso caratteri alfa).

[5] https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf.

[*1] rfc3986 (ietf.org)

[*2] Per l'implementazione con codici QR, gli Stati membri potrebbero prendere in considerazione la possibilità di utilizzare una serie supplementare di caratteri fino a una lunghezza totale di 72 caratteri (compresi i 27-30 caratteri dell'identificativo stesso) per trasmettere altre informazioni. Spetta agli Stati membri definire la specifica di tali informazioni.

[*3] L'algoritmo di Luhn mod N è un'estensione dell'algoritmo di Luhn (noto anche come algoritmo mod 10) che funziona per i codici numerici ed è utilizzato ad esempio per calcolare la somma di controllo delle carte di credito. L'estensione consente all'algoritmo di funzionare con sequenze di valori su qualsiasi base (nel nostro caso caratteri alfa).

GOVERNANCE DEI CERTIFICATI A CHIAVE PUBBLICA

1. Introduzione

Lo scambio sicuro e fidato delle chiavi di firma per i certificati COVID digitali dell'UE (DCC) tra gli Stati membri è realizzato dal gateway per i certificati COVID digitali dell'UE (Digital COVID Certificate Gateway - DCCG), che funge da archivio centrale per le chiavi pubbliche. Con il DCCG, gli Stati membri sono abilitati a pubblicare le chiavi pubbliche corrispondenti alle chiavi private che utilizzano per firmare i certificati COVID digitali. Gli Stati membri che se ne avvalgono possono utilizzare il DCCG per estrarre in tempo utile materiale aggiornato relativo alle chiavi pubbliche. Successivamente, il DCCG potrà essere esteso allo scambio di informazioni supplementari affidabili fornite dagli Stati membri, come le norme di convalida per i DCC. Il modello di fiducia del quadro DCC è un'infrastruttura a chiave pubblica (PKI). Ciascuno Stato membro mantiene una o più autorità nazionali di certificazione (CSCA) i cui certificati hanno una durata di vita relativamente lunga. A seguito della decisione dello Stato membro, la CSCA può essere uguale o diversa dalla CSCA utilizzata per i documenti di viaggio leggibili a macchina. La CSCA rilascia certificati a chiave pubblica per i firmatari di documenti nazionali di breve durata (ossia i firmatari dei DCC), denominati certificati di firma digitale (DSC). La CSCA agisce come un'ancora di fiducia in modo che gli Stati membri che se ne avvalgono possano utilizzare il certificato CSCA per convalidare l'autenticità e l'integrità dei DSC che cambiano regolarmente. Una volta effettuata la convalida, gli Stati membri possono fornire tali certificati (o solo le chiavi pubbliche in essi contenute) alle loro applicazioni di convalida dei DCC. Oltre alle CSCA e ai DSC, il DCCG si avvale anche della PKI per autenticare le transazioni, firmare i dati, come base per l'autenticazione e come mezzo per garantire l'integrità dei canali di comunicazione tra gli Stati membri e il DCCG.

Le firme digitali possono essere utilizzate per garantire l'integrità e l'autenticità dei dati. Le infrastrutture a chiave pubblica creano fiducia legando le chiavi pubbliche a identità verificate (o emittenti). Ciò è necessario per consentire agli altri partecipanti di verificare l'origine dei dati e l'identità del partner della comunicazione e di decidere in merito alla fiducia. Per l'autenticità, nel DCCG sono utilizzati diversi certificati a chiave pubblica. Il presente allegato definisce quali certificati a chiave pubblica sono utilizzati e come devono essere concepiti al fine di consentire un'ampia interoperabilità tra gli Stati membri. Esso fornisce maggiori dettagli sui necessari certificati a chiave pubblica, nonché orientamenti sui modelli di certificato e sui periodi di validità per gli Stati membri che intendono gestire una propria CSCA. Poiché i DCC devono essere verificabili per un periodo di tempo definito (a partire dal rilascio, scadono dopo un determinato periodo di tempo), è necessario definire un modello di verifica per tutte le firme applicate sui certificati a chiave pubblica e sui DCC.

2. Terminologia

La tabella seguente riporta le abbreviazioni e la terminologia utilizzate in tutto il presente allegato.

.

3. Flussi di comunicazione e servizi di sicurezza DCCG

Questa sezione fornisce una panoramica dei flussi di comunicazione e dei servizi di sicurezza nel sistema DCCG. Definisce inoltre quali chiavi e certificati sono utilizzati per proteggere la comunicazione, le informazioni caricate, i DCC e un elenco di fiducia firmato contenente tutti i certificati CSCA di cui è stato effettuato l'on-boarding. Il DCCG funge da hub di dati che consente lo scambio di pacchetti di dati firmati per gli Stati membri.

I pacchetti di dati caricati sono forniti dal DCCG «tal quali», il che significa che il DCCG non aggiunge né cancella i DSC dai pacchetti ricevuti. Il back-end nazionale (NB) degli Stati membri è abilitato a verificare l'integrità e l'autenticità end-to-end dei dati caricati. Inoltre i back-end nazionali e il DCCG utilizzeranno l'autenticazione TLS reciproca per stabilire una connessione sicura in aggiunta alle firme contenute nei dati scambiati.

3.1. Autenticazione e creazione di connessioni

Il DCCG utilizza il protocollo Transport Layer Security (TLS) con autenticazione reciproca per stabilire un canale criptato autenticato tra il back-end nazionale (NB) dello Stato membro e l'ambiente gateway. Pertanto il DCCG detiene un certificato del server TLS, abbreviato DCCG_TLS, mentre i back-end nazionali detengono un certificato del client TLS, abbreviato NB_TLS. I modelli di certificato sono forniti nella sezione 5. Ogni back-end nazionale può fornire il proprio certificato TLS. Tale certificato sarà esplicitamente inserito in una lista bianca e potrà quindi essere rilasciato da un'autorità di certificazione pubblicamente riconosciuta (ad esempio un'autorità di certificazione che segue i requisiti di base del CA/Browser Forum), da un'autorità nazionale di certificazione o potrà essere autofirmato. Ciascuno Stato membro è responsabile dei propri dati nazionali e della protezione della chiave privata utilizzata per stabilire la connessione con il DCCG. L'approccio «presenta il tuo certificato» richiede una procedura ben definita di registrazione e identificazione, nonché procedure di revoca e rinnovo come descritto nelle sezioni 4.1, 4.2 e 4.3. Il DCCG utilizza una lista bianca in cui vengono aggiunti i certificati TLS dei back-end nazionali dopo l'avvenuta registrazione. Solo i back-end nazionali che si autenticano con una chiave privata corrispondente a un certificato della lista bianca possono stabilire una connessione sicura con il DCCG. Il DCCG utilizzerà anche un certificato TLS che consenta ai back-end nazionali di verificare che stiano effettivamente stabilendo una connessione con il «vero» DCCG e non con qualche entità malevola che si fa passare per il DCCG. Il certificato del DCCG sarà fornito ai back-end nazionali una volta effettuata la registrazione. Il certificato DCCG_TLS sarà rilasciato da un'autorità di certificazione pubblicamente riconosciuta (anche in tutti i principali browser). Spetta agli Stati membri verificare che la loro connessione al DCCG sia sicura (ad esempio, controllando l'impronta digitale del certificato DCCG_TLS del server collegato rispetto a quella fornita dopo la registrazione).

3.2. Autorità nazionali di certificazione e modello di convalida

Gli Stati membri che partecipano al quadro DCCG sono tenuti ad avvalersi di una CSCA per il rilascio dei DSC. Gli Stati membri possono avere più di una CSCA, ad esempio in caso di decentramento regionale. Ciascuno Stato membro può avvalersi delle autorità di certificazione esistenti oppure istituire un'apposita autorità di certificazione (eventualmente autofirmata) per il sistema DCC.

Gli Stati membri devono presentare il certificato o i certificati CSCA all'operatore del DCCG durante la procedura ufficiale di on-boarding. Dopo l'avvenuta registrazione dello Stato membro (cfr. la sezione 4.1 per maggiori dettagli), l'operatore del DCCG aggiornerà un elenco di fiducia firmato contenente tutti i certificati CSCA attivi nel quadro del DCC. L'operatore del DCCG utilizzerà un'apposita coppia di chiavi asimmetriche per firmare l'elenco di fiducia e i certificati in ambiente off-line. La chiave privata non sarà memorizzata nel sistema DCCG on line per evitare che una compromissione del sistema on line consenta a un aggressore di compromettere l'elenco di fiducia. Il corrispondente certificato dell'ancora di fiducia DCCG_TA sarà fornito ai back-end nazionali durante la procedura di on-boarding.

Gli Stati membri possono recuperare l'elenco di fiducia dal DCCG per le loro procedure di verifica. La CSCA è definita come l'autorità di certificazione che rilascia i DSC, per cui gli Stati membri che utilizzano una gerarchia di autorità di certificazione a più livelli (ad esempio, autorità di certificazione radice -> CSCA -> DSC) devono indicare l'autorità di certificazione subordinata che rilascia i DSC. In questo caso, se uno Stato membro si avvale di un'autorità di certificazione esistente, il sistema DCC ignorerà tutto ciò che è al di sopra della CSCA e inserirà nella lista bianca solo la CSCA come ancora di fiducia (anche se si tratta di un'autorità di certificazione subordinata). Ciò è dovuto al fatto che nel modello ICAO sono consentiti solo 2 livelli: una CSCA «radice» e un DSC «foglia» firmato solo da tale CSCA.

Nel caso in cui uno Stato membro gestisca la propria CSCA, tale Stato membro è responsabile del funzionamento sicuro e della gestione delle chiavi di tale autorità. La CSCA funge da ancora di fiducia per i DSC e pertanto la protezione della chiave privata della CSCA è essenziale per l'integrità dell'ambiente DCC. Il modello di verifica nella PKI DCC è il modello a strati, in base al quale tutti i certificati nella convalida del percorso del certificato devono essere validi in un determinato momento (ossia al momento della convalida della firma). Si applicano pertanto le restrizioni seguenti:

- la CSCA non rilascia certificati con periodo di validità superiore a quello del certificato dell'autorità di certificazione stesso;

- il firmatario del documento non firma documenti con periodo di validità superiore a quello del DSC stesso;

- gli Stati membri che gestiscono la propria CSCA sono tenuti a definire i periodi di validità della loro CSCA e di tutti i certificati rilasciati e devono provvedere al loro rinnovo.

La sezione 4.2 contiene raccomandazioni per i periodi di validità.

3.3. Integrità e autenticità dei dati caricati

I back-end nazionali possono utilizzare il DCCG per caricare e scaricare pacchetti di dati firmati digitalmente dopo l'avvenuta autenticazione reciproca. All'inizio, questi pacchetti di dati contengono i DSC degli Stati membri. La coppia di chiavi utilizzata dal back-end nazionale per la firma digitale dei pacchetti di dati caricati nel sistema DCCG è denominata coppia di chiavi di firma per il caricamento da parte del back-end nazionale e il corrispondente certificato a chiave pubblica è abbreviato con certificato NB_UP. Ciascuno Stato membro presenta il proprio certificato NB_UP, che può essere autofirmato o rilasciato da un'autorità di certificazione esistente, come un'autorità pubblica di certificazione (ossia un'autorità di certificazione che rilascia certificati conformemente ai requisiti di base del CA/Browser Forum). Il certificato NB_UP è diverso da qualsiasi altro certificato utilizzato dallo Stato membro (ossia CSCA, client TLS o DSC).

Gli Stati membri devono fornire il certificato di caricamento all'operatore del DCCG durante la procedura di registrazione iniziale (cfr. la sezione 4.1 per maggiori dettagli). Ciascuno Stato membro è responsabile dei propri dati nazionali ed è tenuto a proteggere la chiave privata utilizzata per firmare i caricamenti.

Gli altri Stati membri possono verificare i pacchetti di dati firmati utilizzando i certificati di caricamento forniti dal DCCG. Il DCCG verifica l'autenticità e l'integrità dei dati caricati con il certificato di caricamento del back-end nazionale prima che siano forniti agli altri Stati membri.

3.4. Requisiti relativi all'architettura tecnica del DCCG

I requisiti relativi all'architettura tecnica del DCCG sono i seguenti:

- il DCCG utilizza l'autenticazione TLS reciproca per stabilire una connessione criptata autenticata con i back-end nazionali. Pertanto il DCCG tiene una lista bianca dei certificati del client NB_TLS registrati;

- il DCCG utilizza due certificati digitali (DCCG_TLS e DCCG_TA) con due coppie di chiavi distinte. La chiave privata della coppia di chiavi DCCG_TA è mantenuta off-line (non sulle componenti on line del DCCG);

- il DCCG tiene un elenco di fiducia dei certificati NB_CSCA firmati con la chiave privata DCCG_TA;

- le cifrature utilizzate devono soddisfare i requisiti della sezione 5.1.

4. Gestione del ciclo di vita del certificato

4.1. Registrazione dei back-end nazionali

Per partecipare al sistema DCCG, gli Stati membri devono registrarsi presso l'operatore del DCCG. Questa sezione descrive la procedura tecnica e operativa da seguire per registrare un back-end nazionale.

L'operatore del DCCG e lo Stato membro devono scambiarsi informazioni sui referenti tecnici per la procedura di on-boarding. Si presume che i referenti tecnici siano legittimati dai rispettivi Stati membri e che l'identificazione/autenticazione avvenga attraverso altri canali. Ad esempio, l'autenticazione può essere ottenuta quando il referente tecnico di uno Stato membro fornisce i certificati sotto forma di file criptati con password via e-mail e condivide la password corrispondente con l'operatore del DCCG per telefono. Possono essere utilizzati anche altri canali sicuri definiti dall'operatore del DCCG.

Lo Stato membro deve fornire tre certificati digitali durante il processo di registrazione e identificazione:

- il certificato TLS dello Stato membro NB_TLS;

- il certificato di caricamento dello Stato membro NB_UP;

- il certificato o i certificati CSCA dello Stato membro NB_CSCA.

Tutti i certificati forniti devono soddisfare i requisiti definiti nella sezione 5. L'operatore del DCCG verificherà che il certificato fornito sia conforme ai requisiti della sezione 5. Dopo l'identificazione e la registrazione, l'operatore del DCCG:

- aggiunge il certificato o i certificati NB_CSCA all'elenco di fiducia firmato con la chiave privata che corrisponde alla chiave pubblica DCCG_TA;

- aggiunge il certificato NB_TLS alla lista bianca dell'endpoint TLS del DCCG;

- aggiunge il certificato NB_UP al sistema DCCG;

- fornisce allo Stato membro il certificato a chiave pubblica DCCG_TA e DCCG_TLS.

4.2. Autorità di certificazione, periodi di validità e rinnovo

Nel caso in cui uno Stato membro intenda gestire la propria CSCA, i certificati CSCA possono essere autofirmati. Essi fungono da ancora di fiducia dello Stato membro e pertanto lo Stato membro deve proteggere con forza la chiave privata corrispondente alla chiave pubblica del certificato CSCA. Si raccomanda agli Stati membri di utilizzare un sistema off-line per la loro CSCA, ossia un sistema informatico non connesso ad alcuna rete. Per accedere al sistema si utilizza un controllo multi-persona (ad esempio, secondo il principio del doppio controllo). Dopo la firma dei DSC sono effettuati controlli operativi e il sistema che detiene la chiave CSCA privata è conservato in condizioni di sicurezza con forti controlli d'accesso. Per proteggere ulteriormente la chiave CSCA privata si possono utilizzare moduli di sicurezza hardware o carte intelligenti. I certificati digitali contengono un periodo di validità che impone il rinnovo del certificato. Il rinnovo è necessario per utilizzare nuove chiavi crittografiche e per adattare le dimensioni delle chiavi nel caso di nuovi miglioramenti nel calcolo o quando nuovi attacchi minacciano la sicurezza dell'algoritmo crittografico utilizzato. Si applica il modello a strati (cfr. la sezione 3.2).

Data la validità di un anno dei certificati COVID digitali, si raccomandano i periodi di validità seguenti:

- CSCA: 4 anni

- DSC: 2 anni

- Caricamento: 1-2 anni

- Autenticazione del client TLS: 1-2 anni

Ai fini di un rinnovo tempestivo, si raccomandano i periodi di utilizzo seguenti per le chiavi private:

- CSCA: 1 anno

- DSC: 6 mesi

Gli Stati membri devono creare tempestivamente nuovi certificati di caricamento e certificati TLS, ad esempio un mese prima della scadenza, al fine di consentire il corretto funzionamento. I certificati CSCA e i DSC dovrebbero essere rinnovati almeno un mese prima della fine dell'utilizzo della chiave privata (tenendo conto delle necessarie procedure operative). Gli Stati membri devono fornire certificati CSCA, certificati di caricamento e TLS aggiornati all'operatore del DCCG. I certificati scaduti sono rimossi dalla lista bianca e dall'elenco di fiducia.

Gli Stati membri e l'operatore del DCCG devono tenere traccia della validità dei propri certificati. Non esiste un'entità centrale che tenga traccia della validità dei certificati e che informi i partecipanti.

4.3. Revoca dei certificati

In generale, i certificati digitali possono essere revocati dall'autorità di certificazione che li ha rilasciati utilizzando elenchi dei certificati revocati o il responder Online Certificate Status Protocol (OCSP). Le CSCA per il sistema DCC dovrebbero fornire elenchi dei certificati revocati (CRL). Anche se tali CRL non sono attualmente utilizzati da altri Stati membri, essi dovrebbero essere integrati per le applicazioni future. Se una CSCA decide di non fornire CRL, i DSC di tale CSCA dovranno essere rinnovati quando i CRL diventeranno obbligatori. Per la convalida dei DSC, i verificatori non dovrebbero utilizzare l'OCSP ma i CRL. Si raccomanda che il back-end nazionale esegua la necessaria convalida dei DSC scaricati dal DCCG e che trasmetta ai validatori DCC nazionali solo una serie di DSC fidati e convalidati. I validatori DCC non dovrebbero effettuare alcun controllo delle revoche dei DSC nel loro processo di convalida. Uno dei motivi è proteggere la vita privata dei titolari di DCC evitando ogni possibilità che l'uso di un determinato DSC possa essere monitorato dal suo responder OCSP associato.

Gli Stati membri possono rimuovere autonomamente i propri DSC dal DCCG utilizzando certificati di caricamento e TLS validi. Rimuovendo un DSC, tutti i DCC rilasciati con tale DSC non saranno più validi quando gli Stati membri estrarranno gli elenchi di DSC aggiornati. La protezione del materiale relativo alle chiavi private corrispondenti ai DSC è fondamentale. Gli Stati membri sono tenuti a informare l'operatore del DCCG quando devono revocare i certificati di caricamento o TLS, ad esempio a causa della compromissione del back-end nazionale. L'operatore del DCCG può quindi togliere la fiducia per il certificato in questione, ad esempio rimuovendolo dalla lista bianca TLS. L'operatore del DCCG può rimuovere i certificati di caricamento dalla banca dati del DCCG. I pacchetti firmati con la chiave privata corrispondente a questo certificato di caricamento non saranno più validi quando i back-end nazionali toglieranno la fiducia per il certificato di caricamento revocato. Qualora un certificato CSCA debba essere revocato, gli Stati membri informano l'operatore del DCCG e gli altri Stati membri con cui hanno rapporti di fiducia. L'operatore del DCCG rilascerà un nuovo elenco di fiducia in cui il certificato in questione non sarà più presente. Tutti i DSC rilasciati da tale CSCA non saranno più validi nel momento in cui gli Stati membri aggiorneranno il trust store del loro back-end nazionale. Nel caso in cui il certificato DCCG_TLS o il certificato DCCG_TA debba essere revocato, l'operatore del DCCG e gli Stati membri devono collaborare per stabilire una nuova connessione TLS fidata e un nuovo elenco di fiducia.

5. Modelli di certificato

Questa sezione stabilisce i requisiti crittografici, i relativi orientamenti e i requisiti dei modelli di certificato. Per i certificati del DCCG, questa sezione definisce i modelli di certificato.

5.1. Requisiti crittografici

Gli algoritmi crittografici e le suite di cifratura TLS sono scelti sulla base delle attuali raccomandazioni dell'Ufficio federale tedesco per la sicurezza delle informazioni (BSI) o del SOGIS. Tali raccomandazioni e le raccomandazioni di altre istituzioni e organismi di normazione sono simili. Le raccomandazioni sono contenute negli orientamenti tecnici TR 02102-1 e TR 02102-2 [1] o nei meccanismi crittografici concordati dal SOGIS [2].

5.1.1. Requisiti relativi al DSC

Si applicano i requisiti di cui all'allegato I, sezione 3.2.2. Si raccomanda pertanto vivamente ai firmatari dei documenti di utilizzare l'algoritmo di firma digitale su curva ellittica (ECDSA) con NIST-p-256 (come definito nell'appendice D di FIPS PUB 186-4). Altre curve ellittiche non sono supportate. A causa dei limiti di spazio del DCC, gli Stati membri non dovrebbero utilizzare l'algoritmo RSA-PSS, anche se consentito come algoritmo di riserva. Nel caso in cui gli Stati membri utilizzino l'algoritmo RSA-PSS, dovrebbero utilizzare un modulo di dimensioni pari a 2048 o al massimo 3072 bit. L'algoritmo SHA-2 con una lunghezza di output ≥ 256 bit è utilizzato come funzione di hash crittografico (cfr. ISO/IEC 10118-3:2004) per la firma del DSC.

5.1.2. Requisiti per certificati TLS, di caricamento e CSCA

Per i certificati digitali e le firme crittografiche nel contesto del DCCG, i principali requisiti relativi agli algoritmi crittografici e alla lunghezza della chiave sono riassunti nella tabella seguente (a partire dal 2021):

.

La curva ellittica raccomandata per l'algoritmo EC-DSA è NIST-p-256 a causa della sua applicazione diffusa.

5.2. Certificato CSCA (NB_CSCA)

La tabella seguente fornisce indicazioni sul modello di certificato NB_CSCA se uno Stato membro decide di gestire la propria CSCA per il sistema DCC.

Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

.

Il nome del soggetto deve essere univoco e non vuoto all'interno dello Stato membro specificato. Il codice paese (c) deve corrispondere allo Stato membro che si avvarrà di questo certificato CSCA. Il certificato deve contenere un identificativo della chiave del soggetto (Subject Key Identifier - SKI) univoco conformemente a RFC 5280 [3].

5.3. Certificato di firma digitale (DSC)

La tabella seguente fornisce indicazioni sul DSC. Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

.

Il DSC deve essere firmato con la chiave privata corrispondente a un certificato CSCA utilizzato dallo Stato membro.

Devono essere utilizzate le estensioni seguenti:

- il certificato deve contenere un identificativo della chiave dell'autorità (Authority Key Identifier - AKI) corrispondente all'identificativo della chiave del soggetto (SKI) del certificato della CSCA emittente;

- il certificato dovrebbe contenere un identificativo della chiave del soggetto univoco (conformemente a RFC 5280 [4]).

Inoltre il certificato dovrebbe contenere l'estensione del punto di distribuzione del CRL che indica l'elenco dei certificati revocati (CRL) fornito dalla CSCA che ha rilasciato il DSC.

Il DSC può contenere un'estensione dell'utilizzo esteso della chiave con zero o più identificativi di policy sull'utilizzo della chiave che limitano i tipi di HCERT che il certificato è autorizzato a verificare. In presenza di una o più estensioni, i verificatori verificano l'utilizzo della chiave confrontandola con l'HCERT memorizzato. A tal fine sono definiti i valori extendedKeyUsage (utilizzo esteso della chiave) seguenti:

.

In mancanza di un'estensione dell'utilizzo della chiave (ossia nessuna estensione o zero estensioni), questo certificato può essere utilizzato per convalidare qualsiasi tipo di HCERT. Altri documenti possono definire ulteriori identificativi di policy sull'utilizzo esteso della chiave utilizzati per la convalida degli HCERT.

5.4. Certificati di caricamento (NBUP)

La tabella seguente fornisce indicazioni per il certificato di caricamento del back-end nazionale. Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

.

5.5. Autenticazione del client TLS del back-end nazionale (NB_TLS)

La tabella seguente fornisce indicazioni per il certificato di autenticazione del client TLS del back-end nazionale. Le voci in grassetto sono obbligatorie (devono essere inserite nel certificato), quelle in corsivo son raccomandate (dovrebbero essere inserite). Per i campi mancanti non sono definite raccomandazioni.

.

Il certificato può, ma non necessariamente deve, contenere anche server authentication (autenticazione del server) (1.3.6.1.5.5.7.3.1) per l'utilizzo esteso della chiave.

5.6. Certificato di firma dell'elenco di fiducia (DCCG_TA)

La tabella seguente definisce il certificato dell'ancora di fiducia del DCCG.

.

5.7. Certificati del server TLS del DCCG (DCCG_TLS)

La tabella seguente definisce il certificato TLS del DCCG.

.

Il certificato può, ma non necessariamente deve, contenere anche client authentication (autenticazione del client) (1.3.6.1.5.5.7.3.2) per l'utilizzo esteso della chiave.

Il certificato TLS del DCCG è rilasciato da un'autorità di certificazione pubblicamente riconosciuta (anche in tutti i principali browser e sistemi operativi, conformemente ai requisiti di base del CA/Browser Forum).

________________

[1] BSI - Technical Guidelines TR-02102 (bund.de).

[2] SOGIS - Supporting documents (sogis.eu).

[3] rfc5280 (ietf.org).

[4] rfc5280 (ietf.org).

[5] La terminologia «certificato verde digitale» anziché «certificato COVID digitale dell'UE» è stata mantenuta in questo contesto perché è questa la terminologia che è stata codificata in modo fisso e utilizzata nel certificato prima che i colegislatori decidessero di modificarla.

(introdotto dall'art. 1 della Dec. (UE) 2021/2014, modificato dall'art. 1 della Dec. (UE) 2022/483 e dall'art. 1 della Dec. (UE) 2022/1516)

SCHEMA JSON (JAVASCRIPT OBJECT NOTATION)

1. Introduzione

Il presente allegato definisce la struttura tecnica dei dati per i certificati COVID digitali dell'UE (EUDCC), rappresentata come schema JSON. Il documento fornisce istruzioni specifiche relative ai singoli campi di dati.

2. Posizione e versioni dello schema JSON

Lo schema JSON ufficiale autorevole per EUDCC è disponibile all'indirizzo https://github.com/ehn-dcc-development/ ehn-dcc-schema. Altre posizioni non sono autorevoli, ma possono essere utilizzate per preparare le prossime revisioni.

Per impostazione predefinita, la versione attuale definita nel presente allegato e sostenuta da tutti i paesi attualmente impegnati nella produzione, figura all'URL indicato.

La prossima nuova versione, che deve essere sostenuta da una data definita da tutti i paesi, figura all'URL indicato mediante attribuzione di tag alle versioni ("version tagging"), descritto in dettaglio nel file Readme.

3. Strutture comuni e requisiti generali

Un certificato COVID digitale dell'UE non può essere rilasciato se, a causa di informazioni mancanti, non è possibile compilare correttamente tutti i campi di dati conformemente alla presente specifica. Ciò non va inteso in modo da pregiudicare l'obbligo degli Stati membri di rilasciare certificati COVID digitali dell'UE.

In tutti i campi le informazioni possono essere fornite utilizzando l'insieme completo di caratteri UNICODE 13.0 codificati utilizzando l'UTF-8, a meno che i caratteri non siano specificamente limitati a serie di valori o a insiemi di caratteri più ristretti.

La struttura comune è la seguente:

"JSON":{

"ver":<informazioni sulla versione>,

"nam":{

<informazioni sul nome della persona>

},

"dob":<data di nascita>,

"v" o "t" o "r":[

{<informazioni sulla dose di vaccinazione, sul test o sulla guarigione, una voce>}

]

}

Nelle sezioni successive sono fornite informazioni dettagliate sui singoli gruppi e campi.

Se le regole indicano che un campo deve essere tralasciato, ciò significa che deve essere vuoto e che nel contenuto non sono ammessi né il nome né il valore del campo.

3.1. Versione

Devono essere fornite informazioni sulla versione. Le versioni seguono il versionamento semantico ("Semantic Versioning" semver: https://semver.org). In fase di produzione la versione deve corrispondere a una delle versioni prodotte ufficialmente (attuale o precedenti). Per maggiori dettagli cfr. sezione relativa alla posizione dello schema JSON.

.

3.2. Nome e data di nascita della persona

Il nome della persona è il nome ufficiale completo, corrispondente al nome indicato nei documenti di viaggio. L'identificativo della struttura è nam. Deve essere indicato esattamente 1 (un) nome della persona.

.

3.3. Gruppi per informazioni specifiche relative al tipo di certificato

Lo schema JSON supporta tre gruppi di voci comprendenti informazioni specifiche relative al tipo di certificato. Ciascun EUDCC deve contenere esattamente 1 (un) gruppo. Non sono ammessi gruppi vuoti.

.

4. Informazioni specifiche relative al tipo di certificato

4.1. Certificato di vaccinazione

Il gruppo Vaccinazione, se presente, deve contenere esattamente 1 (una) voce che descriva esattamente un evento vaccinale (una dose). Tutti gli elementi del gruppo Vaccinazione sono obbligatori, i valori vuoti non sono supportati.

.

4.2. Certificato di test

Il gruppo Test, se presente, deve contenere esattamente 1 (una) voce che descriva esattamente un risultato di test.

.

4.3. Certificato di guarigione

Il gruppo Guarigione, se presente, deve contenere esattamente 1 (una) voce che descrive esattamente una dichiarazione di guarigione. Tutti gli elementi del gruppo Guarigione sono obbligatori, i valori vuoti non sono supportati.

.

(introdotto dall'art. 1 della Dec. (UE) 2022/483)

RESPONSABILITA' DEGLI STATI MEMBRI IN QUALITA' DI CONTITOLARI DEL TRATTAMENTO PER IL GATEWAY PER I CERTIFICATI COVID DIGITALI DELL'UE AI FINI DELLO SCAMBIO DEGLI ELENCHI DEI CERTIFICATI COVID DIGITALI DELL'UE REVOCATI

SEZIONE 1

Sottosezione 1

Ripartizione delle responsabilità 

1) I contitolari del trattamento trattano i dati personali tramite il gateway del quadro di fiducia conformemente alle specifiche tecniche di cui all'allegato I. 

2) Le autorità di rilascio degli Stati membri sono gli unici titolari del trattamento responsabili della raccolta, dell'uso, della comunicazione e di qualsiasi altro trattamento delle informazioni sulla revoca al di fuori del gateway, anche per quanto riguarda la procedura che conduce alla revoca di un certificato. 

3) Ogni titolare del trattamento è responsabile del trattamento dei dati personali nel gateway del quadro di fiducia conformemente agli articoli 5, 24 e 26 del regolamento generale sulla protezione dei dati. 

4) Ogni titolare del trattamento istituisce un punto di contatto con una casella di posta elettronica funzionale da utilizzare per la comunicazione tra i contitolari del trattamento stessi e tra questi ultimi e il responsabile del trattamento. 

5) Un gruppo di lavoro istituito dal comitato di cui all'articolo 14 del regolamento (UE) 2021/953 è incaricato di decidere in merito a eventuali problematiche derivanti dallo scambio degli elenchi dei certificati revocati nonché dalla contitolarità del relativo trattamento dei dati personali e di agevolare la fornitura di istruzioni coordinate alla Commissione in qualità di responsabile del trattamento. Il processo decisionale dei contitolari del trattamento è disciplinato da tale gruppo di lavoro e dal regolamento interno che esso è chiamato ad adottare. Come norma di base, la non partecipazione di qualsiasi contitolare del trattamento a una riunione del suddetto gruppo di lavoro, che sia stata annunciata per iscritto almeno sette (7) giorni prima della convocazione, è considerata quale tacito accordo con gli esiti di tale riunione del gruppo di lavoro. Qualsiasi contitolare del trattamento può convocare una riunione di tale gruppo di lavoro. 

6) Le istruzioni al responsabile del trattamento sono inviate dai punti di contatto di qualsiasi contitolare del trattamento, d'intesa con gli altri contitolari del trattamento, come da processo decisionale del gruppo di lavoro di cui al precedente punto 5. Il contitolare del trattamento che fornisce le istruzioni dovrebbe trasmetterle al responsabile del trattamento per iscritto e informarne tutti gli altri contitolari del trattamento. Se la questione in esame è così urgente da non consentire una riunione del gruppo di lavoro di cui al precedente punto 5, è comunque possibile fornire istruzioni, ma esse possono essere revocate dal gruppo di lavoro. Tali istruzioni dovrebbero essere fornite per iscritto e tutti gli altri contitolari del trattamento dovrebbero esserne informati all'atto della fornitura delle istruzioni. 

7) Il gruppo di lavoro istituito in base al precedente punto 5 non osta alla competenza individuale di qualsiasi contitolare del trattamento di informare la rispettiva autorità di controllo competente conformemente agli articoli 33 e 24 del regolamento generale sulla protezione dei dati. Tale notifica non richiede il consenso degli altri contitolari del trattamento. 

8) Nell'ambito del gateway del quadro di fiducia solo le persone autorizzate dalle autorità nazionali o dagli organismi ufficiali designati possono accedere ai dati personali scambiati. 

9) Ogni autorità di rilascio tiene, sotto la propria responsabilità, un registro delle attività di trattamento. La contitolarità del trattamento può essere indicata nel registro.

Sottosezione 2

Responsabilità e ruoli per la gestione delle richieste degli interessati e la loro informazione

1) Ogni titolare del trattamento, nel suo ruolo di autorità di rilascio, fornisce alle persone fisiche i cui certificati sono stati da esso revocati (gli «interessati») informazioni su tali revoche e sul trattamento dei loro dati personali nel gateway per i certificati COVID digitali dell'UE al fine di sostenere lo scambio degli elenchi dei certificati revocati, conformemente all'articolo 14 del regolamento generale sulla protezione dei dati, salvo che ciò non si riveli impossibile o implichi uno sforzo sproporzionato. 

2) Ogni titolare del trattamento funge da punto di contatto per le persone fisiche i cui certificati sono stati da esso revocati e gestisce le richieste presentate dagli interessati o dai loro rappresentanti nell'esercizio dei loro diritti a norma del regolamento generale sulla protezione dei dati personali. Se un contitolare del trattamento riceve da un interessato una richiesta relativa a un certificato rilasciato da un altro contitolare del trattamento, esso informa l'interessato dell'identità e dei dati di contatto di tale contitolare del trattamento competente. Se richiesto da un altro contitolare del trattamento, i contitolari del trattamento si forniscono assistenza reciproca nella gestione delle richieste degli interessati e si rispondono reciprocamente senza indebito ritardo e al più tardi entro un mese dalla ricezione di una richiesta di assistenza. Se una richiesta riguarda dati presentati da un paese terzo, il titolare del trattamento che riceve la richiesta la gestisce e informa l'interessato dell'identità e dei dati di contatto dell'autorità di rilascio del paese terzo.

3) Ogni titolare del trattamento mette a disposizione degli interessati il contenuto del presente allegato, comprese le disposizioni di cui ai punti 1 e 2.

SEZIONE 2

Gestione degli incidenti di sicurezza, comprese le violazioni dei dati personali 

1) I contitolari del trattamento si forniscono assistenza reciproca nell'identificazione e nella gestione di eventuali incidenti di sicurezza connessi al trattamento nel gateway per i certificati COVID digitali dell'UE, comprese le violazioni dei dati personali.

2) I contitolari del trattamento, in particolare, si informano reciprocamente:

a) di eventuali rischi potenziali o effettivi per la disponibilità, la riservatezza e/o l'integrità dei dati personali oggetto di trattamento nel gateway del quadro di fiducia;

b) di eventuali violazioni dei dati personali, delle probabili conseguenze delle violazioni dei dati personali e della valutazione del rischio per i diritti e le libertà delle persone fisiche, nonché delle misure adottate per porre rimedio alla violazione dei dati personali e per attenuare il rischio per i diritti e le libertà delle persone fisiche;

c) di eventuali violazioni delle garanzie tecniche e/o organizzative del trattamento nel gateway del quadro di fiducia. 

3) I contitolari del trattamento comunicano alla Commissione, alle competenti autorità di controllo e, ove prescritto, agli interessati, eventuali violazioni dei dati personali in relazione al trattamento nel gateway del quadro di fiducia in conformità agli articoli 33 e 34 del regolamento generale sulla protezione dei dati o a seguito della notifica da parte della Commissione. 

4) Ogni autorità di rilascio applica adeguate misure tecniche e organizzative, intese a:

a) garantire e proteggere la disponibilità, l'integrità e la riservatezza dei dati personali oggetto di trattamento congiunto;

b) proteggere i dati personali in suo possesso da trattamenti, perdite, usi, comunicazioni, acquisizioni o accessi non autorizzati o illeciti;

c) garantire che l'accesso ai dati personali non sia esteso o consentito a soggetti diversi dai destinatari o dai responsabili del trattamento.

SEZIONE 3

Valutazione d'impatto sulla protezione dei dati

1) Se un titolare del trattamento, per rispettare gli obblighi di cui agli articoli 35 e 36 del regolamento (UE) 2016/679, ha bisogno di informazioni da un altro titolare del trattamento, invia una richiesta specifica alla casella di posta elettronica funzionale di cui alla sezione 1, sottosezione 1, punto 4. Quest'ultimo titolare del trattamento si adopera al meglio per fornire tali informazioni.

(introdotto dall'art. 1 della Dec. (UE) 2022/483)

RESPONSABILITA' DELLA COMMISSIONE IN QUALITA' DI RESPONSABILE DEL TRATTAMENTO DEI DATI PER IL GATEWAY PER I CERTIFICATI COVID DIGITALI DELL'UE A SOSTEGNO DELLO SCAMBIO DEGLI ELENCHI DEI CERTIFICATI COVID DIGITALI DELL'UE REVOCATI

La Commissione:

1) Istituisce, per conto degli Stati membri, un'infrastruttura di comunicazione sicura e affidabile che sostenga lo scambio degli elenchi dei certificati revocati presentati al gateway per i certificati COVID digitali dell'UE.

2) Per adempiere i propri obblighi in qualità di responsabile del trattamento dei dati del gateway del quadro di fiducia per gli Stati membri, la Commissione può ricorrere a terzi come sotto-responsabili del trattamento; la Commissione informa i contitolari del trattamento di eventuali modifiche previste riguardanti l'aggiunta o la sostituzione di altri sotto-responsabili del trattamento, offrendo in tal modo ai titolari del trattamento l'opportunità di opporsi congiuntamente a tali modifiche. La Commissione si assicura che a detti sotto-responsabili si applichino gli stessi obblighi in materia di protezione dei dati di cui alla presente decisione.

3) Tratta i dati personali soltanto su istruzione documentata dei titolari del trattamento, a meno che il trattamento non sia richiesto dal diritto dell'Unione o dello Stato membro; in tal caso, la Commissione informa i contitolari del trattamento in merito a tale obbligo giuridico prima di svolgere l'attività di trattamento, a meno che il diritto vieti la fornitura di tale informazione per importanti motivi di interesse pubblico.

Il trattamento della Commissione comprende i seguenti elementi:

a) l'autenticazione dei server back-end nazionali, sulla base dei certificati dei server back-end nazionali;

b) la ricezione dei dati di cui all'articolo 5 bis, paragrafo 3, della decisione caricati dai server back-end nazionali, mediante la fornitura di un'interfaccia di programmazione di un'applicazione (API) che consenta ai server back-end nazionali di caricare i dati pertinenti;

c) la conservazione dei dati nel gateway per i certificati COVID digitali dell'UE;

d) la messa a disposizione dei dati affinché i server back-end nazionali possano scaricarli;

e) la cancellazione dei dati alla data di scadenza o dietro istruzione del titolare del trattamento che li ha presentati;

f) la cancellazione di tutti i dati rimanenti dopo che è terminata la prestazione del servizio, salvo che il diritto dell'Unione o degli Stati membri preveda la conservazione dei dati personali.

4) Adotta tutte le misure di sicurezza fisiche, logiche e organizzative all'avanguardia per mantenere efficiente il gateway per i certificati COVID digitali dell'UE. A tal fine la Commissione:

a) designa un responsabile per la gestione della sicurezza a livello del gateway per i certificati COVID digitali dell'UE, ne comunica i dati di contatto ai contitolari del trattamento e garantisce la sua disponibilità a reagire alle minacce alla sicurezza;

b) si assume la responsabilità della sicurezza del gateway per i certificati COVID digitali dell'UE, anche effettuando periodicamente prove, valutazioni e analisi delle misure di sicurezza;

c) si assicura che tutte le persone cui è consentito l'accesso al gateway per i certificati COVID digitali dell'UE siano assoggettate per contratto, professionalmente o per legge all'obbligo di riservatezza.

5) Adotta tutte le misure di sicurezza necessarie per evitare di compromettere il regolare funzionamento operativo dei server back-end nazionali. A tal fine la Commissione istituisce procedure specifiche relative alla connessione dai server back-end al gateway per i certificati COVID digitali dell'UE. Queste comprendono:

a) una procedura di valutazione del rischio finalizzata a individuare e stimare potenziali minacce al sistema;

b) una procedura di audit e revisione finalizzata a:

i. verificare la corrispondenza tra le misure di sicurezza applicate e la politica di sicurezza applicabile;

ii. controllare periodicamente l'integrità dei file di sistema, dei parametri di sicurezza e delle autorizzazioni concesse;

iii. effettuare controlli allo scopo di rilevare violazioni della sicurezza e intrusioni;

iv. apportare modifiche per ridurre le lacune esistenti in materia di sicurezza;

v. definire le condizioni alle quali autorizzare, anche su richiesta dei titolari del trattamento, audit indipendenti, comprese ispezioni, e revisioni delle misure di sicurezza e contribuire all'esecuzione di tali audit e revisioni, fatto salvo il rispetto il protocollo (n. 7) del TFUE sui privilegi e sulle immunità dell'Unione europea;

c) la modifica della procedura di controllo finalizzata a documentare e misurare l'impatto di una modifica prima della sua realizzazione e a tenere informati i contitolari del trattamento in merito a eventuali modifiche in grado di avere effetti sulla comunicazione con le loro infrastrutture e/o sulla sicurezza di queste ultime;

d) l'elaborazione di una procedura per la manutenzione e la riparazione finalizzata a specificare le norme e le condizioni da rispettare in caso di manutenzione e/o riparazione delle attrezzature;

e) l'elaborazione di una procedura per gli incidenti di sicurezza finalizzata a definire il sistema di segnalazione e successione, informare senza indugio i titolari del trattamento interessati, informare senza indugio i titolari del trattamento affinché possano notificare le autorità nazionali di controllo della protezione dei dati in merito a qualsiasi violazione dei dati personali, e definire un processo disciplinare per affrontare le violazioni della sicurezza.

6) Adotta misure di sicurezza fisiche e/o logiche all'avanguardia per le strutture che ospitano le attrezzature del gateway per i certificati COVID digitali dell'UE e per i controlli relativi all'accesso alla sicurezza e ai dati logici. A tal fine la Commissione:

a) garantisce il rispetto della sicurezza fisica per stabilire specifici perimetri di sicurezza e consentire l'individuazione di violazioni;

b) controlla l'accesso alle strutture e tiene un registro dei visitatori a fini di tracciabilità;

c) si assicura che le persone esterne a cui è consentito l'accesso ai locali siano scortate da personale debitamente autorizzato;

d) provvede affinché non possano essere aggiunte, sostituite o rimosse attrezzature senza la preventiva autorizzazione degli organismi responsabili designati;

e) controlla l'accesso ai server back-end nazionali e da questi al gateway del quadro di fiducia;

f) provvede affinché le persone che accedono al gateway per i certificati COVID digitali dell'UE siano identificate e la loro identità sia accertata;

g) riesamina i diritti di autorizzazione relativi all'accesso al gateway per i certificati COVID digitali dell'UE in caso di violazione della sicurezza riguardante tale infrastruttura;

h) salvaguarda l'integrità delle informazioni trasmesse attraverso il gateway per i certificati COVID digitali dell'UE;

i) applica misure tecniche e organizzative di sicurezza per impedire l'accesso non autorizzato ai dati personali;

j) applica, ove necessario, misure per bloccare l'accesso non autorizzato al gateway per i certificati COVID digitali dell'UE dal dominio delle autorità di rilascio (ossia blocco di un indirizzo IP/di localizzazione).

7) Adotta misure per proteggere il suo dominio, compresa l'interruzione delle connessioni, in caso di scostamento sostanziale rispetto ai principi e ai concetti in materia di qualità o di sicurezza.

8) Prevede un piano di gestione dei rischi in relazione al suo settore di competenza.

9) Monitora - in tempo reale - l'efficienza di tutte le componenti dei suoi servizi del gateway del quadro di fiducia, produce statistiche periodiche e conserva le informazioni.

10) Fornisce (24 ore su 24 e sette giorni alla settimana) supporto in inglese per tutti i servizi del gateway del quadro di fiducia tramite telefono, posta elettronica o portale web e accetta le chiamate dai chiamanti autorizzati: coordinatori del gateway per i certificati COVID digitali dell'UE e rispettivi helpdesk, responsabili di progetto e persone designate dalla Commissione.

11) Assiste i contitolari del trattamento con misure tecniche e organizzative adeguate, nella misura in cui ciò sia possibile a norma dell'articolo 12 del regolamento (UE) 2018/1725, al fine di soddisfare l'obbligo del titolare del trattamento di dare seguito alle richieste per l'esercizio dei diritti dell'interessato di cui al capo III del regolamento generale sulla protezione dei dati.

12) Assiste i contitolari del trattamento fornendo informazioni relative al gateway per i certificati COVID digitali dell'UE al fine di adempiere gli obblighi di cui agli articoli 32, 33, 34, 35 e 36 del regolamento generale sulla protezione dei dati.

13) Garantisce che i dati trattati all'interno del gateway per i certificati COVID digitali dell'UE siano incomprensibili a chiunque non sia autorizzato ad accedervi.

14) Adotta tutte le misure necessarie per evitare che gli operatori del gateway per i certificati COVID digitali dell'UE abbiano accesso non autorizzato ai dati trasmessi.

15) Adotta misure volte a facilitare l'interoperabilità e la comunicazione tra i titolari del trattamento designati del gateway per i certificati COVID digitali dell'UE.

16) Tiene un registro delle attività di trattamento svolte per conto dei contitolari del trattamento in conformità all'articolo 31, paragrafo 2, del regolamento (UE) 2018/1725.