Oid организации. Плохая подпись Подпись не прошла проверку Отсутствует объектный идентификатор OID

Вадим Малых
02.10.2013

Некоторое время назад в группе « Forum Rus» на фейсбуке произошла дискуссия по вопросам применения в информационных системах органов власти (обсуждение было не по теме топика, можно посмотреть в нижних комментариях). Суть спора — из-за OID"ов (object identifier - идентификатор объекта) информационных систем, которые необходимо прописывать в квалифицированных сертификатах электронной подписи (ЭП) должностных лиц, эти самые ЭП приходится менять даже чаще чем раз в год (что диктуется требованиями безопасности), а это, в свою очередь, ведет к дополнительным сложностям и издержкам, так как большинство органов работают с коммерческими УЦ, не имея собственных. Проблема усугубляется отсутствием общего понимания, что именно эти OID дают и насколько они необходимы и/или обязательны.

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

Если начинать с базовых понятий, электронное подписание основывается на асимметричных алгоритмах шифрования. Основная особенность этих алгоритмов в том, что для шифрования и расшифровки сообщения используются два разных ключа. Широкой общественности более знакомы симметричные алгоритмы, когда одним ключом (или паролем) мы и шифруем и расшифровываем сообщение, например архивируем файл с паролем или защищаем документ MS Word.

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

При чем тут собственно подпись? Ведь нам надо подписать документ, а не зашифровать его. Для начала надо разобраться, что такое собственно подпись и для чего она нужна. Когда вы ставите свою собственноручную подпись на бумажный документ, вы тем самым заверяете, что именно вы (а не кто-то другой) видели (и согласны) именно этот документ (а не какой-то другой). Важнейшее свойство подписи — неотрекаемость (non-repudiation). Это означает, что подписав документ, вы не можете позже отказаться от этого факта. В случае бумажной подписи вас уличит графологическая экспертиза, в случае электронной — математические методы, основанные на асимметричных алгоритмах шифрования.

Как все это работает, в двух словах. Берем асимметричный алгоритм шифрования, генерируем пару ключей (для шифрования и расшифровки). Ключ шифрования даем человеку, который будет подписывать документы. Он его должен всегда держать при себе и никому не давать. Поэтому его называют «закрытый» ключ. Другой ключ (расшифровки) даем всем желающим, поэтому он «открытый». Подписывая документ, человек должен зашифровать его своим закрытым ключом. На самом деле шифруется не сам документ, так как он может быть достаточно большим, а нам вообще-то и не нужно его шифровать. Поэтому по документу получают хэш — это некая числовая последовательность с большой долей вероятности разная для разных документов, как бы «отпечаток» документа. Его и шифруют закрытым ключом подписанта. Этот зашифрованный хэш и есть электронная подпись документа. Теперь имея документ, подпись и открытый ключ, любой может легко проверить, что именно этот документ был подписан именно этим закрытым ключом. Для этого снова получаем хэш документа, расшифровываем открытым ключом подпись и сравниваем. Должны получить две идентичные числовые последовательности.

Все это прекрасно, но пока мы получили неотрекаемость подписи для закрытого ключа, то есть доказали, что документ подписан конкретным ключом. Нам же необходимо доказать, что он был подписан конкретным человеком. Для этого существуют удостоверяющие центры и цифровые сертификаты. Самое важное, что делает удостоверяющий центр — он удостоверяет, что закрытый ключ принадлежит конкретному лицу. Чтобы это гарантировать, именно удостоверяющий центр генерирует пары ключей и выдает их лично в руки владельцам (есть варианты по доверенности, удаленно, но это уже детали). Вместе с ключами генерируется цифровой сертификат — это электронный документ (бывает и бумажное его представление), в котором содержится информация о владельце ключа, самом ключе, удостоверяющем центре и некоторая другая информация. Владелец, как правило, получает все это добро на защищенном носителе (смарт-карте, ру-токене и так далее), на котором содержится закрытый ключ и сертификат с внедренным открытым ключом. Сам носитель необходимо всегда держать при себе, а скопированный с него сертификат с открытым ключом можно давать всем желающим, чтобы они могли проверить вашу электронную подпись.

