id: Гость   вход   регистрация
текущее время 22:15 17/11/2017
Автор темы: unknown, тема открыта 19/03/2015 12:45 Печать
Категории: софт, gnupg, openpgp, стандарты
создать
просмотр
ссылки

OpenPGP notations


Сабж навеян коментом из другой темы. Делимся историями (не)успеха, примерами применения, подводными камнями в использовании и пр.


 
На страницу: 1, 2, 3, 4 След.
Комментарии
— unknown (19/03/2015 14:32)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664
К вопросу о том, почему не нужно помещать дополнительную информацию в UID: OpenPGP User ID Comments considered harmful. UID не для этого, он не подходит вместо notations.
— Гость (19/03/2015 22:26)   <#>

   Проблема однозначной идентификации не решается указанием имени и почтового ящика хотя бы потому, что ящики время от времени меняются, а некоторые меняют и имена. К тому же, есть разные люди с одинаковыми именами. При последовательной завязке на реальность надо переходить на мировые личные идентификационные номера, которые будут строго уникальными. Чтобы их не подделывать, надо завязаться на совокупность биометрических признаков, и на keysigning party ходить не с паспортами, а с ДНК-секвенсорами ДНК-анализаторами, считывателями отпечатков пальцев и радужной оболочки глаза. Fuzzy hashing может помочь.
   Я предлагаю другое: вместо завязки на ритуализированное PGP лучше следовать взвешенному благоразумию и целесообразности в среднем без опоры на однозначную идентифицируемость по паспорту/биометрии/ещё чему-то. UID'ы засоряют восприятие, поэтому в них стоит писать только то, что коротко, очень важно и очень желательно, чтобы быть увиденным всеми. Про PGP notations мало кто знает, хотя они тут много раз обсуждались [1], [2], [3], [4], [5], поэтому сомневаюсь, что стоит ли туда писать что-то очень информативно-важное.
   Многие условные гуру не хранят отдельно главный секретный ключ, не разбираются в кастомном выставлении capabilities подключей и приоритетов алгоритмов (что важно), а вы тут хотите завязаться на ещё менее известный механизм. Кто его знает и оценит? Один из тысяч, кому почему-то посчастливилось изучить многотонную спецификацию/мануал по протоколу OpenPGP? Я вас уверяю, что 99% регулярных пользователей GnuPG знают лишь 1% того, что написано в man gpg, и почти никто ни разу не прочитывал этот мануал от начала и до конца, поэтому треды «ого, оказывается там вон оно что и есть, и вон как работает, а я даже не знал» появляются каждый год. Я сам большую части дебрей GnuPG не знаю и, честно говоря, изучение этих дебрей у меня имеет невысокий приоритет.
— SATtva (19/03/2015 22:43)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Насколько я понял из темы, от которой отпочковалась эта, notations предлагается использовать для машино-читаемых расширений для надстраивания каких-то протоколов поверх OpenPGP. Обычному пользователю возможно даже не придётся ковыряться во всём этом руками.
— gegel (20/03/2015 00:32)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
По первой ссылке в теме:
Furthermore, since User IDs are atomic, if Jane wants to change the comment field (but leave her name and e-mail address the same), she will instead need to create a new User ID, publish it, get everyone who has certified her old key+userid to certify the key+newuserid, and then revoke the old one.


Верно ли я понял: UserID задается при генерации ключа, и не может быть изменен (добавлен) в этом ключе в дальнейшем?

И тот же вопрос в отношении notations.
— Гость (20/03/2015 01:03)   <#>

И да и нет. UID — PGP-пакет, поэтому в отношении него сохраняются общие правила для всех PGP-пакетов: ранее опубликованный на серверах ключей не может быть удалён, но его значение может быть изменено публикацией нового PGP-пакета на связке.

При генерации ключа нужно указать какой-то UID. Вы можете потом (после генерации, но до выкладки ключей в паблик) навесить на ключ новые UID'ы и удалить старые. Вроде это будет эквивалентно тому, как если бы старых UID'ов не существовало никогда.

После публикации ключа с определённым UID'ом на серверах ключей, этот UID может быть помечен как отозванный, если сгенерировать соответствующую подпись и повторно загрузить ключ на сервера. Может быть, старый UID даже больше не будет показываться по умолчанию, однако, при желании его всё равно любой сможет просмотреть.


Ровно то же самое вроде как.

