Ключевое слово в защите информации
КЛЮЧЕВОЕ СЛОВО
в защите информации
Получить ГОСТ TLS-сертификат для домена (SSL-сертификат)
Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Icon
Error

Опции
К последнему сообщению К первому непрочитанному
Offline Ananda  
#1 Оставлено : 15 июня 2009 г. 22:26:37(UTC)
Ananda

Статус: Участник

Группы: Участники
Зарегистрирован: 15.06.2009(UTC)
Сообщений: 11
Мужчина
Откуда: г.Москва

Уважаемые специалисты!

Просмотрел вроде бы все темы, которые есть в разделе "Общие вопросы", и не нашел интересующей меня информации, поэтому решил обратиться к знатокам ЭДО.

Если использовать ЭЦП для организации обмена электронными документами между разными хояйствующими субъектами, то возникает несколько вопросов, а именно:

1. Как следует из федерального закона "Об ЭЦП", для юридической значимости электронного документа мало корректности самой ЭЦП (положительный результат проверки, сертификат действующий). Нужно, чтобы правовые отношения, к которым относится ЭД, соответствовали сведениям об отношениях, которые указаны для соответствующего СКП. Есть ли какие-то рекомендации относительно определения сведений об этих отношениях (то, что в КриптоПРО зовется областью использования сертификата и заносится в атрибут ExtendedKeyUsage СКП)?
Кстати, почему по формированию идентификатора области использования СПК дается ссылка на RFC 1098 (см. ЖТЯИ.00035-01 90 13, разделы 1 и 3)? Описание структуры и идентификации информации управления рассматривается в RFC 1155 (бывший RFC 1065); полдня искал, чтобы разобраться.

2. Каким образом с использованием средств КриптоПРО (в т.ч. через API) можно контролировать область использования сертификата? Или предлагается контролировать ее "глазками"?

3. Если скачать корневые сертификаты УЦ КриптоПРО, то можно увидеть в ряде полей (Алгоритм подписи, Открытый ключ) идентификаторы объектов, которые начинаются с 1.2.643.2.2. Вместе с тем, в соответствии с RFC 1155 для корня iso(1) допускается только ветка org(3), т.е. 1.3.х.х.х. С чем связано расхождение со стандартом и что оно означает? Если это не расхождение, то в соответствии с каким стандартом эти идентификаторы сформированы?

4. В теме "Как обеспечить юридическую силу ЭЦП в электронном документе?" к сжалению ничего не сказано про то, что всем лицам, участвующим в ЭДО, должны быть выданы доверенности, уполномачивающие их на подписание соответствующих документов (как в бумажном, так и в электронном виде). Можно более подробно раскрыть этот вопрос?

С уважением,
Владимир Андреев.
С уважением,
Владимир Андреев.
Offline Юрий Маслов  
#2 Оставлено : 16 июня 2009 г. 13:16:30(UTC)
Юрий Маслов

Статус: Активный участник

Группы: Администраторы
Зарегистрирован: 29.12.2007(UTC)
Сообщений: 1,036
Мужчина
Откуда: КРИПТО-ПРО

Поблагодарили: 36 раз в 25 постах
Здравствуйте, Владимир!

1. В своем продукте ПАК "КриптоПро УЦ" мы реализовали определение сведений об отношениях, при которых ЭД имеет юридическую силу, в СКП двуми способами: с использованием EKU и CertificatePolicies. Какой выбрать? Это решать Вам!

2. На стороне клиента из наших продуктов работает СКЗИ "КриптоПро CSP". Это криптопровайдер и он знать не знает о СКП, ЭЦП и бизнес-логики приложения. Поэтому контролировать область использования программно можно только на уровне приложения. Наиболее удобно работать с EKU, т.к. эти области использования из сертификатов можно получить, например, с помощью CAPICOM. С CertificatePolicies сложнее т.к. Вам самим придется писать прогу, что бы добраться до значения в этом расширении СКП.

3. Рекомендуем ознакомиться с RFC 4490 "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)" и RFC 4491 "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile".