Итак, подписание производится закрытым ключом, а проверка подписи открытым. Поэтому фраза «документ подписывается набором OID» (прозвучавшая в упомянутом споре) лишена всякого смысла. В процедуре подписания и проверки участвуют только два ключа, в 63-ФЗ они и названы соответственно — ключ подписи и ключ проверки подписи.

А что такое эти пресловутые OID? Формат цифрового сертификата X.509 позволяет сохранять в нем расширения (extensions). Это некие необязательные атрибуты, при помощи которых можно хранить дополнительную информацию. Каждый такой атрибут является объектом, который задается идентификатором из иерархического справочника. Отсюда OID — Object Identifier. Углубляться в природу самих OID здесь смысла нет. По сути это некоторая дополнительная информация, которая может присутствовать в сертификате.

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

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

В мире эти два вида сертификатов называются соответственно Public Key Certificate (PKC) и Attribute Certificate (или Authorization Certificate - AC). Сертификат второго рода может выпускаться гораздо чаще первого, другой организацией и должен быть доступнее и проще в получении, чем персональный сертификат «открытого ключа». Во всяком случае, так рекомендует RFC 3281, посвященный этому виду сертификатов. Сертификат второго рода должен содержать лишь ссылку на сертификат открытого ключа, чтобы система, использующая его для авторизации пользователя, могла сначала идентифицировать персону при помощи PKC.

Теперь перенесемся ближе к нашим реалиям. На законодательном уровне вопросы, связанные с применением электронной подписи в Российской Федерации, регулируются двумя основными документами — законом РФ от 06.04.2011 №63-ФЗ «Об электронной подписи» и приказом ФСБ РФ от 27.12.2011 №795 «Об утверждении требований к форме квалифицированного сертификата ключа проверки электронной подписи». Состав квалифицированного сертификата описан в 795-м приказе (ч. II «Требования к совокупности полей квалифицированного сертификата») и в нем нет требований к атрибутам, управляющим авторизацией в каких-либо информационных системах. В качестве дополнительных обязательных атрибутов указаны лишь сведения, позволяющие идентифицировать физическое или юридическое лицо в РФ (ИНН, СНИЛС и т. д.). Хотя ни закон ни приказ ФСБ не запрещают включать в квалифицированный сертификат другие сведения.

Как видим, никакие законодательные нормы не диктуют обязательного наличия в квалифицированном сертификате атрибутов, связанных с авторизацией в каких-либо информационных системах. Откуда тогда эти требования берутся? А исходят они от разработчиков (или «владельцев») конкретных систем. Возьмём например «Методические рекомендации по использованию электронной подписи при межведомственном электронном взаимодействии (версия 4.3)», размещенные на технологическом портале СМЭВ. Действительно, в пункте 6 данного документа читаем: «При подготовке сведений для формирования сертификата ЭП-СП необходимо определить необходимость запроса сведений из Росреестра (выписки из ЕГРП). При необходимости такого запроса в поле “Улучшенный ключ” (OID=2.5.29.37) в сертификате ЭП-СП должен быть указан OID по требованиям Росреестра.». То есть информационная система Росреестра использует этот атрибут для определения сведений, которые можно выдавать владельцу сертификата. Однако этот же документ содержит важное примечание, а именно — данное требование действует до полного запуска ЕСИА (единый сервис авторизации в гос. системах) и подключения к ней системы Росреестра. Это важное замечание, запомним его.

Не буду разбираться с другими ИС, применяемыми в гос. органах. Подозреваю, что там ситуация похожая. Портал госзакупок, электронные торговые площадки, различные бухгалтерские и финансовые приложения также могут требовать наличия тех или иных дополнительных OID в сертификате пользователя. При этом утверждение, что прописывая OID информационной системы в сертификате, я каким-либо образом делегирую ответственность удостоверяющему центру, мягко говоря, неверно. УЦ вносит эти данные в сертификат согласно моей заявки. Если у меня изменилась должность, а я забыл подать заявку на отзыв старого и выпуск нового сертификата, УЦ никак не может отвечать за мою забывчивость. К тому-же закон 63-ФЗ прямо закрепляет ответственность за неправильное использование сертификата за его владельцем. В пункте 6 статьи 17 читаем:
Владелец квалифицированного сертификата обязан:
1) не использовать ключ электронной подписи и немедленно обратиться в аккредитованный удостоверяющий центр, выдавший квалифицированный сертификат, для прекращения действия этого сертификата при наличии оснований полагать, что конфиденциальность ключа электронной подписи нарушена;
2) использовать квалифицированную электронную подпись в соответствии с ограничениями, содержащимися в квалифицированном сертификате (если такие ограничения установлены).

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

