erav3n
Вы же поняли смысл фразы, он был следующий: вероятность ошибиться у человека, который генерирует ОДИН запрос (свой собственный), гораздо меньше, чем у сотрудника, который обрабатывает МНОГО запросов.
По-поводу компрометации - это как раз легко. Представим себе что я недобросовестный сотрудник, целью которого является сбор ключей пользователей. Генерируем приватный ключ и запрос на сертификат вне ключевого носителя (т.е. вне Рутокена), затем выпускаем сертификат, объединяем ключ и сертификат и формируем .pfx (Personal Information Exchange). Импортируем ключи в Рутокен, копируем pfx к себе на носитель. Отдаем Рутокен клиенту, клиент видит надпись "Сертификат с неизвлекаемой и неэкспортируемой ключевой парой" и радуется, но у меня-то есть копия ) А клиент не подозревает что приватный ключ был сгенерирован вне защищенного носителя. Например так )
К тому же, никто не мешает УЦ сделать форму для загрузки запроса на сертификат с предварительной валидацией полей. Например, клиент из дома загружает свой запрос на сертификат, который проходит предварительную валидацию всех обязательных полей, в момент посещения офиса, предоставленные клиентом в запросе данные сравниваются сотрудником УЦ с документами. В результате экономится время. Плюс, можно сделать подачу запроса платной, например, 100-250 руб. Ошибся в букве, указал неверный ИНН - не вопрос, никто не ограничивает клиента от подачи какого угодно количества запросов. Как говорится, любой каприз за ваши деньги.
Не согласен с Вами, время как раз экономится, если я сам сформирую PKCS #10 запрос, корректно заполню сам все поля (у кого больше времени на более тщательную проверку полей, у меня, как человека которому нужно проверить всего один запрос, или у сотрудника УЦ, который оформляет в день сотни, а то и тысячи таких запросов?), отправлю его в УЦ до личного визита, а при личном визите пройду только идентификацию личности по паспорту и получу сертификат.
Вообщем с моей точки зрения, для того чтобы допустить ошибку в полях запроса в ИНН, или фамилии - это нужно сильно постараться. К тому же, даже если действительно выяснится что ошибка была допущена - сформировать новый запрос дело 1 минуты.
К тому же:
"Многие УЦ после удостоверения личности предоставляют Вам личный кабинет для онлайн выпуска электронной подписи с Вашего рабочего места."
Многие != все, т.е., а некоторые не предоставляют. Вариант в котором вы обращаетесь в УЦ, а в результате вам выдают носитель и бумажки на подпись - непреемлем по понятным причинам. Выяснять как именно происходит процесс генерации подписи в данном конкретном УЦ - на рабочем месте клиента или еще как-то - тоже потеря времени, поэтому четко обозначенная задача - получение подписи по запросу в PKCS#10, априори исключает все лишние вопросы и непреемлемые варианты.
p.s. "Не вижу смысла формирования запроса в формате PKCS #10 на носитель Рутокен ЭЦП 2.0."
Плюс, запрос формируется не на носитель (!). Запрос формируется в файл, который вы как раз и должны предоставить в УЦ, на носителе в момент генерации запроса формируется неэкспортируемая ключевая пара.
Это для случая когда у вас есть mycertfile.crt ... а если его нет, а есть только номер сертификата, то проверить отзыв можно только через CRL.
Сформировать запрос на сертификат в формате PKCS#10 можно, например, с помощью оригинальной утилиты от RuToken - https://dev.rutoken.ru/pages/viewpage.action?pageId=72451710 . Возможно для каких-то типов сертификатов (например, не для физ. лиц) понадобятся доп. шаблоны и/или поля, вся информация есть по ссылке.
Опасность в том, что я, как пользователь, должен располагать всеми ключевыми парами, от всех своих подписей, т.е. по-хорошему я должен иметь приватный ключ от этого сертификата в явном виде. И должен быть уверен, что помимо меня этого ключа нет ни у кого. В случае же с этим приложением - ключ был сгенерирован "как-то" внутри приложения, как именно и насколько надежно он там хранится - проверить не представляется возможным, также неизвестно какие операции приложение осуществляет(-ляло) с этим ключом. По-умолчанию, я предполагаю, что оно потенциально могло сделать с ним все что угодно, в том числе и передать куда-либо.
Простая аналогия - ключ от дверного замка. Вы захотели установить дверной замок и иметь один ключ от него для себя. Пришел мастер, поставил замок, отдал вам ключ, все хорошо. В процессе анализа того что получилось, внимательного чтения документов и т.п., вы узнаете, что в момент подписания договора на установку замка - оказывается был изготовлен еще один ключ. Вы не знаете мастером, фирмой, которая устанавливает замки, просто знаете что он есть. Естественно что вы захотите его уничтожить, чтобы в квартиру никто кроме вас не имел доступа. И даже если фирма, которая занимается установкой замков с государственной лицензией и т.д. и т.п., чувство беспокойства что у кого-то есть еще один ключ от вашей двери - не оставит вас, пока вы не убедитесь что дубликат ключа действительно был уничтожен.
Кстати, на ГосУслугах в web-интерфейсе баг. Отозванный вчера сертификат до сих пор отображается в списке действующих подписей, хотя по идее должен был попасть в недействующие.
Сертификат отозвали, в приложении IDPoint он отображается как недействительный. Естественно что захотелось проверить факт отзыва сертификата как-то еще. Проблема заключалась в том, что сам файл сертификата, который генерируется при использовании приложения IDPoint пользователю в явном виде не предоставляется. Поэтому пришлось скачать список отозванных сертификатов с сайта Инфотекс - CA-INFOTECS-1-2021.crl, взять OpenSSL с поддержкой ГОСТ для отображения crl в виде текста и найти там сертификат по номеру. Он действительно был отозван, причем судя по Revocation Date - в течении часа после обращения в УЦ по e-mail. Так что отозвали они вполне своевременно, однако меня об этом никак не уведомили в принципе.
(комментирую, чтобы история была до конца объективной)
Отписал в ЛС. Спасибо за обратную связь.
Александр, спасибо за информацию.
По-поводу токена, вы имеете ввиду Рутокен ЭЦП 3.0, который NFC в виде смарткарты? Я читал про него мельком, но так понял что для работы на ПК необходим отдельный ридер, что показалось не очень удобным.
Справедливости ради, добавлю еще несколько моментов:
1. Астрал все же ответил на email:
Подпись выдать можем, но вам все равно необходимо будет пройти идентификацию в точке идентификации КалугаАстрал.
Так что по крайней мере по email - они утверждают что смогут все сделать на основании PCKS#10. Действительно ли это так или нет - выяснится только при визите в точку идентификации, однако, т.к. цель достигнута и сертификат получен в другом УЦ - проверить это в ближайший год точно не получится.
2. Что касается Инфотекс, то "счастье" при общении с поддержкой по-видимому закончилось. После того как выяснилось что в процессе оформления КЭП было выдано два сертификата, как и говорил, я отправил заявление на отзыв второго. Однако, ответ по данному заявлению отсутствует уже длительное время. Хотя вопросы с отзывом как раз, должны решаться более оперативно, в идеале - незамедлительно.
Владислав, С какой-то точки зрения вы правы, но с другой стороны - я не говорил что готов был потратить на получение КЭП - 900 руб. и ни копейкой больше. Возможно я бы оплатил услугу "ускоренного получения КЭП" / услугу "персонального менеджера", назвать можно как угодно, смысл в том, чтобы адекватный сотрудник постарался вникнуть в суть проблемы, пусть даже и за дополнительную плату. Если бы подобная услуга вообще была бы предложена - однако, увы, ничего подобного никто даже и не попытался предложить.
К тому же, предполагая что подобные запросы в принципе могут быть, никто не мешал УЦ сделать доп. услугу - выпуск сертификата на основе PKCS#10 за X руб. или выпуск КЭП на носителе с поддержкой аппаратной криптографии за Y руб. Где X и Y существенно больше 900 руб., однако, таких услуг, увы, тоже не предоставляется.
Более того, Тензор ответил в стиле "А у нас только Рутокен Lite", не хотите, не берите, что тоже не представляется правильным.
На самом деле наиболее адекватным во всей этой истории выглядит ответ УЦ АйтиКом. Но т.к. подпись я уже успел получить в УЦ Инфотекс, то в статье преимущественно про него, поэтому и оговорка.
Намекаете на то что будут ошибки при заполнении полей? Я думаю что не будут, т.к. никто не мешает найти любой сертификат и посмотреть какие поля в нем есть и как именно они заполняются. Ну, например, что в поле S (регион) нужно написать не "Хабаровский край", например, а "27 Хабаровский край" нетрудно догадаться по образцу. Также легко гуглятся всякие "Правила заполнения заявлений на создание сертификатов ключей
проверки электронной подписи" ... АйтиКом, к примеру, запросили у меня пример запроса для проверки - оказалось что я с первого раза заполнил все без ошибок, хотя до этого сертификаты КЭП в глаза не видел.