Вопросы по составу сертификатов физ лиц на новом ГОСТ 34.10-2015

#1

Добрый день,

Выпустил себе сертификат на ГОСТ 34.10-2015 по инструкции https://pki.gov.kz/docs/guides_ru/lk_fl/#3410-2015, есть несколько вопросов к структуре сертификата.

1. Использование ключа (Key Usage)

В использовании ключа (Key Usage) используется значение E0, то есть установлены первые три бита: digitalSignature (Цифровая подпись), nonRepudiation (Неотрекаемость) и keyEncipherment (Шифрование ключей). Такое значение выводит цифровые подписи, сформированные с использованием подобного сертификата, из области действия Закона “Об электронном документе и электронной цифровой подписи” (проще говоря цифровые подписи не обладают юридической значимостью и не равнозначны подписям от руки), так как в этом случае не возможно выполнить шаг 3 пункта 6 главы 2 Приказа " Об утверждении Правил проверки подлинности электронной цифровой подписи".

2 Политика выпуска сертификата (Certificate Policies)

В расширении указан OID политики 1.2.398.3.3.2, в соответствии с https://root.gov.kz/oid/ его описание “Политики применения регистрационных свидетельств”, то есть это контейнерный OID, а не OID какой-то конкретной политики. Получается что я получил сертификат, выпущенный без политики? Не является ли это нарушением правил аккредитации УЦ?

3 Расширенные использования ключа (Extended Key Usage)

В расширенных использованиях ключа фигурирует 1.2.398.3.3.4.3.2.1, в соответствии с https://root.gov.kz/oid/ его описание “Идентификация Digital-ID”, он находится внутри 1.2.398.3.3.4.3.2 Удаленная идентификация. Но я не проходил удаленной идентификации с использованием Digital-ID для получения этого сертификата. Я подписал запрос на выпуск сертификата с помощью имеющегося у меня сертификата, который получал путем личной явки в ЦОН (сертификат на три года на токене). Получается что в выпущенном мне сертификата приведена недостоверная информация.

Политика применения ключей стандарта ГОСТ 2015
#2

НУЦ РК запустил выдачу ключей ЭЦП на алгоритме ГОСТ 34.10-2015 для физических лиц, что позволяет владельцам информационных систем, перед официальным (полным) переходом на данный стандарт, протестировать использование данных ключей ЭЦП в боевой среде, для более плавного обновления.

Полный переход на ГОСТ 34.10-2015 планируется произвести после утверждения Правил выдачи, хранения, отзыва регистрационных свидетельств и подтверждения принадлежности и действительности открытого ключа электронной цифровой подписи национальным удостоверяющим центром Республики Казахстан от 26 июня 2015 года № 727 и соответствующего поручения от уполномоченного органа (Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан).

В ответ на Ваши вопросы сообщаем следующе:

1. Использование ключа (Key Usage).

Используемые поля Цифровая подпись, Неотрекаемость и Шифрование ключей не противоречит Законодательству Республики Казахстан. Так согласно СТ РК 1073-2007 запрещено использовать один ключ ЭЦП для подписания и шифрования данных. Хотим отметить, что при аутентификации не используется шифрование данных.

2 Политика выпуска сертификата (Certificate Policies)

Настоящим сообщаем, что указание данного OID считается правильным, так как Правила (Политика) применения регистрационных свидетельств НУЦ РК, содержит описание всех видов выдаваемых регистрационных свидетельств, что соответствует подпункту 2-1) пункта 1 статьи 21 Закона Республики Казахстан «Об электронном документе и электронной цифровой подписи», где говориться, что удостоверяющий центр утверждает правила применения регистрационных свидетельств. Требование написания Правил/Политики применения регистрационных свидетельств на каждый вид регистрационных свидетельств является устаревшими.

3 Расширенные использования ключа (Extended Key Usage)

В регистрационном свидетельстве на алгоритме ГОСТ 34.10-2015, выявлено несвойственное значение в поле «Расширенные использования ключа». После выявления, данное значение было удалено из структуры регистрационного свидетельства.

