02021D1073 — RO — 15.09.2022 — 004.001

---

Acest document are doar scop informativ și nu produce efecte juridice. Instituțiile Uniunii nu își asumă răspunderea pentru conținutul său. Versiunile autentice ale actelor relevante, inclusiv preambulul acestora, sunt cele publicate în Jurnalul Oficial al Uniunii Europene și disponibile pe site-ul EUR-Lex. Aceste texte oficiale pot fi consultate accesând linkurile integrate în prezentul document.

►B

DECIZIA DE PUNERE ÎN APLICARE (UE) 2021/1073 A COMISIEI din 28 iunie 2021 de stabilire a specificațiilor tehnice și a regulilor de punere în aplicare a cadrului de încre dere pentru certificatul digital al UE privind COVID instituit prin Regulamentul (UE) 2021/953 al Parlamentului European și al Consiliului (Text cu relevanță pentru SEE) (JO L 230 30.6.2021, p. 32)

Astfel cum a fost modificată prin:

		Jurnalul Oficial
		NR.	Pagina	Data
►M1	DECIZIA DE PUNERE ÎN APLICARE (UE) 2021/2014 A COMISIEI din 17 noiembrie 2021	L 410	180	18.11.2021
►M2	DECIZIA DE PUNERE ÎN APLICARE (UE) 2021/2301 A COMISIEI din 21 decembrie 2021	L 458	536	22.12.2021
►M3	DECIZIA DE PUNERE ÎN APLICARE (UE) 2022/483 A COMISIEI din 21 martie 2022	L 98	84	25.3.2022
►M4	DECIZIA DE PUNERE ÎN APLICARE (UE) 2022/1516 A COMISIEI din 8 septembrie 2022	L 235	61	12.9.2022

---

▼B

DECIZIA DE PUNERE ÎN APLICARE (UE) 2021/1073 A COMISIEI

din 28 iunie 2021

de stabilire a specificațiilor tehnice și a regulilor de punere în aplicare a cadrului de încre dere pentru certificatul digital al UE privind COVID instituit prin Regulamentul (UE) 2021/953 al Parlamentului European și al Consiliului

(Text cu relevanță pentru SEE)

Articolul 1

Specificațiile tehnice pentru certificatul digital al UE privind COVID care stabilesc structura datelor generice, mecanismele de codare și mecanismul de codare pentru transport într-un format optic care poate fi citit automat sunt stabilite în anexa I.

Articolul 2

Regulile de completare a certificatelor menționate la articolul 3 alineatul (1) din Regulamentul (UE) 2021/953 sunt stabilite în anexa II la prezenta decizie.

Articolul 3

Cerințele care stabilesc structura comună a identificatorului unic al certificatului sunt stabilite în anexa III.

▼M1

Articolul 4

Normele de guvernanță aplicabile certificatelor de chei publice în legătură cu gateway-ul pentru certificatul digital al UE privind COVID care sprijină aspectele de interoperabilitate ale cadrului de încredere sunt prevăzute în anexa IV.

▼M1

Articolul 5

O structură comună coordonată a datelor care trebuie incluse în certificatele menționate la articolul 3 alineatul (1) din Regulamentul (UE) 2021/953, utilizând o schemă JavaScript Object Notation (JSON), este prevăzută în anexa V la prezenta decizie.

▼M3

Articolul 5a

Schimbul de liste cu certificatele revocate

Articolul 5b

Transmiterea de către țările terțe de liste cu certificatele revocate

Țările terțe care eliberează certificate privind COVID-19 pentru care Comisia a adoptat un act de punere în aplicare în temeiul articolului 3 alineatul (10) sau al articolului 8 alineatul (2) din Regulamentul (UE) 2021/953 pot prezenta liste cu certificatele privind COVID-19 revocate care fac obiectul unui astfel de act de punere în aplicare, pentru a fi prelucrate de Comisie în numele operatorilor asociați, în cadrul gateway-ului, astfel cum se menționează la articolul 5a, în conformitate cu specificațiile tehnice prevăzute în anexa I.

Articolul 5c

Guvernanța prelucrării datelor cu caracter personal în gateway-ul central pentru certificatele digitale ale UE privind COVID

▼M1

Articolul 6

Prezenta decizie intră în vigoare la data publicării în Jurnalul Oficial al Uniunii Europene.

▼B

Prezenta decizie intră în vigoare la data publicării în Jurnalul Oficial al Uniunii Europene.

---

ANEXA I

FORMATUL ȘI GESTIONAREA CADRULUI DE ÎNCREDERE

Structura datelor generice, mecanismele de codare și mecanismul de codare pentru transport într-un format optic care poate fi citit automat (denumit în continuare „QR”)

1.    Introducere

Specificațiile tehnice stabilite în prezenta anexă conțin o structură a datelor generice și mecanisme de codare pentru certificatul digital al UE privind COVID („DCC”). Acestea specifică, de asemenea, un mecanism de codare pentru transport într-un format optic care poate fi citit automat („QR”) și care poate fi afișat pe ecranul unui dispozitiv mobil sau imprimat. Formatele container ale certificatului de sănătate electronic aferente specificațiilor menționate sunt generice, dar, în acest context, sunt utilizate pentru a purta DCC.

2.    Terminologie

În sensul prezentei anexe, „emitenți” înseamnă organismele care utilizează aceste specificații pentru emiterea certificatelor de sănătate și „verificatori” înseamnă organismele care acceptă certificatele de sănătate ca dovadă a stării de sănătate. „Participanți” înseamnă emitenții și verificatorii. Unele aspecte prevăzute în prezenta anexă, cum ar fi gestionarea unui spațiu de nume și distribuirea cheilor de criptare, trebuie să facă obiectul coordonării între participanți. Se presupune că una dintre părți, denumită în continuare „secretariatul”, îndeplinește aceste sarcini.

3.    Formatul container al certificatului de sănătate electronic

Formatul container al certificatului de sănătate electronic (Electronic Health Certificate Container Format – HCERT) este conceput pentru a asigura un vehicul uniform și standardizat pentru certificatele de sănătate eliberate de diferiți emitenți („emitenții”). Obiectivul prezentelor specificații este de a armoniza modul în care certificatele de sănătate sunt reprezentate, codate și semnate, cu scopul de a facilita interoperabilitatea.

Capacitatea de a citi și interpreta un DCC, indiferent care este emitentul său, necesită o structură de date comună și ajungerea la un acord cu privire la semnificația fiecărui câmp de date al sarcinii utile. Pentru a facilita o astfel de interoperabilitate, se definește o structură de date comună coordonată, prin utilizarea unei scheme JSON (JavaScript Object Notation – notarea obiectelor în JavaScript), care constituie cadrul DCC.

3.1.    Structura sarcinii utile

Sarcina utilă este structurată și codată sub formă de CBOR (Concise Binary Object Representation – reprezentarea concisă a obiectelor binare), cu o semnătură digitală în formatul COSE (CBOR Object Signing and Encryption – semnarea și criptarea de obiecte utilizând CBOR). Aceasta este cunoscută sub denumirea de „token web CBOR” (CWT) și este definită în RFC 8392 ( 1 ). Sarcina utilă, astfel cum este definită în secțiunile următoare, este transportată într-o revendicare hcert.

Integritatea și autenticitatea originii datelor privind sarcina utilă trebuie să poată fi verificate de verificator. Pentru a furniza acest mecanism, emitentul trebuie să semneze CWT utilizând un sistem asimetric de semnătură electronică, astfel cum este definit în specificația privind COSE (RFC 8152 ( 2 )).

3.2.    Revendicări CWT

3.2.1.    Prezentare generală a structurii CWT

Antet protejat

Sarcină utilă

Semnătură

3.2.2.    Algoritmul de semnătură

Parametrul algoritmului de semnătură (alg) indică algoritmul care a fost utilizat pentru crearea semnăturii. Acesta trebuie să respecte sau chiar să depășească orientările actuale ale SOG-IS (Senior Officials Group Information Systems Security – Grupul înalților funcționari pentru securitatea sistemelor informatice), astfel cum sunt rezumate în paragrafele următoare.

Se definesc un algoritm primar și unul secundar. Algoritmul secundar ar trebui utilizat numai în cazul în care algoritmul primar nu este acceptabil conform normelor și reglementărilor impuse emitentului.

Pentru a asigura securitatea sistemului, ar trebui ca toate punerile în aplicare să includă algoritmul secundar. Din acest motiv, trebuie aplicat atât algoritmul primar, cât și cel secundar.

Nivelurile stabilite de SOG-IS pentru algoritmul primar și pentru cel secundar sunt următoarele:

Acesta corespunde parametrului ES256 al algoritmului COSE.

Acesta corespunde algoritmului COSE, parametrul PS256.

3.2.3.    Identificatorul cheii

Revendicarea privind identificatorul cheii (kid) indică certificatul de semnatar de documente (DSC) care conține cheia publică pe care verificatorul trebuie să o utilizeze atunci când verifică dacă semnătura digitală este corectă. Guvernanța certificatelor de cheie publică, inclusiv cerințele pentru DSC-uri, este descrisă în anexa IV.

Revendicarea privind identificatorul cheii (kid) este utilizată de verificatori pentru selectarea cheii publice corecte dintr-o listă de chei aferente emitentului indicat în revendicarea privind emitentul (iss). Un emitent poate utiliza în paralel mai multe chei, din motive administrative și atunci când efectuează reînnoirea cheilor. Identificatorul cheii nu este un câmp critic din punctul de vedere al securității. Din acest motiv, el poate fi plasat și într-un antet neprotejat, dacă este necesar. Verificatorii trebuie să accepte ambele opțiuni. În cazul în care sunt prezente ambele opțiuni, trebuie utilizat identificatorul cheii din antetul protejat.

Din cauza scurtării identificatorului (din motive de limitare a dimensiunii), există o șansă redusă, dar nu egală cu zero, ca lista globală a DSC-urilor (Document Signer Certificates – certificate ale semnatarilor de documente) acceptate de un verificator să conțină DSC-uri cu același kid. Din acest motiv, verificatorul trebuie să verifice toate DSC-urile cukid-ul respectiv.

