— SATtva (02/03/2015 11:31)   
Вы читали это^[link1] и это^[link2]? Если да, то приведите конкретно, что Вам неясно в документации.

— Гость (02/03/2015 11:35, исправлен 02/03/2015 11:51)   

The web of trust allows a more elaborate algorithm to be used to validate a key. Formerly, a key was considered valid only if you signed it personally. A more flexible algorithm can now be used: a key K is considered valid if it meets two conditions:

it is signed by enough valid keys, meaning

you have signed it personally,

it has been signed by one fully trusted key, or

it has been signed by three marginally trusted keys; and

the path of signed keys leading from K back to your own key is five steps or shorter.

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

1) он подписан другим достоверным ключом, включая

ИЛИ

2) путь от некоего ключа K к вашему короче пяти или четырех ключей

— Гость (02/03/2015 11:41)   

Figure 3-1 shows a web of trust rooted at Alice. The graph illustrates who has signed who's keys. The table shows which keys Alice considers valid based on her trust in the other members of the web. This example assumes that two marginally-trusted keys or one fully-trusted key is needed to validate another key. The maximum path length is three.

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

— Гость (02/03/2015 11:46)   

When computing valid keys in the example, Blake and Dharma's are always considered fully valid since they were signed directly by Alice.

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

The validity of the other keys depends on trust.

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

In the first case, Dharma is trusted fully, which implies that Chloe's and Francis's keys will be considered valid.

В первом случае к дхарме полное доверие, отсюда вытекает что ключи хлои и френсиса также полностью подлинные.

— Гость (02/03/2015 11:51)   

In the second example, Blake and Dharma are trusted marginally. Since two marginally trusted keys are needed to fully validate a key, Chloe's key will be considered fully valid, but Francis's key will be considered only marginally valid.

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

— Гость (02/03/2015 11:54)   

In the case where Chloe and Dharma are marginally trusted, Chloe's key will be marginally valid since Dharma's key is fully valid.

В случае когда доверие к ключам хлои и дхармы только частичное, ключ хлои только частично подлинный, в то время как ключ дхармы полностью подлинный,
так как его подписала сама алиса.

— Гость (02/03/2015 11:59)   

Francis's key, however, will also be considered marginally valid since only a fully valid key can be used to validate other keys, and Dharma's key is the only fully valid key that has been used to sign Francis's key.

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

— Гость (02/03/2015 12:03)   

When marginal trust in Blake is added, Chloe's key becomes fully valid and can then be used to fully validate Francis's key and marginally validate Elena's key.

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

— Гость (02/03/2015 12:08)   
Lastly, when Blake, Chloe, and Elena are fully trusted, this is still insufficient to validate Geoff's key since the maximum certification path is three, but the path length from Geoff back to Alice is four.

В последнем случае есть полное доверие к ключам блейка хлои и елены, но этого не достаточно чтобы утверждать что ключ геоффа подлинный, так так чтобы это утверждать,
длина цепочки должна состовлють три, а у нас от алисы получается уже четыри (алиса – блейк – хлоя – елена).

Надеюсь ВАМ это поможет разобраться во всех хитросплетениях.

— Гость (02/03/2015 12:14)   

Вы читали это и это? Если да, то приведите конкретно, что Вам неясно в документации.

Надеюсь ВАМ это поможет разобраться во всех хитросплетениях.

Благодарю за перевод, великой душевной шедрости ЧЕЛОВЕК. Потихонюку разбираюсь.

— Гость (02/03/2015 12:15)   

Благодарю за перевод, великой душевной шедрости ЧЕЛОВЕК. Потихонюку разбираюсь.

НЕ СТОИТ, всегда рад помочь новичкам.

— Гость (02/03/2015 12:32)   
А правильно понимаю, что PGP не имеет сети доверия,
сеть доверия есть только у GPG? А как тогда проверять ключи
чисто PGP? Кому в этом случае доверять? Корпорации Семантик?
Как проверить ключ PGP?

— unknown (02/03/2015 12:47, исправлен 02/03/2015 12:48)   

Неправильно, имеет, OpenPGP стандарт общий, в реализации также много общего.

