02021D1073 — IT — 15.09.2022 — 004.001

Il presente testo è un semplice strumento di documentazione e non produce alcun effetto giuridico. Le istituzioni dell’Unione non assumono alcuna responsabilità per i suoi contenuti. Le versioni facenti fede degli atti pertinenti, compresi i loro preamboli, sono quelle pubblicate nella Gazzetta ufficiale dell’Unione europea e disponibili in EUR-Lex. Tali testi ufficiali sono direttamente accessibili attraverso i link inseriti nel presente documento

►B DECISIONE DI ESECUZIONE (UE) 2021/1073 DELLA COMMISSIONE del 28 giugno 2021 che stabilisce specifiche tecniche e norme per l’attuazione del quadro di fiducia per il certificato COVID digitale dell’UE istituito dal regolamento (UE) 2021/953 del Parlamento europeo e del Consiglio (Testo rilevante ai fini del SEE) (GU L 230 del 30.6.2021, pag. 32)

Modificata da:









▼B

DECISIONE DI ESECUZIONE (UE) 2021/1073 DELLA COMMISSIONE

del 28 giugno 2021

che stabilisce specifiche tecniche e norme per l’attuazione del quadro di fiducia per il certificato COVID digitale dell’UE istituito dal regolamento (UE) 2021/953 del Parlamento europeo e del Consiglio

(Testo rilevante ai fini del SEE)







Articolo 1

Le specifiche tecniche del certificato COVID digitale dell’UE che stabiliscono la struttura dei dati generici, i meccanismi di codifica e il meccanismo di codifica di trasporto in un formato ottico leggibile meccanicamente sono stabilite nell’allegato I.

Articolo 2

Le norme per la compilazione dei certificati di cui all’articolo 3, paragrafo 1, del regolamento (UE) 2021/953 sono stabilite nell’allegato II della presente decisione.

Articolo 3

I requisiti che stabiliscono la struttura comune dell’identificativo univoco del certificato sono stabiliti nell’allegato III.

▼M1

Articolo 4

Le norme di governance applicabili ai certificati a chiave pubblica in relazione al gateway per i certificati COVID digitali dell'UE a sostegno degli aspetti di interoperabilità del quadro di fiducia sono stabilite nell'allegato IV.

▼M1

Articolo 5

Una struttura comune coordinata dei dati per i dati da includere nei certificati di cui all'articolo 3, paragrafo 1, del regolamento (UE) 2021/953, che utilizza uno schema JavaScript Object Notation (JSON), figura nell'allegato V della presente decisione.

▼M3

Articolo 5 bis

Scambio degli elenchi dei certificati revocati

1. Il quadro di fiducia per il certificato COVID digitale dell’UE consente lo scambio degli elenchi dei certificati revocati tramite il gateway centrale per i certificati COVID digitali dell’UE (il «gateway»), conformemente alle specifiche tecniche di cui all’allegato I.

2. Qualora revochino certificati COVID digitali dell’UE, gli Stati membri possono presentare al gateway gli elenchi dei certificati revocati.

3. Qualora gli Stati membri presentino elenchi dei certificati revocati, le autorità di rilascio tengono un elenco dei certificati revocati.

4. Qualora siano scambiati dati personali tramite il gateway, il trattamento è limitato alla finalità di sostenere lo scambio di informazioni sulla revoca. Tali dati personali sono utilizzati unicamente al fine di verificare lo stato di revoca dei certificati COVID digitali dell’UE rilasciati nell’ambito del regolamento (UE) 2021/953.

5. Le informazioni presentate al gateway comprendono i seguenti dati, conformemente alle specifiche tecniche di cui all’allegato I: a) gli identificativi univoci pseudonimizzati dei certificati revocati; b) una data di scadenza per l’elenco dei certificati revocati presentato.

6. Qualora revochi certificati COVID digitali dell’UE da essa rilasciati a norma del regolamento (UE) 2021/953 o del regolamento (UE) 2021/954 e intenda scambiare le pertinenti informazioni tramite il gateway, un’autorità di rilascio trasmette al gateway, in un formato sicuro, le informazioni di cui al paragrafo 5 sotto forma di elenchi dei certificati revocati, conformemente alle specifiche tecniche di cui all’allegato I.

7. Le autorità di rilascio forniscono, nella misura del possibile, una soluzione per informare i titolari dei certificati revocati in merito allo stato di revoca dei loro certificati e al motivo della revoca al momento della revoca stessa.

