Если Id файл дискредитирован

[seoman2]

Какой алгоритм применяют в лотусе, в случае утери id файла?
Человек, который ставит подписи утерял свой id. И получается, что теперь возможно кто-то может подписывать документы с его подписью, если знает пароль на ид.
Как сделать старый id - недоверяемым, и выдать новый сертефицированный id юзеру?

В документе сервера есть опции в Security Settings:
Check passwords on Notes IDs:
Compare public keys:

Но как туда загнать дискредитированные ID?

Если ид заблокирован, то цифр подпись невалидна?

Как сгенерировать юзеру новый открытый ключ? получается фактически новый ид сделать.

есть ещё проверка пароля. рекомендуют ей пользоваться...

 

[Akupaka]

тему в админку надо, имхо.

 

[ToxaRat]

совсем недавно же было
напишите дескридитировали по английски и сразу найдете статью на ИБМ

 

[seoman2]

Ещё вопрос, после подписания дока, кроме самой подписи открытый ключ подписавшего храниться в документе? Или при проверке подписи открытый ключ подписавшего ищется не в доке,а в адресной книге сервера?

 

[Akupaka]

при проверке подписи открытый ключ подписавшего ищется не в доке, а в адресной книге сервера

Да вроде так, но не только сервера, есть же еще ключи, которые пользователь импортировал себе.
Но в доке его хранить нет смысла, т.к. тогда можно было бы подделать документ, подпись, и ключ для проверки тут же положить. Кому это надо?
Могу ошибаться...

 

[ToxaRat]

документ подписывает личным ключом, проверяется публичным
публичный ключ может быть как в АК пользователя так и в Ак сервера

 

[seoman2]

А если пришел документ с ЦП на сервер от стороннего адресата, то возможно же, что открытый ключ адресата не попал на сервер в АК?
Где его тогда брать для проверки подписи?
А для проверки открытого ключа есть сертификаты.

напишите дескридитировали по английски и сразу найдете статью на ИБМ

Можно ссылочку?

 

[Akupaka]

А если пришел документ с ЦП на сервер от стороннего адресата, то возможно же, что открытый ключ адресата не попал на сервер в АК?

есть же еще ключи, которые пользователь импортировал себе

либо иметь общий внешний центр сертификации и проверки ключей, вероятно.

 

[Мыш]

Ссылка скрыта от гостей

Ключи-то можно сменить, но есть подозрение, что при проверке подписи будут использоваться сначала локально сохраненные сертификаты *, а потом уже из общей АК. Т.е., "старый" ключ будет валиден. На самом деле, это надо проверять...

* Точно помню, что была в свое время проблема с шифрованием документов. Т.е., пользователь1 скопировал себе в личную АК документ пользователя2 (естественно, вместе с сертификатом). У последнего меняются ключи. Далее пользователь1 отправляет шифрованное письмо пользователю2, тот не может открыть - т.к. оно зашифровано его "старым" ключом. Ессно, помогало удаление документа из личной АК...

 

[Constantin A Chervonenko]

Но в доке его хранить нет смысла, т.к. тогда можно было бы подделать документ, подпись, и ключ для проверки тут же положить. Кому это надо?
Могу ошибаться... :ya_lamo:

Ошибаешься. Именно что все ПУБЛИЧНЫЕ (самого подписанта и всех вышестоящих сертификаторов) ключи к подписи прилагаются.
Кому это надо? Тому юзеру, который проверяет подпись, не имея доступа к АК с публичным ключом. Это бывает при автономной работе и просто в другом домене.

 

[Akupaka]

Ошибаешься. Именно что все ПУБЛИЧНЫЕ ключи к подписи прилагаются

Но в таком случае, я могу перехватить документ, подделать содержимое, подписать его нужным (поддельным) закрытым ключем, вложить туда нужный открытый ключ и отправить дальше!
И проверка пройдет успешно!
Константин, если я действительно ошибаюсь, приму ссылку на правильную инфу :ya_lamo:

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

 

[seoman2]

Но в таком случае, я могу перехватить документ, подделать содержимое, подписать его нужным (поддельным) закрытым ключем, вложить туда нужный открытый ключ и отправить дальше!
И проверка пройдет успешно!

Для этого есть сертификаты.

Так открытый ключ передается в документе или в АК храниться? Или обоими способами передается получателю?
И как можно откр. ключ импортировать в документ?

 

[Akupaka]

Для этого есть сертификаты

Для этого требуется доступный центр сертификации и верификации!

вот тут маленькая статейка

Ссылка скрыта от гостей

 

[seoman2]

Итого, как на сервере занести в черный список недоверяемый ид?
И как создать для существующего юзера новый ид?

 

[Akupaka]

ищи похожее "Revoke Certificate"...
а може просто пересоздать пользователя?

 

[seoman2]

Можно и так, но как правильно блокировать старый ид???

 

[ToxaRat]

Можно и так, но как правильно блокировать старый ид

самое простое решение это включить проверку пароля и заставитьв всех сменить пароль

 

[am4]

Можно и так, но как правильно блокировать старый ид???

ID lockout в админовском хелпе.

 

[Klido]

как правильно блокировать старый ид

вон там мы обсуждаем тему про FAQ - а это оно и есть ссыль #1 в гугле...

Ссылка скрыта от гостей

Добавлено:

включить проверку пароля и заставить всех сменить пароль

включить сверку ключей и сменить ключи - надежнее, т.к. злоумышленник может подобрать на старый id новый пароль

 

[Constantin A Chervonenko]

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

"Фигушки! Я плотоядная!!"(с)
Принципы Лотусёвой аутентификации, изобретённые Рэем Оззи уж лет чуть не 20 как назад, замечательно растолкованы в старой книге Ионцева Н.Н., Некрасова и C[sup]o[/sup] (Интертраст, про 4-ку ещё).
Если ОЧЕНЬ коротко, то:
1.В подписи есть ВСЕ сертификаты (открытые ключи), как самого подписанта, так и его вышестоящих сертификаторов
2.Проверяющий смотрит, есть-ли что-то из этих сертификатов в его собственном ID (не обращаясь к сёрверу!).
3.Предположим, самый старший сертификат у них общий. Тогда проверяющий проверяет эл.подпись на следующем (вниз по дереву) сертификате (сертификат - это публ.ключ, заверенный эл.подписью вышестоящего сертификатора. Публ.ключ его у юзера есть в ID).
4.Если сертификат неподделан, то ключ из него используется для проверки следующего, вниз по дереву имен, сертификата в подписи.
.. и т.д., до последнего юзерского сертификата
5.Теперь у проверяющего есть проверенный публ.ключ подписанта. Ним и проверяется эл.подпись самого документа
Ы?

Гениальная схема! Ничего заранее пересылать не надо (при пересылке м.б. подменен)
По такой-же схеме происходит и взаимная аутентификация юзера с сервером