По схеме нюанс - если в сертификате есть фио, снилс, то пользователю надо показать подписываемое в каком-либо виде иначе это будет идти в разрез с законодательством.
По вопросам - принципе все так и есть. Разве что надо уточнить, что есть "значение подписи" (для ГОСТ оно в 2 раза длинее чем значение хэша, то есть 64-128 байт, используется на уровне низкоуровневого CryptoAPI, по сути это зашифрованное закрытым ключом значение хэша) и есть подпись "в сборе" (отличимо длинее обычно от 500 байт до нескольких килобайт) - включающая значение подписи и еще много чего: может включать сертификат, может включать цепочку сертификатов без корневого или с корневым, дополнительные данные (например, штамп доверенного времени, списки отзыва на момент подписания), могут даже включаться исходные данные. Если исходные данные присутствуют, то это присоединенная подпись, если данные отсутствуют, то отсоединенная (открепленная) подпись. Похоже что под "подписанный хэш" Вы имеете в виду "подпись в сборе".
1) Если содержится сертификат в "подписи в сборе", то отдельно его передавать нет необходимости. Если только "значение подписи" в низкоуровневые функции, то нужно передавать дескриптор открытого ключа, полученный импортом кусочка с открытым ключом из контекста сертификата.
2) Да, для ГОСТ есть однозначное соответствие между алгоритмом хэширования и алгоритмом подписи. В сертификате/контексте сертификата есть поле оида алгоритма открытого ключа и к нему 2 поля параметров: оид параметров алгоритма хэширования и оид параметров алгоритма подписи. Не вдаваясь в подробности - у алгоритмов открытого ключа значений меньше, поэтому я бы посоветовал ориентироваться на него. Подробнее я уже на этом форуме уточнял, наверно это четвертый или пятый подобный вопрос с августа прошлого года.
Обратите внимание, что в сертификате есть еще поля алгоритм подписи и алгоритм хэширования, их не нужно использовать, так как они указывают на алгоритмы ключа удостоверяющего центра (УЦ) и теоретически могут отличаться от алгоритма ключа самого сертификата. У аккредитованных УЦ ФСБ и Минкомсвязь принудительно ввели соответствие, но любые неаккредитованные УЦ (для тестовых сертификатов и т.д.) могут подписать сертификат клиента ГОСТ-2012 сертификатом УЦ ГОСТ-2001 и ввести в заблуждение программы, смотрящие не то поле.
3) Если получили "подпись в сборе", то в целом да. Если получили только значение, то нет.
Обратите внимание, что для пересылки туда-обратно данные обычно кодируются в base64. А плагин вообще почти всегда принимает и отдает данные в base64. Поэтому файл подписи по-хорошему должен быть не текстовый, а двоичный - записать в файл нужно двоичные данные после декодирования из base64. Однако некоторые средства проверки подписи принимают подпись и в кодировке base64. В тот же плагин нужно посылать кодированное значение. С текстовым вариантом подписи в base64 главное не забыть, что данные в файле уже кодированы и не закодировать по ошибке еще разок. Обычно есть список требований для конкретного случая и там указывается допустимость кодировки в файле подписи. Хотя есть и печальные случаи когда люди знают только слова "усиленная квалифицированная электронная подпись", но не могут пояснить детали.
Присоединенная подпись всегда больше чем исходные данные, так как их содержит. Поэтому если получили "подпись в сборе" и она меньше исходных данных, то это отсоединенная подпись.
Отредактировано пользователем 19 апреля 2019 г. 13:07:20(UTC)
| Причина: Не указана
