В связи с выходом нового стандарта OpenPGP (RFC4880) предлагаю приступить к обсуждению необходимых изменений в следующей версии. Тут возможно обсуждение и сопутствующих сервисов (keyserver и т.д.).
Пусть пользователь "A" хочет получить одно сообщение от пользователя "B",
после чего он уничтожает связку открытый ключ/закрытый ключ PK_A, SK_A. Также он уничтожает расшифрованное сообщение.
Это гарантирует ему защиту от требования выдачи предыдущих ключей и сообщений враждебной стороной. Проблема в том, что одноразовые ключи должны храниться в формате, позволяющем лёгкое уничтожение, что трудно при условие, что вся связка хранится в виде базы в одном общем файле.
Уничтожение ключа должно происходить с запросом разрешения пользователя, который проверит подлинность присланного сообщения по подписи или примет решение о ценности его содержимого. Иначе анонимные отправители израсходуют всю всязку одноразовых публичных подключей.
Предположим, владелец ключа не хочет активно участвовать в создании сети доверия, а его ключ представляет какую-либо серьёзную официальную организацию. Чтобы посторонние люди не могли ставить подписи на этот ключ и снабжать их нежелатльными для владельца комментариями, загромождать посторонними подписывающими ключами и т.д., ключ должен быть или полностью закрыт от проставления подписей или требовать запрос от владельца.
В запросе присылаются все поля, которые подписывающая сторона хочет внести в ключ. Если владелец соглашается, то он подписывает запрос и оптравляет обратно подписывающей стороне. Только при правильной подписи подписывающей стороны и владельца ключа, подписывающий ключ может быть допущен к подписанию.
В противном случае все невалидные поля должны выбраковываться из ключа.
Более того, это не помешает проведению "keysigning party" (за исключением того, что подключи подписывающего ключа не будут отображаться на связке): вместо предъявления таблички с хэшем своего ключа, участники должны будут собрать друг у друга таблички или визитки с запросами (или переписать хэши запросов, а запросы скачать по хэшам с сервера "keysigning party").
Описание атаки: при подписывании кратких сообщений (например: "Я согласен.") на форумах существует проблема несанкционированного переноса этого сообщения на другой форум, что исказит позицию автора.
Предложение: сделать возможность привязки к хэш-значению предыдущего поста (нескольким постам, на случай необходимости удаления рекламы).
Плюсы: возможность проверки последовательности сообщений
Минусы: сложности при модерации
Мини-FAQ
- Я считаю предложение требует значительного изменения.
Если вы уверены, что ваше изменение будет принято остальными, можете изменить само предложение. В противном случае обоснуйте своё мнение в комментариях. При согласии с вашей аргументацией автор предложения или владелец документа внесёт изменения в страницу.
- Я хочу добавить предложение.
Добавьте предложение, согласно шаблону. Желательно указать себя, как ответственного за перенос спорных изменений этого предложения на страницу.
- Предложения будут посланы в официальный список рассылки OpenPGP?
Да.
- Что должно получиться в результате?
Статья с чёткими предложениями и аргументацией по улучшению OpenPGP.
- Почему нельзя это обсуждать в официальном списке рассылки OpenPGP?
Обсуждая будущий стандарт на русском языке, мы расширяем круг участвующих людей и, как следствие, улучшаем качество конечных изменений.
Предложения
тип идентификатора ключа (Serzh[link1])
Предложение: Необходимо ввести тип идентификатора, т.е. получить "расширеный vCard". Типы возможных идентификаторов:
- имя
- фамилия
- отчество
- jabber (и другие, каждый IM как отдельный тип)
- nickname (псевданим)
- номер паспорта
- сайт/пользователь (например: www.pgpru.com/Serzh)
- фото
- логотип
- блог / домашняя страница
- телефон
- день рождения
- адрес
- произвольная строка
- возможность подписать отдельный идентификатор
- легко реализуема автоматическая обработка
- больше отличий между владельцами ключей
связь ключа шифрования с контактом (Serzh[link1])
Предложение: Сделать возможность привязки ключа шифрования к определённым контактам. Например: 1-й ключ используется для шифрования 1-й и 2-й почты, 2-й ключ для шифрования jabber и 3-й почты, 3-й ключ для особо приватных контактов.
Плюсы: гибкость при разделении ключей шифрования.
Минусы: -
Плюсы: гибкость при разделении ключей шифрования.
Минусы: -
публичность идентификатора/ключа (Serzh[link1])
Предложение: каждому идентификатору/ключу добавить условие публичности, т.е. если идентификатор/ключ обозначен как приватный, то keyserver его игнорирует (не импортирует).
Плюсы:
Плюсы:
- добавляет управление количеством опубликованой информации
- крайних пораноиков добавляет в общую сеть доверия, т.к. им можно не публиковать свой самый-самый-самый секретный открытый ключ
управление удалением идентификаторов/ключей (Serzh[link1])
Предложение: в свойствах ключа добавить список хэшей возможных идентификаторов/ключей. Например: мы имеем ключ с двумя идентификаторами ид1 и ид2. В свойствах хранится хэш(ид1) и хэш(ид2). Через некоторое время мы решили оставить только 1-й идентификатор. Следовательно из свойств мы удаляем хэш(ид2), а т.к. дата самоподписи позже, то и остальные сервера его успешно удаляют.
Плюсы:
Плюсы:
- возможность целиком удалять старые идентификаторы (это не отзыв!)
- меньше раздувается объём ключа при замене идентификаторов
Использование одноразовых публичных подключей(unknown[link2])
Пусть пользователь "A" хочет получить одно сообщение от пользователя "B",
после чего он уничтожает связку открытый ключ/закрытый ключ PK_A, SK_A. Также он уничтожает расшифрованное сообщение.
Это гарантирует ему защиту от требования выдачи предыдущих ключей и сообщений враждебной стороной. Проблема в том, что одноразовые ключи должны храниться в формате, позволяющем лёгкое уничтожение, что трудно при условие, что вся связка хранится в виде базы в одном общем файле.
Уничтожение ключа должно происходить с запросом разрешения пользователя, который проверит подлинность присланного сообщения по подписи или примет решение о ценности его содержимого. Иначе анонимные отправители израсходуют всю всязку одноразовых публичных подключей.
- Черновая спецификация расширений PFS для OpenPGP: file:openpgp-pfs.txt[link3]. — SATtva[link4]
Возможность запрета на подпись ключа или разрешение подписи только по запросу(unknown[link2])
Предположим, владелец ключа не хочет активно участвовать в создании сети доверия, а его ключ представляет какую-либо серьёзную официальную организацию. Чтобы посторонние люди не могли ставить подписи на этот ключ и снабжать их нежелатльными для владельца комментариями, загромождать посторонними подписывающими ключами и т.д., ключ должен быть или полностью закрыт от проставления подписей или требовать запрос от владельца.
В запросе присылаются все поля, которые подписывающая сторона хочет внести в ключ. Если владелец соглашается, то он подписывает запрос и оптравляет обратно подписывающей стороне. Только при правильной подписи подписывающей стороны и владельца ключа, подписывающий ключ может быть допущен к подписанию.
В противном случае все невалидные поля должны выбраковываться из ключа.
Более того, это не помешает проведению "keysigning party" (за исключением того, что подключи подписывающего ключа не будут отображаться на связке): вместо предъявления таблички с хэшем своего ключа, участники должны будут собрать друг у друга таблички или визитки с запросами (или переписать хэши запросов, а запросы скачать по хэшам с сервера "keysigning party").
Защита от атаки "Скопировать/Вставить"(Serzh[link1])
Описание атаки: при подписывании кратких сообщений (например: "Я согласен.") на форумах существует проблема несанкционированного переноса этого сообщения на другой форум, что исказит позицию автора.
Предложение: сделать возможность привязки к хэш-значению предыдущего поста (нескольким постам, на случай необходимости удаления рекламы).
Плюсы: возможность проверки последовательности сообщений
Минусы: сложности при модерации
- имхо защита от такой атаки не входит в модель OpenPGP, и ее внесение только излишне усложнит стандарт. Для желающих избежать такой атаки будет достаточно вставлять в каждый пост ссылку на топик к которому он относиться. (ntldr[link5])
- Согласен, это чисто инженерная проблема реализации; сам протокол с такими мелочами связываться не должен.
© 2007 SATtva, ntldr, serzh, unknown
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike[link6]
Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike[link6]
[link2] http://www.pgpru.com/proekt/poljzovateli?profile=unknown
[link3] http://www.pgpru.com/chernowiki/specifikacii/rfc/obsuzhdenienovogostandartaopenpgp/files?get=openpgp-pfs.txt
[link4] http://www.pgpru.com/proekt/poljzovateli?profile=SATtva
[link5] http://www.pgpru.com/proekt/poljzovateli?profile=ntldr
[link6] http://creativecommons.org/licenses/by-sa/3.0/