4. А что за вопрос, который Вы просите раскрыть? Доверенности должны выдаваться. Вопрос, кому их сдавать :-) Можно и в УЦ, можно и организатору системы. Это дело индивидуальное. Кстати, обсуждался тут http://www.cryptopro.ru/...t.aspx?g=posts&t=823 и где-то ещё на на нашем форуме.
Если Вы заглянете в наш прейскурант цен http://www.cryptopro.ru/cryptopro/buy/price.htm то увидите, что мы оказываем информационно-консультационные услуги по разработке документов, обеспечивающих применение ЭЦП.
С уважением,
КРИПТО-ПРО
Offline Ananda  
#3 Оставлено : 18 июня 2009 г. 17:13:47(UTC)
Ananda

Статус: Участник

Группы: Участники
Зарегистрирован: 15.06.2009(UTC)
Сообщений: 11
Мужчина
Откуда: г.Москва

Здравствуйте, Юрий!

Юрий Маслов написал:
1. В своем продукте ПАК "КриптоПро УЦ" мы реализовали определение сведений об отношениях, при которых ЭД имеет юридическую силу, в СКП двуми способами: с использованием EKU и CertificatePolicies. Какой выбрать? Это решать Вам!

2. На стороне клиента из наших продуктов работает СКЗИ "КриптоПро CSP". Это криптопровайдер и он знать не знает о СКП, ЭЦП и бизнес-логики приложения. Поэтому контролировать область использования программно можно только на уровне приложения. Наиболее удобно работать с EKU, т.к. эти области использования из сертификатов можно получить, например, с помощью CAPICOM. С CertificatePolicies сложнее т.к. Вам самим придется писать прогу, что бы добраться до значения в этом расширении СКП.

Понятно. А можете дать ссылку на документацию по EKU и CertificatePolicies?

Юрий Маслов написал:
3. Рекомендуем ознакомиться с RFC 4490 "Using the GOST 28147-89, GOST R 34.11-94, GOST R 34.10-94, and GOST R 34.10-2001 Algorithms with Cryptographic Message Syntax (CMS)" и RFC 4491 "Using the GOST R 34.10-94, GOST R 34.10-2001, and GOST R 34.11-94 Algorithms with the Internet X.509 Public Key Infrastructure Certificate and CRL Profile".

Ознакомился.

В этих RFC речь идет об использовании алгоритмов GOST для формирования ЭЦП. У меня же вопрос был про то, каким документом регулируется построение идентификатора объекта (OBJECT IDENTIFIER) по схеме: iso(1) member-body(2) ru(643) и т.д? Где описываются правила построения этих веток?

В RFC 3061 в разделе "Process of identifier assignment" указывается, что есть "1.3.6.1.4.1 - IANA-assigned company OIDs, used for private MIBs and such things". Откуда тогда берется ветка идентификаторов iso(1) member-body(2) ru(643)?

Юрий Маслов написал:
4. А что за вопрос, который Вы просите раскрыть? Доверенности должны выдаваться. Вопрос, кому их сдавать :-) Можно и в УЦ, можно и организатору системы. Это дело индивидуальное. Кстати, обсуждался тут http://www.cryptopro.ru/...t.aspx?g=posts&t=823 и где-то ещё на на нашем форуме.

Понятно.

Просто у нас в организации при обсуждении ЭДО возникла мысль давать доверенность только на "подписание ЭЦП электронных документов". То есть не доверенность на право подписи документов (бумажных вообще и электронных в частности), а только доверенность только на наложение ЭЦП сотрудника на электронный документ, соответствующий бумажному документу, подписанному другим лицом (наример, руководителем).

Лично меня в этом подходе смущает то, что целью 1-ФЗ "Об ЭЦП" является "обеспечение правовых условий использования электронной цифровой подписи в электронных документах, при соблюдении которых электронная цифровая подпись в электронном документе признается равнозначной собственноручной подписи в документе на бумажном носителе". Т.е. бумажном документе (если он есть) и электронный документ должен быть подписан одним и тем же лицом, который имеет на это полномочия (эти полномочия и указываются в сертификате ключа подписи как сведения об отношениях ...).

