ALLEGATO I

Nell’allegato I della decisione di esecuzione (UE) 2021/1073 è aggiunta la seguente sezione 9:

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

Tipo Attributo Calcolo dell’hash SIGNATURE DCC Signature SHA256 of DCC Signature UCI UCI (Unique Certificate Identifier) SHA256 of UCI COUNTRYCODEUCI Issuing Country Code + UCI SHA256 of Issuing CountryCode + UCI

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

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 (2), 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.

[deprecato2, 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:

Campo Definizione more Flag booleano che indica che vi sono più batch. batches Array con i batch esistenti. batchId https://en.wikipedia.org/wiki/Universally_unique_identifier country Codice paese ISO 3166 date Data UTC ISO 8601. Data in cui il batch è stato aggiunto o cancellato. deleted booleano. «True» se cancellato. Quando viene impostato il flag «deleted», la voce può essere rimossa definitivamente dai risultati dell’interrogazione dopo 7 giorni.

9.5.1.2.1.1. Codici di risposta

Codice Descrizione 200 Tutto ok. 204 Nessun contenuto, se il contenuto dell’intestazione «If-Modified-Since» non restituisce alcuna corrispondenza.

Intestazione della richiesta

Intestazione Obbligatoria Descrizione If-Modified-Since Sì Questa intestazione contiene l’ultima data scaricata al fine di ottenere solo i risultati più recenti. Nella chiamata iniziale l’intestazione dovrebbe essere impostata su «2021-06-01T00:00:00Z»

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:

Campo Obbligatorio Tipo Definizione expires Sì String Data in cui l’elemento può essere rimosso. Data/ora UTC ISO 8601 country Sì String Codice paese ISO 3166 hashType Sì String Tipo di hash delle voci fornite (cfr. Tipi di hash) entries Sì JSON Object Array Cfr. tabella Voci kid Sì String kid del DSC codificato in base64 utilizzato per firmare il DCC. Se il kid è sconosciuto è possibile utilizzare la stringa «UNKNOWN_KID» (escludendo le»). Note:

— 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

Campo Obbligatorio Tipo Definizione hash Sì String Primi 128 bit dell’hash SHA256 codificati come stringa in base64

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

Codice Descrizione 200 Tutto ok. 410 batch non più presente. Il batch può essere cancellato nel back-end nazionale.

9.5.1.2.2.3. Intestazioni della risposta

Intestazione Descrizione ETag ID del batch

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