Как вытащить организацию, выдавшую ключ?
Хочу из выдачи gpg вытащить не только пользователя (user), но и выдавшего ключ (issuer)gpg --no-tty --list-sigs --fixed-list-mode --with-fingerprint --with-colons
Из DETAILS.gz мне это понять не удалось (я новичок в работе с gpg). Посоветуйте, пожалуйста, в каком типе записей (второй uid в ключе? sig?) это искать.
Вы не путаете OpenPGP с X.509? Или забыли нам что-то сказать (например, что используете gpg2 и пытаете им сертификат X.509)?
Не совсем забыл. :)
Одно из моих заданий – добавить в систему возможность указания своего публичного ключа и отображение информации из этого ключа. На сервере установлен gpg. Заказчик указал, какую именно информацию из ключа надо отображать. Всё, кроме одного поля, понятно откуда брать. А вот откуда брать выдавшего ключ, пока не пойму.
Вы хотите намекнуть, что это поле только в X.509?
Прямо вот на это и намекаю.
И искать это поле в выдаче gpg 1.4.6 бесполезно?
Ну нет концепции issuer в OpenPGP, что Вы там будете искать? В X.509 PKI как бы подразумевается, что самоподписанным сертификатом можно подтереться, поэтому он якобы "издаётся" некоей третьей стороной (хотя всё это чушь на самом деле).
а второй GPG хоть как-то эти сертификаты обрабатывает? Судя по DETAILS.gz там в выдаче есть crt и crs записи...
1.4.5 не обрабатывает, насколько я понял
Так Вам что надо, X.509 или OpenPGP? Или заказчику плевать, лишь бы issuer был?
Заказчику надо PGP, но он отличается крайней лаконичностью. Увы.
Буду пытаться выяснить, что он хочет.
[offtop]
Наверное, я один, кто прочитав название топика в "последних комментах" решил что речь идёт о "вытаскивании" (коммерческой) организации, по глупости слившей ключ органам от компрометирующих данных (типа юридическая помощь и что можно в таких случаях сделать). Да, у меня параноя.
[/offtop]
Кажется я вопрос понял. И у меня есть схожий. Как из подписи проверить что ключ подписавшего был подписан таким-то ключом. Скажем, его фингерпринт имеется. Это позволило бы проверить имеет ли подписавший право подписывать что-либо, скажем код для исполнения. Например у нас есть мастерключ, созданный для того, чтобы раздавать эту привелегию. Если им подписан чей-либо ключ, то владелец этого ключа имеет право подписывать им свои программы для их запуска на каком-либо ресурсе. Ну это пример. Как подобную штуку реализовать с помощью gpg? Это помогло бы с помощью gpg не только проверить подлинность подписи, но и выполнить авторизацию на основе роли.
Есть идейка, правда кривая. Для осуществления проверки на роль надо иметь в pubring-е всего один доверенный ключ, соответствующий выбранной роли. Если попись проходит проверку, то значит владелец ключа получил подпись "ролераздавателя", если же нет – значит нет. Минус такой схемы в том что для каждой роли нужен свой pubring, что не всегда гут
По подписи можно узнать практически только отпечаток ключа. По отпечатку ключа можно получить обновлённую версию открытого ключа с сервера публичных ключей (общедоступного или корпоративного) и добавить его на свою связку с открытыми ключами. Дальше можно посмотреть, какими ключами подписан ключ.
Но проблема в том, что подписи gpg-ключей сами по себе ничего не удостоверяют кроме факта заверения аутентичности. На подпись к ключу нельзя приклеить никакого обязательства. Не могу сходу сказать, есть ли какой-либо механизм отзыва подписи на ключе, кроме как отозвать сам подписывавший ключ (что неудобно).
Можно действительно завести специальный ключ, в котором в UID или в комментариях прописать, "это ключ для заверения филиалов банка", "это ключ для заверения ключей участников проекта OpenPGP" и т.д. и использовать его только для этой цели.
Для отзыва завести второй ключ (здесь есть потенциально ненадёжный, уязвимый момент). Если это именно то, что вам нужно, тогда это отчасти решение.
Для закрытой инфраструктуры с иерархией традиционно создавалось не (Open)PGP, а SMIME, подписи на сертификатах. Вся инфраструктура таких центров сертификации может опираться на внутрикорпоративное решение (даже без необходимости использования коммерческих сертификатов).
Заверитель может отозвать свою подпись. В GnuPG делается через --edit-key и revsig.
Почему не существует? Кажется вполне себе существует: отзываешь свою подпись, потом отправляешь на кейсервер, откуда отзыв распространяется дальше.
Насчет спецключа – именно это я и говорил. Кажется именно так подписывают пакеты во всяческих линуксах чтобы точно знать что они не поддельные. Однако способ с отдельным кейрингом на каждый такой спецключ не вполне элегантен: а что, если таких спецключей несколько? На каждый свой кейринг с доверенным спецключом для проверки? Может есть какой более правильный способ?
Насчет SMIME. А можно в архитектуре x509 иметь более чем 1 CA? один – для заверки аутентичности ключа, а другой – для индикации его принадлежности к той или иной группе? Если можно, то как это сделать в OpenSSL?
В смысле, больше одного заверителя у ключа? Нельзя. В этом принципиальное отличие от OpenPGP.
В целом верно, если не смотреть на развитие стандарта. Сейчас с x509 в этом направлении экспериментируют ребята, что двигают ГРИД. Дополнительные заверитили появились в виде VOMS-расширений (виртуальные организации: virtual organization management service). По мне это похоже на скрещивание x509 с OpenPGP, но им виднее :-/
И даже это — результат общественного договора о том, как трактовать подпись одного ключа другим, и не более того.
Будет ли после этого ситуация идентичная той, что была до подписи ключа, или остаются какие-то следы (в копиях самих публичных ключей на сервере)?
Не совсем про то, но может быть интересно решение на уровне ядра:Похожий функционал, в расширенном смысле, можно сделать через kauth[link2], недавно
украденныйадаптированный[link3] в т.ч. в Mac OS X.Разумеется, с серверов ничего не удаляется и не откатывается обратно. При каждой операции над ключом объём информации только возрастает. На ключ/подключ вешается подпись, которая показывает, что теперь он имеет статус отозванного.
Совсем не про то :) Под Lin тоже что-то такое было, не помню название проекта, жив ли он. Также есть решение по запихиванию управления ключами в ядро, что в прочем не имеет отношения ни к тому, ни к другому.
Так мы говорим сейчас не про отзыв самого ключа, а про отзыв подписи на некотором ключе. Что, при скачивании такого ключа и выполнении --list-sigs там действительно будет 2 записи: первая о том, что подпись ключом таким-то, и вторая о том, что подпись позже отозвана? Ситуация разве не будет идентичной той, как будто ключ никогда не подписывалcя заданным? [надеюсь, понятно сформулировал вопрос].
Нет, конечно — увидите только, что подпись отозвана. Зато --list-packets покажет и сертифицирующую подпись, и сертификат аннулирования подписи.
Именно так и будет. list-sigs, правда, покажет только одну подпись, помеченную как отозванную, но технически на ключе будут именно две подписи.
С точки зрения протоколов так должно быть по крайней мере. Было бы нехорошо на стороне серверов просто убирать подпись на открытом ключе (делать откат к старой версии), надо предоставить доказательство, что смена статуса ключа санкционирована другой подписью. Вся цепочка действий (транзакций) должна строиться на основе проверяемых заверений и оставаться на самом открытом ключе.
Представим, если бы было не так. Сервер проверил бы отзывающую подпись и сам удалил с ключа лишнее что-ли? Или вы бы поверили тому, что он там напроверял?
Сервер только отдаёт ключ, он не должен ничего с ним делать. Он может только не принимать заведомо некорректные ключи. Вся остальная проверка идёт на стороне клиента, что правильно.
Исключение: кажется были случаи или попытки договориться раз в n лет чистить сервера от очень старых ключей. Реализован отзыв с удалением был только у коммерческого сервера PGP corp.
Спасибо. Сейчас всё стало понятно.