Кратко

  • Действующая политика Mozilla разделяет сопровождение хранилища корней, уверенность за период и проверки, которые УЦ обязан провести до включения данных подписчика в сертификат.
  • Ни политика, ни аудит периода не восстанавливают конкретную заявку, наблюдение проверки, выпуск, позднейший статус отзыва или результат отдельного клиента.

Mozilla Root Store Policy 3.1 действует с 1 июля 2026 года и полезна именно тем, что ставит рядом несколько верных утверждений, не превращая их в взаимозаменяемые. Mozilla распространяет сертификаты УЦ с битами доверия для разных целей. Для входящих в область корней и технически способных выпускать рабочие серверные или почтовые сертификаты промежуточных УЦ политика требует определённых аудитов до включения и затем не реже раза в год. Она также требует проверять сведения, представленные подписчиком, по независимому источнику или альтернативному каналу до включения в сертификат.

Для TLS-сертификата УЦ должен удостовериться в праве на доменные имена и контроле над IP-адресами документированными методами.

Каждое утверждение существенно. Ни одно не становится автоматически доказательством следующего.

У аудита есть граница уверенности: охваченная система, критерии, период, методика, проверенные материалы, выводы и ограничения. Политика требует обновлять сведения о периодическом аудите не реже ежегодно. Для годовых периодов, начинающихся 1 июля 2027 года или позже, она дополнительно требует Detailed Controls Report от некоторых УЦ с битом доверия для веб-сайтов. Его назначение — показать границы системы, средства контроля, реализацию, тестирование и операционную эффективность. Это ценное доказательство надзора, но не журнал всех заявок и не современная запись об одном выпуске.

Разница видна при взгляде на сертификат. Серийный номер, издатель, срок действия и альтернативные имена субъекта описывают объект. Они не говорят, какая заявка поступила, какая версия процедуры действовала, кто или какой автоматический контроль был уполномочен, что наблюдал независимый источник, оставалось ли наблюдение в допустимом окне, или почему ключ связали с этими именами. Аудиторское мнение не создаёт этих отсутствующих связей одним фактом своего существования.

Обратная подмена столь же ненадёжна. Запись о выпуске может показать, что объект создан, но не доказывает работу всей контрольной среды в течение периода, охват всех площадок, отсутствие позднейшего факта или сохранение одинакового режима корней каждой производной поставкой. Сама политика Mozilla говорит, что распространители программ на её основе могут добавлять, удалять и изменять сертификаты и биты доверия. Поэтому политика управляет стандартным набором Mozilla, а не каждой возможной сборкой.

Выпуск также не равен позднейшему принятию. Документация NSS различает блоки сертификатов и блоки доверия; корень — это сертификат плюс настройки доверия. Клиенту всё ещё нужно построить и оценить путь в соответствии со своим состоянием ПО и локальными условиями. Имя хоста, время, расширения, построение цепочки, сведения об отзыве, применение и наблюдаемый при соединении сервис — отдельные вопросы. Это не утверждение о сбое какого-либо клиента; это предел того, что можно доказать аудитом или файлом УЦ без клиентского свидетельства.

Практический ответ — ограниченная квитанция доказательств выпуска. Под защитой в ней следует хранить идентификатор заявки; запрошенные имена и отпечаток ключа; версию правила и процедуры; уполномоченного исполнителя или автоматический контроль; наблюдение независимого источника либо альтернативного канала и его временное окно; затем серийный номер, издателя, срок, существенные расширения и время выпуска. Поздний отзыв следует хранить отдельно с временем запроса и контекстом ответа. Результат клиента также хранится отдельно: граница сборки или политики, имя хоста, путь и время — без излишнего сбора данных пользователя.

Это не требование публиковать доказательства контроля домена, клиентские досье или защитные детали. Это требование не выдавать одно утверждение за другое. Чувствительные материалы могут проверяться при надлежащем полномочии. Долговечной должна остаться карта связей: какое решение поддержало какой объект, по какому правилу и на какое позднейшее наблюдение действительно ссылаются.

Границы доказательств

Изученные источники не называют УЦ, подписчика, сертификат, аудиторское мнение, DCR, инцидент или событие полагающейся стороны. Они не доказывают нарушение. Предлагаемая квитанция — редакционный анализ, а не требование Mozilla, CA/Browser Forum, NSS или RFC.

Источники

  1. Mozilla Root Store Policy 3.1
  2. Mozilla NSS: Updating NSS’s Root Store
  3. RFC 5280