Добрый день!

Для обмена электронными сообщениями использую Thunderbird 2.0.0.12.

С недавних пор появилась необходимость использовать цифровой сертификат для шифрования электронных сообщений. Сертификат был получен в удостоверяющем центре "КРИПТО-ПРО" (www.crypto-pro.ru).

Спецификацию этого сертификата не знаю, имеет расширение ".cer".
Он был разработан по одному из ГОСТов ФСБ России.
Они используются многими российскими корпорациями.

Но эти сертификаты не совместимы с Thunderbird. Тех. поддержка КРИПТО-ПРО это подтверждает.
Как я ни пытался, но использовать сертификат, полученный в КРИПТО-ПРО не получается.

Приходится для расшифровки сообщений, полученных от партнеров, использовать MS Outlook.

Когда Вы сможете включить поддержку таких сертификатов?

С уважением,
Вадим Лагутин.

molasar
это видимо баг 350193

Официальные сборки Mozilla не поддерживают российские стандарты шифрования. Используйте Outlook или The Bat!.

А когда будет поддерживать?
Ведь шифрование передачи данных - это стандарт применяемый при обмене информацией в бизнесе.
Или mozilla - это только для дома????

Вот поэтому и не будет поддерживать :-)

Российский ГОСТ - он, что - Библия или настольная книга всех разработчиков OpenSource?
Или наклейка "Made in FSB" - гарантия качества?

Я конечно извиняюсь, но чем хуже сертификаты выполненные по мировым технологиям и стандартам? Или ГОСТовские болmit нравятся ФСБ ?

