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

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
Offline Алексей87890  
#1 Оставлено : 22 апреля 2020 г. 17:31:41(UTC)
Алексей87890

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

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

Сказал(а) «Спасибо»: 2 раз
Подскажите пожалуйста ссылку на пример, где подписывается XML документ xades методом в браузере через КриптоПро ЭЦП Browser plug-in, но НЕСКОЛЬКИМИ подписями. Т.е. когда несколько человек подписывают xml документ почередно. Меня интересует реализация элемента "CounterSignature" согласно спецификации https://www.w3.org/TR/XAdES/ (параграф 5.2.4)
P.S. я в курсе про пример через CADES подпись: http://cpdn.cryptopro.ru...-sign-empty-content.html но интересует именно XADES вариант.

Спасибо!

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

Offline two_oceans  
#2 Оставлено : 23 апреля 2020 г. 5:16:19(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Обычно (во всех госсистемах) при подписи xades несколькими участниками просто деляют несколько подписей параллельно. Правда для этого подпись не должна быть enveloped и enveloping, а быть detached (для xades detached может быть и в том же документе при подписи фрагмента и в отдельном документе при подписи всего документа). См. также требования сервисов СМЭВ, ФСС, ПФР и т.д. Как я понимаю, но могу ошибаться, контрсигнатуры уже не рекомендованы к применению.

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

thanks 1 пользователь поблагодарил two_oceans за этот пост.
Алексей87890 оставлено 23.04.2020(UTC)
Offline Алексей87890  
#3 Оставлено : 23 апреля 2020 г. 10:08:35(UTC)
Алексей87890

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

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

Сказал(а) «Спасибо»: 2 раз
Спасибо большое за ответ! Попробуем этот вариант решения. А я правильно понимаю (перекопав документацию по "КриптоПро ЭЦП Browser plug-in" и "КриптоПро .NET"), что на данный момент нет такого API у библиотек КриптоПро для мульти-подписания XML со вложенными подписями?
Offline two_oceans  
#4 Оставлено : 24 апреля 2020 г. 12:03:25(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Смотря что имеете в виду под вложенная - замечание выше
Если же просто что 2 подписи в где-нибудь в Header, а подписывается Body - проблем нет. В "КриптоПро ЭЦП Browser plug-in" есть объект, реализующий режим подписания xades. Пример - где скачиваете плагин, есть тестовая страничка плагина, подписывающая по xades-bes. Пример подписывает весь документ (Reference URI=""), так что подпись выходит только одна, но если подписывать фрагмент и правильно разместить подпись, то возможно и несколько подписей в документе. Технически возможно подписать и весь документ несколькими людьми, но тогда их для надежности проверки надо выносить подписи в отдельный документ (непременимо, если используется SOAP).

Итак, для объекта есть вариант подписания по шаблону. То есть заполняете тег Signature в документе (указывая алгоритмы хэша, подписи, трансформов, Reference URI) без значений хэша и подписи, вызванный метод объекта вычисляет значение хэша и подписи и заполняет в шаблон. Минус - не все трансформы поддерживаются, однако если без экзотических трансформов, то вполне рабочий вариант. Еще не удается подписать документы в ПФР - проблема с кириллицей в адресах пространств имен от libxml (кириллица не запрещена, но и не разрешена тоже соответствующим RFC). Шаблонов может быть несколько в одном документе, тогда при вызове указывается какой шаблон нужно обработать при подписи конкретным ключом. Если не указать какой шаблон обработать - могут быть подписаны все сразу (не поручусь каким ключом).

Для .Net есть примеры подписания xades для ГИС ЖКХ. https://github.com/Good-...ritan/signature-demo-net Сам пример для гост-2001, но где-то здесь на форуме были уточнения где в коде поменять на гост-2012. Пример там для enveloped подписи, то есть может быть только одна. Если перенести подпись, например, в Header в контейнер wsse:Security, то можно аналогично сделать подписи разных людей. Здесь слабое звено - версия .Net: технически все работает в версиях ниже 4.5, но практически есть шанс получить неверную подпись на старых платформах (в зависимости от документа). Майкрософт доработала каноникализацию именно в версии 4.5.

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

thanks 1 пользователь поблагодарил two_oceans за этот пост.
Алексей87890 оставлено 24.04.2020(UTC)
Offline Алексей87890  
#5 Оставлено : 24 апреля 2020 г. 18:00:41(UTC)
Алексей87890

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

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

Сказал(а) «Спасибо»: 2 раз
Большое спасибо за отзыв! Angel
Offline Алексей87890  
#6 Оставлено : 3 июня 2020 г. 15:30:57(UTC)
Алексей87890

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

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

Сказал(а) «Спасибо»: 2 раз
Мы реализовали в своем проекте подписание xml документов несколькими участниками enveloped-подписями. Оставлю решение здесь, чтобы кому нибудь еще пригодилось. На самом деле я просто не знал, что подписанный xml документ может вполне содержать несколько вложенных подписей, и думал, что такое можно реализовать только через спецификацию "CounterSignature", и поэтому интересовался по этому вопросу здесь. А оказывается нужно просто правильно выбрать Transform-ы, чтобы проверяющая сторона правильно интерпретировала вложенные подписи:

1) Если предполагается, что документ будет подписываться целиком и содержать только одну подпись, то можно использовать стандартную трансформацию enveloped: "http://www.w3.org/2000/09/xmldsig#enveloped-signature". Проверяющая сторона удалит подпись перед проверкой, чтобы вычислить хэш документа;

