id: Гость   вход   регистрация
текущее время 18:21 23/04/2024
Автор темы: Гость, тема открыта 04/01/2005 12:41 Печать
https://www.pgpru.com/Форум/РаботаСPGP/ПодписываниеКлюча
создать
просмотр
ссылки

подписывание ключа


Скажите пожалуйста, к примеру я поместил ключ некоторого человека NN на свою связку. Этот ключ мной подписан не был, однако он подписан другим человеком MM, ключ которого в свою очередь уже находится у меня на связке и мною подписан, причем для него установлен средний уровень доверия. В результате ключ человека NN автоматически становиться валидным, на что указывает зелененький шарик графы Validity. Вопрос: Стоит ли в этом случае подписывать ключ человека NN?


 
На страницу: 1, 2 След.
Комментарии
— SATtva (18/09/2005 20:00)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Сейчас нет установленной программы под рукой, но попробуйте посмотреть в PGPprefs.xml что-нибудь вроде MarginalValidityIsInvalid и переключить параметр в TRUE. Непосредственно в пользовательском интерфейсе настроек доверия, к сожалению, больше нет. Сам удивлён, зачем их убрали?
— Вий (19/09/2005 16:01)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
SATtva, добрый день! :)
Нашел в этом файле одну единственную строку со словом Validi
<key>marginalIsInvalid</key>
<false></false>
<key>displayMarginalValidity</key>
<false></false>
<key>wordWrapEnable</key>


И никаких ключей. Открыл файл с помощью FrontPage в виде программного кода. Это правильно?
— SATtva (19/09/2005 21:38)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Не надо ФронтПэйджа, он туда своих маркеров и мета-данных насуёт. Откройте простым Блокнотом и замените следующее:
<key>marginalIsInvalid</key>
<true></true>

— Вий (29/01/2006 13:09)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
SATtva, добрый день!
Ваш совет из предыдущего сообщения действует, спасибо. Однако не ясно следующее (далее я исхожу из настроек PGP9 установленных по умолчанию).
В статье основы криптографии описывалось, что для принятия программой ключа как подлинного нужно иметь как минимум 2 других подписанных ключа с установленной маргинальной степенью доверия или один ключ с установленным полным доверием. PGP9 дает валидность ключу и при наличии одного ключа с частичным доверием.
PGP требует одну Полностью доверяемую или две Частично доверяемых подписи, чтобы установить ключ как подлинный. Метод PGP приравнивания двух Частичных к одной Полной аналогичен тому, как иногда от вас требуют два вида документов, удостоверяющих личность. Вы можете посчитать Алису частично надёжной, также посчитать Боба частично заслуживающим доверия. Есть риск, что каждый из них в отдельности может случайно подписать липовый ключ, так что вы, вероятно, не станете предоставлять Полного доверия ни одному. Однако, вероятность того, что оба они подпишут один и тот же липовый ключ, довольно мала.

Я провел эксперимент и создал третий ключ. Получилось следующее:
Ключ А подписан ключом Б. Ключ Б подписан ключом С. Ключ С подписан моим ключом. Ключам Б и С присвоен присвоено маргинальное доверие.
Чего я ожидал. Ожидал того, что при такой последовательной цепочке как минимум ключу С нужно будет дать полное доверие для того, что бы программа расценила ключ А как достоверный, но этого не произошло.
Следовательно мне не понятна разница между установкой доверия маргинального и полного. Или я уже совсем запутался? :)
(в эксперименте использовались открытые ключи)
— Вий (29/01/2006 15:39)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Еще вопрос по аннулированию ключей, если можно.
В руководстве сказано
Кроме аннулирования своих ключей вы можете отзывать с чужих ключей собственные сертифицирующие подписи, например, если посчитаете, что ключ скомпрометирован и вы более не можете гарантировать его целостность и принадлежность только изначальному владельцу, или если по иным причинам не захотите, чтобы другие пользователи полагались на вашу подтверждающую подпись. Аннулированная подпись никогда не берётся в расчёт при вычислении достоверности ключа.

При аннулировании ключа Б, которым подписан ключ А, подпись, которая заверяла ключ А (от ключа Б) осталась не аннулированной. Выполнение операции Verifi Signatures было проведено. Пробовал разместить на связке как только открытый аннулированный ключ Б, так и аннулированную ключевую пару Б. Результат тот же.
— Гость (31/01/2006 07:32)   <#>
Вий, Всё верно. Аннулировать нужно саму подпись, а не ключ, её создавший.
— Вий (05/02/2006 16:42)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Давайте по порядку. Каким образом аннулируется подпись, каков порядок, механизм? Аннулировать подпись вручную на чужом ключе я не могу, так же я не могу заставить сделать это всех корреспондентов, которым я подписал ключ, тем более если таких подписей много, кому то будет просто некогда, а кто-то просто забудет это сделать, и тем более если я работаю на своей машине но не со своим ключом. То о чем говорите Вы мне не понятно, как можно аннулировать подпись не аннулируя при этом сам открытый ключ? Отдельно можно аннулировать лишь определенную запись сертификата на своем собственном ключе, если Вы отказались от использования определенного почтового ящика например, но это совсем другой случай. Я могу только создать (что следует из логики аннулирования самого ключа) сертификат отзыва подписи.

