ИПС "Әділет"

Еуразиялық экономикалық одақ шеңберіндегі ақпараттық-коммуникациялық технологиялар және ақпараттық өзара іс-қимыл туралы хаттаманың (2014 жылғы 29 мамырдағы Еуразиялық экономикалық одақ туралы шартқа № 3 қосымша) 3, 4 және 30-тармақтарына сәйкес Еуразиялық экономикалық комиссия Алқасы шешті:

1. Қоса беріліп отырған Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ереже бекітілсін.

2. Еуразиялық экономикалық одаққа мүше мемлекеттер мүше мемлекеттердің мемлекеттік билік органдарының өзара және Еуразиялық экономикалық комиссиямен өзара іс-қимылы кезінде Еуразиялық экономикалық одақтың интеграцияланған ақпараттық жүйесін пайдалана отырып, мүше мемлекеттер пайдаланатын электрондық құжат айналымы жүйелерінің арасында электрондық құжаттармен алмасу мүмкіндігін өз заңнамасында бекітуді қамтамасыз етсін.

3. Осы Шешім ресми жарияланған күнінен бастап күнтізбелік 30 күн өткен соң күшіне енеді.

Еуразиялық экономикалық комиссия
Алқасының Төрағасы

В.Христенко

Еуразиялық экономикалық
комиссия Алқасының
2015 жылғы 28 қыркүйектегі
№ 125 шешімімен
БЕКІТІЛГЕН

Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ЕРЕЖЕ

I. Жалпы ережелер

1. Осы Ереже интеграцияланған жүйе шеңберінде заңды маңызы бар электрондық құжаттармен алмасуды қамтамасыз ету мақсатында сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде және оның функционалдық мүмкіндіктерін кеңейту негізінде құрылған Одақтың интеграцияланған ақпараттық жүйесінде Еуразиялық экономикалық одаққа мүше мемлекеттердің (бұдан әрі тиісінше – мүше мемлекеттер, Одақ) мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен (бұдан әрі – Комиссия) трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу тәртібін белгілейді, сондай-ақ электрондық құжаттармен алмасуға қатысушылардың құрамын, электрондық цифрлық қолтаңбамен электрондық құжатқа қол қою (электрондық қол қою) талаптарын және электрондық құжаттармен алмасуға қатысушылардың жауапкершілігін айқындайды.

2. Осы Ережеде пайдаланылатын ұғымдар мыналарды білдіреді:

"XML" – Ғаламтор Консорциумы (W3C) ұсыным берген белгілеудің кеңейтілген тілі;

"XML–құжат" XML талаптарына сәйкес келетін деректер жиынтығы;

"XML каноникализациялау" - XML-құжаттарды XML каноникикалық нысанына айналдыру процесі;

"сенім білдірілген үшінші тараптың түбіртегі" –электрондық құжаттың және электрондық цифрлық қолтаңбаның (электрондық қолтаңбаның) электрондық құжатта төлнұсқалығын тексеру нәтижесін растау үшін сенім білдірілген үшінші тарап қалыптастырған және сенім білдірілген үшінші тараптың электрондық цифрлық қолтаңбасы (электрондық қолтаңба) қойылған электрондық құжат;

"криптографиялық стандарт"–электрондық цифрлық қолтаңбаларды (электрондық қолтаңбалар) қалыптастыру мен тексеру қағидаларын белгілейтін техникалық ерекшеліктердің жиынтығы;

"жөнелтуші" – электрондық құжатты жөнелтетін немесе оның атынан жөнелтілетін электрондық құжаттармен алмасуға қатысушы;

"алушы" –электрондық құжат жөнелтілген электрондық құжаттармен алмасуға қатысушы;

"жөнелтушінің сегменті", "алушының сегменті" –жөнелтушінің (алушының) ақпараттық жүйелерін электрондық құжаттарды жөнелту (қабылдау) үшін пайдаланатын мүше мемлекеттің ұлттық сегменті немесе Комиссияның интеграцияланған сегменті;

"ЭЦҚ-ны тексеру кілтінің сертификаты", "сертификат" –куәландырушы орталық шығарған, куәландырушы орталықтың жабық (жеке) кілтімен қол қойылған және сертификатта көрсетілген ашық кілттің электрондық құжаттармен алмасуға белгілі бір қатысушыға тиесілігін растайтын ақпарат пен тиісті криптографиялық стандарттарда көзделген өзге де ақпаратты қамтитын электрондық құжат;

"интеграцияланған жүйенің сенім білдірілген үшінші тарапының қызметі" - мүше мемлекеттердің сенім білдірілген үшінші тараптары мен Комиссияның интеграцияланған жүйеде электрондық құжаттармен алмасу кезінде бірыңғай трансшекаралық сенім кеңістігін қамтамасыз ететін сервистерінің жиынтығы;

"хабарлама" – интеграцияланған жүйеде жөнелтушіден алушыға берілетін ресмилендірілген ақпарат;

"Х.509 стандарты" – "Ақпараттық технологиялар. Ашық жүйелердің өзара байланысы. Анықтама: Ашық кілттер мен атрибуттар сертификаттарының құрылымдары" ITU-T Х.509 стандарты;

"XadES стандарты" –XML форматында электрондық цифрлық қолтаңбаның (электрондық қолтаңбаның) кеңейтілген форматын сипаттайтын XML Advanced Electronic Signature стандарты;

"XMLDSig стандарты"–XML форматында синтаксис және электрондық цифрлық қолтаңбаны (электрондық қолтаңбаны) өңдеу стандарты;

"куәландырушы орталық" – Комиссияның актілеріне, мүше мемлекеттің заңнамасына сәйкес ЭЦҚ-ны тексеру кілттерінің сертификаттарын шығару, тарату, сақтау және осы сертификаттардың жарамдылығын тексеру жөніндегі қызметтер көрсетуді қамтамасыз ететін уәкілетті орган немесе ұйым;

"электрондық цифрлық қолтаңба (электрондық қолтаңба)", "ЭЦҚ" –электрондық түрдегі басқа ақпаратпен қосылған немесе өзгеше түрде мұндай ақпаратпен байланысты электрондық түрдегі ақпарат, осы ақпараттың тұтастығы мен төлнұсқалығын бақылау үшін пайдаланылады, авторлықтан бас тартудың мүмкін еместігін қамтамасыз етеді, жабық (жеке) кілтті пайдалана отырып, осы ақпаратқа қатысты криптографиялық түрлендіруді қолдану арқылы әзірленеді және ашық кілтті пайдалана отырып, тексеріледі;

"электрондық құжаттың заңды маңыздылығы" – осы электрондық құжаттың мазмұнын төлнұсқа ретінде қабылдауға мүмкіндік беретін электрондық құжаттың ерекшелігі.

Осы Ережеде пайдаланылатын өзге ұғымдар Еуразиялық экономикалық одақ шеңберіндегі ақпараттық-коммуникациялық технологиялар және ақпараттық өзара іс-қимыл туралы хаттамада (2014 жылғы 29 мамырдағы Еуразиялық экономикалық одақ туралы шартқа № 3 қосымша) (бұдан әрі – Хаттама) айқындалған мағыналарда қолданылады.

3. Электрондық құжаттармен алмасуға байланысты туындайтын қатынастар 2014 жылғы 24 мамырдағы Еуразиялық экономикалық одақ туралы шартпен, Одақ құқығына кіретін өзге де халықаралық шарттармен, осы Ережемен, Комиссия бекітетін Одақ шеңберіндегі ортақ процестердің интеграцияланған жүйесінің құралдарын іске асыру кезінде ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттармен (бұдан әрі – ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттар), сондай-ақ мүше мемлекеттердің заңнамасымен реттеледі.

4. Ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттар Еуразиялық экономикалық комиссияның 2014 жылғы 6 қарашадағы № 200 шешіміне сәйкес әзірленеді.

5. Электрондық құжаттарды ресімдеуге қойылатын талаптар №1-4 қосымшаларға сәйкес айқындалды.

Осы Ережеге №1-4 қосымшаларда айқындалған талаптарды есепке алғанда, осы Ережеге сәйкес ресімделген электрондық құжаттар қағаз жеткізгіште ресімделген және қолтаңбамен немесе қолтаңбамен және мөрмен куәландырылған тең құжаттар болып танылады.

II. Электрондық құжаттармен алмасуға қатысушылар

3. Интеграцияланған жүйе шеңберінде электрондық құжаттармен алмасуға қатысушылар:

а) Комиссия;

б) уәкілетті органдар немесе олар айқындаған (аккредиттеген) ұйымдар;

в) мүше мемлекеттер мен Комиссияның сенім білдірілген үшінші тараптары;

г) мүше мемлекеттер мен Комиссияның куәландырушы орталықтары, интеграцияланған жүйенің сенім білдірілген үшінші тараптарының куәландырушы орталықтары;

д) ұйымдар – мүше мемлекеттердің ұлттық сегменттерінің және Комиссияның интеграциялық сегментінің интеграциялық шлюздерінің операторлары;

е) Комиссияның, сенім білдірілген үшінші тараптардың, уәкілетті органдардың немесе олар айқындаған (аккредиттеген) ұйымдардың, сондай-ақ мүше мемлекеттер мен Комиссияның электрондық құжаттармен алмасуға өз атынан қатысатын куәландырушы орталықтары.

7. Электрондық құжаттармен алмасуға қатысушылардың құрамын айқындауды мыналар жүзеге асырады:

а) мүше мемлекеттер – уәкілетті органдарға, сенім білдірілген үшінші тараптарға, куәландырушы орталықтарға, ұйымға – осы мүше мемлекеттің ұлттық сегментінің интеграциялық шлюзінің операторына қатысты;

б) уәкілетті органдар немесе олар айқындаған (аккредиттеген) ұйымдар – осы уәкілетті органдардың немесе ұйымдардың лауазымды адамдары мен қызметкерлеріне қатысты;

в) Комиссия – Комиссияның сенім білдірілген үшінші тарапына, Комиссияның куәландырушы орталығына, интеграцияланған жүйенің сенім білдірілген үшінші тарапының куәландырушы орталығына, осы органдардың лауазымды адамдарына қатысты, сондай-ақ Комиссияның лауазымды адамдары мен қызметкерлеріне қатысты.

8. Электрондық құжаттармен алмасуға қатысушылар мынадай функцияларды жүзеге асырады:

а) жөнелтуші – электрондық құжатты дайындау, оған ЭЦҚ қол қою және алушыға жөнелту;

б) алушы – жөнелтушіден алынған электрондық құжатты және жөнелтушінің электрондық құжатының төлнұсқалығын тексеру үшін алушының сенім білдірілген үшінші тарапының түбіртегін қабылдау және өңдеу;

в) ұйымдар – интергацияланған жүйенің интеграциялық шлюздерінің операторлары – электрондық құжаттарды трансшекаралық беруді қамтамасыз ету, сондай-ақ алушы көрінеу өңдеуге тиіс емес және өңдеуі мүмкін емес төлнұсқа емес электрондық құжаттарды беруге жол бермеу мақсатында сенім білдірілген үшінші тараптың түбіртектерін тексеру;

г) жөнелтушінің сенім білдірілген үшінші тарапы – электрондық құжаттың және электрондық құжат ЭЦҚ төлнұсқалығын тексеру, тексеру нәтижесімен жөнелтушінің сенім білдірілген үшінші тарапының түбіртегін қалыптастыру және оған қол қою;

д) алушының сенім білдірілген үшінші тарапы – жөнелтушінің сенім білдірілген үшінші тарапы түбіртегінің және осы түбіртектегі ЭЦҚ төлнұсқалығын тексеру және тексеру нәтижесімен алушының сенім білдірілген үшінші тарапының түбіртегіне қол қою; е) мүше мемлекеттің куәландырушы орталығы және Комиссияның куәландырушы орталығы – сертификаттар беру, өз құзыреті шегінде берілген сертификаттардың өзектілігін тексеруге арналған сервистер, жөнелтушінің сенім білдірілген үшінші тарапы арқылы ЭЦҚ-ны тексеру кезінде пайдаланылған сертификаттар иелерінің өкілеттіктерін (құқықтық мәртебелерін) тексеруге арналған сервистер, сондай-ақ уақытты көрсететін мөртабанның сервисін ұсыну;

ж) сенім білдірілген үшінші тараптың куәландырушы орталығы – мүше мемлекеттердің сенім білдірілген үшінші тараптарына сертификаттар беру, берілген сертификаттардың өзектілігін тексеруге арналған сервистер және уақытты көрсететін мөртабанның сервисін ұсыну.

9. Электрондық құжаттармен алмасуға қатысушылар:

а) электрондық құжаттармен алмасу процесінде осы Ережені сақтауға;

б) бағдарламалық-аппараттық құралдар жұмысындағы техникалық ақаулардың электрондық құжаттармен алмасуға кедергі келтіретін барлық жағдайлары туралы бір-біріне хабарлауға;

в) дау-дамай жағдайлары туындаған кезде оларды шешуге қатысуға;

г) Комиссия актілері мен мүше мемлекеттер заңнамаларының талаптарына сәйкес ақпарат қорғауды қамтамасыз етуге;

д) тиісті мүше мемлекеттің заңнамасына сәйкес берілген ЭЦҚ құралдарын, қолда бар сәйкестік сертификаттарын пайдалануға міндетті.

10. Қажет болған кезде электрондық құжаттармен алмасуға қатысушыларға қойылатын талаптар Комиссия Хаттаманың 18-тармағында көзделген трансшекаралық сенім кеңістігін құруға, дамытуға және олардың жұмыс істеуіне қойылатын талаптарды бекіткеннен кейін өзектендірілуі мүмкін, ал осы Ережені өзектендіру қажетті халықаралық стандарттар мен ұсынымдардың оқшауландырылған нұсқаларын қабылдағаннан кейін, сондай-ақ Комиссия мүше мемлекеттердің уәкілетті органдары, шаруашылық жүргізуші субъектілері және жеке тұлғалары арасындағы өзара іс-қимыл кезінде ақпаратты құжаттау қағидаларын бекіткеннен кейін жүргізіледі.

III. Электрондық құжаттармен алмасу

1. Электронды құжаттармен алмасу кезінде криптографиялық стандарттарға қойылатын талаптар

11. Электрондық құжаттармен алмасу кезінде қатысушылар мынадай криптографиялық стандарттарды пайдаланады:

а) мүше мемлекеттің бір ұлттық сегментінің шеңберінде жөнелтушілер (алушылар) мен сенім білдірілген үшінші тарап арасындағы өзара іс-қимыл кезінде - осы мүше мемлекеттің криптографиялық стандарттары;

б) Комиссияның интеграциялық сегментінің шеңберінде жөнелтушілер (алушылар) мен сенім білдірілген үшінші тарап арасындағы өзара іс-қимыл кезінде - Комиссия осы мақсаттар үшін бекіткен криптографиялық стандарт.

12. Интеграцияланған жүйенің сенім білдірілген үшінші тарапының өзара қызмет сервистерінің өзара іс-қимылы кезінде Комиссия осы мақсаттар үшін бекіткен ЭЦҚ-ның келісілген криптографиялық стандарты және хэштеу функциясының келісілген криптографиялық стандарты (интеграцияланған жүйенің сенім білдірілген үшінші тарапының қызмет стандарттары) пайдаланылады.

2. Электрондық құжаттармен алмасу тәртібі

13. Одақ шеңберіндегі ортақ процестерді (бұдан әрі – ортақ процестер) іске асыру кезінде электрондық құжаттармен алмасу ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттарға сәйкес, сондай-ақ Еуразиялық экономикалық комиссияның 2015 жылғы 27 қаңтардағы №5 шешімімен бекітілген Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректермен электрондық алмасу қағидаларына (бұдан әрі – Деректермен электрондық алмасу қағидалары) сәйкес орындалады.

14. Ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттарда көзделген электрондық құжаттарды ресімдеу осы Ережеге № 1 қосымшада айқындалған талаптарға сәйкес ортақ процестің интеграцияланған жүйесінің құралдарымен іске асыру кезінде ортақ процеске қатысушылар арасындағы ақпараттық өзара іс-қимыл регламентінде ортақ процестің әрбір транзакциясы үшін көрсетілген "ЭЦҚ белгісі" өлшемі мәнінің негізінде орындалады ("иә" немесе "жоқ"деген мән қабылдайды).

Егер өлшем "иә" деген мәнді қабылдаса, онда ортақ процестердің транзакциялары шеңберінде берілетін деректер электрондық құжаттар түрінде ресімделеді. Ерекшеліктер белгілері мен растау белгілері және қызметтік хабарламалар арқылы берілетін деректер, егер ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттарда немесе Одақ құқығына кіретін актілерде өзгеше айқындалмаса, электрондық құжаттар түрінде ресімделмейді.

Егер өлшем "жоқ" деген мәнді қабылдаған жағдайда ортақ процесс транзакциясының шеңберіндегі деректермен электрондық алмасуға қойылатын осы Ереженің талаптары қолданылмайды.

15. Электрондық құжаттармен алмасу процесінде мүше мемлекеттің ұлттық сегментінің (Комиссияның интеграциялық сегментінің) шегінде сенім білдірілген үшінші тараптардың интеграциялық шлюздері мен сервистері № 5 қосымшаға сәйкес сипаттамаға сәйкес құрастырылатын және № 6 қосымшаға сәйкес сипаттамаға сәйкес деректермен электрондық алмасу хаттамасы арқылы берілетін хабарламалармен алмасады.

16. Жөнелтуші мынадай іс-қимылдарды орындайды:

а) электрондық құжатты қалыптастырады және оған қол қояды;

б) электрондық құжатты хабарлама түрінде ресімдейді;

в) жөнелтушінің интеграциялық шлюзіне алушыға арналған хабарлама жолдайды;

17. Жөнелтушінің интеграциялық шлюзі арқылы жөнелтушіден хабарлама қабылданады және жөнелтушінің сенім білдірілген үшінші тарапына арналған жаңа хабарлама қалыптастырылады, оған алынған электрондық құжат салынады. Жөнелтушінің интеграциялық шлюзінде қалыптастырылған хабарлама жөнелтушінің сенім білдірілген үшінші тарапына беріледі.

18. Жөнелтушінің сенім білдірілген үшінші тарапы интеграциялық шлюзден келіп түскен хабарламаны қабылдайды және электрондық құжаттағы әрбір ЭЦҚ үшін мынадай жиынтық талаптардың сақталуын тексереді:

а) ЭЦҚ қол қойылған деректер тұтастығының бұзылмауы;

б) ЭЦҚ ашық кілттің тиісті сертификатының (ЭЦҚ-ны тексеру кілтінің сертификаты) осы ЭЦҚ құрамында көрсетілген жабық (жеке) кілтті пайдалана отырып, әзірленуі;

в) ЭЦҚ-ны тексеру кілтінің сертификаты электрондық құжатқа қол қою кезінде жарамды;

г) сертификаттар тізбесінен алынған) куәландырушы орталықтың әрбір сертификатының қол қою кезінде жарамдылығы.

19. Жөнелтушінің сенім білдірілген үшінші тарапы электрондық құжатты тексеру нәтижелері бойынша жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі осы Ережеге № 3 қосымшада айқындалған талаптарға және №7 қосымшаның үлгісіне сәйкес қалыптастырылады. Жөнелтушінің сенім білдірілген үшінші тарапының түбіртегіне интеграцияландырылған жүйенің сенім білдірілген үшінші тарапы қызметінің криптографиялық стандартына сәйкес жөнелтушінің сенім білдірілген үшінші тарапының ЭЦҚ қолы қойылады. Сенім білдірілген үшінші тарап қызметінің криптографиялық стандартын сәйкестендіру үшін түбіртек құрылымында №8 қосымшаға сәйкес тізбе бойынша алгоритмдер сәйкестендіргіштері пайдаланылады.

20. Жөнелтушінің сенім білдірілген үшінші тарапы түбіртектің өзіне уақыт көрсетілген тиісті мөртабаны бар өз ЭЦҚ-мен түбіртекке қол қою уақыты электрондық құжатты жөнелту уақыты болып табылады.

21. Жөнелтушінің сенім білдірілген үшінші тарапы жөнелтушінің интеграциялық шлюзіне арналған хабарлама дайындайды, оған жөнелтушінің сенім білдірілген үшінші тарапының электрондық құжаты мен түбіртегі салынып, жөнелтушінің интеграциялық шлюзіне беріледі.

22. Жөнелтушінің интеграциялық шлюзі жөнелтушінің сенім білдірілген үшінші тарапынан хабарламаны қабылдайды.

23. Егер жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі электрондық құжаттың немесе электрондық құжаттағы ЭЦҚ төлнұсқалығын тексерудің теріс нәтижесін куәландыратын болса, онда жөнелтушінің интеграциялық шлюзі ЭЦҚ-ны тексеру дің теріс нәтижесі себебіне байланысты қате туралы хабарламаны қалыптастырады және жөнелтушіге жолдайды.

Егер қате туралы хабарламаны Комиссияның интеграциялық сегментінің интеграциялық шлюзі қалыптастыратын болса, ол Деректермен электрондық алмасу қағидаларына сәйкес "int:Receipt Еггог" кодымен қате туралы технологиялық хабарлама болуға тиіс.

Егер қате туралы хабарламаны мүше мемлекеттің ұлттық сегментінің интеграциялық шлюзі қалыптастыратын болса, қате туралы хабарлама құрылымына қойылатын талаптарды мүше мемлекет айқындайды.

24. Егер жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі электрондық құжаттың немесе электрондық құжаттағы ЭЦҚ төлнұсқалығын тексерудің оң нәтижесін куәландыратын болса, онда жөнелтушінің интеграциялық шлюзі мынадай іс-қимылдарды орындайды:

а) электрондық құжат пен жөнелтушінің сенім білдірілген үшінші тарапының түбіртегін тақырыптар блогы осы Ереженің 17-тармағына сәйкес жөнелтушінің интеграциялық шлюзі алған хабарлама тақырыптарының блогына сәйкес келетін хабарламаға салу;

б) алушының интеграциялық шлюзіне хабарламаны беру.

25. Алушының интеграциялық шлюзі жөнелтушінің интеграциялық шлюзінен хабарламаны алады және алушының сенім білдірілген үшінші тарапы үшін электрондық құжат пен жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі салынатын жаңа хабарлама қалыптастырылады. Қалыптастырылған хабарламаны интеграциялық шлюз алушының сенім білдірілген үшінші тарапына береді.

26. Алушының сенім білдірілген үшінші тарапы алушының интеграциялық шлюзінен келіп түскен хабарламаны қабылдайды және жалпы мынадай талаптардың сақталуын тексереді:

а) хабарламаға жөнелтушінің сенім білдірілген үшінші тарапының түбіртегінің салынуы;

б) жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі қалыптастырылған электрондық құжат тұтастығының бұзылмауы;

в) түбіртекке жөнелтушінің сенім білдірілген үшінші тарапының жабық (жеке) кілтін пайдалана отырып, әзірленген жөнелтушінің сенім білдірілген үшінші тарапының ЭЦҚ қолы қойылуы, ашық кілт сертификаты (ЭЦҚ-ны тексеру кілтінің сертификаты) осы ЭЦҚ құрамында көрсетілуі;

г) жөнелтушінің сенім білдірілген үшінші тарапының ЭЦҚ-ны тексеру кілтінің сертификатын интеграцияландырылған жүйенің куәландырушы орталығы дайындауы және жөнелтушінің сенім білдірілген үшінші тарапының түбіртегіне қол қою кезінде жарамдылығы;

д) интеграцияландырылған жүйенің куәландырушы орталығының ЭЦҚ-ны тексеру кілтінің сертификаты жөнелтушінің сенім білдірілген үшінші тарапының түбіртегіне қол қою кезінде жарамдылығы;

е) жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі электрондық құжаттың және электрондық құжаттағы ЭЦҚ төлнұсқалығын тексерудің оң нәтижесін куәландыруы.

27. Жөнелтушінің сенім білдірілген үшінші тарапының электрондық құжаты мен түбіртегін тексеру нәтижелері бойынша алушының сенім білдірілген үшінші тарапының түбіртегі қалыптастырылады, оған алушы юрисдикциясының криптографиялық стандартына сәйкес ЭЦҚ қол қойылады. Жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі алушының сенім білдірілген үшінші тарапы түбіртегінің құрамына енгізіледі. Алушының сенім білдірілген үшінші тарапының жөнелтушінің сенім білдірілген үшінші тарапының түбіртегін өңдеуі және алушы үшін түбіртек қалыптастыруы осы Ережеге №3 қосымшада айқындалған талаптарға сәйкес жүзеге асырылады. Электрондық құжатты алушы юрисдикциясының криптографиялық стандартын сәйкестендіру үшін түбіртек құрылымында осы Ережеге № 8 қосымшада көзделген алгоритмдердің сәйкестендіргіштері пайдаланылады.

28. Алушының сенім білдірілген үшінші тарапы түбіртектің өзіне уақыт көрсетілген тиісті мөртабаны бар өз ЭЦҚ-мен түбіртекке қол қою уақыты электрондық құжатты алу уақыты болып табылады.

29. Алушының сенім білдірілген үшінші тарапы алушының интеграциялық шлюзіне арналған хабарлама дайындайды, оған алушының сенім білдірілген үшінші тарапының электрондық құжаты мен түбіртегі салынып, жөнелтушінің интеграциялық шлюзіне беріледі.

