02021D1073 — BG — 25.12.2021 — 002.001

Този текст служи само за информационни цели и няма правно действие. Институциите на Съюза не носят отговорност за неговото съдържание. Автентичните версии на съответните актове, включително техните преамбюли, са версиите, публикувани в Официален вестник на Европейския съюз и налични в EUR-Lex. Тези официални текстове са пряко достъпни чрез връзките, публикувани в настоящия документ

►B РЕШЕНИЕ ЗА ИЗПЪЛНЕНИЕ (ЕС) 2021/1073 НА КОМИСИЯТА от 28 юни 2021 година за определяне на техническите спецификации и правила за прилагането на рамката за доверие за Цифровия COVID сертификат на ЕС, въведена с Регламент (ЕС) 2021/953 на Европейския парламент и на Съвета (текст от значение за ЕИП) (ОВ L 230, 30.6.2021 г., стp. 32)

Изменено с:









▼B

РЕШЕНИЕ ЗА ИЗПЪЛНЕНИЕ (ЕС) 2021/1073 НА КОМИСИЯТА

от 28 юни 2021 година

за определяне на техническите спецификации и правила за прилагането на рамката за доверие за Цифровия COVID сертификат на ЕС, въведена с Регламент (ЕС) 2021/953 на Европейския парламент и на Съвета

(текст от значение за ЕИП)







Член 1

Техническите спецификации за Цифровия COVID сертификат на ЕС, които определят общата структура на данните, механизмите за кодиране и механизма за кодиране за пренос в машинночетим оптичен формат, са определени в приложение I.

Член 2

Правилата за попълване на сертификатите по член 3, параграф 1 от Регламент (ЕС) 2021/953 са определени в приложение II към настоящото решение.

Член 3

Изискванията, определящи общата структура на уникалния идентификатор на сертификата, са посочени в приложение III.

▼M1

Член 4

Правилата за управление, приложими към удостоверенията за публичен ключ във връзка с портала на Цифровия COVID сертификат на ЕС за поддържане на аспектите, свързани с оперативната съвместимост на рамката за доверие, са определени в приложение IV.

▼M1

Член 5

В приложение V към настоящото решение е определена обща координирана структура на данните, които трябва да се поместват в сертификатите, посочени в член 3, параграф 1 от Регламент (ЕС) 2021/953, като се използва схемата JavaScript Object Notation (JSON).

Член 6

Настоящото решение влиза в сила в деня на публикуването му в Официален вестник на Европейския съюз.

▼B

Настоящото решение влиза в сила в деня на публикуването му в Официален вестник на Европейския съюз.









ПРИЛОЖЕНИЕ I

ФОРМАТ И УПРАВЛЕНИЕ НА ДОВЕРИЕТО

Обща структура на данните, механизми за кодиране и механизъм за кодиране за пренос в машинночетим оптичен формат (наричан по-долу „QR“)

1. Увод

Техническите спецификации, посочени в настоящото приложение, съдържат обща структура на данните и механизми за кодиране за Цифровия COVID сертификат на ЕС („DCC“). Също така с тях се определя механизъм за кодиране за пренос в машинночетим оптичен формат (QR), който може да се показва на екрана на мобилно устройство или да бъде разпечатан. Форматите на контейнерите на електронния здравен сертификат, посочени в тези спецификации, са общи, но в този контекст се използват за пренасяне на DCC.

2. Терминология

За целите на настоящото приложение „издатели“ означава организации, които използват тези спецификации за издаване на здравни сертификати, а „проверяващи органи“ означава организации, които приемат здравните сертификати като доказателство за здравното състояние на лицата. „Участници“ означава издатели и проверяващи органи. Някои аспекти, определени в настоящото приложение, трябва да бъдат координирани между участниците, като например управлението на пространството от имена и разпространението на криптографските ключове. Приема се, че тези задачи се извършват от страната, наричана по-долу „Секретариат“.

3. Формат на контейнера на електронния здравен сертификат

Форматът на контейнера на електронния здравен сертификат има за цел да осигури единен и стандартизиран носител на здравните сертификати от различните им издатели („издатели“). Целта на настоящите спецификации е да се хармонизират начините, по които тези здравни сертификати се представят, кодират и подписват, така че да се улесни оперативната съвместимост.

За да са възможни четенето и интерпретирането на DCC, издаден от който и да е издател, е необходима обща структура на данните и съгласие за значението на всяко поле на полезните данни. За да се улесни такава оперативна съвместимост, е определена обща координирана структура на данните посредством използването на схема „JSON“, която съставлява рамката на DCC.

3.1. Структура на полезните данни

Полезните данни са структурирани и кодирани като CBOR с цифров подпис COSE. Това е известно като „CBOR Web Token“ (CWT) и е определено в RFC 8392 ( 1 ). Полезните данни, както са определени в следващите секции, се пренасят в заявка hcert.

Целостта и автентичността на произхода на полезните данни трябва да могат да бъдат проверени от проверяващия орган. За да осигури този механизъм, издателят трябва да подпише CWT, като използва асиметрична схема на електронен подпис, както е определена в спецификацията за COSE (RFC 8152 ( 2 )).

3.2. ЗАЯВКИ ЗА CWT

3.2.1. Общ преглед на структурата на CWT

Защитена заглавна част

— Алгоритъм за подпис (alg, етикет 1)

— Идентификатор на ключ (kid, етикет 4)

Полезни данни

— Издател (iss, ключ за заявка 1, незадължителен, ISO 3166-1 двубуквен код на издателя)

— Издаден на (iat, ключ за заявка 6)

— Срок на валидност (exp, ключ за заявка 4)

— Здравен сертификат (hcert, ключ за заявка -260)

— Цифров COVID сертификат на ЕС версия 1 (eu_DCC_v1, ключ за заявка 1)

Подпис

3.2.2. Алгоритъм за подпис

Параметърът на алгоритъма за подпис (alg) указва кой алгоритъм се използва за създаването на подписа. Той трябва да отговаря на или да надхвърля текущите насоки на SOG-IT, обобщени в следващите параграфи.

Определят се един основен и един вторичен алгоритъм. Вторичният алгоритъм следва да се използва само ако основният не е допустим в рамките на правилата и наредбите, наложени от издателя.

За да се подсигури сигурността на системата, всички изпълнения трябва да включват вторичния алгоритъм. Поради тази причина трябва да бъдат внедрени както основният, така и вторичният алгоритъм.

Нивата на набора SOG-IT за основния и вторичния алгоритъм са:

— Основен алгоритъм: Основният алгоритъм е Elliptic Curve Digital Signature Algorithm (алгоритъм за електронни подписи по елиптична крива) (ECDSA), определен в (ISO/IEC 14888–3:2006) раздел 2.3, използващ параметрите P–256, определени в допълнение D (D.1.2.3) към (FIPS PUB 186–4), в съчетание с алгоритъма SHA–256 за хеширане, определен в (ISO/IEC 10118–3:2004), функция 4.

Това съответства на параметъра на алгоритъма COSE, ES256.

— Вторичен алгоритъм: Вторичният алгоритъм е RSASSA-PSS, определен в (RFC 8230 ( 3 )), с модул от 2048 бита, в съчетание с алгоритъма SHA–256 за хеширане, определен в (ISO/IEC 10118–3:2004), функция 4.

Това съответства на параметъра на алгоритъма COSE: PS256.

3.2.3. Идентификатор на ключ

Заявката за идентификатор на ключ (kid) указва сертификата на подписващия документи орган (DSC), съдържащ публичния ключ, който проверяващият орган трябва да използва за проверка на верността на цифровия подпис. Управлението на удостоверението за публичен ключ, включително изискванията за DSC, е описано в приложение IV.

Заявката за идентификатор на ключ (kid) се използва от проверяващите органи за избиране на правилния публичен ключ от списък с ключове, отнасящи се до издателя, указан в заявката на издателя (iss). Издателят може да използва няколко ключа паралелно за административни цели и когато извършва подновяване на ключовете. Идентификаторът на ключ не е поле от съществено значение за сигурността. Ето защо той може да бъде поставен в незащитена заглавна част, ако е необходимо. Проверяващите органи трябва да приемат и двата варианта. Ако са налице и двете възможности, трябва да се използва идентификаторът на ключа в защитената заглавна част.

Поради скъсяването на идентификатора (поради ограничението на размера) има малък, но не и нулев шанс пълният списък с DSC, приемани от потвърждаващ орган, да съдържа DSC с дублирани kid. Ето защо проверяващият орган трябва да провери всички DSC с този kid.

3.2.4. Издател

Заявката на издателя (iss) е низ, която незадължително може да съдържа ISO 3166-1 двубуквен кода на държавата на организацията, издаваща здравния сертификат. Заявката може да се използва от проверяващия орган, за да установи кой набор от DCS да използва за проверка. Ключ за заявка 1 се използва за идентифициране на тази заявка.

3.2.5. Срок на валидност

Заявката за срок на изтичане (exp) следва да съдържа електронен времеви печат в цифров формат на датата (посочен в RFC 8392 ( 4 ), раздел 2), указващ колко дълго следва да се смята за валиден този конкретен подпис на полезните данни, след което проверяващ орган трябва да отхвърли полезните данни като изтекли. Целта на параметъра за изтичане е да се наложи ограничение на срока на валидност на здравния сертификат. За идентифициране на тази заявка се използва ключ за заявка 4.

Срокът на изтичане не трябва да надхвърля срока на валидност на DSC.

3.2.6. Издаден на

Заявката „Издаден на“ (iad) следва да съдържа електронен времеви печат в цифров формат на датата (посочен в RFC 8392 ( 5 ), раздел 2), указващ момента на създаване на здравния сертификат.

Полето „Издаден на“ не трябва да е с дата, предхождаща срока на валидност на DSC.

Проверяващите органи може да приложат допълнителни правила с цел ограничаване срока на валидност на здравния сертификат в зависимост от момента на издаване. За идентифициране на тази заявка се използва ключ за заявка 6.

3.2.7. Заявка за здравен сертификат

Заявката за здравен сертификат (hcert) е обект JSON (RFC 7159 ( 6 )), съдържащ информация за здравния статус. Може да съществуват няколко различни типа здравни сертификата в една и съща заявка, като DCC е един от тях.

JSON се използва само за целите на схемата. Форматът на представяне е CBOR, както е определен в (RFC 7049 ( 7 )). Програмистите на приложения всъщност може да не разкодират или да кодират от и във формат JSON, а да използват структурата в паметта.

Ключът за идентифициране на тази заявка е -260.

