Главная
Нормативно-правовые акты
Решение
Решение Коллегии Евразийской экономической комиссии от 28.09.2015 N 125 Об утверждении Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

Решение Коллегии Евразийской экономической комиссии от 28.09.2015 N 125

Актуальная версия документа в системе КонсультантПлюс

КОЛЛЕГИЯ ЕВРАЗИЙСКОЙ ЭКОНОМИЧЕСКОЙ КОМИССИИ

РЕШЕНИЕ

от 28 сентября 2015 г. N 125

ОБ УТВЕРЖДЕНИИ ПОЛОЖЕНИЯ

ОБ ОБМЕНЕ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ ПРИ ТРАНСГРАНИЧНОМ

ВЗАИМОДЕЙСТВИИ ОРГАНОВ ГОСУДАРСТВЕННОЙ ВЛАСТИ

ГОСУДАРСТВ - ЧЛЕНОВ ЕВРАЗИЙСКОГО ЭКОНОМИЧЕСКОГО

СОЮЗА МЕЖДУ СОБОЙ И С ЕВРАЗИЙСКОЙ

ЭКОНОМИЧЕСКОЙ КОМИССИЕЙ

В соответствии с пунктами 3, 4 и 30 Протокола об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение N 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года) Коллегия Евразийской экономической комиссии решила:

1. Утвердить прилагаемое Положение об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией.

2. Государствам - членам Евразийского экономического союза обеспечить закрепление в своем законодательстве возможности обмена электронными документами между используемыми государствами-членами системами электронного документооборота при взаимодействии органов государственной власти государств-членов между собой и с Евразийской экономической комиссией с использованием интегрированной информационной системы Евразийского экономического союза.

3. Настоящее Решение вступает в силу по истечении 30 календарных дней с даты его официального опубликования.

Председатель Коллегии

Евразийской экономической комиссии

В.ХРИСТЕНКО

Утверждено

Решением Коллегии Евразийской

экономической комиссии

от 28 сентября 2015 г. N 125

ПОЛОЖЕНИЕ

ОБ ОБМЕНЕ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ ПРИ ТРАНСГРАНИЧНОМ

ВЗАИМОДЕЙСТВИИ ОРГАНОВ ГОСУДАРСТВЕННОЙ ВЛАСТИ

ГОСУДАРСТВ - ЧЛЕНОВ ЕВРАЗИЙСКОГО ЭКОНОМИЧЕСКОГО

СОЮЗА МЕЖДУ СОБОЙ И С ЕВРАЗИЙСКОЙ

ЭКОНОМИЧЕСКОЙ КОМИССИЕЙ

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

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

2. Понятия, используемые в настоящем Положении, означают следующее:

"XML" - рекомендованный Консорциумом Всемирной паутины (W3C) расширяемый язык разметки;

"XML-документ" - совокупность данных, соответствующая требованиям XML;

"каноникализация XML" - процесс преобразования XML-документов в каноническую форму XML;

"квитанция доверенной третьей стороны" - электронный документ, формируемый доверенной третьей стороной и подписанный электронной цифровой подписью (электронной подписью) доверенной третьей стороны, служащий для подтверждения результата проверки подлинности электронного документа и электронной цифровой подписи (электронной подписи) в электронном документе;

"криптографический стандарт" - совокупность технических спецификаций, устанавливающих правила формирования и проверки электронных цифровых подписей (электронных подписей);

"отправитель" - участник обмена электронными документами, который направляет или от имени которого направляется электронный документ;

"получатель" - участник обмена электронными документами, которому отправлен электронный документ;

"сегмент отправителя", "сегмент получателя" - национальный сегмент государства-члена или интеграционный сегмент Комиссии, информационные системы которых используются для отправки (приема) электронных документов отправителем (получателем);

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

"служба доверенной третьей стороны интегрированной системы" - совокупность сервисов доверенной третьей стороны государств-членов и Комиссии, обеспечивающих единое трансграничное пространство доверия при обмене электронными документами в интегрированной системе;

"сообщение" - формализованная информация, передающаяся от отправителя к получателю в интегрированной системе;

"стандарт X.509" - стандарт ITU-T X.509 "Информационные технологии. Взаимосвязь открытых систем. Справочник: Структуры сертификатов открытых ключей и атрибутов";

"стандарт XAdES" - стандарт XML Advanced Electronic Signature, описывающий расширенный формат электронной цифровой подписи (электронной подписи) в формате XML;

"стандарт XMLDSig" - стандарт синтаксиса и обработки электронной цифровой подписи (электронной подписи) в формате XML;

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

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

"юридическая значимость электронного документа" - свойство электронного документа, позволяющее воспринимать содержание данного электронного документа как подлинное.

Иные понятия, используемые в настоящем Положении, применяются в значениях, определенных Протоколом об информационно-коммуникационных технологиях и информационном взаимодействии в рамках Евразийского экономического союза (приложение N 3 к Договору о Евразийском экономическом союзе от 29 мая 2014 года) (далее - Протокол).