30. Алушының интеграциялық шлюзі алушының сенім білдірілген үшінші тарапынан хабарламаны қабылдайды.

31. Егер алушының сенім білдірілген үшінші тарапының түбіртегі электрондық құжаттың немесе электрондық құжаттағы ЭЦҚ төлнұсқалығын тексерудің теріс нәтижесін куәландыратын болса, онда алушының интеграциялық шлюзі Деректермен электрондық алмасу қағидаларына сәйкес "ит1::Кесе1ргЕггог" кодымен қате туралы технологиялық хабарламаны қалыптастырады.

32. Егер алушының сенім білдірілген үшінші тарапының түбіртегі электрондық құжаттың немесе электрондық құжаттағы ЭЦҚ төлнұсқалығын тексерудің оң нәтижесін куәландыратын болса, онда алушының интеграциялық шлюзі мынадай іс-қимылдарды орындайды:

а) электрондық құжат пен алушының сенім білдірілген үшінші тарапының түбіртегін тақырыптар блогы осы Ереженің 25-тармағына сәйкес жөнелтушінің интеграциялық шлюзі алған хабарлама тақырыптарының блогына сәйкес келетін хабарламаға салу;

б) алушыға хабарламаны беру.

33. Алушы алушының интеграциялық шлюзінен келіп түскен хабарламаны қабылдайды және мынадай жиынтық талаптардың сақталуын тексереді:

а) хабарламаға алушының сенім білдірілген үшінші тарапы түбіртегінің салынуы;

б) алушының сенім білдірілген үшінші тарапының түбіртегі қалыптастырылған электрондық құжат тұтастығының бұзылмауы;

в) түбіртекке алушының сенім білдірілген үшінші тарапының жабық (жеке) кілтін пайдалана отырып, әзірленген алушының сенім білдірілген үшінші тарапының ЭЦҚ қолы қойылуы, ашық кілт сертификаты (ЭЦҚ-ны тексеру кілтінің сертификаты) осы ЭЦҚ құрамында көрсетілуі;

г) алушының сенім білдірілген үшінші тарапының ЭЦҚ-ны тексеру кілтінің сертификатын интеграцияландырылған жүйенің куәландырушы орталығы дайындауы және алушының сенім білдірілген үшінші тарапының түбіртегіне қол қою кезінде жарамдылығы;

д) интеграцияландырылған жүйенің куәландырушы орталығының ЭЦҚ-ны тексеру кілтінің сертификаты алушының сенім білдірілген үшінші тарапының түбіртегіне қол қою кезінде жарамдылығы;

34. Егер осы Ереженің 33-тармағында көзделген барлық талаптардың сақталуы расталған болса, алушы электрондық құжатты өңдеу туралы шешімді қабылдайды. Өзге жағдайда электрондық құжатты өңдеуге қабылдамау туралы шешім қабылданады.

35. Егер алушы электрондық құжатты өңдеуге қабылдаудан бас тарту туралы шешім қабылдайтын болса, ол жөнелтушіге Деректермен электрондық алмасу қағидаларына сәйкес қалыптастырылған "Signature:Error" кодымен "Қате" алып тастау белгісімен жөнелтушіге жолдау арқылы бұл туралы хабарлайды.

3. Электрондық құжаттармен алмасу кезінде туындайтын штаттық емес жағдайларды шешу

36. Деректерді өңдеу техникалық іркілістер, электрондық құжаттардың немесе хабарламалар құрылымының белгіленген қағидаларға сәйкес келмеу себептеріне байланысты не басқа негіздер бойынша белгіленген тәртіпте жүргізілмеген болса, электрондық құжаттармен алмасу кезінде туындайтын жағдай штаттық емес болып танылады.

37. Штаттық емес жағдайларды шешумен сенім білдірілген үшінші тараптардың және ұйымдардың – интеграциялық шлюздер операторларының техникалық бөлімшелері айналысады.

38. Интеграцияландырылған жүйенің әрбір сегментінде штаттық емес жағдайларды шешуді қамтамасыз ететін өз техникалық бөлімшелері құрылады.

39. Сенім білдірілген үшінші тарап, егер кіріс хабарламаны өңдеу кезінде кіріс хабарламаны штаттық режимде өңдеуге мүмкіндік бермейтін мынадай күрделі кез келген қателер туындаған жағдайда қате туралы технологиялық хабарламаны ресімдейді және өз сегментінің интеграциялық шлюзіне жолдайды:

а) осы Ережеге №5 қосымшада айқындалған талаптарға хабарлама нысаны мен құрылымының сәйкессіздігі;

б) осы Ережеге № 1 қосымшада айқындалған талаптарға және осы Ережеге №2 қосымшада көзделген деректер схемасына электрондық құжат нысаны мен құрылымының сәйкессіздігі;

в) осы Ережеге № 3 қосымшада айқындалған талаптарға хабарламаға салынған жөнелтушінің сенім білдірілген үшінші тарапы түбіртегінің нысаны мен құрылымының сәйкессіздігі;

г) хабарламаны өңдеу процесінде туындайтын немесе деректер құрылымдарының хабарламалар құрамына енетін қателер.

40. Қателер туралы технологиялық хабарламаларды қалыптастыру осы Ережеге № 5 қосымшаға сәйкес жүзеге асырылады.

41. Сенім білдірілген үшінші тараптан қате туралы хабарлама алынған кезде интеграциялық шлюз электрондық құжатты алушыға одан әрі берудің мүмкін еместігі туралы хабарлама қалыптастырады және жөнелтушінің атына жолдайды.

42. Осы Ереженің 41-тармағында көрсетілген қате туралы хабарламаның форматы мен құрылымына мынадай талаптар қойылады:

а) егер қате туралы хабарламаны интеграциялық шлюз қалыптастыратын болса, ол Деректермен электрондық алмасу қағидаларына сәйкес "int:InternalError" кодымен қате туралы технологиялық хабарламаны білдіруге тиіс;

б) егер қате туралы хабарламаны жөнелтушінің интеграциялық шлюзі қалыптастыратын жағдайда қате туралы хабарламаның форматы мен құрылымын мүше мемлекет айқындайды.

43. Интеграцияланған жүйенің жұмыс істеуі шеңберінде сенім білдірілген үшінші тараптардың және ұйымдардың – интеграциялық шлюздер операторларының техникалық бөлімшелері арасында өзара іс-қимыл ұйымдастырылады.

44. Штаттық емес жағдайларды шешу мақсатында хабарламалар мен электрондық құжаттарды қабылдау, жөнелту және жолдау туралы, сондай-ақ сенім білдірілген үшінші тараптың түбіртегін ресімдеу туралы ақпаратты қамтитын, №9 қосымшаға сай қисынды операциялар мен оқиғалардың тізбесіне сәйкес аудит журналы жүргізіледі.

IV. Дау-дамайлы жағдайларды шешу

45. Электрондық құжаттармен алмасу кезінде туындайтын және электрондық құжаттармен алмасуға қандай да бір қатысушылар ЭЦҚ төлнұсқалығын даулайтын жағдай дау-дамайлы жағдай болып танылады.

46. Дау-дамайлы жағдайлар Комиссия бекіткен дау-дамайлы жағдайларды шешу тәртібіне сәйкес шешуге жатады.

Еуразиялық экономикалық
одаққа мүше мемлекеттердің
мемлекеттік билік
органдарының бір-бірімен
және Еуразиялық
экономикалық комиссиямен
трансшекаралық өзара іс-
қимылы кезінде электрондық
құжаттармен алмасу туралы
ережеге
№ 1 ҚОСЫМША

Электрондық құжаттарды қалыптастыру мен өңдеуге қойылатын ТАЛАПТАР

1. Сыртқы және өзара сауданың интеграцияландырылған ақпараттық жүйесінде және оның функционалдық мүмкіндіктерін кеңейту негізінде құрылған Одақтың интеграцияланған ақпараттық жүйесінде Еуразиялық экономикалық одаққа мүше мемлекеттердің (бұдан әрі тиісінше – мүше мемлекеттер, Одақ) мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде пайдаланылатын электрондық құжаттардың(бұдан әрі тиісінше – электрондық құжаттар, интеграцияланған жүйе) біріздендірілген құрылымы болады.

2. Электрондық құжаттың біріздендірілген құрылымы мынадай негізгі элементтерді (блоктарды) қамтиды:

а) электрондық құжаттың контейнері;

б) бір немесе бірнеше электрондық цифрлық қолтаңбалар (электрондық қолтаңба) (бұдан әрі – ЭЦҚ);

в) электрондық құжат түрлерінің құрылымдары (мәліметтері);

г) интеграцияландырылған жүйе арқылы электрондық құжат берген кезде электрондық құжаттың контейнеріне салынатын сенім білдірілген үшінші тараптың түбіртегі.

3. Электрондық құжаттар түрлерінің құрылымдары (мәліметтер) Одақ шеңберіндегі әрбір ортақ процесс үшін Еуразиялық экономикалық комиссия бекітетін, Еуразиялық экономикалық комиссия Алқасының 2014 жылғы 6 қарашадағы № 200 шешіміне сәйкес әзірленген, Одақ шеңберіндегі ортақ процестің интеграцияланған жүйесінің құралдарымен іске асыру кезінде ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттарда (бұдан әрі – ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттар) айқындалады.

4. Электрондық құжаттың біріздендірілген құрылымын сипаттау кезінде тізбесі 1-кестеде берілген атаулардың кеңістігі пайдаланылады

1-кесте

Құжат атаулары кеңістіктерінің тізбесі

Сөз алды қосымшасы	Мекенжай
doc	urn:EEC:SignedData:v1.0:EDoc
ds	http://www.w3.org/2000/09/xmldsig#
xs	http://www.w3.org/2001/XMLSchema

5. Электрондық құжаттың біріздендірілген құрылымы 2-кестеде беріледі.

2-кесте

Электрондық құжаттың біріздендірілген құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
doc:SignedDoc	doc:SignedDoc Type	электрондық құжат контейнері	1
doc:Dаta	қамтылған электрондық құжаттың блогы	doc:DataType	1
ds:Signature	сенім білдірілген үшінші тараптың түбіртегі	ds:SignatureType	0..1

6. Қамтылған doc:Dаta электрондық құжатының блогы жөнелтуші деңгейінде қалыптастырылатын бір немесе бірнеше ЭЦҚ, сондай-ақ осы ЭЦҚ қол қойылған деректерді қамтуға тиіс. Қамтылған doc:Dаta электрондық құжатының блогы 3-кестеде берілген құрылымға сәйкес келуге тиіс.

3-кесте

Қамтылған электрондық құжат блогының құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
doc:Data	doc:DataType	қамтылған электрондық құжаттың блогы	1
@Id	xs:ID	қамтылған электрондық құжат блогыныңатрибут-сәйкестендіргіші	1
ds:Signature	ds:SignatureType	электрондық құжаттың ЭЦҚ	1..*
doc:SignedContent	–	қол қойылатын деректердің блогы	1
@Id	xs:ID	қол қойылатын деректер блогыныңатрибут-сәйкестендіргіші	1
@DocInstance	xs:anyURI	электрондық құжаттың бірегей сәйкестендіргіші	1
Электрондық құжаттар (мәліметтер) түрлерінің құрылымдары	электрондық құжаттар (мәліметтер) түрлері құрылымдарының типімен айқындалады	электрондық құжаттар (мәліметтер) түрлерінің бір немесе бірнеше құрылымы	1..*

7. doc:Data/@Id атрибуты қамтылған электрондық құжат блогының сәйкестендіргішін қамтуға тиіс. Атрибут мәнін жөнелтуші xml:id Version 1.0 W3C Recommendation 9 September 2005, http://www.w3.org/TR/xml-id/ стандартының (бұдан әрі - xml-id стандарты) талаптарына сәйкес айқындайды.

8. doc:SignedDoc/doc:Data/ds:Signature элементі электрондық құжаттың ЭЦҚ қамтуға тиіс, оны қалыптастыру алгоритміне мынадай талаптар қойылады:

а) ЭЦҚ форматы, оның атрибуттары мен элементтері XMLDsig стандартының не XAdES стандартының талаптарына сәйкес келуге тиіс;

б) ds:Signature/@Id атрибуты ЭЦҚ сәйкестендіргішін қамтуға тиіс. Атрибут мәнін жөнелтуші xml-id стандартының талаптарына сәйкес айқындайды;

в) егер ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттарда өзгеше көрсетілмеген болса, doc:SignedContent блогына ЭЦҚ қол қойылуға тиіс. doc:SignedContent блогына сілтеме жасау үшін ЭЦҚ құрылымынан doc:SignedContent/@Id атрибутының мәнін пайдалану қажет;

г) ds:Signature элементінің құрамында XMLDsig стандартының талаптарына сәйкес ЭЦҚ және ЭЦҚ-ны тексеру кілтінің сертификаты қамтылуға тиіс.

9. doc:SignedContent/@Id атрибуты қол қойылатын деректер блогының сәйкестендіргішін қамтуға тиіс. Атрибут мәнін жөнелтуші xml-id стандартының талаптарына сәйкес айқындайды.

10. doc:SignedContent/@DocInstance атрибуты RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace (Network Working Group. RFC 4122. "A Universally Unique IDentifier (UUID) URN Namespace". http://www.ietf.org/rfc/rfc4122.txt) стандартының қағидаларына сәйкес қалыптастырылған электрондық құжаттың бірегей технологиялық сәйкестендіргішін қамтуға тиіс.

11. doc:SignedContent блогы ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттарда айқындалатын электрондық құжаттар (мәліметтер) түрлерінің құрылымдарын қамтуға тиіс.

12. doc:SignedDoc/ds:Signature элементі сенім білдірілген үшінші тараптың түбіртегін білдіреді. Элементті сенім білдірілген үшінші тарап қалыптастырады. Элементті электрондық құжатты жөнелтуші қалыптастыруға тиіс емес.

13. Электрондық құжаттың ЭЦҚ қол қойылған деректердің тұтастығын тексеруді жөнелтушінің сенім білдірілген үшінші тарапы XMLDsig стандартының 3.2-бөлімінде сипатталған рәсімге сәйкес орындайды. Тұтастықты тексеру рәсімі орындалатын деректер блоктары осы құжаттың "в" тармақшасының талаптарына сәйкес айқындалады.

14. Электрондық құжаттарды өңдеу Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 27 қаңтардағы № 5 шешімімен бекітілген Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректермен электрондық алмасу қағидаларына сәйкес, сондай-ақ мынадай ережелерді есепке алғанда, ақпараттық өзара іс-қимылды регламенттейтін технологиялық құжаттардың талаптарына сәйкес орындалады:

а) қамтылған электрондық құжаттың блогын құрылымдық бақылау кезеңі XSD-схемасы бойынша электрондық құжаттың біріздендірілген құрылымын тексеруді, сондай-ақ электрондық құжаттар (мәліметтер) түрлерінің құрылымдарын тексеруді қамтиды;

б) алушының сенім білдірілген үшінші тарапының түбіртегін тексеру операциясы қамтылған электрондық құжатты құрылымдық бақылау кезеңі орындалғанан кейін орындалуға тиіс;

в) егер шеңберінде электрондық құжат берілетін ақпараттық өзара іс-қимыл тәртібіне сәйкес алушыға "Алынды" растау белгісін беру көзделген болса, онда сенім білдірілген үшінші тараптың түбіртегін тексеру операциясы мұндай растау белгісі жіберілгеннен кейін орындалады.

Электрондық құжат деректерінің схемасы

<?xmlversion="1.0" encoding="UTF-8"?>

<xs:schemaxmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:doc="urn:EEC:SignedData:v1.0:EDoc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="urn:EEC:SignedData:v1.0:EDoc" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd#"/>

<xs:element name="SignedDoc" type="doc:SignedDocType">

<xs:annotation>

<xs:documentation>Электрондық құжат</xs:documentation>

</xs:annotation>

</xs:element>

<xs:complexType name="SignedDocType">

<xs:annotation>

<xs:documentation> "Электрондық құжат" деректер типі</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="Data">

<xs:annotation>

<xs:documentation>Қамтылған электрондық құжаттың блогы</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:complexContent>

<xs:extension base="doc:DataType">

<xs:attribute name="Id" type="xs:ID" use="required"/>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:element>

<xs:element ref="ds:Signature" minOccurs="0">

<xs:annotation>

<xs:documentation>Сенім білдірілген үшінші тараптың түбіртегі</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:complexType>

<xs:complexType name="DataType">

<xs:annotation>

<xs:documentation> Қамтылған электрондық құжат блогының типі</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element ref="ds:Signature" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation> Электрондық цифрлық қолтаңба (электрондық қолтаңба)</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="SignedContent">

<xs:annotation>

<xs:documentation> Қол қойылатын деректердің блогы</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:any namespace="##any" processContents="lax" maxOccurs="unbounded">

<xs:annotation>

<xs:documentation> Электрондыққұжаттар (мәліметтер) түрлерініңқұрылымы</xs:documentation>

</xs:annotation>

</xs:any>

</xs:sequence>

<xs:attribute name="Id" type="xs:ID" use="required">

<xs:annotation>

<xs:documentation> Қол қойылатын деректер блогының атрибут-сәйкестендіргіші</xs:documentation>

</xs:annotation>

</xs:attribute>

<xs:attribute name="DocInstance" type="xs:anyURI" use="required">

<xs:annotation>

<xs:documentation> Электрондық құжаттың бірегей сәйкестендіргіші</xs:documentation>

</xs:annotation>

</xs:attribute>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:schema>

Сенім білдірілген үшінші тараптың түбіртектерін қалыптастыруға және өңдеу тәртібіне қойылатын ТАЛАПТАР

1. Сенім білдірілген үшінші тараптың түбіртегі (бұдан әрі – түбіртек) түбіртектің қосымша деректемелерін қамтитын XAdES (XAdES-T нысаны) форматындағы электрондық XML-құжаты болып табылады.

2. Түбіртекті қалыптастыруға және өңдеу тәртібіне қойылатын талаптарды сипаттаған кезде тізбесі 1-кестеде берілген атаулардың кеңістігі пайдаланылады.

1-кесте

Құжат атаулары кеңістігінің тізбесі

Сөз алды қосымшасы	Мекенжай
rcpt	urn:EEC:TTP:v1.0:receipt
doc	urn:EEC:SignedData:v1.0:EDoc
ds	http://www.w3.org/2000/09/xmldsig#
xades	http://uri.etsi.org/01903/v1.3.2#
xs	http://www.w3.org/2001/XMLSchema

3. Түбіртекті толтырған кезде 2-кестеде берілген алгоритмдердің сәйкестендіргіштері пайдаланылады.

Түбіртектің, түбіртектің негізгі және қосымша деректемелері блоктарының XAdES форматындағы құрылымдары 3 –5-кестелерде берілді.

2-кесте

Алгоритмдердің сәйкестендіргіштері

Алгоритм	Сәйкестендіргіш
XML каноникализациялау алгоритмі	http://www.w3.org/2001/10/xml-exc-c14n#
ЭЦҚ мәндерін кодтаудың және хэш-соманың алгоритмі	http://www.w3.org/2000/09/xmldsig#base64

3-кесте

Түбіртектің құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
ds:Signature	ds:SignatureType	түбіртектің айналма элементі	1
@Id	xs:ID	түбіртектің хабарлама шеңберінде бірегейатрибут-сәйкестендіргіші.XML–блоктардың сәйкестендіргіштері н беру қағидалары 6-кестеде берілген	1
ds:SignedInfo	ds:SignedInfoType	қол қойылған деректер блогының айналма элементі	1
ds:CanonicalizationMethod	ds:CanonicalizationMethodType	XML каноникализациялау алгоритмінің айналма элементі	1
@Algorithm	xs:anyURI	XMLканоникализациялау алгоритмінің сәйкестендіргіші. Сәйкестендіргіштерді беру қағидалары 2-кестеде берілген	1
ds:SignatureMethod	ds:SignatureMethodType	ЭЦҚ қалыптастыру алгоритмінің айналма элементі	1
@Algorithm	xs:anyURI	ЭЦҚ қалыптастыру алгоритмінің атрибут-сәйкестендіргіші. Сәйкестендіргіштер тізбесі Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасутуралы ережеге № 8 қосымшада берілген	1
ds:Reference	ds:ReferenceType	түбіртек манифестіне арналған сілтеменің айналма элементі	1
@URI	xs:anyURI	манифест блогының XML-элементіне арналған атрибут-сілтеме	1
@Type	xs:anyURI	манифестке арналған сілтеме ретінде атрибут, ds:Referenceсәйкестендіруші блок "http://www.w3.org/2000/09/xmldsig#Manifest" мәнімен толтырылады	1
ds:Transforms	ds:TransformsType	трансформациялар тізбесінің айналма элементі	1
ds:Transform	ds:TransformType	трансформациялаудың айналма элементі	1
@Algorithm	xs:anyURI	XML каноникализациялау алгоритмінің атрибут-сәйкестендіргіші.Сәйкестендіргіштер беру қағидалары2-кестеде берілген	1
ds:DigestMethod	ds:DigestMethodType	хэш-соманы есептеу алгоритмінің айналма элементі	1
@Algorithm	xs:anyURI	түбіртек үшін хэш-соманы есептеу алгоритмінің атрибут-сәйкестендіргіші. Сәйкестендіргіштер тізбесі Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасутуралы ережеге № 8 қосымшада берілген	1
ds:DigestValue	ds:DigestValueType	XMLканоникализациялау жүргізгеннен кейін хэш-сома мәні	1
ds:Reference	ds:ReferenceType	түбіртектің негізгі деректерінің қол қойылатын блогына арналған сілтеме үшін айналма элемент	1
@URI	xs:anyURI	4-кестеде бірелген хабарлама шеңберінде бірегей, түбіртектердің негізгі деректемелері блогының XML-элементіне арналған атрибут-сілтеме	1
@Type	xs:anyURI	түбіртектің негізгі деректемелерінің блогына арналған сілтеме ретіндегіатрибуты, ds:Referenceсәйкестендіруші блок атрибут. "urn:EEC:TTP:v1.0:receipt:details" мәнімен толтырылады	1
ds:Transforms	ds:TransformsType	трансформациялар тізбесінің айналма элементі	1
ds:Transform	ds:TransformType	трансформациялаудың айналма элементі	1
@Algorithm	xs:anyURI	XML каноникализациялау алгоритмінің атрибут-сәйкестендіргіші. Сәйкестендіргіштер беру қағидалары2-кестеде берілген	1
ds:DigestMethod	ds:DigestMethodType	хэш-соманы есептеу алгоритмінің айналма элементі	1
@Algorithm	xs:anyURI	түбіртек үшін хэш-соманы есептеу алгоритмінің атрибут-сәйкестендіргіші.Сәйкестендіргіштер тізбесі Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ережеге № 8 қосымшада берілген	1
ds:DigestValue	ds:DigestValueType	XMLканоникализациялау жүргізгеннен кейін түбіртектің негізгі деректерінің блогы хэш-сомасының мәні	1
ds:Reference	ds:ReferenceType	XAdES форматында түбіртектің қосымша деректемелерінің блогына арналған сілтеменің айналма элементі	1
@URI	xs:anyURI	5-кестеде берілген, XAdES форматындағы түбіртектің қосымша деректемелері блогының XML-элементіне арналған атрибут-сілтеме	1
@Type	xs:anyURI	XAdES форматында түбіртектің қосымша деректемелерінің блогына арналған сілтеме ретінде атрибут,ds:Reference сәйкестендіруші блок."http://uri.etsi.org/01903#SignedProperties" мәнімен толтырылады	1
ds:Transforms	ds:TransformsType	трансформациялар тізбесінің айналма элементі	1
ds:Transform	ds:TransformType	Трансформациялаудың айналма элементі	1
@Algorithm	xs:anyURI	XML каноникализациялау алгоритмінің атрибут-сәйкестендіргіші. Сәйкестендіргіштер беру қағидалары 2-кестеде берілген	1
ds:DigestMethod	ds:DigestMethodType	хэш-соманы есептеу алгоритмінің айналма элементі	1
@Algorithm	xs:anyURI	түбіртек үшін хэш-соманы есептеу алгоритмінің атрибут-сәйкестендіргіші. Сәйкестендіргіштер тізбесі Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ережеге № 8 қосымшада берілген	1
ds:DigestValue	ds:DigestValueType	XML каноникализациялау жүргізгеннен кейін XAdES форматында түбіртектің қосымша деректерінің блогы хэш-сомасының мәні	1
ds:SignatureValue	ds:SignatureValueType	XML каноникализациялау жүргізгеннен кейін ds:SignedInfo элементі үшін есептелген ЭЦҚ мәні	1
ds:KeyInfo	ds:KeyInfoType	ЭЦҚ қалыптастыру кезінде пайдаланылған негізгі ақпараттың айналма элементі	1
ds:X509Data	ds:X509DataType	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілті сертификатының айналма элементі	1
ds:X509Certificate	xs:base64Binary	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілтінің сертификаты	1
ds:Object	ds:ObjectType	деректердің қосымша блоктарының айналма элементі	1
ds:Manifest	ds:ManifestType	манифест блогының айналма элементі	1
@Id	xs:ID	манифесттің хабарлама шеңберінде бірегей атрибут-сәйкестендіргіші. Сәйкестендіргіштер беру қағидалары 6-кестеде берілген	1
ds:Reference	ds:ReferenceType	қол қойылатын электрондық құжатқа арналған сілтеменің айналма элементі	1
@URI	xs:anyURI	қамтылған электрондық құжат блогының XML-элементіне арналған атрибут-сілтеме. Электрондық құжаттың түбіртек қалыптастырылатын doc:SignedDoc/doc:Data/@Id арналған сілтеме болуға тиіс	1
ds:Transforms	ds:TransformsType	трансформациялар тізбесінің айналма элементі	1
ds:Transform	ds:TransformType	трансформацияның айналма элементі	1
@Algorithm	xs:anyURI	XML каноникализациялау алгоритмінің атрибут-сәйкестендіргіші. Сәйкестендіргіштер беру қағидалары 2-кестеде берілген	1
ds:DigestMethod	ds:DigestMethodType	хэш-соманы есептеу алгоритмінің айналма элементі	1
@Algorithm	xs:anyURI	түбіртек үшін хэш-соманы есептеу алгоритмінің атрибут-сәйкестендіргіші. Сәйкестендіргіштер тізбесі Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ережеге № 8 қосымшада берілген	1
ds:DigestValue	ds:DigestValueType	осы құжаттың 17-тармағына сәйкес қалыптастырылатын XML каноникализациялау жүргізгеннен кейін қол қойылатын электрондық құжаттың хэш-сомасының мәні	1
rcpt:Receipt	rcpt:ReceiptType	түбіртектің негізгі деректемелерінің блогы. Блок сипаттамасы 4-кестеде берілген	1
xades:QualifyingProperties	xades:QualifyingPropertiesType	XAdES форматында түбіртектің қосымша деректемелерінің блогы. Блок сипаттамасы 5-кестеде берілген	1