То есть криптографический АПИ Микрософта в продуктах Мозиллы никогда поддерживаться не будет?
Это принципиальная позиция?
Тогда действительно только для дома ((.

Т.е. проблема необходимость юридически значимой ЭЦП в России приводит к выбору:
1. Использовать Микрософт во всем (такое уж у нас государство).
2. Написать свой OpenSource ГОСТовский криптопровайдер с интерфейсом к Мозилле.
3. Написать свой OpenSource интерфейс от Мозиллы до криптографического АПИ Микрософта
   (такие наработки, правда не OpenSource, велись).
4. Уехать за рубеж.

Да!

Нет.
Есть международные стандарты шифрования. Пока Ваш бизнес не принимает других стандартов и стандарты ГОСТа не стали более открытыми, Tb вам не будет подходить.

Ива

Скорее всего нет. Ничто не мешает добавить поддержку ГОСТов в криптографический модуль Mozilla, нужны лишь люди и деньги.

Государство не принимает, а бизнес понимает. Т.е. я могу верифицировать любые подписи. Но нет смысла верифицировать то, что не имеет юридических последствий. Если вы попробуете договор, подписанный электронно с использованием любых алгоритмов кроме ГОСТовских, предъявить в суд, то суд их просто не примет как доказательство.

ТВ замечательно подходит для частной переписки, но если в нем нельзя сделать юридически значимое письмо - он не подходит для бизнеса (по крайней мере того, который работает с электронными документами) в России.

Это можно рассматривать как проблему России, проблему ТВ или как проблему бизнес-пользователей в России, которые для реализации ЭЦП вынуждены отказаться от ТВ.

PS. Стандарты ГОСТа не закрыты. Или, по крайней мере, их можно найти.

http://gost4yuo.ru/_ld/20/2095_34.11-94.pdf
http://gost4yuo.ru/load/0-0-0-1018-20

Если проект Мозилла в России возьмет на себя реализацию ГОСТ в части проверки (не подписания!) ЭЦП - готов приобрести для рабочей группы по одному экземпляру официальных изданий ГОСТ 34.10-2001 и ГОСТ 31.11.-94.

Никто не предлагает Вам получать сертификат ФСТЭК или тем более ФСБ на реализацию алгоритмов (Т.е. подписать ничего нелья будет по-прежнему ). Но хоть увидеть наличие ЭЦП будет можно.

А то, что подписанное S/MIME по ГОСТ письмо последняя версия ТВ показывает как обычное - это безобразие. Намного корректнее было бы написать пользователю, что использован неизвестный алгоритм подписи (если вы не желаете реализовывать ГОСТ хотя бы в части проверки ЭЦП без возможности подписания).

Ива

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

Стандарты _любого_ криптоалгоритма (скорее уж не стандарты, а принцип работы) не закрыты. Учите матчасть. А что до ГОСТ, то без бумажки это не реализация, а еще какой-то алгоритм, похожий на него. + Не забываем на отсуствие четких требований по TLS.

Бред. Какой смысл от использования такой "пиратской" реализации? Давайте я вам бесплатно в NSS добавлю OID'ы от КриптоПро, их можно будет распечатать и повесить на стенку.

Т.е. ТВ начнет понимать подписанные по ГОСТУ сообщения? Мне кажется, того, что Вы предложили, будет недостаточно.

Про проблемы с ГОСТовскими подписями в суде я в курсе. Закон тоже читал. Однако легко понять, что для ГОСТовских алгоритмов перспективы признания есть, а для остальных - намного более туманные.

Лично для меня было бы достаточно, чтобы
1. ГОСТовский сертификат можно было бы поставить в хранилище ТВ, увидеть, что письмо подписано и проверить без установки Крипто про или другого платного криптопровайдера достоверность подписи (возможно, с уведомлением, что алгоритм не сертифицирован и для окончательной проверки следует воспользоваться сертифицированным ПО или обратиться в удостоверяющий центр за экспертизой).

2. или если будет работать интерфейс между криптографическим интерфейсом ТВ и Крипто про. Мне казалось, что это сложнее, но я могу заблуждаться в этом моменте.

Разумеется, подписывать несертифицированным софтом что-либо полный бред - я этого и не предлагал.

Просто дико выглядит - в Thе Bat, Outlook Express, MS Outlook письмо подписано, подпись проверяется. Заходим в ТВ - письмо ВООБЩЕ не имеет подписи . S/MIME уведомления, разумеется, в ТВ тоже не читаются, но здесь он хоть честно говорит, что не может расшифровать.

IMHO минимально необходимо, чтобы информация о наличии подписи и невозможности ее обработать обязательно доводилась до пользователя.

То, что не видно никакого следа S/MIME полность соответствующего ГОСТУ и RFC - это все же, согласитесь,  баг.

Ива

Естественно недостаточно. Но сам TB ничего не понимает - это делает NSS (криптобиблиотека, которую сейчас разрабатывает в-основном RedHat). Хотите, предложите им написать поддержку псевдогоста в виде отдельного PKCS#11 модуля. За деньги

Вы не поверите, это было бы достаточно в принципе Только вот без сертификации и доступа к документации от КриптоПро ничего не получится.

В корне заблуждаетесь - потому что TB ничего не знает про криптопровайдер от M$, который и патчит КриптоПро. Т.к. TB использует NSS.

Выглядит вполне нормально - все вышеперечисленные программы используют криптопровайдер от M$. Например, проверьте, как себя ведет Opera с такими письмами, 100% она тоже впадает в ступор. Еще раз - для того чтобы было счастье нужно добавлять поддержку ГОСТ в NSS + патчить саму NSS чтобы она понимала все выверты и извраты над RFC, которые придумал КриптоПро (например, формат контейнера для хранения закрытого ключа).

Она вам и доносится, что нельзя разшифровать %) А что у КриптоПро SMIME кривой это не TB виноват.

PS Я бы вам посоветовал обратиться к КриптоПро за разъяснениями - почему они так любят M$, если работают на военных, и где их хваленная надстройка для NSS, которую они обещали "вот-вот" реализовать еще 3 года назад.

А сколько? Боюсь частному лицу это не очень то по карману

Не совсем. Сведения доводятся только об уведомлениях S/MIME. Никаких сведений о письме вообще нет.

Т.Е. чтобы проверить не подписа но ли письмо но ГОСТ я, теоретически, вынужден каждый раз смотреть исходный код письма и глазами искать контейнер S/MIME.

Реализовали, сдали и забыли.

Не пойму, чего во внешнем виде этого S/MIME нестандартного. Самый минимум - не надо даже ключей и сертификатов доставать, просто сказать - "письмо подписано, стандарт такой-то - разбирайтесь сами"

MS OUTLOOK 2003 + ГОСТ
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=gostr3411-94;
    boundary="----=_NextPart_000_0009_01C8D636.D4BCA510"
------=_NextPart_000_0009_01C8D636.D4BCA510
Content-Type: multipart/mixed;
    boundary="----=_NextPart_001_000A_01C8D636.D4BCA510"
------=_NextPart_001_000A_01C8D636.D4BCA510
------=_NextPart_001_000A_01C8D636.D4BCA510
------=_NextPart_001_000A_01C8D636.D4BCA510--
------=_NextPart_000_0009_01C8D636.D4BCA510
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
------=_NextPart_000_0009_01C8D636.D4BCA510--

Thunderbird 2.0.0.6
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1;
        boundary="------------ms040002000807090804070200"
--------------ms040002000807090804070200
Content-Type: multipart/mixed;
boundary="------------030507010205050803040802"
--------------030507010205050803040802
--------------030507010205050803040802
--------------030507010205050803040802--
--------------ms040002000807090804070200
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
--------------ms040002000807090804070200--

"Content-Description header field. This header field is always optional" - так что единственная разница в поле micalg, что неизбежно, поскольку алгоритм другой.

Ива

Много + Деньги на сертификацию, если потом заходите это внедрить в документооборот.

Чтобы понять, какой это стандарт, надо отпарсить этот блоб, чтобы отпарсить, надо знать структуру.

PS Если интересно, я могу подкинуть адреса нескольких контор, у которых есть реализации TB с поддержкой ГОСТ'ов, но они пока не сертифицированы и закрыты.

А проверить наличие

и сказать, что "письмо подписано по ГОСТ - проверяйте другим софтом", нельзя?
Без разборки smime.p7s вообще.

PS. OE при генерации заголовков S/MIME делает ошибку и вместо micalg=gostr3411-94 пишет micalg=sha1. Так здесь ТВ чудно все видит и говорит, что подпись проверить нельзя (что понятно, поскольку smime.p7s, разумеется, остается с ГОСТовским содержимым). Может можно сделать так, чтобы реакция при micalg=gostr3411-94 была бы аналогичная?

Ива

А если очередной придурочный клиент напишет в micalg еще какую-нить ересь? Тупо ей доверять?

IMHO я не думаю, что ГОСТЫ по разу в год будут менять. А раз в 5 лет и добавить можно .

Кроме того, я не предлагаю тупо доверять тому, что написано в micalg=.

Я предлагаю сказать при обнаружении любой нестандартной записи в micalg=, что "сообщение, скорее всего, подписано неизвестным алгоритмом". И все!

Меня крайне напрягает возможность принять юридически значимое сообщение с ГОСТовской ЭЦП за обычное неподписанное.

IMHO если в письме есть S/MIME (не важно - обычный или ГОСТ) - так скажите пользователю об этом, не скрывайте инфу!

Что касается вопроса про S/MIME и уведомление пользователя о наличии его как такового, и как следствие, о возможном наличии ЭЦП.

Мои доводы оказались неубедительными полностью и бесповоротно ?

Или отсутствие ответов со стороны Администрации говорит о продолжающемся анализе ситуации (переговорах и т.п.)?

Ива
patches are welcome. Хотя лично я не вижу смысла в таком уведомлении "что тут у вас какой-то алгоритм, только мы его не будем парсить, потому что не знаем что это ваще такое".

Добавлено Mon Jul  7 22:54:50 2008 :

лично меня крайне напрягает отсутствие законодательной базы для работы с ЭЦП и доверенной третьей стороны.

lakostis
отсутствие законодательной базы ... и доверенной третьей стороны меня тоже напрягают.

Но некоторые законы РФ требуют определять формы и способы передачи документов с ЭЦП от меня уже сейчас. Как сказал мой коллега "закон есть, порядка пока нет".

Про patches are welcome я основательно подумаю. А чем собирается (можно собрать) ТВ для Windows?

Ива

http://developer.mozilla.org/en/docs/Bu … umentation

Express Edition подходит, или обязательно полный нужен?

Ива
Подходит