Налицо стопроцентное попадание в концепцию, именуемую в мире Attribute Certificate (или Authorization Certificate), о которой говорилось выше и при которой рекомендуется выпускать эти сертификаты другим удостоверяющим центром (Attribute Autority, в отличие от Certificate Authority — обычного УЦ, выпускающего квалифицированные сертификаты ЭП) и по упрощенной схеме. Этот сертификат сам по себе не должен содержать ключа электронной подписи и информации о владельце. Вместо этого он содержит ссылку на сертификат открытого ключа владельца, из которого можно получить остальную необходимую информацию о персоне.

Необходимо заметить, что и эта схема имеет весьма ограниченное применение и не решает всех проблем. Что если очередная информационная система решит использовать то-же поле сертификата “Улучшенный ключ” (OID=2.5.29.37), которое уже занято значением Росреестра, для своих нужд? Вписать два разных значения в одно поле не получится. Следовательно придется выпускать ещё один AC! Другая проблема связана с коротким временем жизни PKC (один год). Если имеем несколько AC (в которых содержится ссылка на персональный сертификат), их все придется перевыпустить по истечении срока PKC. Для эффективного применения AC необходим некий единый центр авторизации пользователей во всех информационных системах, а все приложения должны согласованно и единообразно использовать атрибуты сертификатов.

Такой единый центр авторизации для гос. органов уже есть — это ЕСИА. Вспомним про примечание, касающееся OID"ов Росреестра. В будущем они будут заменены информацией из ЕСИА. Так же должны поступать и прочие информационные системы, в которых работают гос. служащие. Вместо использования AC для авторизации, необходимо интегрироваться с ЕСИА и получать необходимую информацию оттуда. ЕСИА должна иметь возможность привязки квалифицированного сертификата ЭП к учетной записи, таким образом информационные системы смогут проводить аутентификацию пользователя по персональному ключу, а его авторизацию (предоставление доступа к приложению) через ЕСИА. Такая система представляется универсальней и надежней, чем применение полей сертификатов, а в перспективе позволит автоматизировать управление доступами. Если будет создана единая система кадрового учета гос. служащих, ЕСИА сможет брать информацию о полномочиях того или иного лица непосредственно оттуда. Перевелся человек на другую должность — автоматически потерял доступ к одним системам и получил к другим. При этом он продолжает пользоваться своим ключом ЭП для подписания документов, ничего перевыпускать не нужно.

В соответствии с Техническими условиями осуществления ЗАО «АЭИ «ПРАЙМ» действий по раскрытию информации о ценных бумагах и об иных финансовых инструментах, утвержденными Банком России (), электронные документы, содержащие публичную информацию должны быть подписаны субъектом раскрытия информации усиленной квалифицированной электронной подписью (см. п. 1.7 Техусловий). Данное требование вступает в силу, начиная с 1 февраля 2017 г.

В настоящее время на сервере раскрытия «ПРАЙМ» начался тестовый период для применения электронной подписи, который продлится до 31 января 2017 г. включительно.

Для тестирования функционала клиенты «ПРАЙМ» могут использовать любой сертификат ключа ЭП, полученный на данное юрлицо ранее.

С 1 февраля 2017 г. по требованию Техусловий (см. п. 1.7. и 9.6.) квалифицированный сертификат ключа проверки электронной подписи пользователя должен соответствовать требованиям к форме квалифицированного сертификата, установленного приказом ФСБ России от 27 декабря 2011 г. №795 «Об утверждении Требований к форме квалифицированного сертификата ключа проверки электронной подписи». Расширение сертификата пользователя «Улучшенный ключ» (объектный идентификатор 2.5.29.37) должно содержать объектный идентификатор на раскрытие информации ПРАЙМ - OID 1.2.643.6.42.5.5.5

