[devel] Вопросы новичка

[Victor B. Wagner]

On 2009.05.05 at 12:43:19 +0300, Alexander Bokovoy wrote:

> > Федора и Сусе делают ставку на libnss. Сертифицированных решений с
> > российскими алгоритмами на базе libnss пока не существует. Не существует
> > даже работающих, хотя и не сертифицированных.
> Витус, ты упустил главное. Я не веду речь о переходе на libnss
> _вообще_. Я хочу, чтобы те, кто заинтересован в этой теме, обратили
> внимание на уже пройденные грабли по централизации обработки
> сертификатов. Грабли эти довольно хорошо задокументированы, особенно в
> Fedora, для целого ряда приложений.

В данном случае я обращаю внимание на то, что путь, который выбран
Fedora и Suse, у нас не очень приемлем. "хорошо задокументированных
граблей по вышепоскипанным ссылкам не заметил". Там перечислены ну
настолько общие места, которые даже в наших методичках для пользователей
CSP и то разжеваны подробнее. Ну то есть понятно, что среди авторов и
мейнтейнеров приложений криптографический ликбез нужно проводить с нуля.
Но все же.

В Maemo - интереснее.

Но вот думать о создании единой политики использования ключевой
инфраструктуры в пределах дистрибутива - надо.

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

На данный момент мы имеем следующую картину

у libnss есть пользовательское хранилище, но нет системного.
У OpenSSL есть "умолчательное", т.е. необязательное к использованию
общесистемное, но нет стандартизованного пользовательского. Кстати можно
попробовать в upstream эту идею пропихнуть. 

У  gnutls это вообще отдано на откуп приложениям.


> Политика меня слабо интересует. Техническая возможность сделать единую

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

Мы бы в общем-то и рады пропихивать нашим клиентам, покупающим у нас
серверные решения, решения переносимые, с которыми можно работать и из
свободного софта. Но пока с этим как-то плохо.

> базу сертификатов для всех разрозненных библиотек существует, хотя бы

Я бы постарался избегать термина "база". К сожалению, прочитав слово
"база" многие разработчики начинают думать об SQL. SQL, даже в
инкарнации SQLite здесь не место. Не те объемы, не те критерии поиска.
А держать по крайней мере хранилище, используемое в WPA, потребуется на
корневой FS. 

Оно нам надо - libsqlite в /lib?

Поэтому я бы предложил использовать термин "хранилище". Чтобы не
вызывать ненужных ассоциаций.

Вообще, на мой взгляд, правильно стандартизировать формат хранилища и
его расположение в файловой системе. Но ни в коем случае не
стандартизировать код для доступа к этому хранилищу. Во всяком случае на
начальном этапе

Формат должен быть такой, чтобы код для доступа умещался в экран.

После того как появятся 4-5 разновидностей этого когда, написанного
разными людьми, под разные приложения и библиотеки, на разных языках,
можно будет посравнивать их и подумать о стандартизации.

> в рамках криптографических алгоритмов, которые они все поддерживают.
> Это приемлемое решение, если все библиотеки будут "смотреть" в одну и

Тут требуется обеспечить возможность игнорирования не понимаемых
алгоритмов. Чтобы использование национальных алгоритмов не было
равнозначным отказу от стандартного хранилища.

Собственно поэтому я начал активно лезть в alt только после появления 
OpenSSL 1.0beta. На данном этапе возможно успешное сосуществование
неподдерживающего национальные алгоритмы софта и поддерживающего над 
общим ABI новой версии OpenSSL. В старой версии, когда ABI версии
поддерживающей ГОСТ и "родной" был несовместим, с этим было сложнее.

> Почему в Maemo для стандартных алгоритмов с тремя библиотеками такую
> систему удалось сделать, а в ALT нельзя? Потенциально российская

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


> криптография в Maemo 6 будет поддерживаться на основании вашей работы
> с апстримом, насколько это будет реально работать к моменту выхода

Если приложение умеет читать openssl.cnf, то как правило, российский TLS 
и PKCS#7 в соответствии с RFC 4490 
в нем работают совершенно прозрачно для пользователя и администратора -
только ключи и заявки на сертификат надо немножко по-другому
генерировать. Если не умеет, то нужен однострочный патч, чтобы
научилось. Вообще-то в документации к OpenSSL читать этот конфиг
настоятельно рекомендуют начиная с версии 0.9.7.

Вопрос "насколько оно будет работать", надо ставить только в отношении
приложений, которые реализуют собственные криптопротоколы - ssh (для
которого пока нет даже драфта на использование российских алгоритмов, не
говоря уж о реализации), openvpn (для которой есть патч).

Из приложений, которые используют обычный tls, единственное на сей
момент найденное приложение, которому требуется нетривиальный патч - это
Apache (насколько понимаю, в случае Maemo - не шибко интересно).