Доброго времени суток.
В приказе ФСБ 795 с новыми требованиями к сертификатам есть ряд интересных пунктов, которые вызывают вопросы. Прошу подсказать, как же их разрешить.
Ситуация: на стороне клиента (изолированного от сети) создаём ключевую пару и PKCS10-файл запроса. Затем на стороне УЦ обрабатываем этот запрос. Задача: создать квалифицированный сертификат.

Итак, согласно приказу в сертификате должны присутствовать:

1. Certificate Policies
Туда нужно загнать OID(ы), соответствующий(ие) классу защиты СКЗИ на клиенте (КС1, КС2 и т.п). Отлично, с удовольствием впишем их в запрос сертификата, но как узнать этот класс программным способом? Есть ли какая-нибудь API-функция? Не спрашивать же об этом пользователя, он может просто не знать. Или этот OID должен вписываться не на стороне клиента в PKCS10, а на стороне УЦ при выпуске сертификата? Но откуда сам УЦ узнает класс защиты на клиентской стороне?

2. Новое расширение SubjectSignTool.

То есть нужно вписать название СКЗИ, используемого клиентом. Это прекрасно, но в каком виде его писать? Стандартная API-функция возвращает вот такое имя: "Crypto-Pro GOST R 34.10-2001 Cryptographic Service Provider" - прямо вот это в запрос и писать? В примерах квалифицированных сертификатов написано гораздо более доброе: "КриптоПро CSP" (версия 3.6). Регламентировано ли название всех СКЗИ и их версий для этого расширения? И опять-таки нужно ли это делать на стороне клиента в PKCS10 или сам УЦ должен "угадать" название использованного СКЗИ? Хотя слово "Subject" в слове SubjectSignTool намекает, что всё же на стороне клиента оно должно заполняться. А если клиент в будущем поставит себе новое СКЗИ, какой-нибудь КриптоПро 4.0, то упс, в сертификате окажется ложь? :)

3. Новое расширение IssuerSignTool.
Из названия следует, что это расширение должно добавляться на стороне УЦ, то есть в файле PKCS10 ему не место. Но давайте посмотрим, что там есть внутри.

3.1 signTool

То есть в моём случае это то же самое СКЗИ у клиента. Тут все вопросы те же, что и в пункте 2

3.2 signToolCert

Вот это самое интересное! Сюда нужно написать реквизиты лицензии ФСБ на СКЗИ у клиента. Разрази меня Брюс Шнайер, где же их взять? Если я должен вписать их на стороне клиента в PKCS10-файл, то как я их программно могу спросить, какое API мне их даст? А если это должен делать УЦ, то как он угадает эти реквизиты?

Что ж, на самый худой вариант можно попробовать в реестр за этой строкой слазить и её распарсить, но это по-моему чудовищный изврат. Наверняка должен быть более простой и удобный способ. Хотя ситуация осложняется ещё и тем, что для создания ключей не всегда можно использовать Windows API. В комнатах ОКЗ, изолированных от внешнего мира, для создания ключей используется простая веб-форма, работающая на стандартных ActiveX-компонентах CertEnroll/XEnroll. Можно ли с их помощью выяснить класс защиты СКЗИ?.. едва ли.


Я нисколько не сомневаюсь в том, что рано или поздно эта лицензия от ФСБ будет получена. Мой вопрос в другом: когда лицензия уже будет существовать, как извлечь её реквизиты? Допустим вначале будет всего один лицензированный дистрибутив, тогда реквизиты можно грубо зашить как константу, но когда таких дистрибутивов станет несколько, с разными реквизитами лицензий, как их вычислять? И чья сторона должна это делать: клиента или УЦ?

А как насчет информации в сертификате УЦ?
Заранее же известно, в какой УЦ будет отправлен запрос на сертификат
+ сам УЦ при издании сертификата заполнит сведения о своих средствах ЭП.

Например, в УЦ КриптоПРО




