Для того, чтобы сформировать PKCS10-запрос на сертификат, необходимо заполнить ASN1-структуру

Затруднение вызывает заполнение поля signatureAlgorithm.

Понятно, что идентификатор алгоритма подписи для заданного криптопровайдера однозначно выводится из пары (<идентификатор алгоритма открытого ключа>, <идентификатор алгоритма хеширования>). <Идентификатор алгоритма открытого ключа> указывается при создании ключевой пары функцией CryptGenKey() и может быть в дальнейшем восстановлен при помощи функции CryptExportPublicKeyInfo(), а <идентификатор алгоритма хеширования> указывается при создании хеша функцией CryptCreateHash(). Таким образом, в момент генерации ЭЦП эти идентификаторы мне известны и доступны.

Для каждой конкретной пары идентификаторов открытого ключа и алгоритма хеширования идентификатор соответствующего алгоритма подписи можно определить, порывшись в различных RFC. Например, для КриптоПро CSP паре (1.2.643.2.2.19 (GOST R 34.10-2001), 1.2.643.2.2.9 (GOST R 34.11-94)) соответствует алгоритм подписи 1.2.643.2.2.3 (GOST R 34.11 / 34.10-2001). Но вот как решить эту задачу в общем виде при помощи универсального кода, обращающегося к CryptoApi, для заранее неизвестных криптопровайдеров?


P.S.: По ряду причин при формировании запроса на сертификат мне хотелось бы избежать использования более "высокоуровневых" CryptoApi-функций типа CryptSignCertificate(), которым идентификатор алгоритма подписи передается явно. Кроме того, я все равно должен как-то узнать, какой идентификатор в эту функцию можно передавать для данного криптопровайдера...

Ну, это не метод...

Ведь подпись-то функцией CryptSignHash() создается без явного указания идентификатора алгоритма подписи. Сигнатура этой функции просто не предусматривает передачу в нее этой информации. Вместо этого она сама как-то определяет алгоритм, который надо использовать. Для этого в ее распоряжении есть хэндл хеша, созданного при помощи функции CryptCreateHash(), в которую передается идентификатор алгоритма хеширования и хендл крипто-контекста ключевого контейнера, созданного и наполненного ключами при помощи функций CryptAcquireContext() и CryptGenKey(). Короче говоря, нигде в этой вполне штатной цепочке вызовов CryptoApi-функций, приводящей к созданию ЭЦП, идентификатор используемого алгоритма подписи явно не фигурирует.

Кстати, COM-объект XEnroll, который, насколько я знаю, используется в веб-интерфейсе MS СА успешно справляется с решеним данной задачи. Для того, чтобы с его помощью создать запрос на сертификат, ему достаточно указать тип и имя криптопровайдера (которые нужны функции CryptAcquireContext()) и идентификатор алгоритма хеширования (который нужен функции CryptCreateHash()):
У XEnroll'а есть еще куча свойств, которые позволяют задать различные флаги, влияющие на свойства создаваемого ключевого контейнера и ключей в нем, но прямого отношения к рассматриваемому вопросу они не имеют. В результате вызова метода xenroll_.createRequest(XECR_PKCS10_V2_0, ...) создается корректно заполненная ASN1-структура CertificationRequest, в частности, содержащая информацию об алгоритме подписи. При этом XEnroll в процессе создания ключей и запроса на сертификат у пользователя не спрашивает какой алгоритм подписи ему следует использовать.

Мыслите в правильную сторону

Он безусловно правильный, но алгоритмы хеширования и ОК все равно придется определять перебором из доступных для выбранного провайдера.

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

В результате, я упростил себе задачу и стал плясать от известных (на стадии разработки) криптопровайдеров и конкретных криптографических алгоритмов, которые нужно поддерживать. Для них все необходимые идентификаторы, параметры и способы их кодирования были заранее собраны и зафиксированы в коде - в конце концов, таких специфических деталей не так уж и много, а излишние обобщения тоже до добра не доводят :-)

Что касается

то я имел в виду следующее: поскольку у меня в проекте задача кодирования/декодирования различных ASN.1-структур в DER уже вполне успешно решена при помощи библиотеки BouncyCastle, мне хотелось по-максимуму избежать нудного заполнения CryptoApi-структур наподобие CERT_REQUEST_INFO, которые передаются в "высокоуровневые" функции типа CryptSignAndEncodeCertificate().

Справедливости ради нужно отметить, что конкретно упомянутая мной функция CryptSignCertificate() принимает уже закодированный в DER массив байтов, на что я не сразу обратил внимание. Но от этого она не становится намного более предпочтительной по сравнению с совсем базовой функцией CryptSignHash(). Она лишь скрывает вызовы функций CryptCreateHash(), CryptSignHash() и CryptHashData(), котрые совсем несложно реализовать и самостоятельно, но зато уже не позволяет подписывать произвольные данные, а только корректные ASN.1-объекты в DER-кодировке.

В любом случае всем спасибо за потраченное на мой вопрос время!