По порядку: по идее подпись проверяется каскадом - а) проверяется SignatureValue с SignedInfo, если неверно выдается ошибка; б) проверяется каждый reference в SignedInfo на предмет соответствия DigestValue, если неверен выдается ошибка; в) если reference имеет особый тип (как signed properties) в рамках б) после сверки digestValue в Reference проводится проверка и самого текста SignedProperties. То есть если в) дает ошибку, это же считается ошибкой этапа б). Если техподдержка не разбиралась в деталях первый раз, то могут наговорить много ерунды.

Подробнее по в): по значениям Issuer и номеру сертификата выбирается сертификат (то есть перебирается каждый сертификат и декодируется из base64, берутся его свойства) из KeyInfo (этой проверке все равно что он там один!) и если сертифтикат не выбрался, то либо будет исключение либо получится совсем другое значение от пустой строки. Если сертификат выбрался, то действительно считается хэш от декодированного из base64 сертификата как массива байтов (сертификат к канонической форме не приводится). В итоге изначальная ошибка по б) может получиться по следующим причинам:
1. ID на который указывает URI из reference б) не уникален в документе и выбрался неправильный тег вместо signedProperties;
2. в документе нет тега с ID на который указывает URI из reference б).
3. изменение текста signedProperties и его потомков после вычисления хэша от канонической формы signedProperties (тут надо понимать что если каноническая форма signedProperties неэксклюзивная, то на нее повлияют и изменения пространств вышестоящих тегов, не только самого signedProperties и его потомков);
4. неверное вычисление канонической формы signedProperties (эксклюзивную можно проверить той программкой), тут же болтается параметр PreserveWhitespace, который не отражается в xml и надо подбирать при проверке если в xml присутствуют переводы строки и отступы перед тегами;
5. вычисление не той канонической формы signedProperties, что указана в reference б);
6. неверное вычисление хэша от канонической формы signedProperties (как правило маловероятно, но могут быть разные представления одного и того же значения хэша: little endian и big endian);
7. фактический алгоритм хэша от канонической формы signedProperties отличается от указанного в б);
8. неверные значения Issuer или номера сертификата;
9. неверное значение хэша сертификата (аналогично - little endian и big endian);
10. фактический алгоритм хэша сертификата отличается от указанного в signedProperties;
Пункты 1-7 аналогичны для а).

Правильно, более точно будет сказато что для тега в котором ID соотносится с URI в reference (в цитате из первого референса URI "#a03356a7e8bd4239ad69b3e9c949bca1", значит для тега с ID "a03356a7e8bd4239ad69b3e9c949bca1"). Это должен быть "подписываемый тег".В целом да, сначала трансформы потом вычисление хэша. Обратите внимение, что URI указывает на signedProperties, а не на ds:Object. Более точно сказать, что ds:Object просто обертка, а XadesObject это тег xades:QualifyingProperties и его потомки, так как более продвинутые версии формата Xades включают еще и неподписанные свойства (неподписанные в том смысле, что у них "не наша" подпись и для них не создается reference).

В C# мне немного неудобно разбираться. Как я понимаю, в итоге все идет в базовый объект от Майкрософт, который и вычисляет значения, поэтому нужно включить лог в нем. https://www.cryptopro.ru...&m=105590#post105590

Вообще при подписании последовательность такая - 1) формируем первый референс, применяем трансформы к подписываемому тегу, считаем хэш от результата трансформов, кодируем в base64 и заполняем в референс;
2) формируем второй референс, смотрим что это xades, считаем хэш от сертификата, берем реквизиты сертификата, заполняем SignedProperties;
3) применяем трансформы к signedProperties, считаем хэш от результата трансформов, кодируем в base64 и заполняем в референс;
4) когда все референсы готовы, применяем трансформы к SignedInfo, результат трансформа подписываем (то есть тоже вычисляется хэш, хэш подписывается закрытым ключом, соответствующим сертификату), результат подписи кодируем в base64 и заполняем в SignatureValue;
5) добавляем сертификат в KeyInfo (можно добавить всю цепочку, а не только один сертификат).
Обязательно - при расчете, изначальный вид задается требованиями ИС, он может или быть каноническим или не быть. Некоторые ИС требуют расположения атрибутов в определенном порядке (отличном от канонического), если не ошибаюсь ГИС ЖКХ как раз из таких и отправить канонический вид изначально не выйдет - после проверки подписи ГИС начнет ругаться на порядок атрибутов. Если бы такого не было - надежнее отправлять сразу каноническую форму с PreserveWhitespace = false, при этом будут выкинуты спорные символы.В принципе нормально, так как изначально форма требуемая ГИС ЖКХ, а не каноническая. В приложение можно вставлять только вычисляемый фрагмент (дополненный объявлениями пространств имен из вышестоящих тегов, на которые ругнется).
Если можно путь в исходнике и номер строки где это нашли.Например, мне будет гораздо проще проверить если не будет отступа пробелами и перевода строки перед каждым тегом внутри exportNsiListRequest, так как это тоже влияет на каноническую форму (сравните разные PreserveWhilespace в программке).

