OpenPGP notations


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


Комментарии
— unknown (19/03/2015 14:32)   
К вопросу о том, почему не нужно помещать дополнительную информацию в UID: OpenPGP User ID Comments considered harmful[link2]. UID не для этого, он не подходит вместо notations.
Гость (19/03/2015 22:26)   

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

Насколько я понял из темы[link1], от которой отпочковалась эта, notations предлагается использовать для машино-читаемых расширений для надстраивания каких-то протоколов поверх OpenPGP. Обычному пользователю возможно даже не придётся ковыряться во всём этом руками.
— gegel (20/03/2015 00:32)   
По первой ссылке в теме:
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)   
Какой-нибудь Усама подпишет ключ gegel'я, и придётся последнему потом оправдываться, что он про Усаму ни слухом, ни духом.


В этом есть и положительный момент: вводится отрицаемость. Если сказанное выше справедливо и общеизвестно, то ведь потом всегда можно сказать, что ни слухом ни духом.
— unknown (20/03/2015 17:17, исправлен 20/03/2015 17:56)   

Удобнее всего 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)   

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



Изменять в автоматическом режиме вряд ли возможно, 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][link8].


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

  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)   

Notations вообще не для людей, всё это для парсинга скриптами.
— unknown (21/03/2015 19:12)   

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


В экспертном режиме так делать можно, а в неэкспертном --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)   

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



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

Гость (23/03/2015 00:10)   

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


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


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


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


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

https://trac.torproject.org/projects/tor/ticket/14187
— sentaus (23/03/2015 01:24)   
Это путает. Почему «key flag» стандарта назван «capability» в GnuPG? А если я перейду на другую реализацию, там будет ещё своя, третья терминология, и свои буквы для её обозначения в выводах?

А буковки для обозначений, кстати, вообще не стандартизированы. Думаю, тут просто была как раз попытка перевести всё на человеческий язык.
Гость (23/03/2015 04:44)   

Там, правда, notations для подписей, а не UID'ов.
— SATtva (23/03/2015 08:09)   

Ёлы-палы, напишите им кто-нибудь, чтобы почитали стандарт. В их случае можно нужно прям домен использовать для указания неймспейса нотации: filename@torproject.org.
— unknown (24/03/2015 12:38, исправлен 24/03/2015 12:45)   

Ещё раз перепроверил /comment90733[link11], там всё дельно и правильно насчёт uid vs. primary. Ошибка была у меня, где-то из-за моей невнимательности.


И ещё раз пока предварительный итог: даже если нет удобного способа неинтерактивного парсинга notations (а тем более добавления), это всё равно мощное и практически применимое средство.


Успешно сгенерил 4096-битный notations и скопипастил его в ключ:



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

Гость (25/03/2015 09:16)   

То, что поведение должно быть именно таким, вытекает из общей логики. Было бы крайне странным, если б это поведение было иным.

Наткнулся на сайт http://www.openpgp-notations.org.

Непонятно, что с отзывом нотаций. Похоже, проще, чем через отзыв UID'а, никак; гугл молчит на этот счёт. Технически нотации меняют вывод showpref, но preferences можно менять сколь угодно много раз, повторно публикуя ключ на серверах ключей. Правда, там есть стандартные фиксированные поля под это, поэтому, я так понимаю, при смене предпочтений старые автоматически отзываются и заменяются новыми. А вот полей с нотациями может быть сколько угодно.

Короче, я всё понял и проверил, всё логично, в общем-то. Как для showpref есть имена Cipher, Compression, так и есть имена key01, key02 и др. Они по смыслу равноправны. Когда вы удаляете нотацию key02, реально генерится серт отзыва на нотацию с именем key02.

А, нет, всё ещё тоньше и изящней. Во-первых, имена тут, как и следовало ожидать, вообще ни о чём. Можете хоть идентичные 10 notations сделать. Не можете, но можете создавать любые, отличающиеся хоть чем-то. К примеру, keyxx@=oneone и keyxx@=oneone2 — две валидные нотации, вешаете их на ключ, всё ОК. Лишь бы хоть чем-то они отличались — этого достаточно. При удалении нотации, судя по всему, делается полный отзыв uid'а и замена его новым uid'ом с новым списком нотаций и предпочтений, просто от пользователя вся эта машинерия скрыта. Короче говоря (проверено), если вы удалили нотацию и получившийся ключ экспортнули куда-то, то больше ничего и не надо. При повторной сборке PGP-ключа GnuPG автоматически определит, что была удалена старая нотация и не будет её показывать.