Вход в личный кабинет пользователя раскрытия информации «ПРАЙМ» будет осуществляться по ранее полученному клиентом ЛОГИНУ и ПАРОЛЮ.

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

Для применения ЭП на сервере раскрытия информации «ПРАЙМ» клиенту необходимо предварительно установить плагин (установка бесплатна для пользователей и не занимает много времени). Инструкцию по установке плагина см. ниже.

В личном кабинете пользователя раскрытия информации после установки клиентом плагина при заполнении форм для публикации сообщения в Ленте раскрытия информации или размещении документа в сети Интернет, а также при изменении данных регистрационной карточки появятся дополнительные поля «Электронная подпись документа», где необходимо будет выбрать отображенный в соответствующем служебном поле сертификат ключа подписи и нажать кнопку «Подписать». Таким образом клиент будет подтверждать свои действия по раскрытию информации или внесению изменений в свою регистрационную карточку.

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

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

В остальном порядок действий эмитента в личном кабинете на сервере раскрытия информации «ПРАЙМ» не меняется.

Большое спасибо, Михаил, все сделали оперативно а главное понятно для меня... Так как мы с вами нашли общий язык. хотелось бы в дальнейшем так же продолжить связь именно с вами. Надеюсь на плодотворное сотрудничество.

Олеся Михайловна - генеральный директор ООО "ВКС"

От имени предприятия ГУП "Севастопольское авиационное предприятие" выражаем благодарность за профессионализм и оперативность вашей компании! Желаем вашей компании дальнейшего процветания!

Гуськова Лилия Ивановна - менеджер. ГУП "САП"

Спасибо вам, Михаил, большое за помощь в оформлении. Очень квалифицированный сотрудник +5!

Надия Шамильевна - предприниматель ИП Аношкина

От лица компании "АКБ-Авто" и от себя лично выражаю Вам и всем сотрудникам вашей компании благодарность за продуктивную и качественную работу, чуткое отношение к требованиям клиента и оперативность в исполнении заказываемых работ.

Насибуллина Альфира - Старший менеджер "АКБ-Авто"

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

Ольга Севостьянова.

Приобретение ключа оказалось очень лёгким и, даже, приятным. Огромная благодарность за содействие менеджеру Михаилу. Объясняет сложные и массивные для понимания вещи ёмко, но очень понятно. К тому же я позвонил на горячую бесплатную линию и в режиме он-лайн, вместе с Михаилом оставил заявку. Мне изготовили ключ через 2 рабочих дня. В общем, рекомендую если экономите своё время, но в тоже время хотите иметь понимание - что покупаете и за что платите. Спасибо.

Левицкий Александр Константинович г. Самара

Личная благодарность консультанту Михаилу Владимировичу за оперативную консультацию и работу по ускоренному получению сертификата ЭП. В ходе предварительной консультации подбирается оптимальный набор индивидуальных услуг. Конечный результат получен незамедлительно.

Стоянова Н.Л. - главный бухгалтер ООО "СИТЕКРИМ"

Спасибо за оперативную работу и компетентную помощь! Консультацией остался очень доволен!

Дмитрий Фомин

ООО "Эксперт Система" благодарит за оперативную работу консультанта Михаила! Желаем Вашей компании роста и процветания!

Суханова М.С. - Оценщик ООО "Эксперт Система", г. Волгоград

Спасибо консультанту, представившемуся Михаилом, за оперативность в работе с клиентами.

Пономарев Степан Геннадьевич

Большое спасибо консультанту Михаилу, за оказанную помощь в получении ЭЦП. За оперативную работу и консультирование по вопросам возникающим в процессе оформления.

Леонид Некрасов

Компания в лице консультанта Михаила делает невозможное! Ускорение аккредитации менее чем за 1 час! Оплата по факту оказания услуги. Думал, такого не бывает. С полной ответственностью могу советовать связываться с Центром выдачи электронных подписей.