2) Если предполагается, что документ будет подписываться целиком, но 2-мя участниками (т.е. будет содержать 2 вложенные подписи), то тогда надо применять для каждой подписи трансформацию XSL или XPath, например
<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">not(ancestor-or-self::dsig:Signature)</XPath></Transform>, которая просто убирает все подписи перед вычислением хэша, что аналогично первому варианту;

3) А если документ подписывается не целиком, а отдельными узлами, то здесь не важно сколько будет вложенных подписей, и поэтому даже не нужно никаких трасформаций (если конечно подпись не будет встраиваться в подписываемый элемент).

И конечно, для всех случаев рекомендуется использовать трансформацию c14n или exc-c14n (указать после предыдущих трансформаций).
Offline migel  
#7 Оставлено : 12 октября 2020 г. 11:10:42(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: Алексей87890 Перейти к цитате
Мы реализовали в своем проекте подписание xml документов несколькими участниками enveloped-подписями. Оставлю решение здесь, чтобы кому нибудь еще пригодилось. На самом деле я просто не знал, что подписанный xml документ может вполне содержать несколько вложенных подписей, и думал, что такое можно реализовать только через спецификацию "CounterSignature", и поэтому интересовался по этому вопросу здесь. А оказывается нужно просто правильно выбрать Transform-ы, чтобы проверяющая сторона правильно интерпретировала вложенные подписи:
....

2) Если предполагается, что документ будет подписываться целиком, но 2-мя участниками (т.е. будет содержать 2 вложенные подписи), то тогда надо применять для каждой подписи трансформацию XSL или XPath, например
<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">not(ancestor-or-self::dsig:Signature)</XPath></Transform>, которая просто убирает все подписи перед вычислением хэша, что аналогично первому варианту;
....

И конечно, для всех случаев рекомендуется использовать трансформацию c14n или exc-c14n (указать после предыдущих трансформаций).

Добрый день.
А ваши документы подписанные по п 2 валидируются online сервисами CryptoPro https://dss.cryptopro.ru/Verify/Verify/ ?
У меня возникла такая же задача и документы с такой трансформацией на указанном сервисе не валидируются.
Как пример: dd.xml (15kb) загружен 13 раз(а).
Offline two_oceans  
#8 Оставлено : 12 октября 2020 г. 23:17:05(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Что-то файл не скачивается.

По теме - нисколько не удивлюсь если файл действительно не валидируется. Это как раз то, что я имел ввиду, когда выше писал, что вариант с двумя и более enveloped (по расположению) будет проверяться не везде. Обозначу для ясности проблему: стандарт xmldsig определяет список трансформов которые предполагаются к поддержке. При этом по обязательности они делятся на три уровня: обязательные Required, рекомендованные Recommended и необязательные Optional. Рекомендованный уровень означает, что авторы стандарта рекомендуют включить поддержку алгоритма во все приложения, если приложение не имеет ограничений ресурсы из-за которых реализовать алгоритм непрактично.
https://www.w3.org/TR/xmldsig-core1/#sec-AlgID
Проматываем вниз почти до конца пункта 6.1 и видим что "внезапно" XPath относится к рекомендованным, да ещё и с примечанием, что в следующих версиях стандарта возможно будет понижен до необязательного. Для сравнения, enveloped обязателен по стандарту, с примечанием что важен результат, но не обязательно реализовать enveloped через XPath.

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

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

Offline migel  
#9 Оставлено : 13 октября 2020 г. 9:31:33(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Что-то файл не скачивается.
.....
xpath_transform.xml (15kb) загружен 6 раз(а). xpath_transform.zip (3kb) загружен 2 раз(а).

Перезалил сразу два на выбор ;-)
Offline two_oceans  
#10 Оставлено : 15 октября 2020 г. 6:25:10(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 110 раз
Поблагодарили: 393 раз в 366 постах
Ну этот пример определенно еще более неудачный - сейчас считанные единицы ПО, которое его сможет валидировать. Проблема даже не в XPath, а в чудесной мысли авторов схемы ПФР, записавших пф.рф и далее кириллицей в объявления пространств имен. Фокус в том, что кириллица в таком месте документа не входит в стандарт RFC, есть примечание в стандарте в духе "если технически сможете использовать национальный алфавит - используйте, но это не регламентируется данным стандартом". Вот здесь кириллицу можно без проблем:
Код:
<Наименование НекийАтрибут="Лалала">1505Приказ</Наименование>

Код:
xmlns:ТПУ
А вот здесь в кавычках после xmlns специальный тип URI/URN, для которого не регламентировано использование ничего кроме латинских букв и спецсимволов:
Код:
="http://пф.рф/ПУ/типы/2017-10-08"
Отдельная вишенка что punycode не поможет, так как преобразования также запрещены, адреса пространств имен сравниваются "как есть".
В распространенной libxml поддержку ничего кроме латинских букв и некоторых спецсимволов не реализовали, потому все средства валидирующие документ через libxml будут давать ошибку. Программные решения КриптоПро, как я понимаю, тоже через libxml пропускают текст (подтверждено в соседней теме для плагина). Для проверки в этом ли дело, можно поменять всю кириллицу в кавычках после xmlns: на латинские буквы.

Если кто-то знает трансформ для транслита, тоже могло бы помочь.

Отредактировано пользователем 15 октября 2020 г. 6:39:56(UTC)  | Причина: Не указана

RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.