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

Уведомление

Icon
Error

2 Страницы12>
Опции
К последнему сообщению К первому непрочитанному
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 которые я получил в Польше и Эстонии в их квалифицированных УЦ, так вот там нет никаких полномочий - и так работает весь мир, кроме нас разумеется :-)
RSS Лента  Atom Лента
Пользователи, просматривающие эту тему
Guest
2 Страницы12>
Быстрый переход  
Вы не можете создавать новые темы в этом форуме.
Вы не можете отвечать в этом форуме.
Вы не можете удалять Ваши сообщения в этом форуме.
Вы не можете редактировать Ваши сообщения в этом форуме.
Вы не можете создавать опросы в этом форуме.
Вы не можете голосовать в этом форуме.