Кратко

  • За SC100 проголосовали 22 участвовавших издателя сертификатов и три потребителя сертификатов; голосов против и воздержавшихся не было. Проверка интеллектуальных прав должна завершиться 5 сентября 2026 года. На дату отсечения 31 августа текст ещё не входил в действующие TLS Baseline Requirements.
  • Проект собирает уже существующие правила DNSSEC. Для относящихся к контролю домена и CAA запросов он требует валидацию на первичной сетевой перспективе, с узким частичным исключением для почтовых методов. На удалённых сетевых перспективах DNSSEC остаётся необязательным.
  • Multi-Perspective Issuance Corroboration, или MPIC, не отменяет эту асимметрию. Удалённые наблюдения подтверждают вывод первичной перспективы; удалённая перспектива может участвовать в MPIC, хотя правила не делают DNSSEC обязательным для неё.
  • Проект исключает полный набор DNS-запросов из названных областей журналирования и самоаудита, но требует сохранить достаточно информации для проверки. Практичная запись должна соединять ограниченную по времени квитанцию контроля резолвера с квитанцией конкретного выпуска, которая называет первичную перспективу и отдельно фиксирует DNSSEC на каждой удалённой.

Одна версия в заголовке не означает один статус

На официальной странице SC100 зафиксирован необычно чистый результат. «За» проголосовали 22 участвовавших издателя сертификатов. Apple, Cisco Systems и Mozilla дали ещё три голоса от потребителей сертификатов. Не было ни голосов против, ни воздержавшихся; указанный кворум 15 был достигнут.

Но результат голосования — не конец пути принятия. Та же страница говорит, что проверка интеллектуальных прав началась 6 августа в 19:00 UTC и должна закончиться 5 сентября в 19:00 UTC. На момент исследования участники ещё могли подать уведомления об исключении. Протокол рабочей группы от 13 августа также описывает SC100 как недавно вошедший в IPR review.

Статус легко прочесть неверно: приложение с принятыми изменениями озаглавлено как версия 2.2.9 от 6 августа. Страница действующих требований называет текущие TLS Baseline Requirements той же версией 2.2.9 и той же датой. Однако таблица редакций текущего документа заканчивается SC101, а SC100 в ней не опубликован. Каталог документов и уведомление о проверке раскрывают необходимое различие: один файл — действующая Final Guideline, другой — полный Draft Maintenance Guideline, подготовленный для проверки.

Это не мелкая канцелярская оговорка. Доказательство соответствия должно указывать состояние документа, а не только номер в колонтитуле. Слова «версия 2.2.9» сами по себе не сообщают, идёт ли речь о текущем выпуске, принятом проекте SC100 или будущем выпуске, который, возможно, включит его.

Текст бюллетеня устанавливает ещё одну границу. У SC100 нет даты вступления в силу, поскольку заявленная цель — разъяснение и консолидация без намерения изменить действующие требования. Поэтому эта статья не объявляет новый контроль. Она спрашивает, какие свидетельства сделали бы уточнённый контроль проверяемым.

Обязательное действие принадлежит роли

Исходное требование появилось в SC085v2. С 15 марта 2026 года применимые запросы контроля домена и CAA, выполненные первичной сетевой перспективой, должны проходить DNSSEC-валидацию при наличии цепочки. Действующая версия 2.2.9 сохраняет это правило в нескольких разделах.

SC100 собирает материал в предлагаемом § 4.2.2.2. Сначала проект описывает резолвер первичной сетевой перспективы. Он должен валидировать по § 5 RFC 4035, поддерживать NSEC3 и SHA-2 и учитывать вопросы безопасности из § 4 RFC 6840.

Далее подразделы распределяют поведение. Первичная сетевая перспектива должна выполнять DNSSEC для всех DNS-запросов, связанных с Domain Authorization or Control и обработкой CAA. Для оставшихся почтовых методов предусмотрена частичная граница: CNAME-, CAA- и TXT-запросы, с помощью которых получают Authorization Domain Name, по-прежнему обязательны, а к другим запросам применяется SHOULD. Для остальных методов и CAA локальная политика не может отключить требуемую валидацию. Ошибка DNSSEC на первичной перспективе — в проекте приведён пример SERVFAIL — не может стать разрешением на выпуск в пределах оговорённого исключения.

