Возвращаясь к напечатанному...

> Сколько потребуется публичных/приватных ключей, чтобы обеспечить доступность N серверов с любого из этих N компьютеров? Насколько я понимаю, требуется перенести публичный ключ каждого сервера на каждый из клиентов - то есть дофига перемещений.

Нужно распространить один ключ CA на всех клиентов. В случае AD это делается автоматически.

При чём здесь AD? Ты же утверждал, что SSL/TLS масштабируется не хуже Kerberos, а теперь выясняется, что нужна еще дополнительная сущность в виде AD для обеспечения этой масштабируемости.

> Ты же утверждал, что SSL/TLS масштабируется не хуже Kerberos

Я утверждал (и продолжаю утверждать), что инфраструктура X.509 масштабируется не хуже.

AD - это, грубо говоря, средство транспорта для CA/PA. Его может не быть - можно хранить корневой сертификат на каждом клиенте, более того, если ты ведешь свою иерархию от коммерческих CA, тебе клиенту ничего вообще давать не нужно.

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

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

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

За счет того, что у тебя есть сертификаты корневых CA, ты можешь отследить trust path до клиента.

Никто при этом не мешает тебе при необходимости выдавать сертификаты клиенту самостоятельно.

Похоже мы понимаем под масштабируемостью разные вещи. В качестве примера я всегда представлял себе большие "полуоткрытые" организации с большим числом серверов (сервисов) и еще большим числом пользователей. Причём пользователи имеют какое-то отношение к организации, и сервис предоставляется им как изнутри так и извне этой организации (пример - кампус при университете).
Масштабируемость же TLS (как я понял с твоих слов) сводится к тому, что для каждого (!) из сервисов нужно перенести публичный ключ на каждый из клиентов. Средствами TLS это не решается и требуется привлечение внешних сущностей - будь то AD или коммерческий CA (сколько они попросят за обслуживание 1000 сервисов?)
Из твоих комментариев я понял, что для одного сервиса и неограниченного числа пользователей не испытывающих недостатка в средствах TLS может быть и неплохое решение. Хотя с моей точки зрения коммерческий (CA) и trusted party - понятия несовместимые.

> Масштабируемость же TLS (как я понял с твоих слов) сводится к тому, что для каждого (!) из сервисов нужно перенести публичный ключ на каждый из клиентов.

нет. тебе нужно только иметь сертификат корневого CA. он может быть твоим, а может быть внешним.

еще x.509 позволяет строить иерархии, а в kerberos это несколько затруднительно - прописывать трасты между доменами нужно руками.

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

> только не впоне понятно насколько это удобно - переносить сертификат CA на все клиенты

как я сказал, в виндовом окружении для этого можно использовать AD. в юниксовом - ну, cfengine какой-нибудь

> если с CA что-то случится

корневой CA вообще можно (и нужно) делать off-line...

>если с CA что-то случится
Не в том смысле, что CA упадёт, а в том, что с ним произойдут необратимые изменения. Ну, там пароль (ключ) изменится...

ну, что будет, если TGS упадет? что будет, если сломается база ключей клиентов?

какой пароль в CA?

>>>какой пароль в CA?

Ну, а как та херня называется, которой что-то там подписывают?

ключ. закрытый. он не меняется просто так.

М-да ... ликбез основ какой то.

Я рад, что и ты, Олежка, нашёл что-то для себя полезное в этой дискуссии...