8. Il gateway raccoglie gli elenchi dei certificati revocati ricevuti. Esso fornisce strumenti per la distribuzione degli elenchi agli Stati membri. Cancella automaticamente gli elenchi in base alle date di scadenza indicate per ciascun elenco dall’autorità che lo ha presentato.

9. Le autorità nazionali o gli organismi ufficiali designati degli Stati membri che effettuano il trattamento dei dati personali nel gateway sono contitolari del trattamento dei dati. Le rispettive responsabilità dei contitolari del trattamento sono ripartite conformemente all’allegato VI.

10. La Commissione è responsabile del trattamento dei dati personali trattati all’interno del gateway. In qualità di responsabile del trattamento per conto degli Stati membri, la Commissione garantisce la sicurezza della trasmissione e dell’hosting dei dati personali all’interno del gateway e rispetta gli obblighi incombenti al responsabile del trattamento di cui all’allegato VII.

11. L’efficacia delle misure tecniche e organizzative volte a garantire la sicurezza del trattamento dei dati personali all’interno del gateway è periodicamente verificata, esaminata e valutata dalla Commissione e dai contitolari del trattamento.

Articolo 5 ter

Presentazione degli elenchi dei certificati revocati da parte di paesi terzi

I paesi terzi che rilasciano certificati COVID-19 per i quali la Commissione ha adottato un atto di esecuzione a norma dell’articolo 3, paragrafo 10, o dell’articolo 8, paragrafo 2, del regolamento (UE) 2021/953 possono presentare elenchi dei certificati COVID-19 revocati contemplati da tale atto di esecuzione, affinché siano trattati dalla Commissione per conto dei contitolari del trattamento nel gateway di cui all’articolo 5 bis, conformemente alle specifiche tecniche di cui all’allegato I.

Articolo 5 quater

Governance del trattamento dei dati personali nel gateway centrale per i certificati COVID digitali dell’UE

1. Il processo decisionale dei contitolari del trattamento è gestito da un gruppo di lavoro istituito nell’ambito del comitato di cui all’articolo 14 del regolamento (UE) 2021/953.

2. Le autorità nazionali o gli organismi ufficiali designati degli Stati membri che effettuano il trattamento dei dati personali nel gateway in qualità di contitolari del trattamento designano i rappresentanti presso tale gruppo.

▼M1

Articolo 6

La presente decisione entra in vigore il giorno della pubblicazione nella Gazzetta ufficiale dell'Unione europea.

▼B

La presente decisione entra in vigore il giorno della pubblicazione nella Gazzetta ufficiale dell’Unione europea.









ALLEGATO I

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

▼M3

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

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

▼M1









ALLEGATO II

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.

►M4 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. È 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:







Codice Visualizzazione Nome del sistema di codici URL del sistema di codici OID del sistema di codici Versione del sistema di codici 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

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.

▼M4

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.

▼M1

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.

▼M4

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

▼M1

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.

▼M2

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 1o 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.

▼M1

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:







Codice Visualizzazione Nome del sistema di codici URL del sistema di codici OID del sistema di codici Versione del sistema di codici LP6464-4 Amplificazione dell'acido nucleico con rilevamento della sonda LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69 LP217198-3 Immunodosaggio rapido LOINC http://loinc.org 2.16.840.1.113883.6.1 2.69

▼M4

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

▼M1

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

Da utilizzare nel certificato 2.

▼M4

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.

▼M1

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:







Codice Visualizzazione Nome del sistema di codici URL del sistema di codici OID del sistema di codici Versione del sistema di codici 260415000 Non rilevato SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Rilevato SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼B









ALLEGATO III

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.

▼M1

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 ( 14 ), vale a dire {'/','#',':'};

2) lunghezza massima: i programmatori cercano di rispettare una lunghezza di 27-30 caratteri ( 15 );

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

▼B

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à ( 17 ) 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.









ALLEGATO IV

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.