3. Отношения, возникающие в связи с обменом электронными документами, регулируются Договором о Евразийском экономическом союзе от 29 мая 2014 года, иными международными договорами, входящими в право Союза, настоящим Положением, утверждаемыми Комиссией технологическими документами, регламентирующими информационное взаимодействие при реализации средствами интегрированной системы общих процессов в рамках Союза (далее - технологические документы, регламентирующие информационное взаимодействие), а также законодательством государств-членов.

4. Технологические документы, регламентирующие информационное взаимодействие, разрабатываются в соответствии с Решением Коллегии Евразийской экономической комиссии от 6 ноября 2014 г. N 200.

5. Требования к оформлению электронных документов определены согласно приложениям N 1 - 4.

Электронные документы, оформленные в соответствии с настоящим Положением, с учетом требований, определенных приложениями N 1 - 4 к настоящему Положению, признаются равнозначными документам, оформленным на бумажном носителе и заверенным подписью или подписью и печатью.

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

6. Участниками обмена электронными документами в рамках интегрированной системы являются:

а) Комиссия;

б) уполномоченные органы или определенные (аккредитованные) ими организации;

в) доверенные третьи стороны государств-членов и Комиссии;

г) удостоверяющие центры государств-членов и Комиссии, удостоверяющий центр службы доверенной третьей стороны интегрированной системы;

д) организации - операторы интеграционных шлюзов национальных сегментов государств-членов и интеграционного сегмента Комиссии;

е) должностные лица и сотрудники Комиссии, доверенных третьих сторон, уполномоченных органов или определенных (аккредитованных) ими организаций, а также удостоверяющих центров государств-членов и Комиссии, которые участвуют в обмене электронными документами от своего имени.

7. Определение состава участников обмена электронными документами осуществляется:

а) государствами-членами - в отношении уполномоченных органов, доверенной третьей стороны, удостоверяющих центров, организации - оператора интеграционного шлюза национального сегмента этого государства-члена;

б) уполномоченными органами или определенными (аккредитованными) ими организациями - в отношении должностных лиц и сотрудников этих уполномоченных органов или организаций;

в) Комиссией - в отношении доверенной третьей стороны Комиссии, удостоверяющего центра Комиссии, удостоверяющего центра службы доверенной третьей стороны интегрированной системы, должностных лиц этих органов, а также в отношении должностных лиц и сотрудников Комиссии.

8. Участниками обмена электронными документами осуществляются следующие функции:

а) отправителем - подготовка электронного документа, его подписание ЭЦП и отправка получателю;

б) получателем - прием и обработка полученных от отправителя электронного документа и квитанции доверенной третьей стороны получателя для проверки подлинности электронного документа отправителя;

в) организациями - операторами интеграционных шлюзов интегрированной системы - обеспечение трансграничной передачи электронных документов, а также проверка квитанций доверенных третьих сторон в целях недопущения передачи неподлинных электронных документов, которые заведомо не должны или не могут быть обработаны получателем;

г) доверенной третьей стороной отправителя - проверка подлинности электронного документа и ЭЦП электронного документа, формирование и подписание квитанции доверенной третьей стороны отправителя с результатом проверки;

д) доверенной третьей стороной получателя - проверка подлинности электронного документа в соответствии с квитанцией доверенной третьей стороны отправителя и ЭЦП в этой квитанции, формирование и подписание квитанции доверенной третьей стороны получателя с результатом проверки;

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

ж) удостоверяющим центром службы доверенной третьей стороны - выдача сертификатов доверенным третьим сторонам государств-членов, предоставление сервисов для проверки актуальности выданных сертификатов и сервиса штампа времени.

9. Участники обмена электронными документами обязаны:

а) соблюдать настоящее Положение в процессе обмена электронными документами;

б) информировать друг друга обо всех случаях возникновения технических неисправностей в работе программно-аппаратных средств или о других обстоятельствах, препятствующих обмену электронными документами;

в) при возникновении конфликтных ситуаций участвовать в их разрешении;

г) обеспечивать защиту информации при обмене электронными документами в соответствии с требованиями актов Комиссии и законодательства государств-членов;

д) использовать средства ЭЦП, имеющие сертификаты соответствия, выданные согласно законодательству соответствующего государства-члена.

10. Требования к участникам обмена электронными документами при необходимости могут уточняться после утверждения Комиссией требований к созданию, развитию и функционированию трансграничного пространства доверия, предусмотренных пунктом 18 Протокола, а актуализация настоящего Положения будет проводиться после принятия локализованных версий необходимых международных стандартов и рекомендаций, а также утверждения Комиссией правил документирования информации при взаимодействии между уполномоченными органами, хозяйствующими субъектами и физическими лицами государств-членов.

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

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

электронными документами

