476-ФЗ и получение КСКПЭП в УЦ ФНС для ИП и юрлиц

Добро пожаловать, Гость! Чтобы использовать все возможности Вход или Регистрация.

Уведомление

Error

476-ФЗ и получение КСКПЭП в УЦ ФНС для ИП и юрлиц

Опции

Предыдущая тема Следующая тема

Ahmier		#1 Оставлено : 20 декабря 2021 г. 4:11:52(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 30.01.2020(UTC) Сообщений: 8 Сказал(а) «Спасибо»: 1 раз		Кто в курсе как там в налоговой инспекции всё организовано технически? Можно ли получить КСКПЭП по распределённой схеме, без того чтобы непонятно-кому отдавать свой токен с ПИН-кодом (проще говоря "отдаться"). Прочитал регламент Вроде регламент явно предусматривает вариант самостоятельного изготовления ключей заявителем: Цитата: Процедура создания ключей ЭП и ключей проверки ЭП в УЦ ФНС России ... 11. Создание ключа ЭП и ключа проверки ЭП осуществляется самостоятельно лицом, обратившимся за получением КСКПЭП следующими способами: на его автоматизированном рабочем месте (далее – АРМ) с использованием собственных сертифицированных средств криптографической защиты информации ... Но процедура предусматривает также и "предоставление" работнику ФНС самого токена: Цитата: Процедура создания и выдачи КСКПЭП ... 22. Создание КСКПЭП осуществляется на основании заявления на КСКПЭП, которое формируется: ... в) в иных информационных системах. В пунктах выдачи УЦ ФНС России заявителем предоставляется носитель ключевой информации, оснащенный интерфейсом универсальной последовательной шины (ТИП А), сертифицированный ... (про ПИН-код правда ничего не сказано) Понятно, что носитель им нужен как минимум для проверки его "сертифицированности", но в регламенте не предусмотрен "запрос на сертификат" или хотя-бы вообще передача им открытого ключа каким-то другим образом. У меня Рутокен ЭЦП 2.0 Touch (ФСБ), и на нём технически можно открытый ключ смотреть без ПИН-кода. Для записи сертификата на токен тоже ПИН-код не требуется. Но почему-то кажется, что ПО у них заточено на "стандартную" процедуру с втыканием токена, вводом дефолтного ПИН-кода и генерацией запроса на сертификат. И всем пофигу, что у меня на этом токене может еще десяток других ключевых пар и я никому не хочу даже на минуту давать к ним доступ. И даже без этого, к своей ключевой паре я не хочу предоставлять доступ кому попало. Но еще мне кажется, что после того как я им скажу ПИН-код (или мне придётся установить дефолтный 12345678), то мне просто запишут обычный криптопрошный контейнер с "неэскпортируемым" ключем и класть они хотели на "защищённый" носитель, мой встроенный аппаратный криптопровайдер, мою новенькую ключевую пару с неизвлекаемым ключем и всё остальное ... А это меня не устраивает вообще, категорически. Кто знает: "ПАКМ "КриптоПро HSM" версии 2.0 (комплектация 1) (исполнение 1)" или что там у них скорее всего используется, умеет выпускать сертификат без знания ПИН-кода и доступа к закрытому ключу (допустим ключевая пара у клиента на токене уже сгенерирована)? Или может быть это невозможно принципиально, по каким-то техническим (каким?) причинам? (я понимаю, что большинству пофиг на это всё - никто вообще со своей подписью не заморачивается и разбрасывает её куда попало) Кто уже сталкивался с работой УЦ ФНС? Посоветуйте что мне делать? Не совсем в тему, но спрошу: Кто знает что такое "владение" ключём? Что это за новое понятие такое в регламенте: Цитата: III. Права и обязанности УЦ ФНС России ... д) отказывает в создании КСКПЭП, если не подтверждено владение лицом, обратившимся за получением КСКПЭП, ключом ЭП, который соответствует ключу проверки ЭП, указанному им для получения КСКПЭП; ... Очень интересно, а как вообще у них возможно что заявитель "указал им" свой ключ проверки ЭП, да еще так, что у него на токене такого ключа не оказалось? В регламенте вообще ничего про открытый ключ нет...


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»


	Wanna join the discussion?! Login to your Форум КриптоПро forum account, or Register a new forum account.

