РегистрацияВ связи с выходом нового стандарта OpenPGP (RFC4880) предлагаю приступить к обсуждению необходимых изменений в следующей версии. Тут возможно обсуждение и сопутствующих сервисов (keyserver и т.д.).
Мини-FAQ
- Я считаю предложение требует значительного изменения.
- Я хочу добавить предложение.
- Предложения будут посланы в официальный список рассылки OpenPGP?
- Что должно получиться в результате?
- Почему нельзя это обсуждать в официальном списке рассылки OpenPGP?
Предложения
тип идентификатора ключа (Serzh)
- имя
- фамилия
- отчество
- jabber (и другие, каждый IM как отдельный тип)
- nickname (псевданим)
- номер паспорта
- сайт/пользователь (например: www.pgpru.com/Serzh)
- фото
- логотип
- блог / домашняя страница
- телефон
- день рождения
- адрес
- произвольная строка
Плюсы:
- возможность подписать отдельный идентификатор
- легко реализуема автоматическая обработка
- больше отличий между владельцами ключей
Минусы: -
связь ключа шифрования с контактом (Serzh)
Плюсы: гибкость при разделении ключей шифрования.
Минусы: -
публичность идентификатора/ключа (Serzh)
Плюсы:
- добавляет управление количеством опубликованой информации
- крайних пораноиков добавляет в общую сеть доверия, т.к. им можно не публиковать свой самый-самый-самый секретный открытый ключ
Минусы: -
управление удалением идентификаторов/ключей (Serzh)
Плюсы:
- возможность целиком удалять старые идентификаторы (это не отзыв!)
- меньше раздувается объём ключа при замене идентификаторов
Использование одноразовых публичных подключей(unknown)
Пусть пользователь "A" хочет получить одно сообщение от пользователя "B",
после чего он уничтожает связку открытый ключ/закрытый ключ PK_A, SK_A. Также он уничтожает расшифрованное сообщение.
Это гарантирует ему защиту от требования выдачи предыдущих ключей и сообщений враждебной стороной. Проблема в том, что одноразовые ключи должны храниться в формате, позволяющем лёгкое уничтожение, что трудно при условие, что вся связка хранится в виде базы в одном общем файле.
Уничтожение ключа должно происходить с запросом разрешения пользователя, который проверит подлинность присланного сообщения по подписи или примет решение о ценности его содержимого. Иначе анонимные отправители израсходуют всю всязку одноразовых публичных подключей.
- Черновая спецификация расширений PFS для OpenPGP:
file:openpgp-pfs.txt. — SATtva
Возможность запрета на подпись ключа или разрешение подписи только по запросу(unknown)
Предположим, владелец ключа не хочет активно участвовать в создании сети доверия, а его ключ представляет какую-либо серьёзную официальную организацию. Чтобы посторонние люди не могли ставить подписи на этот ключ и снабжать их нежелатльными для владельца комментариями, загромождать посторонними подписывающими ключами и т.д., ключ должен быть или полностью закрыт от проставления подписей или требовать запрос от владельца.
В запросе присылаются все поля, которые подписывающая сторона хочет внести в ключ. Если владелец соглашается, то он подписывает запрос и оптравляет обратно подписывающей стороне. Только при правильной подписи подписывающей стороны и владельца ключа, подписывающий ключ может быть допущен к подписанию.
В противном случае все невалидные поля должны выбраковываться из ключа.
Более того, это не помешает проведению "keysigning party" (за исключением того, что подключи подписывающего ключа не будут отображаться на связке): вместо предъявления таблички с хэшем своего ключа, участники должны будут собрать друг у друга таблички или визитки с запросами (или переписать хэши запросов, а запросы скачать по хэшам с сервера "keysigning party").
Защита от атаки "Скопировать/Вставить"(Serzh)
Описание атаки: при подписывании кратких сообщений (например: "Я согласен.") на форумах существует проблема несанкционированного переноса этого сообщения на другой форум, что исказит позицию автора.
Предложение: сделать возможность привязки к хэш-значению предыдущего поста (нескольким постам, на случай необходимости удаления рекламы).
Плюсы: возможность проверки последовательности сообщений
Минусы: сложности при модерации
- имхо защита от такой атаки не входит в модель OpenPGP, и ее внесение только излишне усложнит стандарт. Для желающих избежать такой атаки будет достаточно вставлять в каждый пост ссылку на топик к которому он относиться. (ntldr)
- Согласен, это чисто инженерная проблема реализации; сам протокол с такими мелочами связываться не должен.
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
