Проект Требований к форме квалифицированного сертификата ключа проверки электронной подписи

[igus]

Хочу заметить что ввод в сертификат всего не характеризующее субъекта не правильно, поскольку запихивая в сертификат ИНН УЦ берёт на себя обязанность проверять этот ИНН, а ведёт то его не УЦ, а ФНС и т.д.

Ну пусть неправильно, но ФЗ-то уже принят, и в нем записано, что ИНН в сертификате должен быть. Вот должен, и все тут. И чего теперь копья-то ломать? Dura lex, sed lex.

[pavlov]

Тоже позволю себе не согласиться. Если в сертификате в поле SubjectPublicKeyInfo.algorithm прописан идентификатор 1.2.643.2.2.19, описанный в RFC 4491, то этого должно быть достаточно для любой реализации, чтобы работать с таким ключом. Если это не так, и возможно появление 2 разных несовместимых реализаций, это (всего лишь) означает, что разработчики RFC не доработали и в RFC описаны не все детали. Это все чисто теоретические утверждения, т.к. на практике сейчас проблем в этом смысле нет, т.к. уже сделаны совместимые по сертификатам реализации разных производителей. Я немного поторопился, сказав без детализации, что этот OID "указывает на алгоритм ГОСТ", конечно OID указывает не на абстрактный ГОСТ, а на конкретные детали использования этого ГОСТ в соответствии с упомянутым RFC.

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

По поводу недобросовестной конкуренции. Требования закона приводят к том, что можно будет по сертификату узнать, какой софт его сделал. И можно будет написать программу, которая откажется проверять сертификат не того производителя. Раньше этого не могло быть. Так что беда в законе, который "суров". Давайте в требованиях к сертификату напишем, что УЦ должны класть такую-то информацию, но разработчики систем проверки подписи не должны её использовать ("а зачем клали?", -- "а так, для справки?", -- "для справки для кого?", -- "ясно для кого").

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

Часть требования из п.п. 14.2.4 "стандарты, требованиям которых соответствуют ключ электронной подписи и ключ проверки электронной подписи" выполняется, т.к. каждый сертификат содержит идентификатор алгоритма ключа в поле SubjectPublicKeyInfo.algorithm, что указывает на стандарт ГОСТ.

Вот с этим, пожалуй, не соглашусь. Смысл этого требования ФЗ, как я понимаю, в том, чтобы из сертификата было понятно, какими средствами проверять соответствующие подписи. И ответ на этот вопрос может быть сформулирован двумя способами: либо указать конкретное средство, либо указать такой набор стандартов, чтобы любое средство, им удовлетворяющее, подходило. А это не только ГОСТ, но и, как минимум, RFCшки, разработанные в рамках соглашения о совместимости.
Так что во исполнение ФЗ нужно предусмотреть возможность указать этот набор стандартов.

И, кстати, во избежание недобросовестной конкуренции хорошо бы прописать, что указание конкретного средства ЭП допустимо только если невозможно описать набор стандартов.

[Хвостов]

Муругову

Сергей Михайлович!
Да, вы правы Закон прямо не устновил соответствие.
Однако, для акредитации УЦ требуется (ст. 16) "3) наличие средств электронной подписи и средств удостоверяющего центра, получивших подтверждение соответствия требованиям, установленным федеральным органом исполнительной власти в области обеспечения безопасности"

Таким образом, акредитацию УЦ будет проводить Минкомсвязи, которое устанавливает правила акредитации,
а требования к структуре квалифицированного сертификата, устанавливает ФСБ.

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

Между тем Минюст подготовил законопроект "О внесении изменений в отдельные законодательные акты
Российской Федерации" и в нем везде квалифицированная подпись.
В связи с этим, повторю вопрос: какому классу средств подписи и УЦ соответствует квалифицированная подпись

Дополнительно по Вашему предыдущему ответу:
проверку корретности встраивания УЦ ( в смысле программно-аппаратного комплекса, а не ПО) в прикладные системы требуют в обязательном порядке и это д.б. вписано в формуляр УЦ.

