Кратко

  • Pull request 622 остаётся открытым Draft Ballot SC-XX. Окончательного номера, голосования, завершённой IPR-проверки, принятого текста и вступившего в силу правила пока нет.
  • Действующие TLS Baseline Requirements 2.2.9 измеряют период до опубликованного отзыва от получения Certificate Problem Report или связанного уведомления. Проект сначала даёт УЦ 24 часа на решение, является ли отчёт actionable, и только с этого решения запускает применимый срок отзыва.
  • Actionability — порог для начала расследования, а не доказательство нарушения. Замороженный текст требует корректного идентификатора хотя бы одного действующего неотозванного сертификата и описания нарушения либо причины отзыва.
  • Та же отметка запускает 120 часов на проверку всех остальных действующих неотозванных сертификатов, выданных УЦ. Для каждого дополнительно найденного сертификата отдельный срок начинается с момента его первой идентификации.
  • Предлагаемое определение Revoked можно проверять извне: соответствующий CRL должен содержать серийный номер, а соответствующий OCSP — отвечать certStatus=revoked. Это не гарантирует синхронное обновление всех кэшей.
  • Ограниченная по раскрытию квитанция должна связать официальный канал, получение, actionability, вывод по существу, расширение множества, класс срока и публикацию статуса, не раскрывая закрытые ключи, текст отчёта или данные подписчиков.

Входящий отчёт делит время на несколько линий

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

PR 622 раскладывает обработку на интервалы. В течение 24 часов после получения Certificate Problem Report УЦ должен определить, пригоден ли он для действий. Положительное решение открывает несколько обязательств: сообщить доступному автору о результатах в следующие 24 часа, запустить срок отзыва по соответствующей причине и за 120 часов проверить прочие действующие неотозванные сертификаты на ту же non-compliance.

Это не одни часы. Раздел 4.9.1.1 сохраняет разные классы. Свидетельство компрометации закрытого ключа или ненадёжной доменной валидации требует отзыва за 24 часа. Для других перечисленных обстоятельств 24 часа остаются SHOULD, а пять дней — MUST. Аудиторская запись обязана содержать и старт, и класс причины: отметка «в срок» без них ничего не доказывает.

В текущей версии 2.2.9 внешний интервал от отчёта или уведомления до опубликованного отзыва привязан к получению. Проект для сторонних сообщений переносит старт на решение об actionability. Его обоснование прямо называет этот промежуток временем, за которое УЦ может убедиться, что получил достаточно данных до включения основного срока.

В этом есть операционный смысл. Непонятное сообщение без сертификата и объяснения не должно немедленно запускать действие, способное остановить сервис. Но как только классификация сдвигает весь календарь соответствия, она перестаёт быть обычной сортировкой почты. Это первое управляющее событие дела.

Пригодный к расследованию отчёт может оказаться ошибочным

Замороженный проект строит входной тест из двух частей. Во-первых, нужен действительный идентификатор сертификата, выданного этим УЦ, находящегося в сроке действия и ещё не отозванного. Серийный номер должен поддерживаться; SHA-256-отпечаток сертификата или precertificate следует поддерживать. Во-вторых, нужно объяснить нарушение Baseline Requirements или политики УЦ либо указать причину отзыва — например, компрометацию ключа.

Заполненный по этим правилам отчёт не становится истинным автоматически. Автор может назвать реальный сертификат и реальный пункт, но неверно понять факты. УЦ вправе принять дело к разбору, а затем не подтвердить нарушение. Комментарии к pull request различают пригодность к расследованию, вывод о несоответствии и завершение исправления.

Различие защищает обе стороны. Автор формы не получает полномочия распорядиться отзывом. УЦ не получает права трактовать actionable как «мы согласны с обвинением», иначе старт можно отложить до конца собственного расследования. Формула “is considered actionable if it includes” описывает входные признаки, а не итоговый вердикт.

Канал тоже входит в границу. Предложение требует ясной процедуры в разделе 1.5.2 Certification Practice Statement и рекомендует доступную страницу, FAQ или базу знаний. УЦ может технически отсекать непригодные отправки, но должен принимать пригодные.

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

Определение отзыва выходит за пределы базы УЦ

Самая проверяемая часть проекта — новое определение Revoked. Если сертификат содержит URI CRL Distribution Point, доступный там CRL должен включать его серийный номер. Если в Authority Information Access указан OCSP URI, запрос по этому серийному номеру должен получить certStatus=revoked.

servercert issue 252 с 2021 года задаёт вопрос о техническом событии. Отзыв происходит при изменении внутреннего поля? При подписи нового CRL или OCSP-ответа? При размещении объекта на origin-сервере? Или когда relying party может получить новое состояние по путям, объявленным сертификатом?

Внутренний бит не меняет внешнее решение о доверии. Подписанный объект, не покинувший origin, тоже недостаточен. Предлагаемое определение помещает завершение на интерфейс, который действительно запрашивает пользователь. Если сертификат объявляет оба механизма, естественное прочтение требует выполнения обоих применимых условий.

Это не обещание абсолютной одновременности. В issue 252 описана сложность обновления и очистки контента через CDN. Кэши некоторое время могут показывать разные состояния; OCSP-сервис по запросу может создать ответ лишь в момент обращения. Определение даёт наблюдаемое условие завершения, а не одинаковую миллисекунду для каждого устройства.

Получается явная асимметрия. Конец можно исследовать вне УЦ. Начало — решение об actionability — сначала существует только внутри него.

