Atom Лента - Форум КриптоПро - Тема:Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in - 10Форум КриптоПро - Atom Лентаurn:https:--www-cryptopro-ru:AtomLenta:ForumKriptoPro:Tema:Mul'tipodpis'XMLdokumentavbrauzerecherezKriptoProEhCPBrowserplug-in-10:1Copyright 2024 Форум КриптоПро2024-03-29T10:02:21Zhttps://www.cryptopro.ru/forum2/Images/YAFLogo.pngForum Adminhttps://www.cryptopro.ruforum@cryptopro.rutwo_oceanshttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=36490&name=two_oceanstwo_oceanshttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=36490&name=two_oceansmigelhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=51620&name=migeltwo_oceanshttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=36490&name=two_oceansmigelhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=51620&name=migeltwo_oceanshttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=36490&name=two_oceansmigelhttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=51620&name=migelАлексей87890https://www.cryptopro.ru/forum2/default.aspx?g=profile&u=56125&name=Алексей87890Алексей87890https://www.cryptopro.ru/forum2/default.aspx?g=profile&u=56125&name=Алексей87890two_oceanshttps://www.cryptopro.ru/forum2/default.aspx?g=profile&u=36490&name=two_oceansАлексей87890https://www.cryptopro.ru/forum2/default.aspx?g=profile&u=56125&name=Алексей87890YetAnotherForum.NETurn:https:--www-cryptopro-ru:ftPosts:st1:meid119787:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer_Alt" width="100%"><tr><td>Не запрещена, да, просто не регламентирована этим RFC потому какой смысл его цитировать?<div class="quote"><span class="quotetitle">Цитата:</span><blockquote>users might benefit from being able to use a wider range of characters; such use is not defined by this specification.</div></div>Соль в этой фразе (открестились от национальных алфавитов, предложив разработать новый RFC если кто заинтересован). Остальная часть цитаты просто размышления авторов RFC, так как дальше они замечательным образом поясняют, что если использовать Percent-encoded, то использовать вообще везде. Визуально браузер может быть будет заменять по указанной кодировке на кириллицу, но сравниваться при форматно-логическом контроле схемы и фактически быть указаны в документе должны именно процентики (в случае такой выбранной кодировки) без всякой замены на кириллицу. Причина: преобразования перед сравнением запрещены, как есть в документе - так и сравниваются, то есть с процентиками и кириллицей - это две большие разницы.<br /><br />ПФР никакой кодировки процентами не выбрал, punycode не выбрал, фактически простые парни написали кириллицу Юникодом (так как при подписании все кодировки приводятся к UTF-8, не буду заострять внимание на кодировке именно исходного документа). Поэтому случай с ПФР явно относится к той фразе "such use is not defined by this specification".<br /><br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>Пространства имен должны быть нормализованы согласно Extensible Markup Language (XML) 1.0 (Fifth Edition) <br />Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще. Можно конечно попробовать все такие ури нормализовать перед подписанием.</div></div>Конечно виртуозно Вы разные редакции приводите, одно из третьей, другое из пятой, сама подпись вообще из первой. Но не суть, нормализация ровно ничего не даст - там в основном меняются переводы строк и мнемоники. Остальные символьные референсы, внешние ссылки, инструкции обработки и т.д. запрещены стандартом SOAP. В остальном "For another character, append the character to the normalized value." Кириллица как раз попадает в "another character", (потому собственно и удалось ее туда вписать) - будет пропущена без изменений.<br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>P.S и да с enveloped трансформом все валидируется</div></div>Это уже интереснее, по есть с пф.рф и enveloped все нормально?</td></tr></table>2020-10-16T07:47:38+03:002020-10-16T07:47:38+03:00two_oceans<table class="content postContainer_Alt" width="100%"><tr><td>Не запрещена, да, просто не регламентирована этим RFC потому какой смысл его цитировать?<div class="quote"><span class="quotetitle">Цитата:</span><blockquote>users might benefit from being able to use a wider range of characters; such use is not defined by this specification.</div></div>Соль в этой фразе (открестились от национальных алфавитов, предложив разработать новый RFC если кто заинтересован). Остальная часть цитаты просто размышления авторов RFC, так как дальше они замечательным образом поясняют, что если использовать Percent-encoded, то использовать вообще везде. Визуально браузер может быть будет заменять по указанной кодировке на кириллицу, но сравниваться при форматно-логическом контроле схемы и фактически быть указаны в документе должны именно процентики (в случае такой выбранной кодировки) без всякой замены на кириллицу. Причина: преобразования перед сравнением запрещены, как есть в документе - так и сравниваются, то есть с процентиками и кириллицей - это две большие разницы.<br /><br />ПФР никакой кодировки процентами не выбрал, punycode не выбрал, фактически простые парни написали кириллицу Юникодом (так как при подписании все кодировки приводятся к UTF-8, не буду заострять внимание на кодировке именно исходного документа). Поэтому случай с ПФР явно относится к той фразе "such use is not defined by this specification".<br /><br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>Пространства имен должны быть нормализованы согласно Extensible Markup Language (XML) 1.0 (Fifth Edition) <br />Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще. Можно конечно попробовать все такие ури нормализовать перед подписанием.</div></div>Конечно виртуозно Вы разные редакции приводите, одно из третьей, другое из пятой, сама подпись вообще из первой. Но не суть, нормализация ровно ничего не даст - там в основном меняются переводы строк и мнемоники. Остальные символьные референсы, внешние ссылки, инструкции обработки и т.д. запрещены стандартом SOAP. В остальном "For another character, append the character to the normalized value." Кириллица как раз попадает в "another character", (потому собственно и удалось ее туда вписать) - будет пропущена без изменений.<br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote>P.S и да с enveloped трансформом все валидируется</div></div>Это уже интереснее, по есть с пф.рф и enveloped все нормально?</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid119755:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=119745#post119745"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Ну этот пример определенно еще более неудачный - сейчас считанные единицы ПО, которое его сможет валидировать. Проблема даже не в XPath, а в чудесной мысли авторов схемы ПФР, записавших пф.рф и далее кириллицей в объявления пространств имен. Фокус в том, что кириллица в таком месте документа не входит в стандарт RFC, есть примечание в стандарте в духе "если технически сможете использовать национальный алфавит - используйте, но это не регламентируется данным стандартом".</div></div><br />Согласно стандарту <a rel="nofollow" href="https://www.rfc-editor.org/rfc/rfc3986.html" title="https://www.rfc-editor.org/rfc/rfc3986.html">rfc3986</a><br />1.2. Design Considerations<br />1.2.1. Transcription<br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote><br /> In local or regional contexts and with improving technology, users<br /> might benefit from being able to use a wider range of characters;<br /> such use is not defined by this specification. Percent-encoded<br /> octets (Section 2.1) may be used within a URI to represent characters<br /> outside the range of the US-ASCII coded character set if this<br /> representation is allowed by the scheme or by the protocol element in<br /> which the URI is referenced. Such a definition should specify the<br /> character encoding used to map those characters to octets prior to<br /> being percent-encoded for the URI.<br /></div></div><br />Прямого запрета нет и согласно рекомендациям W3C а так как енкодинг у нас в файле задан то все согласно стандарта<img src="/forum2/Images/Emoticons/eusa_think.gif" alt="Think" /> .<br /><a rel="nofollow" href="https://www.w3.org/TR/REC-xml-names" title="https://www.w3.org/TR/REC-xml-names">Namespaces in XML 1.0 (Third Edition)</a><br />Пространства имен должны быть нормализованы согласно <a rel="nofollow" href="https://www.w3.org/TR/REC-xml/#AVNormalize" title="https://www.w3.org/TR/REC-xml/#AVNormalize">Extensible Markup Language (XML) 1.0 (Fifth Edition)</a><br />Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще.<br />Можно конечно попробывать все такие ури нормализовать перед подписанием. <img src="/forum2/Images/Emoticons/eusa_doh.gif" alt="d'oh!" /><br />P.S и да с enveloped трансформом все валидируется...<img src="/forum2/Images/Emoticons/eusa_shifty.gif" alt="Anxious" /></td></tr></table>2020-10-15T11:17:38+03:002020-10-15T11:17:38+03:00migel<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=119745#post119745"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Ну этот пример определенно еще более неудачный - сейчас считанные единицы ПО, которое его сможет валидировать. Проблема даже не в XPath, а в чудесной мысли авторов схемы ПФР, записавших пф.рф и далее кириллицей в объявления пространств имен. Фокус в том, что кириллица в таком месте документа не входит в стандарт RFC, есть примечание в стандарте в духе "если технически сможете использовать национальный алфавит - используйте, но это не регламентируется данным стандартом".</div></div><br />Согласно стандарту <a rel="nofollow" href="https://www.rfc-editor.org/rfc/rfc3986.html" title="https://www.rfc-editor.org/rfc/rfc3986.html">rfc3986</a><br />1.2. Design Considerations<br />1.2.1. Transcription<br /><div class="quote"><span class="quotetitle">Цитата:</span><blockquote><br /> In local or regional contexts and with improving technology, users<br /> might benefit from being able to use a wider range of characters;<br /> such use is not defined by this specification. Percent-encoded<br /> octets (Section 2.1) may be used within a URI to represent characters<br /> outside the range of the US-ASCII coded character set if this<br /> representation is allowed by the scheme or by the protocol element in<br /> which the URI is referenced. Such a definition should specify the<br /> character encoding used to map those characters to octets prior to<br /> being percent-encoded for the URI.<br /></div></div><br />Прямого запрета нет и согласно рекомендациям W3C а так как енкодинг у нас в файле задан то все согласно стандарта<img src="/forum2/Images/Emoticons/eusa_think.gif" alt="Think" /> .<br /><a rel="nofollow" href="https://www.w3.org/TR/REC-xml-names" title="https://www.w3.org/TR/REC-xml-names">Namespaces in XML 1.0 (Third Edition)</a><br />Пространства имен должны быть нормализованы согласно <a rel="nofollow" href="https://www.w3.org/TR/REC-xml/#AVNormalize" title="https://www.w3.org/TR/REC-xml/#AVNormalize">Extensible Markup Language (XML) 1.0 (Fifth Edition)</a><br />Libxml в разборе URI (uri.c) жестко завязан на ascii (макро ISA_PCHAR) и не учитывает енкодинг документа вообще.<br />Можно конечно попробывать все такие ури нормализовать перед подписанием. <img src="/forum2/Images/Emoticons/eusa_doh.gif" alt="d'oh!" /><br />P.S и да с enveloped трансформом все валидируется...<img src="/forum2/Images/Emoticons/eusa_shifty.gif" alt="Anxious" /></td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid119745:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer_Alt" width="100%"><tr><td>Ну этот пример определенно еще более неудачный - сейчас считанные единицы ПО, которое его сможет валидировать. Проблема даже не в XPath, а в чудесной мысли авторов схемы ПФР, записавших пф.рф и далее кириллицей в объявления пространств имен. Фокус в том, что кириллица в таком месте документа не входит в стандарт RFC, есть примечание в стандарте в духе "если технически сможете использовать национальный алфавит - используйте, но это не регламентируется данным стандартом". Вот здесь кириллицу можно без проблем:<br /><div class="code"><strong>Код:</strong><div class="innercode"><pre class="line-numbers"><code class="language-markup"><Наименование НекийАтрибут="Лалала">1505Приказ</Наименование></code></pre>
</div></div><br /><div class="code"><strong>Код:</strong><div class="innercode"><pre class="line-numbers"><code class="language-markup">xmlns:ТПУ</code></pre>
</div></div>А вот здесь в кавычках после xmlns специальный тип URI/URN, для которого не регламентировано использование ничего кроме латинских букв и спецсимволов:<br /><div class="code"><strong>Код:</strong><div class="innercode"><pre class="line-numbers"><code class="language-markup">="http://пф.рф/ПУ/типы/2017-10-08"</code></pre>
</div></div>Отдельная вишенка что punycode не поможет, так как преобразования также запрещены, адреса пространств имен сравниваются "как есть".<br />В распространенной libxml поддержку ничего кроме латинских букв и некоторых спецсимволов не реализовали, потому все средства валидирующие документ через libxml будут давать ошибку. Программные решения КриптоПро, как я понимаю, тоже через libxml пропускают текст (подтверждено в соседней теме для плагина). Для проверки в этом ли дело, можно поменять всю кириллицу в кавычках после xmlns: на латинские буквы.<br /><br />Если кто-то знает трансформ для транслита, тоже могло бы помочь.</td></tr></table>2020-10-15T06:39:56+03:002020-10-15T06:39:56+03:00two_oceans<table class="content postContainer_Alt" width="100%"><tr><td>Ну этот пример определенно еще более неудачный - сейчас считанные единицы ПО, которое его сможет валидировать. Проблема даже не в XPath, а в чудесной мысли авторов схемы ПФР, записавших пф.рф и далее кириллицей в объявления пространств имен. Фокус в том, что кириллица в таком месте документа не входит в стандарт RFC, есть примечание в стандарте в духе "если технически сможете использовать национальный алфавит - используйте, но это не регламентируется данным стандартом". Вот здесь кириллицу можно без проблем:<br /><div class="code"><strong>Код:</strong><div class="innercode"><pre class="line-numbers"><code class="language-markup"><Наименование НекийАтрибут="Лалала">1505Приказ</Наименование></code></pre>
</div></div><br /><div class="code"><strong>Код:</strong><div class="innercode"><pre class="line-numbers"><code class="language-markup">xmlns:ТПУ</code></pre>
</div></div>А вот здесь в кавычках после xmlns специальный тип URI/URN, для которого не регламентировано использование ничего кроме латинских букв и спецсимволов:<br /><div class="code"><strong>Код:</strong><div class="innercode"><pre class="line-numbers"><code class="language-markup">="http://пф.рф/ПУ/типы/2017-10-08"</code></pre>
</div></div>Отдельная вишенка что punycode не поможет, так как преобразования также запрещены, адреса пространств имен сравниваются "как есть".<br />В распространенной libxml поддержку ничего кроме латинских букв и некоторых спецсимволов не реализовали, потому все средства валидирующие документ через libxml будут давать ошибку. Программные решения КриптоПро, как я понимаю, тоже через libxml пропускают текст (подтверждено в соседней теме для плагина). Для проверки в этом ли дело, можно поменять всю кириллицу в кавычках после xmlns: на латинские буквы.<br /><br />Если кто-то знает трансформ для транслита, тоже могло бы помочь.</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid119674:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=119665#post119665"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Что-то файл не скачивается.<br />.....<br /></div></div>[attach]9147[/attach] [attach]9148[/attach]<br /><br />Перезалил сразу два на выбор ;-)<br /></td></tr></table>2020-10-13T09:31:33+03:002020-10-13T09:31:33+03:00migel<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: two_oceans <a href="/forum2/default.aspx?g=posts&m=119665#post119665"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Что-то файл не скачивается.<br />.....<br /></div></div>[attach]9147[/attach] [attach]9148[/attach]<br /><br />Перезалил сразу два на выбор ;-)<br /></td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid119665:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-inНу за всех не скажу, но когда свою программу xmldsig начал писать, то сделал упор на малый объем кода в противовес раздувшимся фреймворкам/платформам дотнет и джава. Стандартную дельфи реализацию XPath до сих пор жаба давит прикрутить, так как она в полный рост тащит все дерево зависимостей: COM движок - гуиды - системные объекты - весь огромный модуль windows. Без всего этого безобразия с десятком действительно нужных winapi функций сейчас 22 библиотеки весят 3,45 Мб, включая отладочную информацию. Вместе со всем будет минимум на 30% больше. Поэтому действительно есть над чем подумать перед реализацией XPath. Тем не менее раздумываю на обработкой именно этого выражения XPath для удаления других Signature.2020-10-12T23:24:05+03:002020-10-12T23:24:05+03:00two_oceansНу за всех не скажу, но когда свою программу xmldsig начал писать, то сделал упор на малый объем кода в противовес раздувшимся фреймворкам/платформам дотнет и джава. Стандартную дельфи реализацию XPath до сих пор жаба давит прикрутить, так как она в полный рост тащит все дерево зависимостей: COM движок - гуиды - системные объекты - весь огромный модуль windows. Без всего этого безобразия с десятком действительно нужных winapi функций сейчас 22 библиотеки весят 3,45 Мб, включая отладочную информацию. Вместе со всем будет минимум на 30% больше. Поэтому действительно есть над чем подумать перед реализацией XPath. Тем не менее раздумываю на обработкой именно этого выражения XPath для удаления других Signature.urn:https:--www-cryptopro-ru:ftPosts:st1:meid119603:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: Алексей87890 <a href="/forum2/default.aspx?g=posts&m=115878#post115878"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Мы реализовали в своем проекте подписание xml документов несколькими участниками enveloped-подписями. Оставлю решение здесь, чтобы кому нибудь еще пригодилось. На самом деле я просто не знал, что подписанный xml документ может вполне содержать несколько вложенных подписей, и думал, что такое можно реализовать только через спецификацию "CounterSignature", и поэтому интересовался по этому вопросу здесь. А оказывается нужно просто правильно выбрать Transform-ы, чтобы проверяющая сторона правильно интерпретировала вложенные подписи:<br />....<br /><br />2) Если предполагается, что документ будет подписываться целиком, но 2-мя участниками (т.е. будет содержать 2 вложенные подписи), то тогда надо применять для каждой подписи трансформацию XSL или XPath, например <br /><Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><strong>not(ancestor-or-self::dsig:Signature)</strong></XPath></Transform>, которая просто убирает все подписи перед вычислением хэша, что аналогично первому варианту;<br />....<br /><br />И конечно, для всех случаев рекомендуется использовать трансформацию c14n или exc-c14n (указать после предыдущих трансформаций).</div></div><br />Добрый день.<br />А ваши документы подписанные по п 2 валидируются online сервисами CryptoPro <a rel="nofollow" href="https://dss.cryptopro.ru/Verify/Verify/" title="https://dss.cryptopro.ru/Verify/Verify/">https://dss.cryptopro.ru/Verify/Verify/</a> ?<br />У меня возникла такая же задача и документы с такой трансформацией на указанном сервисе не валидируются.<br />Как пример:[attach]9137[/attach]</td></tr></table>2020-10-12T11:10:42+03:002020-10-12T11:10:42+03:00migel<table class="content postContainer" width="100%"><tr><td><div class="quote"><span class="quotetitle">Автор: Алексей87890 <a href="/forum2/default.aspx?g=posts&m=115878#post115878"><img src="/forum2/Themes/soclean/icon_latest_reply.gif" title="Перейти к цитате" alt="Перейти к цитате" /></a></span><blockquote>Мы реализовали в своем проекте подписание xml документов несколькими участниками enveloped-подписями. Оставлю решение здесь, чтобы кому нибудь еще пригодилось. На самом деле я просто не знал, что подписанный xml документ может вполне содержать несколько вложенных подписей, и думал, что такое можно реализовать только через спецификацию "CounterSignature", и поэтому интересовался по этому вопросу здесь. А оказывается нужно просто правильно выбрать Transform-ы, чтобы проверяющая сторона правильно интерпретировала вложенные подписи:<br />....<br /><br />2) Если предполагается, что документ будет подписываться целиком, но 2-мя участниками (т.е. будет содержать 2 вложенные подписи), то тогда надо применять для каждой подписи трансформацию XSL или XPath, например <br /><Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><strong>not(ancestor-or-self::dsig:Signature)</strong></XPath></Transform>, которая просто убирает все подписи перед вычислением хэша, что аналогично первому варианту;<br />....<br /><br />И конечно, для всех случаев рекомендуется использовать трансформацию c14n или exc-c14n (указать после предыдущих трансформаций).</div></div><br />Добрый день.<br />А ваши документы подписанные по п 2 валидируются online сервисами CryptoPro <a rel="nofollow" href="https://dss.cryptopro.ru/Verify/Verify/" title="https://dss.cryptopro.ru/Verify/Verify/">https://dss.cryptopro.ru/Verify/Verify/</a> ?<br />У меня возникла такая же задача и документы с такой трансформацией на указанном сервисе не валидируются.<br />Как пример:[attach]9137[/attach]</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid115878:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer_Alt" width="100%"><tr><td>Мы реализовали в своем проекте подписание xml документов несколькими участниками enveloped-подписями. Оставлю решение здесь, чтобы кому нибудь еще пригодилось. На самом деле я просто не знал, что подписанный xml документ может вполне содержать несколько вложенных подписей, и думал, что такое можно реализовать только через спецификацию "CounterSignature", и поэтому интересовался по этому вопросу здесь. А оказывается нужно просто правильно выбрать Transform-ы, чтобы проверяющая сторона правильно интерпретировала вложенные подписи:<br /><br />1) Если предполагается, что документ будет подписываться целиком и содержать только одну подпись, то можно использовать стандартную трансформацию enveloped: "http://www.w3.org/2000/09/xmldsig#enveloped-signature". Проверяющая сторона удалит подпись перед проверкой, чтобы вычислить хэш документа;<br /><br />2) Если предполагается, что документ будет подписываться целиком, но 2-мя участниками (т.е. будет содержать 2 вложенные подписи), то тогда надо применять для каждой подписи трансформацию XSL или XPath, например <br /><Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><strong>not(ancestor-or-self::dsig:Signature)</strong></XPath></Transform>, которая просто убирает все подписи перед вычислением хэша, что аналогично первому варианту;<br /><br />3) А если документ подписывается не целиком, а отдельными узлами, то здесь не важно сколько будет вложенных подписей, и поэтому даже не нужно никаких трасформаций (если конечно подпись не будет встраиваться в подписываемый элемент).<br /><br />И конечно, для всех случаев рекомендуется использовать трансформацию c14n или exc-c14n (указать после предыдущих трансформаций).</td></tr></table>2020-06-03T15:30:57+03:002020-06-03T15:30:57+03:00Алексей87890<table class="content postContainer_Alt" width="100%"><tr><td>Мы реализовали в своем проекте подписание xml документов несколькими участниками enveloped-подписями. Оставлю решение здесь, чтобы кому нибудь еще пригодилось. На самом деле я просто не знал, что подписанный xml документ может вполне содержать несколько вложенных подписей, и думал, что такое можно реализовать только через спецификацию "CounterSignature", и поэтому интересовался по этому вопросу здесь. А оказывается нужно просто правильно выбрать Transform-ы, чтобы проверяющая сторона правильно интерпретировала вложенные подписи:<br /><br />1) Если предполагается, что документ будет подписываться целиком и содержать только одну подпись, то можно использовать стандартную трансформацию enveloped: "http://www.w3.org/2000/09/xmldsig#enveloped-signature". Проверяющая сторона удалит подпись перед проверкой, чтобы вычислить хэш документа;<br /><br />2) Если предполагается, что документ будет подписываться целиком, но 2-мя участниками (т.е. будет содержать 2 вложенные подписи), то тогда надо применять для каждой подписи трансформацию XSL или XPath, например <br /><Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"><XPath xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><strong>not(ancestor-or-self::dsig:Signature)</strong></XPath></Transform>, которая просто убирает все подписи перед вычислением хэша, что аналогично первому варианту;<br /><br />3) А если документ подписывается не целиком, а отдельными узлами, то здесь не важно сколько будет вложенных подписей, и поэтому даже не нужно никаких трасформаций (если конечно подпись не будет встраиваться в подписываемый элемент).<br /><br />И конечно, для всех случаев рекомендуется использовать трансформацию c14n или exc-c14n (указать после предыдущих трансформаций).</td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid114851:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer" width="100%"><tr><td>Большое спасибо за отзыв! <img src="/forum2/Images/Emoticons/eusa_angel.gif" alt="Angel" /> </td></tr></table>2020-04-24T18:00:41+03:002020-04-24T18:00:41+03:00Алексей87890<table class="content postContainer" width="100%"><tr><td>Большое спасибо за отзыв! <img src="/forum2/Images/Emoticons/eusa_angel.gif" alt="Angel" /> </td></tr></table>urn:https:--www-cryptopro-ru:ftPosts:st1:meid114826:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-inесли подпись вложена в сам тег, который подписан (enveloped), то не все программы проверки смогут обработать 2 подписи вложенные в один тег. Когда наоборот подписанный тег вложен в подпись (enveloping), то очевидно что теги вложенные в 2 подписи хоть и могут быть одинаковыми, но структурно это 2 разных тега.2020-04-24T12:09:57+03:002020-04-24T12:09:57+03:00two_oceansесли подпись вложена в сам тег, который подписан (enveloped), то не все программы проверки смогут обработать 2 подписи вложенные в один тег. Когда наоборот подписанный тег вложен в подпись (enveloping), то очевидно что теги вложенные в 2 подписи хоть и могут быть одинаковыми, но структурно это 2 разных тега.urn:https:--www-cryptopro-ru:ftPosts:st1:meid114777:1Мультиподпись XML документа в браузере через КриптоПро ЭЦП Browser plug-in<table class="content postContainer" width="100%"><tr><td>Спасибо большое за ответ! Попробуем этот вариант решения. А я правильно понимаю (перекопав документацию по "КриптоПро ЭЦП Browser plug-in" и "КриптоПро .NET"), что на данный момент нет такого API у библиотек КриптоПро для мульти-подписания XML со вложенными подписями?</td></tr></table>2020-04-23T10:08:35+03:002020-04-23T10:08:35+03:00Алексей87890<table class="content postContainer" width="100%"><tr><td>Спасибо большое за ответ! Попробуем этот вариант решения. А я правильно понимаю (перекопав документацию по "КриптоПро ЭЦП Browser plug-in" и "КриптоПро .NET"), что на данный момент нет такого API у библиотек КриптоПро для мульти-подписания XML со вложенными подписями?</td></tr></table>