4-кесте

Түбіртектің негізгі деректемелері блогының құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
rcpt:Receipt	rcpt:ReceiptType	түбіртектің негізгі деректемелері блогының айналма элементі	1
@Id	xs:ID	түбіртектің негізгі деректемелері блогының хабарлама шеңберінде бірегей атрибут-сәйкестендіргіші. Сәйкестендіргіштер беру қағидалары 6-кестеде берілген	1
rcpt:ReceiptId	xs:anyURI	қалыптастырылған түбіртектің бірегей сәйкестендіргіші. Сәйкестендіргіштер қалыптастыру қағидалары осы құжаттың 5-тармағында берілген	1
rcpt:DocId	xs:anyURI	түбіртек қалыптастырылған электрондық құжаттың сәйкестендіргіші. Сәйкестендіргіштер қалыптастыру қағидалары осы құжаттың 6-тармағында берілген	1
rcpt:Report	–	тексеру нәтижелері туралы мәліметтердің блогы. Блокты қалыптастыру қағидалары осы құжаттың 7-12 тармақтарында берілген	1
rcpt:Success	rcpt:SuccessType	тексеру табысты орындалғанын көрсететін элемент	0..*
rcpt:Error	rcpt:ErrorType	тексеру кезінде қате туындағанын көрсететін элемент	0..*
rcpt:AttachedData	–	қосымша мәліметтердің блогы. Блокты қалыптастыру қағидалары осы құжаттың 13-тармағында берілген	0..1
один или несколько элементов блока	xs:any	қосымша мәліметтердің қамтылған блогы	1..*

5-кесте

XAdES форматында түбіртектің қосымша деректемелері блогының құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
xades:QualifyingProperties	xades:QualifyingPropertiesType	XAdES форматында түбіртектің қосымша деректемелері блогының айналма элементі	1
xades:SignedProperties	xades:SignedPropertiesType	түбіртектің қол қойылатын ерекшеліктерінің блогы	1
@Id	xs:ID	XAdES форматында түбіртектің қол қойылатын ерекшеліктері блогының атрибут-сәйкестендіргіші. Сәйкестендіргіштер беру қағидалары 6-кестеде берілген	1
xades:SignedSignatureProperties	xades:SignedSignaturePropertiesType	айналма элемент	1
xades:SigningCertificate	xades:CertIDListType	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілтінің сертификатын пайдалану туралы мәліметтердің айналма элементі	1
xades:Cert	xades:CertIDType	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілтінің пайдаланылған сертификаты туралы мәліметтердің айналма элементі	1
xades:CertDigest	xades:DigestAlgAndValueType	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілтінің пайдаланылған сертификатының хэш-сомасының айналма элементі	1
ds:DigestMethod	ds:DigestMethodType	хэш-соманы есептеу алгоритмінің айналма элементі	1
@Algorithm	xs:anyURI	түбіртек үшін хэш-соманы есептеу алгоритмінің сәйкестендіргіші. Сәйкестендіргіштер тізбесі Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ережеге № 8 қосымшада берілген	1
ds:DigestValue	ds:DigestValueType	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілтінің сертификаты хэш-сомасының мәні	1
ds:IssuerSerial	ds:X509IssuerSerialType	айналма элемент	1
ds:X509IssuerName	xs:string	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілтінің сертификатын дайындаған куәландырушы орталықтың атауы (Issuerжолағы X.509 стандартына сәйкес толтырылады)	1
ds:X509SerialNumber	xs:integer	сенім білдірілген үшінші тараптың ЭЦҚ-ны тексеру кілті сертификатының сериялық нөмірі (SerialNumber жолағы X.509 стандартына сәйкес толтырылады)	1
xades:SignatureProductionPlace	xades:SignatureProductionPlace Type	түбіртек қалыптастыру орнының (сегментінің) айналма элементі	1
xades:CountryName	xs:string	түбіртек қалыптастыру орнының (сегментінің) сәйкестендіргіші. Толтыру қағидалары осы құжаттың 14-тармағында берілген	1
xades:SignerRole	xades:SignerRoleType	түбіртек қалыптастыратын сенім білдірілген үшінші тараптың рөлі туралы мәліметтердің айналма элементі	1
xades:ClaimedRoles	xades:ClaimedRolesListType	айналма элемент	1
xades:ClaimedRole	xades:AnyType	сенім білдірілген үшінші тараптың рөлі. Рөлдер тізбесі осы құжаттың 15-тармағында берілген	1
xades:UnsignedProperties	xades:UnsignedPropertiesType	уақыт белгісін қамтитын түбіртектің қол қойылмаған ерекшеліктерінің блогы	1
xades:SignatureTimeStamp	xades:SignatureTimeStamp	уақытты көрсететін мөртабанға арналған айналма элемент	1
ds:CanonicalizationMethod	ds:CanonicalizationMethodType	XMLканоникализациялау алгоритмінің сәйкестендіргіші. Сәйкестендіргіштер беру қағидалары 2-кестеде берілген	1
xades:EncapsulatedTimeStamp	xades:EncapsulatedPKIDataType	RFC 3161 уақыт мөртабандары хаттамасының стандартына сәйкес ресімделген уақытты көрсететін мөртабан. Уақытты көрсететін мөртабанды қалыптастыру қағидалары осы құжаттың 16-тармағында берілген. Уақытты көрсететін мөртабан қалыптастыру кезінде криптографиялық алгоритмдердің индикаторлары Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ережеге № 8 қосымшада көзделген қағидаларға сәйкес көрсетілуге тиіс	1

4. XML-блоктардың сәйкестендіргіштерін толтыру қағидалары 6-кестеде берілген. Бұл ретте <Нөмір> элементінің орнына "1" деген мән қойылуға тиіс, ал <ДТС> элементінің орнына мынадай мәндердің біреуі қойылуға тиіс:

а) TTP.Sender –егер түбіртекті сенім білдірілген үшін тарап қалыптастыратын болса;

б) TTP.Receiver –егер түбіртекті алушының сенім білдірілген үшінші тарапы қалыптастыратын болса.

6-кесте

XML-блоктардың сәйкестендіргіштерін толтыру қағидалары

XML-блоктың сәйкестендіргіші	Толтыру қағидалары
түбіртектің сәйкестендіргіші	<ДТС>.Receipt<Номер>
манифест блогының сәйкестендіргіші	<ДТС>.Receipt<Номер>Manifest
түбіртектің негізгі дректері блогының сәйкестендіргіші	<ДТС>.Receipt.<Номер>Details
XAdESформатында түбіртектің қол қойылатын ерекшеліктері блогының сәйкестендіргіші	<ДТС>.Receipt<Номер>SignedProperties

5. Түбіртектің бірегей сәйкестендіргіші (rcpt:ReceiptIdэлементі) RFC 4122 (Network Working Group. RFC 4122. "A Universally Unique IDentifier (UUID) URN Namespace". http://www.ietf.org/rfc/rfc4122.txt) ерекшелігіне сәйкес қалыптастырылуға тиіс.

6. Электрондық құжат сәйкестендіргіші (rcpt:DocId) түбіртек қалыптастырылатын электрондық құжатты бірегей сәйкестендіретін жол болып табылады. Сәйкестендіргіш электрондық құжат құрылымынан алынған мынадай атрибуттың мәнімен толтырылады: "doc:SignedDoc/doc:Dаta/doc:SignedContent/@DocInstance".

7. Тексеру нәтижелері туралы мәліметтердің блогы (rcpt:Report) сенім білдірілген үшін тарап орындаған тексеру нәтижелері туралы куәландыратын бір немесе бірнеше rcpt:Error және rcpt:Success элементін қамтуға тиіс. rcpt:Success және rcpt:Error элементтерінің құрылымы 7-8 кестелерде берілген.

7-кесте

rcpt: Success элементінің құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
rcpt:Success	rcpt:SuccessType	тексеру табысты орындалғанын көрсететін элемент	1
@Reference	xs:anyURI	тексерілген объектінің сәйкестендіргіші	0..1

8-кесте

rcpt: Error элементінің құрылымы

Элемент	Деректер типі	Сипаттамасы	Еселігі
rcpt:Error	rcpt:ErrorType	тексеру кезінде қате туындағанын көрсететін элемент	1
@Reference	xs:anyURI	тексерілген объектінің сәйкестендіргіші	0..1
rcpt:ReasonCode	xs:string	қате коды	1
rcpt:ReasonText	xs:string	қатенің мәтіндік сипаттамасы	1

8. rcpt: Success және rcpt:Error элементтерінің Reference атрибутын жөнелтушінің сенім білдірілген үшінші тарапы толтырады. Атрибут rcpt:Success немесе rcpt:Error элементі қалыптастырылатын электрондық құжаттағы ЭЦҚ арналған сілтемені қамтуға тиіс. Сілтемені қалыптастыру үшін ЭЦҚ-ның ds:Signature/@Id атрибутының мәнін пайдалану қажет.

Алушының сенім білдірілген үшінші тарапы Reference атрибутын қалыптастыруға тиіс емес.

9. rcpt:ReasonCode элементін толтыру кезінде мынадай кодтар пайдаланылуға тиіс:

а) Signature.Error – код электрондық құжаттағы ЭЦҚ немесе түбіртектегі ЭЦҚ-ны тексеру қатесі туралы куәландырады;

б) Signature.BadCertificate – код электрондық құжаттың ЭЦҚ-ны тексеру кілтінің сертификатын не түбіртектің ЭЦҚ-ны тексеру кілтінің сертификатын тексеру қатесі туралы куәландырады.

10. rcpt:ReasonText элементі қатені сипаттайтын мәтінді қамтиды. rcpt:ReasonText элементін толтыру қағидаларын сенім білдірілген үшінші тарап дербес айқындайды.

11. Жөнелтушінің сенім білдірілген үшінші тарапы rcpt:Report тексеру нәтижелері туралы мәліметтердің қамтылған блогын қалыптастырудың мынадай алгоритмін іске асыруға тиіс:

а) электрондық құжаттағы алғашқы ЭЦҚ-ны іздестіру орындалады;

б) табылған ЭЦҚ үшін Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 28 қыркүйектегі № 125 шешімімен бекітілген Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ереженің ІІІ бөлімінің 2-кіші бөлімінде көзделген тексерулер орындалады;

в) егер ЭЦҚ-ны барлық тексеру табысты орындалса, онда жөнелтушінің сенім білдірілген үшінші тарапы rcpt:Success блогын қалыптастырады, кері жағдайда rcpt:Error блогы қалыптастырылады;

г) электрондық құжатта мынадай ЭЦҚ-ны іздестіру орындалады. Егер ЭЦҚ табылса, осы тармақтың "б"-"г" тармақшаларында көрсетілген әрекеттер қайталанады.

12. Алушының сенім білдірілген үшінші тарапы rcpt:Report тексеру нәтижелері туралы мәліметтердің қамтылған блогын қалыптастырудың мынадай алгоритмін іске асыруға тиіс:

а) алушының сенім білдірілген үшінші тарапының түбіртегін электрондық құжаттың құрамында іздестіру орындалады;

б) табылған түбіртек үшін Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 28 қыркүйектегі № 125 шешімімен бекітілген Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ереженің ІІІ бөлімінің 2-кіші бөлімінде көзделген тексерулер орындалады;

в) егер түбіртекті барлық тексеру табысты орындалса, онда алушының сенім білдірілген үшінші тарапы rcpt:Success блогын қалыптастырады, кері жағдайда rcpt:Error блогы қалыптастырылады.

13. rcpt:AttachedData блогы түбіртекпен байланысты қосымша ақпаратты қамтиды.

Алушының сенім білдірілген үшінші тарапы rcpt: AttachedData блогына жөнелтушінің сенім білдірілген үшінші тарапының түбіртегін салуға тиіс.

14. Түбіртекті қалыптастыру орнын (сегментін) (xades:CountryName элементі) сәйкестендіру үшін мынадай кодтардың біреуі пайдаланылуға тиіс:

а) EEC – Еуразиялық экономикалық комиссияның интеграциялық сегментінде түбіртекті қалыптастыру кезінде;

б) ISO 3166-1 alpha-2 стандартына сәйкес ел коды – Еуразиялық экономикалық одаққа мүше мемлекеттердің біреуінің (бұдан әрі – мүше мемлекеттер) ұлттық сегментінде түбіртекті қалыптастыру кезінде.

15. Сенім білдірілген үшінші тараптың рөлін көрсету үшін (xades:ClaimedRole элементі) мынадай кодтардың біреуі пайдаланылуға тиіс:

а) TTP.Sender –егер түбіртекті жөнелтушінің сенім білдірілген үшінші тарапы қалыптастырса;

б) TTP.Receiver –егер түбіртекті алушының сенім білдірілген үшінші тарапы қалыптастырса.

16. Жөнелтушінің сенім білдірілген үшінші тарапының түбіртегі үшін уақытты көрсететін мөртабан (xades: EncapsulatedTimeStamp элементі) қалыптастыру үшін сенім білдірілген үшінші тараптың куәландырушы орталығының уақытты көрсететін мөртабанның сервисін пайдалана отырып және интеграцияланған жүйенің сенім білдірілген үшінші тарапы қызметінің стандарттарын қолдана отырып,орындалады.

Алушының сенім білдірілген үшінші тарапының түбіртегі үшін уақытты көрсететін мөртабан қалыптастыру мүше мемлекеттің уақытты көрсететін мөртабанның сервисін пайдалана отырып және ұлттық криптографиялық стандарттарды қолдана отырып, орындалады.

Сенім білдірілген үшінші тараптың куәландырушы орталығының уақытты көрсететін мөртабанның сервисі қол жетімсіз болған жағдайда интеграцияланған жүйенің сенім білдірілген үшінші тарапы қызметінің криптографиялық стандарттарының көмегімен уақытты көрсететін мөртабан қалыптастыра отырып, жөнелтушінің сенім білдірілген үшінші тарапының уақытты көрсететін мөртабанның автономды сервисі пайдаланылуға тиіс. Сенім білдірілген үшінші тарап қызметінің куәландырушы орталығының уақытты көрсететін мөртабан сервисінің қолжетімсіздігі және көрсетілген факт себептерге талдау жүргізу және оларды жою мақсатында сенім білдірілген үшінші тараптың аудит журналында міндетті тәртіпте жазылады.

17. Түбіртек манифесті блогындағы хэш (ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue элементінде қамтылған) электрондық құжаттың doc: Dаtaблогында XML-тег doc:Dаta өзін, оның атрибуттарын және барлық элемент-буындарын қоса алғанда, қалыптастырылуға тиіс (1-сурет).

Хэш қалыптастыру үшін электрондық құжаттың XML-элементтерін іріктеу XMLDsig стандартының "same-document reference" типінің сілтемелері бойынша іріктеу үшін ұқсас қағидалар бойынша орындалуға тиіс (4.3.3.3-бөлім). Элементтер-комментарийлерді (non-comment node) қоспағанда, электрондық құжаттың барлық XML- элементтерін іріктеу жүргізілуге тиіс.

1-сурет. Электрондық құжаттың құрылымында, түбіртек манифестінің блогында хэш қалыптастыру аясында түбіртектің орналасуы

18. Мүше мемлекеттердің ұлттық сегменттерінің ішінде пайдаланылатын хабарламалар форматтарының әралуандығы жағдайында жөнелтушіден алушыға электрондық құжатты беру бойынша шығындарды азайту мақсатында түбіртектер электрондық құжаттың құрылымына салынуға тиіс.

Түбіртекті салу doc:Data блогынан кейін doc:SignedDoc блогының еншілес элементі ретінде түбіртектің XML-құрылымын қосу арқылы орындалады(1-сурет).

19. Түбіртектегі ЭЦҚ-ны тексеру 2 режимде орындалуы мүмкін:

а) түбіртек қалыптастырылған электрондық құжат болған кезде түбіртектегі ЭЦҚ-ны тексеру (тексерудің негізгі режимі);

б) түбіртек қалыптастырылған электрондық құжатсыз түбіртектегі ЭЦҚ-ны тексеру (тексерудің қызметтік режимі).

20. Негізгі режимде түбіртектегі ЭЦҚ-ны тексеру түбіртек қалыптастырылған электрондық құжаттың заңды маңыздылығын қамтамасыз ету мақсатында орындалады.

Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 28 қыркүйектегі № 125 шешімімен бекітілген Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ереженің ІІІ бөлімінің 2-кіші бөлімінде көзделген түбіртектегі ЭЦҚ барлық тексерулер негізгі режимде орындалады.

21. Негізгі режимде түбіртектегі ЭЦҚ-ны тексеру рәсіміне мынадай талаптар қойылады:

тексеру XAdES (XAdES-T нысаны) стандартында көрсетілген қағидаларға сәйкес орындалады.

негізгі режимде түбіртектегі ЭЦҚ-ны тексеру электрондық құжаттың тұтастығын тексеруді қамтиды.

Осы құжаттың 17-тармағының талаптарына, сондай-ақ XMLDsig стандартының қағидаларына сай ds:Reference типті элементтерді өңдеу қағидаларына сәйкес қамтылған электрондық құжаттың хэшін қалыптастыру рәсімі түсіндіріледі және түбіртектің ЭЦҚ ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue элементінде көрсетілген мәнмен қалыптастырылған хэшті салыстырып тексеру электрондық құжаттың тұтастығын тексеру болып түсіндіріледі.

Егер қамтылған электрондық құжаттың хэші түбіртектің ЭЦҚ ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue элементінің құрамында көрсетілген мәнге сәйкес келмеген жағдайда, электрондық құжаттың тұтастығы бұзылған, түбіртектегі ЭЦҚ-ны тексеру рәсімі қатемен аяқталған болып саналады.

22. Қызметтік режимде түбіртектегі ЭЦҚ-ны тексеру түбіртек өзі қалыптастырылған электрондық құжаттан жеке сақталған жағдайларда түбіртектің тұтастығы мен төлнұсқалығын тексеру мақсатында орындалады. Бұл ретте түбіртек қалыптастырылған электрондық құжаттың тұтастығын тексеру орындалмайды.

Түбіртектегі ЭЦҚ-ны тексеру дің қызметтік режимі түбіртектердің тұтастығы мен төлнұсқалығын мерзімді тексеруді, архивтік сақтау мерзімін ұзарту үшін түбіртектерді қосымша ЭЦҚ-мен куәландыруды қоса алғанда, сенім білдірілген үшінші тараптың түбіртектерін архивтік сақтауға байланысты операцияларда пайдаланылуы мүмкін.

23. Түбіртектегі ЭЦҚ-ны тексеру рәсіміне мынадай талаптар қойылады:

а) тексеру XAdES (XAdES-T нысаны) стандартында көрсетілген қағидаларға сәйкес орындалады;

б) тексеру кезінде түбіртектің ЭЦҚ ds:Signature/ds:Object/ds:Manifest/ds:Reference элементі өңделмейді.

түбіртектің негізгі деректемелерінің ДЕРЕКТЕР СХЕМАСЫ

<?xmlversion="1.0" encoding="UTF-8"?>

<xs:schemaxmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:rcpt="urn:EEC:TTP:v1.0:receipt" targetNamespace="urn:EEC:TTP:v1.0:receipt" elementFormDefault="qualified" attributeFormDefault="unqualified">

<xs:element name="Receipt" type="rcpt:ReceiptType">

<xs:annotation>

<xs:documentation>Түбіртектің негізгі деректемелерінің блогы</xs:documentation>

</xs:annotation>

</xs:element>

<xs:complexType name="ReceiptType">

<xs:annotation>

<xs:documentation>Түбіртектің негізгі деректемелі блогының типі</xs:documentation>

</xs:annotation>

<xs:sequence>

<xs:element name="ReceiptId" type="xs:anyURI">

<xs:annotation>

<xs:documentation>Қалыптастырылған түбіртектің бірегей сәйкестендіргіші</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="DocId" type="xs:anyURI">

<xs:annotation>

<xs:documentation>Электрондық құжаттың сәйкестендіргіші</xs:documentation>

</xs:annotation>

</xs:element>

<xs:element name="Report">

<xs:annotation>

<xs:documentation>Тексеру нәтижелері туралы мәліметтердің блогы</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:choice maxOccurs="unbounded">

<xs:element name="Success" type="rcpt:SuccessType"/>

<xs:element name="Error" type="rcpt:ErrorType"/>

</xs:choice>

</xs:complexType>

</xs:element>

<xs:element name="AttachedData" minOccurs="0">

<xs:annotation>

<xs:documentation>XMLформатындақосымшамәліметтердіңблогы</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

<xs:attribute name="Id" type="xs:ID" use="required"/>

</xs:complexType>

<xs:complexType name="BaseReportType">

<xs:annotation>

<xs:documentation>Тексеру туралы элементтің-есептің базалық типі</xs:documentation>

</xs:annotation>

<xs:attribute name="Reference" type="xs:anyURI" use="optional"/>

</xs:complexType>

<xs:complexType name="SuccessType">

<xs:annotation>

<xs:documentation>ДТС тексеру табысты орындалғанын көрсететін элементтің типі</xs:documentation>

</xs:annotation>

<xs:complexContent>

<xs:extension base="rcpt:BaseReportType"/>

</xs:complexContent>

</xs:complexType>

<xs:complexType name="ErrorType">

<xs:annotation>

<xs:documentation>Қате сипаттамасы контейнерінің типі</xs:documentation>

</xs:annotation>

<xs:complexContent>

<xs:extension base="rcpt:BaseReportType">

<xs:sequence>

<xs:element name="ReasonCode">

<xs:annotation>

<xs:documentation>Қате коды</xs:documentation>

</xs:annotation>

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Signature.Error"/>

<xs:enumeration value="Signature.BadCertificate"/>

<xs:enumeration value="Document.AuthenticityError"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

<xs:element name="ReasonText" type="xs:string" >

<xs:annotation>

<xs:documentation>Қатенің мәтіндік сипаттамасы</xs:documentation>

</xs:annotation>

</xs:element>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

</xs:schema>

Еуразиялық экономикалық
одаққа мүше
мемлекеттердің
мемлекеттік билік
органдарының бір-бірімен
және Еуразиялық
экономикалық омиссиямен
трансшекаралық өзара іс-
қимылы кезінде
электрондық құжаттармен
алмасу туралы ережеге
№ 5 ҚОСЫМША

Сенім білдірілген үшінші тараппен өзара іс-қимыл кезінде пайдаланылатын хабарламалардың СИПАТТАМАСЫ

1. Сенім білдірілген үшінші тараппен алмасатын хабарламалар мен сыртқы және өзара сауданың интеграциялық ақпараттық жүйесінің интеграциялық шлюзі (Еуразиялық экономикалық одақтың интеграцияланған ақпараттық жүйесінің функционалдық мүмкіндіктерін кеңейту негізінде құрылған) (бұдан әрі - интеграцияланған жүйе) Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 27 қаңтардағы № 5 шешімімен бекітілген Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректермен электрондық алмасу қағидаларына (бұдан әрі – Деректермен электрондық алмасу қағидалары) сәйкес қалыптастырылады.

Барлық хабарламалар интеграцияланған жүйенің қызметтік хабарламалар сыныбына жатады.

2. Хабарламаларды сипаттау кезінде тізбесі кестеде берілген атаулар кеңістігі пайдаланылады.

Құжат атаулары кеңістігінің тізбесі

Сөз алды қосымшасы	Мекенжай
ttp	urn:EEC:TTP:v1.0
soap	Деректермен электрондық алмасу қағидаларына сәйкес
wsa	Деректермен электрондық алмасу қағидаларына сәйкес

