19.07.2005 17:15:15CAPICOM и eToken Ответов: 2
Дмитрий

Уважаемые знатоки помогите разобраться с механизмами ЭЦП

Необходимо подписвать данные из вэб форм.

Для этого для каждого вэб пользователя завожу в СА учетную запись и генерю
личный ключ и сертификат который скидываю пользователю на eToken. (пока что в ручную)

На стороне клиента пользователь заполняет некую вэб форму втыкает токен подписывает документ,
постит его на сервер вместе с формировавшейся подписью.

На сервере я проверяю подпись если все ОК то обрабатываю данные из вэб формы.

На стадии проектирвания возникло несколько вопросов.

1. Как автоматизировать процесс Создать пользователя + сгенерить запрос на сертификат +
получить сертификат и происталлить его в eToken.

подозреваю что надо делать это через объект CEnroll и методы createRequest InstallPKCS7
как только указать что надо проинсталлить сертификат именно на eToken

если можно то ссылки на примеры.


2. При проверке подписи

методом SignedData.Verify
возникает вопрос как это метод проверяет отправителя.
если во все примерах описано что в него предеается только сообщение и его подпись

например у меня есть два ключа я подписываю ими одно и тоже сообщения.

передаю в функцию SignedData.Verify она возвращает что все нормально.

я думал что подпись должна содержать данные об отправителе и при проверке будет два этапа

1. Действительно ли сообщение отпрвил тот то ?
2. Соответсвует ли хэш сообщению.

я думал что в функцию верификации должна передаваться информация об отправителе
как работает флаг CAPICOM_VERIFY_SIGNATURE_AND_CERTIFICATE

или же я чего то недопонимаю.



3. что в себе содержит подпись PKCS7

 
Ответы:
20.07.2005 12:11:12Kirill Sobolev
1. Да, именно CEnroll, только acceptPKCS7 а не InstallPKCS7. Вы наверное используете CSP от eToken? Тогда чтобы сертификат был установлен на eToken нужно установить флаг WriteCertToCSP = True
Насчет примеров поищите на форуме, много раз эта тема обсуждалась.
2. В подписи есть информация об отправителе. Хэш приходит зашифрованный, для его расшифрования нужен открытый ключ отправителя, иначе он не сойдется. После проверки подписи информация об отправителе попадает в SignedData.Signers.
3. RFC 2630
20.07.2005 16:42:23Дмитрий
Спасибо за ответ