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

PS. Под 32-х разрядную версию уже есть бета, под 64-х - месяца 2...

Наш разработчик, который занимался модулем поддержки для КриптоПро CSP, выходит в понедельник. Тогда он и ответит.

Нет, 2.05 - это без поддержки Висты. Повторяю, у нас пока есть только бета-версия, а беты мы на сайт не выкладываем. Если есть желание погонять бета-версию, пришлите запрос на hotline@rutoken.ru и мы Вам ее вышлем.

Простите, можно немного прояснить мою голову насчет сертификатов?

Вы совершенно правильно заметили - эта команда позволяет поместить в ранее созданный контейнер с ключевой парой, сертификат, соответствующий этой паре. Действительно, способы работы с CryptoAPI 2.0 описаны крайне плохо. По крайней мере, в документации в MSDN Library по функции CryptSetKeyParam, достаточно четко написано как записать сертификат в контейнер. Для получения более полной информации можно посмотреть статью "The Smart Card Cryptographic Service Provider Cookbook" из MSDN Library - в ней достаточно полно описана внутренняя структура CSP.

Дело в том, что интерфейсы CryptoAPI созданы Microsoft, а Rutoken Cryptographic Service Provider является лишь реализацией конкретного модуля по этому интерфейсу. Со всеми крипто-провайдерами работа, с точки зрения программиста ведется совершенно одинаково. Описания полнее, чем в MSDN Library просто не существует (хотя оно далеко не полное).

При возникновении подобных трудностей с использованием Rutoken CSP обращайтесь в форум или техническую поддержку компании "Актив".

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

Относительно Rutoken CSP.
Крипто-провайдер, исходя из архитектуры CryptoAPI, - это модуль реализующий некоторый криптографический функционал. Весь этот функционал можно поделить на две большие группы: реализация криптографических алгоритмов и хранение ключевой информации. Основное назначение Aktiv ruToken CSP - позволять пользователям CryptoAPI хранить ключевую информацию на Rutoken. При этом, чтобы крипто-провайдер имел тип PROV_RSA_FULL, необходима поддержка соответсвующих алгоритмов. Мы не писали свою реализацию этих алгоритмов, а просто перенаправили соответсвующие вызовы к Microsoft Enhanced Cryptographic Provider. Это сделано для того чтобы дать пользователям больше возможностей по использованию ключевой информации, хранимой на Rutoken.

По-поводу ГОСТ.
Если мы говорим о ГОСТ 28147-89, поддерживаемом Rutoken, то ситуация следующая: архитектура CryptoAPI не поддразумевает долговременное использование одного и тоже ключа симметричного алгоритма, для шифрования разных сообщений. По этому особого смысла поддержки в Aktiv ruToken CSP нет.
Если говорить ГОСТ 34.10-94 или ГОСТ 34.10-2001, то поддержка имела бы смысл, если эти алгоритмы были реализованы аппаратно на Rutoken. На сегодняшний день, Rutoken не содержит аппаратную реализацию этих алгоритмов.

Отвечу по путнктам:
1. При создании подписи, в структуру подписи кладутся как минимум сведения о владельце закрытого ключа, при помощи которого осуществлялась подпись. Эта информация указана только в сертификате соответсвующего ключевого контейнера.
2. Уточните, что именно связано и с чем? (Наиболее подробно про ALG_ID, AT_KEYEXCHANGE и AT_SIGNATURE можно прочитать в статье: http://msdn2.microsoft.com/en-us/library/aa375549.aspx)

По пунктам:

1. При создании подписи можно использовать две функции CryptSignMessage и CryptSignMessageWithKey.
CryptSignMessage в явном виде принимает на вход контекст сертификата, используемого для подписи.
CryptSignMessageWithKey принимает на вход только открытый ключ.
И в том и в другом случае подписанное сообщение содержит некоторую информацию о владельце открытого ключа, как минимум сернийный номер сертификата. Таким образом сертификат владельца должен быть доступен. Многие приложения при этом требуют, чтобы сертификат был зарегистрирован в локальном хранилище, для создания подписи.
Самый удобный способ передать получателю сообщения открытый ключ - передать сертификат. Так как получатель сможет при этом не только проверить саму подпись, а так же информацию о владельце ключевой пары (CRL, timestpamping и т.д.) - большинство приложений именно так и делают. Это правильно с точки зрения безопасности, с точки зрения PKI.
Для работы приложений от Microsoft необходимо наличие сертификата в локальном хранилище. Если при этом его нет в контейнере, для пользователя ни чего страшного не происходит, пока он не попытается использовать эту ключевую пару на другом копьютере - ему придется каким нибудь образом перенести туда сертификат.
2. CryptGetUserKey будет отрабатывать, если в контейнере есть ключевая пара - наличие других свойств не влияет на работу функции.
3. Это сделано для возможно расширения функционала. Akriv ruToken СSP v.1.0 поддерживает только ключи у которых dwKeySpec только AT_KEYEXCHANGE или AT_SIGNATURE.