Termine Definizione Certificato O certificato a chiave pubblica. Un certificato X.509 v3 contenente la chiave pubblica di un’entità. CSCA Autorità nazionale di certificazione DCC Certificato COVID digitale dell’UE. Un documento digitale firmato contenente informazioni sulla vaccinazione, sul test o sulla guarigione. DCCG Gateway per i certificati COVID digitali dell’UE. Questo sistema è utilizzato per scambiare DSC tra gli Stati membri. DCCGTA Il certificato dell’ancora di fiducia del DCCG. La chiave privata corrispondente è utilizzata per firmare l’elenco di tutti i certificati CSCA off-line. DCCGTLS Il certificato del server TLS del DCCG DSC Certificato di firma digitale. Il certificato a chiave pubblica dell’autorità preposta alla firma dei documenti di uno Stato membro (ad esempio un sistema autorizzato a firmare i DCC). Tale certificato è rilasciato dalla CSCA dello Stato membro. EC-DSA Algoritmo di firma digitale su curva ellittica. Un algoritmo di firma crittografica basato su curve ellittiche. Stato membro Stato membro dell’Unione europea mTLS TLS reciproco. Il protocollo Transport Layer Security con autenticazione reciproca. NB: Back-end nazionale di uno Stato membro NBCSCA Il certificato CSCA di uno Stato membro (potrebbe essere più di uno) NBTLS Il certificato di autenticazione del client TLS di un back-end nazionale NBUP Il certificato utilizzato da un back-end nazionale per firmare pacchetti di dati caricati sul DCCG PKI Infrastruttura a chiave pubblica. Modello di fiducia basato su certificati a chiave pubblica e autorità di certificazione. RSA Algoritmo crittografico asimmetrico basato sulla fattorizzazione dei numeri interi utilizzato per le firme digitali o per la cifratura asimmetrica

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 DCCGTLS, mentre i back-end nazionali detengono un certificato del client TLS, abbreviato NBTLS. 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 DCCGTLS 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 DCCGTLS 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 DCCGTA 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 NBUP. Ciascuno Stato membro presenta il proprio certificato NBUP, 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 NBUP è 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 DCCGTLS o il certificato DCCGTA 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 ( 18 ) o nei meccanismi crittografici concordati dal SOGIS ( 19 ).

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







Algoritmo di firma Dimensioni della chiave Funzione di hash EC-DSA Min. 250 bit SHA-2 con lunghezza di output ≥ 256 bit RSA-PSS (riempimento raccomandato) RSA-PKCS#1 v1.5 (riempimento preesistente) Modulo RSA (N) da min. 3000 bit con esponente pubblico e > 2^16 SHA-2 con lunghezza di output ≥ 256 bit DSA Numero primo p da min. 3000 bit, chiave q da 250 bit SHA-2 con lunghezza di output ≥ 256 bit

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

5.2. Certificato CSCA (NBCSCA)

La tabella seguente fornisce indicazioni sul modello di certificato NBCSCA 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.







Campo Valore Subject (Soggetto) cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro che gestisce la CSCA> Key usage (Utilizzo della chiave) certificate signing (firma del certificato), CRL signing (firma del CRL) (come minimo) Basic Constraints (Limitazioni di base) CA = true (vero), path length constraints (limiti di lunghezza del percorso) = 0

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

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.







Campo Valore Serial Number (Numero di serie) numero di serie univoco Subject (Soggetto) cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro che utilizza il DSC> Key Usage (Utilizzo della chiave) digital signature (firma digitale) (come minimo)

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

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:







Campo Valore extendedKeyUsage (utilizzo esteso della chiave) 1.3.6.1.4.1.1847.2021.1.1 per i soggetti che rilasciano certificati di test extendedKeyUsage (utilizzo esteso della chiave) 1.3.6.1.4.1.1847.2021.1.2 per i soggetti che rilasciano certificati di vaccinazione extendedKeyUsage (utilizzo esteso della chiave) 1.3.6.1.4.1.1847.2021.1.3 per i soggetti che rilasciano certificati di guarigione

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.







Campo Valore Subject (Soggetto) cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro che utilizza il certificato di caricamento> Key Usage (Utilizzo della chiave) digital signature (firma digitale) (come minimo)

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

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.







Campo Valore Subject (Soggetto) cn=<nome comune univoco e non vuoto>, o=<fornitore>, c=<Stato membro sul back-end nazionale> Key Usage (Utilizzo della chiave) digital signature (firma digitale) (come minimo) Extended key usage (Utilizzo esteso della chiave) client authentication (autenticazione del client) (1.3.6.1.5.5.7.3.2)

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 (DCCGTA)

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







Campo Valore Subject (Soggetto) cn = Digital Green Certificate Gateway (gateway per i certificati verdi digitali) (1) , o=<fornitore>, c=<paese> Key Usage (Utilizzo della chiave) digital signature (firma digitale) (come minimo) ( 1 ) 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.

5.7. Certificati del server TLS del DCCG (DCCGTLS)

La tabella seguente definisce il certificato TLS del DCCG.