11. При обмене электронными документами участниками такого обмена используются следующие криптографические стандарты:

а) при взаимодействии между отправителями (получателями) и доверенной третьей стороной в рамках одного национального сегмента государства-члена - криптографические стандарты этого государства-члена;

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

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

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

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

14. Оформление электронных документов, предусмотренных технологическими документами, регламентирующими информационное взаимодействие, в соответствии с требованиями, определенными приложением N 1 к настоящему Положению, выполняется на основании значения параметра "признак ЭЦП" (принимает значение "да" или "нет"), указанного для каждой транзакции общего процесса в регламенте информационного взаимодействия между участниками общего процесса при реализации средствами интегрированной системы общего процесса.

В случае если параметр принимает значение "да", то данные, передаваемые в рамках транзакций общих процессов, оформляются в виде электронных документов. Данные, передаваемые посредством сигналов-исключений, сигналов-подтверждений и служебных сообщений, не оформляются в виде электронных документов, если иное не определено технологическими документами, регламентирующими информационное взаимодействие, или актами, входящими в право Союза.

В случае если параметр принимает значение "нет", требования настоящего Положения к электронному обмену данными в рамках транзакции общего процесса не применяются.

15. В процессе обмена электронными документами интеграционные шлюзы и сервисы доверенных третьих сторон в пределах национального сегмента государства-члена (интеграционного сегмента Комиссии) обмениваются сообщениями, составленными в соответствии с описанием согласно приложению N 5 и передаваемыми посредством протокола электронного обмена данными в соответствии с описанием согласно приложению N 6.

16. Отправителем выполняются следующие действия:

а) формируется и подписывается электронный документ;

б) оформляется электронный документ в виде сообщения;

в) отправляется сообщение для получателя в интеграционный шлюз отправителя.

17. Интеграционным шлюзом отправителя принимается сообщение от отправителя и формируется новое сообщение для доверенной третьей стороны отправителя, в которое вкладывается полученный электронный документ. Интеграционным шлюзом отправителя сформированное сообщение передается доверенной третьей стороне отправителя.

18. Доверенной третьей стороной отправителя принимается поступившее от интеграционного шлюза отправителя сообщение и для каждой ЭЦП в электронном документе проверяется соблюдение следующих требований в совокупности:

а) целостность данных, подписываемых ЭЦП, не нарушена;

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

в) сертификат ключа проверки ЭЦП действителен на момент подписания электронного документа;

г) каждый сертификат удостоверяющего центра из цепочки сертификатов действителен на момент подписания.

19. По результатам проверки электронного документа доверенной третьей стороной отправителя формируется квитанция доверенной третьей стороны отправителя в соответствии с требованиями, определенными приложением N 3 к настоящему Положению, и образцом согласно приложению N 7. Квитанция доверенной третьей стороны отправителя подписывается ЭЦП доверенной третьей стороны отправителя в соответствии с криптографическим стандартом службы доверенной третьей стороны интегрированной системы. Для идентификации криптографического стандарта службы доверенной третьей стороны в структуре квитанции используются идентификаторы алгоритмов по перечню согласно приложению N 8.

20. Временем отправления электронного документа является время подписания доверенной третьей стороной отправителя квитанции доверенной третьей стороны отправителя своей ЭЦП с соответствующим штампом времени в самой квитанции.

21. Доверенной третьей стороной отправителя формируется сообщение для интеграционного шлюза отправителя, в которое вкладываются электронный документ и квитанция доверенной третьей стороны отправителя, и передается в интеграционный шлюз отправителя.

22. Интеграционным шлюзом отправителя принимается сообщение от доверенной третьей стороны отправителя.

23. В случае если квитанция доверенной третьей стороны отправителя свидетельствует об отрицательном результате проверки подлинности электронного документа или ЭЦП в электронном документе, то интеграционным шлюзом отправителя формируется сообщение об ошибке по причине отрицательного результата проверки ЭЦП, которое направляется отправителю.

В случае если сообщение об ошибке формируется интеграционным шлюзом интеграционного сегмента Комиссии, оно должно представлять собой технологическое сообщение об ошибке с кодом "int:ReceiptError" в соответствии с Правилами электронного обмена данными.

В случае если сообщение об ошибке формируется интеграционным шлюзом национального сегмента государства-члена, требования к структуре сообщения об ошибке определяются государством-членом.

24. В случае если квитанция доверенной третьей стороны отправителя свидетельствует о положительном результате проверки подлинности электронного документа и ЭЦП в электронном документе, то интеграционным шлюзом отправителя выполняются следующие действия:

а) вложение электронного документа и квитанции доверенной третьей стороны отправителя в сообщение, блок заголовков которого соответствует блоку заголовков сообщения, полученного интеграционным шлюзом отправителя в соответствии с пунктом 17 настоящего Положения;

б) передача сообщения в интеграционный шлюз получателя.

