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

«Об утверждении Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств — членов Евразийского экономического союза между собой и с Евразийской экономической комиссией»

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

РЕШЕНИЕ

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

ОБ УТВЕРЖДЕНИИ ПОЛОЖЕНИЯ ОБ ОБМЕНЕ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ ПРИ ТРАНСГРАНИЧНОМ ВЗАИМОДЕЙСТВИИ ОРГАНОВ ГОСУДАРСТВЕННОЙ ВЛАСТИ ГОСУДАРСТВ — ЧЛЕНОВ ЕВРАЗИЙСКОГО ЭКОНОМИЧЕСКОГО СОЮЗА МЕЖДУ СОБОЙ И С ЕВРАЗИЙСКОЙ ЭКОНОМИЧЕСКОЙ КОМИССИЕЙ

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

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

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

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

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

ПОЛОЖЕНИЕ ОБ ОБМЕНЕ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ ПРИ ТРАНСГРАНИЧНОМ ВЗАИМОДЕЙСТВИИ ОРГАНОВ ГОСУДАРСТВЕННОЙ ВЛАСТИ ГОСУДАРСТВ — ЧЛЕНОВ ЕВРАЗИЙСКОГО ЭКОНОМИЧЕСКОГО СОЮЗА МЕЖДУ СОБОЙ И С ЕВРАЗИЙСКОЙ ЭКОНОМИЧЕСКОЙ КОМИССИЕЙ

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

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

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

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

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

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

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

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

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

«стандарт X.509» — стандарт ITU-T X.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. Определение состава участников обмена электронными документами осуществляется:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В случае если сообщение об ошибке формируется интеграционным шлюзом интеграционного сегмента Комиссии, оно должно представлять собой технологическое сообщение об ошибке с кодом «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. Электронные документы, используемые при трансграничном взаимодействии органов государственной власти государств — членов Евразийского экономического союза (далее соответственно — государства-члены, Союз) между собой и с Евразийской экономической комиссией в интегрированной информационной системе внешней и взаимной торговли и создаваемой на основе расширения ее функциональных возможностей интегрированной информационной системе Союза (далее соответственно — электронные документы, интегрированная система), имеют унифицированную структуру.

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

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

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

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

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

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

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

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

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

Таблица 2

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

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

Таблица 3

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

б) атрибут ds:Signature/@Id должен содержать идентификатор ЭЦП. Значение атрибута определяется отправителем в соответствии с требованиями стандарта xml-id;

в) блок doc:SignedContent должен подписываться ЭЦП, если иное не указано в технологических документах, регламентирующих информационное взаимодействие. Для ссылки на блок doc:SignedContent из структуры ЭЦП следует использовать значение атрибута doc:SignedContent/@Id;

г) в состав элемента ds:Signature должны включаться ЭЦП и сертификат ключа проверки ЭЦП в соответствии с требованиями стандарта XMLDsig.

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

<xs:complexType name=«SignedDocType»> xs:annotation xs:documentationТип данных «Электронный документ»</xs:documentation> </xs:annotation> xs:sequence

<xs:element name="Data"><br>
 <xs:annotation><br>
  <xs:documentation>Блок содержимого электронного документа</xs:documentation><br>
 </xs:annotation><br>
 <xs:compiexType><br>
  <xs:complexContent><br>
   <xs:extension base="doc:DataType"><br>
    <xs:attribute name="ld" type="xs:ID" use="required"/><br>
   </xs:extension><br>
  </xs:complexContent><br>
 </xs:complexType><br>
</xs:element><br>
<xs:element ref="ds:Signature" minoccurs="0"><br>
 <xs:annotation><br>
  <xs:documentation>Квитанция доверенной третьей стороны</xs:documentation><br>
 </xs:annotation><br>
</xs:element><br>

<xs:documentation>Тип блока содержимого электронного документа</xs:documentation>

</xs:annotation> xs:sequence <xs:element ref=«ds:Signature» maxOccurs=«unbounded»> xs:annotation <хs:documentation>Электронная цифровая подпись (электронная подпись)</xs:documentation> </xs:annotation> </xs:element> <xs:element name=«SignedContent»> xs:annotation <хs:documenttion>Блок подписываемых данных</xs:documentation> </xs:annotation> xs:complexType xs:sequence <xs:any namespace=«##any» processContents=«lax» maxOccurs=«unbounded»> xs:annotation xs:documentationСтруктура видов электронных документов (сведений)</xs:documentation> </xs:annotation> </xs:any> </xs:sequence> <xs:attribute name=«ld» type=«xs:ID» use=«required»> xs:annotation <хs:documentation>Атрибут-идентификатор блока подписываемых данных</xs:documentation>

   </xs:annotation><br>
  </xs:attribute><br>
  <xs:attribute name="Doclnstance" type="xs:anyURI" use="required"><br>
   <xs:annotation><br>
    <хs:documentation>Уникальный идентификатор электронного документа</xs:documentation><br>
   </xs:annotation><br>
  </xs:attribute><br>
 </xs:complexType><br>
