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

[serikov]

Уважаемые коллеги, просьба подавать Ваши замечания и предложения к содержательной части проекта Требований.
Срок представления предложений - до 26 сентября 2011 г.

Предложения размещать в данной теме форума.


Справка по концепции требований к форме квалифицированного сертификата

Во исполнение части 5 статьи 8 Федерального закона «Об электронной подписи» (далее – Федерального закона) подготовлен проект Требований к форме квалифицированного сертификата ключа проверки электронной подписи (далее – Требования), устанавливающих требования к совокупности и порядку расположения полей квалифицированного сертификата.
Требования к совокупности полей квалифицированного сертификата устанавливаются в соответствии со статьями 14 и 18 Федерального закона. При определении требований к порядку расположения полей квалифицированного сертификата в виде электронного документа в качестве основы использовался международный стандарт ISO/IEC 9594-8 (международные рекомендации ITU-T X.509) и рекомендации IETF RFC 5280. В целях выполнения требований Федерального закона к составу информации, содержащейся в квалифицированном сертификате, предъявлены требования по использованию ряда новых атрибутов имени и дополнений (extensions) сертификата.
Должны использоваться атрибуты OGRN, SNILS и INN для указания соответственно основного государственного регистрационного номера, страхового номера индивидуального лицевого счета и идентификационного номера налогоплательщика.
В дополнении certificatePolicies должны указываться как минимум два идентификатора политик сертификации, отражающие класс средств электронной подписи владельца квалифицированного сертификата и класс средств удостоверяющего центра, с использованием которых был выпущен квалифицированный сертификат.
Дополнение subjectSignTool введено для указания в квалифицированном сертификате наименования используемого владельцем квалифицированного сертификата средства электронной подписи.
Дополнение issuerSignTool введено для указания в квалифицированном сертификате наименования средств электронной подписи и средств аккредитованного удостоверяющего центра, которые использованы для создания ключа электронной подписи, ключа проверки электронной подписи, квалифицированного сертификата, а также реквизитов документа, подтверждающего соответствие указанных средств требованиям, установленным законодательством Российской Федерации.
Указанные требования предназначены для разработчиков, специализированных организаций, а также для операторов информационных систем, реализующих прикладные задачи (например, предоставление государственных и муниципальных услуг в электронной форме), поскольку именно на оператора информационной системы ложится нагрузка по информированию рядового пользователя о том, средства какого класса защищенности он должен использовать.

[murugov]

Очень бегло глянул, но тем не менее резануло глаз, что не хватает отсылок на RFC 4357, 4490, 4491 (возможно кто то из них лишний где про CMS, а может и нет) и ещё я так и не получил ответа на вопрос, можно ли ключи квалифицированного сертификата использовать не для выработки-проверке подписи, т.е. не по прямому назначению, которое не регулируется 63-ФЗ (это я про шифрование .... и т.д)? В какой то RFC написано что это делать не рекомендуется (точно форму запрета не припомню, возможно там написано более жёстче). Хочу также напомнить, что в Европе назначение ключей разнесено - отдельно квалифицированные и взводится один единственный бит "contentCommitment", а всё остальное (шифрование, процедуры обмена ключами, доступ (как они это называют)) отдельный слот в токене и сертификаты не квалифицированные.

[timakov]

Добрый день.

1) Предлагается дополнить пп.17,18 следующими пояснениями:
- в этих пунктах лишь перечисляются атрибуты, которые РЕКОМЕНДУЕТСЯ использовать в issuer и subject;
- другие атрибуты также МОГУТ включаться, но при этом они не обязательно должны использоваться для различения имён.

2) Подпункты 17.2 (surname) и 17.3 (givenName) предлагается либо исключить либо подробно описать их отношения с commonName.

3) Необходимо определить минимальный (обязательный) набор атрибутов:
- для issuer;
- для subject сертификата физического лица;
- для subject сертификата юридического лица.

4) П. 24 (authorityKeyIdentifier).
Непонятно, можно ли наряду с authorityCertSerialNumber включать keyIdentifier и authorityCertIssuer?
Предлагаю сократить формулировку: "В квалифицированном сертификате СЛЕДУЕТ использовать дополнение authorityKeyIdentifier."

5) П. 25 (Key Usage) - описывает все возможные биты назначения.
Поскольку документ ориентирован исключительно на сертификаты подписи (и при этом ссылается на ФЗ об ЭП), то п. 25 предлагается в следующей редакции:
"Расширение Key Usage ДОЛЖНО включаться в квалифицированный сертификат. При этом ДОЛЖНЫ быть установлены биты назначения digitalSignature (0) и contentCommitment (1). Другие биты назначения также МОГУТ быть установлены."

6) Пп. 24-30 описывают 5 расширений: AuthorityKeyIdentifier, KeyUsage, CertificatePolicies, SubjectSignTool, IssuerSignTool.
Необходимо добавить пояснение, что квалифицированный серификат МОЖЕТ включать также и другие расширения (например: BasicConstraints, ExtendedKeyUsage и т.д.).