3.2.4.    Emitent

Revendicarea privind emitentul (iss) este o valoare de tip șir care poate conține codul de țară ISO 3166-1 alpha-2 al entității care eliberează certificatul de sănătate. Această revendicare poate fi utilizată de un verificator pentru a identifica setul de DSC-uri care urmează să fie utilizate pentru verificare. Pentru a identifica această revendicare se utilizează cheia de revendicare 1.

3.2.5.    Momentul expirării

Revendicarea privind momentul expirării (exp) trebuie să conțină o marcă temporală în formatul de tip număr întreg NumericDate (astfel cum se specifică în RFC 8392 ( 4 ), secțiunea 2), care indică perioada de valabilitate a acestei semnături specifice asupra sarcinii utile, după încheierea căreia verificatorul trebuie să respingă sarcina utilă ca fiind expirată. Scopul parametrului de expirare este de a impune o limită la perioada de valabilitate a certificatului de sănătate. Pentru a identifica această revendicare se utilizează cheia de revendicare 4.

Momentul expirării nu trebuie să depășească perioada de valabilitate a DSC.

3.2.6.    Emis la

Revendicarea „emis la” (iat) trebuie să conțină o marcă temporală în formatul de tip număr întreg NumericDate (astfel cum se specifică în RFC 8392 ( 5 ), secțiunea 2), indicând momentul în care a fost creat certificatul de sănătate.

Câmpul „emis la” nu trebuie să conțină o dată anterioară perioadei de valabilitate a DSC.

Verificatorii pot să aplice și alte politici cu scopul de a limita valabilitatea certificatului de sănătate în funcție de momentul emiterii. Pentru a identifica această revendicare se utilizează cheia de revendicare 6.

3.2.7.    Revendicarea privind certificatul de sănătate

Revendicarea privind certificatul de sănătate (hcert) este un obiect JSON (RFC 7159 ( 6 )) care conține informații privind starea de sănătate. În cadrul aceleiași revendicări pot exista mai multe tipuri de certificate de sănătate, printre care și DCC.

Formatul JSON este utilizat exclusiv pentru scheme. Formatul de reprezentare este CBOR, astfel cum este definit în (RFC 7049 ( 7 )). Este posibil ca, în realitate, dezvoltatorii de aplicații să nu decodeze sau să codeze niciodată în și din format JSON, ci să utilizeze în schimb structura integrată în memorie.

Pentru a identifica această revendicare se utilizează cheia de revendicare -260.

Șirurile din obiectul JSON ar trebui normalizate în conformitate cu forma de normalizare NFC (Normalization Form Canonical Composition - forma de normalizare cu compunere canonică) definită în standardul Unicode. Cu toate acestea, aplicațiile de decodare ar trebui să fie permisive și robuste în aceste privințe, iar acceptarea oricărui tip de conversie rezonabilă este puternic încurajată. În cazul în care, în timpul decodării sau în funcțiile de comparare ulterioară, se descoperă date nenormalizate, punerile în aplicare ar trebui să se comporte ca și cum datele de intrare ar fi normalizate pentru NFC.

4.    Serializarea și crearea sarcinii utile a DCC

Ca model de serializare, se utilizează următoarea schemă:

Procesul începe cu extragerea de date, de exemplu, dintr-un registru de date privind sănătatea (sau dintr-o sursă de date externă), structurând datele extrase în conformitate cu schemele DCC definite. În acest proces, conversia în formatul de date definit și transformarea pentru a permite lizibilitatea umană pot avea loc înainte de începerea serializării în format CBOR. Acronimele revendicărilor trebuie puse în corespondență, în fiecare caz, cu denumirile de afișare înainte de serializare și după deserializare.

Conținutul opțional de date naționale nu este permis în certificatele eliberate în conformitate cu Regulamentul (UE) nr. 2021/953 ( 8 ). Conținutul datelor se limitează la elementele de date definite în setul minim de date specificat în anexa la Regulamentul 2021/953.

5.    Codările pentru transport

5.1.    Forma brută

Pentru interfețele de date arbitrare, formatul container al certificatului HCERT și sarcinile sale utile pot fi transferate ca atare, utilizând orice tip de transport de date subiacent sigur și fiabil cu 8 biți. Interfețele respective pot include comunicarea în câmp apropiat (Near-Field Communication – NFC), Bluetooth sau transfer prin intermediul unui protocol privind nivelul de aplicație, de exemplu transferul unui certificat HCERT de la emitent către dispozitivul mobil al unui titular.

În cazul în care transferul certificatului HCERT de la emitent către titular se bazează pe o interfață exclusiv de prezentare (de exemplu, SMS sau e-mail), codarea pentru transport brută nu este, în mod evident, aplicabilă.

5.2.    Codul de bare

5.2.1.    Compresia sarcinii utile (CWT)

Pentru a reduce dimensiunea și a îmbunătăți viteza și fiabilitatea procesului de citire a certificatelor HCERT, CWT trebuie comprimat utilizând formatul ZLIB (RFC 1950 ( 9 )) și mecanismul de compresie Deflate, în formatul definit în RFC 1951 ( 10 ).

5.2.2.    Codul de bare QR 2D

Pentru a gestiona mai bine echipamentele tradiționale concepute să funcționeze pe sarcini utile ASCII (American Standard Code for Information Interchange – Codul standard american pentru schimbul de informații), CWT comprimat este codificat ca ASCII cu ajutorul schemei de codare Base45, înainte de a fi codat într-un cod de bare 2D.

Pentru generarea de coduri de bare 2D trebuie utilizat formatul QR, astfel cum este definit în (ISO/IEC 18004:2015). Se recomandă o rată de corecție a erorilor egală cu „Q” (de aproximativ 25 %). Deoarece se utilizează Base45, codul QR trebuie să utilizeze codarea alfanumerică (modul 2, indicat de simbolurile 0010).

Pentru ca verificatorii să poată detecta tipul de date codate și să selecteze schema corespunzătoare de decodare și prelucrare, datele codate cu ajutorul schemei de codare Base45 (în conformitate cu prezenta specificație) trebuie să fie precedate de identificatorul de context sub formă de șir „HC1:”. Versiunile viitoare ale prezentei specificații de natură să afecteze compatibilitatea inversă vor defini un nou identificator de context, iar caracterul care urmează după literele „HC” trebuie selectat din setul de caractere [1-9A-Z]. Ordinea incrementelor este definită în această ordine, și anume mai întâi [1-9] și apoi [A-Z].

Se recomandă ca, în cadrul mediului de prezentare, codul optic să aibă o diagonală cuprinsă între 35 mm și 60 mm, pentru a permite utilizarea de cititoare cu elemente optice fixe pentru care mediul de prezentare trebuie amplasat pe suprafața cititorului.

În cazul în care codul optic este imprimat pe hârtie cu ajutorul unei imprimante cu rezoluție mică (< 300 dpi), trebuie să se acorde atenție reprezentării cu precizie a fiecărui simbol (punct) al codului QR, astfel încât acesta să aibă formă pătrată. Scalarea neproporțională va face ca unele rânduri sau coloane din QR să aibă simboluri dreptunghiulare, ceea ce, în multe cazuri, va afecta lizibilitatea.

6.    Formatul listelor de încredere (lista CSCA și lista DSC)

Fiecare stat membru trebuie să furnizeze o listă cuprinzând una sau mai multe autorități naționale de certificare pentru semnătură (CSCA) și o listă a tuturor certificatelor de semnatar de documente (DSC) în termen de valabilitate, și să asigure actualizarea acestor liste.

6.1.    CSCA/DSC simplificate

Începând cu versiunea curentă a specificațiilor, statele membre nu trebuie să pornească de la prezumția că informațiile din lista certificatelor revocate (CRL) sunt utilizate sau că perioada de utilizare a cheii private este verificată de către entitățile care asigură punerea în aplicare.

În schimb, mecanismul principal de verificare a perioadei de valabilitate este prezența certificatului pe cea mai recentă versiune a respectivei liste de certificate.

6.2.    Documentul de călătorie electronic cu citire optică (eMRTD) și certificatul de cheie publică PKI ale Organizației Aviației Civile Internaționale (OACI) și centrele de încredere

Statele membre pot utiliza o CSCA separată, dar pot, de asemenea, să transmită certificatele eMRTD emise de CSCA existentă și/sau DSC-urile deja existente și pot alege chiar să achiziționeze certificate de la centre de încredere (comerciale) și să le transmită. Cu toate acestea, orice DSC trebuie să fie întotdeauna semnat de CSCA prezentată de statul membru respectiv.

7.    Considerente de securitate

Atunci când proiectează o schemă care utilizează această specificație, statele membre trebuie să identifice, să analizeze și să monitorizeze anumite aspecte legate de securitate.

Trebuie luate în considerare cel puțin următoarele aspecte:

7.1.    Perioada de valabilitate a semnăturii certificatelor HCERT

Emitentul certificatului HCERT trebuie să limiteze perioada de valabilitate a semnăturii prin specificarea momentului la care expiră semnătura. Prin urmare, titularul unui certificat de sănătate este obligat să îl reînnoiască periodic.

Perioada de valabilitate acceptabilă poate fi determinată de constrângeri practice. De exemplu, este posibil ca un călător să nu aibă posibilitatea de a-și reînnoi certificatul de sănătate în timpul unei călătorii în străinătate. Cu toate acestea, se poate întâmpla, de asemenea, ca un emitent să ia în considerare posibilitatea ca securitatea să fie compromisă, emitentul fiind nevoit să retragă un DSC (invalidând toate certificatele de sănătate eliberate cu ajutorul cheii respective care sunt încă valabile). Consecințele unui astfel de eveniment pot fi limitate prin reînnoirea periodică a cheilor emitenților și prin impunerea reînnoirii tuturor certificatelor de sănătate într-un interval rezonabil.

7.2.    Gestionarea cheilor

Prezenta specificație se bazează în mare măsură pe mecanisme criptografice solide, menite să asigure integritatea datelor și autentificarea originii datelor. Prin urmare, este necesar să se mențină confidențialitatea cheilor private.