Низовете в обекта JSON следва да се нормализират съгласно NFC, определен в стандарта Unicode. Приложенията за разкодиране би трябвало обаче да имат гъвкавост и капацитет по отношение на тези аспекти и силно се насърчава приемането на всеки разумен тип преобразуване. Ако по време на разкодиране или при последващи сравнителни функции бъдат открити ненормализирани данни, изпълненията трябва да функционират така, все едно че входните данни са нормализирани съгласно NFC.

4. Сериализация и създаване на полезните данни на DCC

Като модел за сериализация се използва следната схема:

Процесът започва с извличане на данни, например от хранилище на здравни данни (или от някой външен източник на данни), като извлечените данни се структурират в съответствие с определените схеми за DCC. При този процес преобразуването в определения формат на данните и преобразуването за четимост от човек може да се извърши преди началото на сериализацията към CBOR. Съкращенията в заявките трябва да бъдат съпоставяни при всички случаи с показваните имена преди сериализацията и след десериализацията.

Незадължителното съдържание на национални данни не е разрешено в сертификатите, издадени съгласно Регламент (ЕС) 2021/953 ( 8 ). Съдържанието на данни е ограничено до определените елементи на данни в минималния набор от данни, посочен в приложението към Регламент 2021/953.

5. Кодирания за пренос

5.1. Непреработено

За произволни интерфейси от данни контейнерът HCERT и полезните му данни може да се прехвърлят без промяна, като се използва всяко основно, 8-битово безопасно и надеждно пренасяне на данните. Тези интерфейси може да включват комуникация в близката зона (на полето) (NFC), Bluetooth или прехвърляне посредством протокол на приложния слой, например прехвърляне на HCERT от издателя до мобилно устройство на притежателя.

Ако прехвърлянето на HCERT от издателя на притежателя е базирано само на изобразяващ интерфейс (например SMS, имейл), кодирането за пренос „непреработено“ очевидно не е приложимо.

5.2. Баркод

5.2.1. Компресиране на полезните данни (CWT)

За да се намали размерът и да се увеличат скоростта и надеждността на процеса на разчитане на HCERT, CWT следва да се компресира посредством ZLIB (RFC 1950 ( 9 )) и механизма за компресиране Deflate във формата, определен в RFC 1951 ( 10 ).

5.2.2. QR двуизмерен баркод

За да се използва по-добре наследеното оборудване, което е предназначено да оперира с полезни данни в ASCII, компресираният CWT се кодира като ASCII посредством Base45, преди да се кодира в двуизмерен баркод.

QR форматът, определен в (ISO/IEC 18004:2015) следва да се използва за генериране на двуизмерен баркод. Процент на корекция на грешката на „Q“ (около 25 %) е препоръчителен. Тъй като се използва Base45, QR кодът трябва да използва буквено-цифрово кодиране (Mode 2, указан със символите 0010).

За да могат проверяващите органи да установят типа на кодираните данни и да изберат правилната схема за разкодиране и обработване, кодираните с Base45 данни (според настоящата спецификация) следва да са с представка, състояща се от низа с идентификатор на контекста „HC1:“. Бъдещите версии на тази спецификация, които засягат обратната съвместимост, следва да определят нов идентификатор на контекста, при който знаците след „НС“ следва да бъдат взети от набора със знаци [1-9A-Z]. Подредбата на нарастващите стойности се определя в този ред, т.е. първо [1-9], а след това — [A-Z].

Оптичният код е препоръчително да бъде изразен в изобразяващата медия с диагонален размер между 35 mm и 60 mm, за да е съвместим с четци с фиксирана оптика, където изобразяващата медия трябва да бъде поставена на повърхността на четеца.

Ако оптичният код е отпечатан на хартия чрез принтер с ниска резолюция (< 300 dpi), трябва да се внимава всеки символ (точка) на QR кода да се изобразява като точен квадрат. Непропорционалното мащабиране ще доведе до това някои редове и колони в QR кода да са с правоъгълни символи, а това в много случаи ще попречи на прочитането.

6. Формат на доверителния списък (списък на CSCA и DSC)

От всяка държава членка се изисква да предостави списък с един или няколко национални подписващи сертификати органа (CSCA), както и списък на всички валидни сертификати на подписващите документи органи (DSC), и да поддържа тези списъци актуални.

6.1. Опростени CSCA/DSC

От тази версия на спецификациите държавите членки не следва да приемат, че може да се използва информация от списъка на отменени сертификати (CRL); или че срокът на използване на частния ключ се проверява от внедряващите органи.

Вместо това основният механизъм за проверка е наличието на сертификата в най-новата версия на този списък със сертификати.

6.2. Инфраструктура на публичния ключ (PKI) за еМЧДП на ИКАО и доверителни центрове

Държавите членки могат да използват отделен CSCA, но могат също така да подадат своите съществуващи сертификати на CSCA за еМЧДП и/или DSC; а може дори да изберат да ги доставят от (търговски) доверителни центрове — и да изпращат тях. Всеки DSC обаче трябва винаги да бъде подписан от CSCA, подаден от тази държава членка.

7. Съображения за сигурност

Когато разработват схема, използвайки тази спецификация, държавите членки следва да идентифицират, анализират и проследяват определени аспекти на сигурността.

По-специално би трябвало да бъдат взети под внимание най-малко следните аспекти:

7.1. Срок на валидност на подписа на HCERT

Издателят на HCERT трябва да ограничи срока на валидност на подписа, като посочи срок на изтичането му. За това е необходимо притежателят на здравния сертификат да го подновява периодично.

Допустимият срок на валидност може да бъде определен на базата на практически ограничения. Например пътуващият може да не е имал възможност да поднови здравния си сертификат по време на пътуване в чужбина. Може обаче да се случи издател да обмисля възможността за някакъв компромис със сигурността, който изисква от него да оттегли DSC (като така отмени валидността на всички здравни сертификати, издадени с този ключ, чийто срок на валидност още не е изтекъл). Последствията от такова събитие може да се ограничат от редовното подновяване на ключовете на издателя и от изискването за подновяване на всички здравни сертификати през някакъв разумен интервал.

7.2. Управление на ключовете

Настоящата спецификация разчита в значителна степен на силни криптографски механизми, за да осигури целостта на данните и потвърждаването на произхода на данните. Ето защо е необходимо да се поддържа поверителността на частните ключове.

Поверителността на криптографските ключове може да бъде компрометирана по различни начини, например:

— Процесът на генериране на ключа може да има дефекти, което да доведе до слаба сигурност на ключовете.

— Ключовете може да са изложени на човешка грешка.

— Ключовете може да бъдат откраднати от външни или вътрешни нарушители.

— Ключовете може да бъдат изчислени посредством криптоанализ.

С цел от смекчаване на рисковете алгоритъмът за подписване да се окаже слаб, което да позволи компрометиране на частните ключове посредством криптоанализ, настоящата спецификация препоръчва всички участници да внедрят вторичен, резервен алгоритъм за подпис, основан на различни параметри или на различен математически проблем от предишния.

По отношение на споменатите рискове, свързани с оперативната среда на издателите, следва да се приложат смекчаващи мерки за осигуряване на ефективен контрол, като например частните ключове да се генерират, съхраняват и използват в хардуерни модули за сигурност (HSM). Използването на HSM за подписване на здравни сертификати силно се насърчава.

Независимо дали издателят реши да използва HSM или не, би трябвало да бъде въведен график за подновяване на ключовете, при който честотата на подновяване е пропорционална на излагането на ключовете във външни мрежи, други системи или персонал. Добре избраният график за подновяване на ключовете също така ограничава рисковете, свързани с погрешно издадени здравни сертификати, като дава възможност на издателя да отмени такива сертификати на партиди, като оттегли даден ключ, ако е необходимо.

7.3. Потвърждаване на входните данни

Настоящите спецификации може да се използват по начин, който предполага получаването на данни от ненадеждни източници в системи, които може да са от критично значение. За да се ограничат рисковете, свързани с такива атаки, всички полета за входни данни трябва да бъдат правилно валидирани по типове данни, дължина и съдържание. Подписът на издателя следва също да бъде проверен, преди да се извърши обработване на съдържанието на HCERT. Валидирането на подписа на издателя обаче предполага извършването на синтактичен анализ първо на защитената заглавна част на издателя, в която потенциален нападател може да опита да инжектира внимателно изработена информация с цел да компрометира сигурността на системата.

8. Управление на доверието

За проверка на подписа на HCERT е необходим публичен ключ. Тези публични ключове се осигуряват от държавите членки. В крайна сметка всеки проверяващ орган трябва да разполага със списък на всички публични ключове, на които е решил да се довери (тъй като публичният ключ не е част от HCERT).

Системата се състои от (само) два слоя; за всяка държава членка — един или няколко сертификата на ниво държава, като всеки подписва един или няколко сертификата на подписващия документи орган, използвани в ежедневни операции.

Сертификатите на държавите членки се наричат сертификати на националните подписващи сертификати органи (CSCA) и (обикновено) са самоподписващи се. Държавите членки може да имат повече от един (например в случай на регионално самоуправление). Тези сертификати на CSCA редовно подписват сертификатите на подписващия документи орган (DSC), използвани за подписване на HCERT.

„Секретариатът“ има функционална роля. Той следва редовно да обобщава и публикува DSC на държавите членки, след като ги е потвърдил в списъка със сертификати на CSCA (който е предаден и потвърден чрез други средства).

Полученият списък с DSC след това следва да предостави обобщен набор от допустими публични ключове (както и съответстващите kid), който проверяващите органи могат да използват за валидиране на подписите в HCERT. Проверяващите органи трябва редовно да се сдобиват с този списък и да го актуализират.

Такива списъци, които са конкретни за държавите членки, може да бъдат адаптирани във формата, съответстващ на националните им условия. Така форматът на файла на този доверителен списък може да се различава. Например може да бъде подписан JWKS (формат на JWK набор според раздел 5 на RFC 7517 ( 11 )) или друг формат, който е конкретен за технологията, използвана от съответната държава членка.

За да се осигури опростеност, държавите членки може да изпращат съществуващите си сертификати на CSCA от своите системи за еМЧДП на ИКАО или, както препоръчва СЗО, да създадат такъв конкретно за тази здравна сфера.

8.1. Идентификатор на ключ (kid)

Идентификаторът на ключ (kid) се изчислява при изграждането на списъка с доверени публични ключове от DSC и се състои от съкратен отпечатък SHA-256 (първите 8 байта) на DSC, кодиран в DER формат (непреработен).