С уважением

А. Хвостов

[Sidorin Yuriy]

Уважаемые коллеги, присоединяюсь к предложениям:
- убрать "политики" привязанные к уровням требований из certificatePolicies
- заменить строковые значения в IssuerSignTool и cATool на OID-ы (реестр прошедших сертификацию СКЗИ и УЦ есть, так почему-же не пользоваться им ?)
- расширить данные в IssuerSignTool и cATool уровнями сертификации соответствующих средств
- сделать обязательным по крайней мере одно расширение certificatePolicies со ссылкой на CPS в соответствии с которым выпущен сертификат
- включить в состав полей PrivateKeyUsagePeriod

Кроме того в составе расширений внести CRLDistributionPoints, FreshestCRL и AuthorityInfoAccess, сделав наличие ссылки на crl обязательным. Согласно 63ФЗ УЦ аккредитованный УЦ обязан публиковать в электронном виде CRL-и, так что наличие ссылки на него будет логично...
P.S. Странно, что согласно определению квалифицированного сертификата в 63ФЗ и предложенном проекте, аккредитованный УЦ не можен выпускать никаких сертификатов кроме квалифицированных...

С уважением,
Сидорин Юрий.
ФГУП "НТЦ "Атлас"

[pavlov]

P.S. Странно, что согласно определению квалифицированного сертификата в 63ФЗ и предложенном проекте, аккредитованный УЦ не может выпускать никаких сертификатов кроме квалифицированных...

По крайней мере, насчёт сертификатов ключей ЭП, вероятно, так дела и обстоят. Действительно, странно. Не обратил на это внимание.

Тогда становится немного понятным пункт 4 из требований.

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

Если каждый сертификат, изготовленный аккредитованным УЦ, - квалифицированный (по определению), и, следовательно, должен удовлетворять обсуждаемым требованиям, то выполнить это можно только проверив функциональность софта УЦ при аккредитации, что он не вкладывает не разрешённые поля в сертификаты (только это даст гарантии, что ВСЕ сертификаты, выданные этим УЦ будут удовлетворять требованиям). Это значит, что в требованиях должен содержаться не минимальный набор полей, как я думал раньше, а наоборот, полный набор полей, который может встретиться в сертификате. Иначе в будущем можно будет обвинить УЦ, что он выпускает квалифицированные сертификаты (а раз он аккредитованный УЦ, то он только такие и выпускает), не удовлетворяющие требованиям. Правильно рассуждаю?

Это означает, что в документе надо указать все допустимые расширения, все допустимые компоненты имени в RDN, (т.е., действительно, надо не забыть AIA, CDP, Freshest CRL, SubjectAltName, IsssuerAltName, SubjectKeyId, AuthorityKeyId, EKU, CertPolicy, PrivateKeyUsagePeriod).

Аккредитованный УЦ должен уметь выдавать кросс-сертификаты (в том числе для подчинённых CA)? Тогда не забудьте еще BasicConstraints, NameConstraints, PolicyMappings, PolicyConstraints, Inhibit anyPolicy (для полноты картины).

Аккредитованный УЦ должен поддерживать OCSP? Не забудем тогда еще id-pkix-ocsp-nocheck.

Может, ещё для каких популярных в госорганах приложениях нужны какие-нибудь расширения? Тоже их надо тут упомянуть.

И ещё следствие. Если необходимость в неудовлетворяющих требованиям сертификатах все-таки будет (чтобы не ломать существующие корпоративные системы), аккредитованному УЦ понадобится своё отдельное юридическое лицо? Ничего не напутал?

Или, может быть, пункт 4 требований ослабить? Тогда достаточно в этом документе будет достаточно прописать минимальный набор полей, благодаря которым сертификат сможет носить имя квалифицированного. А остальные поля УЦ может добавлять, никого не спрашивая?