#3

НУЦ РК запустил выдачу ключей ЭЦП на алгоритме ГОСТ 34.10-2015 для физических лиц, что позволяет владельцам информационных систем, перед официальным (полным) переходом на данный стандарт, протестировать использование данных ключей ЭЦП в боевой среде, для более плавного обновления.

Полный переход на ГОСТ 34.10-2015 планируется произвести после утверждения Правил выдачи, хранения, отзыва регистрационных свидетельств и подтверждения принадлежности и действительности открытого ключа электронной цифровой подписи национальным удостоверяющим центром Республики Казахстан от 26 июня 2015 года № 727 и соответствующего поручения от уполномоченного органа (Министерства цифрового развития, инноваций и аэрокосмической промышленности Республики Казахстан).

Не могли бы Вы прояснить, электронные документы, подписанные с использованием этих сертификатов попадают под действие Закона об электронном документе и ЭЦП или нет? Если это тестовые сертификаты, то это одно, если боевые, то другое. В анонсе нигде не было сказано что это тестовые сертификаты, при их получении так же ни слова не сказано что они тестовые.

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

1. Использование ключа (Key Usage).

Используемые поля Цифровая подпись, Неотрекаемость и Шифрование ключей не противоречит Законодательству Республики Казахстан. Так согласно СТ РК 1073-2007 запрещено использовать один ключ ЭЦП для подписания и шифрования данных. Хотим отметить, что при аутентификации не используется шифрование данных.

Но в Правилах проверки прописано (тот самый шаг 3 пункта 6 главы 2):

  1. проверка области использования ЭЦП регистрационного свидетельства. Проверка заключается в проверке значения поля регистрационного свидетельства “использование ключа” (KeyUsage). Значения “Цифровая подпись” и “Неотрекаемость”, содержащиеся в поле “использование ключа”, означают что, это регистрационное свидетельство используется для ЭЦП. Значения “Цифровая подпись” и “Шифрование ключей”, содержащиеся в поле “использование ключа”, означают что, это регистрационное свидетельство используется для аутентификации;

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

Более того технически ключи ГОСТ 34.10-2015 нельзя использовать для “Шифрование ключей”, сам криптографический алгоритм этого не предусматривает. Зачем же тогда добавлять это значение в сертификат, если оно не оправдано ни юридически, ни технически?

2 Политика выпуска сертификата (Certificate Policies)

Настоящим сообщаем, что указание данного OID считается правильным, так как Правила (Политика) применения регистрационных свидетельств НУЦ РК, содержит описание всех видов выдаваемых регистрационных свидетельств, что соответствует подпункту 2-1) пункта 1 статьи 21 Закона Республики Казахстан «Об электронном документе и электронной цифровой подписи», где говориться, что удостоверяющий центр утверждает правила применения регистрационных свидетельств. Требование написания Правил/Политики применения регистрационных свидетельств на каждый вид регистрационных свидетельств является устаревшими.

То, что каждый УЦ самостоятельно определяет свои политики - это понятно. Так же понятно что политики прописываются в документации УЦ, как минимум в рамках прохождения процедуры аккредитации и очевидно что ее НУЦ так же проходит.

Но как тогда понять на основании какой именно политики был выпущен мой сертификат? Получается что с какой-то целью определены политики (в Правилах применения), определены их OIDы, но при этом понять какой политике соответствует какой сертификат невозможно?

Плюс это дополнительный механизм контроля для информационных систем - можно требовать чтобы подписи под определенными документами были сформированы с помощью сертификатов, выпущенных по определенным политикам.

Мне не понятен отказ от прописывания в сертификате информации о том, на основании какой политики он выпущен.

1 Симпатия
#4

Владимир, а вы не пробовали с помощью этой функционалость на казтокен выпустить ключи.
Оно вроде как без ошибок отрабатывает, сертификат записывается и в панели управления Казтокен отображается, что сертификат действителен.