7) Для строк, используемых в расширениях SubjectSignTool, IssuerSignTool необходимо определить максимальный размер.

8) Вопрос: IssuerSignTool.signTool и subjectSignTool - это не одно и то же? Если да, одно, то SubjectSignTool можно безболезненно исключить.

9) OID'ам, приведённым в пп. 27 и 28 (описатели классов защиты), на мой взгляд, в CertificatePolicies не совсем место - поскольку под политикой подразумевается вполне конкретный документ.
Предлагаю перенести их в IssuerSignTool, дополнив структуру:
SubjectSignTool ::= SEQUENCE {
signTool UTF8String,
cATool UTF8String,
signToolCert UTF8String,
cAToolCert UTF8String,
signToolClass OBJECT IDENTIFIER,
cAToolClass OBJECT IDENTIFIER }

10) Вопрос: на основании какого подтверждения УЦ включает в сертификат "полное наименование средства ЭП, которое было использовано для создания ключа ЭП"? Аналогично для требования включать "полное наименование, номер и дата выдачи документа, подтверждающего соответствие средства ЭП, которое было использовано для создания ключа ЭП".
И второй вопрос: может ли такой сертификат (с наименованием одного средства) быть использован для проверки ЭП другим средством?

11) Раздел IV. Непонятно, каким образом можно использовать "сертификат на бумажном носителе"? Проверить подпись однозначно не удастся. Достоверность данных самого сертификата также не может быть подтверждена.
В любом случае требование "пригодности для проведения формализованной процедуры контроля соответствия квалифицированного сертификата" подразумевает более детальное и формализованное описание полей: дат, наименований атрибутов имени, бинарных полей, расширений.

12) Отсутствует список документов, на которые есть ссылки.

--
С уважением,
Тимаков В.М.
ЗАО "Сигнал-КОМ"

[timakov]

Добрый день.

Два небольших замечания:
1) к п. 18.2
СНИЛС имеет формат "123-456-789 12".
Т.е. он не укладывается ни в NumericString (поскольку используется дефис), ни в отведённый размер 11.
2) к п.18.3
ИНН может иметь размер 10 либо 12 символов.

С уважением,
Тимаков В.М.
ЗАО "Сигнал-КОМ"

[murugov]

А может в очередной раз не стоит опять изобретать новые сущности ?!
Давайте вспомним на кой нам нужны эти самые ИНН, СНИЛС и т.п. ответ, если это для ввода данных, то для таких вещей более подходит сабжектальтнэйм а не просто сабжект, если это для обеспечения уникальности DN, то в RFC 3039 для этого специально придуман серийное имя энд-юзера и УЦ обязаны это обеспечить, вот например как это выглядит в настоящем боевом сертификате изданным в Европе:
Subject:
GivenName: Sergey
Surname: Murugov
SerialNumber: NIP:8520006444
OrganizationName: LLC Top Cross
CountryName: RU
CommonName: Sergey Murugov
(NIP == Налоговый Идентификатор человека или фирмы)
А отсюда следует:
serialNumber ATTRIBUTE ::= { WITH SYNTAX PrintableString (SIZE (1..ub-serialNumber))
EQUALITY MATCHING RULE caseIgnoreMatch
SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch
ID id-at-serialNumber
}
, для содержимого которого установить определенный формат, например

idList = singleId [ ‘;’ idList ]
singleId = idType ‘:’ idValue
idType = ‘OGRN’ | ‘INN’ | ‘SNILS’ …
idValue = …
И тут можно разрулить все проблемы с написанием и длинной, что Виктор заметил.
И далее большая просьба, давайте поменьше выдумывать, нам ещё в Европе жить (я надеюсь) и трансграничность не следует сходу обрубать. Вот при социализме было отличное правило, в новом проекте закладывалось и ограничивалось число новых комплектующих и это не давало возможности изобретать треугольные гайки и т.п. фигню, мы что это всё забыли уже?!

[sedovroman]

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

1. Всё-таки используемого для чего средства?
Если для формирования ключа - это одно, а если для формирования ЭП, то, вообще говоря, средства могут использоваться разные.

2. И еще в п.29 написано, что расширение должно использоваться, а в приложениях помечено как поле, "которое в квалифицированном сертификате могут отсутствовать".

[mail]

1. Было бы целесообразно вместе с требованиями по совокупности определить форматы заполнения каждого из полей и перечень возможных к использованию символов и их представлению (стандарт кодировки). Желательно изначально обеспечить представление данных в сертификате простым и однозначным образом, чтобы исключить разночтения документа уже на этапе разработки приложений.
2. Требования не позволяют выдавать сертификаты индивидуальным предпринимателям. В требованиях заложен атрибут INN в 12 символов при том, что он заполняется только в случае выпуска квалифицированного сертификата на ЮЛ, у которого ИНН состоит 10 символов. Атрибут OGRN в 13 символов вместить значение ОГРНИП не сможет.
3. Пункты 17.1-17.3 – избыточность одновременного внесения одних и тех же сведений в 3 поля.

