OpenPGP notations

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

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

Там, правда, notations для подписей, а не UID'ов.

Ёлы-палы, напишите им кто-нибудь, чтобы почитали стандарт. В их случае можно нужно прям домен использовать для указания неймспейса нотации: filename@torproject.org.

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

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

Успешно сгенерил 4096-битный notations и скопипастил его в ключ:
dd if=/dev/urandom bs=1c count=512 | base64 -w0 | xclip ; xclipboard

gpg> showpref [ultimate] (1)* test01 <test@test.com> Cipher: AES256, AES192, AES, CAST5, 3DES Digest: SHA256, SHA1, SHA384, SHA512, SHA224 Compression: ZLIB, BZIP2, ZIP, Uncompressed Features: MDC, Keyserver no-modify Notations: key01@={20150324}{0123456789abcdef} key02@={20150324}{023d41fa07fb4893032afc8e9b106a5bc52e776c8348b97b503dc5fb70a91d6269b64458bc73dc0e8e5f4bc97872aa0ee19807489ff8eb3b46912f7871c5e19c} key03@={20150324}{aoFPwBC7JfBSqPkiDPnP/I+RbdhvmzgqBTQzfCNoy+ghwT8dRNdlGmnyEIETyN9KRYF/lnW3hrzOTmUraHJQMk+XCPFStCGxN+OZB0Kow2xK08vB44zfvJJq+NSDpSde+NTmZ6wYP8/GzAkWsI61DmOiiCIKHoqxjGc5MkrDNL53+WakcfrsawDCy1IMv9S/DNiktJzj81SZ52DRQPn/PmZpdgB+DG+JGN9wMtrMl+gVrFl9ShpeDev1anZNvRlRm08GIbVm2XqzZQunlthFTsSm8Hvy4e4fBIMrjvMCe97n2XuTIyGyLpI1B/j4lpgHYuZoMf4pJObPRx/WVPa1XD/CPtEvoBp/3H+VvwANJclmF36gyStoceXyoj5dQf95z7ZdwOsGBuc9mevrPVX/hQuZLZquHFzOXE0e7Pd/jTV1oRm740UC9UNgVbX8/KNU4dDmUJ2rjsO5Jcxsh8l6UDm23UGaMjertKY51gdRkVMdOw+7lHiLHIpzJ7XvbyWKlzQRhlHAvBsgyCNlMucVUqtxRAiRHR+1h/Ztc1JWsfI2KphKMBVFtfIlmVhd3XdLzdjE2FcwHkS2ZzUbULSenl5v+smwF6n/wtbCNUxadTdh0xUEX8AaUm8CXJOAmPCR9Z8165pUl02VKfJhcLtqTxZVjcDyRJch8d2skAHBk3Y=}

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

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

Наткнулся на сайт 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-ключи чтением им новых нотаций и ничего не бояться.

Я плохо понял тех. детали того, что они делают, и того, что вы предлагаете, но коммент в меру понимания добавил. Если ключ уже и так TorProject'овский, зачем там ещё раз писать @torproject.org? Будет лишь загаживание нотаций дополнительным неинформативным мусором.

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

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

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

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

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

Unknown, а можно в двух словах – как это применять простым смертным? Ну не совсем пошагово, а хотя бы вкратце.
Спасибо

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

А ну это я понял, что не для людей а для парсинга. Просто подумал, что можно, как-то для простых. Как тогда обсуждали про возможные 4кб текста в инфу о ключе пихать – это интересно.

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


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


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


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


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


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

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

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


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


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


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


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


Да, перепутал. Более того, стандарт допускает их даже для отдельных подключей.

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


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

---

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

^* Сейчас специально проверил: можно удалять uid'ы из чужих ключей, приватный для этого не нужен.