Сергей Кирюшкин, 10/04/23
Корректная проверка электронной подписи – трудоемкая задача, требующая ото всех участников процесса не только погружения в проблематику, но и детального понимания значимости всех этапов работы с ЭП. Вступление в силу приказа ФСБ России от 04.12.2020 г. № 556 "Об утверждении требований к средствам доверенной третьей стороны, включая требования к используемым доверенной третьей стороной средствам электронной подписи" создало все предпосылки для корректного решения задачи проверки электронной подписи, однако практика реализации требований приказа выявила ряд неопределенностей.
Авторы:
Екатерина Ермина, ООО “Газинформсервис”
Сергей Кирюшкин, к.т.н., ООО “Газинформсервис”
При проверке электронной подписи электронного документа должна выполняться проверка действительности всех квалифицированных сертификатов ключей проверки электронных подписей из цепочки сертификатов и данных в сертификате на соответствие требованиям, установленным Федеральным законом от 06.04.2011 г. № 63-ФЗ "Об электронной подписи", а также иными принимаемыми в соответствии с ним нормативными правовыми актами. Кроме того, должны быть учтены требования к содержанию сертификатов доверенной третьей стороны и служб УЦ из цепочки сертификатов RFC 3029, RFC 3161 и RFC 6960.
Особенности проверки действительности квалифицированных сертификатов
По результатам исследований, проводимых компанией "Газинформсервис" при разработке и сертификации продуктов семейства Litoria, сотрудники компании отметили некоторые особенности проверки действительности цепочки квалифицированных сертификатов. Часть полей и атрибутов сертификата проверяются в соответствии с четко определенными требованиями, например содержание полей должно быть на русском языке с использованием символов кириллического алфавита; значение поля version (версия) должно быть равно 2; IdentificationKind используется для указания идентификатора, однозначно указывающего на то, как проводилась идентификация заявителя при выдаче СКПЭП; SNILS должен содержать 11 цифр и проходить проверку контрольной суммы. Реализация таких проверок достаточно определенна. Часть полей сертификата имеет более сложный алгоритм проверки, например атрибуты поля Subject. Рассмотрим их далее.
Требования к атрибутам поля Subject сертификата, не учитывающие особенности ведения хозяйственной деятельности как субъектов РФ, так и субъектов иностранных государств
Требования к атрибутам поля Subject сертификата изложены в приказах ФСБ России № 795 и № 31. Однако остаются следующие атрибуты, в отношении которых не установлены требования, учитывающие особенности хозяйственной деятельности как субъектов РФ, так и субъектов иностранных государств, к ним относятся stateOrProvinceName (наименование штата или области), INNLE, INN и SNILS.
- StateOrProvinceName (наименование штата или области) – в пояснении к этому атрибуту указано, что "в качестве значения данного атрибута имени следует использовать текстовую строку, содержащую наименование соответствующего субъекта Российской Федерации", однако для юридического лица иностранного государства данный атрибут должен быть заполнен наименованием региона (области), не являющегося субъектом Российской Федерации. При этом, согласно приложению 2, данное поле обязательно для указания в сертификате.
Для физического лица, являющегося индивидуальным предпринимателем, атрибут StateOrProvinceName, наряду с атрибутами LocalityName и StreetAddress, не являются обязательным, однако на практике возникают случаи, когда в ответе от СМЭВ содержатся значения для данных атрибутов. - INNLE, INN и SNILS – данные атрибуты обязательны для юридических лиц иностранных государств, их представителей, а также физических лиц иностранных государств. Однако практика применения показывает, что представители данных правовых форм не обязаны иметь ИНН и СНИЛС, зарегистрированные в РФ (несмотря на то, что возможность их получения предусмотрена). Например, если физическое лицо или юридическое лицо иностранного государства приезжает в РФ, чтобы получить квалифицированный сертификат, и уезжает в страну проживания (ведения бизнеса), оно использует экспортный вариант СКЗИ.
Возможное решение: целесообразно внести изменения в приказ ФСБ России от 27.12.2011 г. № 795 "Об утверждении требований к форме квалифицированного сертификата ключа проверки электронной подписи", предусматривающие:
- условия использования атрибута StateOrProvinceName для юридических лиц иностранных государств, а также урегулировать случаи заполнения атрибутов LocalityName и StreetAddress;
- необязательность использования атрибутов INNLE, INN и SNILS для юридических и физических лиц иностранных государств.
Ограничения при проверке сертификатов в СМЭВ и возможные пути решения
В соответствии с п 14.7 приказа ФСБ России No 556 от 04.12.2020 г. необходимо выполнять проверку для установления соответствия сведений о владельце сертификата в СМЭВ. При этом проверка должна выполняться вне зависимости от правового статуса владельца сертификата.
В текущей конфигурации СМЭВ возможно выполнить запрос на проверку следующих сведений:
- о юридическом лице: выписки из ЕГРЮЛ по запросам органов государственной власти;
- о физическом лице, являющемся индивидуальным предпринимателем: выписки из ЕГРИП по запросам органов государственной власти;
- о физическом лице: о соответствии фамильно-именной группы, даты рождения, пола и СНИЛС.
Проверка фамилии, имени, отчества и ИНН физического лица в СМЭВ не проводится, так как предоставление сведений о документе, удостоверяющем личность физического лица, и сведений о физическом лице по фамилии, имени и отчеству может выполняться только федеральным и региональным органом исполнительной власти (а не УЦ или ДТС).
Получение данных о юридических лицах иностранных государств из СМЭВ не выполняется ввиду невозможности получения таких данных из СМЭВ.
Кроме того, существуют категории данных, по которым СМЭВ будет возвращать отрицательный результат проверки:
- данные судей не пройдут проверку в СМЭВ, так как в соответствии со ст. 2 ФЗ от 20.04.1995 г. № 45-ФЗ "О государственной защите судей, должностных лиц правоохранительных и контролирующих органов" их данные подлежат государственной защите;
- данные юридических лиц, которые являются резидентами недружественных стран, могут быть скрыты в ЕГРЮЛ.
Возможное решение: обновить (дополнить) справочник СМЭВ, а также скорректировать список получателей сведений СМЭВ, дополнив его ДТС.
Еще одним препятствием при получении сведений из СМЭВ является невозможность их запроса доверенной третьей стороной (если юридическое лицо, предоставляющее услуги ДТС, не является одновременно и аккредитованным УЦ), потому что ДТС как получатель сведений СМЭВ отсутствует в перечне возможных получателей. Так, например, вышеперечисленные сведения могут получить только УЦ и федеральные и региональные органы исполнительной власти.
Согласно принятому Постановлению Правительства РФ от 10.10.2022 г. № 1797, вносящему изменения в Правила подключения организаций к СМЭВ, если необходимость взаимодействия информационных систем, подключаемых организаций с инфраструктурой электронного правительства, предусмотрена федеральными законами, актами президента РФ или актами Правительства РФ, решение о присоединении информационной системы организации к инфраструктуре принимается Минцифры в соответствии с регламентом соответствующей информационной системы инфраструктуры электронного правительства, утвержденным президиумом Правительственной комиссии по цифровому развитию.
Ввиду того, что не все изменения Постановления Правительства РФ вступили в силу, если ДТС не является одновременно аккредитованным УЦ, то при проверке данных владельца сертификата могут выполняться только проверки без подключения к СМЭВ.
Нюансы выдачи сертификатов некоторым службам УЦ и ДТС и возможные пути решения
В соответствии с п. 2 ст. 10 63-ФЗ от 06.04.2011 г. "Об электронной подписи" "участники электронного взаимодействия не вправе устанавливать иные, за исключением предусмотренных настоящим Федеральным законом, ограничения признания усиленной квалифицированной электронной подписи". В отношении сертификатов пользователей данное ограничение представляется способом избавиться от множества объектных идентификаторов (OID), которые по тем или иным причинам зачастую требовались для возможности применения в конкретной информационной системе. Однако в отношении сертификатов ДТС и служб TSP, OCSP исключение OIDов является нарушением текущих технических спецификаций (RFC, МР, формуляров на сертифицированные службы УЦ).
RFC 5280 Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (п. 4.2.1.4) определяет OID как политику, согласно которой сертификат был выпущен, и цель, для которой сертификат может быть использован. На практике объектные идентификаторы в назначении сертификата используются для определения степени доверия к сертификатам. А ДТС и службы УЦ являются службами, обеспечивающими высокий уровень доверия, а значит, их сертификаты должны изготавливаться уполномоченными на это УЦ, а их назначение должно быть идентифицировано объектными идентификаторами, как это и предполагается техническими спецификациями.
Сертификат OCSP-сервера согласно RFC и МР должен содержать OID 1.3.6.1.5.5.7.3.9, расширение ExtendedKeyUsage (EKU) должно быть помечено как критическое и содержать назначение "подпись ответов службы OCSP" (id-kp-OCSPSigning). При этом для обеспечения доверия сертификат OCSPсерверу должен выдать УЦ, выдавший проверяемый сертификат.
Согласно текущему законодательству сертификат OCSP-сервера является сертификатом для автоматического создания ЭП и в соответствии с п. 5 ст. 17.2 ФЗ от 06.04.2011 г. № 63-ФЗ "Об электронной подписи" должен выдаваться УЦ ФНС.
К подобным сертификатам также относятся сертификаты TSP-сервера и сервера проверки электронной подписи доверенной третьей стороны.
Так, сертификат TSP-сервера согласно RFC 3161 Internet X.509 Public Key Infrastructure. Time-Stamp Protocol (TSP) с учетом Р 1323565.1.044–2022 "Информационная технология. Криптографическая защита информации. Использование российских криптографических алгоритмов в протоколе штампов времени (TSP)" должен содержать OID 1.3.6.1.5.5.7.3.8, расширение EKU должно быть помечено как критическое и содержать назначение "подпись штампов времени" (id-kp-timeStamping). Отсутствие OID повлечет некорректную обработку метки доверенного времени в клиентских приложениях.
Сертификат сервера ДТС согласно RFC 3029 Internet X.509 Public Key Infrastructure. Data Validation and Certification Server Protocols с учетом проекта МР "Информационная технология. Криптографическая защита информации. Протокол сервера проверки и удостоверения данных" должен содержать OID 1.3.6.1.5.5.7.3.10, расширение EKU должно быть помечено как критическое и содержать назначение "подпись ответов службы DVCS" (id-kp-dvcs). Отсутствие данного OID является несоответствием международным рекомендациям, что крайне нежелательно для сервисов, позиционируемых для участия в трансграничных процессах.
Возможное решение: УЦ ФНС должен выдавать сертификаты серверу ДТС и службам TSP и OCSP, так как они являются сертификатами только для автоматического создания электронной подписи, но выдать такие сертификаты не может, потому что не поддерживает выдачу сертификатов с дополнительным OID, требующимся согласно техническим спецификациям.
Для синхронизации законодательства с практикой применения "служебных" квалифицированных сертификатов мы предлагаем внести следующие изменения в ФЗ от 06.04.2011 г. № 63-ФЗ "Об электронной подписи":
- В части сертификатов, используемых для автоматического подписания, исключить из перечня сертификаты служб TSP и OCSP. Данные сертификаты должен выдавать сам аккредитованный УЦ, в состав которого входят службы TSP и OCSP.
- В части невозможности использовать специальные объектные идентификаторы для ДТС и служб TSP и OCSP. Требования к наличию OID в сертификатах должны быть приведены в нормативно-технических документах (стандартах, рекомендациях по стандартизации) на соответствующий протокол.
Опыт работы компании "Газинформсервис" и УЦ "ГИС" в области PKI показывает, что сегодня существуют спорные моменты для признания проверки действительности цепочки квалифицированных сертификатов в соответствии с требованиями отечественных нормативных документов корректной, однако также есть предложения по их решению, подготовленные в том числе с учетом мнения и практического опыта экспертных организаций.
