ПРИЛОЖЕНИЕ 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, а не със злонамерeна организация, представяща се за 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 използва два цифрови сертификата (DCCGTLS и DCCGTA) с две различни двойки ключове. Частният ключ на двойката ключове на DCCGTA се поддържа офлайн (а не в онлайн компонентите на DCCG).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 (1) или в Договорените криптографски механизми на SOG-IS (2).

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

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

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

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

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

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

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

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

Освен това сертификатът следва да съдържа разширението на точката на разпределение на 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 = Портал за цифров зелен сертификат (5) , o=<доставчик>, c=<държава> Използване на ключа digital signature (като минимум)

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

(1) BSI — Техническо ръководство TR-02102 (bund.de)

(2) SOG-IS — Поддържаща документация (sogis.eu)

(3) rfc5280 (ietf.org)

(4) rfc5280 (ietf.org)

(5) Терминът „цифров зелен сертификат“ вместо „цифров COVID сертификат на ЕС“ е запазен в този контекст, тъй като това е терминът, който е записан и използван в сертификата преди съзаконодателите да вземат решение относно нов термин.