| ||||
| ||||
| Такая проблема. Есть требования для сертификатов, которые должны действовать в определенной сфере. В соответствие данному сертификату ставится OID. Но данный идентификатор соответствует определенному УЦ. Проблема в том, что выпуская сертификаты другим УЦ для той же сферы использования сертификатов OID-ы отличается (они соответствуют двум разным УЦ). Можно ли использовать чужой OID при генерации сертификатов? Если нет, то как быть в такой ситуации, есть ли какие-нибудь регламенты? | ||||
| Ответы: | ||||
| ||||
| Каждый УЦ разрабатывает свой документ ( например, "Регламент услуг УЦ") в котором, в том числе, перечислены возможные OID-ы использования ключей (EKU) и их юридическая интерпретация. Данный УЦ будет выдавать только такие сертификаты, в которых OID-ы EKU являются допустимыми (т.е. из вышеупомянутого списка). Кроме того, область применения сертификатов может быть юридически ограничена рамками конкретной информационной системы (это, опять-таки, определяется Регламентом услуг УЦ). | ||||
| ||||
| Каждый УЦ разрабатывает свой документ ( например, "Регламент услуг УЦ") в котором, в том числе, перечислены возможные OID-ы использования ключей (EKU) и их юридическая интерпретация. Данный УЦ будет выдавать только такие сертификаты, в которых OID-ы EKU являются допустимыми (т.е. из вышеупомянутого списка). Кроме того, область применения сертификатов может быть юридически ограничена рамками конкретной информационной системы (это, опять-таки, определяется Регламентом услуг УЦ). Хорошо. Есть два УЦ. Применение сертификатов у них одни и те же, т.е. в рамках конкретной системы. Но OID-ы у них отличаются поскольку УЦ разные. Проблема в том, что ПО в рамках системы работает только с сертификатами с конкретным OID-ом. Что тут можно сделать ? | ||||
| ||||
| Здесь обратная ситуация. Если нужно, чтобы сертификаты, которые выпускает УЦ, применялись в рамках конкретной информационной системы (ИС), то как раз сам УЦ подстраивают под требования этой системы. Т.е. на всех УЦ, которые будут выдавать сертификаты для работы в ИС нужно настроить разрешения нужных OID-ов EKU (а также расширений сертификатов, если это нужно). Разные УЦ могут выдавать сертификаты с одинаковыми OID-ами EKU. | ||||
| ||||
| Здесь обратная ситуация. Если нужно, чтобы сертификаты, которые выпускает УЦ, применялись в рамках конкретной информационной системы (ИС), то как раз сам УЦ подстраивают под требования этой системы. Т.е. на всех УЦ, которые будут выдавать сертификаты для работы в ИС нужно настроить разрешения нужных OID-ов EKU (а также расширений сертификатов, если это нужно). Разные УЦ могут выдавать сертификаты с одинаковыми OID-ами EKU. Это касается только OID-ов которые начинаются на 1.3? Или также и 1.2.643.3.? Дело в том что у нас партнерские отношения с некоторой организацией по работе в ИС. У нас и у сторонней-партнерской организации есть свои УЦ. Может нужны какие-то договора или соглашения по использованию сторонних OID. Например, если наш УЦ 1.3.643.3.111..., а необходим 1.3.643.3.112... Смущает именно 111 и 112. | ||||
| ||||
| Здесь обратная ситуация. Если нужно, чтобы сертификаты, которые выпускает УЦ, применялись в рамках конкретной информационной системы (ИС), то как раз сам УЦ подстраивают под требования этой системы. Т.е. на всех УЦ, которые будут выдавать сертификаты для работы в ИС нужно настроить разрешения нужных OID-ов EKU (а также расширений сертификатов, если это нужно). Разные УЦ могут выдавать сертификаты с одинаковыми OID-ами EKU. Это касается только OID-ов которые начинаются на 1.3? Или также и 1.2.643.3.? Дело в том что у нас партнерские отношения с некоторой организацией по работе в ИС. У нас и у сторонней-партнерской организации есть свои УЦ. Может нужны какие-то договора или соглашения по использованию сторонних OID. Например, если наш УЦ 1.3.643.3.111..., а необходим 1.3.643.3.112... Смущает именно 111 и 112. | ||||
| ||||
| Разрешите принять участие в обсуждении... OID 1.3.643.3.111 зарегистрирован за организацией "ОРГ1" и теперь OID 1.3.643.3.111 является объектом собственности организации "ОРГ1" OID 1.3.643.3.112 зарегистрирован за организацией "ОРГ2" и теперь OID 1.3.643.3.112 является объектом собственности организации "ОРГ2" Использование чужой собственности регулируется соглашениями (договором) между владельцем и пользователем собственности. Для того, что бы "ОРГ2" могла использовать OID 1.3.643.3.111 ей нужно заключить соглашение с "ОРГ1". Поэтому использовать чужой OID без разрешения его владельца НЕЛЬЗЯ | ||||
| ||||
| Ну не факт, если дерево идентификаторов открыто, например, все используют Алгоритм: gostR3410EC_CryptoPro: OBJECT_IDENTIFIER: 1.2.643.2.2.36.0 OBJECT_IDENTIFIER: 1.2.643.2.2.30.1 OID которых принадлежат ветки КриптоПРО, и я не думаю, чтобы кто нить вам за это платил или заключал с вами договор. ------------- А по существу игначального вопроса, существует понятие маппирования политик, где OID одного защищенного домена соотносится с OID из другого домена. И становится все просто, в терминах Маслова "собственность" остается у собственника, а в рамках объединенной зоны составляется соглашение о соответствии политик между двумя организаторами доменов - УЦ. | ||||
| ||||
| Объясняю еще раз... Использование OID должно быть основано на соглашении с владельцем. Например, OID 1.2.643.2.2.36.0 является собственностью КРИПТО-ПРО. Он является одним из элементов программного обеспечения производства КРИПТО-ПРО. КРИПТО-ПРО продает право использования программным обеспечением, включая программу для ЭВМ, ее составные части, документацию. Продажа этого права осуществляется по соглашени. Таким образом, использование OID 1.2.643.2.2.36.0 определено соглашением. Вопрос про технологические OIDы КРИПТО-ПРО снят? Переходим к следующему вопросу... Тут все проще. Только не начинайте думать о "маппировании", "доменах" и прочиих не регламентированных терминах и понятиях. Вот есть OID 111, который является собственностью "ОРГ1" и определяет сферу отношений "подписывание налоговой отчетности". Вы, как "ОРГ2", берете своий OID 112 и в Регламенте УЦ прописываете, что 112 определяет сферу отношений "подписывание налоговой отчетности". Это Вам никто не запретит. Теперь, при сдаче наговой отчетности в ФНС по телекоммуникационным каналам связи, можно использовать и OID 111 и OID 112. Обычно, потребность в заключении соглашения возникает тогда, когда в ПО производства "ОРГ2" намертво вшита привязка к OID 112. тогда только соглашение | ||||
| ||||
| Тогда уже я спрашиваю еще раз. Берем сертификат, выпущенный на вашем сервере и видим следующие технологические OID: Назначение ключа: Аутентификация клиента: 1.3.6.1.5.5.7.3.2 далее Доступ к информации издателя: Описание: Способ доступа: 1.3.6.1.5.5.7.48.2 Я не уверен, что КриптоПРО ПОКУПАЛО право использовать эти OID. Почему право использования OID размещенного в свободном доступе в RFC определяющие использование отечественных криптоалгоритмов надо у кого то покупать? Юрий я думаю вас мало кто поймет :-))) И это мы уже обсуждали когда готовили (кстати вмести с вашей компанией) эти самые RFC которые еще были драфтами. И я считал, что этот вопрос решен, а тут опять – КриптоПРО принадлежит (и это надо выкупать) идентификация отечественного крипта – вас точно не поймут :-) --------------- Теперь к следующему вопросу: понятия домен, маппирование, политики использования сертификатов есть международные термины, закрепленные в тех же RFC опираясь на которые вы (надеюсь) строите свои продукты. Далее по OID, согласно вашей логики если 111 принадлежит ОРГ1, а 112 - ОРГ2, на каком основании оператор или сама налоговая (своего рода ОРГ3) может принимать к рассмотрению (использовать) эти 111 и 112 не покупая их у ОРГ1 и ОРГ2 соответственно? В международной практике есть понятия открытых и закрытых областей идентификаторов, где идентификаторы из открытых областей доступны к использованию всеми без покупки и тому подобной ерунды. И если уж далее рассуждать, все в той же мировой практике политика использования сертификатов указывается через специальный атрибут - политики, а не через EKU, где последний применяется для технических нужд, например, указывает, что ключ может быть использован для шифрования, идентификации субъекта и т.п. , а не для ролевых признаков субъекта. Именно поэтому во всем мире введены понятия маппирования политик, чтобы связать однотипные роли различных доменов (или областей доверия или зон - что одно и тоже по смыслу). В НИСТе существует даже специальная серия тестов для прикладного ПО посвященная именно маппированию (которого по мнению Маслова - нет :-)))) ) у нас в стране существуют аналоги НИСТовских тестов для отечественной криптографии которые в настоящий момент находятся на рассмотрении в ФСБ, там тоже есть раздел посвященный маппированию. А вот маппирования EKU в природе не существует :-))) | ||||
| ||||
| TO "Муругов Сергей Михайлович" Меня прикалывают свободные толкования и измышления. Во всех моих постах никаким анализатором не найти слово "купить" или аналогичное ему по смыслу слова. Я уважаю Вас, поэтому считаю Ваши сентенции на эту тему временным "сбоем" сознания или еще чего. Если обладатель прав на OID включил их в состав предложения на проект RFC, которые перешли в собственно RFC, то согласно правил ЛЮБОЙ может руководствоваться этими RFC без дополнительных соглашений с авторами. Таким образом, все правовые вопросы использования OID от КРИПТО-ПРО в данных RFC являются отрегулированными. Подобным образом нетрудно установить правовые основы использования в наших продуктах OID 1.3.6.1.5.5.7.3.2. Честно говоря, это настолько прозрачно, что даже как то неловко объяснять Вам это. Что касается второй части, то там сразу бросаются в глаза слова "покупая их" (об этом я писал выше), некий субъект правоотношений "НИСТ" (такого субъекта я не нашел в нормативно-правовых актах Российской Федерации), некое слово "маппирование", толкование которого я тоже не нашел в в нормативно-правовых актах РФ. Значит, это очередной диспут не о чем. Сергей Михайлович, прошу простить, но я его продолжать не буду :-) Вот когда это эфемерное "маппирование" перейдет в некие законные или подзаконные акты, хотя бы на уровне требований ФСБ, и будет толкование его на правовом уровне, вот тогда с удовольствием приму участие с Вами в диспуты о том как его применять в бизнес-практике и как его реализовывать. | ||||
| ||||
| 1. Не все же время работой заниматься надо маленько и «по сентенцировать» :-) 2. В нормативных актах, наравне с политиками сертификатов и маппированием я также не нашел слов EKU (кстати слова «сфера отношений» тоже не нашел), но нашел слова «используются в соответствии со сведениями, указанными в сертификате ключа подписи» - ФЗ Об ЭЦП. Я твердо знаю, что ФСБ не требует казывать «использование» через EKU, а значит оба подхода имеют право на жизнь, только работая через политики предлагается более гибкое и логичное управление, принятое во всем мире. Не буду тут писать откуда вообще это EKU взялось и кто придумал туда укладывать роли. 3. Что касается непосредственно сути вопроса. Уважаемый Александр, опубликуйте публично OID и попросите своих партнеров поступить аналогично и пользуйтесь на здоровье все – вставляйте в сертификаты и т.п. , без этих заумных «объект собственности» из которых может вылезти в последствии неизвестно что. Для опубликования, вполне может подойти и то что уже есть, например, http://www.tel-inform.ru/x500/OIDS/inform.htm#REG2 посмотрите для номерочка 1.2.643.2.21 это ветка нашей компании. | ||||
| ||||
| TO "Муругов Сергей Михайлович" 1. Надо постараться совместить. Как это делаем мы сейчас :-) 2. ФСБ не требует, но наш продукт сертифицирован, в отличии от многих прочих :-). EKU более приятен тем, что многие стандартные приложения Windows работаю именно с этим расширением. Например, MS IE требует в EKU "проверку подлинности клиента" при работе с HTTPS. MS IIS и MS ISA Server требуют в EKU "проверку подлинности сервера". Outlook требует в EKU "Защита электронной почты". А вот CP (политики) приложения не требуют и обрабатывать не умеют. Опять таки разработчикам удобнее через высокоуровневые средства (например, CAPICOM) получить доступ к EKU. А вот для доступа к CP таких средств нет. Поэтому ради "маппирования" менять платформы ОС и прочие приложения - гнилая идея. Вот наш ПАК "КриптоПро УЦ" тоже умеет "работать" (изготавливать и управлять) сертификаты с расширениями CP и CPS. Но кому от этого счастье?! :-) 3. Александр, только не вздумайте опубликовывать в своих Регламентах чужие OIDы без предварительного согласования с владельцем. Так же как и не призываю Вас использовать пиратское программное обеспечение. Это одного уровня проблемы. Особенно если чужой OID - это OID от конкурента :-) Просто придумайте свой с тем же смыслом. Вот и все... | ||||
Александр