Мне сначала подумалось, что он помечает отозванной только конкретную нотацию, а не весь UID, но это плохо похоже на правду. Делаем нотацию, потом другую, экспортируем в файл. Потом удаляем одну из нотаций, экспортируем в другой файл. Сносим связку PGP-ключей и создаём её заново (теперь уже без приватного), импортируя первый файл (появляется 2 нотации), потом импортируем второй файл (одна нотация исчезает). Если второй импорт делать с -vvv, то дампу пакетов похоже, что весь UID просто напросто заменяется другим. SATtva мог бы точнее сказать.

Вообще, тема отзыва нотаций ему, наверно, сразу показалась смешной, но он предпочёл не комментировать.

Короче, всё работает, всё классно. Можно загаживать свои PGP-ключи чтением им новых нотаций и ничего не бояться.
Гость (25/03/2015 09:28)   

Я плохо понял тех. детали того, что они делают, и того, что вы предлагаете, но коммент[link12] в меру понимания добавил. Если ключ уже и так TorProject'овский, зачем там ещё раз писать @torproject.org? Будет лишь загаживание нотаций дополнительным неинформативным мусором.
— unknown (25/03/2015 11:02, исправлен 25/03/2015 11:06)   

Они хотят делать другие notations — которые в одну конкретную подпись, а не в висящий на ключе UID.



Генерим 128-килобитные одноразовые OpenSSL-ключи на каждый день на год вперёд, вешаем на OpenPGP-ключ и не боимся АНБ. ☺

— SATtva (25/03/2015 11:49, исправлен 25/03/2015 11:49)   

В отличие от UID, которые совсем не формализованы, нотации скорее ближе к user-defined-пакетам, они должны быть семантически однозначны. Требование к наличию знака @ возникло в стандарте не просто так: то, что идёт после знака, определяет namespace данной нотации, чтобы не получилось коллизии в интерпретации значений.


Допустим, TorProject таки внедрит нотацию вида file@name=x, но что если ещё какой-то олух кто-то независимо от них будет применять нотацию такого же вида, но с иной семантикой? Как вести себя стороннему пользователю, которому попадутся две такие подписи с нотациями одного вида, но несущими разный смысл?



Да нет, однозначного ответа у меня тоже не было. Но вообще выглядит логичным: нотация в данном случае — атрибут UID'а, посему для её изменения/удаления нужно пересоздать UID. Почти то же самое, что с предпочтениями, только они — атрибут ключа, т.е., технически, self-signature данного ключа, поэтому их изменение не затрагивает UID'ы и прочие элементы сертификата.

— ressa (25/03/2015 13:12)   

Unknown, а можно в двух словах – как это применять простым смертным? Ну не совсем пошагово, а хотя бы вкратце.
Спасибо
— unknown (25/03/2015 13:34, исправлен 25/03/2015 13:35)   

То была ирония и гипербола. Простым смертным это не надо. Конкретных сценариев применения ещё не придумано, зато проверено, что идея рабочая.

— ressa (25/03/2015 13:38)   
А ну это я понял, что не для людей а для парсинга. Просто подумал, что можно, как-то для простых. Как тогда обсуждали про возможные 4кб текста в инфу о ключе пихать – это интересно.
Гость (25/03/2015 15:32)   

Например, вместо публикации хэшей в инете, как тут[link13], вешать их в качестве нотаций на свои PGP-ключи.


Это я понял. Вопрос был в тех. деталях, с которыми я не стал вдумчиво разбираться (что именно значат их команды).


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


Именно после, а не до? Там вроде есть какие-то параметры, предопределённые стандартом, которые потенциально могут привести к проблемам, как я понял, но шансы столкнуться с таким вариантом невелики. Т.е. писать --expert если и делать, что хочешь, в нотациях, то сто против одного, что нигде никаких проблем не возникнет и без всяких «@» и «=».