Можете прокомментировать такой подход в части правовых рисков?

С уважением,
Владимир Андреев.
С уважением,
Владимир Андреев.
Offline Юрий Маслов  
#4 Оставлено : 18 июня 2009 г. 18:27:35(UTC)
Юрий Маслов

Статус: Активный участник

Группы: Администраторы
Зарегистрирован: 29.12.2007(UTC)
Сообщений: 1,036
Мужчина
Откуда: КРИПТО-ПРО

Поблагодарили: 36 раз в 25 постах
Ananda написал:
Понятно. А можете дать ссылку на документацию по EKU и CertificatePolicies?


Документации "по EKU и CertificatePolicies" я не встречал. Есть RFC 3280 и есть эксплуатационная документация на ПАК "КриптоПро УЦ".

Ananda написал:
В этих RFC речь идет об использовании алгоритмов GOST для формирования ЭЦП. У меня же вопрос был про то, каким документом регулируется построение идентификатора объекта (OBJECT IDENTIFIER) по схеме: iso(1) member-body(2) ru(643) и т.д? Где описываются правила построения этих веток?

В RFC 3061 в разделе "Process of identifier assignment" указывается, что есть "1.3.6.1.4.1 - IANA-assigned company OIDs, used for private MIBs and such things". Откуда тогда берется ветка идентификаторов iso(1) member-body(2) ru(643)?


А вот по этому вопросу я рекомендую Вам написать письмо с вопросом на support@cryptopro.ru. Ибо наши технические специалисты эту ветку форума уже не читают, так тут перемешалось всё: и правовые вопросы и технические :-) А на ВАше письмо ответят соответствующие гуру...

Ananda написал:
Просто у нас в организации при обсуждении ЭДО возникла мысль давать доверенность только на "подписание ЭЦП электронных документов". То есть не доверенность на право подписи документов (бумажных вообще и электронных в частности), а только доверенность только на наложение ЭЦП сотрудника на электронный документ, соответствующий бумажному документу, подписанному другим лицом (наример, руководителем).

Лично меня в этом подходе смущает то, что целью 1-ФЗ "Об ЭЦП" является "обеспечение правовых условий использования электронной цифровой подписи в электронных документах, при соблюдении которых электронная цифровая подпись в электронном документе признается равнозначной собственноручной подписи в документе на бумажном носителе". Т.е. бумажном документе (если он есть) и электронный документ должен быть подписан одним и тем же лицом, который имеет на это полномочия (эти полномочия и указываются в сертификате ключа подписи как сведения об отношениях ...).

Можете прокомментировать такой подход в части правовых рисков?


Вас правильно смущает. Не всё ли равно, в какой форме документ, на бумажном или в электронной форме? От этого суть отношений или фактов финансово-хозяйственной деятельности, которые документ фиксирует, не меняется. Поэтому правомочность субъекта, подписавшего документ, должна быть определена.
Если выдать доверенность только на "подписание ЭЦП электронных документов" сотруднику организации, то он может подписывать ЛЮБЫЕ электронные документы, даже если он не имеет права подписывать аналогичные по содержанию документы оформленные на бумаге. Это значит, что контрагент (лицо, принимающее к исполнению и/или к сведению электронный документ, удостоверенный ЭЦП) вправе и должен затребовать документы, подтверждающие право подписи (с применением ЭЦП или собственноручно) такого типа документа. И что? Будете контрагенту отсылать заверенные копии: устава, приказа о назначении, доверенность и т.д. Зачем тогда этот электронный документооборот, который должен повышать эффективность деятельности, оптимизировать бизнес-процессы и т.д. ? Вот поэтому и нужно в СКП заносить информацию о конкретных полномочиях владельца сертификата. Эти сведения должны подтверждаться соответствующей доверенностью в бумажной форме, представляемую или в УЦ или организатору системы (который ,в свою очередь, подтверждает факт получения и информирует УЦ).