120 часов возвращают поиск тому, у кого есть данные

С момента положительной классификации УЦ получает 120 часов на оценку всех других выданных им действующих неотозванных сертификатов на предмет той же non-compliance. Автору отчёта не нужно перечислять всю популяцию. Один сертификат открывает расследование; внутренние данные УЦ позволяют найти связанные экземпляры.

Инцидент DigiCert с CNAME-валидацией показывает информационный разрыв, но не доказывает, что проект его предотвратил бы. В Bugzilla 1910322 записано, что третья сторона сначала не передала известные серийные номера. Позднее DigiCert назвал среди корневых причин несерьёзное отношение к CPR без серийных номеров и указал 83 267 действующих сертификатов, выданных затронутым методом на момент полного отчёта. Первая подсказка и реальная группа были объектами разного масштаба.

Требование полного списка от внешнего автора перевернуло бы информационное преимущество. Порог в один сертификат и поиск по УЦ распределяют обнаружение разумнее. Но они создают новые старты: 120 часов идут от actionability; срок дополнительного сертификата — от его первой идентификации УЦ.

Фраза «проверка популяции завершена» не различает, когда запущен поиск, когда система нашла совпадение и когда человек внёс его в дело. Нужны исходное определение множества, версия метода или запроса, начало, конец, число проверенных, число новых, исключения и последующие исправления. Сам запрос и список клиентов могут оставаться закрытыми. Позже обнаруженная группа не должна выглядеть так, будто никогда не входила в первоначальную область поиска.

Более качественный отчёт не должен стирать ранний

Трудности каналов входят в историю проекта. В деле DigiCert известные серийные номера не были переданы сначала. Жалоба на SSL.com в Bugzilla 1942270 описывала перевод с электронной почты на форму и неясность поля “thumbprint”; итоговый статус — INVALID. В Bugzilla 1942241 сообщалось, что официальный адрес GoDaddy отклонял архив с материалом скомпрометированного ключа; итог — FIXED.

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

Опасность возникает, когда порог качества превращается в механизм исчезновения. По замороженному тексту, если отчёт не actionable и контакт известен, УЦ обычно должен запросить недостающие сведения в течение 24 часов после решения. Их последующее получение может стать основой дальнейших сроков. Срок вправе законно начаться позже, но история не обязана начинаться позже.

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

Узкая квитанция может сохранить всю цепочку

Публичный архив доказательств инцидента не требуется. Требуется соединить состояния, которые уже создаёт проект.

Состояние Минимальная запись
Официальный вход Канал, версия инструкции, время получения, защищённый идентификатор отчёта
Первая классификация Время решения, присутствующие или недостающие данные, ограниченный код причины
Вывод по существу Класс нарушения или отзыва, явно отдельный от actionability
Начальный набор Число, защищённые идентификаторы, класс 24 часов или пяти дней
Оценка популяции Область, версия метода, начало, конец, проверенные, новые, исключения
Дополнительные находки Первая идентификация и класс срока для защищённого элемента или когорты
Публикация Каждая применимая точка CRL/OCSP и первое успешное наблюдение отзыва
Остаток Исключения распространения, координация с подписчиком, исправления, следующий ответственный

Публичный слой может показывать время, числа и коды состояния. Идентификаторы допустимо хэшировать или задерживать, если раскрытие навредит подписчикам или расследованию. Открытые ключи, полный текст, данные аккаунтов, внутренние поисковые запросы и защитная логика форм должны оставаться закрытыми. Подробный слой доступен аудитору или root program.

Различие «слоёв реальности» у Lu Heng здесь служит лишь ограниченным редакционным тестом, а не доктриной Web PKI. Название состояния нужно соединить с исполнимым событием, которое придаёт ему последствия. Actionable меняет часы; Revoked меняет то, чему relying party вправе доверять. Обоим нужны время и наблюдение, а не один ярлык.

Дата в рабочей ветке не равна дате вступления в силу

На момент заморозки источников pull request всё ещё назывался Draft Ballot SC-XX. Его head — ef1dda7b7652d439c3b4b8db2328c4afd4a31ec0, base — 6aba16d239d793d547c9397c50a3013257107bb6. Сравниваемый текущий main заморожен на 5c13e270b4e0b6aaef258acf0a642d1c5a36cf97, версия документа — 2.2.9.

При этом файл в PR head всё ещё называет себя 2.2.2 и содержит предлагаемую дату 15 сентября 2026 года. Само несоответствие предупреждает: дата — поле рабочей ветки, а не принятый график. Протокол SCWG от 13 августа доказывает обсуждение работы, но не завершение номера, официального периода, голосования, IPR и публикации по Charter и Bylaws.

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

Источники

  1. Heng Lu, «On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile»
  2. Pull request 622 репозитория servercert CA/Browser Forum
  3. Предлагаемые Baseline Requirements в замороженном head ef1dda7b…
  4. Действующие Baseline Requirements в замороженном commit main 5c13e270…
  5. servercert issue 252: уточнение технического смысла отзыва
  6. Mozilla Bugzilla 1910322: инцидент CNAME-валидации DigiCert
  7. Mozilla Bugzilla 1942270: жалоба на механизм сообщений SSL.com
  8. Mozilla Bugzilla 1942241: жалоба на вложения GoDaddy
  9. Протокол SCWG от 13 августа 2026 года
  10. Charter Server Certificate Working Group
  11. Bylaws CA/Browser Forum