[Хвостов]

Добрый день!

1. Обсуждаемый документ называется «Требования к форме квалифицированного сертификата ключа проверки электронной подписи» (далее Требования)
В п.2 определено: « удостоверяющий центр (далее – УЦ) – юридическое лицо или индивидуальный предприниматель, осуществляющие функции по созданию и выдаче сертификатов ключей проверки ЭП, а также иные функции»
Таким образом, в первую очередь данный документ предназначен для УЦ, как организации эксплуатирующей средства УЦ. И эта организация, а не разработчик средств УЦ, осуществляет включение дополнительных полей в состав квалифицированного сертификата на основании п.8.
Соответственно разработчик средств УЦ должен предусмотреть возможность реализации данной функции, что и должно быть отражено в ТЗ на разработку средств УЦ.
В связи с этим предлагается следующая формулировка п. 4
4. При включении в состав квалифицированного сертификата дополнительных полей требования к их назначению и расположению в квалифицированном сертификате определяются в техническом задании на встраивание средств УЦ в системы обработки информации.

2. В каком виде могут быть включены в квалифицированный сертификат данные о полномочиях владельца сертификата действовать по поручению третьих лиц? См. Федеральный закон, статья 15 (“Сведения о наименованиях, номерах и датах выдачи документов, подтверждающих полномочия владельца квалифицированного сертификата действовать по поручению третьих лиц, если информация о таких полномочиях владельца квалифицированного сертификата включена в квалифицированный сертификат.”)?

3. В состав RDN необходимо включить обязательный атрибут Email, который необходим для рассылки СОС и др. сообщений от имени УЦ.

4. А что Extended Key Usage не имеет право на жизнь? А как разграничивать назначение (область применения) сертификатов?
RFC 5280 п 4.2.1.12 «This extension indicates one or more purposes for which the certified public key may be used, in addition to or in place of the basic purposes indicated in the key usage extension. In general, this extension will appear only in end entity certificates»


4. Обозначение уровня защищенности информации, защищаемой средствами ЭП владельца квалифицированного сертификата, предлагается использовать в отдельном дополнении, , а не в certificatePolicies. Заменить п.п. 30, 31, 32, 33 на:

30. Для обозначения уровня защиты информации владельца сертификата, в том числе доверенное лицо удостоверяющего центра, в квалифицированный сертификат вводится критичное дополнение с объектным идентификатором 1.2.643.100.113.1.
Структура значения дополнения определяется следующим образом:
ClientSecurityInformationLevel ::= SEQUENCE {
signSecurityInformationClass SecurityInformationClassID,
signToolSecurityInformationClass SecurityInformationClassID,
signToolName UTF8String }
SecurityInformationClassID ::= OBJECT IDENTIFIER
Поле signSecurityInformationClass содержит идентификатор уровня защищенности ЭП владельца сертификата.
Поле signToolSecurityInformationClass содержит идентификатор уровня защищенности СЭП владельца сертификата.
Поле signToolName содержит наименование СЭП владельца сертификата.
Уровень защиты информации владельца сертификата определяется по наименьшему уровню защищенности ЭП и уровню защищенности СЭП.

Для обозначения уровня защиты информации удостоверяющего центра , в квалифицированный сертификат вводится критичное дополнение с объектным идентификатором 1.2.643.100.113.2
Структура значения дополнения определяется следующим образом:
CaSecurityInformationLevel ::= SEQUENCE {
signSecurityInformationClass SecurityInformationClassID,
signToolSecurityInformationClass SecurityInformationClassID,
signToolName UTF8String }
SecurityInformationClassID ::= OBJECT IDENTIFIER
Поле signSecurityInformationClass содержит идентификатор уровня защищенности ЭП удостоверяющего центра.
Поле signToolSecurityInformationClass содержит идентификатор уровня защищенности СЭП удостоверяющего центра.
Поле signToolName содержит наименование СЭП удостоверяющего центра.
Уровень защиты информации удостоверяющего центра определяется по наименьшему уровню защищенности ЭП и уровня защищенности СЭП.
В соответствии с Требованиями к средствам электронной подписи, утвержденными приказом ФСБ России от № и Требованиями к средствам удостоверяющих центров, утвержденными приказом ФСБ России от № для обозначения уровня защищенности вводится следующий набор объектных идентификаторов:
1.2.643.100.114.1 – уровень защищенности КС1,
1.2.643.100.114.2 – уровень защищенности КС2,
1.2.643.100.114.3 – уровень защищенности КС3,
1.2.643.100.114.4 – уровень защищенности КВ1,
1.2.643.100.114.5 – уровень защищенности КВ2,
1.2.643.100.114.6 – уровень защищенности КА1.
Класс защиты информации ЭП, поставленной при помощи квалифицированного сертификата, определяется как наименьший из уровней класса защиты информации владельца сертификата и удостоверяющего центра, выдавшего квалифицированный сертификат.