Campo Valore Subject (Soggetto) cn=<FQDN o indirizzo IP del DCCG>, o=<fornitore>, c=<paese> SubjectAltName (Nome alternativo del soggetto) dNSName: <nome DNS del DCCG> o iPAddress: <indirizzo IP del DCCG> Key Usage (Utilizzo della chiave) digital signature (firma digitale) (come minimo) Extended Key usage (Utilizzo esteso della chiave) server authentication (autenticazione del server) (1.3.6.1.5.5.7.3.1)

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

▼M1









ALLEGATO V

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.

▼M3

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.







ID del campo Nome del campo Istruzioni ver Versione dello schema Deve corrispondere all’identificativo della versione dello schema utilizzata per generare l’EUDCC. Esempio: «ver»:«1.3.0»

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.







ID del campo Nome del campo Istruzioni nam/fn Cognome/i Cognome/i del titolare. Se il titolare non ha cognomi e ha un nome, il campo deve essere tralasciato. In tutti gli altri casi deve essere fornito esattamente 1 (un) campo non vuoto, che include tutti i cognomi. In caso di più cognomi, questi devono essere separati da uno spazio. I nomi composti che comprendono trattini o caratteri simili devono tuttavia rimanere invariati. Esempi: «fn»:«Musterfrau-Gößinger» «fn»:«Musterfrau-Gößinger Müller» nam/fnt Cognome/i standardizzato/i Cognome/i del titolare traslitterato utilizzando la stessa convenzione utilizzata nei documenti di viaggio a lettura ottica del titolare (come le norme definite nel documento ICAO 9303, parte 3). Se il titolare non ha cognomi e ha un nome, il campo deve essere tralasciato. In tutti gli altri casi, deve essere fornito esattamente 1 (un) campo non vuoto, che include solo i caratteri A-Z e <. Lunghezza massima: 80 caratteri (come da specifica ICAO 9303). Esempi: «fnt»:«MUSTERFRAU<GOESSINGER» «fnt»:«MUSTERFRAU<GOESSINGER<MUELLER» nam/gn Nome/i Nome/i del titolare. Se il titolare non ha nomi e ha un cognome, il campo deve essere tralasciato. In tutti gli altri casi, deve essere fornito esattamente 1 (un) campo non vuoto, che include tutti i nomi. In caso di più nomi, questi devono essere separati da uno spazio. Esempio: «gn»:«Isolde Erika» nam/gnt Nome/i standardizzato/i Nome/i del titolare traslitterato utilizzando la stessa convenzione utilizzata nei documenti di viaggio a lettura ottica del titolare (come le norme definite nel documento ICAO 9303, parte 3). Se il titolare non ha nomi e ha un cognome, il campo deve essere tralasciato. In tutti gli altri casi, deve essere fornito esattamente 1 (un) campo non vuoto, che include solo i caratteri A-Z e <. Lunghezza massima: 80 caratteri. Esempio: «gnt»:«ISOLDE<ERIKA» dob Data di nascita Data di nascita del titolare del DCC. Data completa o parziale senza ora, limitata all’intervallo da 1900-01-01 a 2099-12-31. Se la data di nascita completa o parziale è nota, deve essere fornito esattamente 1 (un) campo non vuoto. Se la data di nascita non è nota, neanche parzialmente, il campo deve contenere una stringa vuota «». Il contenuto del campo dovrebbe corrispondere alle informazioni riportate sui documenti di viaggio. Se sono disponibili informazioni sulla data di nascita, deve essere utilizzato uno dei seguenti formati ISO 8601. Altre opzioni non sono supportate. AAAA-MM-GG AAAA-MM AAAA (L’app di verifica può indicare le parti mancanti della data di nascita utilizzando la stessa convenzione XX utilizzata nei documenti di viaggio a lettura ottica, ad esempio 1990-XX-XX.) Esempi: «dob»:«1979-04-14» «dob»:«1901-08» «dob»:«1939» «dob»:”"

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.







Identificativo del gruppo Nome del gruppo Voci v Gruppo Vaccinazione Se presente, deve contenere esattamente 1 (una) voce che descriva esattamente 1 (una) dose di vaccinazione (una dose). t Gruppo Test Se presente, deve contenere esattamente 1 (una) voce che descriva esattamente 1 (un) risultato del test. r Gruppo Guarigione Se presente, deve contenere esattamente 1 (una) voce che descriva 1 (una) dichiarazione di guarigione.

▼M1

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.







