Приложение 3. ПОЛОЖЕНИЕ ОБ ОБМЕНЕ ЭЛЕКТРОННЫМИ ДОКУМЕНТАМИ ПРИ ТРАНСГРАНИЧНОМ ВЗАИМОДЕЙСТВИИ ОРГАНОВ ГОСУДАРСТВЕННОЙ ВЛАСТИ ГОСУДАРСТВ - ЧЛЕНОВ ЕВРАЗИЙСКОГО ЭКОНОМИЧЕСКОГО СОЮЗА МЕЖДУ СОБОЙ И С ЕВРАЗИЙСКОЙ ЭКОНОМИЧЕСКОЙ КОМИССИЕЙ

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

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

Таблица 1

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

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

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

Таблица 2

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

Таблица 3

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

Таблица 4

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

Таблица 5

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

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.

Таблица 7

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

Таблица 8

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

8. Атрибут Reference элементов rcpt:Success и rcpt:Error заполняется доверенной третьей стороной отправителя. Атрибут должен содержать ссылку на ЭЦП в электронном документе, для которого формируется элемент rcpt:Success или rcpt:Error. Для формирования ссылки следует использовать значение атрибута ds:Signature/@Id ЭЦП.

Доверенная третья сторона получателя не должна формировать атрибут Reference.

9. При заполнении элемента rcpt:ReasonCode должны использоваться следующие коды:

а) Signature.Error - код свидетельствует об ошибке проверки ЭЦП в электронном документе или ЭЦП в квитанции;

б) Signature.BadCertificate - код свидетельствует об ошибке проверки сертификата ключа проверки ЭЦП электронного документа либо сертификата ключа проверки ЭЦП квитанции.

10. Элемент rcpt:ReasonText содержит текст, описывающий ошибку. Правила заполнения элемента rcpt:ReasonText доверенная третья сторона определяет самостоятельно.

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

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

б) для найденной ЭЦП выполняются проверки, предусмотренные подразделом 2 раздела III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. N 125;

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

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

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

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

б) для найденной квитанции выполняются проверки, предусмотренные подразделом 2 раздела III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. N 125;

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

13. Блок rcpt:AttachedData содержит дополнительную информацию, связанную с квитанцией.

Доверенная третья сторона получателя должна вкладывать в блок rcpt:AttachedData квитанцию доверенной третьей стороны отправителя.

14. Для идентификации места (сегмента) формирования квитанции (элемент xades:CountryName) должен использоваться один из следующих кодов:

а) EEC - при формировании квитанции в интеграционном сегменте Евразийской экономической комиссии;

б) код страны в соответствии со стандартом ISO 3166-1 alpha-2 - при формировании квитанции в одном из национальных сегментов государств - членов Евразийского экономического союза (далее - государства-члены).

15. Для указания роли доверенной третьей стороны (элемент xades:ClaimedRole) должен использоваться один из следующих кодов:

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

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

16. Формирование штампа времени (элемент xades:EncapsulatedTimeStamp) для квитанции доверенной третьей стороны отправителя выполняется с использованием сервиса штампа времени удостоверяющего центра службы доверенной третьей стороны и с применением стандартов службы доверенной третьей стороны интегрированной системы.

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

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

17. Хэш в блоке манифеста квитанции (содержимое элемента ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue) должен формироваться на блок doc:Data электронного документа, включая сам XML-тег doc:Data, его атрибуты и все элементы-потомки (рисунок 1).

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

          ┌─────────────────────────────────────────────────────┐
          │                                      │
          │                                                     │
          │   ┌─────────────────────────────────────────────┐   │
          │   │    Область формирования хэша в квитанции    │   │
          │   │                                             │   │
          │   │   ┌─────────────────────────────────────┐   │   │
          │   │   │                           │   │   │
          │   │   │                                     │   │   │
          │   │   │   ┌─────────────────────────────┐   │   │   │
          │   │   │   │               │   │   │   │
          │   │   │   └─────────────────────────────┘   │   │   │
          │   │   │                                     │   │<──┼───┐
          │   │   │   ┌─────────────────────────────┐   │   │   │   │
          │   │   │   │          │   │   │   │   │
          │   │   │   └─────────────────────────────┘   │   │   │   │
          │   │   └─────────────────────────────────────┘   │   │   │
          │   └─────────────────────────────────────────────┘   │   │
          │                                                     │   │
          │   ┌─────────────────────────────────────────────┐   │   │
          │   │                  Квитанция                  │   │   │
          │   │                                             │   │   │
          │   │                                             │   │   │
          │   │         ┌────────────────────────┐          │   │   │
          │   │         │   Хэш блока Manifest   ├──────────┼───┼───┘
          │   │         └────────────────────────┘          │   │
          │   └─────────────────────────────────────────────┘   │
          └─────────────────────────────────────────────────────┘

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

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

Вложение квитанции выполняется путем добавления XML-структуры квитанции в качестве дочернего элемента блока doc:SignedDoc после блока doc:Data (рисунок 1).

19. Проверка ЭЦП в квитанции может выполняться в 2 режимах:

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

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

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

Все проверки ЭЦП в квитанции, предусмотренные подразделом 2 раздела III Положения об обмене электронными документами при трансграничном взаимодействии органов государственной власти государств - членов Евразийского экономического союза между собой и с Евразийской экономической комиссией, утвержденного Решением Коллегии Евразийской экономической комиссии от 28 сентября 2015 г. N 125, выполняются в основном режиме.

21. К процедуре проверки ЭЦП в квитанции в основном режиме предъявляются следующие требования:

проверка выполняется в соответствии с правилами, указанными в стандарте XAdES (форма XAdES-T);

проверка ЭЦП в квитанции в основном режиме включает в себя проверку целостности электронного документа.

Под проверкой целостности электронного документа понимается процедура формирования хэша содержимого электронного документа в соответствии с требованиями пункта 17 настоящего документа, а также с правилами обработки элементов типа ds:Reference согласно правилам стандарта XMLDsig, и сверка сформированного хэша со значением, указанным в элементе ds:Signature/ds:Object/ds:Manifest/ ds:Reference/ds:DigestValue ЭЦП квитанции.

В случае если хэш содержимого электронного документа не соответствует значению, указанному в составе элемента ds:Signature/ds:Object/ds:Manifest/ds:Reference/ds:DigestValue ЭЦП квитанции, целостность электронного документа считается нарушенной, а процедура проверки ЭЦП в квитанции - завершенной с ошибкой.

22. Проверка ЭЦП в квитанции в служебном режиме выполняется в целях проверки целостности и подлинности квитанции в условиях, когда квитанция хранится отдельно от электронного документа, на который она сформирована. При этом проверка целостности электронного документа, на который сформирована квитанция, не выполняется.

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

23. К процедуре проверки ЭЦП в квитанции предъявляются следующие требования:

а) проверка выполняется в соответствии с правилами, указанными в стандарте XAdES (форма XAdES-T);

б) элемент ds:Signature/ds:Object/ds:Manifest/ds:Reference ЭЦП квитанции при проверке не обрабатывается.