Общие положения.
Выбор способа представления тех или иных данных и дополнительных ограничений на состав полей сертификата основан на следующих принципах:
Международные рекомендации. Настоящий документ разработан с учетом международных рекомендаций:
- RFC 3280 (в обновление к RFC 2459) Internet X.509 Public Key Infrastructure. Certificate and Certificate Revocation List (CRL) Profile.
- RFC 3039 Internet X.509 Public Key Infrastructure. Qualified Certificate Profile - в данном RFC предлагаются общие требования к синтаксису (составу) сертификатов, использование которых юридически значимо.

Состав и назначение полей сертификата.

В данном разделе приводится описание основных полей сертификата открытого ключа, соответствующего Закону "Об электронной цифровой подписи" от 10.01.2002.

Используемые в разделе понятия, обозначения и терминология основаны на RFC 3280 и RFC 3039, которые, в свою очередь, базируются на Рекомендации ITU-T X.509 версии 3. Содержание раздела не копирует содержание указанных документов, а лишь обозначает отличия и особенности использования полей сертификата, реализующие требования к составу сертификата ЭЦП, изложенные в статье 6 Закона об ЭЦП.

Для всех полей сертификата, которые подразумевают русскоязычные строковые значения, предпочтительнее использовать универсальную кодировку UTF-8 (тип UTF8String).

Целью раздела является определение состава и назначения полей сертификата без учета требований конкретного удостоверяющего центра. Документы, регламентирующие работу удостоверяющего центра, могут ограничивать состав полей сертификата и набор атрибутов, используемых для идентификации УЦ и владельцев сертификатов ключей подписи.

Version
Все выпускаемые сертификаты должны иметь версию 3.

SerialNumber
Поле serialNumber должно содержать "... уникальный регистрационный номер сертификата ключа подписи" (ст.6, п.1, абз.1). Уникальность номера сертификата должна соблюдаться в рамках данного удостоверяющего центра (УЦ).

Validity
Поле validity должно содержать "... даты начала и окончания срока действия сертификата ключа подписи, находящегося в реестре удостоверяющего центра" (ст.6, п.1, абз.1).

SubjectPublicKeyInfo
Поле subjectPublicKeyInfo должно содержать "... открытый ключ электронной цифровой подписи" (ст.6, п.1, абз.3).

Issuer
ФЗ "Об ЭЦП" предполагает выдачу сертификатов только физическим лицам, это положение касается и сертификатов самих УЦ и сертификатов ресурсов. Для соблюдения формальных требований ФЗ предлагается в сертификатах УЦ и ресурсов в атрибутах указывать реальную информацию организации считая, что такой сертификат выдан уполномоченному физическому лицу УЦ или Ресурса и указанная информация должна трактоваться и регистрироваться как сертификат на псевдоним, что допускает ФЗ "Об ЭЦП".
Поле issuer должно однозначно идентифицировать организацию, выпустившую сертификат, и содержать официально зарегистрированное наименование организации.
Для идентификации могут использоваться следующие атрибуты:

countryName	{id-at 6}
stateOrProvinceName	{id-at 8}
localityName	{id-at 7}
organizationName	{id-at 10}
organizationalUnitName	{id-at 11}
postalAddress	{id-at 16}
serialNumber	{id-at 5}

Поле issuer должно обязательно включать атрибуты, описывающие "наименование и место нахождения удостоверяющего центра, выдавшего сертификат ключа подписи" (ст.6, п.1, абз.5).

Наименование должно указываться в атрибуте organizationName. При использовании атрибута organizationName может

Местонахождение удостоверяющего центра может указываться с помощью набора атрибутов countryName, stateOrProvinceName, localityName (каждый из которых является необязательным) либо с помощью единственного атрибута postalAddress. Любым из указанных способов местонахождение УЦ должно обязательно присутствовать в сертификате.

должен содержать юридический адрес удостоверяющего центра. Пробел (символ "0x20") должен использоваться в качестве разделителя.

Атрибут поля subject serialNumber должен использоваться при коллизии имен.

Subject
Для представления DN (Distinguished Name - отличительное имя) владельца сертификата могут использоваться следующие атрибуты:

countryName	{id-at 6}
stateOrProvinceName	{id-at 8}
localityName	{id-at 7}
organizationName	{id-at 10}
organizationalUnitName	{id-at 11}
title	{id-at 12}
commonName	{id-at 3}
pseudonym	{id-at 65}
serialNumber	{id-at 5}
postalAddress	{id-at 16}

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