А кто запретит олуху создавать нотации вида file@torproject.org на своём ключе? В любом случае, нотации висят не в воздухе, а прикрепляются к конкретному ключу. Пользователи будут аутентифицировать нотации не по тому, что в них написано, а по тому, к каким ключам они относятся. По-хорошему, конечно, нужен общепринятый стандарт на подписывание имён файлов. Впрочем, по старнике решается так: файл кладётся в архив, а сам архив подписывается; это фиксирует имя файла (а имя архива неважно).


Предпочтения — тоже атрибуты UID'а. Не зря список как предпочтений, так и нотаций выводится через showpref. Предпочтения задаются per uid, если что (вы это, наверно, и без меня знаете). Я не пробовал в лоб это проверять, но мне представляется это так, что при смене предпочтений тоже происходит отзыв UID'а и замена его новым. Ну, или мы друг друга вообще не поняли.
— ressa (25/03/2015 15:42, исправлен 25/03/2015 15:42)   

Так ведь лучше же тогда в аватарку текст в стеганоконтейнере встраивать. Как раз в стандарте GPG и вычитал, что размер 4кб – там текста много влезет. Можно переписку так вести. А так – спасибо за идею, буду иметь в виду.

— SATtva (25/03/2015 15:50)   

Именно после: notation_name@notation_namespace=value.


Во-первых, велики они или нет, но они есть. Во-вторых, в очередной раз повторюсь, неймспейсы нужны не столько для отделения пользовательский нотаций от стандартных, сколько для разделения пользовательских нотаций между собой. Это настолько очевидная штука, что я уже не знаю, какими словами объяснить, чтобы Вам было понятно.


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


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


По-хорошему, нужна глобальная база данных пользовательских нотаций. Насколько помню, Hauke Laging, на сайт которого Вы давали ссылку выше, предлагал эту идею (и под неё же регистрировал домен) после подобных нашему обсуждений в списке рассылки GnuPG.


Да, перепутал. Более того, стандарт допускает их даже для отдельных подключей.
Гость (25/03/2015 15:50)   

Стего ненадёжно.


Unknown уже писал про «неубиваемый twitter». Да, можно. Но размер ключей будет расти очень сильно, т.к. каждый раз новая инфа будет добавляться к старой.