Confidențialitatea cheilor criptografice poate fi compromisă în mai multe moduri, de exemplu:

Pentru a atenua riscurile de a se constata că algoritmul de semnare este slab și permite compromiterea cheilor prin criptanaliză, prezenta specificație recomandă ca toți participanții să aplice un algoritm de semnătură secundar, de rezervă, bazat pe parametri diferiți sau pe o problemă matematică diferită față de cea pentru algoritmul primar.

În ceea ce privește riscurile menționate legate de mediile de operare ale emitenților, trebuie puse în aplicare măsuri de atenuare care să asigure un control eficace, astfel încât să se genereze, să se stocheze și să se utilizeze cheile private din modulele de securitate hardware (HSM). Se încurajează puternic utilizarea modulelor HSM pentru semnarea certificatelor de sănătate.

Indiferent dacă un emitent decide să utilizeze sau nu modulele HSM, ar trebui stabilit un calendar de reînnoire a cheilor care să prevadă o frecvență a reînnoirii cheilor proporțională cu expunerea cheilor la rețele externe, la alte sisteme și la personal. Un calendar de reînnoire bine ales limitează, totodată, riscurile asociate certificatelor de sănătate eliberate în mod eronat, prin faptul că îi permite unui emitent să revoce aceste certificate de sănătate pe loturi, prin retragerea unei chei, dacă acest lucru se dovedește necesar.

7.3.    Validarea datelor de intrare

Prezentele specificații pot fi utilizate într-un mod care implică primirea de date din surse nefiabile în sisteme care pot fi esențiale pentru îndeplinirea misiunii stabilite. Pentru a reduce la minimum riscurile asociate acestui vector de atac, toate câmpurile de intrare trebuie să fie validate în mod corespunzător, în funcție de tipul, lungimea și conținutul datelor. Înainte de prelucrarea conținutului certificatului HCERT, trebuie verificată, de asemenea, semnătura emitentului. Cu toate acestea, validarea semnăturii emitentului implică analizarea prealabilă a antetului protejat al emitentului, în care un potențial atacator poate încerca să introducă informații atent formulate, concepute pentru a compromite securitatea sistemului.

8.    Gestionarea încrederii

Semnătura certificatului HCERT necesită o cheie publică pentru a fi verificată. Statele membre trebuie să pună la dispoziție aceste chei publice. În ultimă instanță, fiecare verificator trebuie să aibă o listă a tuturor cheilor publice în care este dispus să aibă încredere (având în vedere faptul că o cheie publică nu face parte din certificatul HCERT).

Sistemul este format din (numai) două niveluri: pentru fiecare stat membru, unul sau mai multe certificate la nivel de țară, fiecare dintre acestea servind la semnarea unuia sau a mai multor certificate de semnatar de documente, care sunt utilizate în operațiunile zilnice.

Certificatele statelor membre se numesc certificate ale autorităților naționale de certificare pentru semnătură (CSCA) și sunt (de regulă) certificate autosemnate. Un stat membru poate avea mai multe astfel de certificate (de exemplu, în cazul deconcentrării regionale). Aceste certificate CSCA semnează periodic certificatele de semnatar de documente (DSC) utilizate pentru semnarea certificatelor HCERT.

„Secretariatul” este un rol funcțional. Acesta trebuie să agrege și să publice periodic DSC-urile statelor membre, după ce verifică dacă acestea se regăsesc în lista certificatelor CSCA (care au fost transmise și verificate prin alte mijloace).

Lista de certificate DSC rezultată trebuie să furnizeze apoi setul agregat de chei publice acceptabile (și kid-urile corespunzătoare) pe care verificatorii le pot utiliza pentru a valida semnăturile pentru certificatele HCERT. Verificatorii trebuie să obțină și să actualizeze această listă în mod regulat.

Aceste liste specifice fiecărui stat membru pot fi adaptate în formatul corespunzător situației existente la nivel național. Din acest motiv, formatul fișierului acestei liste de încredere poate varia, de exemplu, poate fi un JWKS semnat (format pentru seturi de chei web JSON conform RFC 7517 ( 11 ) secțiunea 5) sau orice alt format specific tehnologiei utilizate în statul membru respectiv.

Pentru a asigura simplitatea, statele membre pot fie să își transmită certificatele CSCA existente din sistemele lor eMRTD conforme cu normele OACI, fie, în conformitate cu recomandările OMS, să creeze un certificat specific pentru acest domeniu al sănătății.

8.1.    Identificatorul cheii (kid)

Identificatorul cheii (kid) se calculează atunci când se elaborează lista cheilor publice de încredere pe baza certificatelor DSC și constă într-o amprentă digitală SHA-256 trunchiată (primii 8 byți) a DSC, codificată în format DER (brut).

Verificatorii nu trebuie să calculeze kid-ul pe baza certificatului DSC; ei pot corela direct identificatorul cheii din certificatul de sănătate emis cu kid-ul de pe lista de încredere.

8.2.    Diferențe față de modelul de încredere eMRTD PKI al OACI

Deși se bazează pe cele mai bune practici ale modelului de încredere eMRTD PKI al OACI, din motive de rapiditate, în prezenta specificație trebuie efectuate o serie de simplificări:

▼M3

9.    Soluția revocării

9.1.    Dispoziție privind lista DCC revocate (DRL)

Gateway-ul asigură puncte finale și funcționalitatea pentru a păstra și a gestiona listele de revocare:

9.2.    Modelul de încredere

Toate conexiunile sunt stabilite de modelul de încredere standard al DCCG prin intermediul certificatelor NBTLS și NBUP (a se vedea guvernanța certificatelor). Toate informațiile sunt regrupate și încărcate prin mesaje CMS pentru a se asigura integritatea.

9.3.    Construirea loturilor

9.3.1.    Lotul

Fiecare listă de revocare conține una sau mai multe intrări și este regrupată în loturi care conțin un set de hash-uri și metadatele acestora. Un lot este imuabil și stabilește o dată de expirare care indică momentul în care lotul poate fi șters. Data expirării tuturor elementelor din lot trebuie să fie exact aceeași – ceea ce înseamnă că loturile trebuie grupate în funcție de data expirării și prin semnarea DSC. Fiecare lot conține maximum 1 000  de intrări. În cazul în care lista de revocare cuprinde mai mult de 1 000  de intrări, se creează mai multe loturi. Orice intrare poate avea loc în cel mult un lot. Lotul este grupat într-o structură CMS și este semnat de certificatul NBup al țării care îl încarcă.

9.3.2.    Indexul loturilor

Atunci când se creează un lot, acestuia i se atribuie un identificator unic de către gateway și se adaugă automat la index. Indexul loturilor este ordonat în funcție de data modificată, în ordine cronologică crescătoare.

9.3.3.    Comportamentul gateway-ului

Gateway-ul prelucrează loturi de revocare fără nicio modificare: acesta nu poate nici să actualizeze, nici să elimine și nici să adauge vreo informație în loturi. Loturile sunt trimise tuturor țărilor autorizate (a se vedea capitolul 9.6).

Gateway-ul observă în mod activ datele de expirare a loturilor și elimină loturile expirate. După ce lotul este șters, gateway-ul returnează un răspuns „HTTP 410 Gone” pentru URL-ul lotului șters. Prin urmare, lotul apare în indexul loturilor ca fiind „șters”.

9.4.    Tipuri de hash

Lista de revocare conține hash-uri care pot reprezenta diferite tipuri/atribute de revocare. Aceste tipuri sau atribute sunt indicate odată cu transmiterea listelor de revocare. Tipurile curente sunt:

Doar primii 128 de biți de hash-uri codificați ca șiruri base64 sunt introduși în loturi și utilizați pentru a identifica DCC revocat ( 12 ).

9.4.1.    Tipul de hash SHA256(DCC Signature)

În acest caz, hash-ul se calculează pe octeți ai semnăturii COSE_SIGN1 din CWT. Pentru semnăturile RSA, întreaga semnătură va fi utilizată ca intrare. Formula pentru certificatele semnate de EC DSA utilizează valoarea r ca intrare:

SHA256(r)

[necesar pentru toate noile implementări]

9.4.2.    Tipul de hash SHA256(UCI)

În acest caz, hash-ul se calculează pe șirul UCI codificat în UTF-8 și convertit într-o rețea de octeți.

[perimat ( 13 ), dar susținut pentru compatibilitatea inversă]

9.4.3.    Tipul de hash SHA256[Codul țării emitente(CountryCode)+UCI]

În acest caz, CountryCode codificat ca un șir UTF-8 concatenat cu UCI codificat cu un șir UTF-8. Acesta este apoi transformat într-o rețea de octeți și utilizat ca intrare în funcția de hash.

[perimat2, dar susținut pentru compatibilitatea inversă]

9.5.    Structura API

9.5.1.    API care asigură intrarea revocării

9.5.1.1.   Obiectivul

API asigură intrările din lista de revocare în loturi, inclusiv un index al loturilor.

9.5.1.2.   Puncte finale

9.5.1.2.1.   Punctul final pentru descărcarea listei lotului

Punctele finale urmează un model simplu, returnând o listă de loturi cu un wrapper de mici dimensiuni care furnizează metadate. Loturile sunt sortate după dată în ordine crescătoare (cronologică):

/revocation-list

Verb: GET

Content-Type: application/json

Response: JSON Array

Notă: Rezultatul este limitat, implicit, la 1 000 . Dacă indicatorul „more” este setat la „true”, răspunsul indică faptul că sunt disponibile mai multe loturi în vederea descărcării. Pentru a descărca mai multe elemente, clientul trebuie să seteze antetul If-Modified-Since la o dată care să nu fie anterioară ultimei intrări primite.

Răspunsul conține o rețea JSON cu următoarea structură:

9.5.1.2.1.1.    Coduri de răspuns

Antetul cererii

9.5.1.2.2.   Punctul final pentru descărcarea lotului

Loturile conțin o listă de identificatori ai certificatelor:

/revocation-list/{batchId}

Verb: GET

Accepts: application/cms

