Web of trust over X.509
Dec. 6th, 2007 04:38 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vitus_wagnerВ принципе я об этом уже писал.
Проблема заключается в следующем - на белом свете существуют две системы PKI (Public Key infrastructure)
X.509, которая апеллирует к неким мистическим Certificate Authorities, и PGP-шная Web of trust, в которой юзер сам решает, кому он доверяет в деле идентификации ключей других пользователей, а кому нет. (Существуют и еще всякие разные PKI, но интернет-стандартами являются только эти две). Браузеры поддерживают только X.509. Более того, каждый браузер поставляется с комплектом сертификатов неких коммерческих CA, которым он по умолчанию доверяет. Его даже не спрашивают, хочет он доверять американской фирме VeriSign или нет.
Поэтому для распределенного блога, который по определению не должен зависеть ни от каких правительственных или коммерческих организаций, а только от взаимного доверия пользователей, модель Web of trust подходит лучше. Но она не поддерживается из коробки браузерами, соответственно возникнут проблемы при работе из интернет-кафе, а у технически не подкованных юзеров, и при работе из дома.
Но Web of trust - это концепт не столько техничекий, сколько идеологический. Основные применения X.509 сейчас происходят в корпоративной среде, там строгая иерархия естественна. Корпоративный сисадмин ставит всем сотрудникам сертификат корпоративного корневого CA и проблема доверия внутри корпорации решена. Применения в электронной коммерции, с наличием нескольких выделенных корпораций, которые гарантируют всем пользователям идентичность выступаюих на рынке корпораций (на чем, собственно, зарабатывает VeriSign) тоже вполне укладываются в иерархическую модель.
Но давайте, всё же отвлечемся от существующих применений и подумаем - кому и в чем мы доверяем?
На самом деле, в случае distributed blogging-а, электронная подпись под постом или комментарием, удостоверяет только то, что написавший эти строки действительно имеет право писать в блог с определенной URL. Как и OpenId. Разница только в том, что для того, чтобы проверить электронную подпись, нужно всего лишь иметь закэшированный сертификат выдавшего её CA, а для того, чтобы проверить OpenID нужно on-line провзаимодействовать с сервером, к которому относится данная URL.
Т.е. в случае (традиционной) блогосферы сервер, хостящий первичную копию блога является естественным Authority по отношению к идентичности хостящихся на нем пользователей. Не говоря уж о том, что они ему, вероятно, доверяют. А то какого бы хрена они стали на нем хоститься?
Cоответственно, каждый блог-сервер является сам себе CA. Он выдает персональные сертификаты своим пользователям, и сертификат HTTPS себе. Пользователи этого сервера устанавливают себе его сертификат CA в качестве корневого (это, на самом деле, крайне несложная процедура). Соответственно, если пользователь одного сервера хочет удостовериться в идентичности пользователя другого сервера, он должен иметь сертификат ключа CA того сервера, подписанный своим сервером.
Как этого добиться? А очень просто. Примерно так же, как наш сервер узнает адрес OpenID-провайдера чужого сервера.
1. Выкачиваем с того сервера сертификат CA (который на всех серверах распределенной блогосферы будет лежать по определенной URL)
2. Идем на тот сервер по HTTPS и убеждаемся что сертификат HTTPS подписан именно этим ключом CA.
3. Выпускаем свой сертификат на тот ключ CA, подписанный нашим ключом. Этот сертификат мы в любой момент можем отозвать. Если вдруг узнаем что админ того сервера пропил свой секретный ключ. А мы узнаем, не беспокойтесь. Это ж блогосфера, и подобные вещи обязательно всплывут.
4. Раздаем его своим пользователям. Вплоть до автоматического встраивания в PKCS7 структуры подписей, выработанных клиентами этого CA.
Вообще-то лучше сначала поинтересоваться у окружающих блог-серверов, которым мы УЖЕ доверяем, доверяет ли кто-нибудь из них новому, ранее неизвестному нам блог-серверу, и получить сертификат, подписанный уже известным нам ключом CA. Скорее всего такая цепочка выстроится, так как откуда-то наш юзер получил ссылку на тот блог. Скорее всего из какого-то другого блога.
Картина получается примерно такая же, как если от модели с плоской Землей с Мировым Древом посредине мы переходим к модели шарообразной Земли, каждая точка которой является центром Вселенной для тех, кто в этой точке проживает. Т.е. главным Certificate Authority для пользователей каждого блог-сервера, является сам этот блог-сервер, который берет на себя работу по проверке идентичностей всех окружающих серверов.
Теперь посмотрим, что происходит, если наш сервер находится в offline и мы решили запостить или почитать через другой сервер.
Естественно, мы выбираем для постинга сервер, который несет копию нашего блога. А раз он её уже имеет, значит он уже знаком с нашим сервером, с которого он, собственно, эту копию получил. Значит у него есть сертификат на его ключ CA. Значит он может при необходимости удостоверить нашу подпись. С другй стороны, у нас скорее всего есть сертификат на его ключ CA, подписанный нашим CA. То есть нам не надо даже устанавливать его самоподписанный сертификат. Как максимум - удлинится на единицу длина цепочки доверия.
Можно, конечно, придумать ряд технических мер, облегчающих выстраивание цепочек доверия. Например, если наш сервер переподписал сертификат CA соседнего сервера - вернуть ему переподписанный сертификат. Просто так, на всякий случай, вдруг пригодится.
Проблема заключается в следующем - на белом свете существуют две системы PKI (Public Key infrastructure)
X.509, которая апеллирует к неким мистическим Certificate Authorities, и PGP-шная Web of trust, в которой юзер сам решает, кому он доверяет в деле идентификации ключей других пользователей, а кому нет. (Существуют и еще всякие разные PKI, но интернет-стандартами являются только эти две). Браузеры поддерживают только X.509. Более того, каждый браузер поставляется с комплектом сертификатов неких коммерческих CA, которым он по умолчанию доверяет. Его даже не спрашивают, хочет он доверять американской фирме VeriSign или нет.
Поэтому для распределенного блога, который по определению не должен зависеть ни от каких правительственных или коммерческих организаций, а только от взаимного доверия пользователей, модель Web of trust подходит лучше. Но она не поддерживается из коробки браузерами, соответственно возникнут проблемы при работе из интернет-кафе, а у технически не подкованных юзеров, и при работе из дома.
Но Web of trust - это концепт не столько техничекий, сколько идеологический. Основные применения X.509 сейчас происходят в корпоративной среде, там строгая иерархия естественна. Корпоративный сисадмин ставит всем сотрудникам сертификат корпоративного корневого CA и проблема доверия внутри корпорации решена. Применения в электронной коммерции, с наличием нескольких выделенных корпораций, которые гарантируют всем пользователям идентичность выступаюих на рынке корпораций (на чем, собственно, зарабатывает VeriSign) тоже вполне укладываются в иерархическую модель.
Но давайте, всё же отвлечемся от существующих применений и подумаем - кому и в чем мы доверяем?
На самом деле, в случае distributed blogging-а, электронная подпись под постом или комментарием, удостоверяет только то, что написавший эти строки действительно имеет право писать в блог с определенной URL. Как и OpenId. Разница только в том, что для того, чтобы проверить электронную подпись, нужно всего лишь иметь закэшированный сертификат выдавшего её CA, а для того, чтобы проверить OpenID нужно on-line провзаимодействовать с сервером, к которому относится данная URL.
Т.е. в случае (традиционной) блогосферы сервер, хостящий первичную копию блога является естественным Authority по отношению к идентичности хостящихся на нем пользователей. Не говоря уж о том, что они ему, вероятно, доверяют. А то какого бы хрена они стали на нем хоститься?
Cоответственно, каждый блог-сервер является сам себе CA. Он выдает персональные сертификаты своим пользователям, и сертификат HTTPS себе. Пользователи этого сервера устанавливают себе его сертификат CA в качестве корневого (это, на самом деле, крайне несложная процедура). Соответственно, если пользователь одного сервера хочет удостовериться в идентичности пользователя другого сервера, он должен иметь сертификат ключа CA того сервера, подписанный своим сервером.
Как этого добиться? А очень просто. Примерно так же, как наш сервер узнает адрес OpenID-провайдера чужого сервера.
1. Выкачиваем с того сервера сертификат CA (который на всех серверах распределенной блогосферы будет лежать по определенной URL)
2. Идем на тот сервер по HTTPS и убеждаемся что сертификат HTTPS подписан именно этим ключом CA.
3. Выпускаем свой сертификат на тот ключ CA, подписанный нашим ключом. Этот сертификат мы в любой момент можем отозвать. Если вдруг узнаем что админ того сервера пропил свой секретный ключ. А мы узнаем, не беспокойтесь. Это ж блогосфера, и подобные вещи обязательно всплывут.
4. Раздаем его своим пользователям. Вплоть до автоматического встраивания в PKCS7 структуры подписей, выработанных клиентами этого CA.
Вообще-то лучше сначала поинтересоваться у окружающих блог-серверов, которым мы УЖЕ доверяем, доверяет ли кто-нибудь из них новому, ранее неизвестному нам блог-серверу, и получить сертификат, подписанный уже известным нам ключом CA. Скорее всего такая цепочка выстроится, так как откуда-то наш юзер получил ссылку на тот блог. Скорее всего из какого-то другого блога.
Картина получается примерно такая же, как если от модели с плоской Землей с Мировым Древом посредине мы переходим к модели шарообразной Земли, каждая точка которой является центром Вселенной для тех, кто в этой точке проживает. Т.е. главным Certificate Authority для пользователей каждого блог-сервера, является сам этот блог-сервер, который берет на себя работу по проверке идентичностей всех окружающих серверов.
Теперь посмотрим, что происходит, если наш сервер находится в offline и мы решили запостить или почитать через другой сервер.
Естественно, мы выбираем для постинга сервер, который несет копию нашего блога. А раз он её уже имеет, значит он уже знаком с нашим сервером, с которого он, собственно, эту копию получил. Значит у него есть сертификат на его ключ CA. Значит он может при необходимости удостоверить нашу подпись. С другй стороны, у нас скорее всего есть сертификат на его ключ CA, подписанный нашим CA. То есть нам не надо даже устанавливать его самоподписанный сертификат. Как максимум - удлинится на единицу длина цепочки доверия.
Можно, конечно, придумать ряд технических мер, облегчающих выстраивание цепочек доверия. Например, если наш сервер переподписал сертификат CA соседнего сервера - вернуть ему переподписанный сертификат. Просто так, на всякий случай, вдруг пригодится.
