id: Гость   вход   регистрация
текущее время 13:23 17/10/2021
Владелец: SATtva (создано 14/09/2006 22:50), редакция от 01/12/2006 15:48 (автор: Гость) Печать
Категории: криптография, openpgp, инфобезопасность, сеть доверия, сайт проекта, руководства, управление ключами, стандарты
создать
просмотр
редакции
ссылки

Аннулирование сертификата


Применение сертификата допустимо только пока он достоверен. Опасно полагаться на то, что сертификат будет защищён и надёжен вечно. В большинстве организаций и во всех PKI сертификат имеет ограниченный срок «жизни». Это сужает период, в который система может оказаться под угрозой, если сертификат окажется взломан.


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


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


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


В случае сертификатов Х.509 отозванная подпись фактически представляет то же самое, что и аннулированный сертификат, поскольку вообще лишь одна подпись была поручительством подлинности сертификата – подпись Центра сертификации. PGP предоставляет дополнительную возможность аннулирования всего сертификата (а не только подписей на нём), если вы вдруг посчитаете, что он был каким-либо образом скомпрометирован.


Только владелец сертификата (обладатель соответствующего закрытого ключа) или некто, специально уполномоченный владельцем (т.н. «доверенный отменитель», designated revoker), может аннулировать сертификат OpenPGP. (Доверение третьему лицу функции аннулирования весьма полезно, т.к. потеря пароля к закрытому ключу, которая зачастую и служит поводом к аннулированию, делает исполнение этой процедуры самим владельцем сертификата невозможной.) Сертификат Х.509 может быть отозван только его издателем – ЦС – по запросу владельца.

Уведомление об аннулировании сертификата


После аннулирования сертификата крайне важно оповестить всех потенциальных корреспондентов, что он более недействителен. Наиболее простой способ оповещения в среде PGP – это размещение аннулированного сертификата на сервере-депозитарии; таким образом, все, кто могут решить связаться с вами, будут предупреждены не использовать этот открытый ключ.


В среде PKI уведомление об аннулировании сертификатов осуществляется посредством специального механизма, называемого списком аннулированных сертификатов (Certificate Revocation List, CRL), публикуемого Центром сертификации. CRL содержит датированный заверенный список всех аннулированных непросроченных сертификатов системы. Аннулированные сертификаты остаются в списке только до момента своего фактического истечения, после чего удаляются оттуда – это предотвращает бесконечное разрастание списка.


ЦС обновляет CRL через регулярные промежутки времени. Теоретически, это должно свести к минимуму риск непреднамеренного использования аннулированного сертификата. Хотя, всё же остаётся вероятность случайного применения скомпрометированного сертификата во временном промежутке между публикациями CRL.


Назад | Дальше


 
На страницу: 1, 2 След.
Комментарии [скрыть комментарии/форму]
— Гость (03/03/2015 14:09, исправлен 03/03/2015 14:51)   <#>

gpg (GnuPG) 1.4.18

— Гость (03/03/2015 14:57)   <#>
Уважаемый саттва, поясните пожалуйста CS. Не понимаю про C, а вот про S понял что это означает что ключ для подписания.
Сто означает С ?
— Гость (03/03/2015 15:02)   <#>
Проверина мессага насчет revuid, действительно начинает
шифровать отозванным подключом шифрования.

Правдо получилось тут же впихнуть костыль,
только не знаю, наверное так делать нельзя.

делаем uid x + revuid + key x (где х номер отозванного подключа шифрования) + disable + save

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

НАВЕРНОЕ это все таки БАГ, и очень не хороший
— unknown (03/03/2015 15:08)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Certify. Сертификация — это подпись подключей.
— Гость (03/03/2015 23:57)   <#>

revuid — отзыв uid'а в том смысле, чтоб он больше не показывался на связке как валидный, и ничего более. Почему это после его отзыва ключ должен переставать шифровать или подписывать? Не путайте отзыв uid'а с отзывами ключей и подключей.
— Гость (04/03/2015 08:18)   <#>
revuid — отзыв uid'а в том смысле, чтоб он больше не показывался на связке как валидный, и ничего более. Почему это после его отзыва ключ должен переставать шифровать или подписывать? Не путайте отзыв uid'а с отзывами ключей и подключей.


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

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

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

Почему это после его отзыва ключ должен переставать шифровать или подписывать? Не путайте отзыв uid'а с отзывами ключей и подключей.


Потому, что подключ шифрования уже отозван, до отзыва уида. А отзыв подключа приводит к тому,
что консоль gpg уже не позволяет пользоваться этим подключом, тоесть вы не можете шифровать с отозванным подключом
шифрования, можете только расшифровывать ранее зашифрованное. А речь идет о том, что до отзыва уида все так и получается,
отозванный подключ не позволяет зашифровывать, только лиш позволяет расшифровывать. И лиш когда дело доходит до отзва
уида, вот здесь БАГ и проявляется, ПРОЯВЛЯЕТСЯ в том что отозванный подключ шифрования начинает позволять шифровать, чего не должно быть.
— unknown (04/03/2015 09:47)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Если мне память не изменяет, то на подключ можно повесить несколько UID'ов и отзывать их хоть все сразу, хоть только по очереди. Если так, то тогда логично, что можно отозвать все, но всё ещё пользоваться подключом. UID хоть и привязан к ключу, но это отдельная сущность. Не баг, а фича.
— Гость (04/03/2015 11:05)   <#>
Если мне память не изменяет, то на подключ можно повесить несколько UID'ов и отзывать их хоть все сразу, хоть только по очереди. Если так, то тогда логично, что можно отозвать все, но всё ещё пользоваться подключом. UID хоть и привязан к ключу, но это отдельная сущность. Не баг, а фича.


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

Я тоже попробовал описанный алгоритм, отозвал подключ шифрования, и не смог далее его использовать для шифрования, смог только им расшифровать
перед этим зашифрованное. А после этого отозвал UID, и видимо разработчики где то в процессе накосячили, так как UID отображается отозванным,
подключ шифрования тоже отображается отозванным, однако же он вдруг начинает опять шифровать, но ведь такого не должно происходить,
ведь мы его отозвали, а раз он отозван, значит никто даже с открытого ключа не должен иметь возможности формировать им зашифрованные сообщения.
А так получается что если ты этот момент прошляпиш и отправиш обратно на сервер, то твоим отозванным подключом воспользуются, и тебе прийдет шифровка,
а вы этого хотите? Думаю что нет. Ну а далее для чичтоты эксперемента сделал revok на весь ключ с подключами целиком, и о чудо, все ключи отозванны,
все UID отозванны, подключ шифрования не позволяет шифровать, а только расшифровывать, что и ожидаемо от отозванного ключа. Значит гдето происходит
клин, и в отозванном ключе устанавливается возможность шифрования, хоть в консоли он отображается как отозванны.
— SATtva (04/03/2015 18:16)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4114

Ну за кого Вы меня принимаете? :) Просто перечитайте внимательно, о чём пишет Гость: он отзывает подключ — шифрование блокируется, затем отзывает UID — ключ снова начинает шифровать. По мне, это вполне себе баг бажище: отозванный ключ не должен применяться ни при каких обстоятельствах.

Если что, сам я воспроизвести пока не пробовал.


fixed. UID'ы никак не связаны с подключами, это элементы сертификата ключа. Потому-то описанное Гостем поведение никак не выглядит приемлемым.
— Гость (07/03/2015 14:52)   <#>

Теперь понял. Просто у него простыни бессмысленные, много флуда и воды, не относящейся к делу, поэтому смысл стал понятен не сразу.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3