Выложите по возможности примеры "хорошего" и "плохого" подписанного xml. Попробуйте поиграть с PreserveWhitespace.

Похоже вложения не прикрепились. Попробую предположить вслепую, что Вы делаете подпись через низкоуровневые функции или плагин и сами собираете тег Signature - нужно проверить положение вставленного тега подписи Signature и вставленный текст, возможно вставляете не то и не туда. По идее при подписании всего документа (предполагаю что кроме SOAP:Envelope и вложенных в него тегов больше ничего нет в документе), он должен располагаться в конце документа перед , в референс указывается URI="" и в список трансформов под референсом добавляется урл трансформа enveloped signature. Трансформ enveloped signature показывает что подпись (подписи), располженную непосредственно под подписываемым тегом надо удалить при проверке перед расчетом хэша, без него в расчет хэша попадет и сама подпись следовательно хэш не сойдется, так как Вы считали хэш еще без подписи. Также не забудьте проверить, что текст SignedInfo не изменяется в процессе ручной сборки подписи после вычисления SignatureValue (лучше вообще вставить именно каноникализированный текст SignedInfo, от которого вычислено SignatureValue в готовую подпись). Также лучше избегать переводов строк с символом 13 в SignedInfo, разными системами стандарты применяются в разном порядке и есть различия в обработке символов с кодом 13. В идеальном случае символы 13 должны быть удалены перед каноникализацией в процессе "нормализации" документа, то есть каноникализация их вообще не должна обрабатывать при наложении подписи. Если несмотря на все это, все равно ошибка проверки, то возможно каноникализация проведена неверно.

Кстати, возможен еще вариант с "переворотом" значений хэша и/или подписи - в зависимости от криптопровайдера результат может быть "задом наперед" от требуемого XMLDSig формата и нужно поменять первый байт с последним, второй с предапоследин и т.д до середины перед переводом значения в Base64. Если плагин Вам результат выдал уже в Base4 то надо декодировать, перевернуть и снова закодировать. При длине 256 хэш должен заканчиваться один знаком =, а значение подписи двумя знаками ==. В случае гост-2001 и низкоуровневыми функциями нужно было перевернуть хэш, а значение подписи записать как есть без переворота. По гост-2012 было сообщение что порядок тот же, но у меня что-то тоже не сходится подпись, а верных примеров с гост-2012 для "калибровки" маловато, жду пока смэв начнет подписывать новым гост.

Если нужно, могу прогнать Ваши примеры через свою программку и уточнить на каком этапе проверки возникает ошибка.

Посмотрел файлы. Какая-то смесь разных требований если честно, пройти может только первый этап проверки подписи (проверка правильности SignatureValue), хэши в таком виде документа не могут сойтись. Попробую их проверить чуть позже, слегка изменив документ, а пока перечислю странности документа.

1. Исправлено: после перепрочтения текста стандарта в сообщении ниже уже не уверен в своем понимании трансформа enveloped signature, поэтому убрано в спойлер

Еще отмечу, что несмотря на удаление тега Signature и вложенных в него тегов трансформом enveloped signature, в подписываемом тексте должны сохранятся все остальные теги. В данном случае я вижу что в строке для подписи отсутствует тег SenderInformationSystemSignature, по стандартам он должен присутствовать (пусть и пустой), так как он тоже не удалится трансформом enveloped signature.

2. Важно то, что CanonicalizationMethod Algorithm применяется только к SignedInfo перед выработкой SignatureValue и ничего не говорит о каноникалилации тега на который ссылается референс перед вычислением DigestValue. Поэтому если Вы текст документа за исключением текущей подписи каноникализируете, то в трансформах должен присутствовать и метод каноникализации. Иначе при проверка каноникализация скорее всего не будет выполнена и получится другой хэш.

В принципе проверяющая сторона может выбрать некий алгоритм каноникализации по умолчанию, который используется когда никакого не указано. Например, чтобы проверить все примеры разных ГИС моя программа подбирает трансформ каноникализации хэша когда никакого не указано в трансформах референса, но выдает предупреждение что фактически использован такой-то алгоритм каноникализации при том что никакого не указано. Однако это уже натяжка стандарта под конкретные ГИС, лучше укаать явно какой алгоритм каноникализации Вы использовали перед вычислением хэша чтобы проверка точно прошла успешно.

Сразу скажу по порядку трансформов когда их несколько в одном референсе: в случае присутствия трансформа enveloped signature сначала указавается enveloped signature потом метод каноникализации. Если присутствует смэвовский трансформ он указывается после канононикализации. При другом порядке трансформы дают неожиданный результат.

3. Формат начиная с RequestMessage очень напоминает схемы СМЭВ3 (хотя и отличия есть, например MessageID не по требования смэв3 из метки времени и мак адреса, а сгенерирован случайно), по которым в SenderInformationSystemSignature помещается подпись от элемента SenderProvidedRequestData, а не от SOAP:Envelope.

Возможно нужно наложить две подписи - одну по требованиям смэв (в SenderInformationSystemSignature поместить подпись от элемента SenderProvidedRequestData с определенными смэв трансформами: исключающая каноникализация и смэвовский, при этом SenderProvidedRequestData должен иметь Id начинающийся с буквы и этот Id указывается в референс ури после решетки), вторую в конце документа, перед </SOAP:Envelope> с URI="" и трансформами: enveloped signature и каконикализацией. Обратите внимание, что при наложении подписей на теги вложенные один в другой важно соблюдать порядок наложения подписей - сначала подписать вложенный тег потом обрамляющий тег (но без исключения подписи вложенного тега).

Другой вариант - что вторая подпись накладывается на какой-то другой из тегов (SOAP:Body или EPLTSAddData или RequestMessage). Это все же нужно уточнить в требованиях предъявляемых конкретной ИС. Либо все-таки какой-то правильный пример из руководства пользователя хотелось бы посмотреть чтобы не гадать.

Отредактировано пользователем 22 мая 2019 г. 12:19:14(UTC)  | Причина: Не указана

Хм, или я неправильно понимаю трансформ enveloped signature или что-то тут не так.

Ну хорошо, пусть текущая подпись (содержащая алгоритм enveloped signature) убирается где бы ни была, тогда навскидку вижу отличия: 1) нет XML Declaration Ваши файлы вроде бы уже в UTF-8, но без данной строки в начале (строка должна появиться в итоговом варианте, в остальных может отсутствовать, так как все равно удаляется при каноникализации); 2) все же надо вставить пустой тег SenderInformationSystemSignature в строку для подписи; 3) замечание про указание каноникализации из прошлого моего ответа все равно может быть в силе (хоть трансформ каноникализации не указан в примере, может быть не лишним его указать).

Сейчас изменю трансформ в своей программе и попробую проверить на предмет порядка байтов.

Отредактировано пользователем 22 мая 2019 г. 12:20:52(UTC)  | Причина: Не указана

По "правильному" файлу можно ли определить данные в каких тегах подписываются?