2009D0767 — BG — 01.07.2013 — 002.001

---

Този документ е средство за документиране и не обвързва институциите

►B

▼C1 РЕШЕНИЕ НА КОМИСИЯТА от 16 октомври 2009 година за определяне на мерки, улесняващи прилагането на процедури с помощта на електронни средства чрез „единични звена за контакт“ в съответствие с Директива 2006/123/ЕО на Европейския парламент и на Съвета относно услугите на вътрешния пазар (нотифицирано под номер C(2009) 7806) (текст от значение за ЕИП) (2009/767/ЕО) ▼B (ОВ L 274, 20.10.2009, p.36)

Изменен с

		Официален вестник
		No	page	date
►M1	РЕШЕНИЕ НА КОМИСИЯТА от 28 юли 2010 година	L 199	30	31.7.2010
►M2	РЕГЛАМЕНТ (ЕС) № 519/2013 НА КОМИСИЯТА от 21 февруари 2013 година	L 158	74	10.6.2013

поправен от

►C1	Поправка, ОВ L 299, 14.11.2009,  18  (767/2009)
►C2	Поправка, ОВ L 004, 7.1.2011,  6  (767/2009)

---

▼B

▼C1

РЕШЕНИЕ НА КОМИСИЯТА

от 16 октомври 2009 година

за определяне на мерки, улесняващи прилагането на процедури с помощта на електронни средства чрез „единични звена за контакт“ в съответствие с Директива 2006/123/ЕО на Европейския парламент и на Съвета относно услугите на вътрешния пазар

(нотифицирано под номер C(2009) 7806)

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

(2009/767/ЕО)

Член 1

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

1.  Когато е оправдано, въз основа на подходящ анализ на съответните рискове и в съответствие с член 5, параграфи 1 и 3 от Директива 2006/123/ЕО, държавите-членки могат да изискат от доставчика на услуги да използва при осъществяването на определени процедури и формалности чрез единичните звена за контакт съгласно член 8 от Директива 2006/123/ЕО усъвършенствани електронни подписи на базата на квалифицирани удостоверения със или без използването на механизъм (устройство) за създаване на защитени електронни подписи, както е определено и регулирано с Директива 1999/93/ЕО.

2.  Държавите-членки следва да приемат всеки усъвършенстван електронен подпис на базата на квалифицирано удостоверение със или без използването на механизъм (устройство) за създаване на защитени електронни подписи за осъществяването на процедурите и формалностите, посочени в параграф 1, като това не засяга правото на държавите-членки да ограничат приеманите усъвършенствани електронни подписи до такива на базата на квалифицирано удостоверение с използването на механизъм (устройство) за създаване на защитени електронни подписи, когато това е в съответствие с оценката на риска, посочена в параграф 1.

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

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

Член 2

Създаване, поддържане и публикуване на доверителни списъци

1.  Всяка държава-членка създава, поддържа и публикува в съответствие с определените в приложението технически спецификации „доверителен списък“, съдържащ минималната изисквана информация по отношение на намиращите се под неин надзор и притежаващи нейна акредитация доставчици на удостоверителни услуги, издаващи квалифицирани удостоверения за потребители.

▼M1

2.  Държавите-членки създават и публикуват доверителен списък както в четима от човек форма, така и в машинно четима форма в съответствие с определените в приложението технически спецификации.

▼M1

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

▼M1

3.  Държавите-членки съобщават на Комисията следната информация:

▼M1

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

▼C1

Член 3

Прилагане

Настоящото решение се прилага от 28 декември 2009 г.

Член 4

Адресати

Адресати на настоящото решение са държавите-членки.

---

ПРИЛОЖЕНИЕ

ТЕХНИЧЕСКИ СПЕЦИФИКАЦИИ ЗА ОБЩ ОБРАЗЕЦ НА „ДОВЕРИТЕЛЕН СПИСЪК НА ДОСТАВЧИЦИ НА УДОСТОВЕРИТЕЛНИ УСЛУГИ ПОД НАДЗОР/АКРЕДИТАЦИЯ“

ПРЕДГОВОР

1.    Обща информация

С общия образец на „Доверителен списък на доставчици на удостоверителни услуги с акредитация и под надзор“ се цели създаването на общ формат за предоставяне на информация от държавите-членки за състоянието на надзора/акредитацията на намиращите се под техен надзор/акредитация по отношение на съвместимостта със съответните разпоредби на Директива 1999/93/ЕО доставчици на удостоверителни услуги ( 3 ) (ДУУ). Това включва предоставянето на историческа информация за състоянието на поднадзорните/акредитираните удостоверителни услуги.

Задължителната информация в доверителния списък (ДС) трябва да включва минималната необходима информация за поднадзорните/акредитираните ДУУ, издаващи квалифицирани удостоверения (КУ) ( 4 ) в съответствие с разпоредбите на Директива 1999/93/ЕО (член 3, параграф 3, член 3, параграф 2 и член 7, параграф 1, буква а), в това число информация за КУ, поддържащи електронен подпис, и дали подписът е създаден с помощта на механизъм (устройство) за създаване на защитени електронни подписи (SSCD) ( 5 ).

Допълнителна информация за други поднадзорни/акредитирани ДУУ, които не издават КУ, но предлагат услуги, свързани с електронния подпис (например ДУУ, предлагащи услуги за времеви печати (Time Stamping Services) и издаващи времеви маркери (Time Stamp Tokens); ДУУ, издаващи неквалифицирани удостоверения и т.н.) може да бъде включена на доброволна основа в доверителния списък на национално ниво.

Тази информация е предназначена преди всичко да подкрепи валидирането на квалифицирани електронни подписи (КЕП) ( 6 ) и усъвършенствани електронни подписи (УЕП) ( 7 ) ( 8 ) с помощта на квалифицирано удостоверение.

Предложеният общ образец е съгласуван с приложение на базата на спецификациите TS 102 231 ( 9 ) на ETSI, които разглеждат създаването, публикуването, разполагането, достъпа, идентифицирането и удостоверяването на такъв вид списъци.

2.    Насоки за редактиране на данни в ДС

2.1.    ДС, насочен към удостоверителни услуги под надзор/акредитация

Доверителният списък на една държава-членка се определя като „Списък на състоянието на надзора и акредитациите на удостоверителните услуги, предлагани от доставчици на удостоверителни услуги под надзор на/акредитирани от посочената държава-членка относно съвместимостта им със съответните разпоредби на Директива 1999/93/ЕО“.

Такъв доверителен списък трябва да обхваща:

Съгласно определенията и разпоредбите, дадени в Директива 1999/93/ЕО, по-конкретно по отношение на съответните ДУУ, техните системи за надзор/доброволна акредитация, могат да бъдат разграничени два вида ДУУ, а именно ДУУ, които издават КУ на потребители (ДУУКУ), и ДУУ, които не издават КУ на потребители, но предлагат „други (допълнителни) услуги, свързани с електронните подписи“:

Доверителният списък на държавата-членка трябва да предлага минималната необходима информация за поднадзорните/акредитираните ДУУ, издаващи квалифицирани удостоверения за потребители в съответствие с разпоредбите на Директива 1999/93/ЕО (член 3, параграф 3, член 3, параграф 2 и член 7, параграф 1, буква а), информация за КУ, поддържащи електронен подпис, и дали подписът е създаден с помощта на механизъм (устройство) за създаване на защитени електронни подписи.

Допълнителна информация за други поднадзорни/акредитирани услуги на ДУУ, които не издават КУ на потребители (например ДУУ, предлагащи услуги за времеви печати (Time Stamping Services) и издаващи времеви маркери (Time Stamp Tokens), ДУУ, издаващи неквалифицирани удостоверения и т.н.) може да бъде включена на доброволна основа в доверителния списък на национално ниво.

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

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

Фактът, че услугата към момента е под надзор или акредитирана, е елемент на нейното актуално състояние. Освен това състоянието на надзор или акредитация може да бъде „текущо“ („ongoing“), „в процес на преустановяване“ („in cessation“), „преустановено“ („ceased“) и дори „отменено“ („revoked“). В рамките на своето съществуване една удостоверителна услуга може да преминава от режим на надзор в режим на акредитация и обратно ( 10 ).

Фигура 1 показва очакваните преходи на дадена удостоверителна услуга между възможните състояния на акредитация/надзор:

►(7) C2  

►(7) C2  

►(7) C2  

►(7) C2  

►(7) C2  

►(7) C2  

►(7) C2  

Една удостоверителна услуга, издаваща КУ, трябва задължително да бъде под надзор (ако е установена в държава-членка) и може да бъде доброволно акредитирана. Стойността на състоянието на такава услуга, когато е включена в доверителния списък, може да бъде коя да е от посочените по-горе „актуални стойности на състоянието“. Трябва обаче да се отбележи, че стойностите „преустановена акредитация“ и „отменена акредитация“ трябва да бъдат само „преходни състояния“ при услуги на ДУУКУ, установени в държава-членка, тъй като такива услуги трябва да са поднадзорни по подразбиране (дори когато вече не са акредитирани).