С уважением
Хвостов А.С.
ФГНУ ЦИТиС

[pavlov]

4) П. 24 (authorityKeyIdentifier).
Непонятно, можно ли наряду с authorityCertSerialNumber включать keyIdentifier и authorityCertIssuer?
Предлагаю сократить формулировку: "В квалифицированном сертификате СЛЕДУЕТ использовать дополнение authorityKeyIdentifier."

Предлагаемое в п.п.24 заполнение поля authorityCertSerialNumber в качестве номера сертификата немного некорректно.

Во первых, использование данного поля требует одной из 2-х форм, либо keyIdentifier, либо пара, authorityCertSerialNumber и authorityCertIssuer.

Во-вторых, предпочтительным является использование формы с keyIdentifier, он однозначно определяет сертификат, и его использование позволяет корректно осуществлять построение цепочек кросс-сертификатов. При использовании варианта с серийным номером поиск кросс-сертификатов часто невозможен, так как кросс-сертификат имеет серийный номер, отличный от исходного сертификата ЦС.

Однако, цель этого документа определить, как удовлетворить требования 63-ФЗ. Там на интересуемую тему читаем:

Статья 17. Квалифицированный сертификат
2. Квалифицированный сертификат должен содержать следующую информацию:
1) уникальный номер квалифицированного сертификата, даты начала и окончания его действия;
...
6) наименование и место нахождения аккредитованного удостоверяющего центра, который выдал квалифицированный сертификат, номер квалифицированного сертификата удостоверяющего центра;

Попытаемся выполнить требование п.п. 17.2.6 (по хорошему, эту информацию надо искать в сертификате УЦ, а не в сертификате пользователя, но закон есть закон).

Итак, "Наименование и место нахождение аккредитованного удостоверяющего центра, который выдал квалифицированный сертификат" считаем записанным в имени издателя, в полях CN,L,ST,C и т.п. Осталось определиться с "номером квалифицированного сертификата удостоверяющего центра". Заметим также, что в п.п. 17.2.6 нет слова "уникальный", какое есть в п.п. 17.2.1.

Таким образом, требования закона будут выполнены, если будем считать, что "номером квалифицированного сертификата удостоверяющего центра" является keyIdentifier из расширения authorityKeyIdentifier.

При этом поля authorityCertSerialNumber и authorityCertIssuer можно не заполнять. Т.к. закон говорит "должен", то использование этого расширения и поля keyIdentifier является обязательным (MUST). Накладывать ограничения на поля authorityCertSerialNumber и authorityCertIssuer не следует, т.к. цель этого документа не обеспечить корректность функционирования PKI, а именно удовлетворить требованиям закона.

Предлагаемая формулировка для п.п. 24:

"В квалифицированном сертификате должно использоваться дополнение authorityKeyIdentifier с заполненым полем keyIdentifier в соответствии с п.п. 8.2.1.1 рекомендаций X.509. Значение keyIdentifier должно рассматриваться как номер квалифицированного сертификата аккредитованного УЦ, либо доверенного лица аккредитованного УЦ, либо уполномоченного федерального органа, выпустившего исходный квалифицированный сертификат. Настоящие Требования не устанавливают требований к использованию полей authorityCertSerialNumber и authorityCertIssuer дополнения authorityKeyIdentifier."

[murugov]

Категорически против вашей формулировки:

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

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

[murugov]

Попутный оргвопрос - А кто ни будь взял на себя обязанность сводить в единый документ все замечания-предложения которые тут пишутся?

[pavlov]

Определения АСН.1 для стандартных структур в этом документе выглядят лишними, достаточно сослаться на стандарт, где они описаны, причём описаны более формализовано. В крайнем случае, для однозначности ссылки, можно указывать номер п.п. в X.509 и X.520. Эти конструкции только удлиняют документ, ничего нового не внося.

Объектные номера стандартных дополнений и атрибутов в этом документе тоже выглядят лишними, они и так всем известны и описаны в рекомендациях.

Фразы (при описании дополнения KeyUsage) "Значение «1» во втором(третьем и т.д.) бите означает" тоже выглядят лишними. Согласен с формулировкой

5) П. 25 (Key Usage) - описывает все возможные биты назначения.
Поскольку документ ориентирован исключительно на сертификаты подписи (и при этом ссылается на ФЗ об ЭП), то п. 25 предлагается в следующей редакции:
"Расширение Key Usage ДОЛЖНО включаться в квалифицированный сертификат. При этом ДОЛЖНЫ быть установлены биты назначения digitalSignature (0) и contentCommitment (1). Другие биты назначения также МОГУТ быть установлены."

Очень важно написать в начале документа, что все остальные дополнения сертификата, и атрибуты имени, не упомянутые в этих требованиях, РАЗРЕШЕНЫ. Иначе, у многих и потом будут возникать вопросы о их использовании.