</xs:element><br>

электронными документами при трансграничном взаимодействии органов государственной власти государств — членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

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

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

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

Таблица 1

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

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

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

Таблица 2

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

Таблица 3

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

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

а) TTP.Sender — если квитанция формируется доверенной третьей стороной отправителя;

б) TTP.Receiver — если квитанция формируется доверенной третьей стороной получателя.

Таблица 6

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

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.

Таблица 8

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:Data электронного документа, включая сам XML-тег doc:Data, его атрибуты и все элементы-потомки (рисунок 1).

Выборка XML-элементов электронного документа для формирования хэша должна выполняться по правилам, аналогичным для выборок по ссылкам типа «same-document reference» стандарта XMLDsig (раздел 4.3.3.3). Должна производиться выборка всего множества XML-элементов электронного документа, исключая элементы-комментарии (non-comment node).

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

Все проверки ЭЦП в квитанции, предусмотренные подразделом 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 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств — членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

<xs:annotation><br>
  <xs:documentation>Тип блока основных реквизитов квитанции</xs:documentation><br>
</xs:annotation>

<xs:sequence>
  <xs:element name="Receiptld" type="xs:anyURI">
    <xs:annotation>
      <хs:documentation>Уникальный идентификатор сформированной квитанции</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="Docld" type="xs:anyURI">
    <xs:annotation>
      <хs:documentation>Идентификатор электронного документа</xs:documentation>
    </xs:annotation>
  </xs:element>
  <xs:element name="Report">
    <xs:annotation>
      <хs:documentation>Блок сведений о результатах проверки</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:choice maxOccurs="unbounded">
        <xs:element name="Success" type="rcpt:SuccessType"/>
        <xs:element name="Error" type="rcpt:ErrorType"/>
      </xs:choice>
    </xs:complexType>
  </xs:element>
  <xs:element name="AttachedData" minoccurs="0">
    <xs:annotation>
      <хs:documentation>Блок дополнительных сведений в формате XML</xs:documentation>
    </xs:annotation>
    <xs:complexType>
      <xs:sequence>
        <xs:any namespace="##any" processContents="lax" maxOccurs="unbounded"/>
      </xs:sequence>
    </xs:complexType>
  </xs:element>
</xs:sequence>
<xs:attribute name="ld" type="xs:ID" use="required"/>

</xs:complexType> <xs:complexType name=«BaseReportType»> xs:annotation xs:documentationБазовый тип элемента-отчета о проверке</xs:documentation> </xs:annotation> <xs:attribute name=«Reference» type=«xs:anyURI» use=«optional»/> </xs:complexType> <xs:complexType name=«SuccessType»> xs:annotation xs:documentationТип элемента, указывающего, что проверка ДТС выполнена успешно</xs:documentation> </xs:annotation> xs:complexContent <xs:extension base=«rcpt:BaseReportType»/> </xs:complexContent> </xs:complexType> <xs:complexType name=«ErrorType»> xs:annotation xs:documentationТип контейнера описания ошибки</xs:documentation> </xs:annotation> xs:complexContent <xs:extension base=«rcpt:BaseReportType»> xs:sequence <xs:element name=«ReasonCode»> xs:annotation xs:documentationКод ошибки</xs:documentation> </xs:annotation> xs:simpleType <xs:restriction base=«xs:string»> <xs:enumeration value=«Signature.Error»/> <xs:enumeration value=«Signature.BadCertificate»/> <xs:enumeration value=«Document.AuthenticityError»/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name=«ReasonText» type=«xs:string»> xs:annotation xs:documentationТекстовое описание ошибки</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> </xs:schema>

Приложение № 5 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств — членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

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

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

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

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

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

6. К технологическому сообщению об ошибке предъявляются следующие требования:

а) элемент заголовка wsa:To должен содержать значение элемента wsa:ReplyTo/wsa:Address входящего сообщения;

б) элемент заголовка wsa:From/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-конверт вместе с содержимым тела и заголовками входящего сообщения, оформленный в соответствии с Правилами электронного обмена данными.