25. Интеграционным шлюзом получателя принимается от интеграционного шлюза отправителя сообщение и формируется новое сообщение для доверенной третьей стороны получателя, в которое вкладываются полученный электронный документ и квитанция доверенной третьей стороны отправителя. Сформированное сообщение передается интеграционным шлюзом получателя доверенной третьей стороне получателя.

26. Доверенной третьей стороной получателя принимается поступившее от интеграционного шлюза получателя сообщение и проверяется соблюдение следующих требований в совокупности:

а) в сообщение вложена квитанция доверенной третьей стороны отправителя;

б) целостность электронного документа, на который сформирована квитанция доверенной третьей стороны отправителя, не нарушена;

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

г) сертификат ключа проверки ЭЦП доверенной третьей стороны отправителя изготовлен удостоверяющим центром службы доверенной третьей стороны интегрированной системы и действителен на момент подписания квитанции доверенной третьей стороны отправителя;

д) сертификат ключа проверки ЭЦП удостоверяющего центра службы доверенной третьей стороны интегрированной системы действителен на момент подписания квитанции доверенной третьей стороны отправителя;

е) квитанция доверенной третьей стороны отправителя свидетельствует о положительном результате проверки подлинности электронного документа и ЭЦП в электронном документе.

27. По результатам проверки электронного документа и квитанции доверенной третьей стороны отправителя формируется квитанция доверенной третьей стороны получателя, которая подписывается ЭЦП в соответствии с криптографическим стандартом юрисдикции получателя. Квитанция доверенной третьей стороны отправителя включается в состав квитанции доверенной третьей стороны получателя. Обработка доверенной третьей стороной получателя квитанции доверенной третьей стороны отправителя и формирование квитанции для получателя осуществляются в соответствии с требованиями, определенными приложением N 3 к настоящему Положению. Для идентификации криптографического стандарта государства-члена, в котором находится получатель электронного документа, в структуре квитанции используются идентификаторы алгоритмов, предусмотренные приложением N 8 к настоящему Положению.

28. Временем получения электронного документа является время подписания доверенной третьей стороной получателя квитанции доверенной третьей стороны получателя своей ЭЦП с соответствующим штампом времени в самой квитанции.

29. Доверенной третьей стороной получателя формируется сообщение, в которое вкладываются электронный документ и квитанция доверенной третьей стороны получателя, и передается в интеграционный шлюз получателя.

30. Интеграционным шлюзом получателя принимается сообщение от доверенной третьей стороны получателя.

31. В случае если квитанция доверенной третьей стороны получателя свидетельствует об отрицательном результате проверки подлинности электронного документа или ЭЦП в квитанции доверенной третьей стороны отправителя, то интеграционным шлюзом получателя формируется технологическое сообщение об ошибке с кодом "int:ReceiptError" в соответствии с Правилами электронного обмена данными, которое направляется отправителю.

32. В случае если квитанция доверенной третьей стороны получателя свидетельствует о положительном результате проверки подлинности электронного документа и ЭЦП в квитанции доверенной третьей стороны отправителя, то интеграционным шлюзом получателя выполняются следующие действия:

а) вложение электронного документа и квитанции доверенной третьей стороны получателя в сообщение, блок заголовков которого соответствует блоку заголовков сообщения, полученного от интеграционного шлюза отправителя в соответствии с пунктом 25 настоящего Положения;

б) передача сообщения получателю.

33. Получателем принимается поступившее от интеграционного шлюза получателя сообщение и проверяется соблюдение следующих требований в совокупности:

а) в сообщение вложена квитанция доверенной третьей стороны получателя;

б) целостность электронного документа, на который сформирована квитанция доверенной третьей стороны получателя, не нарушена;

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

г) сертификат ключа проверки ЭЦП доверенной третьей стороны получателя действителен на момент подписания квитанции;

д) квитанция доверенной третьей стороны получателя свидетельствует о положительном результате проверки подлинности электронного документа.

34. Решение об обработке электронного документа принимается получателем, если подтверждено соблюдение всех требований, предусмотренных пунктом 33 настоящего Положения. В ином случае принимается решение об отказе в обработке электронного документа.

35. В случае если получателем принято решение об отказе в обработке электронного документа, он уведомляет об этом отправителя путем направления отправителю сигнала-исключения "Ошибка" с кодом "Signature:Error", сформированного в соответствии с Правилами электронного обмена данными.

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

электронными документами

36. Нештатной признается ситуация, возникающая при обмене электронными документами, при которой обработка данных по причине технических сбоев, несоответствия структуры электронных документов или сообщений установленным правилам либо по другим основаниям не может быть произведена в установленном порядке.

37. Разрешением нештатных ситуаций занимаются технические подразделения доверенных третьих сторон и организаций - операторов интеграционных шлюзов.

38. В каждом сегменте интегрированной системы создаются свои технические подразделения, обеспечивающие разрешение нештатных ситуаций.

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