Response:CMS with Content

Răspunsul conține un CMS care include o semnătură care trebuie să corespundă certificatului NBUPal țării. Toate elementele din rețeaua JSON conțin următoarea structură:

9.5.1.2.2.1.   Intrări

Notă: Obiectul intrărilor conține în prezent doar un hash, dar pentru a fi compatibil cu modificările viitoare a fost ales un obiect în locul unei rețele json.

9.5.1.2.2.2.   Coduri de răspuns

9.5.1.2.2.3.   Antete de răspuns

9.5.1.2.3.   Punctul final pentru încărcarea lotului

Încărcarea se face pe același punct final prin comanda POST:

/revocation-list

Verb: POST

Accepts: application/cms

Request: CMS with Content

ContentType: application/cms

Content:

Lotul va fi semnat utilizându-se certificatul NBUP. Gateway-ul va verifica dacă semnătura a fost stabilită de NBUP pentru țara respectivă. Dacă verificarea semnăturii eșuează, atunci eșuează și încărcarea.

NOTĂ: Fiecare lot este imuabil și nu poate fi schimbat după încărcare. Cu toate acestea, poate fi șters. ID-ul fiecărui lot șters este stocat, iar încărcarea unui lot nou cu același ID este respinsă.

9.5.1.2.4.   Punctul final pentru ștergerea lotului

Un lot poate fi șters pe același punct final prin comanda DELETE:

/revocation-list

Verb: DELETE

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

Sau, din motive de compatibilitate, la următorul punct final cu comanda POST:

/revocation-list/delete

Verb: POST

Accepts: application/cms

ContentType: application/cms

Request: CMS with Content

Content:

9.6.    Protecția API/RGPD

Această secțiune specifică măsurile de implementare pentru respectarea dispozițiilor Regulamentului (UE) 2021/953 în ceea ce privește prelucrarea datelor cu caracter personal.

9.6.1.    Autentificarea existentă

Gateway-ul utilizează în prezent certificatul NBTLS pentru autentificarea țărilor care se conectează la gateway. Această autentificare poate fi utilizată pentru a stabili identitatea țării conectate la gateway. Această identitate poate fi apoi utilizată pentru a pune în aplicare controlul accesului.

9.6.2.    Controlul accesului

Pentru a putea prelucra în mod legal datele cu caracter personal, gateway-ul implementează un mecanism de control al accesului.

Gateway-ul implementează o listă de control al accesului combinată cu securitatea bazată pe roluri. În această schemă se mențin două tabele - un tabel care descrie care sunt rolurile care pot aplica anumite operațiuni anumitor resurse, celălalt tabel descrie ce roluri se atribuie și căror utilizatori.

Pentru a pune în aplicare controalele cerute în conformitate cu prezentul document sunt necesare trei roluri, și anume:

Următoarele puncte finale verifică dacă utilizatorul are rolul de RevocationListReader; dacă așa este, se acordă acces, dacă nu, se returnează un răspuns HTTP 403 Forbidden:

GET/revocation-list/

GET/revocation-list/{batchId}

Următoarele puncte finale verifică dacă utilizatorul are rolul de RevocationUploader; dacă așa este, se acordă acces, dacă nu, se returnează un răspuns HTTP 403 Forbidden:

POST/revocation-list

Următoarele puncte finale verifică dacă utilizatorul are rolul de RevocationDeleter; dacă așa este, se acordă acces, dacă nu, se returnează un răspuns HTTP 403 Forbidden:

DELETE/revocation-list

POST/revocation-list/delete

Gateway-ul asigură, de asemenea, o metodă fiabilă prin care administratorii pot gestiona rolurile care sunt legate de utilizatori astfel încât să se reducă riscul apariției unor erori umane fără a împovăra însă administratorii funcționali.

▼M1

---

ANEXA II

REGULI DE COMPLETARE A CERTIFICATULUI DIGITAL AL UE PRIVIND COVID

Regulile generale privind seturile de valori stabilite în prezenta anexă au scopul de a asigura interoperabilitatea la nivel semantic și trebuie să permită punerea în aplicare tehnică uniformă pentru certificatul digital al UE privind COVID. Elementele cuprinse în prezenta anexă pot fi utilizate pentru cele trei contexte diferite (vaccinare/testare/vindecare), astfel cum se prevede în Regulamentul (UE) 2021/953. Numai elementele pentru care este necesară standardizarea semantică prin seturi de valori codate sunt enumerate în prezenta anexă.

Responsabilitatea pentru traducerea elementelor codate în limba națională le revine statelor membre.

Pentru toate câmpurile de date care nu sunt menționate în următoarele descrieri ale seturilor de valori, codarea este descrisă în anexa V.

În cazul în care, dintr-un motiv oarecare, nu pot fi utilizate sistemele de coduri preferate enumerate mai jos, pot fi utilizate alte sisteme de coduri internaționale și trebuie elaborate recomandări privind punerea în corespondență a codurilor din celelalte sisteme de coduri cu sistemul de coduri preferat. Textul (denumirile de afișare) poate fi utilizat, în cazuri excepționale, ca mecanism de rezervă, atunci când în seturile de valori definite nu este disponibil niciun cod adecvat.

Statele membre care utilizează alte coduri în sistemele lor trebuie să pună în corespondență aceste coduri cu seturile de valori descrise. Statele membre sunt responsabile de orice astfel de puneri în corespondență.

►M4  Întrucât anumite seturi de valori bazate pe sistemele de codificare prevăzute în prezenta anexă, cum ar fi cele pentru codificarea vaccinurilor și a testelor antigenice, se schimbă frecvent, acestea trebuie publicate și actualizate periodic de către Comisie, cu sprijinul rețelei de e-sănătate și al Comitetului pentru securitate sanitară. ◄ Î Seturile de valori actualizate trebuie publicate pe site-ul relevant al Comisiei, precum și pe pagina web a rețelei de e-sănătate. Trebuie furnizat un istoric al modificărilor.

1.    Boala sau agentul vizat/boala sau agentul de care s-a vindecat titularul: COVID-19 (SARS-CoV-2 sau una dintre variantele sale)

A se utiliza în certificatele 1, 2 și 3.

Se utilizează următorul cod:

2.    Vaccinul împotriva COVID-19 sau metodele profilactice împotriva COVID-19

Sistemul de coduri preferat: SNOMED CT sau clasificarea ATC (anatomică, terapeutică și chimică).

A se utiliza în certificatul 1.

Exemple de coduri care trebuie utilizate din sistemele de coduri preferate sunt codul SNOMED CT 1119305005 (vaccin antigenic împotriva SARS-CoV-2), 1119349007 (vaccin de tip ARNm împotriva SARS-CoV-2) sau J07BX03 (vaccinuri împotriva COVID-19).

Un set de valori care stabilește codurile ce trebuie utilizate în temeiul sistemelor de coduri stabilite în prezenta secțiune trebuie publicat și actualizat periodic de către Comisie, cu sprijinul rețelei de e-sănătate. Setul de valori trebuie extins atunci când se dezvoltă și se introduc noi tipuri de vaccinuri.

3.    Medicamentul reprezentând vaccinul împotriva COVID-19

Sistemele de coduri preferate (în ordinea preferințelor):

Denumirea setului de valori: vaccin.

A se utiliza în certificatul 1.

Din sistemul de coduri preferat, un exemplu de cod care trebuie utilizat este EU/1/20/1528 (Comirnaty). Un exemplu de denumire a vaccinului care poate fi utilizată drept cod: Sputnik-V (pentru Sputnik V).

Un set de valori care stabilește codurile ce trebuie utilizate în temeiul sistemelor de coduri stabilite în prezenta secțiune trebuie publicat și actualizat periodic de către Comisie, cu sprijinul rețelei de e-sănătate.

Vaccinurile se codifică utilizând un cod existent în setul de valori publicate, chiar dacă denumirile lor sunt diferite în țări diferite. Motivul este acela că nu există încă un registru mondial al vaccinurilor care să includă toate vaccinurile utilizate în prezent. Exemplu:

În cazul în care acest lucru nu este posibil sau recomandabil într-un caz specific, în setul de valori publicate se va furniza un cod separat.

▼M4

În cazul în care o țară care utilizează certificatul digital al UE privind COVID („certificatul digital al UE privind COVID”) decide să elibereze certificate de vaccinare participanților la studii clinice în curs de desfășurare, medicamentul reprezentând vaccinul se codifică conform modelului

CT_identificator-studiu-clinic

În cazul în care studiul clinic a fost înregistrat în Registrul de studii clinice al UE (EU-CTR), se utilizează identificatorul studiului clinic din acest registru. În alte cazuri, se pot utiliza identificatori din alte registre (cum ar fi clinicaltrials.gov sau Australian New Zealand Clinical Trials Registry).

Identificatorul studiului clinic include un prefix care permite identificarea registrului de studii clinice (cum ar fi EUCTR pentru Registrul de studii clinice al UE, NCT pentru clinicaltrials.gov sau ACTRN pentru Australian New Zealand Clinical Trials Registry).

În cazul în care Comisia a primit orientări din partea Comitetului pentru securitate sanitară, a Centrului European de Prevenire și Control al Bolilor (ECDC) sau a Agenției Europene pentru Medicamente (EMA) cu privire la acceptarea certificatelor eliberate pentru un vaccin împotriva COVID-19 care face obiectul unor studii clinice, orientările se publică fie ca parte a documentului privind seturile de valori, fie separat.

▼M1

4.    Deținătorul autorizației de comercializare sau producătorul vaccinului împotriva COVID-19

Sistemul de coduri preferat:

A se utiliza în certificatul 1.

Din sistemul de coduri preferat, un exemplu de cod care trebuie utilizat este ORG-100001699 (AstraZeneca AB). Un exemplu de denumire a organizației care poate fi utilizată drept cod: Sinovac-Biotech (pentru Sinovac Biotech).

Un set de valori care stabilește codurile ce trebuie utilizate în temeiul sistemelor de coduri stabilite în prezenta secțiune trebuie publicat și actualizat periodic de către Comisie, cu sprijinul rețelei de e-sănătate.