Я нашел это в инструкции ГИС ЖКХ по формированию подписи



Попробую - понять бы как это сделать только. Опять же кода много - уже пробовал PreserveWhitespace = false - все равно в результате есть и пробелы и переносы - осталось понять откуда они берутся.

Тоже попробую.
Вообще хотелось бы понять как проверить DigestValue и SignatureValue - ушел вникать что пояснил two_oceans

Кстати тестовый пример формирования подписи по ГОСТ 2001, который отправляет ГИС ЖКХ (собственно на нем я и пытаюсь сделать)
Не имеет проверки подписи на борту - все что я видел это проверка срока действия сертификата.

да там было "http://www.w3.org/TR/2001/REC-xml-c14n-20010315"

Вот тоже пытаюсь понять это.
единственное место где указывается каноникализация было стр 84 https://github.com/Good-...des/XadesBesSignedXml.cs

Естественно менял XmlDsigCanonicalizationUrl ("http://www.w3.org/TR/2001/REC-xml-c14n-20010315") на XmlDsigExcC14NTransformUrl (оно же "http://www.w3.org/2001/10/xml-exc-c14n#")
Но больше найти не смог...
Кстати по ответу по указанной ошибке поддержкой ГИС ЖКХ точно смотреть ничего не надо - я тут по инету посмотрел они много кому ответили таким же ответом - короче просто шаблон ответа скинули который более или менее подходил видимо

Длинные строки в сообщениях форума лучше заключать в тег code=markup (при написании сообщения выше кнопка "Выберите тип подсветки кода"-"Plain text") иначе страница форума искажается.

От приведенного в прошлом сообщении сертификата тестового центра действительно такое значение хэша.
1CD19045B5FCCF315AF45F5083B8CE3BCBAB346F77FBD018BB2106F5D55F8140
HNGQRbX8zzFa9F9Qg7jOO8urNG93+9AYuyEG9dVfgUA=
Однако в "out (2).xml" указан другой сертификат на ООО ***-КОСТРОМА с хэшем
88782576451F619BAB9B5FCE01B6C5143A96728C711E0B6651C6D50445952A55
iHgldkUfYZurm1/OAbbFFDqWcoxxHgtmUcbVBEWVKlU=

Строка влияет на SignedInfo, должны быть еще трансформы для референсов. Например,
https://github.com/Good-...ns/GostCryptoProvider.cs стр 84 и где правили второй трансформ по идее тоже должно быть (или по крайней мере, Вы в своем коде добавляли каноникализацию второго референса): https://github.com/Good-...ibrary/XadesSignedXml.cs или https://github.com/Good-...ns/GostCryptoProvider.cs или https://github.com/Good-...e/Library/XadesObject.cs В этих местах мелькает и PreserveWhitespace = true

Еще вот: https://github.com/Good-...lXmlDsigC14NTransform.cs стр 14 и 16 Надо полагать, это патч каноникализации для дотнет 3.5, ссылка на https://www.cryptopro.ru...=57702&find=lastpost

Насчет E= похоже здесь https://github.com/Good-...ations/IssuerComparer.cs стр 19 замена на оид

UPD: Исправил у себя обработку комментариев при каноникализации - теперь пример из сообщения 11проходит проверку и значения подписи и референсов (без проверки полей QualifyingProperties пока).

Отредактировано пользователем 9 сентября 2019 г. 12:57:18(UTC)  | Причина: Не указана

Конечно, это может быть причиной, однако в данном случае namespace добавлены верно, но еще одного не хватает в DigestMethod. Ненормально 2 факта: 1) в итоговом документе присутствую отступы пробелами перед тегами и переводы строк, а на отладке расчета DigestValue они отсутствуют (опять PreserveWhitespace... что-то мне кажется без точного понимания откуда что идет его изменение сделает только хуже, так как в коде тьма методов GetXml и надо похоже найти все и явно указать PreserveWhitespace); 2) тег DigestMethod без префикса и namespace, судя потому что каноническая форма его не изменила, попал вообще в default namespace. Это может привести к тому, что при проверке тег DigestMethod не найдется из-за различающегося namespace и будет выбран неизвестно какой алгоритм "по умолчанию" для расчета хэша сертификата (гост-2001, например). Странно, что в сообщении 11 файл "out (2).xml" был с правильным DigestMethod для сертификата.
Да, прошел primer 2012.xml. В out.xml пока ругается на все: как выяснилось отступы сделаны пробелами, а не табуляцией (мой дополнительный фильтр настроен на табуляции), то есть придется сделать аккуратную вырезку текстовых узлов в которых все символы с кодами меньше или равны пробелу (как в смэв 3 трансформе). Где-то бы найти хорошее пояснение по whitespace.
Ах да, это же ГИС ЖКХ, Вам достаточно долго удавалось попасть на кого-то относительно вменяемого в техподдержке, а теперь попался еще больший "попугайчик". Если проблема из-за DigestMethod для сертификата, то они вообще почти правильно сказали про DigestValue сертификата, только тег соседний на самом деле.

Отредактировано пользователем 10 сентября 2019 г. 7:08:46(UTC)  | Причина: Не указана