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

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
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,066
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Обычно (во всех госсистемах) при подписи 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,066
Российская Федерация
Откуда: Иркутская область

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Смотря что имеете в виду под вложенная - замечание выше
Если же просто что 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)
Сообщений: 35
Российская Федерация
Откуда: Москва

Сказал(а) «Спасибо»: 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) загружен 8 раз(а).
Offline two_oceans  
#8 Оставлено : 12 октября 2020 г. 23:17:05(UTC)
two_oceans

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

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

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

По теме - нисколько не удивлюсь если файл действительно не валидируется. Это как раз то, что я имел ввиду, когда выше писал, что вариант с двумя и более 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)
Сообщений: 35
Российская Федерация
Откуда: Москва

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

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

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

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

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

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

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

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

Offline migel  
#11 Оставлено : 15 октября 2020 г. 11:10:11(UTC)
migel

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

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

Сказал(а) «Спасибо»: 3 раз
Поблагодарили: 5 раз в 5 постах
Автор: two_oceans Перейти к цитате
Ну этот пример определенно еще более неудачный - сейчас считанные единицы ПО, которое его сможет валидировать. Проблема даже не в XPath, а в чудесной мысли авторов схемы ПФР, записавших пф.рф и далее кириллицей в объявления пространств имен. Фокус в том, что кириллица в таком месте документа не входит в стандарт RFC, есть примечание в стандарте в духе "если технически сможете использовать национальный алфавит - используйте, но это не регламентируется данным стандартом".

Согласно стандарту rfc3986
1.2. Design Considerations
1.2.1. Transcription
Цитата:

In local or regional contexts and with improving technology, users
might benefit from being able to use a wider range of characters;
such use is not defined by this specification. Percent-encoded
octets (Section 2.1) may be used within a URI to represent characters
outside the range of the US-ASCII coded character set if this
representation is allowed by the scheme or by the protocol element in
which the URI is referenced. Such a definition should specify the
character encoding used to map those characters to octets prior to
being percent-encoded for the URI.

Прямого запрета нет и согласно рекомендациям W3C а так как енкодинг у нас в файле задан то все согласно стандартаThink .
Namespaces in XML 1.0 (Third Edition)
Пространства имен должны быть нормализованы согласно Extensible Markup Language (XML) 1.0 (Fifth Edition)
Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще.
Можно конечно попробывать все такие ури нормализовать перед подписанием. d'oh!
P.S и да с enveloped трансформом все валидируется...Anxious

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

Offline two_oceans  
#12 Оставлено : 16 октября 2020 г. 7:43:07(UTC)
two_oceans

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

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

Сказал(а) «Спасибо»: 69 раз
Поблагодарили: 242 раз в 227 постах
Не запрещена, да, просто не регламентирована этим RFC потому какой смысл его цитировать?
Цитата:
users might benefit from being able to use a wider range of characters; such use is not defined by this specification.
Соль в этой фразе (открестились от национальных алфавитов, предложив разработать новый RFC если кто заинтересован). Остальная часть цитаты просто размышления авторов RFC, так как дальше они замечательным образом поясняют, что если использовать Percent-encoded, то использовать вообще везде. Визуально браузер может быть будет заменять по указанной кодировке на кириллицу, но сравниваться при форматно-логическом контроле схемы и фактически быть указаны в документе должны именно процентики (в случае такой выбранной кодировки) без всякой замены на кириллицу. Причина: преобразования перед сравнением запрещены, как есть в документе - так и сравниваются, то есть с процентиками и кириллицей - это две большие разницы.

ПФР никакой кодировки процентами не выбрал, punycode не выбрал, фактически простые парни написали кириллицу Юникодом (так как при подписании все кодировки приводятся к UTF-8, не буду заострять внимание на кодировке именно исходного документа). Поэтому случай с ПФР явно относится к той фразе "such use is not defined by this specification".

Цитата:
Пространства имен должны быть нормализованы согласно Extensible Markup Language (XML) 1.0 (Fifth Edition)
Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще. Можно конечно попробовать все такие ури нормализовать перед подписанием.
Конечно виртуозно Вы разные редакции приводите, одно из третьей, другое из пятой, сама подпись вообще из первой. Но не суть, нормализация ровно ничего не даст - там в основном меняются переводы строк и мнемоники. Остальные символьные референсы, внешние ссылки, инструкции обработки и т.д. запрещены стандартом SOAP. В остальном "For another character, append the character to the normalized value." Кириллица как раз попадает в "another character", (потому собственно и удалось ее туда вписать) - будет пропущена без изменений.
Цитата:
P.S и да с enveloped трансформом все валидируется
Это уже интереснее, по есть с пф.рф и enveloped все нормально?

Отредактировано пользователем 16 октября 2020 г. 7:47:38(UTC)  | Причина: Не указана

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