Проверяващите органи не се налага да изчисляват kid на базата на DSC и могат директно да съпоставят идентификатора на ключа в издадения здравен сертификат с kid в доверителния списък.

8.2. Разлики в доверителния модел на инфраструктурата на публичния ключ (PKI) за еМЧДП на ИКАО

Въпреки че за модел са използвани най-добри практики на доверителния модел на инфраструктурата на публичния ключ (PKI) за еМЧДП на ИКАО, ще бъдат извършени няколко опростявания с оглед на скоростта:

— Държава членка може да изпраща няколко сертификата на CSCA.

— Срокът на валидност на DSC (използване на ключа) може да бъде зададен за всякаква продължителност, без да надхвърля валидността на сертификата на CSCA, и може да липсва.

— DSC може да съдържа идентификатори на политика (удължено използване на ключа), конкретни за здравните сертификати.

— Държавите членки може да изберат никога да не извършват проверка на публикувани оттегляния; но вместо това изцяло да разчитат на списъците с DSC, които получават ежедневно от Секретариата, или да ги съставят самостоятелно.

▼M1









ПРИЛОЖЕНИЕ II

ПРАВИЛА ЗА ПОПЪЛВАНЕТО НА ЦИФРОВИЯ COVID СЕРТИФИКАТ НА ЕС

Общите правила, свързани с наборите от стойности, определени в настоящото приложение, имат за цел да осигурят оперативната съвместимост на семантично ниво и следва да дадат възможност за единни технически изпълнения на Цифровия COVID сертификат на ЕС. Елементи, съдържащи се в настоящото приложение, може да се използват за трите различни настройки (ваксинация/направено изследване/преболедуване), както е определено в Регламент (ЕС) 2021/953. В настоящото приложение са посочени само елементи с необходимост от семантична стандартизация посредством набори от кодирани стойности.

Преводът на кодираните елементи на националния език е отговорност на държавите членки.

За всички полета с данни, които не са споменати в следните описания на набори от стойности, кодирането е описано в приложение V.

Ако поради някаква причина предпочитаните системи за кодиране, посочени по-долу, не могат да бъдат използвани, може да се използват други международни системи за кодиране и трябва да се разработят съвети за намиране на съответствие на кодовете от другите системи за кодиране с кодовете в предпочитаната. Текст (показвани имена) може да се използва в изключителни случаи като резервен механизъм, когато не е наличен подходящ код в определените набори от стойности.

Държавите членки, използващи друго кодиране в системите си, трябва да намерят съответствие на тези кодове в описаните набори от стойности. Държавите членки отговарят за всяко такова намиране на съответствие.

Тъй като някои набори от стойности, които са основани на системите за кодиране, предвидени в настоящото приложение, като например тези за кодиране на ваксини и бързи тестове за антигени, често се променят, Комисията ги публикува и редовно актуализира с помощта на мрежата за електронно здравеопазване и Комитета за здравна сигурност. Актуализираните набори от стойности ще се публикуват на съответния уебсайт на Комисията, както и на уеб страницата на мрежата за електронно здравеопазване. Представя се и хронология на промените.

1. Заболяване или патоген / заболяване или патоген, което/който притежателят е преболедувал: COVID-19 (SARS-CoV-2 или някой от неговите варианти)

Да се използва в сертификати 1, 2 и 3.

Използва се следният код:







Код Текст Име на системата за кодиране URL адрес на системата за кодиране Система за кодиране (ИНО) Версия на системата за кодиране 840539006 COVID-19 SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

2. Ваксина срещу COVID-19 или профилактика

Предпочитана система за кодиране: SNOMED CT или ATC класификация.

Да се използва в сертификат 1.

Примерни кодове, които трябва да се използват от предпочитаните системи за кодиране, са кодът по SNOMED CT 1119305005 (SARS-CoV-2 антигенна ваксина), 1119349007 (SARS-CoV-2 иРНК ваксина) или J07BX03 (ваксини срещу Covid-19).

Със съдействието на мрежата за електронно здравеопазване Комисията публикува и редовно актуализира набор от стойности, определящ кодовете, които да се използват съгласно установените в настоящия раздел системи за кодиране. Наборът от стойности трябва да бъде разширен, когато бъдат разработени и въведени в употреба нови типове ваксини.

3. Ваксинационен лекарствен продукт срещу COVID-19

Предпочитани системи за кодиране (по ред на предпочитание):

— Регистър на лекарствените продукти на Съюза за ваксини с разрешение за целия ЕС (номера на разрешенията);

— Глобален регистър на ваксините, например такъв, който би могъл да бъде въведен от Световната здравна организация;

— Име на ваксинационния лекарствен продукт в други случаи. Ако името включва интервали, те трябва да бъдат заменени от тире (-).

Име на набора от стойности: Ваксина.

Да се използва в сертификат 1.

Пример на код, който трябва да се използва от предпочитаната система за кодиране, е ЕС/1/20/1528 (Comirnaty). Пример на името на ваксината, което да се използва като код: Sputnik-V (за Sputnik V).

Със съдействието на мрежата за електронно здравеопазване Комисията публикува и редовно актуализира набор от стойности, определящ кодовете, които да се използват съгласно установените в настоящия раздел системи за кодиране.

Ваксините трябва да се кодират, като се използва съществуващ код в публикувания набор от стойности, дори ако имената им са различни в различните държави. Причината е, че все още няма глобален регистър на ваксините, който да обхваща всички ваксини, използвани понастоящем. Пример:

— За ваксината „COVID-19 Vaccine Moderna Intramuscular Injection“ (наименованието на ваксината Spikevax в Япония) използвайте код EU/1/20/1507, тъй като това е наименованието на тази ваксина в ЕС.

Ако това не е възможно или препоръчително в конкретен случай, в публикувания набор от стойности ще бъде посочен отделен код.

4. Притежател на разрешението за търговия или производител на ваксината срещу COVID-19

Предпочитана система за кодиране:

— Код на организацията от EMA (система SPOR за ISO IDMP);

— Глобален регистър на притежателите на разрешението за търговия или производителите на ваксината, например такъв, който би могъл да бъде въведен от Световната здравна организация;

— Име на организацията в други случаи. Ако името включва интервали, те трябва да бъдат заменени от тире (-).

Да се използва в сертификат 1.

Пример на код, който трябва да се използва от предпочитаната система за кодиране, е ORG-100001699 (AstraZeneca AB). Примерно име на организацията, което да се използва като код: Sinovac-Biotech (за Sinovac Biotech).

Със съдействието на мрежата за електронно здравеопазване Комисията публикува и редовно актуализира набор от стойности, определящ кодовете, които да се използват съгласно установените в настоящия раздел системи за кодиране.

Различните клонове на един и същ притежател на разрешение за търговия или на един и същ производител трябва да използват съществуващ код от публикувания набор от стойности.

По правило за един и същ ваксинационен продукт се използва кодът, отнасящ се до притежателя на разрешението за търговия в ЕС, тъй като все още няма международно договорен регистър на производителите на ваксини или на притежателите на разрешения за търговия. Пример:

— За компанията Pfizer AG, притежател на разрешение за търговия с ваксината Comirnaty, която се използва в Швейцария, трябва да се използва код ORG-100030215, отнасящ се до BioNTech Manufacturing GmbH, които са притежател на разрешението за търговия с Comirnaty в ЕС.

— За компанията Zuellig Pharma, притежател на разрешение за търговия с ваксината Covid-19 Vaccine Moderna (Spikevax), която се използва във Филипините, трябва да се използва код ORG-100031184, отнасящ се до Moderna Biotech Spain S.L., които са притежател на разрешението за търговия с Spikevax в ЕС.

Ако това не е възможно или препоръчително в конкретен случай, в публикувания набор от стойности ще бъде посочен отделен код.

5. Пореден номер при серия от дози, както и общ брой на дозите в серията

Да се използва в сертификат 1.

Две полета:

(1) Пореден номер в последователност от дози ваксина срещу COVID-19 (N);

(2) Общ брой дози във ваксинационната серия (С).

5.1. Основна ваксинационна серия

Когато лицето получава дози в рамките на основната ваксинационна серия, т.е. ваксинационната серия, предназначена да осигури достатъчна защита на първоначален етап, (C) отразява общия брой дози от стандартната основна ваксинационна серия (напр. 1 или 2, в зависимост от вида на поставената ваксина). Това включва възможността да се използва по-кратък курс (C=1), когато протоколът за ваксинация, прилаган от дадена държава членка, предвижда поставяне на еднократна доза от ваксина с 2 дози на лица, които са преболедували SARS-CoV-2. Така завършената основна ваксинационна серия ще се указва с N/C = 1. Например:

— 1/1 ще означава завършена основна ваксинационна серия с единична доза или завършена основна ваксинационна серия, състояща се от една доза на ваксина с 2 дози, поставена на преболедувало лице в съответствие с ваксинационния протокол, прилаган от държавата членка;

— 2/2 ще означава завършена ваксинационна серия с 2 дози.

Когато основната ваксинационна серия бъде разширена, например за лица със силно отслабена имунна система, или когато препоръчителният интервал между основните дози не е бил спазен, всички такива дози се кодират като допълнителни и са в обхвата на раздел 5.2.

▼M2

5.2. Подсилващи дози

Когато лицето получава дози след основната ваксинационна серия, тези подсилващи дози се отразяват в съответните сертификати, както следва:

— 2/1 означава поставяне на подсилваща доза след основна ваксинационна серия, състояща се от една доза, или поставяне на подсилваща доза след приключена основна ваксинационна серия, състояща се от една доза от ваксина с 2 дози, поставена на преболедувало лице в съответствие с ваксинационния протокол, прилаган от държавата членка; След това дозите (Х), поставени след първата подсилваща доза, се обозначават с (2+X)/(1) > 1 (например „3/1“);

— 3/3 означава поставяне на подсилваща доза след основна ваксинационна серия, състояща се от 2 дози. След това дозите (Х), поставени след първата подсилваща доза, се посочват с (3+X)/(3+X) = 1 (например „4/4“).

Държавите членки въвеждат правилата за кодиране, определени в настоящия раздел, до 1 февруари 2022 г.

Държавите членки, автоматично или по искане на заинтересованите лица, преиздават сертификатите, в които поставянето на подсилваща доза след курс на ваксинация с единична доза е кодирано по такъв начин, че да не може да бъде разграничено от приключването на основната ваксинационна серия.