1) Предлагается дополнить пп.17,18 следующими пояснениями:
- в этих пунктах лишь перечисляются атрибуты, которые РЕКОМЕНДУЕТСЯ использовать в issuer и subject;
- другие атрибуты также МОГУТ включаться, но при этом они не обязательно должны использоваться для различения имён.
...
6) Пп. 24-30 описывают 5 расширений: AuthorityKeyIdentifier, KeyUsage, CertificatePolicies, SubjectSignTool, IssuerSignTool.
Необходимо добавить пояснение, что квалифицированный серификат МОЖЕТ включать также и другие расширения (например: BasicConstraints, ExtendedKeyUsage и т.д.).

[pavlov]

Настоящий документ должен показать, как удовлетворить следующим требованиям 63-ФЗ:

Статья 14. Сертификат ключа проверки электронной подписи
2. Сертификат ключа проверки электронной подписи должен содержать следующую информацию:
4) наименование используемого средства электронной подписи и (или) стандарты, требованиям которых соответствуют ключ электронной подписи и ключ проверки электронной подписи;

Статья 17. Квалифицированный сертификат
2. Квалифицированный сертификат должен содержать следующую информацию:
5) наименования средств электронной подписи и средств аккредитованного удостоверяющего центра, которые использованы для создания ключа электронной подписи, ключа проверки электронной подписи, квалифицированного сертификата, а также реквизиты документа, подтверждающего соответствие указанных средств требованиям, установленным в соответствии с настоящим Федеральным законом;

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

Осталось разобраться с :
"наименованием используемого средства электронной подписи",
"наименования средств аккредитованного удостоверяющего центра",
"реквизиты документа, подтверждающего соответствие требованиям используемого средства электронной подписи",
"реквизиты документа, подтверждающего соответствие требованиям используемого средства аккредитованного удостоверяющего центра".

Замечу, что про средства электронной подписи, которое использовал УЦ для изготовления подписи под сертификатом, в законе нет. Речь идёт только про "средства аккредитованного удостоверяющего центра", которое, конечно, включает и средства электронной подписи. Так что их разделение - инициатива этого документа. Однако, особых возражение против такого разделения у меня нет.

9) OID'ам, приведённым в пп. 27 и 28 (описатели классов защиты), на мой взгляд, в CertificatePolicies не совсем место - поскольку под политикой подразумевается вполне конкретный документ.

Двумя руками за. CertificatePolicies отвечают за регламент УЦ и участвуют в построении цепочек. Совсем не уместно определять OID-ы для разных "политик" в этом документе. Могут быть проблемы при построении цепочек при взаимодействии разных систем. Уж если есть желание как-то отрегулировать CertificatePolicies , документ мог бы рекомендовать или обязать поместить в CertificatePolicies для некоторой политики ссылку URL на документ регламента УЦ на сайте УЦ или на сайте УФО.

8) Вопрос: IssuerSignTool.signTool и subjectSignTool - это не одно и то же? Если да, одно, то SubjectSignTool можно безболезненно исключить.

Видимо, не одно и тоже. subjectSignTool - СКЗИ у клиента, а IssuerSignTool.signTool - СКЗИ на УЦ, в общем случае разные.

10) Вопрос: на основании какого подтверждения УЦ включает в сертификат "полное наименование средства ЭП, которое было использовано для создания ключа ЭП"?

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

Аналогично для требования включать "полное наименование, номер и дата выдачи документа, подтверждающего соответствие средства ЭП, которое было использовано для создания ключа ЭП".

Такого требования нет в 63-ФЗ, оно появилось только в обсуждаемом документе.

И второй вопрос: может ли такой сертификат (с наименованием одного средства) быть использован для проверки ЭП другим средством?

Конечная версия документа должна это позволить (иначе зачем вообще этот форум нужен). Если у людей могут возникнуть сомнения, значит в документе следует явно прописать как-то так: "Расширения subjectSignTool и issuerSignTool добавляются только в информационных целях. Проверка ЭП документов и ЭП сертификатов, созданных разными средствами не должна зависеть от этих расширений."

7) Для строк, используемых в расширениях SubjectSignTool, IssuerSignTool необходимо определить максимальный размер.

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

63-ФЗ говорит только про наименование средств. Эти средства можно и зарегистрировать где-то, например, в УФО, и присвоить им идентификаторы OID, для каждой версии сертифицированного средства свой OID. Можно ещё проще, обязать разместить в сертификате URL на страницу сайта производителя СКЗИ и/или УЦ (для каждой версии СКЗИ или УЦ свой URL). А вот полные реквизиты сертификатов соответствия ПО в сертификатах ключей точно не нужны. Если выбрать вариант с URL (а URL - это реквизит электронного документа), то вот по этим ссылкам и должны быть доступны все необходимые сведения о сертификации ПО.

