Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.05.2015(UTC) Сообщений: 41 Сказала «Спасибо»: 4 раз
|
Да, ответ от Ростелекома. Код:CN="ПАО \"Ростелеком\"", C=RU, ST=78 Санкт-Петербург, L=Санкт-Петербург, STREET="191002, г. Санкт-Петербург, ул. Достоевского д.15", O="ПАО \"Ростелеком\"", OID.1.2.643.100.1=#120D31303237373030313938373637, OID.1.2.643.3.131.1.1=#120C303037373037303439333838, OID.1.2.840.113549.1.9.2=Сертификат ЭП-СМЭВ3.0
Отредактировано пользователем 23 октября 2018 г. 18:57:18(UTC)
| Причина: Не указана
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,910 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 685 раз в 646 постах
|
Необходимо получить информацию, как каноникализируются данные при подписи (образец) и чем она создается. |
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.05.2015(UTC) Сообщений: 41 Сказала «Спасибо»: 4 раз
|
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,910 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 685 раз в 646 постах
|
Здравствуйте. Еще раз - проблема, скорее всего, в каноникализации, JCP только проверяет хеш (32 байта) и подпись (64 байта), остальное делает, например, xmlsec или любая другая подобная библиотека. Есть ли возможность прикрепить образцы - исходный документ и то, что должно быть получено и проходит проверку где-то (некий тестовый сервис)? <- Имеется в виду проблемный документ (видимо, образец от Ростелеком). Формат документов может быть разный, потому часть документов проходит, часть нет (каноникализация выполняется иначе). Отредактировано пользователем 23 ноября 2018 г. 13:37:10(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.05.2015(UTC) Сообщений: 41 Сказала «Спасибо»: 4 раз
|
Поясните, пожалуйста, вы имеете ввиду конкретные примеры xml-документов, которые мы получаем, и в которых подпись проверяется\не проверяется? Или речь о данных, которые нужно у Ростелекома запрашивать?
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,910 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 685 раз в 646 постах
|
Для этого конкретного случая у ростелекома есть образцы исходного документа и подписанного, проходящие у них проверку? желательно с промежуточным результатом, где есть каноникализированные данные, которые хешируются и подписываются? Отредактировано пользователем 23 ноября 2018 г. 14:15:16(UTC)
| Причина: Не указана |
|
|
|
|
Статус: Эксперт
Группы: Участники
Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 393 раз в 366 постах
|
Кажется тут диалог зашел в тупик, говорите о немного разных вещах - ошибка не в смэв при проверке подписи в запросе задающего вопрос, а наоборот, вот эти фрагменты это и есть ответ с подписью по версии Ростелекома и по идее эта подпись должна проходить проверку у них самих и ее можно использовать как образец. А задающий вопрос как раз не может ее проверить, так как второй образец возвращает другой хэш после каноникализации. В документации Ростелокома есть 4 примера по данному дополнительному трансформу, что должно получиться на выходе. Ну за месяц уже можно и вручную построить данный трансформ конкретного образца, сверить с хэшем и убедиться что верное, а что не верное. Ближайшее время как раз планирую этот трансформ реализовать, так что попробую построить и этот конкретный образец. Полностью согласен в необходимости промежуточного образца (текста после трансформа, от которого считается хэш), это кратчайший путь к решению. В моей реализации C14N одно время была ошибка в том, что один из символов не попадал в список разрешенных в значениях атрибута и потому отсутствовал в канонической форме, соответственно хэш получался другой если в атрибуте присутствовал данный символ. Второй раз во фрагмент не перенеслось пространство имен из "ancestor context" и также вышел другой хэш. По промежуточному образцу эти случаи оказалось очень просто выявить, до этого 2 месяца бодался с проблемой почему одни документы проходят проверку, а другие нет. Отредактировано пользователем 26 ноября 2018 г. 7:22:27(UTC)
| Причина: Не указана
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.05.2015(UTC) Сообщений: 41 Сказала «Спасибо»: 4 раз
|
Ждали ответа от техподдержки СМЭВа 3 месяца, в итоге никаких промежуточных этапов трансформации и т.п. они не предоставили, а сослались в очередной раз на свою документацию, что там всё есть.
two_oceans, подскажите, пожалуйста, когда Вы говорите про дополнительный трансформ, вы имеете ввиду SmevTransformSpi, представленный в документации СМЭВа? Вы его дорабатывали?
|
|
|
|
Статус: Активный участник
Группы: Участники
Зарегистрирован: 19.05.2015(UTC) Сообщений: 41 Сказала «Спасибо»: 4 раз
|
Автор: Евгений Афанасьев Здравствуйте. Еще раз - проблема, скорее всего, в каноникализации, JCP только проверяет хеш (32 байта) и подпись (64 байта), остальное делает, например, xmlsec или любая другая подобная библиотека. Поясните еще, пожалуйста по поводу каноникализации. Вот в документации СМЭВа указано: Канонизация (для XMLDSig) - Exclusive XML Canonicalization от 18 июля 2002 - http://www.w3.org/2001/10/xml-exc-c14n# Дополнительная трансформация (для XMLDSig) - Нормализация СМЭВ - urn://smev-gov-ru/xmldsig/transformАлгоритм дополнительной трансформации предоставляет сам СМЭВ (java-код SmevTransformSpi) Каноникализация c14n происходит при помощи библиотеке xmlsec, а она вместе с КриптоПро JCP идет же. Т.е. для JCP.2.0 - используется версия xmlsec-1.5.0. Задавали вопрос, и в СМЭВе говорят, что для работы с их SmevTransformSpi также требуется использовать именно xmlsec-1.5.0. Тогда как может получиться, что каноникализация выполнятся иначе? Отредактировано пользователем 25 января 2019 г. 12:02:32(UTC)
| Причина: Не указана
|
|
|
|
Статус: Сотрудник
Группы: Участники
Зарегистрирован: 06.12.2008(UTC) Сообщений: 3,910 Откуда: Крипто-Про Сказал(а) «Спасибо»: 20 раз Поблагодарили: 685 раз в 646 постах
|
Все операции с XML выполняет xmlsec (разбор, проверки схемы, извлечение узлов и данных, поиск алгоритмов, трансформации и т.д.), затем подает в JCP лишь хеш (32 байта), алгоритм, ключ и подпись (64 байта) для проверки (для подписи - подобным образом). Исключение из xmlsec transform - трансформ СМЭВ. От коллег (.NET) также поступил документ с каноникализациями: стандартной http://www.w3.org/2001/10/xml-exc-c14n# и СМЭВ (тоже Ростелеком). Одна из подписей не проверяется - не сходится хеш данных (и в Java xmlsec + SmevTransformSpi, и в .NET проекте). Каноникализировались данные согласно публичному SmevTransformSpi. Предположительно, что-то изменилось в алгоритме каноникализации (других причин быть не должно). В процессе выяснения, как проверить подпись. Отредактировано пользователем 25 января 2019 г. 12:11:58(UTC)
| Причина: Не указана |
|
|
|
|
Быстрый переход
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.
Important Information:
The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies.
More Details
Close