Но при этом, пишется что это НУЦ ГОСТ 34.310-2004 (хотя сам сертификат содержит новые oid`ы)

#5

Владимир, а вы не пробовали с помощью этой функционалость на казтокен выпустить ключи.
Оно вроде как без ошибок отрабатывает, сертификат записывается и в панели управления Казтокен отображается, что сертификат действителен.

Добрый день, да, мы это уже тестировали, отлично работает - на одном устройстве могут быть ключи и на старых и на новых алгоритмах.

Но при этом, пишется что это НУЦ ГОСТ 34.310-2004 (хотя сам сертификат содержит новые oid`ы)

Видимо Панель не корректно идентифицирует ключи при отображении информации. Но так как Панель не участвует в подписании, а только отображает информацию, то это не критично. С другой стороны, конечно, починить нужно.

#6

Добрый вечер,

Буду признателен за комментарии к моим комментариям по пунктам 1 и 2.

#7

Здравствуйте!
По крайней мере по пункту 1 постараюсь донести до руководства критическую ошибку в указании бита “Шифрование ключей”. Это действительно некорректное использование!
Вы могли заметить такое использование ещё в тестовых сертификатах. Ещё тогда были споры по этому моменту.
После принятия, надеюсь положительного, решения необходимо будет продумать процедуру отзыва по выпущенным сертификатам, так как они выпущены новым промышленным УЦ.

#8

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

Подскажите, пожалуйста, Вашу персональную точку зрения по поводу политик - это нормально что в сертификате не указано на основании какой политики он выпущен? Если это беспокоит не только меня, то мы могли бы инициировать официальное обращение в НИТ или МЦРИАП по этому поводу чтобы продемонстрировать что сообществу это не безразлично.

1 Симпатия
#9

Бит “Шифрование ключей” не будет проставляться. Вроде уже можно выпустить и проверить. Выпущенные ранее сертификаты, к сожалению, так и останутся. Сказали у НУЦ нет никаких законных оснований самостоятельно отзывать сертификаты.
Но теперь выяснилось, что конкретно Документолог использует текущие пользовательские сертификаты аутентификации RSA в процессе шифрования передаваемых сообщений. Точнее генерируют ключ AES, а его шифруют открытым ключом получателя. Мое предложение было выпускать дополнительный сертификат ГОСТ 34.10-2015 для таких случаев с битом “Согласование ключа”, а дальше ключ будет вырабатываться согласно, например, ВКО ГОСТ, но было принято решение добавлять бит “Согласование ключа” в тот же самый сертификат ГОСТ. В итоге по шаблонам ФЛ, ЮЛ и информационные системы ФЛ\ЮЛ сертификат будет содержать биты “digital signature” + “non-repudiation” + “key agreement”. А в правила проверки будут внесены изменения.
По политике - правильнее будет добавить конкретную политику, чтобы однозначно знать область применения того или иного сертификата. Значений в keyUsage и extendedKeyUsage недостаточно.

1 Симпатия
#10

Точнее генерируют ключ AES, а его шифруют открытым ключом получателя.

Но ведь это противоречит пункту 5.1.3 СТ РК 1073-2007. То есть до тех пор, пока они использовали для этого ключ аутентификации было еще как-то понятно (в сертификате проставлены соответствующие значения), но сейчас ключевая пара одна, сертификат один, причем они предназначены именно для ЭЦП, но в данном случае открытый ключ будет применяться для шифрования, а закрытый для расшифрования. Однозначно противоречит.

Более того, на сколько мне известно, в отличие от RSA, алгоритм СТ РК ГОСТ Р 34.10-2015 не поддерживает шифрования данных, он описывает исключительно формирование и проверку ЭЦП.

1 Симпатия
#11

Ну фактически сейчас противоречит.

Ключевая пара по ГОСТу не имеет возможности использовать алгоритмы шифрования, но их можно использовать для выработки ключа обмена по аналогии со схемой Диффи-Хеллмана. Это описывается как ВКО ГОСТ.

#12

Да, есть такой RFC 7836. На сколько это соответствует 1073 судить не могу, видимо считается что соответствует.

Спасибо, по использованию ключа теперь понятно.