Моё мнение: давать доверенность только на "подписание ЭЦП электронных документов" - это всё равно, что никаких доверенностей нет!
С уважением,
КРИПТО-ПРО
Offline Sergey M. Murugov  
#5 Оставлено : 18 июня 2009 г. 18:27:47(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Извините что вмешиваюсь, однако мне кажется, что основная задача УЦ – это идентификация субъектов обмена и указание в сертификате чего либо ещё – ролевых признаков просто неудачная формулировка ФЗ-1, что и понятно, поскольку совершенно не технологично разрешаются ситуации замещения должностей, отпуска, болезни сотрудников, т.е. все то что разруливается приказами в отделе кадров на работе и по идее все это не имеет отношения к ФЗ-1 и УЦ. Но поскольку в ФЗ-1 Ст. 6 п.1 все же есть эта фраза «… об сведеньях в отношении …» и глубина детализации слава богу не определена, то вполне достаточно указать в политике например вот так: «Целостность и авторство (включая неотрекаемость автора) данных, используется при защите электронных документов и сообщений. Данная политика не детализирует правомочность владельца сертификата вырабатывать ЭЦП на конкретном электронным документе, выступая лишь признаком идентификационного элемента субъекта гражданскоправовых взаимоотношений и выполнения должностных обязанностей в соответствии с действующим законодательством.» Т.с. развести в сторону вопросы идентификации и роли конкретного субъекта в конкретный момент времени в конкретной ситуации. Например, в рамках конкретной ИС её организатор детализирует полномочия и навешивает на субъекта всю необходимую информацию, например, ИНН для ФНС, номер страховки для ПФ ...... но иными способами и технологиями (и такие технологии есть и работают), нежели указание всего этого в СКП.
А в части должностных обязанностей организация ведет актуальный (+ история) реестр должностей из которых вытекают права и обязанности. А это означает, повторюсь, элегантное решение проблем болезни, отпуска, замещения сотрудников на работе и все это без переиздания сертификата ключа подписи :-)
При любых разборах полетов, все прозрачно, кто на основании чего что делал и где это зафиксировано.
Offline Юрий Маслов  
#6 Оставлено : 18 июня 2009 г. 19:04:46(UTC)
Юрий Маслов

Статус: Активный участник

Группы: Администраторы
Зарегистрирован: 29.12.2007(UTC)
Сообщений: 1,036
Мужчина
Откуда: КРИПТО-ПРО

Поблагодарили: 36 раз в 25 постах
Sergey M. Murugov написал:
Извините что вмешиваюсь, однако мне кажется, что основная задача УЦ – это идентификация субъектов обмена и указание в сертификате чего либо ещё – ролевых признаков просто неудачная формулировка ФЗ-1, что и понятно, поскольку совершенно не технологично разрешаются ситуации замещения должностей, отпуска, болезни сотрудников, т.е. все то что разруливается приказами в отделе кадров на работе и по идее все это не имеет отношения к ФЗ-1 и УЦ. Но поскольку в ФЗ-1 Ст. 6 п.1 все же есть эта фраза «… об сведеньях в отношении …» и глубина детализации слава богу не определена, то вполне достаточно указать в политике например вот так: «Целостность и авторство (включая неотрекаемость автора) данных, используется при защите электронных документов и сообщений. Данная политика не детализирует правомочность владельца сертификата вырабатывать ЭЦП на конкретном электронным документе, выступая лишь признаком идентификационного элемента субъекта гражданскоправовых взаимоотношений и выполнения должностных обязанностей в соответствии с действующим законодательством.» Т.с. развести в сторону вопросы идентификации и роли конкретного субъекта в конкретный момент времени в конкретной ситуации. Например, в рамках конкретной ИС её организатор детализирует полномочия и навешивает на субъекта всю необходимую информацию, например, ИНН для ФНС, номер страховки для ПФ ...... но иными способами и технологиями (и такие технологии есть и работают), нежели указание всего этого в СКП.
А в части должностных обязанностей организация ведет актуальный (+ история) реестр должностей из которых вытекают права и обязанности. А это означает, повторюсь, элегантное решение проблем болезни, отпуска, замещения сотрудников на работе и все это без переиздания сертификата ключа подписи :-)
При любых разборах полетов, все прозрачно, кто на основании чего что делал и где это зафиксировано.