Поэтому предложение такое. Сделать 3 дополнения, которые имеют одну и ту же структуру:

ToolName ::= SEQUENCE
{
-- URL на описание средства и деталей его сертификации
toolReference IA5String SIZE(1..64),

-- класс защищённости средства
toolSecurityClass OBJECT IDENTIFIER,
}

Наименование ПО ЭП пользователя (СКЗИ) (со слов пользователя).
OID дополнения, скажем, 1.2.643.100.111.
сlientSignToolName ::= ToolName

OID дополнения, скажем, 1.2.643.100.112.
Наименование ПО ЭП УЦ (СКЗИ) (указывает УЦ).
cASignToolName ::= ToolName

OID дополнения, скажем, 1.2.643.100.113.
Наименование ПО УЦ (указывает УЦ.
cAToolName ::= ToolName

И будем называть адрес URL в сlientSignToolName - и наименованием средства электронной подписи, и реквизитом документа о соответствии ПО, а адрес URL в cAToolName - наименованием средств аккредитованного удостоверяющего центра, и реквизитом документа о соответствии ПО. Таким образом, требования 63-ФЗ будут выполнены полностью, а дополнительные требования, появившиеся в этом документе, будут в основном выполнены.
Для toolSecurityClass будем использовать такие OID-ы (как уже предлагалось выше):

1.2.643.100.114.1 – уровень защищённости средства ЭП или средства УЦ КС1,
1.2.643.100.114.2 – уровень защищённости средства ЭП или средства УЦ КС2,
1.2.643.100.114.3 – уровень защищённости средства ЭП или средства УЦ КС3,
1.2.643.100.114.4 – уровень защищённости средства ЭП или средства УЦ КВ1,
1.2.643.100.114.5 – уровень защищённости средства ЭП или средства УЦ КВ2,
1.2.643.100.114.6 – уровень защищённости средства ЭП или средства УЦ КА1.

[murugov]

на тему KeyUsage - я очень сомневаюсь, что ключи квалифицированного сертификата для ПОДПИСИ в рамках ФЗ-63 (который регулирует вопросы ТОЛЬКО касающиеся подписи)могут быть использованы для чего бы то ни было, другого кроме подписи - спросите любого ФСБшника. Хочу также ПОВТОРНО обратить внимание на то что в Европе взводится только один флаг "contentCommitment". Соответственно формулировка должна быть вот такой:

"Расширение Key Usage ДОЛЖНО включаться в квалифицированный сертификат. При этом ДОЛЖЕН быть установлен бит назначения contentCommitment (1). Другие биты назначения МОГУТ быть установлены только в объёме обеспечения выпуска сертификатов."

[pavlov]

В стандарте X.509 (08/2005) RU написано следущее:

Биты в KeyUsage означают следующее:
a) digitalSignature: для проверки цифровых подписей, которые используются с услугой аутентификации объекта, услугой аутентификации источника данных и/или услугой целостности;
b) contentCommitment: для проверки цифровых подписей, цель которых состоит в сигнализации о том, что подписавшее лицо фиксируется в подписываемом содержимом. Тип фиксации, для поддержки которого может использоваться сертификат, может в дальнейшем быть ограничен СА, например, посредством политики сертификатов. Точный тип фиксации подписавшего лица, например, "рассмотрено и одобрено" или "с намерением быть связанным", может сигнализироваться посредством подписываемого содержимого, например, самого подписанного документа или дополнительной подписанной информации. Так как подписание фиксации содержимого рассматривается как операция, подписанная цифровой подписью, нет необходимости устанавливать в сертификате бит digitalSignature. Если он установлен, это не влияет на уровень фиксации, предоставленный подписавшим лицом в подписанном содержимом. Отметим, что является неправильным относить к данному биту keyUsage идентификатор nonRepudiation. Тем не менее, использование данного идентификатора было исключено. Несмотря на используемый идентификатор, семантика данного бита является такой же, как определенная в данной спецификации Справочника;

В обсуждаемом документе представляет интерес только бит contentCommitment. Так давайте про это и напишем. Не надо трогать остальные биты. На "квалифицированность" подписи это не влияет.

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

Предлагаю видоизменить формулировку так (убрав упоминание про бит digitalSignature(0) и исключив фразу "установлены только в объёме обеспечения выпуска сертификатов" как не несущую новой информации):

Расширение Key Usage ДОЛЖНО включаться в квалифицированный сертификат. При этом ДОЛЖЕН быть установлен бит назначения contentCommitment (1). Другие биты назначения также МОГУТ быть установлены."

[murugov]

В обсуждаемом документе представляет интерес только бит contentCommitment. Так давайте про это и напишем. Не надо трогать остальные биты. На "квалифицированность" подписи это не влияет.

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

[pavlov]

А может в очередной раз не стоит опять изобретать новые сущности ?!
...
serialNumber, для содержимого которого установить определенный формат, например