Для удалённых перспектив глагол другой. Удалённые сетевые перспективы в MPIC могут валидировать DNSSEC до корневого якоря доверия IANA. MAY — это не MUST, но и не MUST NOT. Проект не объявляет удалённую валидацию плохой, ненужной или запрещённой. Он помещает минимально обязательный контроль в первичную роль и позволяет издателю добавить криптографическую проверку на удалённых площадках.

Это и есть доказательная граница. Поле dnssec_status=secure мало что подтверждает, если не называет сетевую перспективу, которая получила состояние. Корректный удалённый результат не заменяет отсутствующий первичный только потому, что оба используют один протокол. И первичный результат нельзя копировать в строки удалённых перспектив так, словно каждая из них приняла независимое DNSSEC-решение.

MPIC умножает наблюдения, а не DNSSEC-обязанности

SC067v3 ввёл MPIC, чтобы усложнить точечные BGP-атаки на проверку домена. Текущий § 3.2.2.9 описывает процесс как подтверждение результатов проверки домена и CAA, полученных первичной перспективой, с удалённых сетевых перспектив до выпуска сертификата.

Два контроля защищают разные переходы. DNSSEC спрашивает, способен ли резолвер криптографически проверить DNS-данные и подтверждённое отсутствие записи в рамках модели доверия протокола. RFC 4035 использует состояния Secure, Insecure, Bogus и Indeterminate. Они описывают результат валидации, но не указывают метод выпуска CA, наблюдательную роль или итоговое решение.

MPIC спрашивает, подтверждают ли достаточно независимые удалённые наблюдения вывод первичной перспективы. Проект SC100 повторяет поэтапный график: с 15 июня 2026 года применимая реализация использует не менее четырёх удалённых перспектив, выполняет таблицу кворума и получает подтверждение как минимум из двух сервисных регионов RIR. С 15 декабря минимум увеличится до пяти. Это количество удалённых наблюдений, а не обязательных DNSSEC-валидаторов.

Поэтому удалённая перспектива может сообщить подтверждающий результат challenge или CAA, хотя требования не обязывают её выполнять DNSSEC. CA может добровольно валидировать DNSSEC там и получить более богатое состояние. Оба варианта совместимы с проектом. В свидетельстве должно быть видно, какой вариант произошёл.

Смешение контролей рождает два ошибочных вывода. Первый: пройденный кворум MPIC якобы доказывает DNSSEC-валидацию каждого наблюдения. Второй: необязательный DNSSEC на удалённых перспективах якобы обесценивает MPIC. Ни один не следует из текста. Сетевая и географическая независимость не превращается в криптографическую проверку, а криптографическая проверка — в сетевую и географическую независимость.

Форум сознательно не задал единственный формат журнала

Проблема доказательств возникла не случайно. SC096 вывел DNSSEC-верификацию из широких требований к журналам DCV и CAA. В обосновании отмечалось, что резолверы не создавались для подробного журналирования, а записи управления изменениями могут показать, что нужные контроли действовали.

Предлагаемый § 4.2.2.2.7 SC100 сохраняет исключение. Полный набор информации DNS lookup, связанной с DNSSEC, остаётся вне самоаудитов § 8.7 и журналирования § 5.4.1. Но далее добавлено решающее требование: несмотря на исключения, CA должна хранить информацию, достаточную для проверки соблюдения остальной части раздела DNSSEC.

Протокол от 16 июля показывает, что открытость была намеренной. Оставался вопрос, стоит ли предписывать конкретный способ журналирования. Участники предпочли достаточные свидетельства при свободе реализации. После возобновления обсуждения на изменённом тексте протокол от 30 июля отметил отсутствие дополнительных комментариев перед голосованием.

Для стандарта это разумно: нормативный документ не должен заставлять все CA пользоваться одной архитектурой резолвера и хранилища. Но гибкость переносит работу на проектирование доказательств. Какая минимальная запись подтверждает ролевую обязанность, не восстанавливая полный DNS-транскрипт, который проект намеренно исключает?

