= Сообщение: 457 из 1933 ========================================== RU.BINKD = От : Pavel Gulchouck 2:463/68 12 Jun 15 23:17:54 Кому : Mithgol the Webmaster 12 Jun 15 23:17:54 Тема : Документы FTSC, поддерживаемые binkd FGHI : area://RU.BINKD?msgid=2:463/68+557b421b На : area://RU.BINKD?msgid=2:50/88+5579c689 = Кодировка сообщения определена как: CP866 ================================== Ответ: area://RU.BINKD?msgid=2:5020/12000+4f5299c1 ============================================================================== Hi Mithgol!
11 Jun 15, Mithgol the Webmaster ==> Andrey Ostanovsky:
AO>> Другое дело, что в binkd можно было бы реализовать использование файла AO>> открытого ключа в качестве пароля на сессию. В свое время, дискуссия AO>> уперлась в недостоверность ключей, которые могут поставлять AO>> недобросовестные NC.
MtW> Я не очень понимаю, как это взаимосвязано. Обычные 'пароли на сессию' ведь MtW> не NC поставляют, а сисопы ими как-то сами по себе обмениваются невозбранно. MtW> Тут то же самое: обязанность открытия открытого ключа нечего и возлагать на NC, MtW> пусть каждый сисоп сам откроет свой ключ кому надо (или вообще всем). А ещё MtW> можно было бы создать инфраструктуру взаимного подписывания ключей, которая бы MtW> работала по принципу N рукопожатий и с возможностью исключения всех тех NC, MtW> которые какой-то конечный получатель счёл не совершенно добросовестными.
Дискуссия об этом, как это обычно бывает, упёрлась в отсутствие желающих непосредственно реализовать.
А по сути там смысл такой. Сейчас есть три категории линков: unlisted, listed, protected. Для них могут быть разные правила обработки почты, и вообще разная политика. Использование ключей позволит добавить ещё один тип: authenticated. То есть, когда не просто пришёл некто и представился Васей Пупкиным 2:123/456, который присутствует в нодлисте, но когда мы знаем, что это действительно Вася Пупкин. Это не говорит о том, что мы ему доверяем, что там не может быть спам или ещё какая-то пакость, но мы знаем, что это действительно Вася Пупкин, а не злоумышленник, представившийся Васей, и это может быть полезно. Хотя это, конечно, не отменяет список protected, т.е. парольных линков, которым мы действительно доверяем (а пароль на сессию в таком случае можно и не прописывать, достаточно ключа).
Технически - обмен ключами можно сделать через keychains, по цепочке координаторов. Если ключ каждого сисопа подписан его NC, ключ NC - RC, а ключ RC - ZC, а у каждого сисопа будут публичные ключи его координаторов (NC, RC, ZC), то проверка по keychains всегда будет возможна. Дополнительно нужно разработать механизм отзыва скомпроментированных ключей. Всё это можно сделать, но - нужно, чтобы кто-то сделал (это не пара десятков строк кода, тут есть что делать); - нужна поддержка координаторов (или разработать альтернативный механизм распространения ключей и их подписи); - нужна поддержка сисопов (генерация ключей, их подписывание у координаторов, добавление ключей координаторов в keyring); - нельзя сказать, что предполагаемый результат очень уж впечатляющий.
По этим причинам технология так пока и остаётся в виде идеи.
Lucky carrier, Паша aka gul@gul.kiev.ua --- GoldED+/LNX 1.1.5 * Origin: printf("%s", "How can I increase performance?\n"); (2:463/68)