Вообще, если подумать, в этом имеется некая нетривиальность, которую требуется осознать. Можно локально тупо удалить подключ или uid,* а вот нотацию нельзя. Когда вы делаете notation -NOTATION_NAME, нотация не удаляется, а просто создаётся сертификат отзыва на неё. Это плохо и неудобно. Если вы хотите локально поиграться с ключом в плане нотаций, сохраните его чистую копию, иначе потом штатно нотации из ключа будет уже не удалить никак (16-ричный редактор исключаем)... По-хорошему нужны обе операции: и просто удаление и отзыв, но первого в GnuPG нет (исключая вариант удаления всего UID'а целиком и его последующего пересоздания).

* Сейчас специально проверил: можно удалять uid'ы из чужих ключей, приватный для этого не нужен.
Гость (25/03/2015 16:02)   

Одинаковые нотации создать нельзя. Разные нотации отличаются друг от друга своим текстом. Адресовать их можно по полному содержимому нотации. Это наименее ограничивающая модель применения нотаций, поверх которой можно наворачивать что-то своё и специализированное. Я клоню к тому, что разделить нотации между собой можно всегда и из коробки (это если говорить об их содержимом, а не семантике).


Странно звучит. Глобальная база в плане протокола, т.е. договорённостей, что значат в теле нотации те или иные поля (по сути договорённость о протоколе), или именно глобальная база как собрание всех нотаций? Второе меня удивило бы.


Но GnuPG вроде не позволяет делать UID'ы под конкретный подключ, да?
— ressa (25/03/2015 16:04, исправлен 25/03/2015 16:04)   

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


Не читал. Сейчас поищу. Я подразумевал не конкретную переписку, а обмен важной информацией. К примеру информационная рассылка раз в месяц и тд. А размер ключей почему должен расти? Ты же добавил свой шифротекст, который так или иначе весит 4кб-размер_аватарки. Нужен другой текст – в исходник аватарки добавил, подгрузил ее к_указанной_дате и все. Так или иначе – больше 4кб же не влезет.

— SATtva (25/03/2015 16:07)   

Ох, блин... Речь не об одном ключе, а о разных. На одном ключе, да, каждая нотация является уникальной. Но Вы и я можем создать каждый на своём ключе две нотации с одинаковыми именами.


Это. То есть имя нотации с пояснением, какой она несёт смысл.


Нет, и даже в стандарте такого нет. UID'ы и подключи являются сущностями одного ранга, и то, и другое — атрибуты сертификата.
— SATtva (25/03/2015 16:11, исправлен 25/03/2015 16:12)   

Тогда это не стего вообще никаким боком. Возьмите любые произвольные данные, прилепите к ним JPEG-заголовок (и то лишь для того, чтобы gpg не ругался при добавлении такого файла) и добавьте этот файл к ключу.

— unknown (25/03/2015 16:21, исправлен 25/03/2015 16:23)   

Берём первую же попавшуюся индусскую работу[link14] за 2009 год. У индусов явно всё дыряво и показатели завышены, возьмём их за предел сверху. В известную картинку с портретом Лены в 44 килобайта они «доказуемо» незаметно поместили 5 килобайт стегоданных. Я сильно подозреваю, что поскольку зависимость нелинейная, то в 4-килобайтную картинку незаметно даже 4-байт не влезет. Какое стего? Вы о чём? Можно тупо забить картинку рэндомным бинарным мусором, чтобы занять 4 кб, раз уж оно всё равно палится. Так с notations это гораздо проще и удобнее, зачем выдавать это за картинку?



Локально при импорте всё лишнее может и чистится (руками по желанию), но на серверах ключевой материал не может быть удалён. Иначе вы добавите подключ на свой ключ, а сервер его удалит? Нет, сервер может теоретически удалить подключ, но не может с чужого открытого ключа удалить подписи отзыва, означающие «здесь был Вася, подключ, UID, notation, ещё какая-то хрень с таким-то хэшем, больше не пользуйтесь ею, владелец её удалил, никто кроме него это сделать не мог».

— ressa (25/03/2015 16:42, исправлен 25/03/2015 16:42)   

Оппа, спасибо. Не думал, что это может прокатить.


SATtva объяснил, там все гораздо проще. Тогда получается четко 4Кб текст – это все-равно довольно много, всяк больше мизерных notations.


Спасибо, понял. Не нашел я этот «неубиваемый twitter», Гугл только эту тему выдает. Можно ссылочку?

— unknown (25/03/2015 16:54, исправлен 25/03/2015 17:20)   

В /comment90808[link15] я показал пример с 512 байтами (4096 бит), килобайт тоже влезает, можно, наверное и больше, не удивлюсь, если как раз 4096 Кбайт на одну notations. Если на одну — так их на UID можно много повесить. Если лимит на все в пределах UID — так можно несколько UID завести.



Это всё обсуждалось[link16], даже с вами[link17] про ваши изначально не ваши идеи с картинками SATtva[link18] и я вам уже всё объясняли и вы также спорили про стего[link19].

— ressa (25/03/2015 17:25)   

Спасибо. Про картинки – я и не говорил, что моя идея. Помню, что обсуждалось где-то, я тогда и полез гуглить про объем. Сейчас перечитаю ту ветку.
Гость (26/03/2015 06:37)   

[offtop]
Хороший пример того, когда в погоне за краткостью, сестрой таланта, писатель начинает думать, будто по контексту все понимают, что именно он имел в виду, но не сказал. Заменить существительное на местоимение можно только тогда, когда это не приводит к двусмысленности. Я должен был понять, что «их» относится к предпочтениям, а понял так, что к UID'ам. Там использование множественного числа должно было дать подсказку, но, строго говоря, в русском вольно-разговорном языке можно говорить и во множественном в следующих предложениях о том, что изначально было упомянуто в единственном. Ну, и когда это всё размазано по разным постам и страницам, собрать в кучу бывает трудно.

А потом возникает ещё реакция:

Э[link20]то настолько очевидная штука, что я уже не знаю, какими словами объяснить, чтобы Вам было понятно.

К[link21]ак ещё объяснить эту очевидную вещь, я уже не знаю.

Очередной раз вспомнился робот-фортран.jpg[link22] из /comment63409[link23].

Двусмысленность хуже недосказанности, нас за это очень сильно били. Но даже однозначно толкуемые тексты не должны быть сжаты до предела, а должны давать некую дорожную карту для читателя: на чём-то важном ставить акцент, что-то пояснять. Как вы думаете, почему я пишу тут простыни? Потому что изложить ровно то же, но коротко и при этом столь же понятно невозможно.

Буквально на днях мне понадобилось написать страничку article-level-текста. Казалось бы, чего трудного — взять да написать то, что и так знаешь? Тем более, это уже не раз описывал, да и не только на русском. Но когда начинаешь думать над тем, что пишешь, всё получается не так просто, и на одну такую вводную страничку текста нужно 3-4 часа работы. Один абзац пишется час. Средняя скорость — три слова в минуту. Это всё нужно, чтобы потом другие не могли задать 10 вопросов к каждому из написанных слов уровня «что за поток сознания ты тут написал?».

В[link24] процессе написания кандидатской человек обдумывает каждое слово, так как одно неверное движение может привести к переписыванию целых разделов. Да, я не шучу. К концу третьего года обучение написание одной страницы А4 занимает неделю, хотя в блог 3 А4 пишется за час.

[/offtop]

Возвращаясь к вопросу: стандарт разрешает использование предпочтений для конкретных подключей? Так сейчас предпочтения — атрибуты UID'а, как они в принципе могут быть засунуты в подключи, чтобы это не противоречило тому, что есть в GnuPG?


Индусы Индийцы бывают разными[link25], хотя эта статья, вы правы, на первый взгляд не вызывает особого доверия.


Степень нелинейности бывает разной, но если обратиться к индусской арифметике[link26] и считать всё линйным, то получится, что в 4KB можно встроить 4096В*5/44=465 байт. Т.е. вы нелинейностью занизили результат в 100 раз. :)