Поле subject должно обязательно содержать следующие сведения: "фамилия, имя и отчество владельца сертификата ключа подписи или псевдоним владельца" (ст.6, п.1, абз.2).

Фамилия, имя и отчество владельца должны содержаться в атрибуте commonName и совпадать с указанными в паспорте. Пробел (символ "0x20") должен использоваться в качестве разделителя.

Псевдоним владельца должен содержаться в атрибуте pseudonym.

Использование одного из этих атрибутов исключает использование другого.

Остальные атрибуты являются необязательными.

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

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

Атрибут title, согласно RFC 3039, должен включаться в расширение subjectDirectoryAttributes. Однако настоящим документом (и RFC 3280) допускается его включение в поле subject.

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

Наименование организации должно указываться в атрибуте organizationName. Значение атрибута должно совпадать с записью наименования организации в учредительных либо иных равнозначных документах. При использовании атрибута organizationName может также использоваться атрибут organizationalUnitName.

Местонахождение организации может указываться с помощью набора атрибутов countryName, stateOrProvinceName, localityName (каждый из которых является необязательным) либо с помощью единственного атрибута postalAddress.

Атрибут postalAddress, в случае его использования, должен содержать юридический адрес организации либо адрес прописки владельца сертификата ключа подписи (для физического лица).

При наличии атрибута organizationName атрибуты countryName, stateOrProvinceName, localityName и postalAddress должны интерпретироваться как местонахождение организации.

Необязательные атрибуты поля subject (countryName, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress) могут быть включены, если это определено регламентом работы УЦ, вместо поля subject в расширение subjectDirectoryAttributes (см. п 3.8.1). В этом случае они не должны включаться в subject и не могут быть использованы для различения владельцев сертификатов ключей подписи.

Атрибут serialNumber должен включаться в поле subject сертификата при коллизии имен. Он также может включаться, если это определено регламентом работы удостоверяющего центра.

Атрибут serialNumber может :

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

Обязательные расширения
должны входить следующие расширения:
- KeyUsage {id-ce 15}
- CertificatePolicies {id-ce 32}
1. KeyUsage
  Для того чтобы сертификат мог быть использован для проверки цифровой подписи, в расширении keyUsage должны быть установлены биты digitalSignature(0) и nonRepuduation(1).
  CertificatePolicies
  Расширение certificatePolicies предназначено для определения области юридически значимого применения сертификата.
  "... наименование средств ЭЦП, с которыми используется данный открытый ключ..." (ст.6, п.1, абз.4), "... сведения об отношениях, при осуществлении которых электронный документ с электронной цифровой подписью будет иметь юридическое значение..." (ст.6, п.1, абз.6) и другие данные, регламентирующие порядок получения и использования сертификатов ключей подписи, могут быть доступны по указанному в данном расширении CPSuri (Certificate Practice Statement URI).

Необязательные расширения
В состав сертификата ключа подписи могут входить любые другие расширения. При включении в сертификат ключа ЭЦП расширений необходимо обеспечивать непротиворечивость и однозначность представленной в сертификате информации.
Настоящий документ не регламентирует использование расширений, за исключением расширения subjectDirectoryAttributes {id-ce 9}.

SubjectDirectoryAttributes
Расширение subjectDirectoryAttributes может содержать атрибуты, дополняющие информацию, представленную в поле subject.
В дополнение к атрибутам, перечисленным в RFC 3039, рекомендуется поддерживать в расширении subjectDirectoryAttributes следующие атрибуты:

qualification	{-}
countryName	{id-at 6}
stateOrProvinceName	{id-at 8}
localityName	{id-at 7}
organizationName	{id-at 10}
organizationalUnitName	{id-at 11}
title	{id-at 12}
postalAddress	{id-at 16}

"В случае необходимости в сертификате ключа подписи на основании подтверждающих документов указываются... квалификация владельца сертификата ключа подписи" (ст.6, п.2).

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

Если атрибуты countryName, stateOrProvinceName, localityName, organizationName, organizationalUnitName, title, postalAddress включены в расширение subjectDirectoryAttributes, они не должны включаться в поле subject.

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

Приложение ASN1