ID campo Nome del campo Istruzioni v/tg Malattia o agente in questione: COVID-19 (SARS-CoV-2 o una delle sue varianti) Un valore codificato dalla serie di valori disease-agent-targeted.json. Questa serie di valori ha un'unica voce 840539006, che è il codice per la COVID-19 dallo SNOMED CT (GPS). Deve essere fornito esattamente 1 (un) campo non vuoto. Esempio: "tg":"840539006" v/vp Vaccino o profilassi anti COVID-19 Tipo di vaccino o profilassi utilizzato/a. Un valore codificato dalla serie di valori vaccine-prophylaxis.json. La serie di valori è distribuita dal Gateway dell'EUDCC. Deve essere fornito esattamente 1 (un) campo non vuoto. Esempio: "vp":"1119349007" (un vaccino anti SARS-CoV-2 mRNA) v/mp Prodotto vaccinale anti COVID-19 Medicinale utilizzato per questa dose specifica di vaccino. ►M4

Un valore codificato dalla serie di valori

vaccine-medicinal-product.json.

O un valore codificato riferito a una sperimentazione clinica e conforme alla regola definita all’allegato II, sezione 3. ◄

La serie di valori è distribuita dal Gateway dell'EUDCC.

Deve essere fornito esattamente 1 (un) campo non vuoto. Esempio:

"mp":"EU/1/20/1528" (Comirnaty) v/ma Titolare dell'autorizzazione all'immissione in commercio del vaccino anti COVID-19 o fabbricante del vaccino Titolare dell'autorizzazione all'immissione in commercio o fabbricante, se non è presente alcun titolare dell'autorizzazione all'immissione in commercio. ►M4

Un valore codificato dalla serie di valori

vaccine-mah-manf.json.

O un valore codificato riferito a una sperimentazione clinica e conforme alla regola definita all’allegato II, sezione 4. ◄

La serie di valori è distribuita dal Gateway dell'EUDCC.

Deve essere fornito esattamente 1 (un) campo non vuoto. Esempio:

"ma":"ORG-100030215" (Biontech Manufacturing GmbH) v/dn Numero in una serie di dosi Numero sequenziale (numero intero positivo) della dose somministrata durante questo evento vaccinale. 1 per la prima dose, 2 per la seconda dose, ecc. Ulteriori norme specifiche sono contenute nell'allegato II, punto 5. Deve essere fornito esattamente 1 (un) campo non vuoto. Esempi: "dn":"1" (prima dose) "dn":"2" (seconda dose) "dn":"3" (terza dose) v/sd Numero complessivo di dosi della serie Numero complessivo di dosi (numero intero positivo) della serie di vaccinazione. Norme più specifiche sono contenute nella sezione 5 dell'allegato II. Deve essere fornito esattamente 1 (un) campo non vuoto. Esempi: "sd":"1" (in caso di un ciclo di vaccinazione primaria che prevede 1 dose) "sd":"2" (nel caso di una serie di vaccinazione primaria che prevede 2 dosi o una dose aggiuntiva dopo un ciclo di vaccinazione primaria che prevede 1 dose) "sd":"3" (ad esempio nel caso di dosi aggiuntive dopo una serie di vaccinazione primaria che prevede 2 dosi) v/dt Data della vaccinazione La data in cui è stata ricevuta la dose indicata, nel formato AAAA-MM-GG (data completa senza ora). Altri formati non sono supportati. Deve essere fornito esattamente 1 (un) campo non vuoto. Esempio: "dt":"2021-03-28" v/co Stato membro o paese terzo in cui è stato somministrato il vaccino Paese espresso come codice ISO3166 a due lettere (RACCOMANDATO) o come riferimento a un'organizzazione internazionale responsabile dell'evento vaccinale (come l'UNHCR o l'OMS). Un valore codificato dalla serie di valori country-2-codes.json. La serie di valori è distribuita dal Gateway dell'EUDCC. Deve essere fornito esattamente 1 (un) campo. Esempio: "co":"CZ" "co":"UNHCR" v/is Soggetto che ha rilasciato il certificato Nome dell'organizzazione che ha rilasciato il certificato. Gli identificatori sono ammessi come parte del nome, si raccomanda di non utilizzarli singolarmente senza il nome in formato testo. Massimo 80 caratteri UTF-8. Deve essere fornito esattamente 1 (un) campo non vuoto. Esempio: "is":"Ministero della Sanità della Repubblica ceca" "is":"Centro di vaccinazione distret