Кстати, на тему, кажется, notations или чего-то подобного (подписей чужими ключами, может быть?) был пропозал, чтобы запретить их делать, а то любой может их навешивать на ваш ключ без вашего согласия. Какой-нибудь Усама подпишет ключ gegel'я, и придётся последнему потом оправдываться, что он про Усаму ни слухом, ни духом.
— gegel (20/03/2015 09:52)   профиль/связь   <#>
комментариев: 389   документов: 4   редакций: 0
Какой-нибудь Усама подпишет ключ gegel'я, и придётся последнему потом оправдываться, что он про Усаму ни слухом, ни духом.


В этом есть и положительный момент: вводится отрицаемость. Если сказанное выше справедливо и общеизвестно, то ведь потом всегда можно сказать, что ни слухом ни духом.
— unknown (20/03/2015 17:17, исправлен 20/03/2015 17:56)   профиль/связь   <#>
комментариев: 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 — удаляет всё. Они при этом отзываются?
Удалять так:


Setting a value of "none" removes all notations, setting a notation prefixed with a minus sign (-) removes that notation, and setting a notation name (without the =value) prefixed with a minus sign removes all notations with that name.


Или надо отозвать UID и создавать новый, чтобы у всех кореспондентов они аннулировались после обновления?


В принципе, хорошая штука для электронной криптовизитки, в т.ч. и псевдонимной, и содержащей шифртексты, и адреса-ключи для связи. Это почти аналог твиттера на ключах!

— SATtva (20/03/2015 20:17, исправлен 21/03/2015 19:39)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Смотреть — так:



Изменять в автоматическом режиме вряд ли возможно, batch-интерфейс позволяет только генерировать ключи.

— Гость (21/03/2015 00:08)   <#>

Верно, но, в любом случае, это может подтолкнуть следствие в сторону посмотреть на кое-что или проверить кое-что.


-N, --set-notation name=value

Put the name value pair into the signature as notation data. name must consist only of printable characters or spaces, and must contain a '@' character in the form keyname@domain.example.com (substituting the appropriate keyname and domain name, of course). This is to help prevent pollution of the IETF reserved notation namespace. The --expert flag overrides the '@' check. value may be any printable string; it will be encoded in UTF8, so you should check that your --display-charset is set correctly. If you prefix name with an exclamation mark (!), the notation data will be flagged as critical (rfc4880:5.2.3.16). --sig-notation sets a notation for data signatures. --cert-notation sets a notation for key signatures (certifications). --set-notation sets both.

Формат-то, наверно, не зависит от типа 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].


Кстати, логично коррелирует с тем, что сказано выше. Итак, если никаких «@» не используется, то:

  1. Удалить все:
    gpg> notation none
  2. Удалить конкретную:
    gpg> notation -NOTATION_NAME
    где NOTATION_NAME — произвольный, но полный текст этой notation.

На практике это не проверял.


Хороший вопрос. Ответ не знаю.


Как только технология перешагнёт порог популярности, так сразу на софте для серверов ключей появится (если ещё не) софт, препятствующий загрузке ключей с определёнными UID/KeyID.


Сделайте меня развидеть этот ужас, он не для людей. Кстати, не понял, почему вот эти команды не работают:
$ gpg --with-colons --list-options show-sig-subpackets=20 --list-sigs
$ gpg --with-colons --list-options show-sig-subpackets=20 -k
$ gpg --with-colons --list-options show-sig-subpackets=20
$ gpg --with-colons --list-options show-sig-subpackets
Казалось бы, было б логично, если б они работали, разве нет? Это же по сути всего лишь добавление verbosity к выводу.
— SATtva (21/03/2015 10:30)   профиль/связь   <#>
комментариев: 11514   документов: 1035   редакций: 4046

Notations вообще не для людей, всё это для парсинга скриптами.
— unknown (21/03/2015 19:12)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Спасибо, работает.


В экспертном режиме так делать можно, а в неэкспертном --edit-key — нельзя:



Знак "@" конвенционально-обязателен для пользовательских notation's иначе они могут толковаться как notation's стандарта OpenPGP, в т.ч. для свойств ключа. Т.е., так можно что-то нечаянно испортить в ключе или ваш ключ у кого-то неверно прочитается, а с "@" гарантируется нормальная работа.



Вообще-то, primary выбирается только на сеанс, после выхода порядок отображения в ключ не записывается. И это не порядок отображения, а порядок операций над uid'ами. Если использовать uid, не воспользовавшись primary то оно не работает как надо, вот к примеру:



Оно потенциально добавляет не туда и удаляет не оттуда.


Пока не проверял, но даже без отзыва UID можно возле notations ставить даты.


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