органов государственной власти государств — членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

ОПИСАНИЕ ТИПОВОГО ПРОТОКОЛА ЭЛЕКТРОННОГО ОБМЕНА ДАННЫМИ МЕЖДУ ИНТЕГРАЦИОННЫМ ШЛЮЗОМ ИНТЕГРИРОВАННОЙ ИНФОРМАЦИОННОЙ СИСТЕМЫ ВНЕШНЕЙ И ВЗАИМНОЙ ТОРГОВЛИ И СЕРВИСАМИ ДОВЕРЕННОЙ ТРЕТЬЕЙ СТОРОНЫ НА ТРАНСПОРТНОМ УРОВНЕ

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

Приложение № 7 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств — членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

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

<ds:Signature Id=«TTP.Sender.Receipt1» xmlns:ds=«http://www.w3.org/2000/09/xmldsig#»> ds:SignedInfo <ds:CanonicalizationMethod Algorithm=«http://www.w3.org/2001/10/xml-exc-c14n#»/> <ds:SignatureMethod Algorithm=«[идентификатор алгоритма вычисления значения ЭЦП]»/> <ds:Reference URI=«#TTP.Sender.Receipt1Manifest» Type=«http://www.w3.org/2000/09/xmldsig#Manifest»> ds:Transforms <ds:Transform Algorithm=«http://www.w3.org/2001/10/xml-exc-c14n#»/>

</ds:Reference> <ds:Reference URI=«#TTP.Sender.ReceiptlDetails» Type=«urn:EEC:TTP:v1.0:receipt:details»> ds:Transforms

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

<ds:Reference URI=«#TTP.Sender.Receipt1SignedProperties» Type=«http://uri.etsi.org/01903#SignedProperties»> ds:Transforms <ds:Transform Algorithm=«http://www.w3.org/2001/10/xml-exc-c14n#»/> </ds:Transforms> <ds:DigestMethod Algorithm=«[идентификатор алгоритма вычисления хэш-суммы]»/> ds:DigestValueUjBsR09...UxNQUFBUUNBRU1tQ1p0dUlGUXhEUzhi</ds:DigestValue>

  <rcpt:Success Reference="#Signature1"/>
  <rcpt:Error Reference="#Signature2">
         <rcpt:ReasonCode>Signature.Error</rcpt:ReasonCode>
         <rcpt:ReasonText>Хэш, указанный в элементе Signature/Signedinfo/DigestValue не совпадает

со значением хэша, построенного ФТС</rcpt:ReasonText> </rcpt:Error> <rcpt:Success Reference=«#Signature3»/> </rcpt:Report> </rcpt:Receipt>

<xades:QualifyingProperties xmlns:xades=«http://uri.etsi.org/01903/v1.3.2#»> <xades:SignedProperties id=«TTP.Sender.Receipt1SignedProperties»> xades:SignedSignatureProperties xades:SigningCertificate xades:Cert xades:CertDigest ds:DigestMethod[идентификатор алгоритма вычисления хэш-суммы]</ds:DigestMethod> ds:DigestValueUjBsRO..tQlpOdUlGUXhEUzhi</ds:DigestValue> </xades:CertDigest> ds:lssuerSerial ds:X509lssuerNameCN= CertCenter, O=CERT-CENTER, C = EEC, E=nfo@cn.org </ds:X509lssuerName> ds:X509SerialNumber18761230</ds:X509SerialNumber> </ds:lssuerSerial> </xades:Cert> </xades:SigningCertificate> xades:SignatureProductionPlace xades:CountryNameRU</xades:CountryName> </xades:SignatureProductionPlace> xades:SignerRole xades:ClaimedRoles xades:ClaimedRoleTTP.Sender</xades:ClaimedRole> </xades:ClaimedRoles> </xades:SignerRole> </xades:SignedSignatureProperties> </xades:SignedProperties> xades:UnsignedProperties xades:UnsignedSignatureProperties <ds:CanonicalizationMethod Algorithm=» http://www.w3.Org/2001/10/xml-exc-c14n#«/> xades:EncapsulatedTimeStampUjBsUxNQUFBUU....UxhEUzhi</xades:EncapsulatedTimeStamp> </xades:UnsignedSignatureProperties> </xades:UnsignedProperties> </xades:QualifyingProperties> </ds:Object> </ds:Signature>»

Приложение № 8 к Положению об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств — членов Евразийского экономического союза между собой и с Евразийской экономической комиссией

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