<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
02.08.2017 17:05, Konstantin Lepikhov пишет:<br>
<blockquote cite="mid:20170802140523.GA29131@lks.home" type="cite">
<pre wrap="">Hi Paul!
On 08/02/17, at 04:24:41 PM you wrote:
<skip>
</pre>
<blockquote type="cite">
<pre wrap=""> +1. А если иерархия УЦ РФ подразделяется на какие-то достаточно
крупные самостоятельные части, то стоит, наверное, так и представить это
для пользователя. Примерно так, как сейчас выбираются группы пакетов в
инсталляторе. Чтобы можно было указать: вот этим доверяю, а вот этим — нет.
</pre>
</blockquote>
<pre wrap="">Это все имеет очень косвенное отношение к проблеме. Проблема в том, что
предлагается упростить правила по обеспечению безопасности списка
доверенных корневых сертификатов на уровне системы с формулировкой "я не хочу
заморачиваться, сделайте красиво". К сожалению, тут такие формулировки
неуместны. Неважно какие сертификаты и от какого УЦ там будут, это просто
работает по другому: когда есть формальные критерии и изменения им
удовлетворяют.
Я привел документ (Mozilla Root Store policy)[1], на котором основан список
сертификатов ca-bundle в системе, и хотелось бы получить что-то со стороны
сторонников "по мирному" и "инсинуаций".
PS Mozilla тут только в качестве хранителя ресурса, сертификацией и
поддержкой NSS вообще-то занимается RedHat[2].
1. <a class="moz-txt-link-freetext" href="https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/">https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/</a>
2. <a class="moz-txt-link-freetext" href="https://wiki.mozilla.org/FIPS_Validation">https://wiki.mozilla.org/FIPS_Validation</a>
</pre>
</blockquote>
При всём уважении к формальным критериям, в экосистеме RedHat мы
видим также и <a
href="https://www.happyassassin.net/2015/01/14/trusting-additional-cas-in-fedora-rhel-centos-dont-append-to-etcpkitlscertsca-bundle-crt-or-etcpkitlscert-pem/">update-ca-trust</a>
.<br>
Положим, необходимость соблюдения должных правил при опакечивании
цепочек доверия - никто не отрицает. Однако начали-то мы с проблем
не безопасности, но функциональности!<br>
Да, речь действительно идёт о некотором упрощении жизни
администратора, и при некоторых обстоятельствах он может таким
образом нанести ущерб безопасности своей системы. Однако обращаю
внимание на тот факт, что суперпользователь по-любому сделает так
как ему покажется правильным, и попытка воспрепятствовать по сути -
security through obscurity. И вообще, кажется мы пытаемся
"заморочить и сделать некрасиво" тому, кто может при желании взять
какой-нибудь более другой дистрибутив? Вот это полагаю по-настоящему
неуместным.<br>
<br>
Моё мнение: правила аудита сертификатов перед опакечиванием -
перевести, опубликовать и принять в качестве Policy. Но это имеет
косвенное отношение к обсуждаемой проблеме.<br>
<br>
<div class="moz-signature">-- <br>
С уважением, <b>Павел Исопенко</b><br>
тел. +79165329582<br>
email: <a class="moz-txt-link-abbreviated" href="mailto:pauli@altlinux.org">pauli@altlinux.org</a><br>
XMPP: <a class="moz-txt-link-abbreviated" href="mailto:pavelri@jabber.credoaudit.ru">pavelri@jabber.credoaudit.ru</a></div>
</body>
</html>