Уважаемый Сергей!
Не в ту степь пошли, однако. Ваше решение ещё хуже, чем мысли в организации, сотрудником которой является Ananda (Владимир Андреев).
Повторяю, контрагент не примет документ (электронный или бумажный) если не подтверждена правомочность лица, чья подпись стоит в документе!!! Поэтому, правомочность нужно доказывать. При заключении договоров в традиционной бумажной форме, с нас требуют эти документы, подтверждающие правомочность. Если, Сергей, Вы не заключали договоров, то Вам это возможно неизвестно. Я не скажу, что все поголовно контрагенты требуют эти документы. Но более или менее солидная организация такое требует. Мы заключаем порядка 1500 договоров в год. Из них порядка 300 требуют с нас заверенные копии документов, подтверждающие правомочность. И это правильно!!!! Поэтому в Вашей схеме до разбора полетов просто не дойдет, потому что договор заключен не будет! :-))) Или Вам придется каждому контрагенту высылать кипу заверенных копий. Да нафиг нужен такой электронный документооборот!
А хуже Ваше решение тем, что предложенная Вами формулировка увеличит риск непринятия документа в качестве доказательства, т.к. черным по белому написано "не детализирует правомочность владельца сертификата вырабатывать ЭЦП", что трактуется как отсутствие правомочности. Что не указано, то не разрешено! Это я перефразировал пессимистическую гипотезу, на которой основывается криптография.
С уважением,
КРИПТО-ПРО
Offline Sergey M. Murugov  
#7 Оставлено : 18 июня 2009 г. 19:08:35(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
В догонку к вышесказанному, мы эту проблему пытались приподнять аж в начале 2008 года и даже была статейка наша напечатана в "Information Security/Информационная безопасность" (http://www.top-cross.ru/Company/InfoSec-6_2007_Page_44.pdf и http://www.top-cross.ru/...oSec-6_2007_Page_45.pdf) а вот её же интерпретация в польском журнале от конца 2008 года - http://www.top-cross.ru/...orld_PKI_2008-12-09.pdf.

Так что проблема не нова и существует её гибкое решение.
Offline Юрий Маслов  
#8 Оставлено : 18 июня 2009 г. 19:19:22(UTC)
Юрий Маслов

Статус: Активный участник

Группы: Администраторы
Зарегистрирован: 29.12.2007(UTC)
Сообщений: 1,036
Мужчина
Откуда: КРИПТО-ПРО

Поблагодарили: 36 раз в 25 постах
Sergey M. Murugov написал:
В догонку к вышесказанному, мы эту проблему пытались приподнять аж в начале 2008 года и даже была статейка наша напечатана в "Information Security/Информационная безопасность" (и ) а вот её же интерпретация в польском журнале от конца 2008 года -

Так что проблема не нова и существует её гибкое решение.


Большая просьба, не давать ссылки на свои корпоративные ресурсы. Если ссылаетесь на статью в СМИ, то ссылку давать на ресурс СМИ.

Отредактировано пользователем 18 июня 2009 г. 19:19:55(UTC)  | Причина: Не указана

С уважением,
КРИПТО-ПРО
Offline Sergey M. Murugov  
#9 Оставлено : 18 июня 2009 г. 19:23:57(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Приношу извинения, но по другому не получается, поскольку польского ресурса у меня просто нет, а на сайте Информационной безопасности все журналы лежат в iMag (http://www.itsec.ru/imag.php) - это фактически заставлять ваших пользователей рыться во всей этой куче информации. Подчеркиваю, не в коем случае не рассматривайте эти ссылки как рекламу нашей компании - был представлен чисто инженерный взгляд на проблему.
Offline Sergey M. Murugov  
#10 Оставлено : 18 июня 2009 г. 19:31:19(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
А теперь по существу отвечу, Юрий - вы совершенно не правы, я не говорил что не надо подкладывать документы подтверждающие полномочия, я только сказал, что указание полномочий именно в СКП ОЧЕНЬ не удачная идея. На практике при выработке ЭЦП в совершенно стандартное место (список сертифкатов) самой ЭЦП укладывается атрибутник с ролью определенной должностными инструкциями. И реестр должностных полномочий ведет именно юрлицо от имени которого идет информационный обмен. К слову, у меня на руках ID-card которые я получил в Польше и Эстонии в их квалифицированных УЦ, так вот там нет никаких полномочий - и так работает весь мир, кроме нас разумеется :-)
Offline Юрий Маслов  
#11 Оставлено : 18 июня 2009 г. 21:05:24(UTC)
Юрий Маслов

