Есть удостоверяющий центр. Он выдает сертификат, то есть он генерит секретный ключ для пользователя, открытый ключ для пользователя, подписывает открытый ключ пользователя и подписывает его. Остается вопрос - как удостоверяющий центр передает сгенерированный секретный ключ конечному пользователю? Неужели это можно сделать только при личной встречи? А есть ли способ все делать удаленно? Я хочу сделать что-то вроде простого удостоверяющего центра. Есть сервер. Он должен сгенерировать сертификат и как-то передать осекретный ключ приложению пользователя. Как это обычно делается?
Распределение сертификатов, Как УЦ может передать секретный ключ пользователя
|
08.01.2007 23:08:50
|
|
|
|
|
|
11.01.2007 17:43:20
Первые 3 вопроса тоже можно решить. Распреденная схеме обслуживания клиентов УЦ достаточно распространена, например
https, пароли и временные сертификаты ещё никто не отменял  А по поводу: "Остается вопрос - как удостоверяющий центр передает сгенерированный секретный ключ конечному пользователю?" - например используя https по взаимной аутентификации сервер-клиент (сертификат сервера и временный сертификат пользователя) |
|
|
|
|
|
11.01.2007 18:12:29
Есть такой вариант - называется депонирование ключей. При этом закрытый ключ сохраняется в УЦ на случай утери (резервное копирование ключей). В этом случае, если ключи генерируются на клиенте, то оба из них передаются серверу. Если на ключи генерируются на сервере -то оба они передаются клиенту. Вопрос как - если по сети - то SSL с односторонней аутентификацией. Если так - то при личной встрече "на дискете" |
|||
|
|
|
|
11.01.2007 19:00:51
offtopic писал:
Pili писал
Естественно, проведя некий предварительный набор мероприятий и снабдив своих работников/клиентов всем необходимым (ключи цифровой подписи и тп) первые три шага (а также многие последующие задачи, связанные с идентификацией личности) тоже беспроблемно можно решать. Но суть то изначального вопроса в том (если я её сам правильно понял ) как всё сделать с нуля.Если речь идёт о строгой идентификации личности, всёравно на этапе вышеупомянутой предвариловки без личного контакта не обойтись. В Вешей же ссылке цитата:
Удачи. |
|||||||
|
|
|
|
12.01.2007 08:16:03
Предварительные мероприятия (напр. заключение договора, представление клиентом актов о готовности рабочих мест, наличие приказа об отв. лицах, письменное заявление) потребуются и в централизованной схеме обслуживания, в такой схеме можно обойтись без временных сертификатов. С нуля (без оформления документов) можно строить корпоративную схему обслуживаня (для своих пользователей), это чаще централизованная схема (когда свои пользователия рядом), но если имеются филиалы, например по городам, лучше перейти на распределенную схему.
Депонироваие ключей почти никто из УЦ не применяет, это лишняя ответственность, к тому же депонирование не регламентировано законодательно. |
|
|
|
|
|
12.01.2007 12:19:28
однозначно 
А сертификат сервера у нас (у пользователя) откуда взялся? А как сервер убедился, что временный сертификат он именно наш использует, а не человека-по-середине? |
|||||
|
|
|
|
12.01.2007 15:07:19
Владимир, почитайте внимательно схему
и регламент распределенной схемы обслуживания Там все хорошо описано. |
|
|
|
|
|
12.01.2007 17:32:51
к сожалению я плохо сформулировал свое утверждение. Посредством почтовой (заказной)или курьерской (фельдегерской) связи можно исключить физическое появление пользователя в Центре. Другими словами - можно заменить с той или иной степенью надежности передачу из рук в руки на передачу по почте. Я же имел в виду невозможность общаться полностью виртуально. И это уже не зависит от регламентов и схем.
|
|
|
|
|
|
29.01.2007 10:54:38
ClosedGL все верно написал. Когда вы генерируете сертификат, его закрытый ключ не покидает хранилища сертификатов вашего компьютера, просто данные вашего сертификата подписываются УЦ. Правда УЦ нужно выбирать посолиднее.
|
||||
|
|
|
|||
Читают тему