3. Сенім білдірілген үшінші тарапқа келіп түсетін хабарламаларға мынадай жалпы талаптар қойылады:

а) wsa:To тақырыбының элементі Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 28 қыркүйектегі № 125 шешімімен бекітілген Еуразиялық экономикалық одаққа мүше мемлекеттердің мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс-қимылы кезінде электрондық құжаттармен алмасу туралы ережеде көзделген тексеруді қамтамасыз ететін сенім білдірілген үшінші тарап сервисінің (бұдан әрі тиісінше – төлнұсқалықты растау сервисі, Ереже) қисынды мекенжайын қамтуға тиіс. Қисынды мекенжай ұйымның – интеграцияланған жүйенің тиісті сегментінің интеграциялық шлюзі операторының төлнұсқалығын растау сервисіне беріледі;

б) wsa:ReplyTo/wsa:Address тақырыбының элементі төлнұсқалықты растау сервисінен келіп түсетін хабарламаларды өңдеуді қамтамасыз ететін интеграциялық шлюз интерфейсінің қисынды мекенжайын қамтуға тиіс;

в) wsa:Action тақырыбының элементі мынадай мәндердің біреуін қамтуға тиіс:

int://SR/TTP/Sender/Incoming – егер хабарламаны жөнелтушінің сенім білдірілген үшінші тарапы жіберген болса;

int://SR/TTP/Recipient/Incoming – егер хабарламаны алушының сенім білдірілген үшінші тарапы жіберген болса;

г) негізге (soap:Body) жөнелтушіден алынған электрондық құжат енгізіледі.

4. Кіріс хабарламаны өңдеу нәтижелеріне байланысты сенім білдірілген үшінші тарап интеграциялық шлюзге мынадай хабарламалар жібереді:

а) төлнұсқалықты растау сервисі штаттық жұмыс істеген жағдайда–электрондық құжат сенім білдірілген үшінші тараптың түбіртегімен толықтырылған хабарлама (жауап хабарлама);

б) сенім білдірілген үшінші тараптың деңгейінде хабарламаны және (немесе) электрондық құжатты өңдеуде қате туындаған жағдайда–қате туралы технологиялық хабарлама.

5. Жауап хабарламаға мынадай талаптар қойылады:

а) wsa:To тақырыбының элементі кіріс хабарламаның wsa:ReplyTo/wsa:Address элементінің мәнін қамтуға тиіс;

б) wsa:From/wsa:Address тақырыбының элементі ұйым – интеграциялық шлюз операторы берген төлнұсқалықты растау сервисінің қисынды мекенжайын қамтуға тиіс;

в) wsa:RelatesTo тақырыбының элементі кіріс хабарламаның wsa:MessageId элементінің мәнін қамтуға тиіс;

г) wsa:Action тақырыбының элементі мынадай мәндердің біреуін қамтуға тиіс:

int://SR/TTP/Sender/Outgoing – егер хабарламаны жөнелтушінің сенім білдірілген үшінші тарапы жіберген болса;

int://SR/TTP/Recipient/Outgoing – егер хабарламаны алушының сенім білдірілген үшінші тарапы жіберген болса;

д) негізге(soap:Body) электрондық құжат пен сенім білдірілген үшінші тараптың түбіртегі енгізіледі.

6. Қате туралы технологиялық хабарламаға мынадай талаптар қойылады:

а) wsa:Toтақырыбының элементі кіріс хабарламаның wsa:ReplyTo/wsa:Address элементінің мәнін қамтуға тиіс;

б) wsa:From/wsa:Address тақырыбының элементі интеграциялық шлюз операторы берген төлнұсқалықты растау сервисінің қисынды мекенжайын қамтуға тиіс;

в) егер қате туралы технологиялық хабарлама Деректермен электрондық алмасу қағидаларында көзделген типтік қателердің біреуінің туындауы туралы куәландыратын болса, soap:Code/soap:Value және soap:Subсode/soap:Value элементтеріне Деректермен электрондық алмасу қағидаларында айқындалған мәндер берілуге тиіс;

г) егер қате туралы технологиялық қате хабарлама негізі құрылымының кіріс хабарламаға қойылатын талаптарға сәйкес келмейтінін куәландыратын болса, soap:Code/soap:Value элементіне "soap:Sender" мәні берілугетиіс, soap:Subсode/soap:Value элементіне – "ttp:InvalidAppData" мәні;

д) soap:Fault/soap:Detail хабарлама негізігің элементі қамтылған негізбен және Деректермен электрондық алмасу қағидаларына сәйкес ресімделген кіріс хабарламаның тақырыптарымен бірге SOAP-конвертті қамтуға тиіс.

	Еуразиялық экономикалық одаққа мүше мемлекеттердің
	мемлекеттік билік органдарының бір-бірімен және Еуразиялық экономикалық комиссиямен трансшекаралық өзара іс- қимылы кезінде электрондық құжаттармен алмасу туралы ережеге № 6 ҚОСЫМША

Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінің интеграциялық шлюзі мен сенім білдірілген үшінші тараптың көлік деңгейіндегі сервистерінің арасында деректермен электрондық алмасудың типтік хаттамасының СИПАТТАМАСЫ

1. Осы құжат хабарламалар кезегін ұйымдастыру үшін құрал ұсынатын аралық бағдарламалық қамтылым (бұдан әрі – MQ бағдарламалық қамтылымы) арқылы сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінің интеграциялық шлюзі (Еуразиялық экономикалық одақтың интеграцияланған ақпараттық жүйесінің функционалдық мүмкіндіктерін кеңейту негізінде құрылған) мен сенім білдірілген үшінші тараптың көлік деңгейіндегі сервистерінің (бұдан әрі тиісінше – интеграцияланған жүйе, алмасуға қатысушылар) арасындағы деректермен электрондық алмасудың типтік хаттамасын сипаттайды.

2. Интеграцияланған жүйенің ұлттық сегменттерінде алмасуға қатысушылардың арасында деректермен электрондық алмасуды ұйымдастыру кезінде веб-сервистер немесе деректермен электрондық алмасуды ұйымдастырудың өзге де тәсілдері (ұқас тәсілдер) арқылы деректермен электрондық алмасуды іске асыруға рұқсат беріледі.

3. Деректермен электрондық алмасуды ұйымдастырудың балама тәсілдерін іске асыру бұл құжатпен реттелмейді. Интеграцияланған жүйенің ұлттық сегментінің шеңберінде деректермен электрондық алмасуды ұйымдастырудың балама тәсілдерін пайдалану кезінде Еуразиялық экономикалық одаққа мүше мемлекет (бұдан әрі – мүше мемлекет) интеграцияланған жүйенің интеграциялық шлюзі мен мүше мемлекеттің ұлттық сегментінің сенім білдірілген үшінші тарапының сервистері арасында деректермен электрондық алмасу хаттамасын сипаттайтын нормативтік-технологиялық құжат (құжаттар) әзірлеуді қамтамасыз етеді.

4. Алмасуға қатысушылар арасында деректер беру арнасы заңсыз енуден қорғалуға тиіс. Деректер беру арнасын қорғау тәсілдері мен тәртібі мүше мемлекеттер мен Еуразиялық экономикалық комиссияның деректермен электрондық алмасу кезінде ақпаратты қорғауға қойылатын талаптарды белгілейтін нормативтік құқықтық актілері мен техникалық құжаттарында айқындалады.

5. Осы құжатта пайдаланылатын ұғымдар келесіні білдіреді:

"API" (Application programming interface) – сыртқы бағдарламалық өнімдерде пайдалану үшін қосымша (кітапхана, сервис) ұсынатын дайын сыныптар, рәсімдер, функциялар, құрылымдар және констант жинағы;

"MIME" (Multipurpose Internet mail extensions) – мәтіндік деректер ішінде беру үшін ақпаратты кодтау мен форматтауға арналған ерекшелік;

"MQMD" (Message queuing message descriptor) – көліктік хабарламаның негізгі деректемелерін қамтитын тақырып;

"MQRFH2" –көліктік хабарламаның қосымша деректемелерін қамтитын көліктік хабарламаның тақырыбы;

"кезек менеджері"– API арқылы хабарламалар кезегінің сервистерін көрсететін бағдарламалық компонент;

"кезек" – кезек менеджері арқылы басқарылатын хабарламаларды атаулы сақтау орны;

"көліктік хабарлама"– көліктік хаттама талаптарына сәйкес ресімделген ақпарат элементтерінің жиынтығы.

6. Деректермен электрондық алмасудың типтік хаттамасын іскеасырған кезде MQ (MQI, AMI, JMS және т.б.) бағдарламалық қамтылымның қолда бар кез келгенін пайдалануға рұқсат беріледі.

Осы құжатта қызметтік құрылымдар мен MQ бағдарламалық қамтылымының константын белгілеу үшін MQI бағдарламалық интерфейсіне сәйкес келетін атау пайдаланылады. Басқа бағдарламалық интерфейстерді пайдаланған кезде құрылымдар мен констант атауы ерекшеленуі мүмкін.

7. Көлік деңгейінде алмасуға қатысушылар MQ бағдарламалық қамтылым форматында көліктік хабарламалармен алмасуды орындайды.

8. Көліктік хабарлама үшін 100 Мб шекті көлем белгіленген.

9. MQMD тақырыбының жолдарын толтыруға қойылатын талаптар кестеде берілген.

MQMD тақырыбының жолдарын толтыру

Жол атауы	Мән	Комментарий
Version	MQMD_VERSION_2	тақырыптардың тек екінші нұсқасы пайдаланылады
MsgType	MQMT_DATAGRAM	алмасу дейтаграммалармен ғана жүзеге асырылады
Expiry	144000	хабарлама жеткізу мерзімін аяқтауға шектеу – 4 сағат
Persistence	MQPER_PERSISTENT	кепілдендірілген жеткізу режимі қосылған
Report	MQRO_EXPIRATION_WITH_FULL_DATA	хабарламаныжеткізу мерзімінің аяқталуы туралы хабарлама сұралады
ReplyToQ	жауап алу кезегінің атауы	хабарламалар - сұрау салулар үшін толтырылады
eplyToQmgr	жауап алу үшін менеджер атауы	хабарламалар-сұрау салулар үшін толтырылады

Кестеде көрсетілмеген MQMD жолдарын толтырған кезде қажетіне қарай мәні болуға тиіс (MQMD_DEFAULT құрылымынан алынған мән пайдаланылады).

10. Егер көліктік хабарламалар арқылы берілген деректерMIME-хабарламалар форматында ұсынылған болса, <usr> папкасындаMQRFH2 тақырыптарының тобында қосарланған салудың болуын сәйкестендіру үшін contentType тақырыбы болуға тиіс, оның "Multipart/Related; boundary=< MIME-блок шегінің сәйкестендіргіші жолақтық мәні>" болады.

11. Егер көліктік хабарламалар арқылы берілген деректер SOAP-хабарламалар түрінде ұсынылған болса,<usr> папкасында MQRFH2 тақырыптарының тобында contentType тақырыбы болуға тиіс, оның "application/soap+xml" жол мәні болуға тиіс.

Жөнелтушінің сенім білдірілген үшінші тарапының түбіртегін толтыру ҮЛГІСІ

<ds:Signature Id="TTP.Sender.Receipt1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="[ЭЦҚ мәнін есептеу алгоритмінің сәйкестендіргіші]"/>

<ds:Reference URI="#TTP.Sender.Receipt1Manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="[хэш-соманы есептеу алгоритмінің сәйкестендіргіші]"/>

<ds:DigestValue>BjBsR09EbGhjZ0dTQUxN……NBRU1tQ1p0dU1GUXhEUzhB</ds:DigestValue>

</ds:Reference>

<ds:Reference URI="#TTP.Sender.Receipt1Details" Type="urn:EEC:TTP:v1.0:receipt:details">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="[хэш-соманы есептеу алгоритмінің сәйкестендіргіші]"/>

<ds:DigestValue>UjBsR09EbGhjZ0dTQUxNQUFB…..U1tQ1p0dU1GUXhEUzhi</ds:DigestValue>

</ds:Reference>

<ds:Reference URI="#TTP.Sender.Receipt1SignedProperties" Type="http://uri.etsi.org/01903#SignedProperties">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="[хэш-соманы есептеу алгоритмінің сәйкестендіргіші]"/>

<ds:DigestValue>UjBsR09...UxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>UjBsR09EbGhjZ..tQ1p0dU1GUXhEUzhi</ds:SignatureValue>

<ds:KeyInfo>

<ds:X509Data>

<ds:X509Certiicate>mMDVhY...11Cm4=</ds:X509Certiicate>

</ds:X509Data>

</ds:KeyInfo>

<ds:Object>

<ds:Manifest Id="TTP.Sender.Receipt1Manifest">

<ds:Reference URI="#Data">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#m"/>

</ds:Transforms>

<ds:DigestMethod Algorithm="[хэш-соманы есептеу алгоритмінің сәйкестендіргіші]"/>

<ds:DigestValue>UjBsR09EbGhjZ0dTQ…UUNBRU1tQ1p0dU1GUXhEUzhi</ds:DigestValue>

</ds:Reference>

</ds:Manifest>

<rcpt:Receipt Id="TTP.Sender.Receipt1Details" xmlns:rcpt="urn:EEC:TTP:v1.0:receipt">

<rcpt:ReceiptId>urn:uuid:9d3b13f5-3c18-4788-9117-efc3faa78272</rcpt:ReceiptId>

<rcpt:DocId>urn:uuid:062c1624-5c7e-4a9f-942c-2bba2ea983cf</rcpt:DocId>

<rcpt:Report>

<rcpt:Success Reference="#Signature1"/>

<rcpt:Error Reference="#Signature2">

<rcpt:ReasonCode>Signature.Error</rcpt:ReasonCode>

<rcpt:ReasonText>Signature/SignedInfo/DigestValue элементінде көрсетілген хэш ДТС</rcpt:ReasonText құрылған хэш мәніне сәйкес келмейді>

</rcpt:Error>

<rcpt:Success Reference="#Signature3"/>

</rcpt:Report>

</rcpt:Receipt>

<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#">

<xades:SignedProperties Id="TTP.Sender.Receipt1SignedProperties">

<xades:SignedSignatureProperties>

<xades:SigningCertificate>

<xades:Cert>

<xades:CertDigest>

<ds:DigestMethod>[хэш-соманы есептеу алгоритмінің сәйкестендіргіші]</ds:DigestMethod>

<ds:DigestValue>UjBsR0..tQ1p0dU1GUXhEUzhi</ds:DigestValue>

</xades:CertDigest>

<ds:IssuerSerial>

<ds:X509IssuerName>CN = CertCenter, O = CERT-CENTER, C = EEC, E = nfo@cn.org </ds:X509IssuerName>

<ds:X509SerialNumber>18761230</ds:X509SerialNumber>

</ds:IssuerSerial>

</xades:Cert>

</xades:SigningCertificate>

<xades:SignatureProductionPlace>

<xades:CountryName>RU</xades:CountryName>

</xades:SignatureProductionPlace>

<xades:SignerRole>

<xades:ClaimedRoles>

<xades:ClaimedRole>TTP.Sender</xades:ClaimedRole>

</xades:ClaimedRoles>

</xades:SignerRole>

</xades:SignedSignatureProperties>

</xades:SignedProperties>

<xades:UnsignedProperties>

<xades:UnsignedSignatureProperties>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<xades:EncapsulatedTimeStamp>UjBsUxNQUFBUU….UxhEUzhi</xades:EncapsulatedTimeStamp>

</SignatureTimeStamp>

</xades:UnsignedSignatureProperties>

</xades:UnsignedProperties>

</xades:QualifyingProperties>

</ds:Object>

</ds:Signature>

Электрондық цифрлық қолтаңбаны (электрондық қолтаңбаны) қалыптастыру кезінде пайдаланылатын криптографиялық алгоритмдер сәйкестендіргіштерінің ТІЗБЕСІ

URI-сәйкестендіргіш	OID-сәйкестендіргіш	Стандарт атауы
I. ЭЦҚ мәнін есептеу алгоритмдері үшін
1. http://www.w3.org/2001/04/xmldsig-more#gostr3410	1.2.398.3.10.1.1.1.2	МЕМСТ 34.310-2004 "Ақпараттық технология. Ақпаратты криптографиялық қорғау. Электрондық цифрлық қолтаңбаны қалыптастыру және тексеру процестері"
2. http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411	1.2.643.2.2.3	МЕМСТ Р 34.10-2001 "Ақпараттық технология. Ақпаратты криптографиялық қорғау. Электрондық цифрлық қолтаңбаны қалыптастыру және тексеру процестері"
3. urn:EAEU:Signature:gostr34.10-2012	1.2.643.7.1.1.1.2	МЕМСТ Р 34.10-2012 Ақпаратты криптографиялық қорғау. Электрондық цифрлық қолтаңбаны қалыптастыру және тексеру процестері"
4. urn:EAEU:Signature:bign-with-hspec	1.2.112.0.2.0.34.101.45.11	СТБ 34.101.45-2013 "Ақпараттық технологиялар және қауіпсіздік. Электрондық цифрлық қолтаңбаның және эллиптикалық қисық алгоритмдердің негізінде көлік кілтінің алгоритмдері - ұзақ уақытты өлшемдермен айқындалған хэштеу функциясы бар ЭЦҚ алгоритмі"
5. urn:EAEU:Signature:bign-with-hbelt	1.2.112.0.2.0.34.101.45.12	СТБ 34.101.45-2013 "Ақпараттық технологиялар және қауіпсіздік. Электрондық цифрлық қолтаңбаның және эллиптикалық қисық алгоритмдердің негізінде көлік кілтінің алгоритмдері - belt-hash алгоритмі берген хэштеу функциясы бар ЭЦҚ алгоритмі"
6. urn:EAEU:Signature:bign-ibs-with-hspec	1.2.112.0.2.0.34.101.45.71	СТБ 34.101.45-2013 "Ақпараттық технологиялар және қауіпсіздік. Электрондық цифрлық қолтаңбаның және эллиптикалық қисық алгоритмдердің негізінде көлік кілтінің алгоритмдері - ұзақ уақытты өлшемдермен айқындалған хэштеу функциясы бар ЭЦҚ алгоритмі"
7. urn:EAEU:Signature:bign-ibs-with-hbelt	1.2.112.0.2.0.34.101.45.72	СТБ 34.101.45-2013 "Ақпараттық технологиялар және қауіпсіздік. Электрондық цифрлық қолтаңбаның және эллиптикалық қисық алгоритмдердің негізінде көлік кілтінің алгоритмдері - belt-hash алгоритмі берген хэштеу функциясы бар ЭЦҚ алгоритмі"
II. Хэш-жиынтықты есептеу алгоритмдері үшін
1. urn:EAEU:Digest:gost34.311-95	1.2.398.3.10.1.3.1	МЕМСТ 34.311-95 "Ақпараттық технология. Ақпаратты криптографиялық қорғау. Хэштеу функциясы"
2. urn:EAEU:Digest:gostr34.11-2012	1.2.643.7.1.1.2.3	МЕМСТ Р 34.11-2012 "Ақпараттық технология. Ақпаратты криптографиялық қорғау. Хэштеу функциясы"
3. http://www.w3.org/2001/04/xmldsig-more#gostr3411	1.2.643.2.2.9	МЕМСТ Р 34.11-94 Ақпараттық технология. Ақпаратты криптографиялық қорғау. Хэштеу функциясы"
4.urn:EAEU:Digest:belt-hash256}	1.2.112.0.2.0.34.101.31.81	СТБ 34.101.31-2011 "Ақпараттық технологиялар және қауіпсіздік. Шифрлеу мен тұтастықты бақылаудың криптографиялық алгоритмдері"

Еуразиялық экономикалық
одаққа мүше мемлекеттердің
мемлекеттік билік органдарының
бір-бірімен және Еуразиялық
экономикалық комиссиямен
трансшекаралық өзара іс-қимылы
кезінде электрондық
құжаттармен алмасу туралы
ережеге
№ 9 ҚОСЫМША

Сенім білдірілген үшінші тараптың электрондық хабарламалары мен электрондық құжаттарын өңдеу кезінде туындаған және аудит журналында көрсетілетін қисынды операциялар мен оқиғалар ТІЗБЕСІ

