OpenPGP notations
Сабж навеян коментом из другой темы. Делимся историями (не)успеха, примерами применения, подводными камнями в использовании и пр.
|
||||||||||||||||||||||||
|
||||||||||||||||||||||||
Нормы пользования. Некоторые права на материалы сайта защищены по условиям лицензии CreativeCommons. Движок
openSpace 0.8.25a и дизайн сайта © 2006-2007 Vlad "SATtva" Miller.
|
||||||||||||||||||||||||
комментариев: 9796 документов: 488 редакций: 5664
Проблема однозначной идентификации не решается указанием имени и почтового ящика хотя бы потому, что ящики время от времени меняются, а некоторые меняют и имена. К тому же, есть разные люди с одинаковыми именами. При последовательной завязке на реальность надо переходить на мировые личные идентификационные номера, которые будут строго уникальными. Чтобы их не подделывать, надо завязаться на совокупность биометрических признаков, и на keysigning party ходить не с паспортами, а с
ДНК-секвенсорамиДНК-анализаторами, считывателями отпечатков пальцев и радужной оболочки глаза. Fuzzy hashing может помочь.Я предлагаю другое: вместо завязки на ритуализированное PGP лучше следовать взвешенному благоразумию и целесообразности в среднем без опоры на однозначную идентифицируемость по паспорту/биометрии/ещё чему-то. UID'ы засоряют восприятие, поэтому в них стоит писать только то, что коротко, очень важно и очень желательно, чтобы быть увиденным всеми. Про PGP notations мало кто знает, хотя они тут много раз обсуждались [1], [2], [3], [4], [5], поэтому сомневаюсь, что стоит ли туда писать что-то очень информативно-важное.
Многие условные гуру не хранят отдельно главный секретный ключ, не разбираются в кастомном выставлении capabilities подключей и приоритетов алгоритмов (что важно), а вы тут хотите завязаться на ещё менее известный механизм. Кто его знает и оценит? Один из тысяч, кому почему-то посчастливилось изучить многотонную спецификацию/мануал по протоколу OpenPGP? Я вас уверяю, что 99% регулярных пользователей GnuPG знают лишь 1% того, что написано в man gpg, и почти никто ни разу не прочитывал этот мануал от начала и до конца, поэтому треды «ого, оказывается там вон оно что и есть, и вон как работает, а я даже не знал» появляются каждый год. Я сам большую части дебрей GnuPG не знаю и, честно говоря, изучение этих дебрей у меня имеет невысокий приоритет.
комментариев: 11558 документов: 1036 редакций: 4118
Насколько я понял из темы, от которой отпочковалась эта, notations предлагается использовать для машино-читаемых расширений для надстраивания каких-то протоколов поверх OpenPGP. Обычному пользователю возможно даже не придётся ковыряться во всём этом руками.
комментариев: 393 документов: 4 редакций: 0
Верно ли я понял: UserID задается при генерации ключа, и не может быть изменен (добавлен) в этом ключе в дальнейшем?
И тот же вопрос в отношении notations.
И да и нет. UID — PGP-пакет, поэтому в отношении него сохраняются общие правила для всех PGP-пакетов: ранее опубликованный на серверах ключей не может быть удалён, но его значение может быть изменено публикацией нового PGP-пакета на связке.
При генерации ключа нужно указать какой-то UID. Вы можете потом (после генерации, но до выкладки ключей в паблик) навесить на ключ новые UID'ы и удалить старые. Вроде это будет эквивалентно тому, как если бы старых UID'ов не существовало никогда.
После публикации ключа с определённым UID'ом на серверах ключей, этот UID может быть помечен как отозванный, если сгенерировать соответствующую подпись и повторно загрузить ключ на сервера. Может быть, старый UID даже больше не будет показываться по умолчанию, однако, при желании его всё равно любой сможет просмотреть.
Ровно то же самое вроде как.
Кстати, на тему, кажется, notations или чего-то подобного (подписей чужими ключами, может быть?) был пропозал, чтобы запретить их делать, а то любой может их навешивать на ваш ключ без вашего согласия.
Какой-нибудь Усама подпишет ключ gegel'я, и придётся последнему потом оправдываться, что он про Усаму ни слухом, ни духом.комментариев: 393 документов: 4 редакций: 0
В этом есть и положительный момент: вводится отрицаемость. Если сказанное выше справедливо и общеизвестно, то ведь потом всегда можно сказать, что ни слухом ни духом.
комментариев: 9796 документов: 488 редакций: 5664
Удобнее всего notations на UID'ах. Тогда:
Добавим uid:
Сделаем второй UID как primary:
Добавим notations к этому UID'у, знак @ — обязателен:
Добавим ещё один:
Теперь набираем showpref и любуемся на результат:
Если через primary отключить "2" и снова глянуть showpref, то видно, что notations только на втором UID. Если бы primary не было выбрано, то после соответствующего подтверждения одинаковые notations записались бы в pref обоих UID.
Сохраним и выйдём через save.
Как бы это всё читать (в смысле смотреть) для открытых и записывать для закрытых ключей из ком.строки, не заходя в edit-key с блужданиями по меню?
Всякие set-notations, show-notations — это другое, это для заметок в подписях (тоже интересная тема, но пока не о ней), cert-notations — тоже не совсем то. Как конкретно читать/записывать notations из/в UID?
Как выводить по имени вида "key01", чтобы не парсить весь вывод?
Как удалять их из UID закрытого ключа по имени, т.к. notations none — удаляет всё. Они при этом отзываются?Удалять так:
Или надо отозвать UID и создавать новый, чтобы у всех кореспондентов они аннулировались после обновления?
В принципе, хорошая штука для электронной криптовизитки, в т.ч. и псевдонимной, и содержащей шифртексты, и адреса-ключи для связи. Это почти аналог твиттера на ключах!
комментариев: 11558 документов: 1036 редакций: 4118
Смотреть — так:
Изменять в автоматическом режиме вряд ли возможно, batch-интерфейс позволяет только генерировать ключи.
Верно, но, в любом случае, это может подтолкнуть следствие в сторону посмотреть на кое-что или проверить кое-что.
Формат-то, наверно, не зависит от типа notations? Вы пробовали с --expert?
Хотел уже спросить, каков формат этих notations, но, судя по man, «@» обязателен не более, чем в UID'ах (там при генерации ключа тоже надо указать что-то со знаком «@», но потом можно первый UID удалить, вместо него создав новый без всяких «@»).
Правда, если notations создаётся без знака «@», то как его адресовать при удалении? Указывать целиком, а перед ним ставить минус? (частичный ответ ниже)И, вообще, какие ограничения на эти notations? Допустимы ли там любые символы, и какой длины? Можно ли так туда запихнуть текст? Какое ограничение будет на его размер?Бердово звучит. При чём тут primary к notations? А что, не на UID, который не primary, нельзя повесить notation? Это же, казалось бы, независимые вещи: какой UID считать главным (показываемым первым на связке) и на какой UID навесить notations. Поидее должно работать так: uid 2 (выбрали второй uid), потом выполняете notation, и он должен будет его повесить только на uid=2. Кстати, showpref и setpref — команды per uid, насколько я помню. Если меняете приоритеты алгоритмов, то нужно поочерёдно выбрать каждый из uid'ов и каждому дать команду setpref.
В GnuPG много чего не делается из космстроки никак, к сожалению [1].
Кстати, логично коррелирует с тем, что сказано выше. Итак, если никаких «@» не используется, то:
На практике это не проверял.
Хороший вопрос. Ответ не знаю.
Как только технология перешагнёт порог популярности, так сразу на софте для серверов ключей появится (если ещё не) софт, препятствующий загрузке ключей с определёнными UID/KeyID.
Сделайте меня развидеть этот ужас, он не для людей. Кстати, не понял, почему вот эти команды не работают:
комментариев: 11558 документов: 1036 редакций: 4118
Notations вообще не для людей, всё это для парсинга скриптами.
комментариев: 9796 документов: 488 редакций: 5664
Спасибо, работает.
В экспертном режиме так делать можно, а в неэкспертном --edit-key — нельзя:
Знак "@" конвенционально-обязателен для пользовательских notation's иначе они могут толковаться как notation's стандарта OpenPGP, в т.ч. для свойств ключа. Т.е., так можно что-то нечаянно испортить в ключе или ваш ключ у кого-то неверно прочитается, а с "@" гарантируется нормальная работа.
Вообще-то, primary выбирается только на сеанс, после выхода порядок отображения в ключ не записывается. И это не порядок отображения, а порядок операций над uid'ами. Если использовать uid, не воспользовавшись primary то оно не работает как надо, вот к примеру:
Оно потенциально добавляет не туда и удаляет не оттуда.
Пока не проверял, но даже без отзыва UID можно возле notations ставить даты.
Не надо сильно злоупотреблять. Естественно, мегабайтные ключи начнут резать, когда приспичит.
Подразумевается что-то типа электронной визитки. С адресами HS.onion, OTR, сертификатами и пр. Или псевдонимный, непривязанный к себе ключ, чтобы для переписки с продвинутыми пользователями м.б. вообще не использовать почту, которая привязана к своему почтовому ящику, а использовать нечто вроде «номерной станции» для уведомлений о новых сообщениях, откуда, что и как скачать. Всё это пихать в notation's в формате JSON.
Когда что-то новое делаешь в GnuPG первое впечатление именно такое. Когда это повторяешь несколько десятков раз, то понимаешь, что для профессионального использования удобнее именно так. И хоть бы они не пошли на поводу и не переделали для людей.
Субпакеты м.б. разные, это надо заглядывать в стандарт. И здесь надо явно указывать, с чего именно выводить субпакеты, чтобы не утонуть в выводе и не подвесить программу.
То же самое можно сказать и про UID'ы? Но там одно ограничение: он не может начинаться с цифры. Чтобы не дразнить стандарт, можно их всегда создавать в виде _@=произвольный_текст. Удалять можно как
Unknown, вы обманываете доверчивых людей:
Вот не к примеру. notation none должен по смыслу удалять все notation со всех uid'ов, что он вроде как и делает. Предупреждение про primary здесь чисто общего характера, скорей всего.
А я взял да проверил сейчас, что добавляет оно туда и удаляет именно оттуда, откуда приказано.
Короче, всё работает там, как надо.
А зачем все поля делать номерными, для пафоса что ли? Если где-то используется алгоритм, почему бы не написать имя алгоритма вместо его номера?
комментариев: 9796 документов: 488 редакций: 5664
Так, спасибо, учту насчёт primary и перепроверю. Что-то у меня без него не получалось с notations, а результат выбора не сохранялся.
SATtva вам кратко ответил. gpg --edit-key и showpref показывают всё в человеческом виде, чтение напрямую из ком. строки — для парсинга и не для людей. Могут быть и другие номера субпакетов, которые толком нереализованы, а только частично перенесены из стандартов. А мой комент по поводу того, что «для людей» относился не к этому, а именно к управлению notations в самом меню и то, что меню вполне нормальное, особенно если заниматься ключами очень часто. Хотя я и в нём умудрился запутаться с primary.
Я не замечал косяков. Учтите, что showpref показывает вывод только для выбранного UID'а, если какой-то из них выбран, и для всех UID'ов, если не выбран ни один из них.
Стандарт мог бы сразу фиксировать и номера и буквы. Это уменьшит свободу реализаций, конечно, но уже одно то, что одни и те же вещи в стандарте и в GnuPG называются по-разному, я считаю ненормальным. Это путает. Почему «key flag» стандарта назван «capability» в GnuPG? А если я перейду на другую реализацию, там будет ещё своя, третья терминология, и свои буквы для её обозначения в выводах?
Учтитывайте всегда вариант «в конкретно моей версии софта есть неисправленная ошибка».
комментариев: 1060 документов: 16 редакций: 32
Вот, кстати, ещё пример из жизни, как это всё хотят использовать.
https://trac.torproject.org/projects/tor/ticket/14187