id: Гость   вход   регистрация
текущее время 16:23 17/12/2018
Автор темы: Alex_B, тема открыта 27/11/2007 13:48 Печать
Категории: инфобезопасность, защита сети, разграничение доступа
https://www.pgpru.com/Форум/Офф-топик/УправлениеИдентификациейПосредствомPGP
создать
просмотр
ссылки

Управление идентификацией посредством PGP


В статье Управление идентификацией посредством PGP


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


1.а каким образом ПОСТАВЩИК проверяет подлинность этого ключа?
Возможно ли, каким-либо образом автоматизировать процесс выдачи PGP билетов?


2. Или другими словами, насколько хорошо предложенная схема PGPticket может быть применима для общественных узлов интернет?


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


Спасибо.


 
Комментарии
— SATtva (27/11/2007 15:11)   профиль/связь   <#>
комментариев: 11533   документов: 1036   редакций: 4084
Лучше бы Вы задавали вопросы непосредственно на странице статьи, чтобы не множить темы форума.

каким образом ПОСТАВЩИК проверяет подлинность этого ключа?

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

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

Есть ли примеры, которые уже работает по этой или схожей схеме?

Реализаций именно для PGPticket я не встречал, скорее всего их просто нет. Особенность этой схемы в том, что требуется реализовать специфический тип PGP-подписи, определив идентификатор пакета в частном/экспериментальном диапазоне (поскольку стандарт OpenPGP вряд ли в скором будущем получит поддержку подобной идеи... если вообще получит); соответственно, придётся писать собственный софт или модифицировать существующий, что, опять же, повышает сложность реализации схемы.

Правда, лично на мой взгляд это всё слишком тяжеловесно и избыточно. Иан Григг и его "Рикардианские контракты" показали, что можно использовать гибкость семантики PGP-подписи во благо, определяя её непосредственно в подписываемом тексте. (Расширение этой концепции на инструменты платёжной системы fileвыполнили недавно Даня Надь и Надежда Шакель, показав могучий потенциал стандарта и существующих реализаций OpenPGP. Надеюсь, их работа попадёт на Financial Cryptography 2008.)

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

Как бы я предпочёл видеть реализацию этой идеи?

Вместо всей этой возни с написанием спецификации собственного OpenPGP-пакета (а потом встраивать его поддержку в ПО, не получая при этом никакой совместимости), можно просто определить ряд текстовых полей, заполняемых соответствующими данными PGPticket'а. Далее, весь этот текст заверяется ключом поставщика, а полученный подписанный текст передаётся в плагин браузера пользователя, где и сохраняется. Теперь при посещении ресурса, требующего предъявить PGPticket, плагин передаёт его автоматически. Заметьте, в большинстве случаев всё это будет происходить без обращения к связке ключей пользователя (которое иногда может расцениваться небезопасным). В принципе, то же самое описано и в статье, идею портит только упоминание о формате собственного пакета, от которой, впрочем, можно легко отказаться.

Идеи PGPticket'а/PGPcoupon'а хороши до тех пор, пока их реализация не предполагает расширений/изменений спецификаций OpenPGP. Всю её можно сделать, полагаясь на существующие инструменты.
— Alex_B (04/12/2007 13:22)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
А чем PGPticket принципиально отличается от SSL?

Так же существует Удостоверяющий Центр выдающий
сертификаты, так же требуется доверие к этому центру, такие же
проблемы с отзывом сертификатов.
— poptalk (04/12/2007 22:43, исправлен 04/12/2007 22:51)   профиль/связь   <#>
комментариев: 259   документов: 12   редакций: 3
Далее, весь этот текст заверяется ключом поставщика, а полученный подписанный текст передаётся в плагин браузера пользователя, где и сохраняется. Теперь при посещении ресурса, требующего предъявить PGPticket, плагин передаёт его автоматически.

PGPticket можно попытаться отправлять через http redirect, как это делается в OpenID. И обойтись без плагина. Правда, тогда PGPticket могут украсть из истории броузера...
— poptalk (04/12/2007 23:11)   профиль/связь   <#>
комментариев: 259   документов: 12   редакций: 3
И кажется, PGPticket не обязательно подписывать, если сервер, который выдаёт PGPticket и сервер, который принимает, могут связаться напрямую.
— Alex_B (04/12/2007 23:21)   профиль/связь   <#>
комментариев: 143   документов: 31   редакций: 143
Без плагина не получится, шифровать то трафик от браузера что-то должно.
— SATtva (05/12/2007 16:12)   профиль/связь   <#>
комментариев: 11533   документов: 1036   редакций: 4084
Без плагина не получится, шифровать то трафик от браузера что-то должно.

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

Отличие от SSL в том, что они в принципе решают разные задачи.
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3