Аннулирование сертификата
Применение сертификата допустимо только пока он достоверен. Опасно полагаться на то, что сертификат будет защищён и надёжен вечно. В большинстве организаций и во всех PKI сертификат имеет ограниченный срок «жизни». Это сужает период, в который система может оказаться под угрозой, если сертификат окажется взломан.
Таким образом, сертификат создаётся с определённым заданным периодом достоверности, начинающимся с даты создания и заканчивающимся датой истечения (аналогично сроку действия водительских прав). Сертификат может быть использован в течение всего периода действия, по истечении которого перестаёт быть верным, поскольку достоверность его идентификационно-ключевой пары более не может быть гарантирована. (Тем не менее, сертификат по-прежнему может применяться для подтверждения информации, зашифрованной или подписанной им ранее в течение периода жизни; однако он становится неприменим для будущих криптографических нужд.)
Но иногда появляется потребность сделать сертификат недействительным до истечения срока его жизни, например, в случае увольнения владельца сертификата с настоящего места работы или когда у владельца возникает подозрение, что закрытый ключ данного сертификата был скомпрометирован. Такой процесс называется отзывом или аннулированием. Аннулированный сертификат гораздо более подозрителен, нежели истекший. Истекший сертификат более непригоден к использованию, однако, не несёт такой угрозы скомпрометированности, как аннулированный.
Любой пользователь, заверивший сертификат (поручившийся за взаимосвязность ключа и сведений сертификата), в любой момент может отозвать с него свою подпись, используя тот же закрытый ключ, которым её создавал. Отозванная подпись указывает на то, что заверитель счёл, что открытый ключ и идентификационная информация более не связаны друг с другом, или что открытый ключ сертификата (или соответствующий закрытый) был скомпрометирован. Отозванная подпись имеет практически такое же значение, как и аннулированный сертификат.
В случае сертификатов Х.509 отозванная подпись фактически представляет то же самое, что и аннулированный сертификат, поскольку вообще лишь одна подпись была поручительством подлинности сертификата – подпись Центра сертификации. PGP предоставляет дополнительную возможность аннулирования всего сертификата (а не только подписей на нём), если вы вдруг посчитаете, что он был каким-либо образом скомпрометирован.
Только владелец сертификата (обладатель соответствующего закрытого ключа) или некто, специально уполномоченный владельцем (т.н. «доверенный отменитель», designated revoker), может аннулировать сертификат OpenPGP. (Доверение третьему лицу функции аннулирования весьма полезно, т.к. потеря пароля к закрытому ключу, которая зачастую и служит поводом к аннулированию, делает исполнение этой процедуры самим владельцем сертификата невозможной.) Сертификат Х.509 может быть отозван только его издателем – ЦС – по запросу владельца.
Уведомление об аннулировании сертификата
После аннулирования сертификата крайне важно оповестить всех потенциальных корреспондентов, что он более недействителен. Наиболее простой способ оповещения в среде PGP – это размещение аннулированного сертификата на сервере-депозитарии; таким образом, все, кто могут решить связаться с вами, будут предупреждены не использовать этот открытый ключ.
В среде PKI уведомление об аннулировании сертификатов осуществляется посредством специального механизма, называемого списком аннулированных сертификатов (Certificate Revocation List, CRL), публикуемого Центром сертификации. CRL содержит датированный заверенный список всех аннулированных непросроченных сертификатов системы. Аннулированные сертификаты остаются в списке только до момента своего фактического истечения, после чего удаляются оттуда – это предотвращает бесконечное разрастание списка.
ЦС обновляет CRL через регулярные промежутки времени. Теоретически, это должно свести к минимуму риск непреднамеренного использования аннулированного сертификата. Хотя, всё же остаётся вероятность случайного применения скомпрометированного сертификата во временном промежутке между публикациями CRL.
Прочитал документацию и все равно не догоняю.
Говорится что при создании ключевой пары (когда простой ключ)
надо сказу создовать сертификат revoke типа сразу для всего ключа по схеме
gpg.exe --homedir="?" --output "?\revoke.asc" --gen-revoke "0x?"
указывая UID только что сгенерированной ключевой пары.
А че делать с полученным сертификатом не говорится.
Что далее с ним делать? Мне что, его физически передать
некоемоему требуемоему мне лицу при физической встече с ним,
когда я ему сообщил что пара скомпроментированна?
Или же мне надо взять этот сертефикат и точно также как
я поместил открытый ключ на сервер открытых ключей, так и этот сертификат отзыва
залить на этот же сервер открытых ключей?
Как правельно HOW TO ПО ШАГАМ И ДОХОДЧИО, если не трудно!
И еще вопрос, а если ключ не простой, а содержит главный ключ подписания + подключ шифрования + подключ подписания.
Как тогда физически получить сертификат отзыва? Какую комманду записать в консоли?
Кактогда к примеру отозвать по отдельности скажем только главный ключ (и возможно сразу с подключами)?
А как тогда по отдельности отзывать подключи, если с главным все в порядке?
Возможно ли генерировать сертификаты revoke для подключей?
И напоследок еще вопрос.
А как генерить в консоли сертификат озыва для третьего лица, (т.н. «доверенный отменитель», designated revoker),
когда забыл пароль от ключевой пары? И есть ли здесь различие, если ключ простой и если он составной.
КАК ЭТО СДЕЛАТЬ В КОНСОЛИ ПЛИЗ HOW TO ДОХОДЧИВО И ПО ШАГАМ!
Заранее спасибо.
комментариев: 9796 документов: 488 редакций: 5664
По шагам в консоли пока не будет, но идея такая:
Это работает потому, что:
С помощью сертификата отзывается главный ключ связки, т.е. все подключи будут недействительными, даже если вы заново найдёте закрытый ключ и добавите новые подключи, они уже все будут недействительны. Сертификат отзыва нужен при утрате закрытого ключа. При наличии закрытого ключа можно отозвать отдельные подключи, а сертификат — это такой экстренный сигнал о компрометации, нештатной ситуации, когда уже нечего спасать отдельные подключи.
О unknown
благодарю за разьяснение, крайне понятно и доходчиво, картина сразу прояснилась.А я думал что надо просто его заливать на сервер ключей.
Так, уже понятно, даже уже догоняю как это сделать в консоли.
Первом приближении догоняю как это легко проворачивается для
простого ключа. Генерирую revoke сразу для всей пары и прячу и так далее если что.
Но мне охота юзать составной ключ по схеме главный ключ подписания + подключ шифрования + подключ подписания.
Что то не нашел в документации как сгенерить revoke для конкретного подключа? Это вообще возможно?
Или если будет сотавной ключ то прийдется его полностью отзывать? А если на нем сотни достоверных подписей и что тогда?
Или в принципе только возможно отзывать только весь ключ целиком сразу с подключами?
Тоесть если я правильно понимаю, то сертификат он как таковой применим только ко всей связке полностью,
сразу к главному ключю с подключами. Тоесь когда утрачен главный закрытый ключ.
Но вы говорите что если главный закрытый ключ не утрачен то можно отзывать подключи, как именно?
комментариев: 9796 документов: 488 редакций: 5664
Я дописывал свой ответ в последнем абзаце.
Сертификат отзывает весь ключ целиком при отсутствии закрытого ключа, это как экстренная мера.
Отдельные подключи можно отзывать, если закрытый ключ есть и нескомпрометирован. Если закрытый ключ скомпрометирован, то даже при наличии к нему доступа у законного владельца, этому владельцу надо отзывать всё — иначе скомпрометировавший его противник понавешает своих подставных подключей.
edit key → revkey
Да хоть срок действия поменять: edit key → expire
Тоесть для подключа нельзя сгенерировать revoke, верно?
И тогда сново этот подключ в его токрытой форме залить на сервер так?
комментариев: 9796 документов: 488 редакций: 5664
Можно, но не заранее сгенерированным сертификатом. Дополнил комент выше про edit key → revkey. Можно даже uid отозвать: edit key → revuid
Всегда так. Точнее, на сервер обратно заливается не подключ, а вся связка целиком, со всеми отзывами, добавлениями и прочими изменениями.
Логика в том, что только владелец главного закрытого ключа может что-то делать со связкой в плане добавления, отзыва, изменения подключей и уидов. Сертификат же не содержит в себе закрытого ключа, он содержит заверенную закрытым ключом специальную запись, которая показывает, что ключу настала полная хана.
А ну да верно, вся связка целиком, экпортирую только подключи,
главный секретный ключ держу разделенным от подключей, как по схеме
https://www.pgpru.com/bibliote.....mi/podkljuchiopenpgp
Все понял, спасибо огромное!
Стандарт это позволяет (как и отзыв uid'а), но в gpg такого функционала нет. Если готовы сидеть с шестнадцатеричным редактором [1] и склеивать PGP-пакеты в связку ключей вручную, то можно сделать.
комментариев: 11558 документов: 1036 редакций: 4118
Помимо склейки нужно ещё сгенерировать саму подпись на материале, так что в любом случае придётся либо писать свою реализацию, либо патчить gpg.
Создание сертификата отзыва возможно с подключа указанием ID этого подключа. Но когда этот
сертификат накатите на ключ, он отзовет этот подключ, а также весь ключ с подключами.
Поэтому подключ отзывается через edit-key revkey + save.
можно отозвать и UID через edit-key revsig + save.
И не забываем обратно закинуть на сервер ключей
Пипец, какой ты кретин. При создании сертификата отзыва он создаётся на весь ключ всегда. Его можно импортировать позже, и тогда главный ключ связки отзовётся. Сертификатов отзыва (штатных) для подключей нет. Когда делается revkey, PGP-пакет отзыва подключа генерируется и тут же добавляется на связку, никакая отложенность невозможна. Ты читаешь хоть, что пишут, или у тебя своё кино в голове?
У меня ключ S + подключ E + подключ S + один единственный UID.
Так вот, лезу в косоль и делаю:
1) кей 1 ревкей сейв = после этого перестает шифровать
2) кей 2 ревкей сейв = после этого по идее должен перестать подписывать, но подписывает главным ключом
3) Самое интересное уид 1 ревуид сейв = Самое интересное проверяю подписание, подписывает главным ключом. Проверяю шифрование, и он как не странно
Это баг с revuid ?
комментариев: 11558 документов: 1036 редакций: 4118
Главный ключ всегда по умолчанию CS.
С чего это "должен", если есть ключ с S-capability? "Должен" он был бы только в том случае, если главный ключ имеет только C-capability, и таки в этом случае он действительно не будет подписывать обычные данные.
Вероятно. Если у Вас последняя версия из конкретной ветки (1.4.x, 2.0.x, 2.1.x), пишите багрепорт разработчикам.