Как я себе представляю данную процедуру?
Случай первый – с участием аннулированного ключа и ключевой пары. Пусть мой аннулированный открытый ключ размещается на связке корреспондента (или обновляется им с сервера), ключ которого ранее был подписан моим ключом. Программа обнаруживает данное обстоятельство и автоматически производит отзыв подписи. Или все таки корреспондент должен выполнить данную операцию вручную? Тогда как?

Теперь вариант второй, с ключами которые принадлежат корреспондентам, этот случай я уже описал.
К примеру на моей связке есть ключи корреспондентов А и Б. Корреспондент А подписал ключ корреспондента Б, а после, через некоторое время, аннулировал свой ключ. Идем далее, я обновил ключи с сервера, в результате ключ А стал аннулированным. Сохраниться ли подпись ключа А поставленная на ключе Б действительной? В руководстве написано, что «Аннулированная подпись никогда не берётся в расчёт при вычислении достоверности ключа», тогда каким образом программа понимает данный случай? И зачем тогда опция Verifi Sign?
Если все таки программа самостоятельно должна отозвать подпись на ключе Б, останется ли подпись аннулированной при удалении аннулированного ключа А со связки?

Иными словами мне не ясно, на каком этапе происходит отзыв подписи.
— Гость (05/02/2006 20:05)   <#>
Каким образом аннулируется подпись, каков порядок, механизм? Аннулировать подпись вручную на чужом ключе я не могу,

Вы можете аннулировать свою подпись на любом ключе, в том числе чужом. В GPG для этого есть команда revsig – она отзывает подпись на выделенном UID. В PGP8 это делалось просто через граф. интерфейс.

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

Технически это аналогично отзыву подписи на чужом ключе – здесь тоже отзывается подпись.

Сохраниться ли подпись ключа А поставленная на ключе Б действительной?

Вкратце так. Сеть доверия себе представляете? Это ориентированный граф, в котором вершинами являются ключи, а рёбрами – подписи.
Отзыв ключа означает удаление вершины из графа. При этом из графа также удаляются все входящие в неё и выходящие из неё рёбра. Т.е. подписи на этом ключе и подписи, сделанные этим ключом не будут использоваться при расчетах достоверности ключей.
Отзыв подписи означает удаление ребра из графа. При этом вершины из графа не удаляются.
— sentaus (05/02/2006 20:06)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Предыдущее сообщение – моё.
— Вий (06/02/2006 14:47)   профиль/связь   <#>
комментариев: 510   документов: 110   редакций: 75
Все, спасибо. Что-то запарил я совсем. :) И в самом деле. Бывает иногда. Остался открытым вышеприведенный вопрос о разнице маргинального и полного доверия в PGP 9 при установках по умолчанию.
— SATtva (21/02/2006 21:06)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
К примеру на моей связке есть ключи корреспондентов А и Б. Корреспондент А подписал ключ корреспондента Б, а после, через некоторое время, аннулировал свой ключ. Идем далее, я обновил ключи с сервера, в результате ключ А стал аннулированным. Сохраниться ли подпись ключа А поставленная на ключе Б действительной?

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

Непосредственно аннулирования подписи A>Б на Вашей связке не происходит. Просто когда программа при запуске вычисляет граф локальной сети доверия (на Вашей связке), она пробегает пути по всем подписям. Если та или иная подпись отозвана, она, как описал sentaus, не принимается в расчёт (как будто её и не было).

Если все таки программа самостоятельно должна отозвать подпись на ключе Б, останется ли подпись аннулированной при удалении аннулированного ключа А со связки?

Подпись не будет выглядеть отозванной — программа не будет располагать ключом (А), чтобы сверить ЭЦП с сертификата аннулирования. Но поскольку на связке не будет ключа А, то и ключ Б, заверенный им, останется недостоверным.

Остался открытым вышеприведенный вопрос о разнице маргинального и полного доверия в PGP 9 при установках по умолчанию.

По умолчанию PGP признает частично достоверные ключи полностью достоверными. Исправить этот недостаток можно в настройках: где-то там должна быть опция вроде Treat marginally valid keys as invalid (привожу по памяти, поскольку включить службу pgpserv из-под юзерского аккаунта не могу). Та же самая опция в файле pgpprefs.xml имеет ключ marginalIsInvalid. Переключите его в True, и всё будет, как надо.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3