✍️Внесены изменения в требования к формату нотариально оформляемого документа в электронной форме
Приказом Минюста от 29.09.2026 № 268 внесены изменения в пункты 3 и 8 Требований к формату нотариально оформляемого документа в электронной форме.
Пункт 3 переписан полностью, если для документа предусмотрена XML-схема, то нотариус направляет получателю два файла:
🔹XML - для информационных систем, подписывается КЭП нотариуса.
🔹PDF - для визуализации XML-документа, содержит отметку об электронной подписи.
Из пункта 8 исключено второе предложение о том, что ранее пакет из XML и PDF подписывался КЭП Нотариуса, про визуализацию речи не было.
Первое предложение пункта 8 вызывает вопросы:
Документ в электронной форме подписывается усиленной квалифицированной электронной подписью нотариуса, консульского должностного лица в формате PKCS#7 (отделенная электронная подпись в кодировке DER)
PKCS#7 - устаревший формат, который не проходит проверку сервисом Головного УЦ. Не хочет Минюст ссылаться на 472 приказ Минцифры.
Вот и думайте, какой смысл от экспертных советов с приглашением толпы людей, рабочих групп, форумов и конференций, если приказы министерств годами содержат грубейшие ошибки.
🛡 «Проверка на прочность»: «мы проверяемся» ≠ «мы понимаем свои риски»
Аудит пройден, пентест проведён, отчёт подписан. А утечка всё равно случилась.
14 октября в Москве форум «Проверка на прочность» разберётся, как не перепутать активность с результатом.
На стыке права, данных и безопасности:
🔹 что на самом деле хочет регулятор (CISO Билайна, Т-Банка, МТС Банка, Райффайзена, HeadHunter, Почты России)
🔹 право на взлом: где граница между этичным хакером и нарушителем
🔹 ИИ в оценке защищённости: где помогает, а где создаёт новую иллюзию
🔹 подрядчики, которые могут уронить вас быстрее хакера
🔹 интерактивный мастер-класс Алексея Лукацкого «50 оттенков зелёного»: как метрики ИБ создают иллюзию защищённости
📍 14 октября, Холидей Инн Сокольники, 9:00–18:00
👉 Программа и регистрация: breakme-forum.ru
✍️Телеграм-канал "Об ЭП и УЦ" выступает медиа партнёром конференции
✍️CA/Browser Forum обновлены базовые требования - AIA, как опция
По итогу голосования в рамках бюллетеня SC104 наличие расширения AIA установлено в значение SHOULD (необязательное), ранее было MUST. Также требование о наличии хотя бы одного параметра внутри расширения дополняется оговоркой "If present" (если присутствует).
Объяснение данной корректировки простое - внутри расширения AIA уже существуют разные уровни обязательности для методов доступа.
Расширение AIA (Authority Information Access) в сертификате показывает дополнительную информацию об удостоверяющем центре, выдавшем этот сертификат. В обязательном порядке включает адрес OCSP-службы для проверки статуса сертификата (метод id-ad-ocsp) и как опцию ссылку на сертификат УЦ (метод id-ad-caIssuers). Например, если в TLS-рукопожатии клиенту не хватает промежуточного сертификата, AIA может указать, где его скачать.
Если ссылка на сертификат издателя опциональна, а адрес OCSP - обязательный, то обязательность AIA теряет смысл, указание адреса OCSP - потребует наличие расширения AIA, но если AIA отсутвует, то ни OCSP, ни ссылки на сертификат УЦ в сертификате не будет.
Новая версия базовых рекомендаций 2.3.1 опубликована 04.10.2026.