Теоретически может сделать и то и другое, просто штатно GnuPG поддерживает удаление подключей и UID'ов, а произвольных PGP-пакетов — вроде как нет (в том числе, удаление пакетов, заверяющих отзыв-удаление нотаций). Если сохранилась предыдущая копия ключа, можно новый удалить, а потом сымпортировать старый; если же её нет, то только 16-ричный редактор поможет. Так или иначе, смысл был в том, что по протоколу серверам ключей запрещено удалять что-либо. Если они начнут этим заниматься, они будут считаться злонамеренными.


Вообще, конечно, интересно, какие там пределы. Гигабайтную нотацию можно на ключ повесить, а потом экспортировать его на сервер ключей? Так можно фильмы распространять. ☺
— unknown (26/03/2015 09:40, исправлен 26/03/2015 09:40)   

Эта идея тоже не нова. Где-то была работа, причём опубликованная очень давно, может даже у нас на форуме упоминалась. Суть в том, что инфраструктура серверов открытых ключей принципиально неустойчива против такого DoS'a. Вроде не через notations, но через что-то другое там показывалось как можно распространить mp3-альбом и прочую пиратщину размером несколько десятков мегабайт, запихав это в открытые ключи. Только гиканутость и непопулярность этой среды до сих пор и спасает её от принудительного огораживания с регистрацией выкладывателей ключей по мобильному.

Гость (26/03/2015 10:12)   
А на onion-сайтах JS, счётчики, банеры и реклама уже появились; осталось дождаться регистраций по телефону. А нет, не надо ждать, facebook-адрес на onion же!
— SATtva (26/03/2015 13:17, исправлен 26/03/2015 13:18)   

Да.



Согласно стандарту, предпочтения могут быть субпакетом в пакете self-signature на UID'е или субпакетом в пакете subkey binding signature на подключе:


Since it is found on a self-signature, is possible that a keyholder may have multiple, different preferences. <...> Note that it is also possible for preferences to be in a subkey's binding signature.

Применительно к конкретной реализации, далеко не факт, что это будет работать, даже если Вы приклеите нужный пакет руками.



Не запрещено и не будут, т.к. никакого формального протокола нет, это Вам не Tor Directories. Такое удаление просто напросто бессмысленно, поскольку при следующей синхронизации удалённые данные снова приползут с одного из пиров.