Вопрос только, зачем сейчас кому-то ещё нужно PGP вместо GnuPG, за исключением случаев коммерческого использования и аутсорсинга безопасности?

— Гость (02/03/2015 12:53)   

Вопрос только, зачем сейчас кому-то ещё нужно PGP вместо GnuPG, за исключением случаев коммерческого использования и аутсорсинга безопасности?

Но веди PGP используют. Так как проверить подлинность через PGP?

— SATtva (02/03/2015 12:56, исправлен 02/03/2015 12:57)   

Точно так же, модель та же самая, смотрите ссылки в начале треда. Отличие по сути только в том, что по умолчанию достаточно двух частично доверенных подписей (если в последних версиях ничего не поменяли).

— Гость (02/03/2015 14:28, исправлен 02/03/2015 14:42)   

Но веди PGP используют. Так как проверить подлинность через PGP?

[moderator]
Нижеследующая инструкция содержит ложные выводы. Следование ей способно скомпрометировать вашу безопасность.
[/moderator]

Для PGP это делается так. Применительно к GPG, так как у самого нет PGP, но можно посмотреть.
1) Идем на официальный сайт ключей симантика https://keyserver.pgp.com/vkd/GetWelcomeScreen.event
2) Ищем ключ филла циммерманна по ID prz@mit.edu или почте prz@mit.edu
3) Скачиваем этот ключ
4) Импортирруем на связку
5) Открываем его через консоль
6) gpg.exe --homedir="?" --list-sigs
7) видим что на нем много подписей, значит он подлинный

pub 1024D/B2D7795E 2001-01-04 sig R B2D7795E 2001-01-04 Philip R. Zimmermann <prz@mit.edu> uid Philip R. Zimmermann <prz@mit.edu> rev 6EE93242 2002-12-10 [User ID not found] sig CF73EC4C 2001-01-06 [User ID not found] sig F414952B 2001-01-07 [User ID not found] sig N B2D7795E 2007-03-02 Philip R. Zimmermann <prz@mit.edu> sig CA57AD7C 2015-02-22 [User ID not found] uid Philip R. Zimmermann <prz@acm.org> sig CF73EC4C 2001-01-06 [User ID not found] sig F414952B 2001-01-07 [User ID not found] sig N B2D7795E 2007-03-02 Philip R. Zimmermann <prz@mit.edu> sig CA57AD7C 2015-02-22 [User ID not found] uid [jpeg image of size 3457] sig N B2D7795E 2007-03-02 Philip R. Zimmermann <prz@mit.edu> uid Philip R. Zimmermann <prz@philzimmermann.com> sig N B2D7795E 2007-03-02 Philip R. Zimmermann <prz@mit.edu> sig CA57AD7C 2015-02-22 [User ID not found] sub 3072g/A8E92834 2001-01-04 sig B2D7795E 2001-01-04 Philip R. Zimmermann <prz@mit.edu>

к примеру sig sig CF73EC4C все на том же https://keyserver.pgp.com/vkd/GetWelcomeScreen.event
находим этого пользователя Will ну и так далее по всем подписям.

ОБРАТИ ВНИМАНИЕ на подпись CA57AD7C PGP Global Directory Verification Key. Эта подпись говорит о том что компания
семантик подписала ключ филла циммермана, говоря о том что семантик подтверждает подлинность ключа филла циммерманна и полностью доверяемт его ключу.
А ТАКЖЕ то что филл циммерман подписал ключ CA57AD7C PGP Global Directory Verification Key компании семантик, он утверждает его подлинность и полностью ему доверяет.

СКЛАДЫВАЯ ВСЕ СЕМЬ ПУНКТОВ, мы делаем вывод что ключ филла циммерманна на сервере ключей семантика ПОЛНОСТЬЮ подлинный и ему можно ПОЛНОСТЬЮ доверять.

— SATtva (02/03/2015 14:40)   

Никогда так не делайте. Сгенерировать ключ с любым UID — не проблема, сгенерировать кучу других ключей и подписать ими первый — не проблема.