Изисква се държави-членки, които създават или са създали дефинирани в национален мащаб „признати схеми за одобрение“, използвани на национална основа за надзор на съвместимостта на услугите на ДУУ, които не издават КУ, с разпоредбите на Директива 1999/93/ЕО и с евентуални национални разпоредби относно предлагането на удостоверителни услуги (по смисъла на член 2, параграф 11 от директивата), да категоризират такива „схеми за одобрение“ в една от следните две категории:

По същия начин, удостоверителна услуга, която не издава КУ, може да бъде под надзор или доброволно акредитирана. Стойността на състоянието на такава услуга, когато е включена в доверителния списък, може да бъде коя да е от посочените по-горе „актуални стойности на състоянието“ (вж. фигура 1).

Доверителният списък трябва да съдържа информация за прилаганите схеми за надзор/акредитация, по-конкретно:

Последните два пакета от информация са от ключово значение за оценяването от доверяващите се страни на качеството и нивото на сигурност на такива системи за надзор/акредитация, приложени на национално ниво към ДУУ, които не издават КУ. Когато в ДС се предлага информация за състоянието на надзора/акредитациите по отношение на ДУУ, които не издават КУ, гореспоменатите пакети от информация се предлагат на ниво ДС, като се използват „URI за информация за схемата (Scheme information URI)“ (клауза 5.3.7 — информация, предоставяна от държавите-членки), „Тип/общност/правила на схемата (Scheme type/community/rules)“ (клауза 5.3.9, като се използват общи за всички държави-членки формулировки и незадължителна, предоставяна от държавата-членка, специфична информация) и „Политика/правен коментар на ССДУ (TSL policy/legal notice)“ (клауза 5.3.11 — обща за всички държави-членки формулировка, позоваваща се на Директива 1999/93/ЕО, и възможност за всяка държава-членка да добави специфични национални формулировки или позовавания). Допълнителна, „квалифицираща“ информация на нивото на националните системи за надзор/акредитация на ДУУ, които не издават КУ, може да бъде предложена на нивото на услугата, ако е уместно и необходимо (например за да се различават отделните нива на качество/сигурност), като се използва разширението „additionalServiceInformation“ (клауза 5.8.2) като част от „Service information extension“ (клауза 5.5.9). Допълнителна информация за съответните технически спецификации се предлага в подробните спецификации в глава I.

