id: Гость   вход   регистрация
текущее время 13:47 29/03/2024
Автор темы: alerud, тема открыта 31/08/2010 16:14 Печать
Категории: софт, gnupg
http://www.pgpru.com/Форум/РаботаСGnuPG/КакВытащитьОрганизациюВыдавшуюКлюч
создать
просмотр
ссылки

Как вытащить организацию, выдавшую ключ?

Хочу из выдачи gpg вытащить не только пользователя (user), но и выдавшего ключ (issuer)
gpg --no-tty --list-sigs --fixed-list-mode --with-fingerprint --with-colons
Из DETAILS.gz мне это понять не удалось (я новичок в работе с gpg). Посоветуйте, пожалуйста, в каком типе записей (второй uid в ключе? sig?) это искать.


 
На страницу: 1, 2 След.
Комментарии
— falkenberg (23/03/2012 09:33)   профиль/связь   <#>
комментариев: 20   документов: 1   редакций: 12
В целом верно, если не смотреть на развитие стандарта. Сейчас с x509 в этом направлении экспериментируют ребята, что двигают ГРИД. Дополнительные заверитили появились в виде VOMS-расширений (виртуальные организации: virtual organization management service). По мне это похоже на скрещивание x509 с OpenPGP, но им виднее :-/
— Гость (09/04/2012 00:53)   <#>
Но проблема в том, что подписи gpg-ключей сами по себе ничего не удостоверяют кроме факта заверения аутентичности. На подпись к ключу нельзя приклеить никакого обязательства.

И даже это — результат общественного договора о том, как трактовать подпись одного ключа другим, и не более того.

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

Будет ли после этого ситуация идентичная той, что была до подписи ключа, или остаются какие-то следы (в копиях самих публичных ключей на сервере)?

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

Не совсем про то, но может быть интересно решение на уровне ядра:
Verified Executables (or Veriexec) is an in-kernel file integrity subsystem in NetBSD. It allows the user to set digital fingerprints (hashes) of files, and take a number of different actions if files do not match their fingerprints. For example, one can allow Perl to run only scripts that match their fingerprints
Похожий функционал, в расширенном смысле, можно сделать через kauth, недавно украденный адаптированный в т.ч. в Mac OS X.
— unknown (09/04/2012 10:34)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
Будет ли после этого ситуация идентичная той, что была до подписи ключа, или остаются какие-то следы (в копиях самих публичных ключей на сервере)?

Разумеется, с серверов ничего не удаляется и не откатывается обратно. При каждой операции над ключом объём информации только возрастает. На ключ/подключ вешается подпись, которая показывает, что теперь он имеет статус отозванного.
Совсем не про то :) Под Lin тоже что-то такое было, не помню название проекта, жив ли он. Также есть решение по запихиванию управления ключами в ядро, что в прочем не имеет отношения ни к тому, ни к другому.
— Гость (09/04/2012 10:52)   <#>
Разумеется, с серверов ничего не удаляется и не откатывается обратно. При каждой операции над ключом объём информации только возрастает. На ключ/подключ вешается подпись, которая показывает, что теперь он имеет статус отозванного.

Так мы говорим сейчас не про отзыв самого ключа, а про отзыв подписи на некотором ключе. Что, при скачивании такого ключа и выполнении --list-sigs там действительно будет 2 записи: первая о том, что подпись ключом таким-то, и вторая о том, что подпись позже отозвана? Ситуация разве не будет идентичной той, как будто ключ никогда не подписывалcя заданным? [надеюсь, понятно сформулировал вопрос].
— SATtva (09/04/2012 11:00)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Что, при скачивании такого ключа и выполнении --list-sigs там действительно будет 2 записи

Нет, конечно — увидите только, что подпись отозвана. Зато --list-packets покажет и сертифицирующую подпись, и сертификат аннулирования подписи.
— sentaus (09/04/2012 11:00, исправлен 09/04/2012 11:01)   профиль/связь   <#>
комментариев: 1060   документов: 16   редакций: 32
Что, при скачивании такого ключа и выполнении list-sigs там действительно будет 2 записи: первая о том, что подпись ключом таким-то, и вторая о том, что подпись позже отозвана?

Именно так и будет. list-sigs, правда, покажет только одну подпись, помеченную как отозванную, но технически на ключе будут именно две подписи.

— unknown (09/04/2012 11:48)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
С точки зрения протоколов так должно быть по крайней мере. Было бы нехорошо на стороне серверов просто убирать подпись на открытом ключе (делать откат к старой версии), надо предоставить доказательство, что смена статуса ключа санкционирована другой подписью. Вся цепочка действий (транзакций) должна строиться на основе проверяемых заверений и оставаться на самом открытом ключе.

Представим, если бы было не так. Сервер проверил бы отзывающую подпись и сам удалил с ключа лишнее что-ли? Или вы бы поверили тому, что он там напроверял?

Сервер только отдаёт ключ, он не должен ничего с ним делать. Он может только не принимать заведомо некорректные ключи. Вся остальная проверка идёт на стороне клиента, что правильно.

Исключение: кажется были случаи или попытки договориться раз в n лет чистить сервера от очень старых ключей. Реализован отзыв с удалением был только у коммерческого сервера PGP corp.
— Гость (09/04/2012 12:05)   <#>
Представим, если бы было не так. Сервер проверил бы отзывающую подпись и сам удалил с ключа лишнее что-ли? Или вы бы поверили тому, что он там напроверял?
Спасибо. Сейчас всё стало понятно.
На страницу: 1, 2 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3