а) несоответствие формата и структуры сообщения требованиям, определенным приложением N 5 к настоящему Положению;

б) несоответствие формата и структуры электронного документа, вложенного в сообщение, требованиям, определенным приложением N 1 к настоящему Положению, и схеме данных, предусмотренной приложением N 2 к настоящему Положению;

в) несоответствие формата и структуры квитанции доверенной третьей стороны отправителя, вложенной в сообщение, требованиям, определенным приложением N 3 к настоящему Положению;

г) ошибки, возникшие в процессе обработки сообщения или входящих в состав сообщения структур данных.

40. Формирование технологических сообщений об ошибке осуществляется в соответствии с приложением N 5 к настоящему Положению.

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

42. К формату и структуре указанного в пункте 41 настоящего Положения сообщения об ошибке предъявляются следующие требования:

а) в случае если сообщение об ошибке формируется интеграционным шлюзом получателя, оно должно представлять собой технологическое сообщение об ошибке с кодом "int:InternalError" в соответствии с Правилами электронного обмена данными;

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

43. В рамках функционирования интегрированной системы организуется взаимодействие между техническими подразделениями доверенных третьих сторон и организаций - операторов интеграционных шлюзов.

44. В целях разрешения нештатных ситуаций каждой доверенной третьей стороной ведется журнал аудита, содержащий информацию о приеме, обработке, отправке сообщений и электронных документов, а также о формировании квитанций доверенной третьей стороны, в соответствии с перечнем логических операций и событий согласно приложению N 9.

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

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

46. Конфликтные ситуации подлежат разрешению в соответствии с порядком разрешения конфликтных ситуаций, утверждаемым Комиссией.

Приложение N 1

к Положению об обмене

электронными документами

при трансграничном взаимодействии

органов государственной

власти государств - членов

Евразийского экономического

союза между собой и с Евразийской

экономической комиссией

ТРЕБОВАНИЯ

К ФОРМИРОВАНИЮ И ОБРАБОТКЕ ЭЛЕКТРОННЫХ ДОКУМЕНТОВ

1. Электронные документы, используемые при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза (далее соответственно - государства-члены, Союз) между собой и с Евразийской экономической комиссией в интегрированной информационной системе внешней и взаимной торговли и создаваемой на основе расширения ее функциональных возможностей интегрированной информационной системе Союза (далее соответственно - электронные документы, интегрированная система), имеют унифицированную структуру.

2. Унифицированная структура электронного документа содержит следующие основные элементы (блоки):

а) контейнер электронного документа;

б) одна или несколько электронных цифровых подписей (электронных подписей) (далее - ЭЦП);

в) структуры видов электронных документов (сведений);

г) квитанция доверенной третьей стороны, вкладываемая в контейнер электронного документа при передаче электронного документа через интегрированную систему.

3. Структуры видов электронных документов (сведений) определяются утверждаемыми Евразийской экономической комиссией для каждого общего процесса в рамках Союза технологическими документами, регламентирующими информационное взаимодействие при реализации средствами интегрированной системы общих процессов в рамках Союза, разработанными в соответствии с Решением Коллегии Евразийской экономической комиссии от 6 ноября 2014 г. N 200 (далее - технологические документы, регламентирующие информационное взаимодействие).

4. При описании унифицированной структуры электронного документа используются пространства имен, перечень которых приведен в таблице 1.

Таблица 1

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

Префикс

Адрес

doc

urn:EEC:SignedData:v1.0:EDoc

http://www.w3.org/2000/09/xmldsig#

http://www.w3.org/2001/XMLSchema

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

Таблица 2

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

Элемент

Тип данных

Описание

Кратность

doc:SignedDoc

doc:SignedDocType

контейнер электронного документа

doc:Data

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

doc:DataType

ds: Signature

квитанция доверенной третьей стороны

ds:SignatureType

0..1

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

Таблица 3

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

Элемент

Тип данных

Описание

Кратность

doc:Data

doc:DataType

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

@Id

xs:ID

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

ds: Signature

ds:SignatureType

ЭЦП электронного документа

1..*

doc:SignedContent

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

@Id

xs:ID

атрибут-идентификатор блока подписываемых данных

@DocInstance

xs:anyURI

уникальный идентификатор электронного документа

Структуры видов электронных документов (сведений)

определяется типами структур электронных документов (сведений)

одна или несколько структур видов электронных документов (сведений)

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. "А 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 г. N 5, а также в соответствии с требованиями технологических документов, регламентирующих информационное взаимодействие, с учетом следующих положений:

а) стадия структурного контроля блока содержимого включает в себя проверку унифицированной структуры электронного документа по XSD-схеме, а также проверку структур видов электронных документов (сведений);

б) операция проверки квитанции доверенной третьей стороны получателя должна выполняться после выполнения стадии структурного контроля блока содержимого;