Ничего подобного. Это подпись автоматической валидации почтового адреса и ничего более. Никакой проверки, принадлежит ли этот ключ и email тому человеку, имя которого указано в UID, не проводится.

Гость написал какой-то феерический бред, не читайте его.

— Гость (02/03/2015 14:47)   
А можно по подробнее про

подпись CA57AD7C PGP Global Directory Verification Key

У многих на открытых ключах ее вижу, не могу понять откуда она берется? И для чего она вообше нужна?
Кто ее добавляет, компания семантик?

— SATtva (02/03/2015 15:02)   
При загрузке ключа на keyserver.pgp.com, он высылает запросы на все указанные на ключе email-адреса. При подтверждении такого запроса сервер автоматически подписывает данный UID. Причём подтверждение запроса не требует доказательства владения закрытой частью ключа. То есть с криптографической точки зрения эта подпись вообще ни о чём не говорит, т.к. подтвердить такой запрос может кто угодно, имеющий доступ к почтовому ящику или каналу связи, а даже не только владелец ключа.

— Гость (02/03/2015 15:09)   

При загрузке ключа на keyserver.pgp.com, он высылает запросы на все указанные на ключе email-адреса. При подтверждении такого запроса сервер автоматически подписывает данный UID. Причём подтверждение запроса не требует доказательства владения закрытой частью ключа. То есть с криптографической точки зрения эта подпись вообще ни о чём не говорит, т.к. подтвердить такой запрос может кто угодно, имеющий доступ к почтовому ящику или каналу связи, а даже не только владелец ключа.

А для чего компании семантик необходимо проверять емайлы указанные в UIDах ?
Что это дает? Или ничего не дает? Как интерпретировать эту информацию?
И почему у многих на ключах сразу по несколько десятков этих CA57AD7C PGP Global Directory Verification Key

— unknown (02/03/2015 15:18)   

Компания Саймантик заверяет своим ключом, что кто-то умеет перехватывать почту владельца и слать ей подставные ответы.

— SATtva (02/03/2015 15:18)   

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


Принимайте её в том духе, что владелец ключа с некоторой вероятностью имеет доступ к указанному в UID почтовому ящику.


Раньше это подтверждение выдавалось на ограниченный срок (то ли 3, то ли 6 месяцев) и по его окончании сервер повторно пинговал почтовые ящики и продлевал свою подпись. Для продления подписи требуется сгенерировать новую с новым сроком действия, из-за чего пакеты подписей аккумулировались в нездоровом количестве. Видимо, по данной причине эту порочную практику свернули.

— SATtva (02/03/2015 15:18)   

Лолда.

— Гость (02/03/2015 15:24)   

Раньше это подтверждение выдавалось на ограниченный срок (то ли 3, то ли 6 месяцев) и по его окончании сервер повторно пинговал почтовые ящики и продлевал свою подпись. Для продления подписи требуется сгенерировать новую с новым сроком действия, из-за чего пакеты подписей аккумулировались в нездоровом количестве. Видимо, по данной причине эту порочную практику свернули.

А у филла циммерманна аж 2014 годом CA57AD7C PGP Global Directory Verification Key датирован и начиная кажись с 2003 что ли

— SATtva (02/03/2015 15:28)   
Значит, не свернули (где вроде бы проскакивала такая информация).

— Гость (02/03/2015 15:32, исправлен 02/03/2015 15:37)   

https://keyserver.pgp.com/vkd/.....ificationPGPCom.html^[link3]

[moderator]
Оверквотинг, исправлена ссылка. Автору напоминаю о правилах^[link4] сайта, в другой раз пост будет просто удалён.
[/moderator]

— Гость (02/03/2015 15:35)   
Вы имели в виду сразу на главной странице https://keyserver.pgp.com/vkd/GetWelcomeScreen.event внизу

https://keyserver.pgp.com/vkd/.....ificationPGPCom.html^[link3] + https://keyserver.pgp.com/vkd/.....gningKey.event?rep=4^[link5] ???

— Гость (02/03/2015 15:41)   
Да, оно самое

— Гость (02/03/2015 15:42)   
Предлагают ознакомится и загрузить их CA57AD7C PGP Global Directory Verification Key