Тяжело Росархиву разбираться в вопросах нашей сферы - в приказе от 09.07.2026 № 91 (завтра вступает в силу) о внесении изменений в Правила делопроизводства в госорганах говорится про наделение сотрудников полномочиями по подписанию электронной подписью госоргана, т.е. автоподпись.

Но ещё четыре года назад в 63-ФЗ 339-ФЗ были внесены изменения, что распорядительным актом госоргана определяется ни один сотрудник, а сразу два, первый - ответственный за автоматическое создание/проверку электронной подписи в информационной системе, а второй - за содержание информации, подписываемой такой автоподписью.

Консервативным сотрудникам Росархива можно рекомендовать не игнорировать посещение профильных конференций. Например, в программу PKI-Форума включен доклад "О предложениях профессионального сообщества по совершенствованию нормативного регулирования в сфере управления документами по итогам Всероссийского профессионального форума АРХИВЫ–2026", доклад Росархива "Криптографическая консервация: обеспечение легитимности электронных документов в архивном хранении" в стадии согласования.

✍️"Об ЭП и УЦ"

🔘 Интервью Дмитрия Гусева, заместителя генерального директора, для журнала NBJ в рамках конференции «Криптография и Цифровой рубль»

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

🔗 Смотреть RuTube / ВК

⚪️Мы в МАХ

📣ИнфоТеКС - 35 лет!

Поздравляю компанию "ИнфоТеКС" с 35-летним юбилеем, ваш путь - это история становления целой отрасли!

Ваши решения линейки ViPNet являются технологической основой для ключевых инфраструктур, без которых цифровой мир России сегодня немыслим.

Передача защищенных запросов СМЭВ между ведомствами базируется на ваших комплексах, мобильная технология квалифицированной и неквалифицированной подписи использует ваши средства удостоверяющего центра. Ваша
экспертиза проявилась в полной мере при создании ифраструктуры цифрового рубля, ПАК использованные при создании PKI-решений,  автоматизирующие выдачу TLS-сертификатов и неквалифицированной подписи для пользователей платформы цифрового рубля полностью соответствуя требованиям Банка России.

Что мне лично особо дорого - ваш ViPNet HSM в основе УЦ Федерального казначейства, обеспечивает хранение закрытого ключа УЦ.

Спасибо, что 35 лет вы создаете фундамент доверия - от рядового пользователя до государственных и финансовых систем национального масштаба!

С праздником, "ИнфоТеКС! Желаю , чтобы ваша работа оставалась надежным щитом для новых рубежей цифровой экономики🏆

Телеграм-канал ✍️"Об ЭП и УЦ"

🪙Цифровой рубль - новый этап внедрения массовой отечественной криптографии

Через неделю мобильные приложения самых крупных банков должны получить апгрейд, по итогу которого каждый телефон получит своё СКЗИ (год назад таким образом в приложение Госуслуг был интегрирован TrustCryptoBase Госключ).

Как вы узнаете про это? Будут знаки. ЦБ сообщает, что на главной странице приложений появится специальная кнопка с логотипом цифрового рубля.

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

🔐 PKI - основа инфраструктуры Цифрового рубля:
🔹Два Головных УЦ в Банке России для НЭП и TLS.
🔹в самих банках два УЦ, уже подчиненных - аналогично для НЭП и TLS (в 2027 году - переход на НУЦ), а также TLS-шлюзы и СКЗИ класса КС3,
🔹в мобильных приложениях граждан - средства ЭП КС1, на рабочих местах корпоративных CSP, криптоплагины и браузеры с ГОСТ-TLS.

Согласно программе PKI-Форума заместитель Председателя Банка России приглашена к участию в стратегической сессии "Куда и как развивается отрасль" по вопросу "PKI в цифровом рубле".

✍️Телеграм-канал "Об ЭП и УЦ" четвертый раз выступает информационным партнёром форума.

✍️CA/Browser Forum: корректировка причин отзыва сертификатов

Mozilla предлагает пересмотреть существующие причины отзывов сертификатов. Причина понятна, УЦ по-разному трактуют, браузеры по-разному интерпретирует одни и те же коды причин отзывов.

Статистика показывает большой разброс: одни УЦ массово используют код "unspecified", другие "superseded", третьи "cessationOfOperation", что и говорит о разной трактовке одного и того же стандарта.

Ключевое предложение - код должен показывать причину отзыва, а не административное действие. Если ключ был скомпрометирован - код должен быть keyCompromise, даже если сертификат в итоге был заменен.

Представитель TWCA сообщил, что Chrome, публично заявил - отзывы сертификатов добавляются в CRLSet на основе указанного кода причины (keyCompromise или privilegeWithdrawn). Однако, согласно официальной документации, в CRLSet сейчас попадают только keyCompromise, но не privilegeWithdrawn.

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

Предлагается поэтапный план:
Этап 1 - пересмотр раздела 4.9.1.1 (обстоятельства, требующие отзыва):
🔹установить иерархию, чтобы конкретная причина имеет приоритет над общей
🔹убрать дублирования и пересекающиеся формулировки 🔹чётко разграничить: ключевая безопасность, валидация, авторизация, техническое соответствие
🔹ввести дерево решений для аудиторов и операторов УЦ
🔹пересмотреть, вписываются ли 24-часовые и 5-дневные сроки в новую семантику
🔹определить, как быть с требованиями CP/CPS, которые строже BR - считать ли их нарушением BR или выделять отдельно.

Этап 2 - пересмотр раздела 7.2.2
/RFC 5280 (сопоставление с кодами CRL):
🔹сделать использование кодов единообразным для всех УЦ
🔹пересмотреть устаревшие коды (holdInstruction, removeFromCRL)
🔹чётко определить, когда использовать superseded (только для плановой замены, а не для компрометации)
🔹обсудить возможность изменения RFC 5280 (это более масштабная задача ведь текущие определения не работают)

Как обычно, вопросов много:
1. Как быть с выбором кода неопытным оператором, если он выбирает "на глаз"?
2. Должен ли УЦ проверять обстоятельства или достаточно заявления пользователя?
3. Как УЦ должен проверять причины, заявленные пользователем? Как независимо подтвердить прекращение деятельности?
4. Должен ли УЦ изменить код, если его анализ показывает другую причину?
5. Не пора ли менять RFC 5280, если существующие коды не соответствуют современным реалиям?

✍️"Об ЭП и УЦ"