в) если в соответствии с порядком информационного взаимодействия, в рамках которого передается электронный документ, предусмотрена передача получателю сигнала-подтверждения "Получено", то операция проверки квитанции доверенной третьей стороны выполняется после отправки такого сигнала-подтверждения.

Приложение N 2

к Положению об обмене

электронными документами

при трансграничном взаимодействии

органов государственной

власти государств - членов

Евразийского экономического

союза между собой и с Евразийской

экономической комиссией

СХЕМА ДАННЫХ ЭЛЕКТРОННОГО ДОКУМЕНТА

Приложение N 3

к Положению об обмене

электронными документами

при трансграничном взаимодействии

органов государственной

власти государств - членов

Евразийского экономического

союза между собой и с Евразийской

экономической комиссией

ТРЕБОВАНИЯ

К ФОРМИРОВАНИЮ И ПОРЯДКУ ОБРАБОТКИ КВИТАНЦИЙ ДОВЕРЕННОЙ

ТРЕТЬЕЙ СТОРОНЫ

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

2. При описании требований к формированию и порядку обработки квитанции используются пространства имен, перечень которых приведен в таблице 1.

Таблица 1

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

Префикс

Адрес

rcpt

urn:EEC:TTP:v1.0:receipt

doc

urn:EEC:SignedData:v1.0:EDoc

http://www.w3.org/2000/09/xmldsig#

xades

http://uri.etsi.org/01903/v1.3.2#

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

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

@Id

xs:ID

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

ds:SignedInfo

ds:SignedInfoType

оборачивающий элемент блока подписанных данных

ds:CanonicalizationMethod

ds:CanonicalizationMethodType

оборачивающий элемент алгоритма каноникализации XML

@Algorithm

xs:anyURI

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

ds:SignatureMethod

ds:SignatureMethodType

оборачивающий элемент алгоритма формирования ЭЦП

@Algorithm

xs:anyURI

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

ds:Reference

ds:ReferenceType

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

@URI

xs:anyURI

атрибут-ссылка на XML-элемент блока манифеста

@Type

xs:anyURI

атрибут, идентифицирующий блок ds:Reference в качестве ссылки на манифест. Заполняется значением "http://www.w3.org/2000/09/xmldsig#Manifest"

ds:Transforms

ds:TransformsType

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

ds:Transform

ds:TransformType

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

@Algorithm

xs:anyURI

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

ds:DigestMethod

ds:DigestMethodType

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

@Algorithm

xs:anyURI

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

ds:DigestValue

ds:DigestValueType

значение хэш-суммы манифеста после проведения каноникализации XML

ds:Reference

ds:ReferenceType

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

@URI

xs:anyURI

атрибут-ссылка на XML-элемент блока основных реквизитов квитанции, уникальных в рамках сообщения, приведенных в таблице 4

@Type

xs:anyURI

атрибут, идентифицирующий блок ds:Reference в качестве ссылки на блок основных реквизитов квитанции. Заполняется значением "urn:EEC:TTP:v1.0:receipt:details"

ds:Transforms

ds:TransformsType

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

ds:Transform

ds:TransformType

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

@Algorithm

xs:anyURI

ds:DigestMethod

ds:DigestMethodType

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

@Algorithm

xs:anyURI

ds:DigestValue

ds:DigestValueType

значение хэш-суммы блока основных реквизитов квитанции после проведения каноникализации XML

ds:Reference

ds:ReferenceType

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

@URI

xs:anyURI

атрибут-ссылка на XML-элемент блока дополнительных реквизитов квитанции в формате XAdES, приведенных в таблице 5

@Type

xs:anyURI

атрибут, идентифицирующий блок ds:Reference в качестве ссылки на блок дополнительных реквизитов квитанции в формате XAdES. Заполняется значением "http://uri.etsi.org/01903#SignedProperties"

ds:Transforms

ds:TransformsType

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

ds:Transform

ds:TransformType

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

@Algorithm

xs:anyURI

ds:DigestMethod

ds: DigestMethodType

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

@Algorithm

xs:anyURI

ds:DigestValue

ds:DigestValueType

значение хэш-суммы блока дополнительных реквизитов квитанции в формате XAdES после проведения каноникализации XML

ds:SignatureValue

ds:SignatureValueType

значение ЭЦП, рассчитанное для элемента dsISignedInfo квитанции после проведения каноникализации XML

ds:KeyInfo

ds:KeyInfoType

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

ds:X509Data

ds:X509DataType

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

ds:X509Certificate

xs:base64Binary

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

ds:Object

ds:ObjectType

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

ds: Manifest

ds:ManifestType

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

@Id

xs:ID

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

ds:Reference

ds:ReferenceType

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

@URI

xs:anyURI

атрибут-ссылка на XML-элсмент блока содержимого электронного документа. Должен содержать ссылку на doc:SignedDoc/doc:Data/@Id электронного документа, для которого формируется квитанция

ds:Transforms

ds:TransformsType

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