two_oceans		#2 Оставлено : 20 декабря 2021 г. 8:15:27(UTC)
Статус: Эксперт Группы: Участники Зарегистрирован: 05.03.2015(UTC) Сообщений: 1,602 Откуда: Иркутская область Сказал(а) «Спасибо»: 110 раз Поблагодарили: 394 раз в 366 постах		Добрый день. С УЦ ФНС пока не сталкивался, но есть что ответить на некоторые пункты. Вообще я согласен с Вами, но хотел бы уточнить: 1) если на токене есть какие либо ключи, то по всем нормам после передачи кому-то токена их нужно отзывать. К слову, УЦ ФК так и делает если принесли непустой носитель. Не имеет значения, аппаратно ключи сделаны или программно - для записи ключей/аппаратной генерации в их присутствии/записи сертификата в УЦ передается только пустой носитель. Поэтому все слова про "отдаться" несколько не в кассу и чаще всего нужно следовать правилу "несколько ключей - несколько токенов". Это как раз тот случай, когда экономия может потом стоить дороже; 2) не так давно на форуме обсуждали про пароли на токены. Выяснилось, технически есть токены с несколькими паролями пользователей, однако никакой гарантии что пользователи изолированы внутри токена нет; 3) КСКПЭП - это сертификат, то есть, как я понимаю, процитированный пункт 22 - про запись готового сертификата на флэшку. Видимо, они не будут даже в контейнер его ставить, так как про контейнер, токен и пароль речи не идет. В нагрузку дадут какую-нибудь инструкцию как ставить самостоятельно. Цитата: Очень интересно, а как вообще у них возможно что заявитель "указал им" свой ключ проверки ЭП, да еще так, что у него на токене такого ключа не оказалось? 4) при создании запроса на сертификат в запросе на сертификат указывается открытый ключ, а сам сформированный запрос подписывается закрытым ключом этой же ключевой пары. УЦ должен проверить подпись сформированного запроса при помощи ключа, указанного в этом запросе. Это как раз и будет доказательством, что у подавшего запрос есть ключевая пара целиком (и открытый ключ и закрытый ключ). Цитата: В регламенте вообще ничего про открытый ключ нет... Кажется, для ответа на это мне нужно прочитать регламент целиком, а не только процитированное, там наверняка есть хотя бы про запрос на сертификат, как-то прицепленный к заявлению. Отредактировано пользователем 20 декабря 2021 г. 8:18:27(UTC) \| Причина: Не указана


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Ahmier		#3 Оставлено : 20 декабря 2021 г. 12:44:18(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 30.01.2020(UTC) Сообщений: 8 Сказал(а) «Спасибо»: 1 раз		Автор: two_oceans С УЦ ФНС пока не сталкивался, но есть что ответить на некоторые пункты. Вообще я согласен с Вами, но хотел бы уточнить: 1) если на токене есть какие либо ключи, то по всем нормам после передачи кому-то токена их нужно отзывать. К слову, УЦ ФК так и делает если принесли непустой носитель. Не имеет значения, аппаратно ключи сделаны или программно - для записи ключей/аппаратной генерации в их присутствии/записи сертификата в УЦ передается только пустой носитель. Судя по публикациям на сайте ФНС, ситуация когда заявитель ключевую пару уже сгенерировал - у них вроде ничем особенным не считается: https://www.nalog.gov.ru/rn77/news/activities_fts/11202050/ Цитата: ... Получение подписи бесплатно и экстерриториально, то есть заявитель может обратиться в любую точку УЦ ФНС России, их около 1000. Заявителю необходимо приобрести носитель, на котором будет сгенерирована подпись, то есть закрытый ключ, и затем уже выпустить сертификат. Если заявитель приносит носитель, на котором уже есть закрытая часть электронной подписи, и заявление, то процесс оформления сертификата занимает 15 минут. ... здесь же в видеоролике на 09:15 говориться о том, что закрытый ключ можно сгенерировать самостоятельно заранее Автор: two_oceans Поэтому все слова про "отдаться" несколько не в кассу и чаще всего нужно следовать правилу "несколько ключей - несколько токенов". Это как раз тот случай, когда экономия может потом стоить дороже; С моей точки зрения "отдать токен + новая ключевая пара + ПИН-код" либо если ключевую пару мне сгенерирует "кто-то" - как раз и значит - "отдаться". Про то, что у человека может на токене еще и другие ключи хранятся - это приведено в качестве "дополнительного" аргумента. Автор: two_oceans 2) не так давно на форуме обсуждали про пароли на токены. Выяснилось, технически есть токены с несколькими паролями пользователей, однако никакой гарантии что пользователи изолированы внутри токена нет; совсем не удивляет Автор: two_oceans 3) КСКПЭП - это сертификат, то есть, как я понимаю, процитированный пункт 22 - про запись готового сертификата на флэшку. Видимо, они не будут даже в контейнер его ставить, так как про контейнер, токен и пароль речи не идет. В нагрузку дадут какую-нибудь инструкцию как ставить самостоятельно. напротив - есть уверенность, что передача заявителю сертификата никаким другим способом не предусмотрена, кроме как запись ему на носитель "на месте" хотя регламент сильно упрощён и там про это ни слова Автор: two_oceans Цитата: Очень интересно, а как вообще у них возможно что заявитель "указал им" свой ключ проверки ЭП, да еще так, что у него на токене такого ключа не оказалось? 4) при создании запроса на сертификат в запросе на сертификат указывается открытый ключ, а сам сформированный запрос подписывается закрытым ключом этой же ключевой пары. УЦ должен проверить подпись сформированного запроса при помощи ключа, указанного в этом запросе. Это как раз и будет доказательством, что у подавшего запрос есть ключевая пара целиком (и открытый ключ и закрытый ключ). Цитата: В регламенте вообще ничего про открытый ключ нет... Кажется, для ответа на это мне нужно прочитать регламент целиком, а не только процитированное, там наверняка есть хотя бы про запрос на сертификат, как-то прицепленный к заявлению. К сожалению в регламенте вообще запрос на сертификат не упоминается.


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Ahmier		#4 Оставлено : 23 декабря 2021 г. 3:45:33(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 30.01.2020(UTC) Сообщений: 8 Сказал(а) «Спасибо»: 1 раз		Пока решил свою проблему, обратившись в коммерческий УЦ - один из списка "доверенных лиц" ФНС.


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