В каком ПО создается запрос? В своем?
Известен же выбранный криптопровайдер\контейнер и т.д.
+ в самом запросе (от КриптоПРО CSP) есть OID enrolmentCSP - т.е. явно можно узнать, что это не ViPNet или другой CSP

Пример:

Отредактировано пользователем 10 декабря 2012 г. 21:09:28(UTC)  | Причина: Не указана

Андрей, Вадим, спасибо за ответы.

Согласен, что технически вероятно можно найти способы по включению упомянутой информации. Гораздо интересней, как ее истолковать и как интерпретировать сами требования ФСБ.

Читаем:

"29. Для указания в квалифицированном сертификате наименования используемого владельцем квалифицированного сертификата средства ЭП должно использоваться некритичное дополнение subjectSignTool типа UTF8String SIZE(1..200), объектный идентификатор которого имеет вид 1.2.643.100.111."

Используемого где? когда? При наложении электронной подписи? Но я могу использовать свой ключ и сертификат при работе в нескольких информационных системах или средах, никто мне этого не запрещает (если не прописано в сертификате). С использованием одного и того же ключа и сертификата я, как физическое лицо, могу подписывать документы и в профильной корпоративной информационной системе, и в системе электронного документооборота внутри организации, и в открытой информационной системе госуслуг, если это позволяет область использования сертификата, а как известно, ограничения на использование носят необязательный характер, следовательно, могут отсутствовать, и тогда никто не может запретить или ограничить свободу использования сертификата в нескольких системах и возможность формирования подписи на разных компьютерах. И во всех перечисленных системах, как и на разных компьютерах, может быть установлена и поддерживаться абсолютно разная криптография. Каков тогда смысл указанного дополнения? Не бессмысленен ли он? Откуда издатель, да хоть и составить запроса, может знать, какими средствами ЭП будет пользоваться владелец сертификата в течении всего срока его действия. А даже если бы и знал, неужели включать в сертификат все возможные средства, которые он будет использовать? И что делать, если эти средства не совпадают? Как расценивать такую ситуацию? Будет ли считаться квалифицированной подпись (при соблюдении прочих условий квалифицированности), сформированная с использованием сертификата, в котором указанный subjectSignTool не совпадает с криптосредством, использованным при формировании данной конкретной подписи? Это очень важный вопрос. Если нет, то subjectSignTool носит критичный, ограничивающий характер. Однако в самих Требованиях лично я такой трактовки не вижу.

"30. Для указания в квалифицированном сертификате наименования средств ЭП и средств аккредитованного УЦ, которые использованы для создания ключа ЭП, ключа проверки ЭП, квалифицированного сертификата, а также реквизитов документа, подтверждающего соответствие указанных средств требованиям, установленным законодательством РФ, должно использоваться некритичное дополнение issuerSignTool типа IssuerSignTool"

При генерации ключевой пары и формировании запроса на сертификат на стороне клиента для создания ключа ЭП и ключа проверки ЭП используется средство ЭП владельца сертификата, а не средство ЭП УЦ. С какой стати его наименование должно включаться в issuerSignTool, по одному наименованию которого ясно, что речь идет о средствах ЭП УЦ. Логичнее было бы включать его в subjectSignTool. Но там уже находится средство ЭП, "используемое владельцем квалифицированного сертификата" (см. первую часть оды). А вот средство ЭП, "которое было использовано для создания ключа ЭП, ключа проверки ЭП", должно быть включено в issuerSignTool, хотя в УЦ может быть установлено совершенно другое средство ЭП, нежели у владельца сертификата. Сюда же относятся все остальные вопросы по поводу IssuerSignTool из самого первого поста данной ветки.

Я конечно повторяюсь. Wissenkrieger в начале беседы уже все это озвучил. Но чем больше я пытаюсь найти ответы, тем больше понимаю, что ответов, по всей видимости, нет. Отсюда традиционный русский вопрос: "Что делать?". С двумя другими традиционными русскими вопросами более менее ясно.