Въпреки възможността надзорът и акредитацията в дадена държава-членка да се осъществяват от различни органи, се очаква да се използва едно-единствено вписване за дадена удостоверителна услуга (идентифицирана чрез своята „Service digital identity“ (цифрова идентификация на услугата) съгласно ETSI TS 102 231 ( 11 ) и нейното състояние на надзор/акредитация да се актуализира съответно. Значението на посочените по-горе състояния е разяснено в съответната клауза 5.5.4 на подробните технически спецификации в глава I.

2.2.    Вписвания в ДС с цел улесняване на валидирането на КЕП и УЕПКУ

Най-критичната част от създаването на ДС е установяването на задължителната част на ДС, а именно на „Списъка на услугите“ на всеки ДУУ, издаващ КУ, с цел да се отрази коректно състоянието на издаване на всяка такава услуга за издаване на КУ и да се гарантира, че предоставената във всяко вписване информация е достатъчна за валидирането на КЕП и УЕПКУ (когато се комбинира със съдържанието на потребителското КУ, издадено от ДУУ в рамките на удостоверителната услуга, посочена в даденото вписване).

В този смисъл, тъй като не съществува наистина оперативно съвместим и общоприет профил за КУ, изискваната информация може да бъде различна от „Service digital identity“ на даден (базов) УО, по-специално информация относно състоянието на КУ на издаденото удостоверение, както и информация дали поддържаните подписи са били създадени с SSCD. Органът на държавата-членка, натоварен със създаването, актуализирането и поддръжката на ДС (т.е. операторът на схемата съгласно ETSI TS 102 231) трябва следователно да вземе предвид настоящия профил и съдържанието на удостоверението за всяко КУ, издадено от ДУУКУ, който е включен в ДС.

В идеалния случай всяко издадено КУ следва да съдържа определената от ETSI декларация QcCompliance ( 12 ), когато е обявено като КУ, и да съдържа определената от ETSI декларация QcSSCD, когато се твърди, че то се поддържа от SSCD при генерирането на електронни подписи и/или всяко издадено удостоверение включва един от обектните идентификатори (OIDs) на политиката за сертифициране QCP/QCP+, определени в ETSI TS 101 456 ( 13 ). Използването на разнородни стандарти от страна на ДУУ, издаващи КУ, голямата свобода на интерпретация, която тези стандарти позволяват, както и липсата на осведоменост относно наличието и приоритета на някои технически спецификации или стандарти са довели до разлики в действителното съдържание на издаваните понастоящем КУ (напр. относно използването или не на определените от ETSI декларации) и съответно не позволяват на получателя просто да разчита на удостоверението на подписания (и свързаната с него верига от удостоверения) при извършването на оценка (най-малкото на машинна такава) дали удостоверението, поддържащо електронен подпис е обявено за КУ и дали то е свързано с SSCD, чрез което е бил създаден електронният подпис.

Допълването на полетата „Service type identifier“ („Sti“), „Service name“ („Sn“) и „Service digital identity“ („Sdi“) ( 14 ) с информация, предоставена в полето „Service information extensions“ („Sie“), дава възможност чрез предложения общ образец на ДС да се определи напълно специфичният тип на едно квалифицирано удостоверение, издадено от удостоверяваща услуга на включен в списъка ДУУ, издаващ КУ, и да се предостави информация дали то се поддържа от SSCD или не (когато такава информация липсва в издаденото КУ). С това вписване, разбира се, е свързана специфична информация в полето „Service current status“ („Scs“). Това е показано на фигура 2 по-долу.

Включването на услуга в списъка, за която се предлага само информацията „Sdi“ на (базовия) УО ще означава, че е гарантирано (от ДУУ, издаващ КУ, но и от надзорния/акредитиращия орган, отговарящ за надзора/акредитацията на този ДУУ), че всяко потребителско удостоверение, издадено от този (базов) УО, съдържа достатъчно дефинирана от ETSI и обработваема машинно информация, за да може да бъде оценено дали то е КУ и дали се поддържа от SSCD. Когато например последното твърдение не е вярно (т.е. липсва стандартизирана от ETSI и обработваема машинно информация в КУ дали то се поддържа от SSCD), то въз основа само на информацията „Sdi“ на (базовия) УО ще може единствено да се предположи, че КУ, издадени от тази йерархия на (базови) УО, не се поддържат от SSCD. За да се обозначат тези КУ като поддържани от SSCD, „Sie“ следва да указва този факт (като това ще означава също, че коректността на информацията се гарантира от ДУУ, издаващ КУ и намиращ се под надзора/акредитацията на надзорен или акредитиращ орган съответно).

►(1) C2  

Настоящите технически спецификации на общ образец за ДС позволяват използването на комбинация от пет основни елемента на информацията за вписаната услуга:

2.3.    Насоки за редактиране и използване на вписвания на услуги от ДУУКУ

Основните насоки за редактиране са:

Основен принцип по подразбиране е, че при вписаните в доверителния списък ДУУ трябва да има едно вписване за всяка услуга и за всяко отделно удостоверение от тип X.509v3 за удостоверителни услуги от тип УО/КУ (т.е. удостоверителен орган, издаващ (пряко) КУ). В някои внимателно определени ситуации и грижливо контролирани условия надзорният орган/акредитиращият орган на държава-членка може да реши да използва X.509v3 удостоверения на базов УО или такъв от по-високо ниво (например УО, който не издава непосредствено потребителски удостоверения, но сертифицира йерархични вериги от УО до нивото на УО, издаващи потребителски удостоверения) като информация в полето „Sdi“ на отделен елемент от списъка на услугите на вписан ДУУ. Последствията (предимства и недостатъци) от използването на X.509v3 базови УО или УО от по-високо ниво като стойности в полето „Sdi“ на услуги от ДС трябва да бъдат добре премислени от държавите-членки. Освен това, когато се прилага това изключение от основния принцип, държавите-членки трябва да осигурят необходимата документация, даваща възможност за конструиране и проверка на удостоверителната верига.

За онагледяване на основните правила за редактиране служи следният пример: в контекста на ДУУКУ, които използват базов УО, използван от множество УО за издаване на КУ, но чиито КУ съдържат само декларацията QcCompliance без информация относно поддръжката от SSCD, указването на „Sdi“ на базовия УО ще означава единствено (съгласно правилата, обяснени по-горе), че всяко КУ, издадено от йерархичната верига на този базов УО, НЕ се поддържа от SSCD. Препоръчва се настоятелно използването на декларацията QcSSCD в издаваните в бъдеще удостоверения, ако тези КУ в действителност се поддържат от SSCD. Междувременно (до изтичането на срока на валидност на последното УО, което не съдържа тази информация) в ССДУ следва да се използва полето „Sie“ и свързаното разширение „Qualifications“, напр. филтриране на удостоверения чрез специфични дефинирани от ДУУКУ OID, които евентуално се използват от ДУУКУ за разграничаване на различните видове КУ (поддържани от SSCD или не), и съдържащи изрична „информация за поддръжката от SSCD“ с оглед на удостоверенията, филтрирани въз основа на „квалификатори“.

Основните насоки за използване на приложения на електронния подпис, услуги или продукти, ползващи ССДУ реализация на доверителния списък в съответствие с настоящите технически спецификации, са следните:

Стойност „CA/QC“ (УО/КУ) в полето „Sti“ (по подобен начин това важи за стойност „CA/QC“ (УО/КУ), квалифицирана допълнително като базова (RootCA/QC) чрез полето „Sie“ (additionalServiceInformation extension)

2.4.    Услуги, които поддържат услуги от типа „УО/КУ“, но не са обозначени като „УО/КУ“ в „Sdi“

Случаите, в които CR списъци (CRL — Certificate Revocation List) и OCSP отговори (OCSP — Online Certificate Status Protocol) са подписани с ключове, различни от тези на УО, издаващ КУ („УО/КУ“), следва също да бъдат обхванати. Това може да стане чрез включване на тези услуги като такива в ССДУ реализацията на ДС (т.е. с „Service type identifier“, квалифициран допълнително чрез разширението „additionalServiceInformation“, деклариращо дадена услуга за OCSP или CRL като част от предоставянето на КУ, напр. чрез тип на услугата „OCSP/QC“ или „CRL/QC“ съответно), тъй като тези услуги могат да бъдат считани за част от поднадзорните/акредитираните „квалифицирани“ услуги, свързани с предлагането на удостоверителните услуги с КУ. Разбира се, издаващите OCSP отговори или CR списъци, чиито удостоверения са подписани от УО в йерархичната верига на вписана услуга от тип УО/КУ, следва да се приемат за „валидни“ и съответстващи на състоянието на вписана услуга от тип УО/КУ.

Подобна разпоредба може да се приложи към удостоверителните услуги, издаващи неквалифицирани удостоверения (услуги от тип „CA/PKC“), използващи типовете по подразбиране за OCSP и CRL услуги, съгласно ETSI TS 102 231.

Следва да се отбележи, че ССДУ реализацията на ДС ТРЯБВА да включва услуги за оттегляне на удостоверения, ако подобна информация не е включена в полето AIA на потребителските удостоверения или не е подписана от УО, който е измежду включените в списъка.

2.5.    Създаване на оперативно съвместим профил на КУ

По принцип целта трябва да бъде възможно най-значително опростяване (намаляване) на броя на вписаните услуги (различни „Sdi“). За сметка на това обаче следва да се идентифицират коректно услугите, които са свързани с издаването на КУ и предоставянето на надеждна информация дали тези КУ се поддържат от SSCD, ако тази информация липсва в издаденото КУ.

В идеалния случай употребата на полето „Sie“ и на разширението „Qualification“ следва да бъде (строго) ограничена до специалните случаи, които се решават чрез нея, тъй като КУ следва да съдържат достатъчно информация относно декларираното квалифицирано състояние и декларираното наличие/липса на поддръжка от SSCD.

Доколкото е възможно държавите-членки следва да налагат приемането и употребата на съвместими профили на КУ.

3.    Структура на общия образец за доверителния списък

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

В контекста на ДУУ, издаващи УО, еднозначната идентификация на поднадзорна/акредитирана удостоверителна услуга, подлежаща на включване в списъка, трябва да вземе предвид случаите, при които липсва достатъчно информация в квалифицираното удостоверение относно неговото „квалифицирано“ състояние, евентуалната му поддръжка от SSCD, и особено да реши проблема, произтичащ от факта, че повечето (търговски) ДУУ използват един единствен издателски квалифициран УО за издаването на множество различни типове потребителски удостоверения — както квалифицирани, така и неквалифицирани.

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

1.    Информация за доверителния списък и неговата схема на издаване

В тази категория ще бъде поместена следната информация:

2.    Еднозначна информация за всеки ДУУ, признат в съответствие със схемата

Този пакет от информации ще включва най-малко следното:

3.    За всеки включен в списъка ДУУ, поредица от полета, съдържащи информация за еднозначно идентифициране на удостоверителна услуга, предлагана от ДУУ и попадаща под надзор/акредитация по смисъла на Директива 1999/93/ЕО

Този пакет от информации ще включва най-малко следното за всяка удостоверителна услуга, предлагана от включен в списъка ДУУ:

4.    За всяка включена в списъка услуга, идентификация на актуалното състояние на услугата и историята на състоянието

Този пакет от информации ще включва най-малко следното:

4.    Определения и съкращения

За целите на настоящия документ се прилагат следните определения и съкращения:

ГЛАВА I

ПОДРОБНИ СПЕЦИФИКАЦИИ ЗА ОБЩИЯ ОБРАЗЕЦ НА „ДОВЕРИТЕЛЕН СПИСЪК НА ДОСТАВЧИЦИ НА УДОСТОВЕРИТЕЛНИ УСЛУГИ ПОД НАДЗОР/АКРЕДИТАЦИЯ“

В следващата част от документа ключовите думи „ТРЯБВА“, „НЕ ТРЯБВА/ТРЯБВА ДА НЕ“, „ЗАДЪЛЖИТЕЛЕН“, „СЛЕДВА“, „НЕ СЛЕДВА“, „БИ ТРЯБВАЛО“, „НЕ БИ ТРЯБВАЛО“, „ПРЕПОРЪЧИТЕЛЕН“, „МОЖЕ“ и „НЕЗАДЪЛЖИТЕЛЕН“ следва да се интерпретират в съответствие с термините на английски, описани в RFC 2119 ( 15 ).

►M1  Настоящите спецификации се основават на спецификациите и изискванията, определени в ETSI TS 102 231 v.3.1.2. Когато в настоящите спецификации липсва конкретно изискване, ТРЯБВА изцяло да се прилагат изискванията на ETSI TS 102 231 v.3.1.2. ◄ Когато в настоящите спецификации съществуват конкретни изисквания, те СЛЕДВА да заместят съответните изисквания на ETSI TS 102 231, като се допълват от форматните спецификации на ETSI TS 102 231. В случай на противоречия между настоящите спецификации и спецификациите от ETSI TS 102 231, настоящите спецификации СЛЕДВА да са меродавни.

Езикова поддръжка СЛЕДВА да се реализира и предлага най-малко за английски (EN) и евентуално за един или повече национални езици в допълнение.

Индикацията на времето СЛЕДВА да се съгласува с клауза 5.1.4 от ETSI TS 102 231.

Използването на унифицирани идентификатори на ресурси (URI) СЛЕДВА да се съгласува с клауза 5.1.5 от ETSI TS 102 231.

Информация за схемата на издаване на доверителен списък

Tag (таг)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да се съгласува с клауза 5.2.1 от ETSI TS 102 231.

▼M1 —————

▼C1

Scheme Information (информация за схемата)

Това поле е ЗАДЪЛЖИТЕЛНО и стойността му СЛЕДВА да е числото „3“ (като цяло число).

▼M1

Това поле е ЗАДЪЛЖИТЕЛНО. То ТРЯБВА да указва поредния номер на TSL. Като започва от „1“ за първото издание на TSL, стойността на това цяло число ТРЯБВА да се увеличава за всяко следващо издание на TSL. Стойността НЕ ТРЯБВА да започва отново от „1“, когато по-горната стойност на „TSL version identifier“ е увеличена.

▼C1

▼M1

Това поле е ЗАДЪЛЖИТЕЛНО и указва типа на TSL. То ТРЯБВА да съдържа стойността http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/TSLType/generic (Generic).

▼C1

Забележка: За да отговарят на клауза 5.3.3 от ETSI TS 102 231 и да указват специфичния тип на ССДУ, като същевременно се съобразяват с правилата за създаване на реализации на доверителни списъци ( 16 ) на държавите-членки на базата на ССДУ, установени от настоящите спецификации, и да позволят на парсера (parser = синтактичен анализатор) да определи в какъв формат трябва да очаква следващите полета ( 17 ), тъй като тези полета имат специфично (или алтернативно) значение в зависимост от типа на ССДУ (в настоящия случай това е доверителен списък на една държава-членка), горният URI СЛЕДВА да се регистрира и описва като:

▼M1

URI : (Generic) http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/TSLType/generic

▼C1

Описание : ССДУ реализацията на списък на състоянието на надзора и акредитациите на удостоверителните услуги, предлагани от доставчици на удостоверителни услуги, намиращи се под пряк надзор/акредитация (доброволно или задължително) на посочената държава-членка, която притежава тази реализация, относно съвместимостта им със съответните разпоредби на Директива 1999/93/ЕО.

Това поле е ЗАДЪЛЖИТЕЛНО. То СЛЕДВА да указва името на органа на държавата-членка, отговарящ за създаването, издаването и поддръжката на националния доверителен списък. То СЛЕДВА да указва официалното име, под което работи упълномощеното юридическо лице или упълномощената организация (например държавни административни агенции), която се свързва с този орган. То ТРЯБВА да е името, използвано при формалната юридическа регистрация или оправомощаването, към което следва да се насочва всякакъв вид формална комуникация. То СЛЕДВА да представлява последователност от многоезични символни низове и СЛЕДВА да се реализира задължително на английски (EN) и евентуално на един или повече национални езици.

Забележка: Една държава МОЖЕ да има различни надзорни и акредитиращи органи и дори допълнителни органи за сродни оперативни дейности. ►M1  Всяка държава-членка определя оператора на схемата (Scheme operator) на TSL реализацията на своя доверителен списък. ◄ Очаква се надзорният орган, акредитиращият орган и операторът на схемата (когато са отделни органи) да имат свои собствени отговорности и задължения.

Всяка ситуация, в която различни органи отговарят за надзор, акредитиране или оперативни аспекти, СЛЕДВА да се отразява и обозначава надлежно като такава в информацията за схемата като част от ДС, в това число специфичната информация за схемата, указана в „Scheme information URI“ (клауза 5.3.7).

▼M1

Посоченият оператор на схемата (Scheme operator, клауза 5.3.4) е организацията, която подписва TSL.

▼C1

Това поле е ЗАДЪЛЖИТЕЛНО. То СЛЕДВА да указва адресите на юридическото лице или упълномощената организация, посочени в полето „Scheme operator name“ (клауза 5.3.4), за пощенски и електронни комуникации. То СЛЕДВА да включва както „PostalAddress“ (т.е. улица, селище, [щат или провинция], [пощенски код] и двубуквен код на държавата по ISO 3166-1) съгласно клауза 5.3.5.1, така и „ElectronicAddress“ (т.е. електронна поща и/или уебсайт) съгласно клауза 5.3.5.2.

Това поле е ЗАДЪЛЖИТЕЛНО и указва името, под което действа схемата. То СЛЕДВА да бъде последователност от многоезични символни низове (реализирани задължително на английски (EN) и евентуално на един или повече национални езици), дефинирана както следва:

Името на схемата е необходимо, за да се идентифицира еднозначното схемата, посочена чрез „Scheme information URI“, а също и за да се гарантира, в случай че операторът на схемата поддържа повече от една схема, че всяка от тези схеми е получила различно име.

Държавите-членки и операторите на схеми СЛЕДВА да гарантират, че когато държава-членка или оператор на схема поддържат повече от една схема, всяка от тях получава различно име.

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да посочва идентификатори (URI), чрез които потребителите (доверяващите се страни) могат да получат специфична за схемата информация (като английската езикова версия се предоставя задължително, а евентуално може да съществуват и други национални езикови версии). То СЛЕДВА да бъде последователност от многоезични указатели (реализирани задължително на английски (EN) и евентуално на един или повече национални езици). Указаните URI ТРЯБВА да предлагат адрес за достъп до информация, даваща „подходяща информация за схемата“.

Тази „подходяща информация за схемата“ СЛЕДВА да включва най-малко:

Допълнителна специфична за държавата-членка информация за схемата МОЖЕ да бъде предоставена на доброволна основа. Тя СЛЕДВА да включва:

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да съдържа идентификатора на документа, описващ подхода за определяне на състоянието. СЛЕДВА да се използва следният специфичен идентификатор (URI), както е постановено и описано по-долу:

URI : http://uri.etsi.org/TrstSvc/eSigDir-1999-93-EC-TrustedList/StatusDetn/appropriate

Описание : Състоянието на изброените услуги се определя от (или от името на) оператор на схемата по подходяща система за съответната държава-членка, която позволява „надзора“ (и когато е уместно, „доброволната акредитация“) на доставчици на удостоверителни услуги, установени на нейна територия (или на територията на трета държава в случай на „доброволна акредитация“) и издаващи квалифицирани удостоверения на потребителите в съответствие с член 3, параграф 3 (съответно член 3, параграф 2 или член 7, параграф 1, буква а) от Директива 1999/93/ЕО, и позволява, когато е уместно, „надзора“/„доброволната акредитация“ на доставчици на удостоверителни услуги, които не издават квалифицирани удостоверения, в съответствие с определени и изградени на национално ниво „признати схеми за одобрение“, прилагани на национална основа за надзор на съвместимостта на услугите на ДУУ, които не издават КУ, с разпоредбите на Директива 1999/93/ЕО и евентуално разширени от национални разпоредби по отношение на предлагането на такива услуги.

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да съдържа най-малко следните URI:

В контекста на настоящите спецификации това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да определя държавата, в която е установена схемата (двубуквен код на държавата по ISO 3166-1).

В контекста на настоящите спецификации това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да определя политиката на схемата или предлага коментар относно правния статут на схемата или законовите изисквания, на които тя е подчинена и юрисдикцията, в която тя е установена, и/или ограниченията и условията, при които доверителният списък се поддържа и публикува.

То СЛЕДВА да бъде многоезичен символен низ (неформатиран текст), състоящ се от две части:

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва продължителността на периода (като цяло число), през който в ССДУ се предоставя историческа информация. Това цяло число посочва броя на дните и в контекста на настоящите спецификации то СЛЕДВА да бъде по-голямо от или равно на 3 653 (т.е. една ССДУ реализация на ДС на държава-членка ТРЯБВА да съдържа историческа информация за период от минимум десет години). По-големите стойности следва да са надлежно съобразени със законовите изисквания на държавата-членка, посочена в „Scheme Territory“ (клауза 5.3.10).

В контекста на настоящите спецификации това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да съдържа препратка (когато такава е налице) към съобразен с изискванията на ETSI TS 102 231 списък, съставен от Европейската комисия и съдържащ препратки (указатели) към всички ССДУ реализации на доверителни списъци на държавите-членки. Спецификациите на ETSI TS 102 231, клауза 5.3.13 важат при регламентирането на използването на незадължителната цифрова идентификация, представяща посочения издател на ССДУ, във формата, определен в клауза 5.5.3.

Забележка: Това поле НЕ СЛЕДВА да се използва, докато се очаква създаването на съгласувания с ETSI TS 102 231 и съставен от Европейската комисия списък на препратки към ССДУ реализациите на доверителни списъци на държавите-членки.

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва датата и часа (универсално координирано време, изразено във формат Zulu) на издаване на ССДУ, като стойностите за дата и час отговарят на спецификациите от ETSI TS 102 231, клауза 5.1.4.

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва датата и часа (универсално координирано време, изразено във формат Zulu) на издаване на следващия ССДУ, или е празно, чрез което се указва, че ССДУ е приключен (използваните стойности за дата и час отговарят на спецификациите от ETSI TS 102 231, клауза 5.1.4).

В случай че няма междинни промени в състоянието на включените в схемата ДДУ или услуги, ССДУ ТРЯБВА да бъде преиздаден в момента на изтичане на последния издаден ССДУ.

В контекста на настоящите спецификации разликата между стойностите за дата и час в полето „Next update“ и тези в „List issue date and time“ НЕ СЛЕДВА да надвишава шест (6) месеца.

Това поле е НЕЗАДЪЛЖИТЕЛНО. Ако се използва, то СЛЕДВА да указва адресите, на които е публикувана актуалната ССДУ реализация на ДС и където могат да бъдат намерени актуални версии на настоящия ССДУ. Ако са указани няколко точки на разпространение, те СЛЕДВА да предлагат идентични копия на настоящия ССДУ или на неговата актуализирана версия. Когато се използва, това поле се форматира като непразна последователност от символни низове, всеки от които е съвместим с RFC 3986 ( 19 ).

Това поле е НЕЗАДЪЛЖИТЕЛНО и не се използва в контекста на настоящата спецификация.

List of Trust Service Providers (списък на доставчиците на доверителни услуги)

Това поле е НЕЗАДЪЛЖИТЕЛНО.

В случай че няма или не е имало поднадзорни/акредитирани ДУУ в контекста на схемата на държава-членка, това поле НЕ СЛЕДВА да съществува. Има споразумение обаче, че дори ако в дадена държава-членка липсват поднадзорни или акредитирани ДУУ по схемата, държавите-членки СЛЕДВА да създадат ССДУ, в който обаче това поле не съществува. Липсата на ДУУ в списъка СЛЕДВА да се тълкува като липса на поднадзорни/акредитирани ДУУ на територията на държавата, посочена в „Scheme Territory“.

В случай че една или повече услуги на ДУУ са или са били под надзор/акредитация на схемата, то полето СЛЕДВА да съдържа последователност, идентифицираща всеки ДУУ, предлагащ една или повече от тези поднадзорни/акредитирани услуги, и подробности относно състоянието на надзор/акредитация и история на състоянието на всяка от услугите на ДУУ (на фигурата по-долу ДДУ = ДУУ).

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

►(12) C2  

На горната фигура е изобразен списък на ДДУ. За всеки ДДУ съществува последователност от полета, съдържащи информация за ДДУ („TSP Information“), следвана от списък на услуги. За всяка от тези изброени услуги съществува последователност от полета, съдържащи информация за услугата („Service Information“), и последователност от полета относно историята на състоянието на одобряване на услугата („Service approval history“).

TSP Information (информация за ДДУ)

TSP(1) (ДДУ(1)

TSP name (име на ДДУ) (клауза 5.4.1)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва името на юридическото лице, отговарящо за услугите на ДУУ, които са или са били под надзор/акредитация в рамките на схемата. То представлява последователност от многоезични символни низове (реализирани задължително на английски (EN) и евентуално на един или повече национални езици). Това име ТРЯБВА да е името, използвано при формалната юридическа регистрация, към което следва да се насочва всякакъв вид формална комуникация.

TSP trade name (търговско име на ДДУ) (клауза 5.4.2)

Това поле е НЕЗАДЪЛЖИТЕЛНО и ако съществува, СЛЕДВА да указва алтернативно име, с което един ДУУ се идентифицира в специфичния контекст на предлаганите от него услуги, които могат да бъдат намерени в настоящия ССДУ под неговото име, вписано в полето „TSP name“ (клауза 5.4.1).

Забележка: Когато един ДУУ (едно юридическо лице) предлага услуги под различни търговски имена или в няколко различни специфични контекста, може да съществуват толкова вписвания на ДУУ, колкото специфични контекста има (напр. двойки вписвания име/търговско име). Алтернативно може всеки ДУУ да се вписва само веднъж (юридическо лице), като се дава информация за специфичния контекст в зависимост от услугата. Операторът на схемата на държавата-членка следва да обсъди и постигне споразумение с ДУУ за най-уместния подход.

TSP address (адрес на ДДУ) (клауза 5.4.3)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва адресите на юридическото лице или упълномощената организация, посочени в полето „TSP name“ (клауза 5.4.1), за пощенски и електронни комуникации. То СЛЕДВА да включва както „PostalAddress“ (т.е. улица, селище, [щат или провинция], [пощенски код] и двубуквен код на държавата по ISO 3166-1) съгласно клауза 5.3.5.1, така и „ElectronicAddress“ (т.е. електронна поща и/или уебсайт) съгласно клауза 5.3.5.2.

TSP information URI (URI за информация за ДДУ) (клауза 5.4.4)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва адресите (URI), на които потребителите (доверяващите се страни) могат да получат специфична за ДУУ информация. То СЛЕДВА да бъде последователност от многоезични указатели (реализирани задължително на английски (EN) и евентуално на един или повече национални езици). Указаните URI ТРЯБВА да предлагат адрес за достъп до информация относно общите условия и задължения на ДУУ, неговата практика, юридически въпроси, неговата политика спрямо клиентите и друга основна информация, която засяга всички негови услуги, изброени в рамките на неговото вписване в ССДУ.

Забележка: Когато един ДУУ (юридическо лице) предлага услуги под различни търговски имена или в няколко различни специфични контекста и това е отразено чрез наличието на толкова вписвания на ДУУ, колкото контекста съществуват, това поле СЛЕДВА да съдържа информация, свързана със специфичния набор от услуги, изброени в рамките на вписването за конкретната двойка име/търговско име на ДУУ.

TSP information extensions (разширена информация за ДДУ) (клауза 5.4.5)

Това поле е НЕЗАДЪЛЖИТЕЛНО и ако съществува, МОЖЕ да бъде използвано от оператора на схемата в съответствие със спецификациите ETSI TS 102 231 (клауза 5.4.5), за поместване на специфична информация, която се интерпретира съгласно правилата на специфичната схема.

List of Services (списък на услуги)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да съдържа последователност, описваща всяка от признатите услуги на ДУУ и нейното състояние (и историята на това състояние) на одобрение. В списъка трябва да е включена поне една услуга (дори ако информацията за нея е изцяло историческа).

Тъй като съхраняването на историческа информация за изброените услуги е ЗАДЪЛЖИТЕЛНО според настоящите спецификации, тази историческа информация ТРЯБВА да бъде запазена, дори ако настоящото състояние на услугата не налага непременно включването ѝ в списъка (напр. ако тя е оттеглена). Следователно даден ДУУ ТРЯБВА да бъде включен в списъка, дори ако единствената негова включена в списъка услуга е в състояние, което налага включване в списъка единствено с цел запазване на информацията.

Service Information (информация за услугата)

TSP(1) Service(1) (ДДУ(1) услуга(1)

Service type identifier (идентификатор на типа на услугата) (клауза 5.5.1)

▼M1

Това поле е ЗАДЪЛЖИТЕЛНО и ТРЯБВА да указва идентификатора на типа на услугата в съответствие с типа на настоящите спецификации за TSL (т.е. „/eSigDir-1999-93-EC-TrustedList/TSLType/generic“).

▼C1

Ако посочената услуга е свързана с издаването на квалифицирани удостоверения, то указаният URI СЛЕДВА да бъде http://uri.etsi.org/TrstSvc/Svctype/CA/QC (удостоверителен орган, издаващ квалифицирани удостоверения).

Ако посочената услуга е свързана с издаването на токени на доверителни услуги, които не са КУ и не спомагат за издаването на КУ, указаният URI СЛЕДВА да бъде един от определените и посочени в клауза D.2 на ETSI 102 231 идентификатори, отнасящи се до това поле. Това правило СЛЕДВА да се прилага дори за онези токени на доверителни услуги, които са под надзор/акредитация относно съвместимостта с някои специфични изисквания съгласно националните законодателства на държавите-членки (напр. квалифицирани времеви маркери в Германия или Унгария), като посочените URI СЛЕДВА да бъдат измежду определените в спецификацията ETSI 102 231 и изброени в нейната клауза D.2 идентификатори, отнасящи се до това поле (напр. TSA за определени на национална основа квалифицирани времеви маркери). Когато е уместно, такава специфична национална квалификация на токени на доверителни услуги МОЖЕ да бъде включена във вписването на доверителната услуга, като за тази цел СЛЕДВА да се използват полетата „additionalServiceInformation extension“ (клауза 5.8.2) и „Service information extension“ (клауза 5.8.2).

Основен принцип по подразбиране е, че СЛЕДВА да има по едно вписване за всяко отделно удостоверение от тип X.509v3 (напр. за удостоверителни услуги от тип УО/КУ) сред вписаните удостоверителни услуги на включен в доверителния списък ДУУ (напр. удостоверителен орган, издаващ (непосредствено) КУ). В някои внимателно определени ситуации и грижливо контролирани условия надзорният орган/акредитиращият орган на държава-членка МОЖЕ да реши да използва X.509v3 удостоверения на базов УО или такъв от по-високо ниво (например УО, който не издава непосредствено потребителски удостоверения, но сертифицира йерархични вериги от УО, достигащи до нивото на УО, издаващи потребителски удостоверения) като информация в полето „Sdi“ на отделен елемент от списъка на услугите на вписан ДУУ. Последствията (предимства и недостатъци) от използването на X.509v3 базови УО или УО от по-високо ниво като стойности в полето „Sdi“ на услуги от ДС трябва да бъдат добре премислени от държавите-членки ( 20 ). Освен това, когато се прилага такова едно разрешено изключение от основния принцип, държавите-членки ТРЯБВА да осигурят необходимата документация, даваща възможност за конструиране и проверка на удостоверителната верига.

Забележка: ДУУ от рода на издаващите OCSP отговори или CR списъци, които са част от удостоверителни услуги на ДУУКУ и използват отделни двойки ключове за подписването съответно на OCSP отговори и CR списъци, МОГАТ да бъдат включени също така и в настоящия образец за ССДУ чрез използването на следната комбинация от URI:

Service name (име на услугата) (клауза 5.5.2)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва името, под което указаният в полето „TSP name“ (клауза 5.4.1) ДУУ предлага услугата, указана в полето „Service type identifier“ (клауза 5.5.1). То СЛЕДВА да бъде последователност от многоезични символни низове (реализирани задължително на английски (EN) и евентуално на един или повече национални езици).

Service digital identity (цифрова идентификация на услугата) (клауза 5.5.3)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва поне един уникален за услугата цифров идентификатор, чийто тип е посочен в „Service type identifier“ (клауза 5.5.1) и чрез който услугата може да бъде идентифицирана еднозначно.

В настоящите спецификации цифровият идентификатор, посочен в това поле, СЛЕДВА да бъде съответно удостоверение от тип X.509v3, което е форма на публичните ключове, чрез които ДУУ предлага услугата, чийто тип е указан в „Service type identifier“ (клауза 5.5.1) (т.е. ключът, използван от базов УО/КУ, ключът, с който се подписват удостоверенията ( 21 ) или алтернативно се издават времеви маркери, или се подписват CR списъци или OCSP отговори). Това удостоверение от тип X.509v3 СЛЕДВА да се използва като минимално необходим цифров идентификатор (един вид публични ключове, които ДУУ използва, за да предложи услугата). Допълнителни идентификатори МОГАТ да се използват, както следва, но всички те ТРЯБВА да препращат към същата идентификация (т.е. към съответното удостоверение от тип X.509v3):

Основен принцип е, че един цифров идентификатор (т.е. съответното удостоверение от тип X.509v3) НЕ СЛЕДВА да фигурира повече от един път в доверителния списък, т.е. СЛЕДВА да съществува само по едно вписване за всяко удостоверение от тип X.509v3 в рамките на една удостоверителна услуга, фигурираща сред услугите на даден ДУУ, включен в доверителния списък. Обратно, конкретно удостоверение от тип X.509v3 СЛЕДВА да се използва в полето „Sdi“ на една-единствена услуга.

Забележка 1: Единственият случай, в който не е необходимо да се спазва горепосоченият основен принцип, е когато конкретно удостоверение от тип X.509v3 се използва при издаването на различни типове токени на доверителни услуги, за които са в сила различни схеми за надзор/акредитация, например когато удостоверение от тип X.509v3 се използва от ДУУ от една страна при издаване на КУ в рамките на подходяща система за надзор, а от друга страна при издаване на неквалифицирани удостоверения под надзора/акредитацията на друга система. В този случай ще бъдат използвани две вписвания с различни стойности „Sti“ (в горния пример съответно CA/QC и CA/PKC) и еднакви стойности „Sdi“ (съответното удостоверение от тип X.509v3).

Реализациите са обвързани с ASN.1 или XML и СЛЕДВА да са съгласувани със спецификацията ETSI TS 102 231 (вж. приложение А към ETSI TS 102 231 за ASN.1 и приложение B към ETSI TS 102 231 за XML).

Забележка 2: Когато е необходима допълнителна „квалифицираща“ информация за дадено вписване на услуга и ако е уместно, операторът на схемата СЛЕДВА да използва разширението „additionalServiceInformation“ (клауза 5.8.2) на полето „Service information extension“ (клауза 5.5.9) с цел осигуряване на такава допълнителна „квалифицираща“ информация. Допълнително операторът на схемата може да използва по желание клауза 5.5.6 („Scheme service definition URI“).

Service current status (актуално състояние на услугата) (клауза 5.5.4)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва идентификатора на състоянието на услугата с помощта на един от следните URI:

▼M1

▼C1

Горепосочените състояния СЛЕДВА да се интерпретират в контекста на настоящите спецификации на доверителния списък, както следва:

—

Under Supervision (под надзор) : услугата, посочена в „Service digital identity“ (клауза 5.5.3) и предлагана от доставчика на удостоверителни услуги (ДУУ), указан в „TSP name“ (клауза 5.4.1), е понастоящем под надзор относно съвместимостта ѝ с разпоредбите на Директива 1999/93/ЕО от страна на държавата-членка, посочена в „Scheme territory“ (клауза 5.3.10), в която е установен ДУУ.

▼M1

—

Supervision of Service in Cessation (услуга в процес на преустановяване на надзора) : услугата, посочена в „Service digital identity“ (клауза 5.5.3) и предлагана от CSP, указан в „TSP name“ (клауза 5.4.1), е понастоящем на етап преустановяване на надзора, но все още е под надзор до преустановяването или отменянето на надзора. В случай че отговорността за осигуряване на този етап на преустановяване е поета от юридическо лице, различно от посоченото в „TSP name“, идентификацията на това ново или подсигуряващо юридическо лице (подсигуряващ CSP) ТРЯБВА да се предостави в „Scheme service definition URI“ (клауза 5.5.6) и в разширението „TakenOverBy“ (клауза L.3.2) на записа за услугата.

▼C1

—

Supervision Ceased (преустановен надзор) : валидността на оценката за целите на надзора е изтекла и услугата, посочена в „Service digital identity“ (клауза 5.5.3), не е оценена повторно. Услугата на е повече под надзор от датата на настоящото състояние, като това означава, че услугата вече не функционира.

—

Supervision Revoked (отменен надзор) : услугата или самият ДУУ, които са били под надзор в миналото, не удовлетворяват повече разпоредбите на Директива 1999/93/ЕО, според оценката на държавата-членка, посочена в „Scheme territory“ (клауза 5.3.10), в която е установен ДУУ. Съответно се изисква услугата да прекрати дейността си и се счита, че тя вече не функционира поради горепосочената причина.

Забележка 1: Стойността „Supervision Revoked“ може бъде окончателна, дори ако впоследствие ДУУ прекрати своята дейност; в този случай не е необходимо да се променя състоянието на „Supervision of Service in Cessation“ или на „Supervision Ceased“. Всъщност, единственият начин за промяна на състоянието „Supervision Revoked“ е услугата да възстанови съвместимостта си с разпоредбите на Директива 1999/93/ЕО по преценка на съответната система на надзор, действаща в държавата-членка, притежаваща ДС, и да си възвърне състоянието „Under Supervision“. Състоянията на „Supervision of Service in Cessation“ или на „Supervision Ceased“ се заемат само ако ДУУ непосредствено преустанови своите съответни услуги под надзор, но не и когато надзорът е отменен.

—

Accredited (акредитирана) : акредитиращият орган е провел от името на държавата-членка, посочена в „Scheme territory“ (клауза 5.3.10), оценка с цел акредитиране и услугата, посочена в „Service digital identity“ (клауза 5.5.3) и предлагана от ДУУ ( 22 ), указан в „TSP name“ (клауза 5.4.1), се счита за съвместима с разпоредбите на Директива 1999/93/ЕО.

Забележка 2: Когато се използват в контекста на ДУУ, издаващ КУ, който е установен на територията, посочена в „Scheme territory“ (клауза 5.3.10), състоянията „Accreditation Revoked“ и „Accreditation Ceased“ ТРЯБВА да бъдат считани за „преходни състояния“ и НЕ ТРЯБВА да бъдат използвани като стойности в полето „Service current status“, тъй като (ако се използват) те ТРЯБВА да бъдат последвани незабавно от състояние „Under supervision“ в полето „Service approval history information“ или в полето „Service current status“, евентуално последвано от друго състояние на надзор измежду посочените по-горе, както е указано на фигура 1. Когато се използват в контекста на ДУУ, който не издава КУ, и съществува само схема за „доброволна акредитация“ без съответна схема за надзор или в контекста на ДУУ, издаващ КУ, който не е установен на територията, посочена в „Scheme territory“ (клауза 5.3.10) (напр. в трета държава), споменатите състояния „Accreditation Revoked“ и „Accreditation Ceased“ МОГАТ да се използват като стойности в полето „Service current status“:

—	Accreditation Ceased (преустановена акредитация) : валидността на оценката за целите на акредитирането е изтекла и услугата, посочена в „Service digital identity“ (клауза 5.5.3), не е оценена повторно.

—

Accreditation Revoked (отменена акредитация) : услугата, посочена в „Service digital identity“ (клауза 5.5.3) и предлагана от доставчика на удостоверителни услуги (ДУУ), указан в „TSP name“ (клауза 5.4.1), след като първоначално е удовлетворявала критериите на схемата вече не отговаря на изискванията (или това се отнася за нейния доставчик) на разпоредбите на Директива 1999/93/ЕО.

Забележка 3: Използват се едни и същи стойности за ДУУ, издаващи КУ, и за ДУУ, които не издават КУ (напр. доставчици на услуги за времеви печати, издаващи времеви маркери, ДУУ, издаващи неквалифицирани удостоверения и т.н.). Полето „Service type identifier“ (клауза 5.5.1) се използва за указване на различните приложими системи за надзор/акредитация.

Забележка 4: Допълнителна, свързана със състоянието „квалифицираща“ информация, дефинирана на нивото на националните системи за надзор/акредитация на ДУУ, които не издават КУ, МОЖЕ да бъде предоставена на ниво услуга, когато е уместно и се изисква (например за да се разграничават различни нива на качество/сигурност). Операторите на схемите СЛЕДВА да използват разширението „additionalServiceInformation“ (клауза 5.8.2) на полето „Service information extension“ (клауза 5.5.9) с цел осигуряване на такава допълнителна „квалифицираща“ информация. Допълнително операторът на схемата може да използва по желание клауза 5.5.6 („Scheme service definition URI“).

Current status starting date and time (начална дата и час на актуалното състояние) (клауза 5.5.5)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва датата и часа на преминаване в актуалното състояние (стойностите за дата и час отговарят на спецификациите от ETSI TS 102 231, клауза 5.1.4).

Scheme service definition URI (URI за определенията на услугите на схемата) (клауза 5.5.6)

Това поле е НЕЗАДЪЛЖИТЕЛНО и ако съществува, СЛЕДВА да указва онези URI, чрез които доверяващите се страни могат да получат специфична информация за услугите, предлагани от оператора на схемата, под формата на многоезични указатели (като английската езикова версия се предоставя задължително, а евентуално може да съществуват и други национални езикови версии).

Когато се използва полето, указаните URI ТРЯБВА да предлагат адрес за достъп до информация, описваща услугата, както е определено от схемата. Когато е уместно, то може да съдържа по-конкретно:

Service supply points (точки за доставка на услугата) (клауза 5.5.7)

Това поле е НЕЗАДЪЛЖИТЕЛНО и ако съществува, СЛЕДВА да указва онези URI, чрез които доверяващите се страни могат да получат достъп до услугатаq чрез поредица от символни низове, чийто синтаксис ТРЯБВА да е в съответствие с RFC 3986.

TSP service definition URI (URI за определенията на услугите на ДДУ) (клауза 5.5.8)

Това поле е НЕЗАДЪЛЖИТЕЛНО и ако съществува, СЛЕДВА да указва онези URI, чрез които доверяващите се страни могат да получат специфична информация за услугите, предлагани от ДДУ, под формата на многоезични указатели (като английската езикова версия се предоставя задължително, а евентуално може да съществуват и други национални езикови версии). Използваните URI ТРЯБВА да предлагат адрес за достъп до информация, описваща услугата, както е определена от ДДУ.

Service information extensions (разширена информация за услугата) (клауза 5.5.9)

В контекста на настоящите спецификации това поле е НЕЗАДЪЛЖИТЕЛНО, но СЛЕДВА да се използва, ако предоставената в „Service digital identity“ (клауза 5.5.3) информация не е достатъчна за еднозначното идентифициране на квалифицираните удостоверения, издадени от тази услуга, и/или наличната информация в съответните квалифицирани удостоверения не позволява да бъде установено чрез машинна обработка дали КУ се поддържа от SSCD ( 23 ).

Когато неговата употреба е ЗАДЪЛЖИТЕЛНА в контекста на настоящите спецификации, напр. за услуги от типа УО/КУ, незадължителното поле „Service digital identity“ („Sie“) СЛЕДВА да се използва и структурира в съответствие с разширението „Qualifications“, определено в приложение L.3.1 към ETSI TS 102 231, като поредица от един или повече кортежи, като всеки кортеж включва:

Тези квалификатори се използват в разширение само ако типът на услугата е http://uri.etsi.org/TrstSvc/Svctype/CA/QC.

Това поле зависи от реализацията (ASN.1 или XML) и ТРЯБВА да е съгласувано със спецификациите от приложение L.3.1 към ETSI TS 102 231.

▼M1

В контекста на XML реализация специфичното съдържание на тази допълнителна информация трябва да се кодира, като се използват файловете xsd, предоставени в приложение C на ETSI TS 102 231.

▼C1

Service Approval History (история на одобрението на услугата)

Това поле е НЕЗАДЪЛЖИТЕЛНО, но ТРЯБВА да съществува, ако стойността на „Historical information period“ (клауза 5.3.12) не е нула. В контекста на настоящите спецификации схемата ТРЯБВА да съхранява историческа информация. В случай че се предвижда съхраняването на историческа информация, но услугата няма история, предхождаща настоящото състояние (т.е. това е първото ѝ състояние или историческата информация не е съхранена от оператора на схемата), това поле СЛЕДВА да бъде празно. В противен случай за всяка промяна на актуалното състояние на дадена услуга на ДУУ, която се е случила по време на историческия период, посочен в ETSI TS 102 231, клауза 5.3.12, СЛЕДВА да се предоставя информация за предходното състояние на одобрение в низходящ хронологичен ред на промените на състоянието (т.е. датата и часа на влизане в сила на следващото състояние на одобрение).

Това СЛЕДВА да бъде последователност от исторически данни, както е описано по-долу.

TSP(1) Service(1) History(1) (ДДУ(1) услуга(1) история(1)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва идентификатора на типа на услугата във формата и със значението, използвани в „TSP Service Information — Service type identifier“ (клауза 5.5.1).

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва името, под което ДУУ предлага услугата, указана в полето „TSP Service Information —Service type identifier“ (клауза 5.5.1), във формата и със значението, използвани в „TSP Service Information — Service name“ (клауза 5.5.2). Не се изисква името в тази клауза да бъде същото като в клауза 5.5.2. Промяната на името МОЖЕ да е една от причините за приемането на ново състояние.

▼M1

Това поле е ЗАДЪЛЖИТЕЛНО и ТРЯБВА да указва поне една форма на цифровия идентификатор (например удостоверение X.509v3), използван в „TSP Service Information — Service digital identity“ (клауза 5.5.3) във формата и със значението, определени в ETSI TS 102 231, клауза 5.5.3.

Забележка: За стойност на удостоверението X.509v3, използвана в „Sdi“ клауза 5.5.3 на услуга, трябва да съществува само едно вписване на услугата в доверителен списък за стойността „Sti:Sie/additionalServiceInformation“. Информацията в поле „Sdi“ (клауза 5.6.3), използвана в информацията за историята на състоянието на одобряване на услуга във връзка с вписването на услуга, и използваната в това вписване на услуга информация „Sdi“ (клауза 5.5.3) ТРЯБВА да се отнасят за същата стойност на удостоверението X.509v3. Когато за вписана услуга се променя „Sdi“ (т.е. подновяване или нов ключ на удостоверение X.509v3 например за CA/PKC или CA/QC) или се създава нова „Sdi“ за такава услуга дори с идентични стойности за свързаните „Sti“, „Sn“ и [„Sie“], това означава, че операторът на схемата (Scheme Operator) ТРЯБВА да създаде запис за услугата, различаващ се от предишния.

▼C1

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва идентификатора на предходното състояние на услугата във формата и със значението, използвани в „TSP Service Information — Service current status“ (клауза 5.5.4).

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва датата и часа на влизане в действие на съответното предходно състояние във формата и със значението, използвани в „TSP Service Information — Service current status starting date and time“ (клауза 5.5.5).

Това поле е НЕЗАДЪЛЖИТЕЛНО и МОЖЕ да се използва от оператори на схеми за предоставяне на специфична, свързана с услугата информация във формата и със значението, използвани в „TSP Service Information — Service information extensions“ (клауза 5.5.9).

TSP(1) Service(1) History(2) (ДДУ(1) услуга(1) история(2)

Вписване за ДДУ(1) услуга(1) история(2) (предхождаща история(1)

…

Вписване за ДДУ(1) услуга 2 (ако е уместно)

ДДУ(1) услуга(2) история(1)

…

Вписване за ДДУ 2 (ако е уместно)

Вписване за ДДУ 2 услуга 1

Вписване за ДДУ 2 услуга 1 история 1

…

▼C2

Signed TSL

▼M1

Предназначената за четене от човек форма на TSL реализацията на доверителния списък, създадена съгласно настоящите спецификации, и по-специално съгласно глава IV, СЛЕДВА да е подписана от оператора, посочен в „Scheme operator name“ (клауза 5.3.4), за да се гарантира нейната автентичност и цялост ( 25 ). Форматът на подписа СЛЕДВА да е PAdES part 3 (ETSI TS 102 778-3 ( 26 )), но МОЖЕ да е PAdES part 2 (ETSI TS 102 778-2 ( 27 )) в контекста на конкретния модел на доверие, установен чрез публикуването на удостоверенията, използвани за подписване на доверителния списък.

Машинно четимата форма на TSL реализацията на доверителния списък, създадена съгласно настоящите спецификации, ТРЯБВА да е подписана от оператора, посочен в „Scheme operator name“ (клауза 5.3.4), за да се гарантира нейната автентичност и цялост. Машинно четимата форма на TSL реализацията на доверителния списък, създадена съгласно настоящите спецификации, ТРЯБВА да е във формат XML и ТРЯБВА да съответства на спецификациите, посочени в приложения B и C от ETSI TS 102 231.

Подписът ТРЯБВА да е във формат XAdES BES или EPES, както е определено от спецификациите на ETSI TS 101903 за XML реализации. Такава реализация на електронния подпис ТРЯБВА да отговаря на изискванията, посочени в приложение B към ETSI TS 102 231 ( 28 ). Допълнителни основни изисквания по отношение на въпросния подпис са посочени в следващите раздели.

▼C1

Scheme identification (идентификация на схемата) (клауза 5.7.2)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да съдържа позоваване, включено от оператора на схемата, което идентифицира еднозначно описаната в настоящите спецификации схема и създадения ССДУ, и ТРЯБВА да бъде включено в изчисляването на подписа. Очаква се това да бъде низ от символи или низ от битове.

▼M1

В контекста на настоящите спецификации това позоваване ТРЯБВА да включва „TSL type“ (клауза 5.3.3), „Scheme name“ (клауза 5.3.6) и стойността на разширението SubjectKeyIdentifier на удостоверението, използвано от оператора на схемата, за да подпише TSL по електронен път.

▼C1

Signature algorithm identifier (идентификатор на сигнатурния алгоритъм) (клауза 5.7.3)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да указва идентификатора на криптографския алгоритъм, използван за създаването на подписа. В зависимост от използвания алгоритъм то МОЖЕ да се нуждае от допълнителни параметри. Това поле ТРЯБВА да бъде включено в изчисляването на подписа.

Signature value (сигнатурна стойност) (клауза 5.7.4)

Това поле е ЗАДЪЛЖИТЕЛНО и СЛЕДВА да съдържа действителната стойност на цифровия подпис. Всички полета на ССДУ (с изключение на самата сигнатурна стойност) ТРЯБВА да бъдат включени в изчисляването на подписа.

TSL extensions (разширения на ССДУ) (клауза 5.8)

Това разширение е НЕЗАДЪЛЖИТЕЛНО. Ако се използва, то ТРЯБВА да е съобразено със спецификациите на ETSI TS 102 231, клауза 5.8.1.

Ако се използва, това НЕЗАДЪЛЖИТЕЛНО разширение ТРЯБВА да се употребява само на ниво на услугата и само в полето, определено в клауза 5.5.9 („Service information extension“). Използва се за предоставяне на допълнителна информация за услугата. Това СЛЕДВА да бъде поредица от един или повече кортежи, като всеки кортеж включва:

▼M1

Този URI СЛЕДВА да насочва към четима от човек информация (поне на английски и евентуално на един или повече национални езици), считана за подходяща и достатъчна за разбиране от доверяваща се страна на разширението и по-конкретно обясняваща значението на дадените URI, специфициращи възможните стойности на serviceInformation, и значението на всяка от тях.

▼M1

Qualifications Extension (клауза L.3.1)

Описание :

Това поле е НЕЗАДЪЛЖИТЕЛНО, но ТРЯБВА да съществува, ако употребата му е ЗАДЪЛЖИТЕЛНА, напр. за услуги на RootCA/QC (базови УО/КУ) или CA/QC, както и ако:

Когато се използва, това разширение на нивото на услугата ТРЯБВА да се използва само в полето, описано в „Service information extension“ (клауза 5.5.9) и ТРЯБВА да съответства на спецификациите, посочени в приложение L.3.1 на ETSI TS 102 231.

▼M1

TakenOverBy Extension (клауза L 3.2)

Описание : Това разширение е НЕЗАДЪЛЖИТЕЛНО, но ТРЯБВА да съществува, когато услуга, правната отговорност за която е била носена преди от определен ДУУ (CSP), е поета от друг ДДУ (TSP), и е предназначено за формално обявяване на правната отговорност за услугата, както и за да се даде възможност на софтуера за проверка да покаже на потребителя някои подробности от правно естество. Информацията, предоставена в това разширение, ТРЯБВА да е в съответствие с използването на клауза 5.5.6 и ТРЯБВА да отговаря на спецификациите в приложение L.3.2 към ETSI TS 102 231.

▼M1

„ГЛАВА II

При създаването на своите доверителни списъци държавите-членки използват:

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

▼M1 —————

▼C1

ГЛАВА IV

СПЕЦИФИКАЦИИ ЗА ПРЕДНАЗНАЧЕНИЯ ЗА ЧЕТЕНЕ ОТ ЧОВЕКА ФОРМАТ НА ССДУ РЕАЛИЗАЦИЯТА НА ДОВЕРИТЕЛНИЯ СПИСЪК

ТРЯБВА да бъде осигурен публичен достъп с електронни средства до предназначения за четене от човека документ (ПЧД) на ССДУ реализацията на доверителния списък. Той БИ ТРЯБВАЛО да се предлага под формата на документ във формат PDF в съответствие с ISO 32000, който ТРЯБВА да е форматиран съгласно профила PDF/A (ISO 19005).

Съдържанието на ПЧД на ССДУ реализацията на доверителния списък на базата на PDF/A БИ ТРЯБВАЛО да отговаря на следните изисквания:

▼M1

▼C1

---

( 1 ) ОВ L 376, 27.12.2006 г., стр. 36.

( 2 ) ОВ L 13, 19.1.2000 г., стр. 12.

( 3 ) Както е определено в член 2, параграф 11 от Директива 1999/93/ЕО.

( 4 ) Както е определено в член 2, параграф 10 от Директива 1999/93/ЕО.

( 5 ) Както е определено в член 2, параграф 6 от Директива 1999/93/ЕО.

( 6 ) Както е определено в член 2, параграф 2 от Директива 1999/93/ЕО.

( 7 ) За УЕП, поддържан от КУ, в настоящия документ се използва съкращението УЕПКУ.

( 8 ) Трябва да се отбележи, че съществуват многобройни електронни услуги на базата на прости УЕП, чието трансгранично използване също ще бъде улеснено, при положение че поддържащите ги удостоверителни услуги (например издаване на неквалифицирани удостоверения) са част от контролираните услуги, включени от дадена държава-членка в доброволната част на нейния доверителен списък.

( 9 ) ETSI TS 102 231 — Електронни подписи и инфраструктура (ESI): Предоставяне на хармонизирана информация за състоянието на удостоверителните услуги.

( 10 ) Напр. един доставчик на удостоверителни услуги в дадена държава-членка, който предлага удостоверителна услуга, намираща се първоначално под надзора на държавата-членка (надзорния орган), може след известно време да реши да се подложи на доброволна акредитация за удостоверителната услуга, намираща се понастоящем под надзор. Обратно, един доставчик на удостоверителни услуги в друга държава-членка може да реши да не прекратява предлагането на дадена акредитирана удостоверителна услуга, но да я прехвърли от състояние на акредитация в поднадзорно състояние, напр. поради търговски и/или икономически причини.

( 11 ) ETSI TS 102 231 — Електронни подписи и инфраструктура (ESI): Предоставяне на хармонизирана информация за състоянието на удостоверителните услуги.

( 12 ) За справка виж ETSI TS 101 862 — Електронни подписи и инфраструктура (ESI): Профил на квалифицираното удостоверение.

( 13 ) ETSI TS 101 456 — Електронни подписи и инфраструктура (ESI): Изисквания към политиката за сертифициране на органи, издаващи квалифицирани удостоверения.

( 14 ) Тоест най-малко удостоверение X.509 v3 на издаващия КУО или на един от предшестващите УО във веригата на удостоверяване.

( 15 ) IETF RFC 2119: „Ключови думи, използвани в документация от тип RFC за обозначаване на различните нива на изискванията“.

( 16 ) Тоест „списъкът на състоянието на надзора и акредитациите на удостоверителните услуги, предлагани от доставчици на удостоверителни услуги, които са под надзор/акредитация на съответната държава-членка относно съвместимостта им с разпоредбите на Директива 1999/93/ЕО“ (съкратено „доверителният списък“).

( 17 ) Значение на полетата, определени от ETSI TS 102 231 — Електронни подписи и инфраструктура (ESI): Осигуряване на хармонизирана информация за доверителни услуги, „пригодена“ от настоящите спецификации за описване на процеса на създаване на доверителни списъци на държавите-членки.

( 18 ) Последните два пакета от информация са от ключово значение за оценяването от доверяващите се страни на качеството и нивото на сигурност на такива системи за надзор/акредитация. Тези пакети от информация се предлагат на ниво ДС, като се използват „URI за информация за схемата (Scheme information URI)“ (клауза 5.3.7 — информация, предоставяна от държавите-членки), „Тип/общност/правила на схемата (Scheme type/community/rules)“ (клауза 5.3.9, като се използват общи за всички държави-членки формулировки) и „Правен/политически коментар към ССДУ (TSL policy/legal notice)“ (клауза 5.3.11 — обща за всички държави-членки формулировка, позоваваща се на Директива 1999/93/ЕО, и възможност за всяка държава-членка да добави специфични национални формулировки или позовавания). Допълнителна информация за националните системи за надзор/акредитация на ДУУ, които не издават КУ, може да бъде предложена на нивото на услугата, ако е уместно и необходимо (например за да се различават отделните нивата на качество/сигурност), като се използва разширението „Scheme service definition URI“ (клауза 5.5.6).

( 19 ) IETF RFC 3986: „Uniform Resource Identifiers (URI, унифицирани идентификатори на ресурси): Generic syntax (Общ синтаксис)“.

( 20 ) Използването на удостоверение от тип X.509v3 на базов УО като стойност на полето „Sdi“ ще накара оператора на схемата да възприеме целия набор от удостоверителни услуги в рамките на такъв базов УО като едно цяло по отношение на „състоянието на надзор/акредитация“. Напр. всяка промяна на състоянието, която се изисква от един УО във вписаната базова йерархия, ще доведе до промяна на състоянието за цялата йерархия.

( 21 ) Това може да бъде удостоверение от УО, издаващ потребителски удостоверения (напр. CA/PKC(УО/ПКП), CA/QC(УО/КУ), или удостоверение от упълномощен базов УО, от който може да бъде проследена удостоверителна йерархия надолу до квалифицираните потребителски удостоверения. В зависимост от това дали тази информация и информацията, която може да бъде намерена във всяко потребителско удостоверение, издадено въз основа на това базово удостоверение, може да се използва за еднозначното определяне на подходящите характеристики на всяко квалифицирано удостоверение, тези данни („Service digital identity“) може би ще трябва да бъдат допълнени от данните в „Service information extensions“ (вж. клауза 5.5.9).

( 22 ) Трябва да се отбележи, че този акредитиран ДУУ може да е установен в държава-членка, различна от посочената в „Scheme territory“ на ССДУ реализацията на ДС, или в трета държава (вж. член 7, параграф 1, буква а) от Директива 1999/93/ЕО).

( 23 ) Вж. раздел 2.2 от настоящия документ.

( 24 ) Има се предвид една подходяща комбинация от дефинираната в ETSI декларация QcCompliance, декларации QcSSCD [ETSI TS 101 862] или обектен идентификатор (OID) QCP/QCP+ [ETSI TS 101 456].

( 25 ) В случай че предназначената за четене от човек форма на TSL реализацията на доверителния списък не е подписана, нейната автентичност и цялост ТРЯБВА да бъдат гарантирани чрез подходящ съобщителен канал с еквивалентно ниво на сигурност. Използването на TLS (IETF RFC 5246: „The Transport Layer Security (TLS) Protocol Version 1.2“) се препоръчва за тази цел и контролната сума — „отпечатък“ (fingerprint) на удостоверението на TLS канала ТРЯБВА да бъде предоставена по метода „out of band“ от държавата-членка на TSL потребителите.

( 26 ) ETSI TS 102 778-3 – Electronic Signatures and Infrastructures (ESI): PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles.

( 27 ) ETSI TS 102 778-2 – Electronic Signatures and Infrastructures (ESI): PDF Advanced Electronic Signature Profiles; Part 2: PAdES Basic - Profile based on ISO 32000-1.

( 28 ) Подписващото удостоверение на оператора на схемата задължително трябва да бъде защитено чрез подпис по един от начините, определени от ETSI TS 101903, и ds:keyInfo следва да съдържа съответната верига от удостоверения, когато е приложимо.