Статус: Активный участник

Группы: Администраторы
Зарегистрирован: 29.12.2007(UTC)
Сообщений: 1,036
Мужчина
Откуда: КРИПТО-ПРО

Поблагодарили: 36 раз в 25 постах
Сергей! Не надо лукавить. В Польше и в Эстонии сделана целая инфраструктура на государственном и частном уровне, обеспечивающая такую схему применения ЭЦП: законы, подзаконные акты, предприятия, техническая и программная инфраструктура ведения реестров владельцев ID-card и поддержки ID-card на рабочих местах. Это десятки и десятки миллионов долларов было потрачено.
В России этой инфраструктуры нет. Действующее законодательство РФ не позволяет её применять. А Вы предлагаете уважаемому г-ну Ananda (Владимир Андреев) и его организации самостоятельно всё это построить и поднять? Да Вы садист и утопист! :-)
Для начала, Сергей, измените действующее законодательство, сложите бизнес-практику и судебную практику, практику рассмотрения электронных документов с "вашими ЭЦП" в налоговой, МВД, прокуратуре, а вот потом двигайте новые технологии :-))))))

Поэтому, Сергей, мы обсуждаем вопросы не теоретические "ах как было бы здорово если бы", а вопросы, как реализовать применение ЭЦП в действующем правовом поле и имеющейся (точнее отсутствующей) государственной инфраструктурой обеспечения применения ЭЦП.

