Таблица 8. Структура элемента rcpt:Error

Таблица 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).

Рис. 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 ЭЦП квитанции при проверке не обрабатывается.