В Москве не умеют работать с электронными подписями и документами
Да, согласны, заголовок провокационный и не про всю Москву мы, конечно, будем говорить))
Казалось бы, столица - это пример продвинутости и готовности к инновациям. Но это не всегда так.
Сегодня поделимся историей, которая произошла в течение последней недели.
Есть информационная платформа «PRO.Культура.РФ», которая позволяет
учреждениям культуры анонсировать мероприятия на портале «Культура.РФ» и страницах других партнеров проекта. В том числе для того, чтобы пользователи Пушкинской карты (а это молодежь) могли быть ближе к культуре и искусству.
Для возможности информировать о своем мероприятии на платформе надо направить заявление и вот тут начинается интересное.
Заявление надо либо подписать электронной подписью, либо приложить скан с печатью.
Как раз на этом этапе к нам и обратились за помощью в настройке процесса подписания, потому как ребята молодые и хотят пользоваться современными инструментами, а печать для ИП уже давно не обязательна.
Настроили, подписали, отправили. Проходит время, ребята возвращаются: отказ, не подтверждено авторство заявителя. Вот тут стало по-настоящему интересно. Обращение в службу поддержки привело вот к такому ответу: надо, чтобы была синяя печать или синий штамп подписи на документе. Попытка выяснить у службы поддержки, почему правильно подписанный документ их не устраивает, успехом не увенчались.
Чертыхаясь и грустя помогли визуализировать подписанный документ. Думали, что процесс закончился, но оказалось, что нет.
Пришёл ответ: "В добавленном вами документе печать организации отсутствует или нечитабельна. Документ должен быть заверен синей или электронной печатью".
Занавес.
Работать с электронной подписью не умеют, служба поддержки ориентируется слабо, ещё и придумали новый термин "электронная печать".
Цифровые сервисы - это хорошо, но при внедрении надо не забывать о необходимости иметь компетенцию, как всем этим пользоваться.
Для общественного обсуждения представлен проект постановления Правительства Российской Федерации «Об электронной почтовой системе».
Раздел по защите информации явно нуждается в доработке: взаимодействие с ГосСОПКА, противодействие КА и реагирование на КИ.
🔹Фильм памяти Владимира Георгиевича Матюхина (1945–2026)
🔹Стратегическая сессия «Куда и как развивается отрасль»
🔹Сессия 1 «Актуальные вопросы национального пространства доверия»
🔹Сессия 2 «Мобильная электронная подпись»
🔹Сессия 3 «Трансграничное признание иностранной ЭП»
🔹Сессия 4 «Новые отраслевые аспекты PKI»
🔹Сессия 5 «Правовые вопросы PKI, судебная практика»
🔹Сессия 6 «PKI в прикладных системах. PKI-проекты и продукты»
🔹Сессия 7 «Системный подход в отрасли PKI»
🔹Экспертная панель 1 «Критические аспекты надежности и устойчивости»
🔹Экспертная панель 2 «Электронные архивы с ЭП»
🔹Экспертная панель 3 «Электронная подпись»
✅Видео о прошедшем форуме 2026 года
✍️ Телеграм-канал "Об ЭП и УЦ" четвертый раз выступал информационным партнёром форума.
С нашим каналом своим экспертным комментарием поделился Николай Лобанов, автор канала "На стадии обсуждения". Николай также направлял свои предложения к проекту приказа Минцифры о требованиях к сертификатам безопасности.
Минцифры обработало мои предложения к проекту приказа о требованиях к сертификатам безопасности НУЦ. Кроме типового "Документ приведен в соответствие с требованиями законодательства РФ", в ответе нашлось одно место по существу, про журналы прозрачности:
Гост сертификаты выпускаются через воздушный зазор. У подсистемы ГОСТ нету доступа к публичным логам.
Что в проекте. DV и OV сертификаты на RSA должны содержать три SCT-метки, то есть пресертификат учитывается в CT-логе до выдачи (п. 117 и 169 приложения 1, дополнение 1.3.6.1.4.1.11129.2.4.2). В профилях DV и OV на ГОСТ такого требования нет.
Зачем это владельцу домена. По CT-логу он видит сертификат, выпущенный на его домен без его ведома (RFC 6962, раздел 1). Если ГОСТ сертификаты НУЦ в логи не попадают, такой сертификат он не увидит.
Почему зазор не довод. Встроить SCT-метку он действительно мешает: для этого пресертификат должен уйти в лог и вернуться с меткой до выдачи. Но учесть сертификат в логе можно и после выдачи, подать его туда может кто угодно (раздел 3.1 того же RFC). Выданный сертификат всё равно выходит из закрытого контура к владельцу. Тем же путём он может уйти и в лог.
Какой лог его примет, отдельный вопрос: лог проверяет подпись цепочки и принимает только цепочки до корней из своего опубликованного списка (там же). Поэтому я предлагал, чтобы журнал вёл сам НУЦ или определённый им российский оператор, а сведения о журналах были записаны в порядке выдачи сертификатов.
Ответ на это: "Предложения указанные в приложении будут учитываться при развитии". Статус: Частично учтено.
Тема воздушного зазора актуальна не только в деятельности НУЦ, но и для АУЦ.
Аккредитованный УЦ должен включить в Регламент перечень аппаратных средств, которые запрещается подключать к сетям общего пользования.
- из презентации PKI-Форума 2017.
Воздушный зазор между центром регистрации и центром сертификации, на флешке в одну сторону передаются файлы запросов на сертификаты, а в другую файлы сертификатов и CRL (однонаправленный шлюз не предлагать). Если бы это нашло применение на практике, то удалось бы АУЦ выйти на текущий уровень автоматизации выдачи сертификатов - около 70 тыс. в сутки?
✍️Минцифры обработаны поступившие предложения на проект приказа о требованиях к сертификатам безопасности.
На все 9 предложений от нашего канала получен типовой комментарий разработчика - Частично учтено: Документ приведен в соответствие с требованиями законодательства РФ. Предложения будут рассматриваться при развитии.