3.3. Проверка сертификатов и подписей
Проверка сертификатов ключей электронной подписи и корректности формирования электронной подписи осуществляется:
для электронной подписи субъектов взаимодействия - информационных систем (ЭП-СМЭВ, ЭП-ОВ, ЭП-ПГУ) – специализированным сервисом проверки, зарегистрированным в СМЭВ;
для электронной подписи субъектов взаимодействия – физических лиц (ЭП-П и ЭП-СП) – сервисом проверки сертификатов ЕПД, также зарегистрированным в СМЭВ.
4.Электронные подписи субъектов взаимодействия – физических лиц 4.1. Общие требования к электронной подписи, формируемой от лица пользователя ЕПГУ при заказе услуг
Сертификаты и ключи электронной подписи (п. 3 ст. 14 Федерального закона № 63-ФЗ «Об электронной подписи») пользователя Единого портала государственных услуг (функций) выдаются на имя физического лица пользователя портала и применяются в информационных системах инфраструктуры электронного правительства при подписаниия сведений в запросах на оказание государственных и муниципальных услуг в электронном виде для формирования и (или) проверки электронных подписей.
Данные подписи аналогичны собственноручным подписям этих пользователей и подтверждают, в том числе, факт формирования электронного документа конкретным пользователем в ЕПГУ.
Ответственность за хранение и использование ключа подписи ЭП-П несет пользователь портала.
4.2. Общие требования к электронной подписи, формируемой от имени должностных лиц органов власти при межведомственном информационном обмене
Сертификаты и ключи электронной подписи (п. 3 ст. 14 Федерального закона № 63-ФЗ «Об электронной подписи») должностного лица выдаются на имя физического лица представителя органа власти и применяются в информационных системах при оказании государственных и муниципальных услуг/исполнении государственных и муниципальных функций с использованием системы межведомственного электронного взаимодействия для формирования и (или) проверки электронных подписей.
Данные подписи аналогичны собственноручным подписям этих сотрудников и подтверждают, в том числе, факт формирования электронного документа конкретным сотрудником ОВ в ИС ОВ.
Ответственность за хранение и использование ключа подписи ЭП-СП несет должностное лицо и контролируется представителями органов власти.
Перевыпуск существующих сертификатов ключей ЭП-СП должностных лиц ОВ для использования при межведомственном взаимодействии не является обязательным – возможно использовать ранее выданные и действительные сертификаты ключей подписи должностных лиц при условии, что они выданы одним из удостоверяющих центров, входящих в единое пространство доверия ЭП, формируемое Минкомсвязью России (далее – ЕПД).
4.3. Электронная подпись при подаче заявлений с ЕПГУ или при межведомственном взаимодействии для сообщений с вложениями 4.3.1. Правила формирования архива вложений и электронной подписи файлов для электронных сообщений, содержащих вложения
При подаче заявлений с ЕПГУ, а также при межведомственном взаимодействии, подразумеющем передачу вложений, файл заявления и файлы вложений передаются не по отдельности в электронных сообщениях, а сгруппированные в одном архиве (сформированном по алгоритму zip).
Архив (в формате Base64) или ссылки на него (в случае передачи вложения вне SOAP конверта) размещаются внутри подэлементов элемента smev:AppDocument.
Архив содержит следующие файлы:
Заявление в информационную систему Поставщика в формате XML с ссылками на вложения.
Электронную подпись физического лица, соответствующую файлу заявления на основе стандарта PKCS#7 (detached).
Вложения в виде файлов форматов, согласованных с поставщиком сервиса;
Электронные подписи физического лица, соответствующие каждому из файлов вложений, передаваемых в архиве, на основе стандарта PKCS#7 (detached).
В случае подачи заявления с ЕПГУ электронная подпись к файлам вложений формируется с использованием сертификата ключа ЭП-ПГУ, если это не противоречит нормативно обоснованным требованиям участника-поставщика услуги.
Имя файла заявления должно соответствовать определенной маске:
где GUID_заявления - статистически уникальный 128-битный идентификатор (GUID) унифицированного вида (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
Имя архива должно соответствовать определенной маске:
При формировании имени архива должен использоваться тот же GUID_заявления, что и при формировании файла заявления.
Электронные документы и их электронные подписи могут находиться на любом уровне вложенности в архиве, но пути должны быть прописаны в xml-файле заявления в соответствии с определенным форматом.
Файлы электронной подписи для заявлений и вложений в формате PKCS#7 (detached) имеют формализованное правило именования, при котором к имени исходного файла добавляется постфикс *.sig.
Пример именования файла подписи указан в таблице ниже.
Наименование файла
|
Наименование файла подписи
|
req_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xml
|
req_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.xml.sig
|
attachment.txt
|
attachment.txt.sig
|
При описании вложений в файле заявления должны применяться следующие правила:
Группа вложений описывается элементом AppliedDocuments.
Каждое вложение описывается одним элементом AppliedDocument.
Каждый элемент AppliedDocument должен содержать следующие элементы:
CodeDocument
|
Код документа.
|
Name
|
Имя файла документа.
|
Number
|
Номер документа.
|
URL
|
Относительный путь к файлу внутри архива.
|
Type
|
Тип контента (например: application/pdf или любой другой общепринятый MIME-тип)
|
DigestValue
|
Хеш-код вложения, рассчитываемый по ГОСТ Р 34.11-94.
|
В дополнение к перечисленным элементам поставщики могут использовать свои элементы при условии того, что они будут дочерними к тегу AppliedDocument.
Архив (в формате Base64) может передаваться как внутри SOAP-конверта электронного сообшения, так и вне его.
XSD описание структур данных, используемых для описания вложений внутри заявлений, приведено в приложении 4.
4.3.2. Порядок формирования архива вложений и электронной подписи
Генерация GUID по маске xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx, где x описывается регулярным выражением [a-z0-9].
Формирование обращения на сервис ИС ОВ в формате XML c именем req_GUID.xml со ссылками на файлы-вложения.
Расчет хеш-кода каждого вложения и размещение полученных значений в структуру smev:AppliedDocuments в составе элемента smev:DigestValue.
Подпись каждого вложения по стандарту PKCS#7 и получение одноименных файлов. Пример: подпись attachment.pdf и получение attachment.pdf.sig.
Подпись XML-запроса по стандарту PKCS#7 и получение файла подписи req_GUID.xml.sig.
XML-заявление, его подпись, а также все вложения и их подписи архивируются в zip-файлс наименованием req_GUID.zip.
Код заявления req_GUID проставляется в элемент smev:RequestCode.
Архив req_GUID.zip кодируется в Base64 и полученный код становится содержимым элемента smev:BinaryData в электронном сообщении СМЭВ СМЭВ (или передается вне сообщения как MTOM-attachment).
4.3.3. Передача архива вложений в блоке бинарных вложений
Пример передачи архива в виде бинарного вложения с использованием элемента smev:BinaryData.
. . . . .
. . . . .
. . . . .
req_7d6476ac-a728-4863-804e-a5789d29c630
UEsDBAoAAAAAABBrAz/mb01kEgAAABIAAAAsAAAAcmVxXzk5NTM4MTAwLTliMjgtNDc4NC1iNDM3LTFmYjBkYTEzNzU5NS54bWw8ZGF0YT4KRGF0YTwvZGF0YT5QSwMECgAAAAAAE2sDP0lKW5b+BQAA/gUAADAAAAByZXFfOTk1MzgxMDAtOWIyOC00Nzg0LWI0MzctMWZiMGRhMTM3NTk1LnhtbC5zaWctLS0tLUJFR0lOIFBLQ1M3LS0tLS0KTUlJRVdnWU
. . . . .
| 4.3.4. Передача архива вложений вне конверта электронного сообщения
При передаче архива вложений вне SOAP-конверта электроного сообщения используются элементы smev:Reference и его дочерний элемент xop:Include (ссылка на вложение), а также элемент smev:DigestValue (в пространстве имен xmlns:smev).
Если архив с подписанными данными передается вне электронного сообщения (передается SOAP пакет: Multipart-сообщение, одна часть которого – это SOAP-сообщение, а другая – MTOM attachment), то необходимо заполнение следующих двух элементов:
Хэш Base64 архива;
Content-ID блока данных (attachment), передаваемого вне сообщения.
Хэш код архива в Base64 должен быть рассчитан с помощью криптографической хэш-функции по стандарту ГОСТ Р 34.11-94. Полученное значение должно быть размещено внутри элемента smev:DigestValue.
Ссылка на attachment должна быть отражена в сообщении посредством тега xop:Include со значением атрибута href, равным Content-ID вложения, передаваемого вне электронного сообщения СМЭВ.
Атрубут start= может отсутствовать, тогда базовый SOAP запрос будет идентифицироваться по паре start-info="text/xml"; type="application/xop+xml"; и
Content-Type: application/xop+xml;type="text/xml" соответственно.
MIME-Version: 1.0
Content-type: multipart/related;
start="*c73c9ce8-6e02-40ce-9f68-064e18843428>";
start-info="text/xml";
type="application/xop+xml";
boundary="MIME_boundary";
--MIME_boundary
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
Content-Id: *c73c9ce8-6e02-40ce-9f68-064e18843428>
Content-Transfer-Encoding: binary
. . . . .
. . . . .
req_7d6476ac-a728-4863-804e-a5789d29c630
Хеш кода архива
. . . . .
--MIME_boundary
Content-Type: application/zip
Content-Transfer-Encoding: binary
Content-ID:5aeaa450-17f0-4484-b845-a8480c363444
...binary ZIP image...
--MIME_boundary--
| |