id-at: OID value: 2.5.4
OID description: X.500 attribute types.
id-ce: OID value: 2.5.29
OID description: Object Identifier for Version 3 certificate extensions.

2.5.4.5 id-at-serialNumber serialNumber ATTRIBUTE::= { WITH SYNTAX PrintableString(SIZE (1..64)) EQUALITY MATCHING RULE caseIgnoreMatch SUBSTRINGS MATCHING RULE caseIgnoreSubstringsMatch ID id-at-serialNumber }

(RFC 3039)
The serialNumber attribute type SHALL, when present, be used to differentiate between names where the subject field would otherwise be identical. This attribute has no defined semantics beyond ensuring uniqueness of subject names. It MAY contain a number or code assigned by the CA or an identifier assigned by a government or civil authority. It is the CA"s responsibility to ensure that the serialNumber is sufficient to resolve any subject name collisions.

2.5.4.3 - id-at-commonName

OID value: 2.5.4.3

OID description: The common name attribute type specifies an identifier of an object. A common name is not a directory name; it is a (possibly ambiguous) name by which the object is commonly know in some limited scope (such as an organization) and conforms to the naming conventions of the country or culture with which it is associated.

CommonName ATTRIBUTE::= { SUBTYPE OF name WITH SYNTAX DirectoryString {ub-common-name} ID {id-at-commonName} }

(RFC 3039 : Qualified Certificate Profile)
OID value: 2.5.4.65

pseudonym ATTRIBUTE::= { SUBTYPE OF name WITH SYNTAX DirectoryString ID {id-at-pseudonym} }

OID value: 2.5.29.17

OID description: id-ce-subjectAltName This extension contains one or more alternative names, using any of a variety of name forms, for the entity that is bound by the CA to the certified public key.

SubjectAltName EXTENSION::= { SYNTAX GeneralNames IDENTIFIED BY id-ce-subjectAltName } GeneralNames::= SEQUENCE SIZE (1..MAX) OF GeneralName GeneralName::= CHOICE { otherName INSTANCE OF OTHER-NAME, rfc822Name IA5String, dNSName IA5String, (*) x400Address ORAddress, directoryName Name, ediPartyName EDIPartyName, uniformResourceIdentifier IA5String, IPAddress OCTET STRING, registeredID OBJECT IDENTIFIER } (*) – произвольная строка. OTHER-NAME::= SEQUENCE { type-id OBJECT IDENTIFIER value EXPLICIT ANY DEFINED BY type-id }

OID value: 2.5.4.16

OID description: The Postal Address attribute type specifies the address information for the physical delivery of postal messages by the postal authority to the named object. An attribute value for Postal Address will be typically composed of selected attributes from the MHS Unformatted Postal O/R Address version 1 according to CCITT Rec F.401 and limited to 6 lines of 30 characters each, including a Postal Country Name. Normally the information contained in such an address could include an addressee"s name, street address, city, state or province, postal code and possibly a Post Office Box number depending on the specific requirements of the named object.

PostalAddress ATTRIBUTE::= { WITH SYNTAX PostalAddress EQUALITY MATCHING RULE caseIgnoreListMatch SUBSTRINGS MATCHING RULE caseIgnoreListSubstringsMatch ID id-at-postalAddress } PostalAddress::= SEQUENCE SIZE (1..ub-postal-address) OF DirectoryString {ub-postal-string}

OID value: 2.5.4.12

OID description: The Title attribute type specifies the designated position or function of the object within an organzation. An attribute value for Title is string.