Ahmier		#5 Оставлено : 9 октября 2023 г. 21:38:25(UTC)
Статус: Новичок Группы: Участники Зарегистрирован: 30.01.2020(UTC) Сообщений: 8 Сказал(а) «Спасибо»: 1 раз		Всё-таки пришлось столкнуться лицом к лицу с УЦ ФНС. С недавних пор в регламенте УЦ ФНС произошли изменения в "порядке работы" и в регламенте. https://www.nalog.gov.ru...l_sign_basic_provisions/ РЕГЛАМЕНТ Удостоверяющего центра Федеральной налоговой службы Цитата: 3.2. Обязанности УЦ ФНС России ... 3.2.8. Отказать в создании и выдаче КСКПЭП, если заявитель (в случае самостоятельного создания КЭП) не использовал аппаратную реализацию генерации ключевых пар с помощью ключевого носителя, имеющего действующий сертификат ФСБ России. ... 4.3. Обязанности Владельца КСКПЭП ... 4.3.6. В случае самостоятельного создания КЭП предоставить в УЦ ФНС России файл запроса на изготовление КСКПЭП, формируемый заявителем в формате, установленном IETF RFC 2986 - PKCS #10. Запрос на изготовление КСКПЭП должен содержать необходимую и включаемую в КСКПЭП информацию об использованных для создания КЭП и КПЭП средствах ЭП, имеющих подтверждение соответствия требованиям, установленным Федеральным органом в области обеспечения безопасности, с соблюдением требований приказа ФСБ России от 20.04.2021 № 154 Данный файл может предоставляться лично, либо с использованием информационных систем ФНС России или Доверенного лица. В случае предоставления файла запроса через информационные системы (дистанционно) файл запроса должен быть подписан квалифицированной ЭП. В УЦ ФНС был успешно выпущен сертификат на директора ООО по распределённой схеме. Запрос на сертификат был на флэшке, готовый сертификат был записан сотрудником ФНС на эту же флэшку. Была также попытка записи сертификата сразу на токен (Рутокен ЭЦП 2.0 Touch, ПИН-код для этого не нужен), но у них ничего не получилось. Получилось создать подходящий запрос на сертификат не с первого раза, и как я понял, трудности у людей с этим уже возникали. Отдаю должное сотрудникам ФНС Когда мой запрос на сертификат у них не загрузился с предельно информативным сообщением вида "Ошибка загрузки", то после непродолжительного обсуждения ко мне подошел другой сотрудник. У него на телефоне был заснят процесс успешного создания запроса, снятый после многочисленных попыток кого-то до меня. Среди фотографий была распечатка на текстовой консоли всех полей запроса. По образу и подобию получилось сделать и у меня. Запрос на сертификат был сформирован в программе "КриптоАРМ" (версия 5.4.4) в режиме "Гост" Использовался шаблон запроса "Сертификат КЭП юридического лица (должностное лицо)" Поскольку шаблон требовал обязательно задать значение для поля "Подразделение", пришлось отредактировать файл шаблона: C:\Program Files\Digt\Trusted\Desktop\CertReqTemplateDefault.xml У меня КриптоАрм установился сразу в два каталога: C:\Program Files\Digt\Trusted\Desktop C:\Program Files (x86)\Digt\Trusted\Desktop соответственно файл шаблонов присутствует в обоих каталогах, но используется только один из них, в зависимости от запущенной версии x86 или x64 В файле ищем: "Сертификат КЭП юридического лица (должностное лицо)" для поля "Подразделение" изменяем "mandatory" на "false": Код: `<RDNEntry readonly="false" mandatory="false" hidden="false"> <OID>2.5.4.11</OID> <Name>Подразделение</Name> <Value/> <Length>64</Length> </RDNEntry>` Поскольку ключевая пара у меня к тому времени уже была, выбрал криптопровайдер "Рутокен ЭЦП 2.0" и "Использовать существующий ключевой набор". Запрос был сохранён сразу в формате DER. Распечатка полей запроса на сертификат: данные затёрты XXX, но формат и регистр символов сохранён Код: Certificate Request: Data: Version: 1 (0x0) Subject: INNLE=XXXXXXXXXX INN=XXXXXXXXXXXX - ИНН физического лица SNILS=XXXXXXXXXXX OGRN=XXXXXXXXXXXXX title=ГЕНЕРАЛЬНЫЙ ДИРЕКТОР - как в ЕГРН, буква в букву O=ООО "XXXXXX" - здесь сокращённое наименование, как в ЕГРН, буква в букву, в верхнем регистре street=УЛ XXXXXXXX, Д. XX, КВ. XX L=г. Xxxxx ST=XX - Xxxxxxxxxx область C=RU GN=ИМЯ ОТЧЕСТВО SN=ФАМИЛИЯ CN=ООО "XXXXXX" - здесь сокращённое наименование, как в ЕГРН, буква в букву, в верхнем регистре Subject Public Key Info: Public Key Algorithm: GOST R 34.10-2012 with 256 bit modulus Public key: X:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Y:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Parameter set: id-GostR3410-2001-CryptoPro-A-ParamSet Attributes: Requested Extensions: X509v3 Key Usage: critical Digital Signature, Non Repudiation, Data Encipherment, Key Agreement X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection X509v3 Certificate Policies: critical Policy: KC1 identificationKind: 0:d=0 hl=2 l= 1 prim: INTEGER :00 Signing Tool of Subject: 0:d=0 hl=2 l= 84 prim: UTF8STRING :"КриптоАРМ" (версия 5.4.4), "КриптоПРО CSP" (версия 5) Signing Tool of Issuer: 0:d=0 hl=3 l= 217 cons: SEQUENCE 3:d=1 hl=2 l= 41 prim: UTF8STRING :"КриптоПро CSP" (версия 5) 46:d=1 hl=2 l= 39 prim: UTF8STRING :СФ/121-1859 от 17 июня 2012 г. 87:d=1 hl=2 l= 90 prim: UTF8STRING :ПАК "Удостоверяющий центр "КриптоПро УЦ" версии 1.5 179:d=1 hl=2 l= 39 prim: UTF8STRING :СФ/128-1822 от 01 июня 2012 г. Signature Algorithm: GOST R 34.10-2012 with GOST R 34.11-2012 (256 bit) XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX:XX: XX:XX:XX:XX:XX:XX:XX:XX:XX:XX На мой взгляд, поле "Signing Tool of Issuer" совершенно лишнее, и надо было его тоже из шаблона удалить. Но привожу как было.


Профиль пользователя Просмотр всех сообщений пользователя Просмотр «Спасибо»

RSS Лента

Atom Лента

Пользователи, просматривающие эту тему

Быстрый переход

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

Important Information: The Форум КриптоПро uses cookies. By continuing to browse this site, you are agreeing to our use of cookies. More Details Close