Обсуждение SSL/TLS policy с прошлого месяца, цитирую полностью.

On Mon, Jan 22, 2007 at 09:58:55AM +0300, Mikhail Yakshin wrote:
> Dmitry V. Levin wrote:
> 
> >> Предлагаю сделать нечто вроде SSL policy и закрепить в ней примерно
> >> следующие основные пункты:
> >>
> >> ==========================================================================
> >>
> >> 1. Существует ALT root CA, принадлежащий ООО (как и все остальные
> >> основные подписи и ключи по репозитариями и по проекту в целом).
> > 
> > Я сомневаюсь в том, что всё это принадлежит OOO.
> 
> Кому сейчас принадлежат GPG-ключи, которыми подписывается репозитарий,
> пакет openssl и защищаемые сервера *.altlinux.*? Как это лучше
> переформулировать?

Я не знаю, как это лучше переформулировать.  Нужна помощь.

> >> 1.1. Сертификат имеет CN=<такой-то>, OU=<такой-то>, O=<такой-то>,
> >> C=<такой-то> (и т.п.)
> >> 1.2. Срок действия CA устанавливается в <X> лет.
> > 
> > А какой срок является традиционным?  3 года?  5 лет?
> 
> Ну, вообще, из практики - у коммерческих CA этот срок очень сильно
> отличается. Вменяемые и серьезные CA имеют 10 лет, а
> среднеестатистические - где-то от 20 лет, а то и под 30.
> 
> Большинство самоподписанных сертификатов генерируются часто для галочки
> и имеют фактически неограниченный срок действия.
> 
> В свое время Thawte и VeriSign на этом очень погорели, когда выпустили
> свои первые сертификаты с первыми версиями Netscape на 5 или на 7 лет,
> кажется - и потом вдруг столкнулись с тем, что сертификат уже кончается,
> а масса народа не обновляло браузеры с тех пор и, вообще говоря, как-то
> не особенно планирует обновлять.
> 
> Регенерация сертификата CA - даже для нас - я так понимаю, это довольно
> нетривиальный набор действий (если только не придумать некий макрос в
> RPM, который бы добавлял его автоматически - тогда можно было бы
> пересобирать все нужные пакеты роботом и все), а для коммерческих CA -
> так совсем неподъемная задача.
> 
> Так что, думаю, разумным будет установить этот срок в 10 лет и придумать
> некую обвязку, которая бы позволила все пакеты, носящие в себе этот
> сертификат быстро пересобрать?

OK, пусть будет 10 лет, тогда торопиться с обвязкой не потребуется. :)

> >> 1.3. Его поддержанием, регенерацией, выписыванием сертификатов
> >> занимается <видимо, кто-то из суппорта?>
> > 
> > Это мы уже проходили.  К сожалению, в суппорте для этого слишком низкая
> > мера ответственности.  Думаю что security@altlinux для этого лучше
> > подходит.
> 
> Согласен.

OK

> >> 1.4. Регенерация делается за <полгода> до окончания срока действия
> >> очередного основного CA: генерируется новый сертификат и в эти полгода
> >> все носят 2 сертификата. Старый сертификат выкидывается отовсюду по
> >> возможности, как его срок действия совсем заканчивается.
> > 
> > Судя по опыту замены gpg-ключей, полгода будет мало.  Лучше если год.
> 
> Согласен.

OK

> >> 1.5. Сертификат всегда доступен для скачивания с
> >> <https://tls.altlinux.org>, а также в пакете openssl (из тех
> >> соображений, что он у нас наиболее системообразующий).
> >>
> >> 2. Все https-серверы и XMMP-серверы ALT (как минимум, перечисленные в
> >> gory details в первом письме) используют сертификаты, выписанные этим
> >> ALT root CA.
> >>
> >> 2.1. Сертификаты должны иметь корректно установленные, в том числе,
> >> например, правильный CN.
> >> 2.2. Т.к. есть, как минимум, 3 домена (altlinux.org, altlinux.ru,
> >> altlinux.com), видимо, на каждый сервис нужно выписывать 3 сертификата.
> > 
> > Точнее говоря, на каждый поддерживаемый этим сервисом домен.
> 
> Согласен.

OK

> >> 2.3. Там, где https объективно не нужен - его вообще быть не должно, 443
> >> порт закрыт.
> > 
> > Мне кажется, что это требование более универсально, чем SSL policy.
> 
> Ну, тем не менее -

Ну хорошо, пусть будет.

> >> 3. Все члены команды ALT имеют право попросить заверенные этим CA
> >> сертификаты в любом количестве для своих личных нужд.
> > 
> > Это утверждение надо переформулировать таким образом, чтобы исключить
> > неправильную трактовку, напр. рост количества сертификатов в
> > геометрической прогрессии.
> 
> Да в общем - и в геометрической - я ничего особенно страшного не вижу.
> Если будет необходимость выписывать их тысячами - для этого есть
> всевозможный более-менее свободный софт (всякие http://www.openca.info/,
> http://pki.openca.org/ и т.п.), стандартная процедура - запрос
> сертификата - выписывание сертификата.

OK

> >> ALT Linux TLS policy доступна на http://<URL где будет лежать policy>
> > 
> > SSL policy или TLS policy? :)
> 
> Вообще - лучше использовать термин TLS, он полностью заменил собой SSL
> еще в 1999 году.
> 
> http://en.wikipedia.org/wiki/Transport_Layer_Security#History_and_development

Только аббревиатура SSL всё ещё более распространена.  Тогда может
SSL/TLS?

> >> 5.2. Отсутствия такого текста - <minor> bug.
> >>
> >> ==========================================================================
> >>
> >> Оно же закинуто на http://www.freesource.info/wiki/Altlinux/Policy/TLS
> >>
> >> Прошу помочь вписать значения в <...> и высказаться насчет общего
> >> видения возможности принятия такой policy.
> > 
> > Не вижу принципиальных трудностей.
> 
> Хорошо, тогда, насколько я понимаю - надо дорешать вопросы с
> формулировками и можно сделать первые шаги:
> 
> 1. Сгенерировать этот самый root CA
> 2. Положить его в пакет openssl

OK, это я сделаю.

> 3. Выписать нужные сертификаты на серверы *.altlinux.* и разложить их
> где нужно

Это, видимо, тоже мне придётся делать, при содействии администраторов
соответствующих сайтов.

> 4. Ввести policy в действие

Как у нас принято вводить policy в действие?


-- 
ldv