Title ATTRIBUTE::= { SUBTYPE OF name WITH SYNTAX DirectoryString {ub-title} ID id-at-title } id-ce-certificatePolicies OBJECT IDENTIFIER::= { id-ce 32 } certificatePolicies::= SEQUENCE SIZE (1..MAX) OF PolicyInformation PolicyInformation::= SEQUENCE { policyIdentifier CertPolicyId, policyQualifiers SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL } CertPolicyId::= OBJECT IDENTIFIER PolicyQualifierInfo::= SEQUENCE { policyQualifierId PolicyQualifierId, qualifier ANY DEFINED BY policyQualifierId } -- policyQualifierIds for Internet policy qualifiers id-qt OBJECT IDENTIFIER::= { id-pkix 2 } id-qt-cps OBJECT IDENTIFIER::= { id-qt 1 } id-qt-unotice OBJECT IDENTIFIER::= { id-qt 2 } PolicyQualifierId::= OBJECT IDENTIFIER (id-qt-cps | id-qt-unotice) Qualifier::= CHOICE { cPSuri CPSuri, userNotice UserNotice } CPSuri::= IA5String UserNotice::= SEQUENCE { noticeRef NoticeReference OPTIONAL, explicitText DisplayText OPTIONAL} NoticeReference::= SEQUENCE { organization DisplayText, noticeNumbers SEQUENCE OF INTEGER } DisplayText::= CHOICE { visibleString VisibleString (SIZE (1..200)), bmpString BMPString (SIZE (1..200)), utf8String UTF8String (SIZE (1..200)) }

При входе в личный кабинет для запроса КЭП отображается сообщение « Компьютер не настроен. Для продолжения работы перейдите на страницу настройки компьютера и выполните предложенные действия» . После перехода на страницу настройки и установки всех необходимых компонент в личном кабинете вновь возникает сообщение о том, что компьютер не настроен.

Для устранения ошибки необходимо:

1. Добавить адрес личного кабинета https://i.kontur-ca.ru в надежные узлы. Для этого:

Выбрать меню «Пуск» > «Панель управления» > «Свойства браузера»;
Перейти на вкладку «Безопасность», выделить элемент «Надежные узлы» (или «Надежные сайты») и нажать на кнопку «Узлы»;
Указать в поле Добавить в зону следующий узел адрес https://i.kontur-ca.ru нажать на кнопку «Добавить».

Если в списке надежных узлов уже присутствует данный адрес, следует перейти к следующему пункту.

2. Проверить, что адрес личного кабинета https://i.kontur-ca.ru определяется как надежный:

Если используется Internet Explorer версии 8, то, находясь на странице авторизации, следует проверить, стоит ли галка «Надежные узлы» внизу страницы. Если галки нет, но есть надпись « Интернет», значит адрес https://i.kontur-ca.ru не добавлен в надежные узлы.

Если используется Internet Explorer версии 9 и выше, то, находясь на странице авторизации, следует кликнуть правой кнопкой мыши в любом месте страницы, выбрать «Свойства». В открывшемся окне в строке «Зона» должна содержаться надпись «Надежные сайты». В противном случае адрес https://i.kontur-ca.ru не добавлен в надежные узлы.

Если адрес личного кабинета не определяется как надежный, то следует обратиться к системному администратору с просьбой добавить адрес https://i.kontur-ca.ru в надежные узлы.

3. Проверить, удается ли зайти в Личный кабинет. Если ошибка повторится, то следует запустить утилиту RegOids по ссылке . Данная утилита автоматически настроит параметры OID в реестре компьютера. Также можно вручную импортировать одну из веток реестра в зависимости от разрядности установленной операционной системы:

4. Проверить, что на компьютере используются права администратора (чтобы проверить, перейдите в Пуск — Панель управления — Учётные записи пользователей и семейная безопасность — Учётные записи пользователей ). Если прав недостаточно, необходимо дать пользователю полные права, для этого обратитесь к вашему администратору.

5. После выполнения пункта 3, необходимо перезагрузить компьютер и проверить вход в Личный кабинет.

Если ни один пункт инструкции не помог, то следует обратиться в техническую поддержку по адресу [email protected]. В письме необходимо указать:

1. Номер диагностики.

Для этого необходимо зайти на портал диагностики по адресу https://help.kontur.ru , нажать кнопку « Начать диагностику». Как только процесс проверки закончится, на экране отобразится номер диагностики. Присвоенный номер обращения указать в письме.

2. Скриншот окна с ошибкой (при использовании Internet Explorer версии 9 и выше также необходимо приложить скриншот окна «Свойства» — см. пункт 2).

3. Экспортировать и приложить следующие ветки реестра:

32-bit: HKLM\SOFTWARE\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo
64-bit: HKLM\SOFTWARE\Wow6432Node\Microsoft\Cryptography\OID\EncodingType 0\CryptDllFindOIDInfo