ds:Transform

ds:TransformType

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

@Algorithm

xs:anyURI

ds:DigestMethod

ds:DigestMethodType

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

@Algorithm

xs:anyURI

ds:DigestValue

ds: Digest ValueType

значение хэш-суммы подписываемого электронного документа после проведения каноникализации XML, формируемого в соответствии с пунктом 17 настоящего документа

rcpt: Receipt

rcpt: ReceiptType

блок основных реквизитов квитанции. Описание блока приведено в таблице 4

xades:QualifyingProperties

xades:QualifyingPropertiesType

блок дополнительных реквизитов квитанции в формате XAdES. Описание блока приведено в таблице 5

Таблица 4

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

Элемент

Тип данных

Описание

Кратность

rcpt: Receipt

rcpt:ReceiptType

оборачивающий элемент блока основных реквизитов квитанции

@Id

xs:ID

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

rcpt:ReceiptId

xs:anyURI

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

rcpt:DocId

xs:anyURI

идентификатор электронного документа, на который сформирована квитанция. Правила формирования идентификаторов приведены в пункте 6 настоящего документа

rcpt:Report

блок сведений о результатах проверки. Правила формирования блока приведены в пунктах 7 - 12 настоящего документа

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

идентификатор алгоритма вычисления хэш-суммы для квитанции. Перечень идентификаторов приведен в приложении N 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:SignatureProductionPlaceType

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

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 настоящего документа. При формировании штампа времени идентификаторы криптографических алгоритмов должны указываться в соответствии с правилами, предусмотренными приложением N 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:Data/doc:SignedContent/@DocInstance".

7. Блок сведений о результатах проверки (rcpt:Report) должен содержать один или несколько элементов rcpt:Success и rcpt:Error, свидетельствующих о результатах проверок, выполненных доверенной третьей стороной. Структура элементов rcpt:Success и rcpt:Error приведена в таблицах 7 - 8.

Таблица 7

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

Элемент

Тип данных

Описание

Кратность

rcpt:Success

rcpt:SuccessType

элемент, указывающий, что проверка выполнена успешно

@Reference

xs:anyURI

идентификатор проверяемого объекта

0..1

Таблица 8

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

Элемент

Тип данных

Описание

Кратность

rcpt:Error

rcpt:ErrorType

элемент, указывающий, что при проверке возникла ошибка

@Reference

xs:anyURI

идентификатор проверяемого объекта

0..1

rcpt:ReasonCode

xs:string

код ошибки

rcpt:ReasonText

xs:string

текстовое описание ошибки

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 г. N 125;

в) если все проверки ЭЦП выполнены успешно, то доверенной третьей стороной отправителя формируется блок rcpt: Success, в противном случае формируется блок rcpt:Error;

г) выполняется поиск следующей ЭЦП в электронном документе. Если ЭЦП найдена, действия, указанные в подпунктах "б" - "г" настоящего пункта, повторяются.

12. Доверенной третьей стороной получателя должен быть реализован следующий алгоритм формирования содержимого блока сведений о результатах проверки rcpt:Report:

а) выполняется поиск квитанции доверенной третьей стороны получателя в составе электронного документа;

б) для найденной квитанции выполняются проверки, предусмотренные подразделом 2 раздела III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. N 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:Data электронного документа, включая сам XML-тег doc:Data, его атрибуты и все элементы-потомки (рисунок 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 г. N 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 ЭЦП квитанции при проверке не обрабатывается.

Приложение N 4

к Положению об обмене

электронными документами

при трансграничном взаимодействии

органов государственной

власти государств - членов

Евразийского экономического

союза между собой и с Евразийской

экономической комиссией

СХЕМА ДАННЫХ ОСНОВНЫХ РЕКВИЗИТОВ КВИТАНЦИИ

Приложение N 5

к Положению об обмене

электронными документами

при трансграничном взаимодействии

органов государственной

власти государств - членов

Евразийского экономического

союза между собой и с Евразийской

экономической комиссией

ОПИСАНИЕ

СООБЩЕНИЙ, ИСПОЛЬЗУЕМЫХ ПРИ ВЗАИМОДЕЙСТВИИ С ДОВЕРЕННОЙ

ТРЕТЬЕЙ СТОРОНОЙ

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

Все сообщения относятся к классу служебных сообщений интегрированной системы.

2. При описании сообщений используются пространства имен, перечень которых приведен в таблице.

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

Префикс

Адрес

ttp

urn:EEC:TTP:v1.0

soap

в соответствии с Правилами электронного обмена данными

wsa

в соответствии с Правилами электронного обмена данными

3. К сообщениям, поступающим доверенной третьей стороне, предъявляются следующие общие требования:

а) элемент заголовка wsa:To должен содержать логический адрес сервиса доверенной третьей стороны, обеспечивающего проверки, предусмотренные Положением об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденным Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. N 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 входящего сообщения;