Подразумевается что-то типа электронной визитки. С адресами HS.onion, OTR, сертификатами и пр. Или псевдонимный, непривязанный к себе ключ, чтобы для переписки с продвинутыми пользователями м.б. вообще не использовать почту, которая привязана к своему почтовому ящику, а использовать нечто вроде «номерной станции» для уведомлений о новых сообщениях, откуда, что и как скачать. Всё это пихать в notation's в формате JSON.


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


Субпакеты м.б. разные, это надо заглядывать в стандарт. И здесь надо явно указывать, с чего именно выводить субпакеты, чтобы не утонуть в выводе и не подвесить программу.
— Гость (22/03/2015 20:39)   <#>

То же самое можно сказать и про UID'ы? Но там одно ограничение: он не может начинаться с цифры. Чтобы не дразнить стандарт, можно их всегда создавать в виде _@=произвольный_текст. Удалять можно как
gpg> notation -_@=полный текст нотации


Unknown, вы обманываете доверчивых людей:
gpg> uid 3
 
pub  1024R/3192399C  created: 2015-03-22  expires: 2015-03-27  usage: SCE
                     trust: ultimate      validity: ultimate
[ultimate] (1). uidtwo <uidtwo@mail>
[ultimate] (2)  abcdef <abs@xyz>
[ultimate] (3)* uidthree <uidthree@mail>
 
gpg> primary
 
pub  1024R/3192399C  created: 2015-03-22  expires: 2015-03-27  usage: SCE 
                     trust: ultimate      validity: ultimate
[ultimate] (1)  uidtwo <uidtwo@mail>
[ultimate] (2)  abcdef <abs@xyz>
[ultimate] (3)* uidthree <uidthree@mail>
 
gpg> save
 
$ gpg --edit-key 0x3192399C
...
pub  1024R/3192399C  created: 2015-03-22  expires: 2015-03-27  usage: SCE 
                     trust: ultimate      validity: ultimate
[ultimate] (1). uidthree <uidthree@mail>
[ultimate] (2)  uidtwo <uidtwo@mail>
[ultimate] (3)  abcdef <abs@xyz>
 
gpg>
Более того, это способ поставить нужный uid на первое место на всех серверах ключей.


Вот не к примеру. notation none должен по смыслу удалять все notation со всех uid'ов, что он вроде как и делает. Предупреждение про primary здесь чисто общего характера, скорей всего.


А я взял да проверил сейчас, что добавляет оно туда и удаляет именно оттуда, откуда приказано.



Короче, всё работает там, как надо.


А зачем все поля делать номерными, для пафоса что ли? Если где-то используется алгоритм, почему бы не написать имя алгоритма вместо его номера?
— unknown (22/03/2015 22:47, исправлен 22/03/2015 22:49)   профиль/связь   <#>
комментариев: 9796   документов: 488   редакций: 5664

Так, спасибо, учту насчёт primary и перепроверю. Что-то у меня без него не получалось с notations, а результат выбора не сохранялся.



SATtva вам кратко ответил. gpg --edit-key и showpref показывают всё в человеческом виде, чтение напрямую из ком. строки — для парсинга и не для людей. Могут быть и другие номера субпакетов, которые толком нереализованы, а только частично перенесены из стандартов. А мой комент по поводу того, что «для людей» относился не к этому, а именно к управлению notations в самом меню и то, что меню вполне нормальное, особенно если заниматься ключами очень часто. Хотя я и в нём умудрился запутаться с primary.

— Гость (23/03/2015 00:10)   <#>

Я не замечал косяков. Учтите, что showpref показывает вывод только для выбранного UID'а, если какой-то из них выбран, и для всех UID'ов, если не выбран ни один из них.


Стандарт мог бы сразу фиксировать и номера и буквы. Это уменьшит свободу реализаций, конечно, но уже одно то, что одни и те же вещи в стандарте и в GnuPG называются по-разному, я считаю ненормальным. Это путает. Почему «key flag» стандарта назван «capability» в GnuPG? А если я перейду на другую реализацию, там будет ещё своя, третья терминология, и свои буквы для её обозначения в выводах?


Учтитывайте всегда вариант «в конкретно моей версии софта есть неисправленная ошибка».
— sentaus (23/03/2015 01:17)   профиль/связь   <#>
комментариев: 1058   документов: 16   редакций: 32
Насколько я понял из темы, от которой отпочковалась эта, notations предлагается использовать для машино-читаемых расширений для надстраивания каких-то протоколов поверх OpenPGP. Обычному пользователю возможно даже не придётся ковыряться во всём этом руками.


Notations вообще не для людей, всё это для парсинга скриптами.


Вот, кстати, ещё пример из жизни, как это всё хотят использовать.

https://trac.torproject.org/projects/tor/ticket/14187
На страницу: 1, 2, 3, 4 След.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3