Код	Жазбаның мәтіндік сипаттамасы	Операция (оқиға) және оған ескерту
OP1000	Хабарлама оқылды. Хабарламаның типі: <Тип>	көліктік деңгейде хабарламаны оқу орындалды. Егер хабарламада MIME-бөлік немесе "SOAP" мәні бар болса, егер хабарламада MIME-бөлік жоқ болса, <Тип> жолында "MIME" мәні көрсетіледі
OP1100	Электрондық хабарлама өңдеуге қабылданды. Хабарлама тақырыптары: wsa:To: <тақырыптың мәніwsa:To>; wsa:ReplyTo: <тақырыптың мәні wsa:ReplyTo>; wsa:Action: < тақырыптың мәніwsa:Action>; wsa:MessageID:<тақырыптың мәніwsa:MessageID>	Хабарлама тақырыптарының блогын талдау орындалды, сондай-ақ хабарламада қамтылған хабарламаның (soap:Body) блогы бары айқындалды. <тақырыптың мәні...> типінің жолында SOAP-хабарламаның тиісті тақырыптарының мәндері көрсетіледі
OP1200	Электрондық құжат өңдеуге қабылданды. Хабарламаның сәйкестендіргіші:< тақырыптың мәніwsa:MessageID>; электрондық құжаттың сәйкестендіргіші: <DocInstance>	қамтылған хабарлама блогынан алынған электрондық құжатты есептеу орындалды және оның жолдарын талдау жүргізілді. <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі
OPS5100	ЭЦҚ куәландырылған деректердің тұтастығы хэш бойынша тексерілді. Электрондық құжаттың сәйкестендіргіші: <DocInstance>; ЭЦҚ сәйкестендіргіші: <IDқолтаңбалар>	жөнелтушінің сенім білдірілген үшінші тарапы ғана орындайды. ЭЦҚ құрамында көрсетілген хэш мәндері мен ЭЦҚ-да көрсетілген мәліметтердің негізінде сенім білдірілген үшінші тарап қалыптастырған хэш мәндерін салыстырып тексеру орындалды. <DocInstance>жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. <ID қолтаңбалар>жолында ds:Signature/@Id ЭЦҚ сәйкестендіргіші көрсетіледі
OPS5200	ЭЦҚ мәні тексерілді. Электрондық құжаттың сәйкестендіргіші: <DocInstance>; ЭЦҚ сәйкестендіргіші:<ID қолтаңбалар>	жөнелтушінің сенім білдірілген үшінші тарапы ғана орындайды. ЭЦҚ мәні жабық (жеке) кілтті пайдаланып жасалғанын тексеру орындалды, оның ашық кілтінің тиісті сертификаты (ЭЦҚ-ны тексеру кілтінің сертификаты) осы ЭЦҚ құрамында көрсетілген. <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. <ID қолтаңбалар>жолында ds:Signature/@Id ЭЦҚ сәйкестендіргіші көрсетіледі
OPS5300	Сертификат тексерілді. Электрондық құжаттың сәйкестендіргіші:<DocInstance>; ЭЦҚ сәйкестендіргіші: <ID қолтаңбалар>	жөнелтушінің сенім білдірілген үшінші тарапы ғана орындайды. ЭЦҚ-ны тексеру кілті сертификатының және сертификаттар тізбегінен куәландырушы орталықтың әрбір сертифкатының электрондық құжатқа қол қою кезінде жарамдылығын тексеру орындалды. <DocInstance>жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. <ID қолтаңбалар> жолында ds:Signature/@Id ЭЦҚ сәйкестендіргіші көрсетіледі
OPR5100	Жөнелтушінің ДТС түбіртегімен куәландырылған электрондық құжаттың, сондай-ақ түбіртектің ЭЦҚ құрамында көрсетілген деректер блоктарының тұтастығы тексерілді. Электрондық құжаттың сәйкестендіргіші: <DocInstance>; жөнелтушінің ДТС түбіртегінің сәйкестендіргіші: <ReceiptId>	жөнелтушінің сенім білдірілген үшінші тарапы ғана орындайды. Түбіртекте қамтылған блоктар хэштерінің мәндеріне байланысты қамтылған электрондық құжаттың блогын қоса алғанда, деректердің барлық блоктарының тұтастығы тексерілді. <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. <ReceiptId>жолында жөнелтушінің сенім білдірілген үшінші тарапы түбіртегінің бірегей сәйкестендіргіші(rcpt:ReceiptId элементінің мәні)көрсетіледі
OPR5200	Жөнелтушінің ДТС түбіртегінің ЭЦҚ мәні тексерілді. Электрондық құжаттың сәйкестендіргіші: <DocInstance>	алушының сенім білдірілген үшінші тарапы ғана орындайды. ЭЦҚ мәні жабық (жеке) кілтті пайдаланып жасалғанын тексеру орындалды, оның ашық кілтінің тиісті сертификаты (ЭЦҚ-ны тексеру кілтінің сертификаты) осы ЭЦҚ құрамында көрсетілген.<DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі.<ID қолтаңбалар> жолында ds:Signature/@Id ЭЦҚ сәйкестендіргіші көрсетіледі
OPR5300	Түбіртек сертификаты тексерілді. Электрондық құжаттың сәйкестендіргіші:<DocInstance>	алушының сенім білдірілген үшінші тарапы ғана орындайды. Жөнелтушінің сенім білдірілген үшінші тарапының ЭЦҚ-ны тексеру кілтінің сертификатын сенім білдірілген үшін тараптың куәландырушы орталығы дайындағаны, жөнелтушінің сенім білдірілген үшінші тарапының түбіртегіне қол қою кезінде жарамдылығы, сондай-ақ сенім білдірілген үшін тараптың куәландырушы орталығының ЭЦҚ-ны тексеру кілтінің сертификаты жөнелтушінің сенім білдірілген үшінші тарапының түбіртегіне қол қою кезінде жарамдылығы тексерілді. <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі.
OP10000	ДТС түбіртегі қалыптастырылды. Электрондық құжаттың сәйкестендіргіші: <DocInstance>;түбіртектің сәйкестендіргіші: <ReceiptId>	түбіртек құрылымын қалыптастыру орындалды, түбіртектің барлық жолы дұрыс толтырылды.<DocInstance>жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі.<ReceiptId> жолында түбіртектің бірегей сәйкестендіргіш (rcpt:ReceiptId элементінің мәні) көрсетіледі.
OP10100	ДТС түбіртегі электрондық құжаттың құрылымына енгізілді. Электрондық құжаттың сәйкестендіргіші: <DocInstance>; түбіртектің сәйкестендіргіші: <ReceiptId>	сенім білдірілген үшінші тараптың түбіртегі электрондық құжаттың XML-құрылымына енгізілді. <DocInstance>жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. <ReceiptId>жолында түбіртектің бірегей сәйкестендіргіші( rcpt:ReceiptId элементінің мәні)көрсетіледі
OP10200	Интеграциялық шлюзге арналған жауап хабарлама қалыптастырылды.Электрондық құжаттың сәйкестендіргіші: <DocInstance>. Хабарлама тақырыптары: wsa:To: <тақырыптың мәніwsa:To>; wsa:From: <тақырыптың мәніwsa:From>; wsa:Action: <тақырыптың мәніwsa:Action>; wsa:MessageID: <тақырыптың мәніwsa:MessageID>; wsa:RelatesTo: <тақырыптың мәніwsa: RelatesTo>	интеграциялық шлюз үшін салынған түбіртек бар электрондық құжатты қамтитын жауап хабарлама қалыптастырылды.<DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. <тақырыптың мәні...> типінің жолында SOAP-хабарламалардың тиісті тақырыптарының мәндері көрсетіледі
OP10300	Қате туралы технологиялық хабарлама қалыптастырылды. Электрондық құжаттың сәйкестендіргіші: <DocInstance>. Хабарлама тақырыптары: wsa:To: <тақырыптың мәні wsa:To>; wsa:From: <тақырыптың мәні wsa:From>; wsa:Action: <тақырыптың мәні wsa:Action>; wsa:MessageID: <тақырыптың мәні wsa:MessageID>; wsa:RelatesTo: <тақырыптың мәні wsa: RelatesTo>	қате туралы технологиялық хабарлама қалыптастырылды. Егер қате туралы технологиялық хабарлама құжат (ОP1200)өңдеуге қабылданғаннан кейін орындалатын операция туралы куәландыратын болса, <DocInstance>жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі, керісінше <тақырыптың мәні…> типінің жолдарында жауап SOAP-хабарламаның тиісті тақырыптары көрсетіледі
OP10400	Интеграциялық шлюзге арналған хабарлама табысты жіберілді. Электрондық құжаттың сәйкестендіргіші: <DocInstance>. Хабарламаның сәйкестендіргішіwsa:MessageID: <тақырыптың мәні wsa:MessageID>	электрондық құжат пен түбіртек не қате туралы технологиялық хабарлама бар жауап хабарлама интеграциялық шлюзге табысты жіберілді. <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі.<тақырыптық мәні wsa:MessageID> жолында SOAP-хабарламаның тақырыптың мәні wsa:MessageID көрсетіледі
ERR1000	Көліктік хабарламаның типін айқындау мүмкін болмады	көліктік хабарламаны (OP1000) оқу кезінде деректер ұсыну форматын айқындау мүмкін болмады
ERR1100	SOAP форматында хабарламаны талдау мүмкін болмады. <Себеп>. Хабарламаның бірегей сәйкестендіргішіwsa:MessageID: <тақырыптыңмәні wsa:MessageID>	SOAP (OP1100) форматында хабарламаны талдауды орындау кезінде қате пайда болды. Егер қатенің себебін айқындау мүмкін болса<Себеп> жолында қате себебінің мәтіндік сипаттамасы көрсетіледі: қате туралы XML парсерінің хабарламасы, Еуразиялық экономикалық комиссия Алқасының 2015 жылғы 27 қаңтардағы № 5 шешімімен бекітілген Сыртқы және өзара сауданың интеграцияланған ақпараттық жүйесінде деректермен электрондық алмасу қағидаларына сәйкесSOAP форматында хабарламаның талап етілген тақырыптарының болмауы туралы хабарлама. Егер хабарламаны талдау процесінде оны оқу мүмкін болмаса, <тақырыптың мәні wsa:MessageID>жолында хабарламаның тиісті тақырыбының мәні көрсетіледі.
ERR1200	Электрондық құжаттың құрылымын өңдеу қатесі. <Себеп>. Хабарламаның бірегей сәйкестендіргіші wsa:MessageID: <тақырыптың мәні wsa:MessageID>	Электрондық құжатты өңдеу кезінде оның құрылымы белгіленген талаптарға сәйкес келмейтіні анықталды. Егер қатенің себебін айқындау мүмкін болса, <Себеп> жолында мәтіндік сипаттама көрсетіледі: қате туралы XML парсерінің хабарламасы, электрондық құжаттың атрибуттары мен элементтерін дұрыс емес толтыру туралы мәліметтер. <тақырыптың мәні wsa:MessageID>жолында хабарламаның тиісті тақырыбының мәні көрсетіледі.
ERR1300	Құжаттың ЭЦҚ-ны тексеру қатесі. <Себеп>. Электрондық құжаттың сәйкестендіргіші: <DocInstance>; ЭЦҚ сәйкестендіргіші: <ID қолтаңбалар>	Электрондық құжаттың ЭЦҚ-ны тексеру кезінде қате пайда болды. Егер қатенің себебін айқындау мүмкін болса, <Себеп>жолында сенім білдірілген үшінші тарап қалыптастырған хэшке ЭЦҚ құрамында көрсетілген хэштің сәйкессіздігі;ЭЦҚ-ны тексеру кілтінің жарамсыз сертификаты; куәландырушы орталықтардың қол қою кезінде жарамсыз болған сертификаттарының бірі; XadES стандартының талаптарына сәйкес ЭЦҚ элементтері мен атрибуттарын тексеру қателері (егер ЭЦҚ XadES стандартына сәйкес қалыптастырылған болса) көрсетіледі. <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. Жөнелтушінің сенім білдірілген үшінші тарапы <ID қолтаңбалар> жолында алушының сенім білдірілген үшін тарапының ЭЦҚ – түбіртек сәйкестендіргішін көрсетеді.
ERR1400	Түбіртекті тексеру қатесі. <Себеп>. Электрондық құжаттың сәйкестендіргіші: <DocInstance>; түбіртектің сәйкестендіргіші: <ReceiptId>	Түбіртектің ЭЦҚ қоса алғанда, түбіртекті тексеру кезінде қате пайда болды.<Себеп> жолында қате себебінің мәтіндік сипаттамасы көрсетіледі: сенім білдірілген үшінші тарап қалыптастырған хэшке ЭЦҚ құрамында көрсетілген хэштің сәйкессіздігі; ЭЦҚ мәнін тексеру қатесі, жөнелтушінің сенім білдірілген үшінші тарапының немесе сенім білдірілген үшінші тараптың куәландырушы орталығының ЭЦҚ-ны тексеру кілтінің жарамсыз сертификаты, түбіртектегі уақытты көрсететін мөртабан тексеру қателері көрсетіледі. <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі. <ReceiptId> жолында жөнелтушінің сенім білдірілген үшінші тарапы түбіртегінің бірегей сәйкестендіргіші ( rcpt:ReceiptId элементінің мәні) көрсетіледі
ERR1500	Уақытты көрсететін мөртабанның сервисіне жүгіну қатесі. <Себеп>. Электрондық құжаттың сәйкестендіргіші:<DocInstance>	Түбіртекті қалыптастыру кезінде уақытты көрсететін мөртабанның сервисіне жіберуде қате пайда болды. <Себеп> жолында қате себебінің мәтіндік сипаттамасы көрсетіледі: сервис қол жетімсіз, сервис жауап ретінде қате жіберді (қатенің кодын көрсете отырып). <DocInstance> жолында электрондық құжаттың бірегей сәйкестендіргіші көрсетіледі.
ERR1600	Интеграциялық шлюзге арналған хабарламаны жөнелту мүмкін болмады. <Себеп>. Хабарламаның бірегей сәйкестендіргішіwsa:MessageID: <тақырыптың мәні wsa:MessageID>	Жөнелтуге әрекет жасау кезінде қате пайда болды. <Себеп> жолында қате себебінің мәтіндік сипаттамасы көрсетіледі: хабарламаны кезекке қою мүмкін болмады, сенім білдірілген үшінші тараптың көліктік кіші жүйесі немесе көліктік адаптері қол жетімсіз.<тақырыптың мәні wsa:MessageID>жолында хабарламаның тиісті тақырыбының мәні көрсетіледі.

Ескертулер:

1. Журналдағы әрбір жазба кем дегенде мынадай жолдарды қамтуға тиіс:

қисынды операцияның (оқиғаның) коды;

қисынды операцияны (оқиғаны) тіркеу күні мен уақыты;

орындалған қисынды операцияның (оқиғаның) мәтіндік сипаттамасы.

2. Аудит журналында қисынды операциялар мен оқиғалардың тізбесін және журналдағы жазбалардың сипаттамасын қоса алғанда, мәліметтердің жазбаларын бөлу дәрежесін өзгертуге жол беріледі.

      В соответствии с пунктами 3, 4 и 30 Протокола об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение № 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года) Коллегия Евразийской экономической комиссии решила:
      1. Утвердить прилагаемое Положение об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией.
      2. Государствам – членам Евразийского экономического союза обеспечить закрепление в своем законодательстве возможности обмена электронными документами между используемыми государствами-членами системами электронного документооборота при взаимодействии органов государственной власти государств-членов между собой и с Евразийской экономической комиссией с использованием интегрированной информационной системы Евразийского экономического союза.
      3. Настоящее Решение вступает в силу по истечении 30 календарных дней с даты его официального опубликования.

Председатель Коллегии
Евразийской экономической комиссии В. Христенко

УТВЕРЖДЕНО
Решением Коллегии Евразийской
экономической комиссии
от 28 сентября 2015 года № 125

ПОЛОЖЕНИЕ
об обмене электронными документами при трансграничном
взаимодействии органов государственной власти
государств – членов Евразийского экономического союза
между собой и с Евразийской экономической комиссией

I. Общие положения

      1. Настоящее Положение устанавливает порядок обмена электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза (далее соответственно – государства-члены, Союз) между собой и с Евразийской экономической комиссией (далее – Комиссия) в интегрированной информационной системе внешней и взаимной торговли и создаваемой на основе расширения ее функциональных возможностей интегрированной информационной системе Союза (далее – интегрированная система) в целях обеспечения обмена юридически значимыми электронными документами в рамках интегрированной системы, а также определяет состав участников обмена электронными документами, общие требования к электронным документам, требования к подписанию электронного документа электронной цифровой подписью (электронной подписью) и ответственность участников обмена электронными документами.
      2. Понятия, используемые в настоящем Положении, означают следующее:
      «XML» – рекомендованный Консорциумом Всемирной паутины (W3C) расширяемый язык разметки;
      «XML-документ» – совокупность данных, соответствующая требованиям XML;
      «каноникализация XML» – процесс преобразования XML-документов в каноническую форму XML;
      «квитанция доверенной третьей стороны» – электронный документ, формируемый доверенной третьей стороной и подписанный электронной цифровой подписью (электронной подписью) доверенной третьей стороны, служащий для подтверждения результата проверки подлинности электронного документа и электронной цифровой подписи (электронной подписи) в электронном документе;
      «криптографический стандарт» – совокупность технических спецификаций, устанавливающих правила формирования и проверки электронных цифровых подписей (электронных подписей);
      «отправитель» – участник обмена электронными документами, который направляет или от имени которого направляется электронный документ;
      «получатель» – участник обмена электронными документами, которому отправлен электронный документ;
      «сегмент отправителя», «сегмент получателя» – национальный сегмент государства-члена или интеграционный сегмент Комиссии, информационные системы которых используются для отправки (приема) электронных документов отправителем (получателем);
      «сертификат ключа проверки ЭЦП», «сертификат» – электронный документ, изданный удостоверяющим центром, подписанный закрытым (личным) ключом удостоверяющего центра и содержащий информацию, подтверждающую принадлежность указанного в сертификате открытого ключа определенному участнику обмена электронными документами, и иную информацию, предусмотренную соответствующими криптографическими стандартами;
      «служба доверенной третьей стороны интегрированной
системы» – совокупность сервисов доверенной третьей стороны государств-членов и Комиссии, обеспечивающих единое трансграничное пространство доверия при обмене электронными документами в интегрированной системе;
      «сообщение» – формализованная информация, передающаяся от отправителя к получателю в интегрированной системе;
      «стандарт X.509» – стандарт ITU-T Х.509 «Информационные технологии. Взаимосвязь открытых систем. Справочник: Структуры сертификатов открытых ключей и атрибутов»;
      «стандарт XAdES» – стандарт XML Advanced Electronic Signature, описывающий расширенный формат электронной цифровой подписи (электронной подписи) в формате XML;
      «стандарт XMLDSig» – стандарт синтаксиса и обработки электронной цифровой подписи (электронной подписи) в формате XML;
      «удостоверяющий центр» – уполномоченный орган или организация, обеспечивающие в соответствии с актами Комиссии, законодательством государства-члена предоставление услуг по изданию, распространению, хранению сертификатов ключей проверки ЭЦП и проверки действительности этих сертификатов;
      «электронная цифровая подпись (электронная подпись)», «ЭЦП» – информация в электронном виде, которая присоединена к другой информации в электронном виде или иным образом связана с такой информацией, служит для контроля целостности и подлинности этой информации, обеспечивает невозможность отказа от авторства, вырабатывается путем применения в отношении данной информации криптографического преобразования с использованием закрытого (личного) ключа и проверяется с использованием открытого ключа;
      «юридическая значимость электронного документа» – свойство электронного документа, позволяющее воспринимать содержание данного электронного документа как подлинное.
      Иные понятия, используемые в настоящем Положении, применяются в значениях, определенных Протоколом об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение № 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года) (далее – Протокол).
      3. Отношения, возникающие в связи с обменом электронными документами, регулируются Договором о Евразийском экономическом союзе от 29 мая 2014 года, иными международными договорами, входящими в право Союза, настоящим Положением, утверждаемыми Комиссией технологическими документами, регламентирующими информационное взаимодействие при реализации средствами интегрированной системы общих процессов в рамках Союза (далее – технологические документы, регламентирующие информационное взаимодействие), а также законодательством государств-членов.
      4. Технологические документы, регламентирующие информационное взаимодействие, разрабатываются в соответствии с Решением Коллегии Евразийской экономической комиссии от 6 ноября 2014 г. № 200.
      5. Требования к оформлению электронных документов определены согласно приложениям № 1 – 4.
      Электронные документы, оформленные в соответствии с настоящим Положением, с учетом требований, определенных приложениями № 1 – 4 к настоящему Положению, признаются равнозначными документам, оформленным на бумажном носителе и заверенным подписью или подписью и печатью.

II. Участники обмена электронными документами

      6. Участниками обмена электронными документами в рамках интегрированной системы являются:
      а) Комиссия;
      б) уполномоченные органы или определенные (аккредитованные) ими организации;
      в) третьи стороны государств-членов и Комиссии;
      г) удостоверяющие центры государств-членов и Комиссии, удостоверяющий центр службы доверенной третьей стороны интегрированной системы;
      д) организации – операторы интеграционных шлюзов национальных сегментов государств-членов и интеграционного сегмента Комиссии;
      е) должностные лица и сотрудники Комиссии, доверенных третьих сторон, уполномоченных органов или определенных (аккредитованных) ими организаций, а также удостоверяющих центров государств-членов и Комиссии, которые участвуют в обмене электронными документами от своего имени.
      7. Определение состава участников обмена электронными документами осуществляется:
      а) государствами-членами – в отношении уполномоченных органов, доверенной третьей стороны, удостоверяющих центров, организации – оператора интеграционного шлюза национального сегмента этого государства-члена;
      б) уполномоченными органами или определенными (аккредитованными) ими организациями – в отношении должностных лиц и сотрудников этих уполномоченных органов или организаций;
      в) Комиссией – в отношении доверенной третьей стороны Комиссии, удостоверяющего центра Комиссии, удостоверяющего центра службы доверенной третьей стороны интегрированной системы, должностных лиц этих органов, а также в отношении должностных лиц и сотрудников Комиссии.
      8. Участниками обмена электронными документами осуществляются следующие функции:
      а) отправителем – подготовка электронного документа, его подписание ЭЦП и отправка получателю;
      б) получателем – прием и обработка полученных от отправителя электронного документа и квитанции доверенной третьей стороны получателя для проверки подлинности электронного документа отправителя;
      в) организациями – операторами интеграционных шлюзов интегрированной системы – обеспечение трансграничной передачи электронных документов, а также проверка квитанций доверенных третьих сторон в целях недопущения передачи неподлинных электронных документов, которые заведомо не должны или не могут быть обработаны получателем;
      г) доверенной третьей стороной отправителя – проверка подлинности электронного документа и ЭЦП электронного документа, формирование и подписание квитанции доверенной третьей стороны отправителя с результатом проверки;
      д) доверенной третьей стороной получателя – проверка подлинности электронного документа в соответствии с квитанцией доверенной третьей стороны отправителя и ЭЦП в этой квитанции, формирование и подписание квитанции доверенной третьей стороны получателя с результатом проверки;
      е) удостоверяющим центром государства-члена и удостоверяющим центром Комиссии – выдача сертификатов, предоставление сервисов для проверки актуальности сертификатов, выданных в пределах своей компетенции, сервисов для проверки полномочий (правовых статусов) владельцев сертификатов, используемых при проверке ЭЦП посредством доверенной третьей стороны отправителя, а также сервиса штампа времени;
      ж) удостоверяющим центром службы доверенной третьей стороны – выдача сертификатов доверенным третьим сторонам государств-членов, предоставление сервисов для проверки актуальности выданных сертификатов и сервиса штампа времени.
      9. Участники обмена электронными документами обязаны:
      а) соблюдать настоящее Положение в процессе обмена электронными документами;
      б) информировать друг друга обо всех случаях возникновения технических неисправностей в работе программно-аппаратных средств или о других обстоятельствах, препятствующих обмену электронными документами;
      в) при возникновении конфликтных ситуаций участвовать в их разрешении;
      г) обеспечивать защиту информации при обмене электронными документами в соответствии с требованиями актов Комиссии и законодательства государств-членов;
      д) использовать средства ЭЦП, имеющие сертификаты соответствия, выданные согласно законодательству соответствующего государства-члена.
      10. Требования к участникам обмена электронными документами при необходимости могут уточняться после утверждения Комиссией требований к созданию, развитию и функционированию трансграничного пространства доверия, предусмотренных пунктом 18 Протокола, а актуализация настоящего Положения будет проводиться после принятия локализованных версий необходимых международных стандартов и рекомендаций, а также утверждения Комиссией правил документирования информации при взаимодействии между уполномоченными органами, хозяйствующими субъектами и физическими лицами государств-членов.

III. Обмен электронными документами

1. Требования к криптографическим стандартам при
обмене электронными документами

      11. При обмене электронными документами участниками такого обмена используются следующие криптографические стандарты:
      а) при взаимодействии между отправителями (получателями) и доверенной третьей стороной в рамках одного национального сегмента государства-члена – криптографические стандарты этого государства-члена;
      б) при взаимодействии между отправителями (получателями) и доверенной третьей стороной в рамках интеграционного сегмента Комиссии – криптографический стандарт, утверждаемый для этих целей Комиссией.
      12. При взаимодействии сервисов службы доверенной третьей стороны интегрированной системы между собой используются согласованный криптографический стандарт ЭЦП и согласованный криптографический стандарт функции хэширования (стандарты службы доверенной третьей стороны интегрированной системы), утверждаемые для этих целей Комиссией.

