id: Гость   вход   регистрация
текущее время 06:55 20/11/2017
Владелец: serzh (создано 23/11/2007 01:09), редакция от 30/12/2007 10:30 (автор: SATtva) Печать
Категории: криптография, openpgp, спецификации, сайт проекта, wiki, стандарты, разное, сообщество
http://www.pgpru.com/Черновики/Спецификации/RFC/ОбсуждениеНовогоСтандартаOpenPGP
создать
просмотр
редакции
ссылки

В связи с выходом нового стандарта OpenPGP (RFC4880) предлагаю приступить к обсуждению необходимых изменений в следующей версии. Тут возможно обсуждение и сопутствующих сервисов (keyserver и т.д.).


Оглавление документа:

Мини-FAQ


  • Я считаю предложение требует значительного изменения.
Если вы уверены, что ваше изменение будет принято остальными, можете изменить само предложение. В противном случае обоснуйте своё мнение в комментариях. При согласии с вашей аргументацией автор предложения или владелец документа внесёт изменения в страницу.

  • Я хочу добавить предложение.
Добавьте предложение, согласно шаблону. Желательно указать себя, как ответственного за перенос спорных изменений этого предложения на страницу.

  • Предложения будут посланы в официальный список рассылки OpenPGP?
Да.

  • Что должно получиться в результате?
Статья с чёткими предложениями и аргументацией по улучшению OpenPGP.

  • Почему нельзя это обсуждать в официальном списке рассылки OpenPGP?
Обсуждая будущий стандарт на русском языке, мы расширяем круг участвующих людей и, как следствие, улучшаем качество конечных изменений.

Предложения

тип идентификатора ключа (Serzh)

Предложение: Необходимо ввести тип идентификатора, т.е. получить "расширеный vCard". Типы возможных идентификаторов:
  1. имя
  2. фамилия
  3. отчество
  4. e-mail
  5. jabber (и другие, каждый IM как отдельный тип)
  6. nickname (псевданим)
  7. номер паспорта
  8. сайт/пользователь (например: www.pgpru.com/Serzh)
  9. фото
  10. логотип
  11. блог / домашняя страница
  12. телефон
  13. день рождения
  14. адрес
  15. произвольная строка

Плюсы:

  1. возможность подписать отдельный идентификатор
  2. легко реализуема автоматическая обработка
  3. больше отличий между владельцами ключей

Минусы: -

связь ключа шифрования с контактом (Serzh)

Предложение: Сделать возможность привязки ключа шифрования к определённым контактам. Например: 1-й ключ используется для шифрования 1-й и 2-й почты, 2-й ключ для шифрования jabber и 3-й почты, 3-й ключ для особо приватных контактов.
Плюсы: гибкость при разделении ключей шифрования.
Минусы: -

публичность идентификатора/ключа (Serzh)

Предложение: каждому идентификатору/ключу добавить условие публичности, т.е. если идентификатор/ключ обозначен как приватный, то keyserver его игнорирует (не импортирует).
Плюсы:

  1. добавляет управление количеством опубликованой информации
  2. крайних пораноиков добавляет в общую сеть доверия, т.к. им можно не публиковать свой самый-самый-самый секретный открытый ключ

Минусы: -

управление удалением идентификаторов/ключей (Serzh)

Предложение: в свойствах ключа добавить список хэшей возможных идентификаторов/ключей. Например: мы имеем ключ с двумя идентификаторами ид1 и ид2. В свойствах хранится хэш(ид1) и хэш(ид2). Через некоторое время мы решили оставить только 1-й идентификатор. Следовательно из свойств мы удаляем хэш(ид2), а т.к. дата самоподписи позже, то и остальные сервера его успешно удаляют.
Плюсы:

  1. возможность целиком удалять старые идентификаторы (это не отзыв!)
  2. меньше раздувается объём ключа при замене идентификаторов
Минусы: избыток информации на ключе (хранение хэшей идентификаторов)

Использование одноразовых публичных подключей(unknown)


Пусть пользователь "A" хочет получить одно сообщение от пользователя "B",
после чего он уничтожает связку открытый ключ/закрытый ключ PK_A, SK_A. Также он уничтожает расшифрованное сообщение.
Это гарантирует ему защиту от требования выдачи предыдущих ключей и сообщений враждебной стороной. Проблема в том, что одноразовые ключи должны храниться в формате, позволяющем лёгкое уничтожение, что трудно при условие, что вся связка хранится в виде базы в одном общем файле.


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


Возможность запрета на подпись ключа или разрешение подписи только по запросу(unknown)


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


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


В противном случае все невалидные поля должны выбраковываться из ключа.


Более того, это не помешает проведению "keysigning party" (за исключением того, что подключи подписывающего ключа не будут отображаться на связке): вместо предъявления таблички с хэшем своего ключа, участники должны будут собрать друг у друга таблички или визитки с запросами (или переписать хэши запросов, а запросы скачать по хэшам с сервера "keysigning party").

Защита от атаки "Скопировать/Вставить"(Serzh)


Описание атаки: при подписывании кратких сообщений (например: "Я согласен.") на форумах существует проблема несанкционированного переноса этого сообщения на другой форум, что исказит позицию автора.


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


Плюсы: возможность проверки последовательности сообщений
Минусы: сложности при модерации


  • имхо защита от такой атаки не входит в модель OpenPGP, и ее внесение только излишне усложнит стандарт. Для желающих избежать такой атаки будет достаточно вставлять в каждый пост ссылку на топик к которому он относиться. (ntldr)
  • Согласен, это чисто инженерная проблема реализации; сам протокол с такими мелочами связываться не должен.

© 2007 SATtva, ntldr, serzh, unknown

Материал распространяется на условиях
CreativeCommons-Attribution-ShareAlike
CreativeCommons-Attribution-ShareAlike

 
Несколько комментариев (8) [показать комментарии/форму]
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3