в) в случае если технологическое сообщение об ошибке свидетельствует о возникновении одной из типовых ошибок, предусмотренных Правилами электронного обмена данными, элементам soap:Code/soap:Value и soap: Subcode/soap:Value должны быть присвоены значения, определенные Правилами электронного обмена данными;

г) в случае если технологическое сообщение об ошибке свидетельствует о несоответствии структуры тела сообщения требованиям, предъявляемым к входящим сообщениям, элементу soap:Code/soap:Value должно быть присвоено значение "soap:Sender", а элементу soap:Subcode/soap:Value - значение "ttp:InvalidAppData";

д) элемент тела сообщения soap:Fault/soap:Detail должен содержать SOAP-конверт вместе с содержимым тела и заголовками входящего сообщения, оформленный в соответствии с Правилами электронного обмена данными.

Приложение N 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_DEF AULT).

10. В случае если данные, передаваемые посредством транспортных сообщений, представлены в формате MIME-сообщения, для идентификации наличия двоичного вложения в группе заголовков MQRFH2 в папке <usr> должен присутствовать заголовок contentType, который должен иметь строковое значение "Multipart/Related; bondary=<идентификатор границы MIME-блока>;".

11. В случае если данные, передаваемые посредством транспортных сообщений, представлены в виде SOAP-сообщения, в группе заголовков MQRFH2 в папке <usr> должен присутствовать заголовок contentType, который должен иметь строковое значение "application/soap+xml".

Приложение N 7

к Положению об обмене

электронными документами

при трансграничном взаимодействии

органов государственной

власти государств - членов

Евразийского экономического

союза между собой и с Евразийской

экономической комиссией

ОБРАЗЕЦ ЗАПОЛНЕНИЯ КВИТАНЦИИ

ДОВЕРЕННОЙ ТРЕТЬЕЙ СТОРОНЫ ОТПРАВИТЕЛЯ

Приложение N 8

к Положению об обмене

электронными документами

при трансграничном взаимодействии

органов государственной

власти государств - членов

Евразийского экономического

союза между собой и с Евразийской

экономической комиссией

ПЕРЕЧЕНЬ

ИДЕНТИФИКАТОРОВ КРИПТОГРАФИЧЕСКИХ АЛГОРИТМОВ, ИСПОЛЬЗУЕМЫХ

ПРИ ФОРМИРОВАНИИ ЭЛЕКТРОННОЙ ЦИФРОВОЙ ПОДПИСИ

(ЭЛЕКТРОННОЙ ПОДПИСИ)

URI-идентификатор

OID-идентификатор

Наименование стандарта

I. Для алгоритмов вычисления значения ЭЦП

1. http://www.w3.org/2001/04/xmld sig-more#gostr3 410

1.2.398.3.10.1.1.1.2

ГОСТ 34.310-2004 "Информационная технология. Криптографическая защита информации. Процессы формирования и проверки электронной цифровой подписи"

2. http://www.w3.org/2001/04/xmld sig-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. um: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

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

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 "Информационные технологии и безопасность. Криптографические алгоритмы шифрования и контроля целостности"

Приложение N 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:Receipt!d)

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>

сформировано технологическое сообщение об ошибке. В случае если технологическое сообщение об ошибке свидетельствует об операции, выполняемой после того, как документ взят в обработку (OP1200), в поле <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 г. N 5. В поле <значение заголовка wsa:MessageID> указывается значение соответствующего заголовка сообщения, если в процессе разбора сообщения его удалось считать

ERR 1200

Ошибка обработки структуры электронного документа. <Причина>. Уникальный идентификатор сообщения 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. Допускается изменять степень детализации записи сведений в журнал аудита, включая перечень логических операций и событий, и текстовое описание записей в журнале.

Другие документы по теме

Решение Верховного Суда РФ от 22.04.2002 N ГКПИ2002-334, 382

<Об отказе в удовлетворении жалобы о признании частично недействительными Правил предоставления коммунальных услуг, утвержденных Постановлением Правительства РФ от 26.09.1994 N 1099>

Решение Правления ФСЕМТ РФ от 05.10.1998 N 3/1-ж/д

<Об установлении льготных железнодорожных тарифов на перевозки картофеля, овощей, фруктов, рыбы и рыбопродуктов>

Решение Коллегии Евразийской экономической комиссии от 15.10.2013 N 221

"Об одобрении плана проведения мероприятий по сотрудничеству Евразийской экономической комиссии и Европейской экономической комиссии ООН на 2013 - 2015 годы"

Решение Верховного Суда РФ от 12.10.2001 N ГКПИ01-1340

<Об оставлении без удовлетворения жалобы о признании незаконными положений пунктов 2 и 7 Постановления Правительства РФ от 17.09.1992 N 723 "Об организационных мерах по выполнению Постановления Верховного Совета РСФСР "О порядке введения в действие Закона РСФСР "О милиции">