From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on sa.int.altlinux.org X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,FUZZY_XPILL autolearn=no version=3.2.5 X-Virus-Scanned: Debian amavisd-new at cryptocom.ru Date: Tue, 5 May 2009 14:36:49 +0400 From: "Victor B. Wagner" To: devel@lists.altlinux.org Message-ID: <20090505103649.GH2101@cryptocom.ru> Mail-Followup-To: devel@lists.altlinux.org References: <20090504150025.GA1100@cryptocom.ru> <20090504152716.GD6444@altlinux.org> <6062a6e60905041044pd43de21k572c732eae5bbd2a@mail.gmail.com> <20090505083918.GE2101@cryptocom.ru> <6062a6e60905050243u4642085ap7abe66a302b1d96e@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <6062a6e60905050243u4642085ap7abe66a302b1d96e@mail.gmail.com> User-Agent: Mutt/1.5.13 (2006-08-11) Subject: Re: [devel] =?koi8-r?b?98/Q0s/T2SDOz9fJ3svB?= X-BeenThere: devel@lists.altlinux.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ALT Linux Team development discussions List-Id: ALT Linux Team development discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 May 2009 10:37:04 -0000 Archived-At: List-Archive: List-Post: 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 - не шибко интересно).