Я не спорю, решения с атрибутными сертификатами или государственными реестрами держателей сертификатов и их правомочности, являются красивыми и грамотными. Но... мы имеем то, что мы имеем. Т.к. это государственная задача и решить её способно только государство или очень богатый (синоним - влиятельный) спонсор. А такого нет ни у Вас, ни у нас :-(((
С уважением,
КРИПТО-ПРО
Offline Sergey M. Murugov  
#12 Оставлено : 18 июня 2009 г. 23:21:52(UTC)
Sergey M. Murugov

Статус: Активный участник

Группы: Участники
Зарегистрирован: 18.06.2008(UTC)
Сообщений: 230
Откуда: Москва

Сказал(а) «Спасибо»: 2 раз
Поблагодарили: 40 раз в 28 постах
Я не очень понял ответ, но слов много, спасибо :-)
Какую инфраструктуру строить, какие реесты, что глобально поднимать ??? Вы о чем? Есть сертификат - идентифицирующий субъекта, выданный УЦ причем любым лишь бы ему адресат верил, есть технология как не переделывая тыщу раз сертификат и не бегая все время в УЦ платя деньги каждый раз указать оперативно полномочия, есть совершенно стандартное место в ЭЦП куда укладывается блок (атрибутник) заверенный ЭЦП отдела кадров содержащий текущие полномочия - считай электронная доверенность с подписью. Все это с подписью и запросто парсится и проверяется. Какие реесты, подзаконные акты и т.п. у нас что есть подзаконный акт на формат CMS/PKCS#7 ???
По поводу Польши и Эстонии - карты у меня на столе лежат (могу сертификаты выложить) - боевые, хоть налоги по ней в поляндии плати. Там нет никаких привилегий !!! И ничего я не лукавлю. К слову все эти карты имеют по два слота - в первом только сертификат квалифицированный для ЭЦП, а во втором слоте, как они называют - для "опознавания" - т.е. для TLS и шифрования, до понимания этой тонкости нам ещё предстоит дорасти !
Offline Serge3leo  
#13 Оставлено : 19 июня 2009 г. 2:06:02(UTC)
Serge3leo

Статус: Активный участник

Группы: Участники
Зарегистрирован: 28.01.2008(UTC)
Сообщений: 40
Мужчина
Откуда: Москва

Поблагодарили: 3 раз в 2 постах
Здравствуйте Владимир,
Цитата:
Sent: Thursday, June 18, 2009 9:11 PM
To: support
Subject: Нормативный документ с правилами формирования OID
...
(см.первое и второе сообщение участника Ananda).
В первом сообщении - вопрос №3, а во втором сообщении - текст после второй цитаты.
...
Помогите разобраться, каким документом (RFC xxxx или ISO yyyy) регулируется присвоение OID

Присвоение OID регулируется стандартом на ASN.1: ISO/IEC 8824-1 (X.680).
Госстандарт России, как член ИСО/МЭК, принял его русский перевод ГОСТ Р ИСО/МЭК 8824-1-2001.

Там описано управление корнем, а так же веток iso(1) и iso(1) member-body(2), и даны соответствующие ссылки.

Цитата:
типа iso(1) member-body(2) ru(643)

Управляется уполномоченной членом ИСО/МЭК от РФ организацией. Честно говоря, мир не стоит на месте, сейчас я даже не знаю кто в РФ является членом ИСО/МЭК. "Дефакто" реестр OID iso(1) member-body(2) ru(643) ведёт Марина Игнатьева, по http://www.ctel.msk.ru/x500/OIDS/inform.htm доступен сам реестр и её почтовый адрес.

В этом деле традиционно непросто разобраться, т.к. ИСО и МЭК слились, а Госстандарт (бывший член ИСО) и Минсвязи (бывший член МЭК), насколько мне известно, нет. Зато реорганизовались и переименовались. :)
Цитата:
например 1.2.643.2.2?

А это наша ветка OID, смотри "Дополнительные услуги"

Отредактировано пользователем 19 июня 2009 г. 16:57:02(UTC)  | Причина: Не указана

Offline Serge3leo  
#14 Оставлено : 19 июня 2009 г. 2:30:26(UTC)
Serge3leo

Статус: Активный участник

Группы: Участники
Зарегистрирован: 28.01.2008(UTC)
Сообщений: 40
Мужчина
Откуда: Москва

Поблагодарили: 3 раз в 2 постах
Sergey M. Murugov написал:
в первом только сертификат квалифицированный для ЭЦП, а во втором слоте, как они называют - для "опознавания" - т.е. для TLS и шифрования, до понимания этой тонкости нам ещё предстоит дорасти !

Shhh
Только никому не говори.
http://tools.ietf.org/html/rfc4491#section-3, это конечно не догма, но соответствующая рекомендация указана.
Запамятовал наверное, а ты там в соавторах значишься, эх :(
Shhh

Отредактировано пользователем 19 июня 2009 г. 3:29:03(UTC)  | Причина: Не указана

Offline Ananda  
#15 Оставлено : 19 июня 2009 г. 2:34:02(UTC)
Ananda

Статус: Участник

Группы: Участники
Зарегистрирован: 15.06.2009(UTC)
Сообщений: 11
Мужчина
Откуда: г.Москва

Юрий Маслов написал:
Документации "по EKU и CertificatePolicies" я не встречал. Есть RFC 3280 и есть эксплуатационная документация на ПАК "КриптоПро УЦ".

Юрий, спасибо за наводку. Я заглянул в RFC 3280 и в разделе "Extended Key Usage" прочитал, что OID'ы для идентификации областей использования сертификатов регулируются документом ITU-R X.660. А уже в этом документе в приложении A доходчиво написано, как формируются OID'ы.

К слову сказать, раз уж начал, для организации, которая желает создть свое пространство OID'ов существуют две альтернативные схемы:
1) через iso(1) member-body(2) rus(643);
2) через iso(1) org(3) dod(6) internet(1) private(4) enterprise(1).