idList = singleId [ ‘;’ idList ]
singleId = idType ‘:’ idValue
idType = ‘OGRN’ | ‘INN’ | ‘SNILS’ …
idValue = …

Заманчиво, конечно, сделать так. Когда очередное ведомство издаст очередной приказ, чтобы в сертификат клали номер в его реестре, все УЦ страны не моргнув, начинают класть в serialNumber и эту информацию, никого не спрашивая. Красота.

Однако, можно вспомнить, что язык ASN.1 появился для описания структурированной информации. А это определение (idList = singleId [ ‘;’ idList ] и т.д.) вводит свою структуру внутри ранее определённой сущности. Таким образом, новая сущность все равно определяется, но не прямым способом, а через заднюю дверь. Если какие-то европейцы так делают (видел, что так делают поляки, но поляки ещё не вся Европа), то это не совсем правильно, по крайней мере, я никаких стандартов на этот счёт не видел.

RFC 3739 (заменившее 3039) отдаёт поле serialNumber на усмотрение УЦ для разрешения неоднозначностей. Т.е. если в УЦ появилось два однофамильца, и им нужно выпустить сертификаты, и никаких других отличий в сертификатах нет, то УЦ может в это поле добавить какой-нибудь номер для устранения неоднозначности. Нам же нужно не устранять неоднозначность (хватило бы и одного из наших полей), нам нужно довести до всех участников ИС конкретные значения этих ОГРН, ИНН, СНИЛС и т.п.

В общем, считаю, что язык описания идентификатор в поле serialNumber - немного надуманное решение.
Прямым способом является как раз определение таких компонентов имени RDN, как предложенные INN, OGRN и т.п. Надо только скорректировать ASN.1 определения.

Согласен с предложением перенести эти дополнительные компоненты из поля Subject сертификата в расширение SubjectAltName, в компоненту DirectoryName. Чтобы укоротить Subject, оставив в нем только общеупотребительные компоненты, прописанные в разных стандартах и европейских регламентах.

Если ещё кто-то из участников форума нас поддержит, можно будет включить в документ с нашими пожеланиями просьбу перенести компоненты ОГРН, ИНН, СНИЛС в расширение SubjectAltName, в компоненту DirectoryName. Только сомневаюсь, что нас послушают, т.к. приказ налоговой про ИНН вышел уже давно и многие его уже выполнили.

Кстати, ещё был приказ ФСС, определивший 2 свои компоненты. Их в требованиях к квалифицированному сертификату не нужно упомянуть? Кто-то этот приказ тоже уже выполнил и переносить в SubjectAltName, в компоненту DirectoryName не захочет.

Ещё вопрос. В RFC 3739 тоже идёт речь про разные компоненты имени, там довольно сложные правила, когда использовать surname, pseudonym, common name, givenname, может оттуда что-нибудь взять? Ещё в RFC 3739 описание компонент построено так: "The title attribute type SHALL, when present, be used to ..." ("Атрибут title, если добавлен, используется для..."), т.е. из описания сразу видно, что атрибут не обязательный. Может нам тоже так стоит сделать?

Предложение поправок к ASN.1 определению дополнительных компонент:

Код: Выделить всё

OGRN ::= NUMERIC STRING SIZE (13..15)
SNILS ::= NUMERIC STRING SIZE 11 -- минусы и пробелы в СНИЛС не значащие и опускаются
INN ::= NUMERIC STRING SIZE (10..12)

[murugov]

Хочу заметить что ввод в сертификат всего не характеризующее субъекта не правильно, поскольку запихивая в сертификат ИНН УЦ берёт на себя обязанность проверять этот ИНН, а ведёт то его не УЦ, а ФНС и т.д. Т.е. ФНС лёгким движением руки перевел ответственность по правильности ввода ИНН на УЦ. Правильнее и логичнее было бы обеспечить связь квалифицированного сертификата с неким набором атрибутов которые бы вело профильное ведомство. Например, сделать как это делают поляки в части указания полномочий из аналога ЕГЮРЛа (см. картинку из вложения). Опять же если рассматривать сертификат как аналог е-паспорта, то вот в паспорте не пишется ничего кроме касающейся личности. Другими словами, эта кривизна с манерой запихать в сертификат всё что не поподя - совершенно неправильно и провоцирует подмену УЦ части функциональности других ведомств, как минимум в части эмиссии этих идентификаторов, поскольку квалифицированный сертификат сходу становится носителем ИНН, ОГРН, СНИЛС .... а я не уверен что правила эмиссии этих идентификаторов соответствуют правилам обращения сертификатов. Но это всё фундаментальные посылы. Я так понимаю, что на сейчас получится очередная заплатка с костылями для совместимости с предыдущими приказами ФНС, ФСС и т.п.

[seleznev]

Есть проблема с п. 30 проекта «Требований к форме квалифицированного сертификата ключа проверки электронной подписи», в котором указано, что: «должно использоваться критичное дополнение issuerSignTool».

