Еще вдогонку вот что у меня получается после шифрования ключа:
https://lapo.it/asn1js/#

Как я понял, вот это вектор инициализации:
OBJECT IDENTIFIER 1.2.643.2.2.21 gostCipher (GOST 28147-89 (symmetric key block cipher))
SEQUENCE (2 elem)
OCTET STRING (8 byte) ECCCB62C6F797C0D

А вот это данные:
OBJECT IDENTIFIER 1.2.643.2.2.31.1 cryptoProCipherA (CryptoPro params A (default, variant 'Verba-O') for GOST 28147-89)
[0] (32 byte) 930C0B9EEB04CE3896A6026C85E466F40297EAD51E65E622F41B23B001626CAA

Хотя смущает надпись (default, variant 'Verba-O')....

Ага, стало понятнее про ключ.
А вот с шифрованием не совсем! Дело в том, что я реализую шифрование в SAP, а там это встроенный функциональный модуль (который просто передает данные в КриптоПро через специальную прослойку), на вход которому я подаю свой случайный ключ, и идентификатор ключа(сертификата) из личного хранилища (в данном случае ФСС). И на выходе получаю бинарные данные в формате PKCS7. Никаких векторов инициализации я не создаю и не передаю. По всей видимости КриптоПро это делает за меня.
Вот я и пытаюсь понять, могу я использовать стандарт SAP и просто потом парсить выходные данные и раскладывать их в запрос. Или же надо что-то свое стороннее делать и вызывать из SAP этот функционал.

Добрый день! Сложно сказать без самого файла. Тег Signature как формируете, если получаете RAW_GOST?

Гадание на кофейной гуще: в файле может быть несколько подписей к разным фрагментам файла и возможно перепутали какой фрагмент к какой подписи должен относиться.

ФСС проверяет подписи несколько странно и в обход некоторых деталей стандартов: рекомендуемые атрибуты невалидны по стандартам, но их приходится использовать. Кстати, посмотрите что у Вас получилось в итоге, не исказился ли исходный текст (раз уж он "заранее каноникализирован").

Еще теоретически ФСС в своей реализации проверки вполне может взять фрагмент не смотря на reference URI (взять тот который должен быть подписан по мнению ФСС) и в этом случае выдаст что неверная ЭП, даже если у Вас подпись верна, но верна для другого фрагмента. Перепроверьте еще раз что нигде не спутали, какой именно фрагмент подписывается подписью с определенным actor .

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

Проверка: значение хэша в референсе совпадает с действительным, значение хэша от SignedInfo не проверяется по SignatureValue и сертификату.

Проверяем глазами SignedInfo и выходит что for_sign.xml не каноничен, не хватает определения пространства имен у корневого тега фрагмента. Должно быть:Фрагмент должен быть самодостаточным и содержать все объявления использованных пространств имен. Собственно для SignedInfo как правило одно пространство, если нет заковыристых трансформов с параметрами. Это достаточно частая ошибка, так как если был тег с префиксом, парсер бы указал что в "куске" документа ("кусок", а не "фрагмент", потому что получен строковыми операциями) префикс неопределен, но тут тег без префикса и парсер считает что это пространство имен по умолчанию, а не пространство имен "http://www.w3.org/2000/09/xmldsig#", соответственно при каноникализации куска ошибки не выдалось, но в собранном документе каноническая форма будет уже с пространством имен. Кстати, почему в подписанном документе объявление пространства имен в SignedInfo есть? Добавили после подписания (при сборке) и тем самым нарушили подпись?

Рекомендую сделать SignedInfo (и дочерние теги) с тем же префиксом ds что и Signature. Работает конечно и с разными, но могут быть такие недетектируемые коллизии.

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

Отвечу сам себе (разобрался за полдня). Вот такой должен быть тег <ROW>: template_canonical_row_new.xml (2kb) загружен 26 раз(а).