Diferite sucursale ale aceluiași deținător al autorizației de comercializare sau ale aceluiași producător trebuie să utilizeze un cod existent în setul de valori publicate.

Ca regulă generală, pentru același vaccin se utilizează codul care face trimitere la deținătorul autorizației de comercializare în UE, deoarece nu există încă niciun registru al producătorilor de vaccinuri sau al deținătorilor de autorizații de comercializare a vaccinurilor, care să fie aprobat la nivel internațional. Exemple:

În cazul în care acest lucru nu este posibil sau recomandabil într-un caz specific, în setul de valori publicate se va furniza un cod separat.

▼M4

În cazul în care o țară care utilizează certificatul digital al UE privind COVID decide să elibereze certificate de vaccinare participanților la studii clinice în curs de desfășurare, titularul autorizației de introducere pe piață a vaccinului sau producătorul se codifică utilizând valoarea desemnată pentru acesta în setul de valori, dacă este disponibilă. În celelalte cazuri, titularul autorizației de introducere pe piață sau producătorul se codifică utilizând regula descrisă în Secțiunea 3 – Medicamentul reprezentând vaccinul împotriva COVID-19 (CT_identificator-studiu-clinic).

▼M1

5.    Numărul dintr-o serie de doze, precum și numărul total de doze din serie

A se utiliza în certificatul 1.

Două câmpuri:

5.1.    Seria de vaccinare primară

În cazul în care persoana primește doze din seria de vaccinare primară, și anume seria de vaccinare destinată să asigure o protecție suficientă într-o etapă inițială, (C) trebuie să reflecte numărul total de doze din seria de vaccinare primară standard (de exemplu, 1 sau 2, în funcție de tipul de vaccin administrat). Aceasta include opțiunea de a utiliza o serie mai scurtă (C=1) în cazul în care protocolul de vaccinare aplicat de un stat membru prevede administrarea unei doze unice dintr-un vaccin cu 2 doze persoanelor infectate anterior cu SARS-CoV-2. Prin urmare, o serie completă de vaccinare primară se indică prin N/C=1. De exemplu:

În cazul în care seria de vaccinare primară este extinsă, de exemplu în cazul persoanelor cu sisteme imunitare grav slăbite sau în cazul în care intervalul recomandat între dozele primare nu a fost respectat, orice astfel de doze se codifică drept doze suplimentare care intră sub incidența secțiunii 5.2.

▼M2

5.2.    Doze de rapel

În cazul în care persoana primește doze după seria de vaccinare primară, aceste doze de rapel se reflectă în certificatele corespunzătoare după cum urmează:

Statele membre pun în aplicare normele de încodare stabilite în prezenta secțiune până la 1 februarie 2022.

Statele membre eliberează din nou, în mod automat sau la cererea persoanelor în cauză, certificatele în care administrarea unei doze de rapel după un ciclu primar de vaccinare cu doză unică este încodată astfel încât să nu poată fi distinsă de finalizarea seriei de vaccinare primară.

În sensul prezentei anexe, trimiterile la „dozele de rapel” ar trebui înțelese ca incluzând și dozele suplimentare administrate pentru a proteja mai bine persoanele care prezintă răspunsuri imune inadecvate după finalizarea seriei de vaccinare primară standard. În cadrul juridic instituit prin Regulamentul (UE) 2021/953, statele membre pot lua măsuri pentru a aborda cu prioritate situația grupurilor vulnerabile care pot primi doze suplimentare. De exemplu, dacă un stat membru decide să administreze doze suplimentare numai unor subgrupuri specifice ale populației, acesta poate alege, în conformitate cu articolul 5 alineatul (1) din Regulamentul (UE) 2021/953, să elibereze certificate de vaccinare care să indice administrarea unor astfel de doze suplimentare numai la cerere, și nu în mod automat. În cazul în care se iau astfel de măsuri, statele membre informează persoanele în cauză cu privire la aceasta, precum și cu privire la faptul că persoanele respective pot continua să utilizeze certificatul primit în urma finalizării seriei de vaccinare primară standard.

▼M1

6.    Statul membru sau țara terță în care s-a administrat vaccinul/s-a efectuat testul

Sistemul de coduri preferat: codurile ISO 3166 ale țărilor.

A se utiliza în certificatele 1, 2 și 3.