Если верить статье в Wiki, наиболее часто в природе встречаются OID'ы, присвоенные по второй схеме.

Дерево OID'ов можно посмотреть здесь (OID Repository). Из него, в частности, можно легко увидеть, что по первой схеме регистрирующей организацией для России является Российский сегмент мирового пространства идентификаторов объектов(перечень зарегистрированных организаций). Интересно, что в OID-Repository невозможно найти многие организации, отраженные в реестре Российского сегмента мирового пространства идентификаторов объектов. С чем это связано - не разбирался.

Также на сайте OID-Repository(здесь (OID Repository)) можно зарегистрировать (и т.о. опубликовать, если это нужно) OID'ы своей организации.

Итак, если вы захотите зарегистрировать ветку своих OID'ов в глоблальном пространстве имен вы можете воспользоваться как первой схемой (регистрирующая организация - Российский сегмент мирового пространства идентификаторов объектов), так и второй схемой (регистрирующая организация - IANA).

Вот так.
С уважением,
Владимир Андреев.
Offline Serge3leo  
#16 Оставлено : 19 июня 2009 г. 3:04:54(UTC)
Serge3leo

Статус: Активный участник

Группы: Участники
Зарегистрирован: 28.01.2008(UTC)
Сообщений: 40
Мужчина
Откуда: Москва

Поблагодарили: 3 раз в 2 постах
Ananda написал:
Если верить статье в Wiki, наиболее часто в природе встречаются OID'ы, присвоенные по второй схеме.

Насчёт чаще, не уверен, но, скажем так: их, вероятно, больше.

Ananda написал:
Интересно, что в OID-Repository невозможно найти многие организации, отраженные в реестре Российского сегмента мирового пространства идентификаторов объектов. С чем это связано - не разбирался.

Предполагаю, что им не требовалась эта публикация. Вероятно, им достаточно кросс-ссылки от 1.2.643.

Ananda написал:
Также на сайте OID-Repository(здесь (OID Repository)) можно зарегистрировать (и т.о. опубликовать, если это нужно) OID'ы своей организации.

Не зарегистрировать, но опубликовать уже зарегистрированный в соответствии с X.680 OID. В частности, они же не отвечают даже за уникальность.


iso(1) org(3) dod(6) - Минобороны США, эти ребята оторванные, некоторое время назад у них вообще была Web-морда для регистрации OID-а. :)

Хотя можно понять, в ветке для SNMP уже зарегистрировано несколько десятков тысяч "пользователей". Но хоть за уникальность они отвечают, тут вопросов нет.

Отредактировано пользователем 19 июня 2009 г. 3:26:58(UTC)  | Причина: Не указана

Offline Юрий Маслов  
#17 Оставлено : 19 июня 2009 г. 11:55:15(UTC)
Юрий Маслов

Статус: Активный участник

Группы: Администраторы
Зарегистрирован: 29.12.2007(UTC)
Сообщений: 1,036
Мужчина
Откуда: КРИПТО-ПРО

Поблагодарили: 36 раз в 25 постах
Ananda написал:
Итак, если вы захотите зарегистрировать ветку своих OID'ов в глоблальном пространстве имен вы можете воспользоваться как первой схемой (регистрирующая организация - Российский сегмент мирового пространства идентификаторов объектов), так и второй схемой (регистрирующая организация - IANA).

Вот так.

Владимир, а ещё в составе документации на "КриптоПро УЦ" есть документ "ЖТЯИ.00035-01 90 13. КриптоПро УЦ. Руководство по регистрации дополнительных идентификаторов областей применения сертификатов открытых ключей." :-)
С уважением,
КРИПТО-ПРО
Offline Ananda  
#18 Оставлено : 22 июня 2009 г. 16:31:14(UTC)
Ananda

Статус: Участник

Группы: Участники
Зарегистрирован: 15.06.2009(UTC)
Сообщений: 11
Мужчина
Откуда: г.Москва

Коллеги, спасибо всем за быстрые и точные ответы!
С уважением,
Владимир Андреев.
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.