За целите на настоящото приложение позоваванията на „подсилващи дози“ следва да се разбират като обхващащи и допълнителни дози, поставяни с цел по-добра защита на лицата, които демонстрират неадекватни имунни реакции след приключване на стандартната основна ваксинационна серия. В съгласие с правната рамка, установена с Регламент (ЕС) 2021/953, държавите членки могат да приемат мерки за уреждане на въпроса при уязвимите групи, които може да получат приоритетно допълнителни дози. Например, ако дадена държава членка реши да поставя допълнителни дози само на конкретни подгрупи от населението, тя може да избере, в съответствие с член 5, параграф 1 от Регламент (ЕС) 2021/953, да издава сертификати за ваксинация, в които се посочва, че въпросната допълнителна доза се поставя само при поискване, а не автоматично. Когато приемат такива мерки, държавите членки информират за това засегнатите лица, както и че същите могат да продължат да ползват сертификата, който са получили след приключването на стандартната основна ваксинационна серия.

▼M1

6. Държава членка или трета държава, в която е поставена ваксината/в която е направено изследването

Предпочитана система за кодиране: Кодовете на държавите по ISO 3166

Да се използват в сертификати 1, 2 и 3.

Съдържание на набора от стойности: пълният списък от двубуквени кодове, налични като набор от стойности, определен в Ресурсите за бърза оперативна съвместимост в здравеопазването (FHIR) (http://hl7.org/fhir/ValueSet/iso3166-1-2) Ако ваксинацията или тестът са извършени от международна организация (като ВКБООН или СЗО) и няма налична информация за страната, трябва да се използва код за организацията. Комисията публикува и редовно актуализира тези допълнителни кодове с помощта на мрежата за електронно здравеопазване.

7. Вид на теста

Да се използва в сертификат 2 и сертификат 3, ако чрез делегиран акт е въведена възможност за издаването на сертификати за преболедуване въз основа на вида на изследването или теста, различен от NAAT.

Използват се следните кодове:







Код Текст Име на системата за кодиране URL адрес на системата за кодиране Система за кодиране (ИНО) Версия на системата за кодиране LP6464-4 Амплификация на нуклеинови киселини с детекция със сонда LOINC http://loinc.org 2.16.840.1.113883.6.1 2,69 LP217198-3 Бърз имуноанализ LOINC http://loinc.org 2.16.840.1.113883.6.1 2,69

8. Производител и търговско наименование на използван тест (незадължително за изследване NAAT)

Да се използва в сертификат 2.

Съдържанието на набора от стойности ще включва избора на бърз тест за антигени, както е посочен в общия и актуализиран списък на бързи тестове за антигени за COVID-19, определен на базата на Препоръка на Съвета 2021/С 24/01 и одобрен от Комитета за здравна сигурност. Списъкът се поддържа от JRC в базата данни за ин витро диагностични изделия и методи за изпитване, свързани с COVID-19, на адрес: https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat

За тази система за кодиране се използват съответните полета, като идентификаторът на медицинското изделие за извършване на изследването, името на теста или изследването и производителя, в съответствие с наличния структуриран от JRC формат на адрес: https://covid-19-diagnostics.jrc.ec.europa.eu/devices

9. Резултат от изследването или теста

Да се използва в сертификат 2.

Използват се следните кодове:







Код Текст Име на системата за кодиране URL адрес на системата за кодиране Система за кодиране (ИНО) Версия на системата за кодиране 260415000 Не се открива SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31 260373001 Положителен SNOMED CT http://snomed.info/sct 2.16.840.1.113883.6.96 2021-01-31

▼B









ПРИЛОЖЕНИЕ III

ОБЩА СТРУКТУРА НА УНИКАЛНИЯ ИДЕНТИФИКАТОР НА СЕРТИФИКАТА

1. Увод

Всеки Цифров COVID сертификат на ЕС (DCC) ще включва уникален идентификатор на сертификата (УИС), който поддържа оперативната съвместимост на DCC. УИС може да се използва за проверка на сертификата. Държавите членки са отговорни за внедряването на УИС. УИС е средство за проверка на достоверността на сертификата, и където е приложимо — за свързване с регистрационна система (например с ИИС). Тези идентификатори също така ще активират удостоверения (хартиени и цифрови) от страна на държавите членки, че лицата са били ваксинирани или тествани.

2. Съдържание на уникалния идентификатор на сертификата

УИС ще следва обща структура и формат, които улесняват човешкото и/или машинното интерпретиране на информацията, и може да се отнася до такива елементи като държава членка на ваксинация, самата ваксина и конкретния идентификатор на държавата членка. Той предоставя гъвкавост на държавата членка да го форматира при пълно спазване на законодателството за защита на личните данни. Редът на отделните елементи следва определена йерархия, която може да даде възможност за бъдещи модификации на блоковете, като в същото време поддържа целостта на структурата.

Възможните решения за съдържанието на УИС са в спектър, в който модулността и човешкото интерпретиране са двата основни разграничаващи параметъра и една основополагаща характеристика:

— Модулност: степента, до която кодът е съставен от отделни блокове, съдържащи семантично различна информация

— Човешко интерпретиране: степента, до която кодът е смислен или може да бъде интерпретиран от прочитащия го човек

— Уникален в глобален мащаб; Идентификаторът на държавата или органа се управлява добре; и всяка държава (орган) се очаква да управлява добре своя сегмент от пространството от имена, като никога не рециклира или използва повторно идентификаторите. В комбинация тези мерки осигуряват уникалността на всеки идентификатор в глобален мащаб.

▼M1

3. Общи изисквания

Следните основни изисквания трябва да спазени във връзка с УИС:

(1) Набор от знаци: Допускат се само US-ASCII главни буквено-цифрови знаци (от А до Z, от 0 до 9); с допълнителни специални знаци за отделяне от RFC3986 ( 12 ), по-конкретно „/“, „#“, „:“;

(2) Максимална дължина: разработчиците трябва да се стремят към дължина от 27—30 знака ( 13 );

(3) Представка за версията: това се отнася до версията на схемата на УИС. Представката за версията е „01“ за настоящата версия на документа; представката за версията се състои от две цифри;

(4) Представка за държавата: кодът на държавата е определен от ISO 3166-1. По-дългите кодове (напр. с 3 или повече знака (например „UNHCR“) са запазени за бъдеща употреба;

(5) Наставка на кода/Контролна сума: 5.1 Държавите членки могат да използват контролна сума, когато има вероятност от възникване на пренос, (човешка) транскрипция или друг вид увреждане (когато се използва в печатна форма). 5.2 Не бива да се разчита на контролната сума за потвърждаване на сертификата, нито пък тя е технически част от идентификатора, а се използва за проверка на целостта на кода. Тази контролна сума трябва да бъде обобщената информация ISO-7812-1 (LUHN-10) ( 14 ) на целия УИС в цифров формат/формат за жичен пренос. Контролната сума се разделя от останалата част на УИС със знак „#“.

Трябва да се осигури обратна съвместимост: държавите членки, които с течение на времето променят структурата на идентификаторите си (в рамките на основната версия, понастоящем зададена на v1), трябва да направят така, че всеки два идентични идентификатора да представляват един и същ сертификат/удостоверение за ваксинация. Или, с други думи, държавите членки не могат да рециклират идентификаторите.

▼B

4. Опции за уникални идентификатори на сертификати за сертификати за ваксинация

Насоките на мрежата за електронно здравеопазване за сертификатите за ваксинация с възможност за потвърждаване и основните елементи на оперативната съвместимост ( 15 ) предоставят различни опции на държавите членки и на други страни, които може да съществуват заедно сред различните държави членки. Държавите членки може да използват такива различни опции в друга версия на схемата на УИС.









ПРИЛОЖЕНИЕ IV

УПРАВЛЕНИЕ НА СЕРТИФИКАТИ НА ПУБЛИЧНИ КЛЮЧОВЕ

1. Увод

Сигурната и надеждна обмяна на ключове за подпис за Цифровите COVID сертификати на ЕС (DCC) между държавите членки се осъществява от портала на Цифровия COVID сертификат на ЕС (DCCG), който действа като централен архив за публичните ключове. В DCCG държавите членки са упълномощени да публикуват публичните ключове, отговарящи на частните ключове, които използват за подписване на цифрови сертификати за COVID. Държавите членки, които разчитат на DCCG за това, могат своевременно да се сдобиват с актуализирани публични ключове. По-късно DCCG може да бъде разширен, за да включва обмяната на надеждна допълнителна информация, предоставяна от държавите членки, като например правила за валидиране на DCC. Доверителния модел на рамката на DCC е инфраструктура на публичния ключ (PKI). Всяка държава членка поддържа един или няколко национални подписващи сертификати органи (CSCA), чиито сертификати са сравнително дългосрочни. Съгласно решението на държавата членка CSCA може да бъде същия или различен от CSCA, използван за машинночетими пътнически документи. CSCA издава удостоверения за публичен ключ за националните, краткосрочни, подписващи документите органи (т.е. подписващи за DCC), които се наричат сертификати на подписващия документи орган (DSC). CSCA действа като котва на доверие, така че разчитащите на него държави членки могат да използват сертификата на CSCA за валидиране на автентичността и целостта на редовно променящите се DSC. След като ги потвърдят, държавите членки могат да предоставят тези сертификати (или само съдържащите се в тях публични ключове) на приложенията си за валидиране на DCC. Освен на CSCA и DSC, DCCG разчита и на PKI, за да установява автентичността на трансакции, да подписва данни като основа за установяване на автентичността и като средство за осигуряване целостта на комуникационните канали между държавите членки и DCCG.

Цифровите подписи могат да се използват за постигане на цялостност и автентичност на данните. Инфраструктурите на публичните ключове създават доверие, като свързват публичните ключове с проверени идентичности (или издатели). Това е необходимо, за да се позволи на други участници да проверяват произхода на данните и идентичността на комуникационния партньор и да вземат решения относно доверието. В DCCG се използват редица удостоверения за публичен ключ за автентичност. Настоящото приложение определя кои удостоверения за публичен ключ да се използват и как дизайнът им да позволява широка оперативна съвместимост сред държавите членки. То предоставя повече подробности за необходимите удостоверения за публичен ключ и дава указания за шаблоните на удостоверенията и срока им на валидност за държавите членки, които искат да оперират собствен CSCA. Тъй като DCC ще могат да бъдат проверявани за определен период от време (който започва от издаването и изтича след определено време), е необходимо да се определи модел на проверка за всички подписи, прилагани в удостоверенията за публичен ключ и в DCC.

2. Терминология

Следващата таблица съдържа съкращения и терминология, използвани в настоящото Приложение.







Термин Определение Удостоверение или удостоверение за публичен ключ. Удостоверение X.509 v3, което съдържа публичния ключ на организация CSCA Национален подписващ сертификати орган DCC Цифров COVID сертификат на ЕС. Подписан цифров документ, който съдържа информация за ваксинация, тест или преболедуване DCCG Портал за Цифровия COVID сертификат на ЕС. Тази система се използва за обмяна на DSC между държавите членки DCCGTA Сертификатът на котвата на доверие на DCCG. Съответстващият частен ключ се използва за подписване на списъка на всички сертификати на CSCA офлайн DCCGTLS Сертификатът на TLS сървъра на DCCG DSC Сертификат на подписващия документи орган. Удостоверението за публичен ключ на подписващия документи орган на държава членка (например система, която има право да подписва DCC). Този сертификат се издава от CSCA на държавата членка EC-DSA Алгоритъм за електронни подписи по елиптична крива. Алгоритъм за криптографски подпис, основан на елиптични криви Държава членка Държава — членка на Европейския съюз mTLS Взаимен TLS. Протоколът за сигурност на транспортния слой с взаимна автентификация NB Национален бек-енд на държава членка NB CSCA Сертификатът на CSCA на държава членка (може да е повече от един) NB TLS TLS клиентски сертификат за автентификация на национален бек-енд NB UP Сертификатът, използван от национален бек-енд за подписване на пакети от данни, които се качват в DCCG PKI Инфраструктура на публичния ключ (PKI). Доверителен модел, основан на удостоверения на публичен ключ и органи за издаване на сертификати RSA Асиметричен криптографски механизъм, базиран на факторизация на цели числа, използван за цифрови подписи или асиметрично криптиране

3. Дефекти в комуникацията на DCCG и услуги по сигурността

Настоящият раздел съдържа общ преглед на дефектите в комуникацията и услугите по сигурността на системата на DCCG. Тук също така се определя кои ключове и сертификати се използват за защита на комуникацията, качената информация, DCC и подписания доверителен списък, който съдържа всички приети сертификати на CSCA. DCCG работи като център за данни, който позволява обмяната на подписани пакети от данни за държави членки.

Качените пакети от данни се предоставят от DCCG във вида, в който са. Това означава, че DCCG не добавя, нито изтрива DSC от пакетите, които получава. Националният бек-енд (NB) на държава членка трябва да може да проверява целостта и автентичността на качените данни от край до край. В допълнение към това националните бек-ендове и DCCG ще използват взаимна TLS автентификация за създаването на сигурна връзка. Това е в допълнение към подписите в обменяните данни.

3.1. Автентификация и създаване на връзка

DCCG използва сигурност на транспортния слой (TLS) с взаимно автентификация, за да създаде автентифициран криптиран канал между националния бек-енд (NB) на държава членка и средата на портала. Ето защо DCCG притежава TLS сървърен сертификат — съкратено DCCGTLS, а националните бек-ендове притежават TLS клиентски сертификати — съкратено NB TLS. Шаблоните на сертификатите са предоставени в раздел 5. Всеки национален бек-енд може да предоставя собствен TLS сертификат. Този сертификат ще бъде отбелязан изрично в разрешения списък и така може да бъде издаван от публично доверен сертифициращ орган (например сертифициращ орган, който спазва основните изисквания на CA/Browser Forum), от национални сертифициращи органи или може да е самоподписан. Всяка държава членка е отговорна за националните си данни и защитата на частния ключ, използван за установяване на връзката към DCCG. Подходът от типа „носете си собствен сертификат“ изисква добре определен процес на регистрация и идентифициране, както и процедури за отмяна и подновяване, както са описани в секции 4.1 , 4.2 и 4.3. DCCG използва разрешен списък, в който TLS сертификатите на националните бек-енд се добавят след успешната им регистрация. Само национални бек-ендове, които се автентифицират с частен ключ, съответстващ на сертификат от разрешения списък, могат да установят сигурна връзка към DCCG. DCCG също така използва TLS сертификат, който позволява на националните бек-ендове да проверяват дали наистина установяват връзка с „истинския“ DCCG, а не със злонамерена организация, представяща се за DCCG. Сертификатът на DCCG ще бъде представен на NB след успешна регистрация. DCCGTLS сертификатът ще бъде издаден от публично доверен сертифициращ орган (включен във всички основни браузъри). Държавите членки носят отговорност да проверяват сигурността на връзката си с DCCG (например като проверяват отпечатъка на DCCGTLS сертификата на сървъра, с който са свързани, спрямо този, предоставен след регистрацията).

3.2. Национални подписващи сертификати органи и модел на валидиране

Държавите членки, които взимат участие в рамката на DCCG, трябва да използват CSCA за издаването на DSC. Държавите членки може да имат повече от един CSCA, например в случай на регионална децентрализация. Всяка държава членка може да използва съществуващи сертификационни органи или да създаде специален орган за издаване на (по възможност самоподписани) сертификати за системата на DCC.

Държавите членки трябва да представят сертификата/сертификатите на CSCA на оператора на DCCG по време на официалната процедура по присъединяване. След успешната регистрация на държавата членка (вижте раздел 4.1 за повече информация) операторът на DCCG ще актуализира подписан доверителен списък, съдържащ всички сертификати на CSCA, активни в рамката на DCC. Операторът на DCCG ще използва специална двойка асиметрични ключове за подписване на доверителния списък и на сертификатите в офлайн среда. Частният ключ няма да се съхранява в онлайн системата на DCCG, така че компрометиране на онлайн системата да не даде възможност на нападател да компрометира доверителния списък. Съответстващият сертификат на котвата на доверие DCCGTA ще бъде предоставен на националните бек-ендове по време на процеса на присъединяване.

Държавите членки могат да получат доверителния списък от DCCG за целите на процедурите си по проверка. CSCA се определя като сертифициращ орган, който издава DSC, като затова държавите членки, които използват многостепенна йерархия на сертифициращия орган (например основен сертифициращ орган -> CSCA -> DSC), трябва да предоставят информация за подчинения сертифициращ орган, който издава DSC. В такъв случай, ако се използва съществуващ сертифициращ орган, то системата на DCC ще игнорира всичко над CSCA и ще постави в разрешения списък само CSCA като котва на доверие (въпреки че е подчинен сертифициращ орган). Това е като модела на ИКАО, който допуска само 2 нива — основен CSCA и подчинен DSC, подписан точно от този CSCA.

В случай че държава членка оперира собствен CSCA, тя носи отговорност за сигурната работа и управлението на ключовете на този сертифициращ орган. CSCA действа като котва на доверие за DSC, така че защитата на частния ключ на CSCA е от съществено значение за целостта на средата на DCC. Моделът на проверка в PKI на DCC представлява обвивка, която посочва, че всички сертификати, присъстващи в пътя на сертификата, трябва да са валидни в даден момент (тоест в момента на валидиране на подписа). Ето защо са в сила следните ограничения:

— CSCA не издава сертификати, които са с по-продължителна валидност от самия сертификат на сертифициращия орган.

— Подписващият орган не подписва документи, които са с по-продължителна валидност от самия DSC.

— Държавите членки, които оперират собствен CSCA, трябва да определят срокове на валидност за своите CSCA, както и за всички издавани сертификати, и трябва да се погрижат за подновяването на сертификатите.

Раздел 4.2 съдържа препоръки за сроковете на валидност.

3.3. Цялостност и автентичност на качените данни

Националните бек-ендове могат да използват DCCG, за да качват и изтеглят цифрово подписани пакети от данни след успешна взаимна автентификация. В началото тези пакети от данни съдържат DSC на държавите членки. Двойката ключове, използвана от националния бек-енд за цифрово подписване на качени пакети от данни в системата на DCCG, се нарича двойка ключове за подписване на качените от националния бек-енд данни, а съответното удостоверение за публичен ключ се съкращава като NB UP сертификат. Всяка държава членка осигурява свой собствен NB UP сертификат, който може да е самоподписан или издаден от съществуващ сертифициращ орган, като например обществен сертифициращ орган (т.е. сертифициращ орган, който издава сертификати в съответствие с основните изисквания на CAB-Forum). NB UP сертификатът се различава от всички други сертификати, издавани от държавата членка (напр. CSCA, TLS клиент или DSC).

Държавите членки трябва да предостави сертификата за качване на оператора на DCCG по време на първоначалната процедура по регистрация (вижте раздел 4.1 за повече подробности). Всяка държава членка носи отговорност за националните си данни и трябва да защитава частния ключ, използван за подписване на качените данни.

Други държави членки могат да проверяват подписаните пакети от данни, използвайки качени сертификати, предоставени от DCCG. DCCG проверява автентичността и целостта на качените данни със сертификат на NB за качване, преди да ги предостави на други държави членки.

3.4. Изисквания за техническата архитектура на DCCG

Изискванията за техническата архитектура на DCCG са, както следва:

— DCCG използва взаимна TLS автентификация, за да установи автентифицирана криптирана връзка с NB . Ето защо DCCG поддържа разрешен списък с регистрирани NB TLS клиентски сертификати.

— DCCG използва два цифрови сертификата (DCCG TLS и DCCG TA ) с две различни двойки ключове. Частният ключ на двойката ключове на DCCG TA се поддържа офлайн (а не в онлайн компонентите на DCCG).

— DCCG поддържа доверителен списък на NB CSCA сертификатите, подписани с частния ключ на DCCG TA .

— Използваните шифри трябва да отговарят на изискванията в раздел 5.1 .

4. Управление на жизнения цикъл на сертификатите

4.1. Регистрация на националните бек-ендове

Държавите членки трябва да се регистрират в оператора на DCCG, за да участват в системата на DCCG. В настоящия раздел се описва техническата и оперативна процедура, която трябва да се спазва при регистрация на национален бек-енд.

Операторът на DCCG и държавата членка трябва да обменят информация за техническите лица за връзка за процеса на присъединяване. Приема се, че техническите лица за връзка са легитимирани от съответните си държави членки и е извършено идентифициране/потвърждаване на самоличността посредством други канали. Например потвърждаването на самоличността може да се извърши, когато техническото лице за връзка на държавата членка предоставя сертификатите като криптирани с парола файлове посредством имейл и споделя съответната парола с оператора на DCCG по телефона. Могат да се използват и други сигурни канали, определени от оператора на DCCG.

Държавата членка трябва да предостави три цифрови сертификата по време на процеса на регистрация и идентификация:

— TLS сертификата на държавата членка, NB TLS

— Сертификата за качване на държавата членка, NB UP

— Сертификата/сертификатите на CSCA на държавата членка, NB C SCA

Всички предоставени сертификати трябва да спазват изискванията, определени в раздел 5. Операторът на DCCG ще провери дали предоставеният сертификат спазва изискванията на раздел 5. След идентифицирането и регистрацията операторът на DCCG:

— добавя сертификата/сертификатите NB CSCA към доверителния списък, подписан с частния ключ, който съответства на публичния ключ DCCG TA ;

— добавя сертификата NB TLS към разрешения списък в крайната точка на TLS на DCCG;

— добавя сертификата NB UP в системата на DCCG;

— предоставя удостоверенията за публичен ключ DCCG TA и DCCG TLS на държавата членка.

4.2. Сертифициращи органи, срокове на валидност и подновяване

В случай че държава членка иска да оперира собствен CSCA, сертификатите на CSCA може да са самоподписани. Те действат като котва на доверие на държавата членка и следователно тя трябва надеждно да защитава частния ключ, съответстващ на публичния ключ на сертификата на CSCA. Препоръчително е държавата членка да използва офлайн система за своя CSCA, т.е. компютърна система, която не е свързана към мрежа. Следва да се използва контрол от няколко лица за достъп до системата (например като се следва принципът на четирите очи). След подписване на DSC се прилагат оперативни проверки и системата, която съдържа частния ключ на CSCA, се съхранява на сигурно място с надежден контрол над достъп. Могат да се използват хардуерни модули за сигурност или смарт карти за допълнителна защита на частния ключ на CSCA. Цифровите сертификати съдържат срок на валидност, който налага подновяване на сертификатите. За подновяването трябва да се използват нови криптографски ключове и да се адаптират размерите им към новите подобрения в изчисляването или към новите атаки, застрашаващи сигурността на използвания криптографски алгоритъм. Прилага се моделът на обвивка (виж раздел 3.2).

Препоръчват се следните срокове на валидност предвид предоставената едногодишна валидност на цифровите сертификати за COVID:

— CSCA: 4 години

— DSC: 2 години

— Качване: 1 — 2 години

— Автентификация на TLS клиент: 1 — 2 години

За навременно подновяване се препоръчват следните срокове на използване за частните ключове:

— CSCA: 1 година

— DSC: 6 месеца

Държавите членки трябва навреме да създадат нови сертификати за качване и TLS сертификати, например един месец преди изтичането, за да се осигури безпроблемна работа. Сертификатите на CSCA и DSC следва да бъдат подновявани поне един месец преди края на срока на използване на частния ключ (предвид необходимите оперативни процедури). Държавите членки трябва да предоставят актуализирани сертификати на CSCA, сертификати за качване и TLS сертификати на оператора на DCCG. Изтеклите сертификати се премахват разрешения списък и доверителния списък.

Държавите членки и операторът на DCCG трябва да следят за валидността на собствените си сертификати. Няма централно звено, което поддържа справка за валидността на сертификатите и информира участниците.

4.3. Отмяна на удостоверения

Като цяло цифровите сертификати могат да се отменят от издаващия ги сертифициращ орган посредством списъци на отменени сертификати или услуга за онлайн протокол за състояние на сертификат (OCSP). CSCA за системата на DCC следва да предоставя списъци на отменени сертификати (CRL). Дори ако тези CRL понастоящем не се използват от други държави членки, те следва да бъдат внедрени за бъдещи приложения. В случай че CSCA реши да не предоставя CRL, DSC на този CSCA трябва да бъдат подновени, когато CRL станат задължителни. Проверяващите органи не следва да използват OCSP за валидиране на DSC, а следва да използват CRL. Препоръчително е националните бек-ендове да извършват необходимото валидиране на DSC, изтегляни от портала за DCC, и да препращат само набор от доверени и валидирани DSC към националните валидиращи органи за DCC. Валидиращите органи за DCC не следва да извършват проверка за отмяна на DSC в процеса си на валидиране. Една от причините за това е да се защити поверителността на притежателите на DCC, като се избягва рискът употребата на конкретен DSC да се следи от свързаната с него OCSP услуга.

Държавите членки могат да премахват самостоятелно своите DSC от DCCG, използвайки валидни сертификати за качване и TLS сертификати. Премахването на DSC означава, че всички DCC, издадени с него, ще станат невалидни, когато държавите членки се сдобият с актуализираните списъци на DSC. Защитата на частния ключ, съответстващ на DSC, е от решаващо значение. Държавите членки трябва да информират оператора на DCCG, когато те трябва да отменят сертификати за качване или сертификати TLS, например поради компрометиране на националния бек-енд. Операторът на DCCG тогава може да премахне доверието от засегнатия сертификат, например като го премахне от разрешения списък за TLS. Операторът на DCCG може да премахва сертификати за качване от базата данни на DCCG. Пакети, подписани с частния ключ, съответстващ на този сертификат за качване, ще станат невалидни, когато националните бек-ендове премахнат доверието от отменения сертификат за качване. В случай че трябва да бъде отменен сертификат на CSCA, държавите членки информират оператора на DCCG, както и другите държави членки, с които имат доверителни отношения. Операторът на DCC ще издаде нов доверителен списък, който вече не съдържа засегнатия сертификат. Всички DSC, издадени от този CSCA, ще станат невалидни, когато държавите членки актуализират доверителното хранилище на националния си бек-енд. В случай че трябва да бъде отменен сертификатът DCCGTLS или сертификатът DCCGTA, операторът на DCCG и държавите членки трябва да работят заедно, за да установят нова TLS доверителна връзка и доверителен списък.

5. Шаблони на сертификати

В настоящия раздел се разглеждат криптографските изисквания и насоки, както и изискванията за шаблоните на сертификатите. За сертификатите на DCCG настоящия раздел определя шаблоните на сертификатите.

5.1. Криптографски изисквания

Криптографските алгоритми и поредиците от TLS шифри се избират на базата на текущата препоръка от Германската федерална служба за сигурност на информацията (BSI) или SOG-IS. Тези препоръки и препоръките на други институции и организации за стандартизация са подобни. Препоръките могат да бъдат намерени в техническите ръководства TR 02102-1 и TR 02102-2 ( 16 ) или в Договорените криптографски механизми на SOG-IS ( 17 ).

5.1.1. Изисквания за DSC

Прилагат се изискванията от приложение I, раздел 3.2.2. Ето защо е силно препоръчително подписващите органи да използват алгоритъм за електронни подписи по елиптична крива (ECDSA) с NIST-p-256 (както е посочено в допълнение Г към FIPS PUB 186-4). Други елиптични криви не се поддържат. Поради ограниченията за място в DCC държавите членки не следва да използват RSA-PSS, дори ако той е допустим като резервен алгоритъм. В случай че държавите членки, използват RSA-PSS, те следва да използват размер на модула от 2048 или не повече от 3072 бита. SHA-2 с изходна дължина ≥ 256 бита се използва като криптографска хеш-функция (вж. ISO/IEC 10118-3:2004) за подписа на DSC.

5.1.2. Изисквания към TLS сертификати, сертификати за качване и сертификати за CSCA

За цифрови сертификати и криптографски подписи в контекста на DCCG основните изисквания към криптографските алгоритми и дължината на ключовете са обобщени в следната таблица (от 2021 г.):







Алгоритъм за подпис Размер на ключовете Хешираща функция EC-DSA Мин. 250 бита SHA-2 с дължина на изходната стойност ≥ 256 бита RSA-PSS (препоръчително запълване) RSA-PKCS#1, v1.5 (наследено запълване) RSA Модул (N) с мин. 3000 бита и с публичен експонент е > 2^16 SHA-2 с дължина на изходната стойност ≥ 256 бита DSA Просто число p с мин. 3000 бита, 250 бита ключ q SHA-2 с дължина на изходната стойност ≥ 256 бита

Препоръчителната елиптична крива за EC-DSA е NIST-p-256 поради широко разпространеното ѝ внедряване.

5.2. Сертификат на CSCA (NBCSCA)

Следната таблица предоставя насоки за шаблона на сертификата NB CSCA, ако държава членка реши да оперира собствен CSCA за DCC.

Записите в получер шрифт са задължителни (трябва да бъдат включени в сертификата), а тези в курсив — препоръчителни (следва да бъдат включени). За отсъстващи полета не са определени препоръки.







Поле Стойност Субект cn= <не празно и уникално обикновено име>, o=<доставчик>, c=<държава членка, оперираща CSCA> Използване на ключа certificate signing, CRL signing (като минимум) Основни ограничения CA = true, path length constraints = 0

Името на субекта трябва да бъде не празно и уникално в рамките на посочената държава членка. Кодът на държавата (с) трябва да съответства на държавата членка, която ще използва този сертификат на CSCA. Сертификатът трябва да съдържа уникален идентификатор на ключа на субекта (SKI) в съответствие с RFC 5280 ( 18 ).

5.3. Сертификат на подписващия документи орган (DSC)

В таблицата по-долу са дадени насоки относно DSC. Записите в получер шрифт са задължителни (трябва да бъдат включени в сертификата), а тези в курсив — препоръчителни (следва да бъдат включени). За отсъстващи полета не са определени препоръки.







Поле Стойност Сериен номер уникален сериен номер Субект cn= <не празно и уникално обикновено име>, o=<доставчик>, c=<държава членка, използваща този DSC> Използване на ключа digital signature (като минимум)

DSC трябва да бъде подписан с частен ключ, съответстващ на сертификата на CSCA, използван от държавата членка.

Трябва да се използват следните разширения:

— Сертификатът трябва да съдържа идентификатор на ключа на органа (AKI), съответстващ на идентификатора на ключа на субекта (SKI) на сертификата на издаващия CSCA;

— Сертификатът следва да съдържа уникален идентификатор на ключа на субекта (SKI) (в съответствие с RFC 5280 ( 19 )).

Освен това сертификатът следва да съдържа разширението на точката на разпределение на CRL, насочващо към списъка на отменени сертификати (CRL), предоставен от CSCA, издал DSC.

DSC може да съдържа разширение за разширено използване на ключовете с нула или повече идентификатори на политика за използване на ключовете, които ограничават типовете HCERT, които този сертификат има право да проверява. Ако е наличен един или повече, проверяващите органи проверят използването на ключа спрямо съхранения HCERT. За тази цел са определени следните стойности на разширеното използване на ключа:







Поле Стойност extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.1 за издатели за тестове extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.2 за издатели за ваксинация extendedKeyUsage 1.3.6.1.4.1.1847.2021.1.3 за издатели за възстановяване

Ако липсва разширение за използване на ключа (т.е. няма разширения или нула разширения), сертификатът може да се използва за валидиране на всеки тип HCERT. Други документи може да определят съответни допълнителни идентификатори на политика за разширено използване на ключовете, използвани при валидирането на HCERT.

5.4. Сертификати за качване (NBUP)

Следната таблица предоставя насоки за сертификата за качване на националните бек-ендове. Записите в получер шрифт са задължителни (трябва да бъдат включени в сертификата), а тези в курсив — препоръчителни (следва да бъдат включени). За отсъстващи полета не са определени препоръки.







Поле Стойност Субект cn= <не празно и уникално обикновено име>, o=<доставчик>, c=<държава членка, използваща този сертификат за качване> Използване на ключа digital signature (като минимум)

5.5. Автентификация на TLS клиент на национален бек-енд (NBTLS)

Следната таблица предоставя насоки за TLS клиентски сертификат на национален бек-енд за автентификация. Записите в получер шрифт са задължителни (трябва да бъдат включени в сертификата), а тези в курсив — препоръчителни (следва да бъдат включени). За отсъстващи полета не са определени препоръки.







Поле Стойност Субект cn= <не празно и уникално обикновено име>, o=<доставчик>, c=<държава членка на NB> Използване на ключа digital signature (като минимум) Разширено използване на ключ автенитификация на клиента ( 1.3.6.1.5.5.7.3.2)

Сертификатът може също да съдържа разиреното използване на ключ сървърна автентификация ( 1.3.6.1.5.5.7.3.1) за разширено използване на ключа, но това не е задължително.

5.6. Сертификат за подпис на доверителен списък (DCCGTA)

Следната таблица определя сертификата на котвата на доверие на DCCG.







Поле Стойност Субект cn = Портал за цифров зелен сертификат (1) , o=<доставчик>, c=<държава> Използване на ключа digital signature (като минимум) ( 1 ) Терминът „цифров зелен сертификат“ вместо „цифров COVID сертификат на ЕС“ е запазен в този контекст, тъй като това е терминът, който е записан и използван в сертификата преди съзаконодателите да вземат решение относно нов термин.

5.7. TLS сървърни сертификати на DCCG (DCCGTLS)

Следната таблица определя TLS сертификата на DCCG.







Поле Стойност Субект cn=<FQDN или IP адреса на DCCG>, o=<доставчик>, c= <държава> SubjectAltName dNSName: <име на DNS DCCG > или iPAddress: <IP адрес на DCCG> Използване на ключа digital signature (като минимум) Разширено използване на ключа сървърна автентификация ( 1.3.6.1.5.5.7.3.1)

Сертификатът може също да съдържа клиентска автентификация ( 1.3.6.1.5.5.7.3.2) за удължена употреба на ключа, но това не е задължително.

TLS сертификатът на DCCG се издава от публично доверен сертифициращ орган (включително във всички основни браузъри и операционни системи, като се спазват основните изисквания на CAB-Forum).

▼M1









ПРИЛОЖЕНИЕ V

СХЕМА JAVASCRIPT OBJECT NOTATION (JSON)

1. Увод

С настоящото приложение се установява техническата структура на данните за цифровите COVID сертификати на ЕС (EUDCC), представена като схемата JSON. Документът съдържа конкретни указания, свързани с отделните полета с данни.

2. Адрес на схемата JSON и нейните версии

Валидната официална схема JSON за EUDCC е на разположение на адрес: https://github.com/ehn-dcc-development/ehn-dcc-schema. Всеки друг адрес е невалиден, но може да се използва за подготвяне на предстоящи преразглеждания.

По подразбиране действащата версия, посочена в настоящото приложение и получила одобрението на всички държави, които я ползват понастоящем, е на разположение на посочения URL адрес.

Предстоящата следваща версия, която трябва да получи подкрепата на всички държави до определена дата, е на разположение на посочения URL адрес, маркирана като версия, както е описано по-подробно във файла Readme.

3. Общи структури и общи изисквания

Не се издава цифров COVID сертификат на ЕС, ако поради липсваща информация не всички полета с данни могат да бъдат правилно попълнени в съответствие с настоящата спецификация. Това не следва да се разбира като засягащо задължението на държавите членки да издават цифрови COVID сертификати на ЕС.

Информацията във всички полета може да се предоставя посредством пълния набор от символи UNICODE 13.0, кодирани с използване на UTF-8, освен при изрично ограничение до определени набори от стойности или до по-малки набори от знаци.

Общата структура е, както следва:

"JSON":{

"ver":<version information>,

"nam":{

<person name information>

},

"dob":<date of birth>,

"v" or "t" or "r":[

{<vaccination dose or test or recovery information, one entry>}

]

}

Подробна информация за отделни групи и полета се предоставя в следващите раздели.

3.1. Версия

Предоставя се информация за версията. Контролът на версиите се извършва по модела на семантичното управление на версиите (semver: https://semver.org). В експлоатация трябва да бъде една от официално пуснатите версии (настоящата или някоя от по-старите официално публикувани версии). За повече подробности вж. раздел JSON Schema location.







Идентификатор на поле Наименование на поле Указания ver Версия на схемата Трябва да съответства на идентификатора на версията на схемата, използвана за изготвянето на EUDCC. Пример: "ver":"1.3.0"

3.2. Име и дата на раждане на лицето

Името на лицето е официалното пълно име на лицето, което съответства на името, посочено в документите за пътуване. Идентификаторът на структурата е nam. Попълва се само 1 (едно) име на лице.







Идентификатор на полето Наименование на поле Указания nam/fn Фамилно(и) име(на) Фамилно(и) име(на) на притежателя Попълва се само 1 (едно) поле, което не може да се оставя празно, като всички фамилни имена са включени в него. В случай на няколко фамилни имена те се отделят с интервал. Комбинираните имена, включващи тирета или подобни знаци, трябва обаче да останат същите. Пример: "fn":"Musterfrau-Gößinger" "fn":"Musterfrau-Gößinger Müller" nam/fnt Стандартизирано(и) фамилно(и) име(на) Фамилно(и) име(на) на притежателя, транслитерирано(и) по правилата, използвани в машинночетимите документи за пътуване на притежателя (например правилата, определени в документ 9303 на ИКАО, част 3). Попълва се само 1 (едно) поле, което не може да се оставя празно, единствено със знаците A-Z и <. Максимална дължина: 80 знака (съгласно спецификацията на ИКАО 9303 ). Пример: "fnt":"MUSTERFRAU<GOESSINGER" "fnt":"MUSTERFRAU<GOESSINGER<MUELLER" nam/gn Собствено(и) име(на) Собствено(и) име(на), тоест собствено(и) име(на) на притежателя. Ако притежателят няма собствени имена, полето се пропуска. Във всички други случаи се попълва само 1 (едно) поле, което не може да се оставя празно, като всички собствени имена са включени в него. В случай на няколко собствени имена те се отделят с интервал. Пример: "gn":"Isolde Erika" nam/gnt Стандартизирано(и) лично(и) име(на) Лично(и) име(на) на притежателя, транслитерирано(и) по правилата, използвани в машинночетимите документи за пътуване на притежателя (например правилата, определени в документ 9303 на ИКАО, част 3). Ако притежателят няма собствени имена, полето се пропуска. Във всички други случаи се попълва само 1 (едно) поле, което не може да се оставя празно, единствено със знаците A-Z и <. Максимална дължина: 80 знака. Пример: "gnt":"ISOLDE<ERIKA" dob Дата на раждане Дата на раждане на притежателя на DCC Пълна или частична дата без час, ограничена до интервала от 1900-01-01 до 2099-12-31. Ако е известна пълната или частичната дата на раждане, се попълва само 1 (едно) поле, което не може да се оставя празно. Ако датата на раждане не е известна дори отчасти, полето се настройва на празен низ "". Това следва да съответства на информацията, предоставена в документите за пътуване. Ако е налична информация за датата на раждане, се използва един от следните формати по ISO 8601: Други варианти не се поддържат. ГГГГ-ММ-ДД ГГГГ-ММ ГГГГ (Приложението за проверка може да покаже липсващи части от датата на раждане посредством общоприетите знаци „ХХ“ като използваните в машинночетимите документи за пътуване, напр. 1990-XX-XX.) Пример: "dob":"1979-04-14" "dob":"1901-08" "dob":"1939" "dob":""

3.3. Групи за специфична информация за вида сертификат

Схемата JSON поддържа три групи вписвания, включващи информация за вида сертификат. Всеки EUDCC съдържа точно 1 (една) група. Не се допуска полето за група да остава непопълнено.







Идентификационен код на групата Наименование на групата Вписвания v Група полета „ваксинация“ Ако има такава, трябва да съдържа само 1 (един) запис, описващ само 1 доза ваксина (една доза). t Група полета „тест“ Ако има такава, трябва да съдържа само 1 (един) запис, описващ само 1 (един) резултат от тест. r Група полета „преболедуване“ Ако има такава, трябва да съдържа само 1 (един) запис, описващ само 1 (една) декларация за преболедуване.

4. Информация за вида сертификат

4.1. Сертификат за ваксинация

Ако има група полета „ваксинация“, тя трябва да съдържа само 1 (един) запис, описващ само една ваксинация (една доза). Всички елементи на групата полета „ваксинация“ са задължителни, не се поддържа оставянето на празни полета.







Идентификатор на полето Наименование на поле Указания v/tg Заболяване или патоген: COVID-19 (SARS-CoV или някой от неговите варианти) Кодово обозначение в набора от стойности disease-agent-targeted.json. Този набор от стойности има единствен запис — 840539006, което е кодът за COVID-19 по SNOMED CT (GPS). Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "tg":"840539006" v/vp Ваксина срещу COVID-19 или профилактика Тип използвана ваксина или профилактика. Кодово обозначение в набора от стойности vaccine-prophylaxis.json. Наборът от стойности се разпределя от портала EUDCC. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "vp":"1119349007" (ваксина SARS-CoV-2 mRNA) v/mp Ваксинационен продукт срещу COVID-19 Лекарствен продукт, използван за конкретната доза ваксинация. Кодово обозначение в набора от стойности vaccine-medicinal-product.json. Наборът от стойности се разпределя от портала EUDCC. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "mp":"EU/1/20/1528" (Comirnaty) v/ma Притежател на разрешението за търговия или производител на ваксината срещу COVID-19 Притежател на разрешение за търговия или производител, ако няма притежател на разрешение за търговия. Кодово обозначение в набора от стойности vaccine-mah-manf.json. Наборът от стойности се разпределя от портала EUDCC. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "ma":"ORG-100030215" (Biontech Manufacturing GmbH) v/dn Пореден номер при серия от дози Пореден номер (положително цяло число) на дозата, поставена по време на ваксинирането. 1 за първата доза, 2 за втората доза и т.н. По-конкретни правила се съдържат в раздел 5 от приложение II. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "dn":"1" (първа доза) "dn":"2"(втора доза) "dn":"3" (трета доза) v/sd Общ брой дози в серията. Общ брой дози (положително цяло число) във ваксинационната серия. По-конкретни правила се съдържат в раздел 5 от приложение II. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "sd":"1" (в случай на основна ваксинационна серия с 1 доза ваксина) "sd":"2" (в случай на основна ваксинационна серия с 2 дози или за допълнителна доза след основна ваксинационна серия с 1 доза) "sd":"3" (напр. в случай на допълнителни дози след основна ваксинационна серия с 2 дози) v/dt Дата на ваксинацията Датата, на която е получена посочената доза, във формат ГГГГ-ММ-ДД (пълна дата без час). Други формати не се поддържат. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "dt":"2021-03-28" v/co Държава членка или трета държава, в която е поставена ваксината Име на държавата, изразено с 2-буквен код по ISO3166 (ПРЕПОРЪЧИТЕЛНО) или име на международната организация, отговорна за поставената ваксина (като ВКБООН или СЗО). Кодово обозначение в набора от стойности country-2-codes.json. Наборът от стойности се разпределя от портала EUDCC. Попълва се само 1 (едно) поле. Пример: "co":"CZ" "co":"UNHCR" v/is Издател на сертификата Име на организацията, издала сертификата. Идентификаторите са позволени като част от името, но не е препоръчително да се използват отделно без него. Максимум 80 знака по UTF-8. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "is":"Ministry of Health of the Czech Republic" "is":"Vaccination Centre South District 3" v/ci Уникален идентификатор на сертификата Уникален идентификатор на сертификата (UVCI), както е посочено в https://ec.europa.eu/health/sites/default/files/ehealth/docs/vaccination-proof_interoperability-guidelines_en.pdf Включването на контролната сума не е задължително. Може да се добави префиксът "URN:UVCI:". Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.2. Сертификат за направено изследване

Ако има група полета „тест“, тя трябва да съдържа само 1 (един) запис, описващ само един резултат от тест.







Идентификатор на полето Наименование на поле Указания t/tg Заболяване или патоген: COVID-19 (SARS-CoV или някой от неговите варианти) Кодово обозначение в набора от стойности disease-agent-targeted.json. Този набор от стойности има единствен запис — 840539006, което е кодът за COVID-19 по SNOMED CT (GPS). Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "tg":"840539006" t/tt Вид на теста Вид на използвания тест или изследване въз основа на изпитвания материал. Кодово обозначение в набора от стойности test-type.json (въз основа на LOINC). Не се допускат стойности различни от тези в набора от стойности. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "tt":"LP6464-4" (Амплификация на нуклеинови киселини с детекция със сонда) "tt":"LP217198-3" (Бърз имуноанализ) t/nm Наименование на теста (само за тестове с амплификация на нуклеинови киселини) Наименование на използвания тест за амплификация на нуклеинови киселини (NAAT). Наименованието трябва да включва името на производителя на теста или изследването и търговското наименование на теста, разделени със запетая. За NAAT: полето не е задължително. За RAT: полето не се използва, тъй като наименованието на теста или изследването се получава непряко посредством идентификатора на изделието за тестуване (t/ma). Когато е налице, полето не трябва да е празно. Пример: "nm":"ELITechGroup, SARS-CoV-2 ELITe MGB® Kit" t/ma Идентификатор на изделието за тестуване (само за бързи тестове за антигени) Идентификатор на изделието за бърз тест за антигени (RAT) от базата данни на JRC. Набор от стойности (общ списък от КЗС): — Всички бързи тестове за антигени в общия списък на КЗС (в четим от човек вид). — https://covid-19-diagnostics.jrc.ec.europa.eu/devices/hsc-common-recognition-rat (в машинночетим вид, стойностите на полето id_device, включени в списъка, представляват набора от стойности). В държавите от ЕС/ЕИП издателите трябва да издават само сертификати за тестове от валидния в момента набор от стойности. Наборът от стойности се актуализира на всеки 24 часа. Стойности извън набора от стойности могат да се използват в сертификати, издадени от трети държави, но идентификаторите остават тези от базата данни на JRC. Не се разрешава използването на други идентификатори, като предоставяните пряко от производителите на тестове. Приложенията за проверка трябва да засичат стойностите, които не са част от актуалния набор от стойности, и изписват сертификатите с въпросните стойности като невалидни. Ако даден идентификатор бъде изваден от набора от стойности, сертификатите, които го съдържат, могат да се приемат в продължение на най-много 72 часа след това. Наборът от стойности се разпределя от портала EUDCC. За RAT: попълва се само 1 (едно) поле, което не може да се оставя празно. За NAAT: полето не се използва дори и идентификаторът на изследването NAA да присъства в базата данни на JRC. Пример: "ma":"344" (SD BIOSENSOR Inc, STANDARD F COVID-19 Ag FIA) t/sc Дата и час на вземане на проба за изследване Датата и часа, в които е взета пробата за изследване. Часът включва информация за часовата зона. Стойността не трябва да указва часа, когато е получен резултатът от изследването. Попълва се само 1 (едно) поле, което не може да се оставя празно. Използва се един от следните формати по ISO 8601: Други варианти не се поддържат. ГГГГ-ММ-ДДТчч:мм:ссZ ГГГГ-ММ-ДДТчч:мм:сс[+-]чч ГГГГ-ММ-ДДТчч:мм:сс[+-]ччмм ГГГГ-ММ-ДДТчч:мм:сс[+-]чч:мм Пример: "sc":"2021-08-20T10:03:12Z" Час по координирано универсално време (UTC) "sc":"2021-08-20T12:03:12+02" Централноевропейско време (CEST) "sc":"2021-08-20T12:03:12+0200" Централноевропейско време (CEST) "sc":"2021-08-20T12:03:12+02:00" Централноевропейско време (CEST) t/tr Резултат от изследването или теста Резултат от изследването или теста. Кодово обозначение в набора от стойности test-result.json (въз основа на SNOMED CT, GPS). Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "tr":"260415000" (отрицателна проба) t/tc Център или заведение, извършил изследването Име на организацията, извършила изследването. Идентификаторите са позволени като част от името, но не е препоръчително да се използват отделно без него. Максимум 80 знака по UTF-8. Всички допълнителни знаци трябва да се отстранят. Името не се поддава на автоматизирана проверка. За изследвания NAAT: попълва се само 1 (едно) поле, което не може да се оставя празно. За изследвания RAT: полето не е задължително. Ако се предостави, не може да е празно. Пример: "tc":"Test centre west region 245" t/co Държава членка или трета държава, в която е направено изследването Име на държавата, изразено с 2-буквен код по ISO3166 (ПРЕПОРЪЧИТЕЛНО) или име на международната организация, отговорна за извършеното изследване (като ВКБООН или СЗО). Това трябва да бъде кодово обозначение от набора от стойности country-2-codes.json. Наборът от стойности се разпределя от портала EUDCC. Попълва се само 1 (едно) поле. Пример: "co":"CZ" "co":"UNHCR" t/is Издател на сертификата Име на организацията, издала сертификата. Идентификаторите са позволени като част от името, но не е препоръчително да се използват отделно без него. Максимум 80 знака по UTF-8. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "is":"Ministry of Health of the Czech Republic" "is":"North-West region health authority" t/ci Уникален идентификатор на сертификата Уникален идентификатор на сертификата (UVCI), както е посочено в vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Включването на контролната сума не е задължително. Може да се добави префиксът "URN:UVCI:". Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"

4.3. Сертификат за преболедуване

Ако има група полета „преболедуване“, тя трябва да съдържа само 1 (един) запис, описващ само едно преболедуване. Всички елементи на групата „преболедуване“ са задължителни, не се поддържа оставянето на празни полета.







Идентификатор на полето Наименование на поле Указания r/tg Заболяване или патоген, което/който притежателят е преболедувал: COVID-19 (SARS-CoV-2 или някой от неговите варианти) Кодово обозначение в набора от стойности disease-agent-targeted.json. Този набор от стойности има единствен запис — 840539006, което е кодът за COVID-19 по SNOMED CT (GPS). Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "tg":"840539006" r/fr Дата на първия положителен резултат от изследване NAAT на притежателя Датата, на която е взета пробата за изследване NAAT, дало положителен резултат, във формат ГГГГ-ММ-ДД (попълнете дата без час). Други формати не се поддържат. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "fr":"2021-05-18" r/co Държава членка или трета държава, в която е направен тестът Име на държавата, изразено с 2-буквен код по ISO3166 (ПРЕПОРЪЧИТЕЛНО) или име на международната организация, отговорна за извършеното изследване (като ВКБООН или СЗО). Това трябва да бъде кодово обозначение от набора от стойности country-2-codes.json. Наборът от стойности се разпределя от портала EUDCC. Попълва се само 1 (едно) поле. Пример: "co":"CZ" "co":"UNHCR" r/is Издател на сертификата Име на организацията, издала сертификата. Идентификаторите са позволени като част от името, но не е препоръчително да се използват отделно без него. Максимум 80 знака по UTF-8. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "is":"Ministry of Health of the Czech Republic" "is":"Central University Hospital" r/df Сертификат, валиден от Първата дата, на която сертификатът се счита за валиден. Датата не може да предхожда датата, изчислена като r/fr + 11 days. Датата се представя във формат ГГГГ-ММ-ДД (пълна дата без час). Други формати не се поддържат. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "df":"2021-05-29" r/du Сертификат, валиден до Последната дата, на която сертификатът се счита за валиден — посочва се от издателя на сертификата. Датата не може да бъде по-късна от датата, изчислена като r/fr + 180 days. Датата се представя във формат ГГГГ-ММ-ДД (пълна дата без час). Други формати не се поддържат. Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "du":"2021-11-14" r/ci Уникален идентификатор на сертификата Уникален идентификатор на сертификата (UVCI), както е посочено в vaccination-proof_interoperability-guidelines_en.pdf (europa.eu) Включването на контролната сума не е задължително. Може да се добави префиксът "URN:UVCI:". Попълва се само 1 (едно) поле, което не може да се оставя празно. Пример: "ci":"URN:UVCI:01:NL:187/37512422923" "ci":"URN:UVCI:01:AT:10807843F94AEE0EE5093FBC254BD813#B"