Conținutul setului de valori: lista completă a codurilor de 2 litere, disponibilă ca set de valori definit în FHIR (Fast Healthcare Interoperability Resources – resurse rapide de interoperabilitate în domeniul sănătății) (http://hl7.org/fhir/ValueSet/iso3166-1-2). În cazul în care vaccinarea sau testul a fost efectuat de o organizație internațională (cum ar fi UNHCR sau OMS) și nu sunt disponibile informații cu privire la țară, se utilizează un cod pentru organizație. Aceste coduri suplimentare sunt publicate și actualizate periodic de către Comisie, cu sprijinul rețelei de e-sănătate.

7.    Tipul testului

A se utiliza în certificatul 2 și în certificatul 3 în cazul în care se introduce, printr-un act delegat, posibilitatea de a elibera certificate de vindecare pe baza altor tipuri de teste decât NAAT (nucleic acid amplification technique – tehnica amplificării acidului nucleic).

Se utilizează codurile prezentate în continuare.

▼M4

Codul LP217198-3 (imunoanaliză rapidă) se utilizează pentru a indica atât testele antigenice rapide, cât și testele antigenice de laborator.

▼M1

8.    Producătorul și denumirea comercială a testului utilizat (opționale pentru testul NAAT)

A se utiliza în certificatul 2.

▼M4

Setul de valori trebuie să includă selectarea testului antigenic, astfel cum este menționat în lista comună actualizată a testelor antigenice pentru COVID-19 stabilită pe baza Recomandării 2021/C 24/01 a Consiliului și aprobată de Comitetul pentru securitate sanitară. Lista este actualizată de JRC în baza de date despre dispozitivele și metodele de testare in vitro vizând diagnosticarea COVID-19, disponibilă la adresa: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat.

▼M1

Pentru acest sistem de coduri, trebuie să se utilizeze câmpuri relevante precum identificatorul dispozitivului de testare, denumirea testului și a producătorului, în formatul structurat al JRC, disponibil la adresa: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9.    Rezultatul testului

A se utiliza în certificatul 2.

Se utilizează următoarele coduri:

▼B

---

ANEXA III

STRUCTURA COMUNĂ A IDENTIFICATORULUI UNIC AL CERTIFICATULUI

1.    Introducere

Fiecare certificat digital al UE privind COVID (DCC) trebuie să includă un identificator unic al certificatului (UCI) care asigură interoperabilitatea DCC-urilor. UCI poate fi utilizat pentru a verifica certificatul. Responsabilitatea punerii în aplicare a UCI le revine statelor membre. Identificatorul UCI este un mijloc de verificare a veridicității certificatului și, după caz, de conectare la un sistem de înregistrare (de exemplu, un sistem de informații privind imunizarea). De asemenea, acești identificatori trebuie să le permită statelor membre să ateste (pe suport de hârtie și în format digital) că persoanele au fost vaccinate sau testate.

2.    Compoziția identificatorului unic al certificatului

Identificatorul UCI trebuie să urmeze o structură și un format comune care facilitează interpretabilitatea informațiilor de către om și/sau mașină și care se pot referi la elemente precum statul membru de vaccinare, vaccinul în sine și un identificator specific pentru fiecare stat membru. UCI asigură faptul că statele membre dispun de flexibilitate în ceea ce privește configurarea sa, cu respectarea deplină a legislației privind protecția datelor. Ordinea elementelor separate urmează o ierarhie definită care poate permite modificări viitoare ale componentelor, menținând în același timp integritatea structurală a identificatorului.

Soluțiile posibile pentru compoziția UCI formează un spectru în cadrul căruia modularitatea și interpretabilitatea umană reprezintă cei doi parametri principali de diversificare și o caracteristică fundamentală:

▼M1

3.    Cerințe generale

Următoarele cerințe generale trebuie să fie îndeplinite în ceea ce privește identificatorul UCI:

Trebuie să se asigure compatibilitatea inversă: statele membre care schimbă, în timp, structura identificatorilor lor (în versiunea principală, stabilită în prezent ca fiind v1) trebuie să se asigure că doi identificatori identici reprezintă același certificat/aceeași mențiune de vaccinare. Cu alte cuvinte, statele membre nu pot recicla identificatorii.

▼B

4.    Opțiuni privind identificatorii unici ai certificatului pentru certificatele de vaccinare

Orientările rețelei de e-sănătate privind certificatele verificabile de vaccinare și elementele de interoperabilitate de bază ( 17 ) prevăd diferite opțiuni aflate la dispoziția statelor membre și a altor părți care pot coexista între diferitele state membre. Statele membre pot introduce astfel de opțiuni diferite în diferite versiuni ale schemei UCI.

---

ANEXA IV

GUVERNANȚA CERTIFICATELOR CU CHEIE PUBLICĂ

1.    Introducere

Schimbul securizat și fiabil de chei de semnătură pentru certificatele digitale ale UE privind COVID (DCC) între statele membre este realizat cu ajutorul Gateway-ului pentru certificatele digitale ale UE privind COVID (DCCG), care funcționează ca un registru central pentru cheile publice. Prin intermediul DCCG, statele membre sunt împuternicite să publice cheile publice corespunzătoare cheilor private pe care le utilizează pentru a semna certificatele digitale privind COVID. Statele membre care se bazează pe DCCG pot utiliza portalul pentru a obține în timp util materiale actualizate privind cheile publice. Ulterior, DCCG poate fi extins pentru a face schimb de informații suplimentare fiabile furnizate de statele membre, cum ar fi normele de validare pentru DCC-uri. Modelul de încredere al cadrului DCC este o infrastructură de chei publice (Public Key Infrastructure – PKI). Fiecare stat membru deține una sau mai multe autorități naționale de certificare pentru semnătură (CSCA), ale căror certificate au o durată de viață relativ lungă. În funcție de decizia statului membru, CSCA poate fi aceeași cu CSCA utilizată pentru documentele de călătorie care pot fi citite automat sau poate fi diferită. CSCA emite certificate de cheie publică pentru semnatarii de documente naționale cu durată scurtă de viață (și anume, semnatarii pentru DCC-uri), care sunt denumite certificate de semnatar de documente (DSC). CSCA acționează ca o ancoră de încredere, care le permite statelor membre care se bazează pe aceasta să utilizeze certificatul CSCA pentru a valida autenticitatea și integritatea DSC-urilor, care suferă modificări periodice. Odată ce validarea a fost efectuată, statele membre pot folosi aceste certificate (sau doar cheile publice pe care le conțin) pentru aplicațiile lor de validare a DCC. Pe lângă CSCA și DSC, DCCG se bazează, de asemenea, pe infrastructurile de chei publice (PKI) pentru autentificarea tranzacțiilor, semnarea datelor, ca bază pentru autentificare și ca mijloc de asigurare a integrității canalelor de comunicare dintre statele membre și DCCG.

Semnăturile digitale pot fi utilizate pentru a se asigura integritatea și autenticitatea datelor. Infrastructurile de chei publice creează încredere prin asocierea obligatorie a unor chei publice cu anumite identități verificate (sau emitenți verificați). Acest lucru este necesar pentru a le permite celorlalți participanți să verifice originea datelor și identitatea partenerului de comunicare și să decidă dacă pot avea încredere în acestea. În cadrul DCCG se utilizează mai multe certificate de cheie publică pentru autenticitate. Prezenta anexă definește certificatele de cheie publică utilizate și modul în care acestea trebuie concepute astfel încât să permită o interoperabilitate largă între statele membre. Aceasta oferă mai multe detalii cu privire la certificatele de cheie publică necesare și oferă îndrumări cu privire la modelele de certificate și perioadele de valabilitate pentru statele membre care doresc să opereze propria lor CSCA. Întrucât DCC-urile trebuie să poată fi verificate pentru un interval de timp definit (începând de la emitere, expiră după o anumită perioadă de timp), este necesar să se definească un model de verificare pentru toate semnăturile aplicate pe certificatele de cheie publică și pe DCC.

2.    Terminologie

Tabelul următor conține abrevierile și terminologia utilizate în prezenta anexă.

3.    Fluxurile de comunicații și serviciile de securitate ale DCCG

Prezenta secțiune oferă o imagine de ansamblu asupra fluxurilor de comunicații și a serviciilor de securitate din cadrul sistemului DCCG. Acesta definește, de asemenea, cheile și certificatele utilizate pentru a proteja comunicarea, informațiile încărcate, DCC-urile și o listă de încredere semnată care conține toate certificatele CSCA integrate. DCCG funcționează ca un centru de date care face posibil schimbul de pachete de date semnate pentru statele membre.

Pachetele de date încărcate sunt furnizate de DCCG „ca atare”, ceea ce înseamnă că DCCG nu adaugă și nu șterge DSC-uri din pachetele pe care le primește. Sistemul back-end național (NB) al statelor membre trebuie să fie abilitat să verifice integritatea și autenticitatea datelor încărcate de la un capăt la altul. În plus, sistemele back-end naționale și DCCG vor utiliza autentificarea TLS reciprocă pentru a stabili o conexiune securizată. Aceasta este în plus față de semnăturile incluse în datele care fac obiectul schimbului.

3.1.    Autentificarea și stabilirea conexiunii

DCCG utilizează protocolul de securitate pe nivelul de transport (Transport Layer Security – TLS) cu autentificare reciprocă pentru a crea un canal criptat autentificat între sistemul back-end național al statului membru (NB) și mediul gateway-ului. Prin urmare, DCCG deține un certificat de server TLS, abreviat DCCGTLS, iar sistemele back-end naționale dețin un certificat de client TLS – abreviat NBTLS. Modelele de certificate sunt furnizate în secțiunea 5. Fiecare sistem back-end național poate furniza propriul certificat TLS. Acest certificat va fi inclus în mod explicit în lista albă și, prin urmare, poate fi eliberat de o autoritate de certificare de încredere publică (de exemplu, o autoritate de certificare care respectă cerințele de bază ale Forumului autorităților de certificare și al furnizorilor de browsere – Forumul CA/Browser) ori de o autoritate națională de certificare sau poate fi autosemnat. Fiecare stat membru este responsabil de datele sale naționale și de protecția cheii private utilizate pentru stabilirea conexiunii cu DCCG. Abordarea „adu-ți propriul certificat” necesită o procedură de înregistrare și identificare bine definită, precum și proceduri de revocare și de reînnoire, astfel cum sunt descrise în secțiunile 4.1, 4.2 și 4.3. DCCG utilizează o listă albă pe care sunt adăugate certificatele TLS ale sistemelor back-end naționale după ce au fost înregistrate cu succes. Numai sistemele back-end naționale care se autentifică cu o cheie privată ce corespunde unui certificat inclus în lista albă pot stabili o conexiune sigură cu DCCG. DCCG va utiliza, de asemenea, un certificat TLS care să le permită sistemelor back-end naționale să verifice dacă stabilesc într-adevăr o conexiune cu DCCG „reală” și nu cu o entitate răuvoitoare care se prezintă drept DCCG. Certificatul DCCG va fi furnizat sistemelor back-end naționale după ce au fost înregistrate cu succes. Certificatul DCCGTLS va fi emis de o autoritate de certificare de încredere publică (inclusă în toate browserele importante). Responsabilitatea de a verifica dacă au stabilit o conexiune sigură cu DCCG (de exemplu, prin compararea amprentei digitale a certificatului DCCGTLS al serverului la care s-au conectat cu amprenta furnizată după înregistrare) le revine statelor membre.

3.2.    Autoritățile naționale de certificare pentru semnătură și modelul de validare

Statele membre care participă la cadrul DCCG trebuie să utilizeze o CSCA pentru emiterea DSC-urilor. Un stat membru poate avea mai multe CSCA, de exemplu, în cazul deconcentrării regionale. Fiecare stat membru poate fie să utilizeze autoritățile de certificare existente, fie să înființeze o autoritate de certificare specială (eventual autosemnată) pentru sistemul DCC.

Statele membre trebuie să își prezinte certificatul (certificatele) CSCA operatorului DCCG în timpul procedurii oficiale de integrare. După înregistrarea cu succes a statului membru (a se vedea secțiunea 4.1 pentru mai multe detalii), operatorul DCCG va actualiza o listă de încredere semnată cuprinzând toate certificatele CSCA care sunt active în cadrul DCC. Operatorul DCCG va utiliza o pereche specială de chei asimetrice pentru a semna lista de încredere și certificatele într-un mediu offline. Cheia privată nu va fi stocată în sistemul DCCG online, astfel încât compromiterea sistemului online să nu îi permită unui atacator să compromită lista de încredere. Certificatul de ancoră de încredere DCCGTA corespunzător va fi furnizat sistemelor back-end naționale în timpul procesului de integrare.

Statele membre pot obține lista de încredere de pe gateway-ul DCCG pentru procedurile lor de verificare. CSCA este definită ca fiind autoritatea de certificare care eliberează DSC-urile; prin urmare, statele membre care utilizează o ierarhie pe mai multe niveluri a autorităților de certificare (de exemplu, Root CA –> CSCA –> DSC) trebuie să indice autoritatea de certificare subordonată care eliberează DSC-urile. În acest caz, dacă un stat membru utilizează o autoritate de certificare existentă, atunci sistemul DCC va face abstracție de tot ceea ce se află deasupra CSCA și va include în lista albă doar CSCA ca ancoră de încredere (chiar dacă este o autoritate de certificare subordonată). Acest lucru se explică prin faptul că modelul OACI permite doar două niveluri – o CSCA „rădăcină” și un DSC „frunză” semnat doar de CSCA respectivă.

În cazul în care un stat membru operează propria CSCA, acel stat membru este responsabil de funcționarea și gestionarea cheilor respectivei autorități de certificare în condiții de siguranță. CSCA acționează ca ancoră de încredere pentru DSC-uri și, prin urmare, protejarea cheii private a CSCA este esențială pentru integritatea mediului DCC. Modelul de verificare din infrastructura de cheie privată a DCC este modelul shell, care prevede că toate certificatele prezente în validarea traseului certificatelor trebuie să fie valabile la un anumit moment (și anume, la momentul validării semnăturii). Prin urmare, se aplică următoarele restricții:

Secțiunea 4.2 conține recomandări privind perioadele de valabilitate.

3.3.    Integritatea și autenticitatea datelor încărcate

Sistemele back-end naționale pot utiliza DCCG pentru a încărca și a descărca pachete de date semnate digital după autentificarea reciprocă reușită. La început, aceste pachete de date conțin DSC-urile statelor membre. Perechea de chei care este utilizată de sistemul back-end național pentru semnătura digitală a pachetelor de date încărcate în sistemul DCCG se numește pereche de chei pentru semnătura de încărcare a sistemului back-end național, iar denumirea abreviată a certificatului de cheie publică corespunzător este certificatul NBUP. Fiecare stat membru își aduce propriul certificat NBUP, care poate fi autosemnat sau emis de o autoritate de certificare existentă, cum ar fi o autoritate de certificare publică (și anume, o autoritate de certificare care eliberează certificatul în conformitate cu cerințele de bază ale forumului CA/Browser). Certificatul NBUP trebuie să fie diferit de orice alt certificat utilizat de statul membru respectiv (și anume de CSCA, de certificatul TLS de client sau de DSC-uri).

Statele membre trebuie să furnizeze certificatul de încărcare operatorului DCCG în timpul procedurii inițiale de înregistrare (a se vedea secțiunea 4.1 pentru mai multe detalii). Fiecare stat membru este responsabil de datele sale naționale și trebuie să protejeze cheia privată utilizată pentru semnarea încărcărilor.

Celelalte state membre pot verifica pachetele de date semnate cu ajutorul certificatelor de încărcare furnizate de DCCG. DCCG verifică autenticitatea și integritatea datelor încărcate, comparându-le cu certificatul de încărcare al sistemului back-end național, înainte ca datele să fie furnizate altor state membre.

3.4.    Cerințe privind arhitectura tehnică a DCCG

Cerințele privind arhitectura tehnică a DCCG sunt următoarele:

4.    Gestionarea ciclului de viață a certificatelor

4.1.    Înregistrarea sistemelor back-end naționale

Pentru a participa la sistemul DCCG, statele membre trebuie să se înregistreze la operatorul DCCG. Prezenta secțiune descrie procedura tehnică și operațională care trebuie urmată pentru a înregistra un sistem back-end național.

Operatorul DCCG și statul membru trebuie să facă schimb de informații privind persoanele de contact pentru aspecte tehnice legate de procesul de integrare. Se presupune că persoanele de contact pentru aspecte tehnice sunt legitimate de statele lor membre și că identificarea/autentificarea se efectuează prin intermediul altor canale. De exemplu, autentificarea poate fi realizată atunci când persoana de contact pentru aspecte tehnice a unui stat membru transmite prin e-mail certificatele sub formă de fișiere criptate, cu parolă, și comunică telefonic parola corespunzătoare operatorului DCCG. De asemenea, pot fi utilizate și alte canale securizate definite de operatorul DCCG.

Statul membru trebuie să furnizeze trei certificate digitale în timpul procesului de înregistrare și identificare:

Toate certificatele furnizate trebuie să respecte cerințele definite în secțiunea 5. Operatorul DCCG va verifica dacă certificatul transmis respectă cerințele din secțiunea 5. După identificare și înregistrare, operatorul DCCG:

4.2.    Autoritățile de certificare, perioadele de valabilitate și reînnoirea

În cazul în care un stat membru dorește să opereze propria sa CSCA, certificatele CSCA pot fi certificate autosemnate. Acestea acționează ca ancoră de încredere a statului membru și, prin urmare, statul membru trebuie să protejeze cu fermitate cheia privată corespunzătoare cheii publice a certificatului CSCA. Se recomandă ca statele membre să utilizeze un sistem offline pentru CSCA-urile proprii, și anume un sistem informatic care nu este conectat la nicio rețea. Pentru a avea acces la sistem, trebuie utilizată o metodă de control care presupune mai multe persoane (de exemplu, urmând principiul celor patru ochi). După semnarea DSC-urilor, trebuie efectuate controale operaționale, iar sistemul care deține cheia privată a CSCA se stochează în condiții de siguranță, cu controale stricte al accesului. Pentru a asigura o protecție suplimentară a cheii private a CSCA se pot utiliza module de securitate hardware sau carduri inteligente. Certificatele digitale cuprind o perioadă de valabilitate care impune reînnoirea certificatelor. Reînnoirea este necesară pentru a utiliza noi chei criptografice și pentru a adapta dimensiunile cheilor atunci când apar noi îmbunătățiri ale tehnicii de calcul sau atunci când noi atacuri amenință securitatea algoritmului criptografic utilizat. Se aplică modelul shell (a se vedea secțiunea 3.2).

Se recomandă următoarele perioade de valabilitate, având în vedere valabilitatea de un an a certificatelor digitale privind COVID:

Pentru o reînnoire în timp util, se recomandă următoarele perioade de utilizare pentru cheile private:

Statele membre trebuie să creeze noi certificate de încărcare și noi certificate TLS în timp util, de exemplu, cu o lună înainte de expirare, pentru a permite buna funcționare a certificatelor respective. Ar trebui ca certificatele CSCA și DSC-urile să fie reînnoite cu cel puțin o lună înainte de încheierea perioadei de utilizare a cheii private (având în vedere procedurile operaționale necesare). Statele membre trebuie să îi furnizeze operatorului DCCG certificate CSCA, certificate de încărcare și certificate TLS actualizate. Certificatele expirate trebuie eliminate de pe lista albă și de pe lista de încredere.

Statele membre și operatorul DCCG trebuie să urmărească valabilitatea propriilor certificate. Nu există nicio entitate centrală care să țină evidența valabilității certificatelor și să informeze participanții.

4.3.    Revocarea certificatelor

În general, certificatele digitale pot fi revocate de autoritatea de certificare emitentă prin utilizarea listelor certificatelor revocate sau de respondentul la Protocolul de verificare online a stării certificatelor (Online Certificate Status Protocol – OCSP). Ar trebui ca CSCA-urile pentru sistemul DCC să furnizeze liste ale certificatelor revocate (CRL). Chiar dacă aceste liste nu sunt utilizate în prezent de alte state membre, ar trebui ca ele să fie integrate în aplicațiile viitoare. În cazul în care o CSCA decide să nu furnizeze liste ale certificatelor revocate, certificatele DSC ale respectivei CSCA vor trebui reînnoite atunci când listele certificatelor revocate vor deveni obligatorii. Verificatorii nu ar trebui să utilizeze protocolul OCSP pentru validarea DSC-urilor, ci listele certificatelor revocate. Se recomandă ca sistemul back-end național să efectueze validarea necesară a DSC-urilor descărcate de pe gateway-ul DCC și să transmită mai departe validatorilor naționali ai DCC-urilor doar un set de DSC-uri de încredere și validate. Ar trebui ca validatorii DCC să nu efectueze nicio verificare a revocării în ceea ce privește DSC în cadrul procesului lor de validare. Unul dintre motive este protejarea vieții private a deținătorilor DCC-urilor prin evitarea oricărei posibilități ca utilizarea unei anumite DSC să poată fi monitorizată de către respondentul OCSP asociat.

Statele membre își pot elimina DSC-urile din DCCG pe cont propriu, utilizând certificate de încărcare și certificate TLS valabile. Eliminarea unui DSC înseamnă că toate DCC-urile eliberate cu acest certificat își pierd valabilitatea în momentul în care statele membre obțin listele DSC actualizate. Este esențial să se asigure protecția materialelor de cheie privată corespunzătoare DSC-urilor. Statele membre trebuie să informeze operatorul DCCG atunci când sunt nevoite să revoce certificate de încărcare sau certificate TLS, de exemplu din cauza compromiterii sistemului back-end național. Operatorul DCCG poate apoi să retragă încrederea acordată certificatului afectat, de exemplu, prin eliminarea acestuia de pe lista albă a TLS. Operatorul DCCG poate elimina certificatele de încărcare din baza de date a DCCG. Pachetele semnate cu cheia privată corespunzătoare respectivelor certificate de încărcare își pierd valabilitatea în momentul în care sistemul back-end național retrage încrederea acordată certificatelor de încărcare revocate. În cazul în care un certificat CSCA trebuie revocat, statele membre trebuie să informeze operatorul DCCG, precum și alte state membre cu care au relații de încredere. Operatorul DCCG va emite o nouă listă de încredere, pe care certificatul afectat nu va mai figura. Toate DSC-urile emise de respectiva CSCA își pierd valabilitatea în momentul în care statele membre își actualizează registrul de încredere („trust store”) back-end național. În cazul în care certificatul DCCGTLS sau certificatul DCCGTA trebuie revocate, operatorul DCCG și statele membre trebuie să colaboreze pentru a stabili o nouă listă de conexiuni TLS de încredere și o nouă listă de încredere.

5.    Modele de certificate

Prezenta secțiune stabilește cerințe și îndrumări criptografice, precum și cerințe privind modelele de certificate. De asemenea, aceasta definește modelele de certificate pentru certificatele DCCG.

5.1.    Cerințe criptografice

Algoritmii criptografici și suitele de cifrare TLS trebuie alese pe baza recomandării actuale a Biroului federal german pentru securitatea informațiilor (BSI) sau a Comitetului consultativ privind securitatea sistemelor informatice (Advisory Committee on information systems security, SOG-IS). Aceste recomandări sunt similare cu recomandările altor instituții și organizații de standardizare. Recomandările pot fi găsite în orientările tehnice TR 02102-1 și TR 02102-2 ( 18 ) sau în mecanismele criptografice convenite în cadrul SOG-IS ( 19 ).

5.1.1.    Cerințe privind DSC

Trebuie aplicate cerințele prevăzute în anexa I, secțiunea 3.2.2. Prin urmare, se recomandă insistent ca semnatarii de documente să utilizeze algoritmul de semnătură digitală bazat pe curbe eliptice (ECDSA) cu NIST-p-256 (astfel cum este definit în apendicele D la standardul federal de prelucrare a informațiilor FIPS PUB 186-4). Nu sunt acceptate alte curbe eliptice. Din cauza restricțiilor de spațiu ale DCC, statele membre nu ar trebui să utilizeze algoritmul RSA-PSS, chiar dacă utilizarea acestuia ca algoritm alternativ este permisă. În cazul în care statele membre utilizează algoritmul RSA-PSS, acestea ar trebui să utilizeze o dimensiune a modulului de 2048 biți sau de maximum 3072 biți. Pentru semnătura DSC trebuie utilizat, ca funcție de distribuire (hash) criptografică, algoritmul hash securizat SHA-2 cu o lungime a rezultatului ≥ 256 biți (a se vedea ISO/IEC 10118-3:2004).

5.1.2.    Cerințe privind certificatele TLS, certificatele de încărcare și certificatele CSCA

Pentru certificatele digitale și semnăturile criptografice în contextul DCCG, principalele cerințele privind algoritmii criptografici și lungimea cheii sunt rezumate în următorul tabel (în 2021):

Curba eliptică recomandată pentru EC-DSA este NIST-p-256, datorită punerii sale în aplicare pe scară largă.

5.2.    Certificatul CSCA (NBCSCA)

Tabelul următor oferă îndrumări cu privire la modelul de certificat NBCSCA, în cazul în care un stat membru decide să opereze propria CSCA pentru sistemul DCC.

Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

Denumirea subiectului nu trebuie să fie lăsată necompletată și trebuie să fie unică în statul membru specificat. Codul de țară (c) trebuie să corespundă statului membru care va utiliza certificatul CSCA. Certificatul trebuie să conțină un identificator unic al cheii subiectului (SKI), în conformitate cu RFC 5280 ( 20 ).

5.3.    Certificatul de semnatar de documente (DSC)

Tabelul următor oferă îndrumări cu privire la DSC. Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

DSC trebuie să fie semnat cu cheia privată care corespunde unui certificat CSCA utilizat de statul membru.

Se utilizează următoarele extensii:

În plus, ar trebui ca certificatul să conțină extensia punctului de distribuție a CRL care trimite la lista certificatelor revocate (CRL) furnizată de CSCA care a emis DSC.

DSC poate conține o extensie de utilizare extinsă a cheii cu zero sau mai mulți identificatori ai politicii de utilizare a cheii care limitează tipurile de certificate HCERT pe care acest certificat este autorizat să le verifice. În cazul în care sunt prezenți unul sau mai mulți identificatori, verificatorii trebuie să verifice utilizarea cheii prin comparație cu certificatul HCERT stocat. În acest scop, pentru câmpul extendedKeyUsage sunt definite următoarele valori:

În absența oricărei extensii a utilizării cheii (adică fără extensii sau cu extensii având valoarea zero), acest certificat poate fi utilizat pentru a valida orice tip de certificat HCERT. Alte documente pot defini și alți identificatori relevanți ai politicii de utilizare extinsă a cheii folosiți la validarea certificatelor HCERT.

5.4.    Certificate de încărcare (NBUP)

Tabelul următor oferă îndrumări cu privire la certificatul de încărcare pentru sistemul back-end național. Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

5.5.    Certificatul de autentificare TLS la nivel de client aferent unui sistem back-end național (NBTLS)

Tabelul următor oferă îndrumări cu privire la certificatul de autentificare TLS la nivel de client aferent unui sistem back-end național. Intrările cu caractere aldine sunt obligatorii (trebuie să fie incluse în certificat), intrările cu caractere cursive sunt recomandate (ar trebui incluse). Pentru câmpurile absente, nu sunt definite recomandări.

Certificatul poate conține, de asemenea, autentificarea la nivel de server (1.3.6.1.5.5.7.3.1) aferentă utilizării extinse a cheii, dar aceasta nu este necesară.

5.6.    Certificatul de semnătură pentru lista de încredere (DCCGTA)

Următorul tabel definește certificatul pentru ancora de încredere a DCCG.

5.7.    Certificatele de server TLS ale DCCG (DCCGTLS)

Următorul tabel definește certificatul TLS al DCCG.

Certificatul poate conține, de asemenea, autentificarea la nivel de client (1.3.6.1.5.5.7.3.2) aferentă utilizării extinse a cheii, dar aceasta nu este necesară.

Certificatul TLS al DCCG trebuie eliberat de o autoritate de certificare de încredere publică (inclusă în toate browserele și sistemele de operare importante, în conformitate cu cerințele de bază ale forumului CA/Browser).

▼M1

---

ANEXA V

SCHEMA JAVASCRIPT OBJECT NOTATION (JSON)

1.    Introducere

Prezenta anexă stabilește structura tehnică a datelor pentru certificatele digitale ale UE privind COVID, reprezentată sub forma unei scheme JSON. Documentul oferă instrucțiuni specifice referitoare la câmpurile de date individuale.

2.    Locația și versiunile schemei JSON

Schema JSON oficială acreditată pentru certificatele digitale ale UE privind COVID este disponibilă la adresa https://github.com/ehn-dcc-development/ehn-dcc-schema Alte locații nu sunt acreditate, dar pot fi utilizate pentru pregătirea revizuirilor viitoare.

În mod implicit, versiunea actuală, astfel cum este stabilită în prezenta anexă și susținută de toate țările, care generează în prezent certificate, este afișată în URL-ul indicat.

Următoarea versiune, care va fi susținută până la o dată definită de către toate țările, este afișată în URL-ul indicat prin marcarea versiunii, descrisă mai exact în fișierul Readme.

▼M3

3.    Structuri comune și cerințe generale

Un certificat digital al UE privind COVID nu se eliberează dacă, din cauza lipsei de informații, nu pot fi completate corect toate câmpurile de date în conformitate cu această specificație. Acest lucru nu trebuie înțeles ca afectând obligația statelor membre de a elibera certificate digitale ale UE privind COVID.

Informațiile din toate câmpurile pot fi furnizate utilizând setul complet de caractere UNICODE 13.0 codificate utilizând UTF-8, cu excepția cazului în care caracterele sunt limitate în mod specific la seturi de valori sau la seturi mai restrânse de caractere.

Structura comună este următoarea:

„JSON”:{

„ver”:< informații privind versiunea>,

„nam”:{

<Informații privind numele persoanei>

}

„dob”:<data nașterii>,

„v” sau „t” sau „r”:[

{< informații despre doza de vaccin, testare sau vindecare, o intrare>}

]

}

În secțiunile următoare sunt furnizate informații detaliate privind grupurile și câmpurile individuale.

În cazul în care normele indică faptul că un câmp va fi omis, aceasta înseamnă că va fi gol conținutul său și că nu sunt permise în conținuturi nici numele și nici valoarea câmpului.

3.1.    Versiune

Se furnizează informații privind versiunea. Versiunile respectă Semantic Versioning (semver: https://semver.org). În faza de producție, aceasta trebuie să fie una dintre versiunile lansate oficial (cea curentă sau una dintre versiunile mai vechi lansate oficial). A se vedea secțiunea referitoare la locația schemei JSON pentru mai multe detalii.

3.2.    Numele persoanei și data nașterii

Numele persoanei este numele oficial complet al persoanei, care corespunde numelui menționat pe documentele de călătorie. Identificatorul structurii este nam. Se completează exact 1 (un) nume de persoană.

3.3.    Grupuri pentru informații specifice tipului de certificat

Schema JSON acceptă trei grupuri de intrări care cuprind informații specifice tipului de certificat. Fiecare DCCUE conține exact 1 (un) grup. Grupurile goale nu sunt permise.

▼M1

4.    Informații specifice tipului de certificat

4.1.    Certificatul de vaccinare

Grupul de vaccinare, dacă există, trebuie să conțină exact 1 (o) intrare care să descrie exact un eveniment de vaccinare (o doză). Toate elementele grupului de vaccinare sunt obligatorii, valorile goale nu sunt acceptate.

4.2.    Certificatul de testare

Grupul de testare, dacă există, trebuie să conțină exact 1 (o) intrare care să descrie exact 1 (un) rezultat al testului.

4.3.    Certificatul de vindecare

Grupul de vindecare, dacă există, trebuie să conțină exact 1 (o) intrare care să descrie exact 1 (o) declarație de vindecare. Toate elementele grupului de vindecare sunt obligatorii, valorile goale nu sunt acceptate.

▼M3

---

ANEXA VI

RESPONSABILITĂȚILE STATELOR MEMBRE ÎN CALITATE DE OPERATORI ASOCIAȚI PENTRU GATEWAY-UL PENTRU CERTIFICATUL DIGITAL AL UE PRIVIND COVID ÎN VEDEREA SCHIMBULUI DE LISTE CU DCC-URILE UE REVOCATE

SECȚIUNEA 1

Subsecțiunea 1

Repartizarea responsabilităților

Subsecțiunea 2

Responsabilitățile și rolurile în ceea ce privește tratarea cererilor persoanelor vizate și informarea acestora

SECȚIUNEA 2

Gestionarea incidentelor de securitate, inclusiv a încălcării securității datelor cu caracter personal

SECȚIUNEA 3

Evaluarea impactului asupra protecției datelor

---

ANEXA VII

RESPONSABILITĂȚILE COMISIEI ÎN CALITATE DE PERSOANĂ ÎMPUTERNICITĂ DE OPERATOR PENTRU GATEWAY-UL PENTRU CERTIFICATUL DIGITAL AL UE PRIVIND COVID ÎN VEDEREA SPRIJINIRII SCHIMBULUI DE LISTE CU DCC-URILE UE REVOCATE

Comisia:

---

( 1 ) rfc8392 (ietf.org)

( 2 ) rfc8152 (ietf.org)

( 3 ) rfc8230 (ietf.org)

( 4 ) rfc8392 (ietf.org)

( 5 ) rfc8392 (ietf.org)

( 6 ) rfc7159 (ietf.org)

( 7 ) rfc7049 (ietf.org)

( 8 ) Regulamentul (UE) 2021/953 al Parlamentului European și al Consiliului din 14 iunie 2021 privind cadrul pentru eliberarea, verificarea și acceptarea certificatelor interoperabile de vaccinare, testare și vindecare de COVID-19 (certificatul digital al UE privind COVID) pentru a facilita libera circulație pe durata pandemiei de COVID-19, JO L 211, 15.6.2021, p. 1.

( 9 ) rfc1950 (ietf.org)

( 10 ) rfc1951 (ietf.org)

( 11 ) rfc7517 (ietf.org)

( 12 ) Vă rugăm să luați în considerare, de asemenea, punctul 9.5.1.2 pentru descrierile detaliate ale API.

( 13 ) Perimat înseamnă că această caracteristică nu trebuie luată în considerare pentru noile implementări, ci trebuie sprijinită pentru implementările existente pentru o perioadă de timp bine definită.

( 14 ) rfc3986 (ietf.org)

( 15 ) Pentru punerea în aplicare cu coduri QR, statele membre ar putea lua în considerare utilizarea unui set suplimentar de caractere, cu o lungime totală de până la 72 de caractere (inclusiv cele 27-30 ale identificatorului propriu-zis) pentru a transmite alte informații. Precizarea acestor informații ține de competența statelor membre.

( 16 ) Algoritmul Luhn mod N este o extensie a algoritmului Luhn (cunoscut și sub denumirea de algoritm mod 10) care funcționează pentru coduri numerice și este utilizat, de exemplu, pentru calcularea sumei de verificare a cardurilor de credit. Extensia îi permite algoritmului să funcționeze cu secvențe de valori în orice bază (în cazul nostru, caractere alfa).

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

( 18 ) BSI - Orientări tehnice TR-02102 (bund.de)

( 19 ) SOG-IS - documente justificative (sogis.eu).

( 20 ) rfc5280 (ietf.org)

( 21 ) rfc5280 (ietf.org)