Гость (26/03/2015 17:50)   

А какой в этом смысл? Для UID'а я это понимаю так: это сигнал абоненту о том, что если он хочет написать мне на почту, указанную в UID'е, то пусть использует такие-то предпочтения. С подключом... допустим, аналогично: если хочет зашифровать таким-то момим подключом, пусть использует такие-то предпочтения (на подключи с key flag = S, кстати, какой тогда смысл вешать предпочтения?). Теперь объединяем то и другое вместе и получаем какой-то абсурд: абонент хочет мне написать на некоторый UID, зашифровав определённым моим подключом, но на UID'е висят одни предпочтения, а на подключе другие, и какие тогда выбирать? Как разруливать конфликт? Кстати, я правильно понимаю, что предпочтения могут висеть только на подключе, а на сам главный ключ их повесить нельзя?

Какие-то такие фантазии. Я, наверно, опять всё неправильно понял?
— unknown (26/03/2015 17:58)   

Выбор подключей шифрования реально такой, что его считайте и нет, оно выбирается автоматически, никто рационально согласовывать предпочтения не будет.
Гость (26/03/2015 18:21)   
Мы сейчас говорим о стандарте и том гипотетическом случае, когда всем этим всё-таки пользуются. Как программа определит, какой алгоритм юзать, если указано шифровать подключом 0xXXXXXXXX!, а его предпочтения отличаются от предпочтений выбранного UID'а? Не знаю, можно ли поставить аналогичную проблему для разных UID'ов. Мне казалось, что указание UID'а (особенно в интерактиве) — это всего лишь способ выбрать конкретный главный ключ, но не более того. Какие там будут использоваться подключи — уже сама программа (по умолчанию) решает. Т.е. информация об UID'е как бы теряется, когда выбор уже произведён, нет? И в чём тогда смысл вешать разные предпочтения на разные UID'ы?

Когда не знаешь матчасти крипточасти, приходится сталкиваться с экспоненциальным ростом вопросов, возникающих буквально всюду, с чего бы ни начал разбираться с темой.
Гость (26/03/2015 18:25)   

Не будут, потому что в стандартных реализациях так, но конкретному сервису никто не запрещает перестать синхронизировать с пирами определённые подключи, что-то с них удалять и т.д. Если пользователи заметят, что какой-то конкретный сервер отдаёт не полные ключи, а лишь их огрызки (причём выборочно и осознанно, а не для всех ключей сразу), его по праву будут считать злонамеренным, т.к. уже все привыкли, что полная синхронизация подразумевается по умолчанию.

Ссылки
[link1] https://www.pgpru.com/comment90538

[link2] https://www.debian-administration.org/users/dkg/weblog/97

[link3] https://www.pgpru.com/comment47906

[link4] https://www.pgpru.com/comment70850

[link5] https://www.pgpru.com/comment71170

[link6] https://www.pgpru.com/forum/rabotasgnupg/kommentykpgpkljuchu

[link7] https://www.pgpru.com/biblioteka/statji/analiznadezhnostipgp/formatfajjlovpgp/paketypodpisejj

[link8] https://www.pgpru.com/comment76412

[link9] https://www.pgpru.com/comment90673

[link10] https://www.pgpru.com/comment45493

[link11] https://www.pgpru.com/comment90733

[link12] https://trac.torproject.org/projects/tor/ticket/14187

[link13] https://www.pgpru.com/comment80667

[link14] http://www.cise.ufl.edu/~nemo/tmp/j3_5.pdf

[link15] https://www.pgpru.com/comment90808

[link16] https://www.pgpru.com/comment59234

[link17] https://www.pgpru.com/comment85395

[link18] https://www.pgpru.com/comment85389

[link19] https://www.pgpru.com/comment85402

[link20] https://www.pgpru.com/comment90846

[link21] https://www.pgpru.com/comment71256

[link22] http://s1.hostingkartinok.com/uploads/images/2012/02/229afd9900282be15e8c4c22bd667d76.jpg

[link23] https://www.pgpru.com/comment63409

[link24] http://megamozg.ru/post/4638/

[link25] https://www.pgpru.com/comment81972

[link26] http://pochemuha.ru/v-chyom-sostoit-metod-galery-v-indijskom-umnozhenii