2. Порядок обмена электронными документами

      13. Обмен электронными документами при реализации общих процессов в рамках Союза (далее – общие процессы) выполняется в соответствии с технологическими документами, регламентирующими информационное взаимодействие, а также в соответствии с Правилами электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденными Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5 (далее – Правила электронного обмена данными).
      14. Оформление электронных документов, предусмотренных технологическими документами, регламентирующими информационное взаимодействие, в соответствии с требованиями, определенными приложением № 1 к настоящему Положению, выполняется на основании значения параметра «признак ЭЦП» (принимает значение «да» или «нет»), указанного для каждой транзакции общего процесса в регламенте информационного взаимодействия между участниками общего процесса при реализации средствами интегрированной системы общего процесса.
      В случае если параметр принимает значение «да», то данные, передаваемые в рамках транзакций общих процессов, оформляются в виде электронных документов. Данные, передаваемые посредством сигналов-исключений, сигналов-подтверждений и служебных сообщений, не оформляются в виде электронных документов, если иное не определено технологическими документами, регламентирующими информационное взаимодействие, или актами, входящими в право Союза.
      В случае если параметр принимает значение «нет», требования настоящего Положения к электронному обмену данными в рамках транзакции общего процесса не применяются.
      15. В процессе обмена электронными документами интеграционные шлюзы и сервисы доверенных третьих сторон в пределах национального сегмента государства-члена (интеграционного сегмента Комиссии) обмениваются сообщениями, составленными в соответствии с описанием согласно приложению № 5 и передаваемыми посредством протокола электронного обмена данными в соответствии с описанием согласно приложению № 6.
      16. Отправителем выполняются следующие действия:
      а) формируется и подписывается электронный документ;
      б) оформляется электронный документ в виде сообщения;
      в) отправляется сообщение для получателя в интеграционный шлюз отправителя.
      17. Интеграционным шлюзом отправителя принимается сообщение от отправителя и формируется новое сообщение для доверенной третьей стороны отправителя, в которое вкладывается полученный электронный документ. Интеграционным шлюзом отправителя сформированное сообщение передается доверенной третьей стороне отправителя.
      18. Доверенной третьей стороной отправителя принимается поступившее от интеграционного шлюза отправителя сообщение и для каждой ЭЦП в электронном документе проверяется соблюдение следующих требований в совокупности:
      а) целостность данных, подписываемых ЭЦП, не нарушена;
      б) ЭЦП выработана с использованием закрытого (личного) ключа, соответствующий сертификат открытого ключа которого (сертификат ключа проверки ЭЦП) указан в составе этой ЭЦП;
      в) сертификат ключа проверки ЭЦП действителен на момент подписания электронного документа;
      г) каждый сертификат удостоверяющего центра из цепочки сертификатов действителен на момент подписания.
      19. По результатам проверки электронного документа доверенной третьей стороной отправителя формируется квитанция доверенной третьей стороны отправителя в соответствии с требованиями, определенными приложением № 3 к настоящему Положению, и образцом согласно приложению № 7. Квитанция доверенной третьей стороны отправителя подписывается ЭЦП доверенной третьей стороны отправителя в соответствии с криптографическим стандартом службы доверенной третьей стороны интегрированной системы. Для идентификации криптографического стандарта службы доверенной третьей стороны в структуре квитанции используются идентификаторы алгоритмов по перечню согласно приложению № 8.
      20. Временем отправления электронного документа является время подписания доверенной третьей стороной отправителя квитанции доверенной третьей стороны отправителя своей ЭЦП с соответствующим штампом времени в самой квитанции.
      21. Доверенной третьей стороной отправителя формируется сообщение для интеграционного шлюза отправителя, в которое вкладываются электронный документ и квитанция доверенной третьей стороны отправителя, и передается в интеграционный шлюз отправителя.
      22. Интеграционным шлюзом отправителя принимается сообщение от доверенной третьей стороны отправителя.
      23. В случае если квитанция доверенной третьей стороны отправителя свидетельствует об отрицательном результате проверки подлинности электронного документа или ЭЦП в электронном документе, то интеграционным шлюзом отправителя формируется сообщение об ошибке по причине отрицательного результата проверки ЭЦП, которое направляется отправителю.
      В случае если сообщение об ошибке формируется интеграционным шлюзом интеграционного сегмента Комиссии, оно должно представлять собой технологическое сообщение об ошибке с кодом «int:ReceiptError» в соответствии с Правилами электронного обмена данными.
      В случае если сообщение об ошибке формируется интеграционным шлюзом национального сегмента государства-члена, требования к структуре сообщения об ошибке определяются государством-членом.
      24. В случае если квитанция доверенной третьей стороны отправителя свидетельствует о положительном результате проверки подлинности электронного документа и ЭЦП в электронном документе, то интеграционным шлюзом отправителя выполняются следующие действия:
      а) вложение электронного документа и квитанции доверенной третьей стороны отправителя в сообщение, блок заголовков которого соответствует блоку заголовков сообщения, полученного интеграционным шлюзом отправителя в соответствии с пунктом 17 настоящего Положения;
      б) передача сообщения в интеграционный шлюз получателя.
      25. Интеграционным шлюзом получателя принимается от интеграционного шлюза отправителя сообщение и формируется новое сообщение для доверенной третьей стороны получателя, в которое вкладываются полученный электронный документ и квитанция доверенной третьей стороны отправителя. Сформированное сообщение передается интеграционным шлюзом получателя доверенной третьей стороне получателя.
      26. Доверенной третьей стороной получателя принимается поступившее от интеграционного шлюза получателя сообщение и проверяется соблюдение следующих требований в совокупности:
      а) в сообщение вложена квитанция доверенной третьей стороны отправителя;
      б) целостность электронного документа, на который сформирована квитанция доверенной третьей стороны отправителя, не нарушена;
      в) квитанция подписана ЭЦП доверенной третьей стороны отправителя, выработанной с использованием закрытого (личного) ключа доверенной третьей стороны отправителя, соответствующий сертификат открытого ключа которого (сертификат ключа проверки ЭЦП) указан в составе этой ЭЦП;
      г) сертификат ключа проверки ЭЦП доверенной третьей стороны отправителя изготовлен удостоверяющим центром службы доверенной третьей стороны интегрированной системы и действителен на момент подписания квитанции доверенной третьей стороны отправителя;
      д) сертификат ключа проверки ЭЦП удостоверяющего центра службы доверенной третьей стороны интегрированной системы действителен на момент подписания квитанции доверенной третьей стороны отправителя;
      е) тквитанция доверенной третьей стороны отправителя свидетельствует о положительном результате проверки подлинности электронного документа и ЭЦП в электронном документе.
      27. По результатам проверки электронного документа и квитанции доверенной третьей стороны отправителя формируется квитанция доверенной третьей стороны получателя, которая подписывается ЭЦП в соответствии с криптографическим стандартом юрисдикции получателя. Квитанция доверенной третьей стороны отправителя включается в состав квитанции доверенной третьей стороны получателя. Обработка доверенной третьей стороной получателя квитанции доверенной третьей стороны отправителя и формирование квитанции для получателя осуществляются в соответствии с требованиями, определенными приложением № 3 к настоящему Положению. Для идентификации криптографического стандарта юрисдикции получателя электронного документа, в структуре квитанции используются идентификаторы алгоритмов, предусмотренные приложением № 8 к настоящему Положению.
      28. Временем получения электронного документа является время подписания доверенной третьей стороной получателя квитанции доверенной третьей стороны получателя своей ЭЦП с соответствующим штампом времени в самой квитанции.
      29. Доверенной третьей стороной получателя формируется сообщение, в которое вкладываются электронный документ и квитанция доверенной третьей стороны получателя, и передается в интеграционный шлюз получателя.
      30. Интеграционным шлюзом получателя принимается сообщение от доверенной третьей стороны получателя.
      31. В случае если квитанция доверенной третьей стороны получателя свидетельствует об отрицательном результате проверки подлинности электронного документа или ЭЦП в квитанции доверенной третьей стороны отправителя, то интеграционным шлюзом получателя формируется технологическое сообщение об ошибке с кодом «int:ReceiptError» в соответствии с Правилами электронного обмена данными, которое направляется отправителю.
      32. В случае если квитанция доверенной третьей стороны получателя свидетельствует о положительном результате проверки подлинности электронного документа и ЭЦП в квитанции доверенной третьей стороны отправителя, то интеграционным шлюзом получателя выполняются следующие действия:
      а) вложение электронного документа и квитанции доверенной третьей стороны получателя в сообщение, блок заголовков которого соответствует блоку заголовков сообщения, полученного от интеграционного шлюза отправителя в соответствии с пунктом 25 настоящего Положения;
      б) передача сообщения получателю.
      33. Получателем принимается поступившее от интеграционного шлюза получателя сообщение и проверяется соблюдение следующих требований в совокупности:
      а) в сообщение вложена квитанция доверенной третьей стороны получателя;
      б) целостность электронного документа, на который сформирована квитанция доверенной третьей стороны получателя, не нарушена;
      в) ЭЦП в квитанции доверенной третьей стороны получателя выработана с использованием закрытого (личного) ключа доверенной третьей стороны получателя, соответствующий сертификат открытого ключа которого (сертификат ключа проверки ЭЦП) указан в составе этой ЭЦП;
      г) сертификат ключа проверки ЭЦП доверенной третьей стороны получателя действителен на момент подписания квитанции;
      д) квитанция доверенной третьей стороны получателя свидетельствует о положительном результате проверки подлинности электронного документа.
      34. Решение об обработке электронного документа принимается получателем, если подтверждено соблюдение всех требований, предусмотренных пунктом 33 настоящего Положения. В ином случае принимается решение об отказе в обработке электронного документа.
      35. В случае если получателем принято решение об отказе в обработке электронного документа, он уведомляет об этом отправителя путем направления отправителю сигнала-исключения «Ошибка» с кодом «Signature:Error», сформированного в соответствии с Правилами электронного обмена данными.

3. Разрешение нештатных ситуаций, возникающих при
обмене электронными документами

      36. Нештатной признается ситуация, возникающая при обмене электронными документами, при которой обработка данных по причине технических сбоев, несоответствия структуры электронных документов или сообщений установленным правилам либо по другим основаниям не может быть произведена в установленном порядке.
      37. Разрешением нештатных ситуаций занимаются технические подразделения доверенных третьих сторон и организаций – операторов интеграционных шлюзов.
      38. В каждом сегменте интегрированной системы создаются свои технические подразделения, обеспечивающие разрешение нештатных ситуаций.
      39. Доверенная третья сторона оформляет и направляет в интеграционный шлюз своего сегмента технологическое сообщение об ошибке в том случае, если при обработке входящего сообщения возникла любая из следующих критических ошибок, не позволяющих обработать входящее сообщение в штатном режиме:
      а) несоответствие формата и структуры сообщения требованиям, определенным приложением № 5 к настоящему Положению;
      б) несоответствие формата и структуры электронного документа, вложенного в сообщение, требованиям, определенным приложением № 1 к настоящему Положению, и схеме данных, предусмотренной приложением № 2 к настоящему Положению;
      в) несоответствие формата и структуры квитанции доверенной третьей стороны отправителя, вложенной в сообщение, требованиям, определенным приложением № 3 к настоящему Положению;
      г) ошибки, возникшие в процессе обработки сообщения или входящих в состав сообщения структур данных.
      40. Формирование технологических сообщений об ошибке осуществляется в соответствии с приложением № 5 к настоящему Положению.
      41. При получении от доверенной третьей стороны технологического сообщения об ошибке интеграционным шлюзом формируется и направляется в адрес отправителя сообщение об ошибке, свидетельствующее о невозможности дальнейшей передачи электронного документа получателю.
      42. К формату и структуре указанного в пункте 41 настоящего Положения сообщения об ошибке предъявляются следующие требования:
      а) в случае если сообщение об ошибке формируется интеграционным шлюзом получателя, оно должно представлять собой технологическое сообщение об ошибке с кодом «int:InternalError» в соответствии с Правилами электронного обмена данными;
      б) в случае если сообщение об ошибке формируется интеграционным шлюзом отправителя, требования к формату и структуре сообщения об ошибке определяются государством-членом.
      43. В рамках функционирования интегрированной системы организуется взаимодействие между техническими подразделениями доверенных третьих сторон и организаций – операторов интеграционных шлюзов.
      44. В целях разрешения нештатных ситуаций каждой доверенной третьей стороной ведется журнал аудита, содержащий информацию о приеме, обработке, отправке сообщений и электронных документов, а также о формировании квитанций доверенной третьей стороны, в соответствии с перечнем логических операций и событий согласно приложению № 9.

IV. Разрешение конфликтных ситуаций

45. Конфликтной признается ситуация, которая возникает при обмене электронными документами и при которой каким-либо участником обмена электронными документами оспаривается подлинность ЭЦП.
46. Конфликтные ситуации подлежат разрешению в соответствии с порядком разрешения конфликтных ситуаций, утверждаемым Комиссией.

ПРИЛОЖЕНИЕ № 1
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

ТРЕБОВАНИЯ
к формированию и обработке электронных документов

      1. Электронные документы, используемые при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза (далее соответственно – государства-члены, Союз) между собой и с Евразийской экономической комиссией в интегрированной информационной системе внешней и взаимной торговли и создаваемой на основе расширения ее функциональных возможностей интегрированной информационной системе Союза (далее соответственно – электронные документы, интегрированная система), имеют унифицированную структуру.
      2. Унифицированная структура электронного документа содержит следующие основные элементы (блоки):
      а) контейнер электронного документа;
      б) одна или несколько электронных цифровых подписей (электронных подписей) (далее – ЭЦП);
      в) структуры видов электронных документов (сведений);
      г) квитанция доверенной третьей стороны, вкладываемая в контейнер электронного документа при передаче электронного документа через интегрированную систему.
      3. Структуры видов электронных документов (сведений) определяются утверждаемыми Евразийской экономической комиссией для каждого общего процесса в рамках Союза технологическими документами, регламентирующими информационное взаимодействие при реализации средствами интегрированной системы общих процессов в рамках Союза, разработанными в соответствии с Решением Коллегии Евразийской экономической комиссии от 6 ноября 2014 г. № 200 (далее – технологические документы, регламентирующие информационное взаимодействие).
      4. При описании унифицированной структуры электронного документа используются пространства имен, перечень которых приведен в таблице 1.

Таблица 1

Перечень пространств имен документа

Префикс

Адрес

doc	urn:EEC:SignedData:v1.0:EDoc
ds	http://www.w3.org/2000/09/xmldsig#
xs	http://www.w3.org/2001/XMLSchema

5. Унифицированная структура электронного документа приведена в таблице 2.

Таблица 2

Унифицированная структура электронного документа

Элемент		Тип данных	Описание	Кратность
doc:SignedDoc		doc:SignedDocType	контейнер электронного документа	1
	doc:Dаta	блок содержимого электронного документа	doc:DataType	1
	ds:Signature	квитанция доверенной третьей стороны	ds:SignatureType	0..1

6. Блок содержимого электронного документа doc: Dаta должен содержать одну или несколько ЭЦП, формируемых на уровне отправителя, а также данные, подписанные этой (этими) ЭЦП. Блок содержимого электронного документа doc:Dаta должен соответствовать структуре, приведенной в таблице 3.

Таблица 3

Структура блока содержимого электронного документа

Элемент			Тип данных	Описание	Кратность
doc:Data			doc:DataType	блок содержимого электронного документа	1
	@Id		xs:ID	атрибут-идентификатор блока содержимого электронного документа	1
	ds:Signature		ds:SignatureType	ЭЦП электронного документа	1..*
	doc:SignedContent		–	блок подписываемых данных	1
		@Id	xs:ID	атрибут-идентификатор блока подписываемых данных	1
		@DocInstance	xs:anyURI	уникальный идентификатор электронного документа	1
		Структуры видов электронных документов (сведений)	определяется типами структур электронных документов (сведений)	одна или несколько структур видов электронных документов (сведений)	1..*

      7. Атрибут doc:Data/@Id должен содержать идентификатор блока содержимого электронного документа. Значение атрибута определяется отправителем в соответствии с требованиями стандарта xml:id Version 1.0 W3C Recommendation 9 September 2005, http://www.w3.org/TR/xml-id/ (далее – стандарт xml-id).
      8. Элемент doc:SignedDoc/doc:Data/ds:Signature должен содержать ЭЦП электронного документа, к алгоритму формирования которой предъявляются следующие требования:
      а) формат ЭЦП, ее атрибуты и элементы должны соответствовать требованиям стандарта XMLDsig либо стандарта XAdES;
      б) атрибут ds:Signature/@Id должен содержать идентификатор ЭЦП. Значение атрибута определяется отправителем в соответствии с требованиями стандарта xml-id;
      в) блок doc:SignedContent должен подписываться ЭЦП, если иное не указано в технологических документах, регламентирующих информационное взаимодействие. Для ссылки на блок doc:SignedContent из структуры ЭЦП следует использовать значение атрибута doc:SignedContent/@Id;
      г) в состав элемента ds:Signature должны включаться ЭЦП и сертификат ключа проверки ЭЦП в соответствии с требованиями стандарта XMLDsig.
      9. Атрибут doc:SignedContent/@Id должен содержать идентификатор блока подписываемых данных. Значение атрибута определяется отправителем в соответствии с требованиями стандарта xml-id.
      10. Атрибут doc:SignedContent/@DocInstance должен содержать уникальный технологический идентификатор электронного документа, сформированный в соответствии с правилами стандарта RFC 4122, A Universally Unique IDentifier (UUID) URN Namespace (Network Working Group. RFC 4122. «A Universally Unique IDentifier (UUID) URN Namespace». http://www.ietf.org/rfc/rfc4122.txt).
      11. Блок doc:SignedContent должен содержать структуры видов электронных документов (сведений), которые определяются технологическими документами, регламентирующими информационное взаимодействие.
      12. Элемент doc:SignedDoc/ds:Signature представляет собой квитанцию доверенной третьей стороны. Элемент формируется доверенной третьей стороной. Элемент не должен формироваться отправителем электронного документа.
      13. Проверка целостности данных, подписанных ЭЦП электронного документа, выполняется доверенной третьей стороной отправителя в соответствии с процедурой, описанной в разделе 3.2 стандарта XMLDsig. Блоки данных, для которых выполняется процедура проверки целостности, определяются в соответствии с требованиями подпункта «в» пункта 8 настоящего документа.
      14. Обработка электронных документов выполняется в соответствии с Правилами электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденными Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5, а также в соответствии с требованиями технологических документов, регламентирующих информационное взаимодействие, с учетом следующих положений:
      а) стадия структурного контроля блока содержимого включает в себя проверку унифицированной структуры электронного документа по XSD-схеме, а также проверку структур видов электронных документов (сведений);
      б) операция проверки квитанции доверенной третьей стороны получателя должна выполняться после выполнения стадии структурного контроля блока содержимого;
      в) если в соответствии с порядком информационного взаимодействия, в рамках которого передается электронный документ, предусмотрена передача получателю сигнала-подтверждения «Получено», то операция проверки квитанции доверенной третьей стороны выполняется после отправки такого сигнала-подтверждения.

ПРИЛОЖЕНИЕ № 2
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

СХЕМА ДАННЫХ
электронного документа

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:doc="urn:EEC:SignedData:v1.0:EDoc" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="urn:EEC:SignedData:v1.0:EDoc" elementFormDefault="qualified" attributeFormDefault="unqualified">
   <xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd#"/>
   <xs:element name="SignedDoc" type="doc:SignedDocType">
      <xs:annotation>
         <xs:documentation>Электронный документ</xs:documentation>
      </xs:annotation>
   </xs:element>
   <xs:complexType name="SignedDocType">
      <xs:annotation>
         <xs:documentation>Тип данных "Электронный документ"</xs:documentation>
      </xs:annotation>
      <xs:sequence>
         <xs:element name="Data">
            <xs:annotation>
               <xs:documentation>Блок содержимого электронного документа</xs:documentation>
            </xs:annotation>
            <xs:complexType>
               <xs:complexContent>
                  <xs:extension base="doc:DataType">
                     <xs:attribute name="Id" type="xs:ID" use="required"/>
                  </xs:extension>
               </xs:complexContent>
            </xs:complexType>
         </xs:element>
         <xs:element ref="ds:Signature" minOccurs="0">
            <xs:annotation>
               <xs:documentation>Квитанция доверенной третьей стороны</xs:documentation>
            </xs:annotation>
         </xs:element>
      </xs:sequence>
   </xs:complexType>
   <xs:complexType name="DataType">
      <xs:annotation>
         <xs:documentation>Тип блока содержимого электронного документа</xs:documentation>
      </xs:annotation>
      <xs:sequence>
         <xs:element ref="ds:Signature" maxOccurs="unbounded">
            <xs:annotation>
               <xs:documentation>Электронная цифровая подпись (электронная подпись)</xs:documentation>
            </xs:annotation>
         </xs:element>
         <xs:element name="SignedContent">
            <xs:annotation>
               <xs:documentation>Блок подписываемых данных</xs:documentation>
            </xs:annotation>
            <xs:complexType>
               <xs:sequence>
                  <xs:any namespace="##any" processContents="lax" maxOccurs="unbounded">
                     <xs:annotation>
                        <xs:documentation>Структура видов электронных документов (сведений)</xs:documentation>
                     </xs:annotation>
                  </xs:any>
               </xs:sequence>
               <xs:attribute name="Id" type="xs:ID" use="required">
                  <xs:annotation>
                     <xs:documentation>Атрибут-идентификатор блока подписываемых данных</xs:documentation>
                  </xs:annotation>
               </xs:attribute>
               <xs:attribute name="DocInstance" type="xs:anyURI" use="required">
                  <xs:annotation>
                     <xs:documentation>Уникальный идентификатор электронного документа</xs:documentation>
                  </xs:annotation>
               </xs:attribute>
            </xs:complexType>
         </xs:element>
      </xs:sequence>
   </xs:complexType>
</xs:schema>

ПРИЛОЖЕНИЕ № 3
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

ТРЕБОВАНИЯ
к формированию и порядку обработки квитанций
доверенной третьей стороны

1. Квитанция доверенной третьей стороны (далее – квитанция) представляет собой электронный XML-документ в формате XAdES (форма XAdES-T), содержащий блок дополнительных реквизитов квитанции.
2. При описании требований к формированию и порядку обработки квитанции используются пространства имен, перечень которых приведен в таблице 1.

Таблица 1

Перечень пространств имен документа

Префикс

Адрес

rcpt	urn:EEC:TTP:v1.0:receipt
doc	urn:EEC:SignedData:v1.0:EDoc
ds	http://www.w3.org/2000/09/xmldsig#
xades	http://uri.etsi.org/01903/v1.3.2#
xs	http://www.w3.org/2001/XMLSchema

3. При заполнении квитанции используются идентификаторы алгоритмов, приведенные в таблице 2.
Структуры квитанции, блоков основных и дополнительных реквизитов квитанции в формате XAdES приведены в таблицах 3 – 5.

Таблица 2

Идентификаторы алгоритмов

Алгоритм	Идентификатор
Алгоритм каноникализации XML	http://www.w3.org/2001/10/xml-exc-c14n#
Алгоритм кодирования значений ЭЦП и хэш-суммы	http://www.w3.org/2000/09/xmldsig#base64

Таблица 3

Структура квитанции

Элемент							Тип данных	Описание	Кратность
ds:Signature							ds:SignatureType	оборачивающий элемент квитанции	1
	@Id						xs:ID	атрибут-идентификатор квитанции, уникальный в рамках сообщения. Правила присвоения идентификаторов XML-блоков приведены в таблице 6	1
	ds:SignedInfo						ds:SignedInfoType	оборачивающий элемент блока подписанных данных	1
		ds:CanonicalizationMethod					ds:CanonicalizationMethodType	оборачивающий элемент алгоритма каноникализации XML	1
			@Algorithm				xs:anyURI	идентификатор алгоритма каноникализации XML. Правила присвоения идентификаторов приведены в таблице 2	1
		ds:SignatureMethod					ds:SignatureMethodType	оборачивающий элемент алгоритма формирования ЭЦП	1
			@Algorithm				xs:anyURI	атрибут-идентификатор алгоритма формирования ЭЦП. Перечень идентификаторов приведен в приложении № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией	1
		ds:Reference					ds:ReferenceType	оборачивающий элемент ссылки на манифест квитанции	1
			@URI				xs:anyURI	атрибут-ссылка на XML-элемент блока манифеста	1
			@Type				xs:anyURI	атрибут, идентифицирующий блок ds:Reference в качестве ссылки на манифест. Заполняется значением «http://www.w3.org/2000/09/xmldsig#Manifest»	1
			ds:Transforms				ds:TransformsType	оборачивающий элемент перечня трансформаций	1
				ds:Transform			ds:TransformType	оборачивающий элемент трансформации	1
					@Algorithm		xs:anyURI	атрибут-идентификатор алгоритма каноникализации XML. Правила присвоения идентификаторов приведены в таблице 2	1
			ds:DigestMethod				ds:DigestMethodType	оборачивающий элемент алгоритма вычисления хэш-суммы	1
				@Algorithm			xs:anyURI	атрибут-идентификатор алгоритма вычисления хэш-суммы для квитанции. Перечень идентификаторов приведен в приложении № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией	1
			ds:DigestValue				ds:DigestValueType	значение хэш-суммы манифеста после проведения каноникализации XML	1
		ds:Reference					ds:ReferenceType	оборачивающий элемент для ссылки на подписываемый блок основных реквизитов квитанции	1
			@URI				xs:anyURI	атрибут-ссылка на XML-элемент блока основных реквизитов квитанции, уникальных в рамках сообщения, приведенных в таблице 4	1
			@Type				xs:anyURI	атрибут, идентифицирующий блок ds:Reference в качестве ссылки на блок основных реквизитов квитанции. Заполняется значением «urn:EEC:TTP:v1.0:receipt:details»	1
			ds:Transforms				ds:TransformsType	оборачивающий элемент перечня трансформаций	1
				ds:Transform			ds:TransformType	оборачивающий элемент трансформации	1
					@Algorithm		xs:anyURI	атрибут-идентификатор алгоритма каноникализации XML. Правила присвоения идентификаторов приведены в таблице 2	1
			ds:DigestMethod				ds:DigestMethodType	оборачивающий элемент алгоритма вычисления хэш-суммы	1
				@Algorithm			xs:anyURI	атрибут-идентификатор алгоритма вычисления хэш-суммы для квитанции. Перечень идентификаторов приведен в приложении № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией	1
			ds:DigestValue				ds:DigestValueType	значение хэш-суммы блока основных реквизитов квитанции после проведения каноникализации XML	1
		ds:Reference					ds:ReferenceType	оборачивающий элемент ссылки на блок дополнительных реквизитов квитанции в формате XAdES	1
			@URI				xs:anyURI	атрибут-ссылка на XML-элемент блока дополнительных реквизитов квитанции в формате XAdES, приведенных в таблице 5	1
			@Type				xs:anyURI	атрибут, идентифицирующий блок ds:Reference в качестве ссылки на блок дополнительных реквизитов квитанции в формате XAdES. Заполняется значением «http://uri.etsi.org/01903#SignedProperties»	1
			ds:Transforms				ds:TransformsType	оборачивающий элемент перечня трансформаций	1
				ds:Transform			ds:TransformType	оборачивающий элемент трансформации	1
					@Algorithm		xs:anyURI	атрибут-идентификатор алгоритма каноникализации XML. Правила присвоения идентификаторов приведены в таблице 2	1
			ds:DigestMethod				ds:DigestMethodType	оборачивающий элемент алгоритма вычисления хэш-суммы	1
				@Algorithm			xs:anyURI	атрибут-идентификатор алгоритма вычисления хэш-суммы для квитанции. Перечень идентификаторов приведен в приложении № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией	1
			ds:DigestValue				ds:DigestValueType	значение хэш-суммы блока дополнительных реквизитов квитанции в формате XAdES после проведения каноникализации XML	1
	ds:SignatureValue						ds:SignatureValueType	значение ЭЦП, рассчитанное для элемента ds:SignedInfo квитанции после проведения каноникализации XML	1
	ds:KeyInfo						ds:KeyInfoType	оборачивающий элемент ключевой информации, использованной при формировании ЭЦП	1
		ds:X509Data					ds:X509DataType	оборачивающий элемент сертификата ключа проверки ЭЦП доверенной третьей стороны	1
			ds:X509Certificate				xs:base64Binary	сертификат ключа проверки ЭЦП доверенной третьей стороны	1
	ds:Object						ds:ObjectType	оборачивающий элемент дополнительных блоков данных	1
		ds:Manifest					ds:ManifestType	оборачивающий элемент блока манифеста	1
			@Id				xs:ID	атрибут-идентификатор манифеста, уникальный в рамках сообщения. Правила присвоения идентификаторов приведены в таблице 6	1
			ds:Reference				ds:ReferenceType	оборачивающий элемент ссылки на подписываемый электронный документ	1
				@URI			xs:anyURI	атрибут-ссылка на XML-элемент блока содержимого электронного документа. Должен содержать ссылку на doc:SignedDoc/doc:Data/@Id электронного документа, для которого формируется квитанция	1
				ds:Transforms			ds:TransformsType	оборачивающий элемент перечня трансформаций	1
					ds:Transform		ds:TransformType	оборачивающий элемент трансформации	1
						@Algorithm	xs:anyURI	атрибут-идентификатор алгоритма каноникализации XML. Правила присвоения идентификаторов приведены в таблице 2	1
				ds:DigestMethod			ds:DigestMethodType	оборачивающий элемент алгоритма вычисления хэш-суммы	1
					@Algorithm		xs:anyURI	атрибут-идентификатор алгоритма вычисления хэш-суммы для квитанции. Перечень идентификаторов приведен в приложении № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией	1
				ds:DigestValue			ds:DigestValueType	значение хэш-суммы подписываемого электронного документа после проведения каноникализации XML, формируемого в соответствии с пунктом 17 настоящего документа	1
		rcpt:Receipt					rcpt:ReceiptType	блок основных реквизитов квитанции. Описание блока приведено в таблице 4	1
		xades:QualifyingProperties					xades:QualifyingPropertiesType	блок дополнительных реквизитов квитанции в формате XAdES. Описание блока приведено в таблице 5	1