В то же время, в разделе «4.2. Certificate Extensions» из RFC 5280 «Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile» говорится, что системы, работающие с сертификатами, должны отвергать неизвестные им критичные расширения:

Each extension in a
certificate is designated as either critical or non-critical. A
certificate-using system MUST reject the certificate if it encounters
a critical extension it does not recognize or a critical extension
that contains information that it cannot process.

Это требование может привести к невозможности проверки подписи с использованием квалифицированного сертификата во многих существующих приложениях.

[Хвостов]

А у кого-нибудь есть предложения как связать три вида подписи с уровнями (классами) защищенности информации, защищаемой средствами ЭП владельца квалифицированного сертификата, и информации, защищаемой средствами УЦ ?
Квалифицированная подпись - это какой класс средств ЭП владельца сертификата и средств УЦ?
В каком документе это должно быть?

С уважением

А. Хвостов

[seleznev]

Рекомендуем добавить расширение
2.5.29.16
Период использования закрытого ключа

[murugov]

Поддерживаю, "Период использования закрытого ключа" - это весьма важно чтоб работали краткосрочные е-архивы на 7-15 лет.

[murugov]

А у кого-нибудь есть предложения как связать три вида подписи с уровнями (классами) защищенности информации, защищаемой средствами ЭП владельца квалифицированного сертификата, и информации, защищаемой средствами УЦ ?
Квалифицированная подпись - это какой класс средств ЭП владельца сертификата и средств УЦ?
В каком документе это должно быть?

С уважением

А. Хвостов

Мне кажется, что связывать не надо.
1. Простая подпись - это любой АСП который стороны договорились принимать, к ЭЦП это ни имеет никакого отношения, просто дань формальности, типа в ЕС такое есть теперь будет и у нас, хотя никто не мешал и раньше её использовать хоть по 160 Ст. ГК. Так что на счёт простой подписи заморачиваться (на мой взгляд) не стоит - умрёт сама собой.
2. Усиленная - в рамках PGP или неквалифицированная (Х.509) или видимо VPN - опирается на соглашения сторон - т.е. как договоришься такой класс и будет хоть КА1.
3. Квалифицированная - контора (судя по вброшенному документу) думает что подпись и классы не связаны вообще, поскольку рисуется диапазон КС1-КА1. Кроме бардака это не внесёт точно ничего, поскольку презумпция действительности квалифицированной подписи будет нарушена - появляется параметр - класс защищенности, который надо учитывать при принятии решения подпись верна или нет, а это уже не презумпция действительности! Кроме того, мне кажется, что вписывание классов противоречит 63-Фз Ст. 6

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

Т.е. тут не говорится не про какие классы, если есть квалифицированный сертификат + средство подписи (видимо сертифицированное) - то всё - подпись равнозначна собственноручной.
Хотя тут можно разыграть и вот такую норму из того же 63-ФЗ из статьи 11

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

т.е. класс защищённости - это приравнено к ограничениям, но тогда со мной надо предварительно договорится-согласовать какой класс принимается в каждой конретной системе и это точно противоречит Статьи 6 того же 63-ФЗ. Кстати, 63-ФЗ допускает что ограничений можеть быть не наложено, но в случае с классами защищенности из приведённого Профиля эта норма не сработает никогда.

[igus]

Еще несколько замечаний:

1. П/п 8 п.2 ст.17 ФЗ предусматривает включение в сертификат "иной информации о владельце квалифицированного сертификата (по требованию заявителя)". Обращаю внимание - "по требованию заявителя". То есть я, получая сертификат в УЦ, могу ПОТРЕБОВАТЬ, чтобы в сертификат включили мой литературный псевдоним, и УЦ ОБЯЗАН его туда включить. Соответственно, УЦ всегда должен иметь техническую возможность это сделать. Поэтому необходимо предусмотреть стандартное расширение для "иной информации о владельце квалифицированного сертификата".

2. Из приложений к Проекту можно догадаться, что в случае выпуска сертификата для юр.лица в поля <title> <surname> <givenName> необходимо поместить данные об уполномоченном представителе юридического лица. Это, конечно же, логично, что вот что про это нужно догадываться - неправильно, об этом должно быть явно написано в пп.17.3, 17.4 и 17.10.

3. В ФЗ написано "наименования средств электронной подписи и средств аккредитованного удостоверяющего центра, которые использованы для создания ключа электронной подписи, ключа проверки электронной подписи, квалифицированного сертификата", без конкретизации, кто за что отвечает. В п.30 Проекта средства ЭП и средства УЦ разнесены по разным полям, а выполняемые ими функции скопированы из ФЗ as is, и получается, что средства ЭП у нас создают сертификаты.
Правильно было бы использовать следующие формулировки:
- средство ЭП, которое было использовано для создания ключа ЭП и ключа проверки ЭП;
- средство аккредитованного УЦ, которое было использовано для создания квалифицированного сертификата.

[igus]

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

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

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