Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline IgorDID  
#1 Оставлено : 25 января 2020 г. 7:42:28(UTC)
IgorDID

Статус: Участник

Группы: Участники
Зарегистрирован: 05.04.2012(UTC)
Сообщений: 17
Мужчина
Российская Федерация
Откуда: Россия

Поблагодарили: 1 раз в 1 постах
Добрый день!
Столкнулись со следующей проблемой.
Пытался подписать xml документ, используемый Пенсионным Фондом для представления отчетности в рамках комплекса АИС ПФР2 (документы приведены в альбоме форматов ПФР версии 2.х - http://www.pfrf.ru/info/af/).

Подписывали тут


Версия плагина: 2.0.13771 Версия криптопровайдера: 4.0.9963

Browser plug-in выдал ошибку
Цитата:
Не удалось создать подпись из-за ошибки: An error was encountered while processing an XML digital signature. (0x800705BA)


XML документ, например, такой: (Опись содержания пакета (ОСП) раздел 7.5.1 из pdf описания альбома форматов)
Цитата:
<?xml version="1.0" encoding="UTF-8"?>
<ЭДПФР
xmlns="http://пф.рф/ОСП/2019-11-14" xmlns:УТ2="http://пф.рф/УТ/2017-08-21"
xmlns:АФ4="http://пф.рф/АФ/2017-08-21">
<ОСП>
<Оператор>
<УТ2:РегНомер>075-033-001392</УТ2:РегНомер>
<УТ2:НаименованиеКраткое>АО «ПФ «СКБ Контур»</УТ2:НаименованиеКраткое>
</Оператор>
<Страхователь>
<УТ2:РегНомер>077-008-054314</УТ2:РегНомер>
<УТ2:НаименованиеКраткое>ООО «СЕВЕР»</УТ2:НаименованиеКраткое>
<УТ2:ИНН>7705140401</УТ2:ИНН>
<УТ2:КПП>770501001</УТ2:КПП>
</Страхователь>
<Документ>
<Код>СЗВ-СТАЖ</Код>
<Файл>ПФР_034-008-054314_034008_СЗВ-СТАЖ_20170205_4dbe634c-d3e7-47eb-99bb-5a7235423a12.gz</Файл>
<ТипФайла>application/xml</ТипФайла>
<Сжатие>1</Сжатие>
</Документ>
<Зашифровано>1</Зашифровано>
<ФайлСерт>nord.der</ФайлСерт>
</ОСП>
<СлужебнаяИнформация>
<АФ4:GUID>ba1599d4-cf41-46cd-96f1-e3a254e1da90</АФ4:GUID>
<АФ4:ДатаВремя>2019-09-17T12:00:00</АФ4:ДатаВремя>
</СлужебнаяИнформация>
</ЭДПФР>


Как можно заметить, в xml используются русские символы в доменах и путях URL в пространствах имен, что не соответствует RFC, однако реальность требует работы с такими документами.
Если URL пространств имен удалить или просто написать транслитом, то подпись формируется успешно.

Также опытным путем установили, что все продукты, что были под рукой на основе libxml, не могут сделать каноникализацию такого документа (открыть его и парсить еще можно если подавлять ошибки).
Средство, которое смогло каноникализировать, это xmlsec-c14n (xsec-c14n). Возможно это поможет.

Обмен документами xml из этого альбома форматов ПФР c подписью xmldsig в ближайшее время станет очень активно применяться в связи с введением нового формата обмена.
Прошу обратить внимание на проблему.

Подскажите, возможно ли доработать plug-in, чтобы подписание таких XML стало возможно ?

Отредактировано пользователем 26 января 2020 г. 9:23:11(UTC)  | Причина: Не указана

Offline IgorDID  
#2 Оставлено : 25 января 2020 г. 11:09:38(UTC)
IgorDID

Статус: Участник

Группы: Участники
Зарегистрирован: 05.04.2012(UTC)
Сообщений: 17
Мужчина
Российская Федерация
Откуда: Россия

Поблагодарили: 1 раз в 1 постах
Кстати вот этот инструмент от Крипто-ПРО

при проверке XML с русскими пространствами имен не выдает ошибок связанных с самим XML, только отрицательный результата проверки подписи, которая заведомо была некорректной.
Правильно ли проверяет корректную подпись с русскими пространствами имен - пока не знаю, так как пока нет на руках такой XML.
Offline two_oceans  
#3 Оставлено : 27 января 2020 г. 21:31:29(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Цитата:
Как можно заметить, в xml используются русские символы в доменах и путях URL в пространствах имен, что не соответствует RFC, однако реальность требует работы с такими документами.
Как я понимаю, насчет несоответсия дело обстоит немного по-другому. Если Вы о RFC 3986, то там: да, описан способ представлять URI как ограниченный набор символов глобально, но потом выводят определение более широкого набора символов для регионов (если позволяют технологии) за рамки этого RFC (а чем обмен с ПФР не региональный контекст для России?).
Потом еще упоминают про DNS и не ASCII домены:
Цитата:
URI producers should provide these registered names in the IDNA encoding, rather than a percent-encoding, if they wish to maximize interoperability with legacy URI resolvers.
Смотрим дальше не противоречит ли другим стандартам: русская кириллица представлена символами с кодами x401, x410-x44F, x451 в Юникоде. Проверяем символы в стандарте XML - использовать можно во всех именах (включая значения атрибутов, куда этим стандартом отнесены и адреса пространств имен):
Продолжаем в Namespaces in XML. Тут ссылаются на RFC3986 как представлять URI, но парой разделов ниже способ представления "с процентами" из RFC3986 строго не рекомендуют. Зато в плане символов берут определение Name из стандарта XML и исключают из него двоеточие, то есть все остальные символы включая кириллические допустимы (в префиксах в том числе).

В плане значения атрибута отпределения пространства имен еще интереснее, написано что нормализованное значение должно быть или URI или пустое, то есть, как я понимаю, в документе может быть указано не нормализованное значение, но которое можно привести к нормализованному, соответствующему RFC3986. Повторюсь, значение "с процентами" указывать нельзя. В тоже время использовать зарегистрированные имена DNS доменов считается допустимым.
Исходя из всего, я делаю вывод, что кириллица в адресах пространств имен не запрещена (как региональный стандарт), но поддержку регионального стандарта от зарубежных библиотек ждать не приходится.

Отредактировано пользователем 27 января 2020 г. 22:48:17(UTC)  | Причина: Не указана

Offline IgorDID  
#4 Оставлено : 1 февраля 2020 г. 7:34:24(UTC)
IgorDID

Статус: Участник

Группы: Участники
Зарегистрирован: 05.04.2012(UTC)
Сообщений: 17
Мужчина
Российская Федерация
Откуда: Россия

Поблагодарили: 1 раз в 1 постах
two_oceans Offline спасибо за развернутый анализ, сам в RFC этого не увидел.
Стало быть, документ допустимого формата, но локализованнsй вариант.

Вопрос к КриптоПРО все же остается в силе:

Подскажите, будет ли plug-in работать с такими XML документами ?
Offline Анатолий Беляев  
#5 Оставлено : 3 февраля 2020 г. 10:50:41(UTC)
Анатолий Беляев

Статус: Сотрудник

Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
Плагин для обработки xml использует libxml2, и там с поддержкой кириллических символов не все хорошо.
Насчет DNS еще хочу отметить что, хотя браузеры и показывают домены в локализованных символах, по сети передаются и резолвятся имена в так называемом punycode который не содержит не латинских букв. Я не удивлюсь если авторы в RFC подразумевали именно этот способ кодирования говоря про
Цитата:
URI producers should provide these registered names in the IDNA encoding, rather than a percent-encoding
Техническую поддержку оказываем тут.
Наша база знаний.
Наша страничка в Instagram.
Offline two_oceans  
#6 Оставлено : 4 февраля 2020 г. 9:02:04(UTC)
two_oceans

Статус: Эксперт

Группы: Участники
Зарегистрирован: 05.03.2015(UTC)
Сообщений: 1,602
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Автор: Анатолий Беляев Перейти к цитате
по сети передаются и резолвятся имена в так называемом punycode который не содержит не латинских букв. Я не удивлюсь если авторы в RFC подразумевали именно этот способ кодирования говоря про
Цитата:
URI producers should provide these registered names in the IDNA encoding, rather than a percent-encoding
Да, "IDNA encoding" это именно о том, что сейчас у нас известно как punycode. Как я понял, есть отличия - кодировок IDN несколько, но пункт "не содержит не латинских букв" общий.

Тем не менее, в стандартах про пространства имен подчеркнуто (своими словами из английской цитаты в спойлере выше), что это URN (имя) и хотя возможно использовать URL (адрес) в качестве имени, нет необходимости размещать на адресе использованном как имя какой-либо ресурс. Записи urn:схема-пфр-может-надорвать-нам-мозг или oid:1.2.643.2.2.3 допустимы, хотя разместить на них что-то не выйдет.

Именно это мы и видим в данном случае - если набрать адрес из пространства имен в документе из первого сообщения в браузере, то перекинет на pfrf.ru и вернет 404 (не найдено). Таким образом, в данном случае это только имя (но не адрес) и "IDNA encoding" все также можно расценить как предложение, но не навязывание представления. В то же время если бы ресурс был на самом деле размещен по имени (и адресу!) с кириллицей, то "IDNA encoding" должно было быть применено и то с оговоркой:
Цитата:
if they wish to maximize interoperability with legacy URI resolvers.
В общем, странно что ПФР просто не использовал pfrf.ru

Отредактировано пользователем 4 февраля 2020 г. 9:18:24(UTC)  | Причина: Не указана

Offline miser  
#7 Оставлено : 14 февраля 2020 г. 11:38:31(UTC)
miser

Статус: Активный участник

Группы: Участники
Зарегистрирован: 14.03.2011(UTC)
Сообщений: 152
Мужчина
Откуда: Санкт-Петербург

Сказал «Спасибо»: 1 раз
Поблагодарили: 7 раз в 5 постах
Мой ответ больше относится к сотрудникам КриптоПро. При нормализации xml данных приходится сохранять контекст. Почему бы не заменить функцию номализации атрибутов во время сохранения. Функция libxml2 int xmlSaveSetAttrEscape(xmlSaveCtxtPtr ctxt, xmlCharEncodingOutputFunc escape).

При сохранении целого документа, функция xmlDocContentDumpOutput проверяет предустановленную кодировку и сохраняемую кодировку. Сбрасывая ctxt->escapeAttr в NULL. Но этого не происходит, когда сохраняется содержимого нормализации. Попробуйте мою идею.
Offline idzol  
#8 Оставлено : 14 февраля 2020 г. 15:51:17(UTC)
idzol

Статус: Новичок

Группы: Участники
Зарегистрирован: 14.02.2020(UTC)
Сообщений: 6
Российская Федерация
Откуда: Санкт-Петербург

Сказал(а) «Спасибо»: 2 раз
Все же хотелось бы услышать официальную позицию. Эта проблема будет исправлена либо нет?
Offline Анатолий Беляев  
#9 Оставлено : 19 февраля 2020 г. 13:55:26(UTC)
Анатолий Беляев

Статус: Сотрудник

Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
Автор: miser Перейти к цитате
Мой ответ больше относится к сотрудникам КриптоПро. При нормализации xml данных приходится сохранять контекст. Почему бы не заменить функцию номализации атрибутов во время сохранения. Функция libxml2 int xmlSaveSetAttrEscape(xmlSaveCtxtPtr ctxt, xmlCharEncodingOutputFunc escape).

При сохранении целого документа, функция xmlDocContentDumpOutput проверяет предустановленную кодировку и сохраняемую кодировку. Сбрасывая ctxt->escapeAttr в NULL. Но этого не происходит, когда сохраняется содержимого нормализации. Попробуйте мою идею.


Проблема не в каноникализации а вообще в поддержке такого namespace. В libxml2 есть вот такая функция
xmlParse3986URI (название намекает что она поддерживает только то что описано в RFC 3986, а региональные расширения туда не входят).
В ней идет вот такое условие на допустимые символы
Цитата:
ISA_UNRESERVED(cur) || ISA_PCT_ENCODED(cur) || ISA_SUB_DELIM(cur)
/*
* gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"
*/
#define ISA_GEN_DELIM(p) \
(((*(p) == ':')) || ((*(p) == '/')) || ((*(p) == '?')) || \
((*(p) == '#')) || ((*(p) == '[')) || ((*(p) == ']')) || \
((*(p) == '@')))

/*
* reserved = gen-delims / sub-delims
*/
#define ISA_RESERVED(p) (ISA_GEN_DELIM(p) || (ISA_SUB_DELIM(p)))

/*
* unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
*/
#define ISA_UNRESERVED(p) \
((ISA_ALPHA(p)) || (ISA_DIGIT(p)) || ((*(p) == '-')) || \
((*(p) == '.')) || ((*(p) == '_')) || ((*(p) == '~')))

#define ISA_ALPHA(p) (((*(p) >= 'a') && (*(p) <= 'z')) || \
((*(p) >= 'A') && (*(p) <= 'Z')))


как видно разрешены только латинские буквы, и как не странно символы закодированные через %.
Техническую поддержку оказываем тут.
Наша база знаний.
Наша страничка в Instagram.
Offline Анатолий Беляев  
#10 Оставлено : 21 февраля 2020 г. 12:03:45(UTC)
Анатолий Беляев

Статус: Сотрудник

Группы: Администраторы, Участники
Зарегистрирован: 24.11.2009(UTC)
Сообщений: 965
Откуда: Crypto-Pro

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 174 раз в 152 постах
Автор: idzol Перейти к цитате
Все же хотелось бы услышать официальную позицию. Эта проблема будет исправлена либо нет?

Исправим в следующей версии.
Техническую поддержку оказываем тут.
Наша база знаний.
Наша страничка в Instagram.
thanks 3 пользователей поблагодарили Анатолий Беляев за этот пост.
Андрей * оставлено 21.02.2020(UTC), two_oceans оставлено 25.02.2020(UTC), idzol оставлено 28.02.2020(UTC)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.