Таблица 4

Структура блока основных реквизитов квитанции

Элемент			Тип данных	Описание	Кратность
rcpt:Receipt			rcpt:ReceiptType	оборачивающий элемент блока основных реквизитов квитанции	1
	@Id		xs:ID	атрибут-идентификатор блока основных реквизитов квитанции, уникальный в рамках сообщения. Правила присвоения идентификаторов приведены в таблице 6	1
	rcpt:ReceiptId		xs:anyURI	уникальный идентификатор сформированной квитанции. Правила формирования идентификаторов приведены в пункте 5 настоящего документа	1
	rcpt:DocId		xs:anyURI	идентификатор электронного документа, на который сформирована квитанция. Правила формирования идентификаторов приведены в пункте 6 настоящего документа	1
	rcpt:Report		–	блок сведений о результатах проверки. Правила формирования блока приведены в пунктах 7 – 12 настоящего документа	1
		rcpt:Success	rcpt:SuccessType	элемент, указывающий на то, что проверка выполнена успешно	0..*
		rcpt:Error	rcpt:ErrorType	элемент, указывающий на то, что при проверке возникли ошибки	0..*
	rcpt:AttachedData		–	блок дополнительных сведений. Правила формирования блока приведены в пункте 13 настоящего документа	0..1
		один или несколько элементов блока	xs:any	содержимое блока дополнительных сведений	1..*

Таблица 5

Структура блока дополнительных реквизитов квитанции в формате
XAdES

Элемент

Тип данных

Описание

Кратность

xades:QualifyingProperties

xades:QualifyingPropertiesType

оборачивающий элемент блока дополнительных реквизитов квитанции в формате XAdES

xades:SignedProperties

xades:SignedPropertiesType

блок подписываемых свойств квитанции

@Id

xs:ID

атрибут-идентификатор блока подписываемых свойств квитанции в формате XAdES. Правила присвоения идентификаторов приведены в таблице 6

xades:SignedSignatureProperties

xades:SignedSignaturePropertiesType

оборачивающий элемент

xades:SigningCertificate

xades:CertIDListType

оборачивающий элемент сведений об использованном сертификате ключа проверки ЭЦП доверенной третьей стороны

xades:Cert

xades:CertIDType

оборачивающий элемент сведений об используемом сертификате ключа проверки ЭЦП доверенной третьей стороны

xades:CertDigest

xades:DigestAlgAndValueType

оборачивающий элемент хэш-суммы использованного сертификата ключа проверки ЭЦП доверенной третьей стороны

ds:DigestMethod

ds:DigestMethodType

оборачивающий элемент алгоритма вычисления хэш-суммы

@Algorithm

xs:anyURI

идентификатор алгоритма вычисления
хэш-суммы для квитанции. Перечень идентификаторов приведен в приложении № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

ds:DigestValue

ds:DigestValueType

значение хэш-суммы сертификата ключа проверки ЭЦП доверенной третьей стороны

ds:IssuerSerial

ds:X509IssuerSerialType

оборачивающий элемент

ds:X509IssuerName

xs:string

наименование удостоверяющего центра, выпустившего сертификат ключа проверки ЭЦП доверенной третьей стороны (поле Issuer заполняется согласно стандарту X.509)

ds:X509SerialNumber

xs:integer

серийный номер сертификата ключа проверки ЭЦП доверенной третьей стороны (поле SerialNumber заполняется согласно стандарту X.509)

xades:SignatureProductionPlace

xades:SignatureProductionPlace
Type

оборачивающий элемент места (сегмента) формирования квитанции

xades:CountryName

xs:string

идентификатор места (сегмента) формирования квитанции. Правила заполнения приведены в пункте 14 настоящего документа

xades:SignerRole

xades:SignerRoleType

оборачивающий элемент сведений о роли доверенной третьей стороны, формирующей квитанцию

xades:ClaimedRoles

xades:ClaimedRolesListType

оборачивающий элемент

xades:ClaimedRole

xades:AnyType

роль доверенной третьей стороны. Перечень ролей приведен в пункте 15 настоящего документа

xades:UnsignedProperties

xades:UnsignedPropertiesType

блок неподписываемых свойств квитанции, содержащий метку времени

xades:SignatureTimeStamp

оборачивающий элемент для штампа времени

ds:CanonicalizationMethod

ds:CanonicalizationMethodType

идентификатор алгоритма каноникализации XML. Правила присвоения идентификаторов приведены в таблице 2

xades:EncapsulatedTimeStamp

xades:EncapsulatedPKIDataType

штамп времени, оформленный согласно стандарту протокола штампов времени RFC 3161. Правила формирования штампа времени приведены в пункте 16 настоящего документа. При формировании штампа времени идентификаторы криптографических алгоритмов должны указываться в соответствии с правилами, предусмотренными приложением № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

      4. Правила заполнения идентификаторов XML-блоков приведены в таблице 6. При этом вместо элемента <Номер> должно подставляться значение «1», а вместо элемента <ДТС> должно подставляться одно из следующих значений:
      а) TTP.Sender – если квитанция формируется доверенной третьей стороной отправителя;
      б) TTP.Receiver – если квитанция формируется доверенной третьей стороной получателя.

Таблица 6

Правила заполнения идентификаторов XML-блоков

Идентификатор XML-блока	Правила заполнения
идентификатор квитанции	<ДТС>.Receipt<Номер>
идентификатор блока манифеста	<ДТС>.Receipt<Номер>Manifest
идентификатор блока основных реквизитов квитанции	<ДТС>.Receipt.<Номер>Details
идентификатор блока подписываемых свойств квитанции в формате XAdES	<ДТС>.Receipt<Номер>SignedProperties

      5. Уникальный идентификатор квитанции (элемент rcpt:ReceiptId) должен формироваться согласно спецификации RFC 4122 (Network Working Group. RFC 4122. «A Universally Unique IDentifier (UUID) URN Namespace». http://www.ietf.org/rfc/rfc4122.txt).
      6. Идентификатор электронного документа (rcpt:DocId) представляет собой строку, уникально идентифицирующую электронный документ, на который формируется квитанция. Идентификатор заполняется значением следующего атрибута из структуры электронного документа: «doc:SignedDoc/doc:Dаta/doc:SignedContent/@DocInstance».
      7. Блок сведений о результатах проверки (rcpt:Report) должен содержать один или несколько элементов rcpt:Success и rcpt:Error, свидетельствующих о результатах проверок, выполненных доверенной третьей стороной. Структура элементов rcpt:Success и rcpt:Error приведена в таблицах 7 – 8.

Таблица 7

Структура элемента rcpt:Success

Элемент			Тип данных	Описание	Кратность
	rcpt:Success		rcpt:SuccessType	элемент, указывающий, что проверка выполнена успешно	1
		@Reference	xs:anyURI	идентификатор проверяемого объекта	0..1

Таблица 8

Структура элемента rcpt:Error

Элемент		Тип данных	Описание	Кратность
rcpt:Error		rcpt:ErrorType	элемент, указывающий, что при проверке возникла ошибка	1
	@Reference	xs:anyURI	идентификатор проверяемого объекта	0..1
	rcpt:ReasonCode	xs:string	код ошибки	1
	rcpt:ReasonText	xs:string	текстовое описание ошибки	1

      8. Атрибут Reference элементов rcpt:Success и rcpt:Error заполняется доверенной третьей стороной отправителя. Атрибут должен содержать ссылку на ЭЦП в электронном документе, для которого формируется элемент rcpt:Success или rcpt:Error. Для формирования ссылки следует использовать значение атрибута ds:Signature/@Id ЭЦП.
      Доверенная третья сторона получателя не должна формировать атрибут Reference.
      9. При заполнении элемента rcpt:ReasonCode должны использоваться следующие коды:
      а) Signature.Error – код свидетельствует об ошибке проверки ЭЦП в электронном документе или ЭЦП в квитанции;
      б) Signature.BadCertificate – код свидетельствует об ошибке проверки сертификата ключа проверки ЭЦП электронного документа либо сертификата ключа проверки ЭЦП квитанции.
      10. Элемент rcpt:ReasonText содержит текст, описывающий ошибку. Правила заполнения элемента rcpt:ReasonText доверенная третья сторона определяет самостоятельно.
      11. Доверенной третьей стороной отправителя должен быть реализован следующий алгоритм формирования содержимого блока сведений о результатах проверки rcpt:Report:
      а) выполняется поиск первой ЭЦП в электронном документе;
      б) для найденной ЭЦП выполняются проверки, предусмотренные подразделом 2 раздела III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. № 125;
      в) если все проверки ЭЦП выполнены успешно, то доверенной третьей стороной отправителя формируется блок rcpt:Success, в противном случае формируется блок rcpt:Error;
      г) выполняется поиск следующей ЭЦП в электронном документе. Если ЭЦП найдена, действия, указанные в подпунктах «б» – «г» настоящего пункта, повторяются.
      12. Доверенной третьей стороной получателя должен быть реализован следующий алгоритм формирования содержимого блока сведений о результатах проверки rcpt:Report:
      а) выполняется поиск квитанции доверенной третьей стороны получателя в составе электронного документа;
      б) для найденной квитанции выполняются проверки, предусмотренные подразделом 2 раздела III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. № 125;
      в) если все проверки квитанции выполнены успешно, то доверенной третьей стороной получателя формируется блок rcpt:Success, в противном случае формируется блок rcpt:Error.
      13. Блок rcpt:AttachedData содержит дополнительную информацию, связанную с квитанцией.
      Доверенная третья сторона получателя должна вкладывать в блок rcpt:AttachedData квитанцию доверенной третьей стороны отправителя.
      14. Для идентификации места (сегмента) формирования квитанции (элемент xades:CountryName) должен использоваться один из следующих кодов:
      а) EEC – при формировании квитанции в интеграционном сегменте Евразийской экономической комиссии;
      б) код страны в соответствии со стандартом ISO 3166-1 alpha-2 – при формировании квитанции в одном из национальных сегментов государств – членов Евразийского экономического союза (далее – государства-члены).
      15. Для указания роли доверенной третьей стороны (элемент xades:ClaimedRole) должен использоваться один из следующих кодов:
      а) TTP.Sender – если квитанция формируется доверенной третьей стороной отправителя;
      б) TTP.Receiver – если квитанция формируется доверенной третьей стороной получателя.
      16. Формирование штампа времени (элемент xades:EncapsulatedTimeStamp) для квитанции доверенной третьей стороны отправителя выполняется с использованием сервиса штампа времени удостоверяющего центра службы доверенной третьей стороны и с применением стандартов службы доверенной третьей стороны интегрированной системы.
      Формирование штампа времени для квитанции доверенной третьей стороны получателя выполняется с использованием сервиса штампа времени государства-члена и с применением национальных криптографических стандартов.
      В случае недоступности сервиса штампа времени удостоверяющего центра службы доверенной третьей стороны должен использоваться автономный сервис штампа времени доверенной третьей стороны отправителя с формированием штампа времени при помощи криптографических стандартов службы доверенной третьей стороны интегрированной системы. Недоступность сервиса штампа времени удостоверяющего центра службы доверенной третьей стороны является нештатной ситуацией, и указанный факт в обязательном порядке фиксируется в журнале аудита доверенной третьей стороны с целью проведения анализа причин и их устранения.
      17. Хэш в блоке манифеста квитанции (содержимое элемента ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue) должен формироваться на блок doc:Dаta электронного документа, включая сам XML-тег doc:Dаta, его атрибуты и все элементы-потомки (рисунок 1).
      Выборка XML-элементов электронного документа для формирования хэша должна выполняться по правилам, аналогичным для выборок по ссылкам типа «same-document reference» стандарта XMLDsig (раздел 4.3.3.3). Должна производиться выборка всего множества XML-элементов электронного документа, исключая элементы-комментарии (non-comment node).

Рис. 1. Расположение квитанции в структуре электронного
документа, а также области формирования хэша в блоке манифеста
квитанции

      18. В целях снижения затрат на передачу электронного документа от отправителя получателю в условиях разнородности форматов сообщений, используемых внутри национальных сегментов государств-членов, квитанции должны быть вложены в структуру электронного документа.
      Вложение квитанции выполняется путем добавления XML-структуры квитанции в качестве дочернего элемента блока doc:SignedDoc после блока doc:Data (рисунок 1).
      19. Проверка ЭЦП в квитанции может выполняться в 2 режимах:
      а) проверка ЭЦП в квитанции при наличии электронного документа, на который сформирована квитанция (основной режим проверки);
      б) проверка ЭЦП в квитанции без электронного документа, на который сформирована квитанция (служебный режим проверки).
      20. Проверка ЭЦП в квитанции в основном режиме выполняется в целях обеспечения юридической значимости электронного документа, на который сформирована квитанция.
      Все проверки ЭЦП в квитанции, предусмотренные подразделом 2 раздела III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. № 125, выполняются в основном режиме.
      21. К процедуре проверки ЭЦП в квитанции в основном режиме предъявляются следующие требования:
      проверка выполняется в соответствии с правилами, указанными в стандарте XAdES (форма XAdES-T);
      проверка ЭЦП в квитанции в основном режиме включает в себя проверку целостности электронного документа.
      Под проверкой целостности электронного документа понимается процедура формирования хэша содержимого электронного документа в соответствии с требованиями пункта 17 настоящего документа, а также с правилами обработки элементов типа ds:Reference согласно правилам стандарта XMLDsig, и сверка сформированного хэша со значением, указанным в элементе ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue ЭЦП квитанции.
      В случае если хэш содержимого электронного документа не соответствует значению, указанному в составе элемента ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue ЭЦП квитанции, целостность электронного документа считается нарушенной, а процедура проверки ЭЦП в квитанции – завершенной с ошибкой.
      22. Проверка ЭЦП в квитанции в служебном режиме выполняется в целях проверки целостности и подлинности квитанции в условиях, когда квитанция хранится отдельно от электронного документа, на который она сформирована. При этом проверка целостности электронного документа, на который сформирована квитанция, не выполняется.
      Служебный режим проверки ЭЦП в квитанции может использоваться в операциях, связанных с архивным хранением квитанций доверенной третьей стороной, включая периодическую проверку целостности и подлинности квитанций, заверение квитанций дополнительными ЭЦП для продления срока архивного хранения и т. д.
      23. К процедуре проверки ЭЦП в квитанции предъявляются следующие требования:
      а) проверка выполняется в соответствии с правилами, указанными в стандарте XAdES (форма XAdES-T);
      б) элемент ds:Signature/ds:Object/ds:Manifest/ds:Reference ЭЦП квитанции при проверке не обрабатывается.

ПРИЛОЖЕНИЕ № 4
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

СХЕМА ДАННЫХ
основных реквизитов квитанции

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:rcpt="urn:EEC:TTP:v1.0:receipt" targetNamespace="urn:EEC:TTP:v1.0:receipt" elementFormDefault="qualified" attributeFormDefault="unqualified">
   <xs:element name="Receipt" type="rcpt:ReceiptType">
      <xs:annotation>
         <xs:documentation>Блок основных реквизитов квитанции</xs:documentation>
      </xs:annotation>
   </xs:element>
   <xs:complexType name="ReceiptType">
      <xs:annotation>
         <xs:documentation>Тип блока основных реквизитов квитанции</xs:documentation>
      </xs:annotation>
      <xs:sequence>
         <xs:element name="ReceiptId" type="xs:anyURI">
            <xs:annotation>
               <xs:documentation>Уникальный идентификатор сформированной квитанции</xs:documentation>
            </xs:annotation>
         </xs:element>
         <xs:element name="DocId" type="xs:anyURI">
            <xs:annotation>
               <xs:documentation>Идентификатор электронного документа</xs:documentation>
            </xs:annotation>
         </xs:element>
         <xs:element name="Report">
            <xs:annotation>
               <xs:documentation>Блок сведений о результатах проверки</xs:documentation>
            </xs:annotation>
            <xs:complexType>
               <xs:choice maxOccurs="unbounded">
                  <xs:element name="Success" type="rcpt:SuccessType"/>
                  <xs:element name="Error" type="rcpt:ErrorType"/>
               </xs:choice>
            </xs:complexType>
         </xs:element>
         <xs:element name="AttachedData" minOccurs="0">
            <xs:annotation>
               <xs:documentation>Блок дополнительных сведений в формате XML</xs:documentation>
            </xs:annotation>
            <xs:complexType>
               <xs:sequence>
                  <xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>
               </xs:sequence>
            </xs:complexType>
         </xs:element>
      </xs:sequence>
      <xs:attribute name="Id" type="xs:ID" use="required"/>
   </xs:complexType>
   <xs:complexType name="BaseReportType">
      <xs:annotation>
         <xs:documentation>Базовый тип элемента-отчета о проверке</xs:documentation>
      </xs:annotation>
      <xs:attribute name="Reference" type="xs:anyURI" use="optional"/>
   </xs:complexType>
   <xs:complexType name="SuccessType">
      <xs:annotation>
         <xs:documentation>Тип элемента, указывающего, что проверка ДТС выполнена успешно</xs:documentation>
      </xs:annotation>
      <xs:complexContent>
         <xs:extension base="rcpt:BaseReportType"/>
      </xs:complexContent>
   </xs:complexType>
   <xs:complexType name="ErrorType">
      <xs:annotation>
         <xs:documentation>Тип контейнера описания ошибки</xs:documentation>
      </xs:annotation>
      <xs:complexContent>
         <xs:extension base="rcpt:BaseReportType">
            <xs:sequence>
               <xs:element name="ReasonCode">
                  <xs:annotation>
                     <xs:documentation>Код ошибки</xs:documentation>
                  </xs:annotation>
                  <xs:simpleType>
                     <xs:restriction base="xs:string">
                        <xs:enumeration value="Signature.Error"/>
                        <xs:enumeration value="Signature.BadCertificate"/>
                        <xs:enumeration value="Document.AuthenticityError"/>
                     </xs:restriction>
                  </xs:simpleType>
               </xs:element>
               <xs:element name="ReasonText" type="xs:string" >
                  <xs:annotation>
                     <xs:documentation>Текстовое описание ошибки</xs:documentation>
                  </xs:annotation>
               </xs:element>
            </xs:sequence>
         </xs:extension>
      </xs:complexContent>
   </xs:complexType>
</xs:schema>

ПРИЛОЖЕНИЕ № 5
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

ОПИСАНИЕ
сообщений, используемых при взаимодействии
с доверенной третьей стороной

      1. Сообщения, которыми обмениваются доверенная третья сторона и интеграционный шлюз интегрированной информационной системы внешней и взаимной торговли (создаваемой на основе расширения ее функциональных возможностей интегрированной информационной системы Евразийского экономического союза) (далее – интегрированная система), формируются в соответствии с Правилами электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденными Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5 (далее – Правила электронного обмена данными).
      Все сообщения относятся к классу служебных сообщений интегрированной системы.
      2. При описании сообщений используются пространства имен, перечень которых приведен в таблице.

Перечень пространств имен документа

Префикс	Адрес
ttp	urn:EEC:TTP:v1.0
soap	в соответствии с Правилами электронного обмена данными
wsa	в соответствии с Правилами электронного обмена данными

      3. К сообщениям, поступающим доверенной третьей стороне, предъявляются следующие общие требования:
      а) элемент заголовка wsa:To должен содержать логический адрес сервиса доверенной третьей стороны, обеспечивающего проверки, предусмотренные Положением об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств – членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденным Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. № 125 (далее соответственно – сервис подтверждения подлинности, Положение). Логический адрес присваивается сервису подтверждения подлинности организацией – оператором интеграционного шлюза соответствующего сегмента интегрированной системы;
      б) элемент заголовка wsa:ReplyTo/wsa:Address должен содержать логический адрес интерфейса интеграционного шлюза, обеспечивающего обработку сообщений от сервиса подтверждения подлинности;
      в) элемент заголовка wsa:Action должен содержать одно из следующих значений:
      int://SR/TTP/Sender/Incoming – если сообщение направлено доверенной третьей стороне отправителя;
      int://SR/TTP/Recipient/Incoming – если сообщение направлено доверенной третьей стороне получателя;
      г) в тело (soap:Body) включается электронный документ, полученный от отправителя.
      4. В зависимости от результатов обработки входящего сообщения доверенная третья сторона направляет в интеграционный шлюз следующие сообщения:
      а) сообщение, в котором электронный документ дополнен квитанцией доверенной третьей стороны (ответное сообщение), – в случае штатной работы сервиса подтверждения подлинности;
      б) технологическое сообщение об ошибке – в случае возникновения ошибки обработки сообщения и (или) электронного документа на уровне доверенной третьей стороны.
      5. К ответному сообщению предъявляются следующие требования:
      а) элемент заголовка wsa:To должен содержать значение элемента wsa:ReplyTo/wsa:Address входящего сообщения;
      б) элемент заголовка wsa:From/wsa:Address должен содержать логический адрес сервиса подтверждения подлинности, присвоенный ему организацией – оператором интеграционного шлюза;
      в) элемент заголовка wsa:RelatesTo должен содержать значение элемента wsa:MessageId входящего сообщения;
      г) элемент заголовка wsa:Action должен содержать одно из следующих значений:
      int://SR/TTP/Sender/Outgoing – если сообщение направлено доверенной третьей стороной отправителя;
      int://SR/TTP/Recipient/Outgoing – если сообщение направлено доверенной третьей стороной получателя;
      д) в тело (soap:Body) включаются электронный документ и квитанция доверенной третьей стороны.
      6. К технологическому сообщению об ошибке предъявляются следующие требования:
      а) элемент заголовка wsa:To должен содержать значение элемента wsa:ReplyTo/wsa:Address входящего сообщения;
      б) элемент заголовка wsa:From/wsa:Address должен содержать логический адрес сервиса подтверждения подлинности, присвоенный ему организацией – оператором интеграционного шлюза;
      в) в случае если технологическое сообщение об ошибке свидетельствует о возникновении одной из типовых ошибок, предусмотренных Правилами электронного обмена данными, элементам soap:Code/soap:Value и soap:Subсode/soap:Value должны быть присвоены значения, определенные Правилами электронного обмена данными;
      г) в случае если технологическое сообщение об ошибке свидетельствует о несоответствии структуры тела сообщения требованиям, предъявляемым к входящим сообщениям, элементу soap:Code/soap:Value должно быть присвоено значение «soap:Sender», а элементу soap:Subсode/soap:Value – значение «ttp:InvalidAppData»;
      д) элемент тела сообщения soap:Fault/soap:Detail должен содержать SOAP-конверт вместе с содержимым тела и заголовками входящего сообщения, оформленный в соответствии с Правилами электронного обмена данными.

ПРИЛОЖЕНИЕ № 6
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

ОПИСАНИЕ
типового протокола электронного обмена данными между
интеграционным шлюзом интегрированной информационной системы
внешней и взаимной торговли и сервисами доверенной третьей
стороны на транспортном уровне

      1. Настоящий документ описывает типовой протокол электронного обмена данными между интеграционным шлюзом интегрированной информационной системы внешней и взаимной торговли (создаваемой на основе расширения ее функциональных возможностей интегрированной информационной системы Евразийского экономического союза) и сервисами доверенной третьей стороны (далее соответственно – интегрированная система, участники обмена) посредством промежуточного программного обеспечения, предоставляющего средства для организации очередей сообщений (далее – программное обеспечение MQ).
      2. При организации электронного обмена данными между участниками обмена в национальных сегментах интегрированной системы допускается реализация электронного обмена данными через веб-сервисы или иными способами организации электронного обмена данными (альтернативные способы).
      3. Реализация альтернативных способов организации электронного обмена данными настоящим документом не регулируется. При использовании альтернативных способов организации электронного обмена данными в рамках национального сегмента интегрированной системы государство – член Евразийского экономического союза (далее – государство-член) обеспечивает разработку нормативно-технологического документа (документов), описывающего протокол электронного обмена данными между интеграционным шлюзом интегрированной системы и сервисами доверенной третьей стороны национального сегмента государства-члена.
      4. Канал передачи данных между участниками обмена должен быть защищен от несанкционированного доступа. Способы и порядок защиты канала передачи данных определяются нормативными правовыми актами и техническими документами государств-членов и Евразийской экономической комиссии, устанавливающими требования к защите информации при электронном обмене данными.
      5. Понятия, используемые в настоящем документе, означают следующее:
      «API» (Application programming interface) – набор готовых классов, процедур, функций, структур и констант, предоставляемых приложением (библиотекой, сервисом) для использования во внешних программных продуктах;
      «MIME» (Multipurpose Internet mail extensions) – спецификация для кодирования и форматирования информации для ее передачи внутри текстовых данных;
      «MQMD» (Message queuing message descriptor) – заголовок транспортного сообщения, содержащий основные реквизиты транспортного сообщения;
      «MQRFH2» – заголовок транспортного сообщения, содержащий дополнительные реквизиты транспортного сообщения;
      «менеджер очередей» – программный компонент, предоставляющий сервисы очередей сообщений посредством API;
      «очередь» – именованное хранилище сообщений, управляемое посредством менеджера очередей;
      «транспортное сообщение» – совокупность элементов информации, оформленных в соответствии с требованиями транспортного протокола.
      6. При реализации типового протокола электронного обмена данными допускается использование любого из имеющихся программных интерфейсов к программному обеспечению MQ (MQI, AMI, JMS и т. д.).
      В настоящем документе для обозначения служебных структур и констант программного обеспечения MQ используются наименования, соответствующие программному интерфейсу MQI. При использовании других программных интерфейсов названия структур и констант могут отличаться.
      7. На транспортном уровне участниками обмена выполняется обмен транспортными сообщениями в формате программного обеспечения MQ.
      8. Для транспортного сообщения установлен предельный размер 100 Мб.
      9. Требования к заполнению полей заголовка MQMD приведены в таблице.