Одна квитанция описывает контроль, другая — выпуск

Ответ не должен звучать как «записывать всё». Нужна ограниченная связка двух квитанций.

Квитанция контроля описывает конфигурацию резолвера и первичной перспективы на заданном интервале. Минимальный состав:

ID квитанции контроля + ID первичной перспективы + ID резолвера или сервиса + программа и сборка + хеш конфигурации или политики + набор/версия якорей доверия + состояние проверки RFC 4035 + ссылки на поддержку NSEC3, SHA-2 и RFC 6840 + состояние локальных исключений + ID тестовых прогонов + valid-from/valid-to + одобренная запись изменения

Хеши и контролируемые ссылки позволяют не раскрывать секреты и всю конфигурацию. Цель — превратить общее утверждение «DNSSEC был включён» в ограниченное временем и закреплённое за исполнителем состояние. Материалы управления изменениями показывают, что одобрили операторы и какие тесты связаны с конкретным выпуском резолвера.

Квитанция выпуска описывает один валидационный заход. Она должна связывать:

ID попытки и сертификата/предсертификата + время запроса и решения + имя и область проверки + метод валидации + область CAA + версия BR/проекта + ID первичной перспективы + ID резолвера/квитанции контроля + семейства запросов + состояние DNSSEC + ошибка и fail-closed-решение + ID удалённых перспектив + флаг выполнения DNSSEC и состояние для каждой удалённой + регионы RIR + наблюдения и кворум MPIC + линия повторов + неизменяемый хеш записи

Самые важные поля коротки: ID первичной перспективы и флаг DNSSEC выполнен для каждой удалённой. Без первого состояние Secure не имеет нормативной роли. Без второго молчание двусмысленно: необязательную проверку могли не проводить, результат мог потеряться либо модель данных вообще не представляла выбор.

Если удалённая перспектива не выполняла DNSSEC, запись должна нейтрально сказать: не выполнено, разрешённое необязательное состояние. Нельзя подставлять Insecure, потому что у него есть протокольное значение. Если удалённая перспектива валидировала, результат принадлежит ей и её резолверу. Первичное состояние не следует копировать в удалённые строки для удобства.

Квитанция выпуска не нуждается в полных пакетах, каждом resource record или полном debug trace. Ей нужна достаточная связка для восстановления проверяемого утверждения: требуемая первичная роль использовала соответствующий контроль на нужных запросах; ошибка не стала разрешением на выпуск; независимый MPIC достиг своего кворума.

Модель двух квитанций — аналитическое предложение Daniel Kade. SC100 не перечисляет эти поля, а статья не приписывает их DIGICERT, авторам и endorsers бюллетеня, участникам голосования, аудитору или редактору RFC. Форум выбрал критерий достаточности. Квитанции — один способ сделать его проверяемым.

Флаг успеха не соединяет правило, действие и решение

Представим, что верны четыре утверждения:

  1. CP/CPS издателя говорит, что DNSSEC включён.
  2. Конфигурация резолвера прошла тест соответствия.
  3. Конкретная попытка вернула Secure.
  4. После успешного MPIC-кворума сертификат был выпущен.

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

CP/CPS — декларация практики, а не наблюдение конкретного исполнения. Тест доказывает поведение в тестовых условиях, не каждый будущий вызов. Secure описывает состояние DNSSEC, а не первичную роль. Сертификат доказывает факт выпуска, но не путь решения. Кворум MPIC доказывает подтверждение, но не обязательную DNSSEC-проверку каждым участником.

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

Чего не показывают открытые источники

Публичные материалы не сообщают, внедрил ли какой-либо конкретный CA проект SC100, как устроены его внутренние резолверы и что именно хранится в журналах выпуска. Единогласное голосование не доказывает развёртывание. Отсутствие публичных деталей не доказывает несоблюдение. Статья не выявляет ошибочного выпуска, DNS-отравления или скрытого журнала.

Источники также не позволяют предсказать уведомление об исключении до 5 сентября, изменение принятого текста или номер будущего релиза. Точная формула статуса остаётся прежней: голосование пройдено, проверка открыта, действующий выпуск не изменён.

Источники