В соответствии с пунктами 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"?> |
ПРИЛОЖЕНИЕ № 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, формируемого |
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 |
идентификатор алгоритма вычисления |
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 |
оборачивающий элемент места (сегмента) формирования квитанции |
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: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"?> |
ПРИЛОЖЕНИЕ № 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#"> |
ПРИЛОЖЕНИЕ № 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 |
Электронное сообщение принято в обработку. |
выполнен разбор блока заголовков сообщения, а также определено, что сообщение имеет блок содержимого (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> |
При проверке квитанции, включая ЭЦП квитанции, возникла ошибка. |
ERR1500 |
Ошибка обращения к сервису штампа времени. <Причина>. Идентификатор электронного документа: <DocInstance> |
при формировании квитанции возникла ошибка обращения к сервису штампа времени. В поле <Причина> указывается текстовое описание причины ошибки: сервис недоступен, сервис в качестве ответа возвратил ошибку (с указанием кода ошибки). В поле <DocInstance> указывается уникальный идентификатор электронного документа |
ERR1600 |
Сообщение для интеграционного шлюза не удалось отправить. <Причина>. Уникальный идентификатор сообщения wsa:MessageID: <значение заголовка wsa:MessageID> |
при попытке отправки сообщения возникла ошибка. В поле <Причина> указывается текстовое описание причины ошибки: сообщение не удалось поставить в очередь, транспортная подсистема или транспортный адаптер доверенной третьей стороны недоступен. В поле <значение заголовка wsa:MessageID> указывается значение соответствующего заголовка сообщения |
Примечания: |
1. Каждая запись журнала должна включать как минимум следующие поля: |
2. Допускается изменять степень детализации записи сведений в журнал аудита, включая перечень логических операций и событий, и текстовое описание записей в журнале. |
