From: "Victor B. Wagner" <vitus@altlinux.org> To: devel@lists.altlinux.org Subject: Re: [devel] Вопросы новичка Date: Tue, 5 May 2009 14:36:49 +0400 Message-ID: <20090505103649.GH2101@cryptocom.ru> (raw) In-Reply-To: <6062a6e60905050243u4642085ap7abe66a302b1d96e@mail.gmail.com> 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 - не шибко интересно).
next prev parent reply other threads:[~2009-05-05 10:36 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-05-04 15:00 Victor B. Wagner 2009-05-04 15:06 ` Andrey Rahmatullin 2009-05-04 15:22 ` Victor B. Wagner 2009-05-04 15:24 ` Mikhail Gusarov 2009-05-04 15:27 ` Andrey Rahmatullin 2009-05-04 15:27 ` Alexey I. Froloff 2009-05-04 15:51 ` Victor B. Wagner 2009-05-04 16:51 ` Max Ivanov 2009-05-04 17:31 ` Alexey I. Froloff 2009-05-05 8:10 ` Victor B. Wagner 2009-05-05 13:06 ` Alexey I. Froloff 2009-05-05 13:25 ` Victor B. Wagner 2009-05-05 15:06 ` Max Ivanov 2009-05-04 17:44 ` Alexander Bokovoy 2009-05-05 8:39 ` Victor B. Wagner 2009-05-05 9:43 ` Alexander Bokovoy 2009-05-05 10:36 ` Victor B. Wagner [this message] 2009-05-05 11:47 ` Alexander Bokovoy 2009-05-05 12:16 ` Victor B. Wagner 2009-05-05 12:44 ` Alexander Bokovoy 2009-05-05 12:57 ` Victor B. Wagner 2009-05-05 13:26 ` Alexander Bokovoy 2009-05-05 14:11 ` Victor B. Wagner 2009-05-07 6:13 ` Afanasov Dmitry 2009-05-07 21:26 ` Денис Смирнов 2009-05-08 7:41 ` Victor B. Wagner 2009-05-08 16:38 ` Денис Смирнов 2009-05-09 5:48 ` Alexander Bokovoy 2009-05-09 5:50 ` Andrey Rahmatullin 2009-05-09 6:04 ` Alexander Bokovoy 2009-05-09 6:06 ` Andrey Rahmatullin 2009-05-09 6:04 ` Alexander Bokovoy 2009-05-06 21:26 ` Dmitry V. Levin 2009-05-06 21:35 ` [devel] alt-rpm signature verification Dmitry V. Levin 2009-05-07 7:35 ` Afanasov Dmitry 2009-05-07 8:47 ` Victor B. Wagner 2009-05-07 15:37 ` Dmitry V. Levin 2009-05-07 17:17 ` Evgeny Sinelnikov 2009-05-07 17:21 ` Dmitry V. Levin 2009-05-07 17:22 ` Mikhail Gusarov 2009-05-07 17:31 ` Evgeny Sinelnikov 2009-05-07 18:23 ` Evgeny Sinelnikov 2009-05-07 15:36 ` Dmitry V. Levin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20090505103649.GH2101@cryptocom.ru \ --to=vitus@altlinux.org \ --cc=devel@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
ALT Linux Team development discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \ devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru public-inbox-index devel Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.devel AGPL code for this site: git clone https://public-inbox.org/public-inbox.git