Значения полей заголовка MQMD

Имя поля	Значение	Комментарий
Version	MQMD_VERSION_2	используется только вторая версия заголовков
MsgType	MQMT_DATAGRAM	обмен осуществляется только дейтаграммами
Expiry	144000	ограничение на истечение срока доставки сообщения – 4 часа
Persistence	MQPER_PERSISTENT	включен режим гарантированной доставки
Report	MQRO_EXPIRATION_WITH_FULL_DATA	запрашивается уведомление об истечении срока доставки сообщения
ReplyToQ	имя очереди получения ответов	заполняется для сообщений-запросов
ReplyToQmgr	имя менеджера для получения ответов	заполняется для сообщений-запросов

      Поля MQMD, не указанные в таблице, при заполнении должны иметь значения по умолчанию (используются значения из структуры MQMD_DEFAULT).
      10. В случае если данные, передаваемые посредством транспортных сообщений, представлены в формате MIME-сообщения, для идентификации наличия двоичного вложения в группе заголовков MQRFH2 в папке <usr> должен присутствовать заголовок contentType, который должен иметь строковое значение «Multipart/Related; boundary=<идентификатор границы MIME-блока>;».
      11. В случае если данные, передаваемые посредством транспортных сообщений, представлены в виде SOAP-сообщения, в группе заголовков MQRFH2 в папке <usr> должен присутствовать заголовок contentType, который должен иметь строковое значение «application/soap+xml».

ПРИЛОЖЕНИЕ № 7
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

ОБРАЗЕЦ
заполнения квитанции доверенной третьей стороны отправителя

<ds:Signature Id="TTP.Sender.Receipt1" xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
    <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    <ds:SignatureMethod Algorithm="[идентификатор алгоритма вычисления значения ЭЦП]"/>
    <ds:Reference URI="#TTP.Sender.Receipt1Manifest" Type="http://www.w3.org/2000/09/xmldsig#Manifest">
      <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      </ds:Transforms>
      <ds:DigestMethod Algorithm="[идентификатор алгоритма вычисления хэш-суммы]"/>
      <ds:DigestValue>BjBsR09EbGhjZ0dTQUxN……NBRU1tQ1p0dU1GUXhEUzhB</ds:DigestValue>
    </ds:Reference>
    <ds:Reference URI="#TTP.Sender.Receipt1Details" Type="urn:EEC:TTP:v1.0:receipt:details">
      <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
      </ds:Transforms>
      <ds:DigestMethod Algorithm="[идентификатор алгоритма вычисления хэш-суммы]"/>
<ds:DigestValue>UjBsR09EbGhjZ0dTQUxNQUFB…..U1tQ1p0dU1GUXhEUzhi</ds:DigestValue>
    </ds:Reference>
    <ds:Reference URI="#TTP.Sender.Receipt1SignedProperties" Type="http://uri.etsi.org/01903#SignedProperties">
    <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
    </ds:Transforms>
      <ds:DigestMethod Algorithm="[идентификатор алгоритма вычисления хэш-суммы]"/>
      <ds:DigestValue>UjBsR09...UxNQUFBUUNBRU1tQ1p0dU1GUXhEUzhi</ds:DigestValue>
    </ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>UjBsR09EbGhjZ..tQ1p0dU1GUXhEUzhi</ds:SignatureValue>
<ds:KeyInfo>
    <ds:X509Data>
      <ds:X509Certiicate>mMDVhY...11Cm4=</ds:X509Certiicate>
    </ds:X509Data>
</ds:KeyInfo>
<ds:Object>
<ds:Manifest Id="TTP.Sender.Receipt1Manifest">
    <ds:Reference URI="#Data">
      <ds:Transforms>
        <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#m"/>
      </ds:Transforms>
      <ds:DigestMethod Algorithm="[идентификатор алгоритма вычисления хэш-суммы]"/>
      <ds:DigestValue>UjBsR09EbGhjZ0dTQ…UUNBRU1tQ1p0dU1GUXhEUzhi</ds:DigestValue>
    </ds:Reference>
</ds:Manifest>
    <rcpt:Receipt Id="TTP.Sender.Receipt1Details" xmlns:rcpt="urn:EEC:TTP:v1.0:receipt">
      <rcpt:ReceiptId>urn:uuid:9d3b13f5-3c18-4788-9117-efc3faa78272</rcpt:ReceiptId>
       <rcpt:DocId>urn:uuid:062c1624-5c7e-4a9f-942c-2bba2ea983cf</rcpt:DocId>
       <rcpt:Report>
             <rcpt:Success Reference="#Signature1"/>
             <rcpt:Error Reference="#Signature2">
                          <rcpt:ReasonCode>Signature.Error</rcpt:ReasonCode>
                          <rcpt:ReasonText>Хэш, указанный в элементе Signature/SignedInfo/DigestValue не совпадает со значением хэша, построенного ДТС</rcpt:ReasonText>
             </rcpt:Error>
             <rcpt:Success Reference="#Signature3"/>
       </rcpt:Report>
    </rcpt:Receipt>
<xades:QualifyingProperties xmlns:xades="http://uri.etsi.org/01903/v1.3.2#">
      <xades:SignedProperties Id="TTP.Sender.Receipt1SignedProperties">
        <xades:SignedSignatureProperties>
          <xades:SigningCertificate>
            <xades:Cert>
              <xades:CertDigest>
                <ds:DigestMethod>[идентификатор алгоритма вычисления хэш-суммы]</ds:DigestMethod>
                <ds:DigestValue>UjBsR0..tQ1p0dU1GUXhEUzhi</ds:DigestValue>
              </xades:CertDigest>
              <ds:IssuerSerial>
                <ds:X509IssuerName>CN = CertCenter, O = CERT-CENTER, C = EEC, E = nfo@cn.org </ds:X509IssuerName>
                <ds:X509SerialNumber>18761230</ds:X509SerialNumber>
              </ds:IssuerSerial>
            </xades:Cert>
          </xades:SigningCertificate>
          <xades:SignatureProductionPlace>
            <xades:CountryName>RU</xades:CountryName>
          </xades:SignatureProductionPlace>
          <xades:SignerRole>
            <xades:ClaimedRoles>
              <xades:ClaimedRole>TTP.Sender</xades:ClaimedRole>
            </xades:ClaimedRoles>
          </xades:SignerRole>
        </xades:SignedSignatureProperties>
      </xades:SignedProperties>
      <xades:UnsignedProperties>
        <xades:UnsignedSignatureProperties>
            <SignatureTimeStamp>
                  <ds:CanonicalizationMethod Algorithm=" http://www
w3.org/2001/10/xml-exc-c14n#"/>
                  <xades:EncapsulatedTimeStamp>UjBsUxNQUFBUU….UxhEUzhi</xades:EncapsulatedTimeStamp>
            </SignatureTimeStamp>
          </xades:UnsignedSignatureProperties>
        </xades:UnsignedProperties>
      </xades:QualifyingProperties>
</ds:Object>
</ds:Signature>

ПРИЛОЖЕНИЕ № 8
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

ПЕРЕЧЕНЬ
идентификаторов криптографических алгоритмов, используемых при
формировании электронной цифровой подписи (электронной подписи)

URI-идентификатор	OID-идентификатор	Наименование стандарта
I. Для алгоритмов вычисления значения ЭЦП
1. http://www.w3.org/2001/04/xmldsig-more#gostr3410	1.2.398.3.10.1.1.1.2	ГОСТ 34.310-2004 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»
2. http://www.w3.org/2001/04/xmldsig-more#gostr34102001-gostr3411	1.2.643.2.2.3	ГОСТ Р 34.10-2001 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»
3. urn:EAEU:Signature:gostr34.10-2012	1.2.643.7.1.1.1.2	ГОСТ Р 34.10-2012 «Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи»
4. urn:EAEU:Signature:bign-with-hspec	1.2.112.0.2.0.34.101.45.11	СТБ 34.101.45-2013 «Информационные технологии и безопасность. Алгоритмы электронной цифровой подписи и транспорта ключа на основе эллиптических кривых» - алгоритм ЭЦП с функцией хэширования, определяемой долговременными параметрами»
5. urn:EAEU:Signature:bign-with-hbelt	1.2.112.0.2.0.34.101.45.12	СТБ 34.101.45-2013 «Информационные технологии и безопасность. Алгоритмы электронной цифровой подписи и транспорта ключа на основе эллиптических кривых» - алгоритм ЭЦП с функцией хэширования, заданной алгоритмом belt-hash
6. urn:EAEU:Signature:bign-ibs-with-hspec	1.2.112.0.2.0.34.101.45.71	СТБ 34.101.45-2013 «Информационные технологии и безопасность. Алгоритмы электронной цифровой подписи и транспорта ключа на основе эллиптических кривых» - алгоритм идентификационной ЭЦП с функцией хэширования, определяемой долговременными параметрами
7. urn:EAEU:Signature:bign-ibs-with-hbelt	1.2.112.0.2.0.34.101.45.72	СТБ 34.101.45-2013 «Информационные технологии и безопасность. Алгоритмы электронной цифровой подписи и транспорта ключа на основе эллиптических кривых» - алгоритм идентификационной ЭЦП с функцией хэширования, заданной алгоритмом belt-hash
II. Для алгоритмов вычисления хэш-суммы
1. urn:EAEU:Digest:gost34.311-95	1.2.398.3.10.1.3.1	ГОСТ 34.311-95 «Информационная технология. Криптографическая защита информации. Функция хэширования»
2. urn:EAEU:Digest:gostr34.11-2012	1.2.643.7.1.1.2.3	ГОСТ Р 34.11-2012 «Информационная технология. Криптографическая защита информации. Функция хэширования»
3. http://www.w3.org/2001/04/xmldsig-more#gostr3411	1.2.643.2.2.9	ГОСТ Р 34.11-94 «Информационная технология. Криптографическая защита информации. Функция хэширования»
4. urn:EAEU:Digest:belt-hash256}	1.2.112.0.2.0.34.101.31.81	СТБ 34.101.31-2011 «Информационные технологии и безопасность. Криптографические алгоритмы шифрования и контроля целостности»

ПРИЛОЖЕНИЕ № 9
к Положению об обмене электронными
документами при трансграничном
взаимодействии органов государственной
власти государств – членов Евразийского
экономического союза между собой и
с Евразийской экономической комиссией

ПЕРЕЧЕНЬ
логических операций и событий, возникающих при обработке
электронных сообщений и электронных документов доверенной
третьей стороной и отражаемых в журнале аудита

Код	Текстовое описание записи	Операция (событие) и примечание к нему
OP1000	Сообщение считано. Тип сообщения: <Тип>	выполнено считывание сообщения на транспортном уровне. В поле <Тип> указывается значение «MIME», если сообщение содержит MIME-части, или значение «SOAP», если MIME-части в сообщении отсутствуют
OP1100	Электронное сообщение принято в обработку. Заголовки сообщения: wsa:To: <значение заголовка wsa:To>; wsa:ReplyTo: <значение заголовка wsa:ReplyTo>; wsa:Action: <значение заголовка wsa:Action>; wsa:MessageID: <значение заголовка wsa:MessageID>	выполнен разбор блока заголовков сообщения, а также определено, что сообщение имеет блок содержимого (soap:Body). В полях типа <значение заголовка…> указываются значения соответствующих заголовков SOAP-сообщения
OP1200	Электронный документ принят в обработку. Идентификатор сообщения: <значение заголовка wsa:MessageID>; идентификатор электронного документа: <DocInstance>	выполнено считывание электронного документа из блока содержимого сообщения и произведен разбор его полей. В поле <DocInstance> указывается уникальный идентификатор электронного документа
OPS5100	Целостность данных, заверенных ЭЦП, проверена по хэшу. Идентификатор электронного документа: <DocInstance>; идентификатор ЭЦП: <ID подписи>	выполняется только доверенной третьей стороной отправителя. Выполнено сопоставление значений хэша, указанных в составе ЭЦП, и значений хэша, сформированных доверенной третьей стороной на основе сведений, указанных в ЭЦП. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ID подписи> указывается идентификатор ЭЦП ds:Signature/@Id
OPS5200	Значение ЭЦП проверено. Идентификатор электронного документа: <DocInstance>; идентификатор ЭЦП: <ID подписи>	выполняется только доверенной третьей стороной отправителя. Выполнена проверка того, что значение ЭЦП выработано с использованием закрытого (личного) ключа, соответствующий сертификат открытого ключа которого (сертификат ключа проверки ЭЦП) указан в составе этой ЭЦП. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ID подписи> указывается идентификатор ЭЦП ds:Signature/@Id
OPS5300	Сертификат проверен. Идентификатор электронного документа: <DocInstance>; идентификатор ЭЦП: <ID подписи>	выполняется только доверенной третьей стороной отправителя. Выполнена проверка того, что сертификат ключа проверки ЭЦП и каждый сертификат удостоверяющего центра из цепочки сертификатов действительны на момент подписания электронного документа. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ID подписи> указывается идентификатор ЭЦП ds:Signature/@Id
OPR5100	Целостность электронного документа, заверенного квитанцией ДТС отправителя, а также блоков данных, указанных в составе ЭЦП квитанции, проверена. Идентификатор электронного документа: <DocInstance>; идентификатор квитанции ДТС отправителя: <ReceiptId>	выполняется только доверенной третьей стороной отправителя. Проверена целостность всех блоков данных, включая блок содержимого электронного документа, исходя из значений хэшей блоков, содержащихся в квитанции. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ReceiptId> указывается уникальный идентификатор квитанции доверенной третьей стороны отправителя (значение элемента rcpt:ReceiptId)
OPR5200	Значение ЭЦП квитанции ДТС отправителя проверено. Идентификатор электронного документа: <DocInstance>	выполняется только доверенной третьей стороной получателя. Выполнена проверка того, что значение ЭЦП в квитанции доверенной третьей стороны отправителя выработано с использованием закрытого (личного) ключа доверенной третьей стороны отправителя, соответствующий сертификат открытого ключа которого (сертификат ключа проверки ЭЦП) указан в составе этой ЭЦП. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ID подписи> указывается идентификатор ЭЦП ds:Signature/@Id
OPR5300	Сертификат квитанции проверен. Идентификатор электронного документа: <DocInstance>	выполняется только доверенной третьей стороной получателя. Выполнена проверка того, что сертификат ключа проверки ЭЦП доверенной третьей стороны отправителя изготовлен удостоверяющим центром службы доверенной третьей стороны, действителен на момент подписания квитанции доверенной третьей стороны отправителя, а также сертификат ключа проверки ЭЦП удостоверяющего центра службы доверенной третьей стороны действителен на момент подписания квитанции доверенной третьей стороны отправителя. В поле <DocInstance> указывается уникальный идентификатор электронного документа
OP10000	Квитанция ДТС сформирована. Идентификатор электронного документа: <DocInstance>; идентификатор квитанции: <ReceiptId>	выполнено формирование структуры квитанции, все поля квитанции успешно заполнены. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ReceiptId> указывается уникальный идентификатор квитанции (значение элемента rcpt:ReceiptId)
OP10100	Квитанция ДТС вложена в структуру электронного документа. Идентификатор электронного документа: <DocInstance>; идентификатор квитанции: <ReceiptId>	квитанция доверенной третьей стороны вложена в XML-структуру электронного документа. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ReceiptId> указывается уникальный идентификатор квитанции (значение элемента rcpt:ReceiptId)
OP10200	Сформировано ответное сообщение для интеграционного шлюза. Идентификатор электронного документа: <DocInstance>. Заголовки сообщения: wsa:To: <значение заголовка wsa:To>; wsa:From: <значение заголовка wsa:From>; wsa:Action: <значение заголовка wsa:Action>; wsa:MessageID: <значение заголовка wsa:MessageID>; wsa:RelatesTo: <значение заголовка wsa: RelatesTo>	сформировано ответное сообщение для интеграционного шлюза, содержащее электронный документ с вложенной квитанцией. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В полях типа <значение заголовка…> указываются значения соответствующих заголовков ответного SOAP-сообщения
OP10300	Cформировано технологическое сообщение об ошибке. Идентификатор электронного документа: <DocInstance>. Заголовки сообщения: wsa:To: <значение заголовка wsa:To>; wsa:From: <значение заголовка wsa:From>; wsa:Action: <значение заголовка wsa:Action>; wsa:MessageID: <значение заголовка wsa:MessageID>; wsa:RelatesTo: <значение заголовка wsa: RelatesTo>	сформировано технологическое сообщение об ошибке. В случае если технологическое сообщение об ошибке свидетельствует об операции, выполняемой после того, как документ взят в обработку (ОP1200), в поле <DocInstance> указывается уникальный идентификатор электронного документа, в противном случае идентификатор электронного документа не указывается. В полях типа <значение заголовка…> указываются значения соответствующих заголовков ответного SOAP-сообщения
OP10400	Сообщение для интеграционного шлюза успешно отправлено. Идентификатор электронного документа: <DocInstance>. Идентификатор сообщения wsa:MessageID: <значение заголовка wsa:MessageID>	ответное сообщение с электронным документом и квитанцией либо технологическое сообщение об ошибке успешно отправлено в интеграционный шлюз. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <значение заголовка wsa:MessageID> указывается значение заголовка wsa:MessageID ответного SOAP-сообщения
ERR1000	Тип транспортного сообщения определить не удалось	при считывании транспортного сообщения (OP1000) не удалось определить формат представления данных
ERR1100	Не удалось разобрать сообщение в формате SOAP. <Причина>. Уникальный идентификатор сообщения wsa:MessageID: <значение заголовка wsa:MessageID>	при выполнении разбора сообщения в формате SOAP (OP1100) возникла ошибка. В поле <Причина> указывается текстовое описание причины ошибки, если причину ошибки удалось определить: сообщение парсера XML об ошибке, уведомление об отсутствии требуемых заголовков сообщения в формате SOAP в соответствии с Правилами электронного обмена данными в интегрированной информационной системе внешней и взаимной торговли, утвержденными Решением Коллегии Евразийской экономической комиссии от 27 января 2015 г. № 5. В поле <значение заголовка wsa:MessageID> указывается значение соответствующего заголовка сообщения, если в процессе разбора сообщения его удалось считать
ERR1200	Ошибка обработки структуры электронного документа. <Причина>. Уникальный идентификатор сообщения wsa:MessageID: <значение заголовка wsa:MessageID>	При обработке электронного документа обнаружено, что его структура не соответствует установленым требованиям. В поле <Причина> указывается текстовое описание причины ошибки, если причину ошибки удалось определить: сообщение парсера XML об ошибке, сведения о некорректном заполнении атрибутов или элементов электронного документа. В поле <значение заголовка wsa:MessageID> указывается значение соответствующего заголовка сообщения
ERR1300	Ошибка проверки ЭЦП документа. <Причина>. Идентификатор электронного документа: <DocInstance>; идентификатор ЭЦП: <ID подписи>	при проверке ЭЦП электронного документа возникла ошибка. В поле <Причина> указывается текстовое описание причины ошибки, если причину ошибки удалось определить: несоответствие хэша, указанного в составе ЭЦП, хэшу, сформированному доверенной третьей стороной; недействующий сертификат ключа проверки ЭЦП; один из сертификатов удостоверяющих центров из цепочки сертификатов недействителен на момент подписания; ошибки проверки элементов и атрибутов ЭЦП в соответствии с требованиями стандарта XAdES (если ЭЦП сформирована согласно стандарту XAdES). В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ID подписи> доверенной третьей стороной отправителя указывается идентификатор ЭЦП, доверенной третьей стороной получателя – идентификатор квитанции
ERR1400	Ошибка проверки квитанции. <Причина>. Идентификатор электронного документа: <DocInstance>; идентификатор квитанции: <ReceiptId>	При проверке квитанции, включая ЭЦП квитанции, возникла ошибка. В поле <Причина> указывается текстовое описание причины ошибки: несоответствие хэша, указанного в составе ЭЦП, хэшу, сформированному доверенной третьей стороной; ошибка проверки значения ЭЦП, недействующий сертификат ключа проверки ЭЦП доверенной третьей стороны отправителя или удостоверяющего центра службы доверенной третьей стороны, ошибка проверки штампа времени в квитанции. В поле <DocInstance> указывается уникальный идентификатор электронного документа. В поле <ReceiptId> указывается уникальный идентификатор квитанции доверенной третьей стороны отправителя (значение элемента rcpt:ReceiptId)
ERR1500	Ошибка обращения к сервису штампа времени. <Причина>. Идентификатор электронного документа: <DocInstance>	при формировании квитанции возникла ошибка обращения к сервису штампа времени. В поле <Причина> указывается текстовое описание причины ошибки: сервис недоступен, сервис в качестве ответа возвратил ошибку (с указанием кода ошибки). В поле <DocInstance> указывается уникальный идентификатор электронного документа
ERR1600	Сообщение для интеграционного шлюза не удалось отправить. <Причина>. Уникальный идентификатор сообщения wsa:MessageID: <значение заголовка wsa:MessageID>	при попытке отправки сообщения возникла ошибка. В поле <Причина> указывается текстовое описание причины ошибки: сообщение не удалось поставить в очередь, транспортная подсистема или транспортный адаптер доверенной третьей стороны недоступен. В поле <значение заголовка wsa:MessageID> указывается значение соответствующего заголовка сообщения

Примечания:	1. Каждая запись журнала должна включать как минимум следующие поля: код логической операции (события); дата и время фиксации логической операции (события); текстовое описание выполненной логической операции (события).
	2. Допускается изменять степень детализации записи сведений в журнал аудита, включая перечень логических операций и событий, и текстовое описание записей в журнале.

I. Жалпы ережелер

II. Электрондық құжаттармен алмасуға қатысушылар

III. Электрондық құжаттармен алмасу

1. Электронды құжаттармен алмасу кезінде криптографиялық стандарттарға қойылатын талаптар

2. Электрондық құжаттармен алмасу тәртібі

3. Электрондық құжаттармен алмасу кезінде туындайтын штаттық емес жағдайларды шешу

IV. Дау-дамайлы жағдайларды шешу

Электрондық құжаттарды қалыптастыру мен өңдеуге қойылатын ТАЛАПТАР

Құжат атаулары кеңістіктерінің тізбесі

Электрондық құжаттың біріздендірілген құрылымы

Қамтылған электрондық құжат блогының құрылымы

Электрондық құжат деректерінің схемасы

Сенім білдірілген үшінші тараптың түбіртектерін қалыптастыруға және өңдеу тәртібіне қойылатын ТАЛАПТАР

Құжат атаулары кеңістігінің тізбесі

Алгоритмдердің сәйкестендіргіштері

Түбіртектің құрылымы

Түбіртектің негізгі деректемелері блогының құрылымы

XAdES форматында түбіртектің қосымша деректемелері блогының құрылымы

XML-блоктардың сәйкестендіргіштерін толтыру қағидалары

rcpt: Success элементінің құрылымы

rcpt: Error элементінің құрылымы

түбіртектің негізгі деректемелерінің ДЕРЕКТЕР СХЕМАСЫ

Сенім білдірілген үшінші тараппен өзара іс-қимыл кезінде пайдаланылатын хабарламалардың СИПАТТАМАСЫ

Құжат атаулары кеңістігінің тізбесі

MQMD тақырыбының жолдарын толтыру

Жөнелтушінің сенім білдірілген үшінші тарапының түбіртегін толтыру ҮЛГІСІ

Электрондық цифрлық қолтаңбаны (электрондық қолтаңбаны) қалыптастыру кезінде пайдаланылатын криптографиялық алгоритмдер сәйкестендіргіштерінің ТІЗБЕСІ

I. Общие положения

II. Участники обмена электронными документами

III. Обмен электронными документами

1. Требования к криптографическим стандартам при обмене электронными документами

2. Порядок обмена электронными документами

3. Разрешение нештатных ситуаций, возникающих при обмене электронными документами

IV. Разрешение конфликтных ситуаций

ТРЕБОВАНИЯ к формированию и обработке электронных документов

ТРЕБОВАНИЯ к формированию и порядку обработки квитанций доверенной третьей стороны

ОПИСАНИЕ сообщений, используемых при взаимодействии с доверенной третьей стороной

1. Требования к криптографическим стандартам при
обмене электронными документами

3. Разрешение нештатных ситуаций, возникающих при
обмене электронными документами

ТРЕБОВАНИЯ
к формированию и обработке электронных документов

ТРЕБОВАНИЯ
к формированию и порядку обработки квитанций
доверенной третьей стороны

ОПИСАНИЕ
сообщений, используемых при взаимодействии
с доверенной третьей стороной