Кратко

  • Pull request 679 предлагает разрешить ML-DSA-44, ML-DSA-65 и ML-DSA-87 в TLS Baseline Requirements и задать правила ключей и подписей для сертификатов, CRL и ответов OCSP.
  • В преамбуле названы SDK-клиенты, embedded/IoT, корпоративное middleware и приложения с trust stores операционной системы. Там же сказано, что предложение не обязывает root store доверять ML-DSA и не меняет алгоритм подписи SCT.
  • Устав SCWG охватывает TLS-сертификаты серверов, доступных через Интернет. Однако голосующий Certificate Consumer должен выпускать общедоступный продукт для безопасного веб-браузинга, а квалификация Issuer также проверяется через принятие сертификата таким браузером.
  • Прямое исключение для сугубо внутренней PKI уже и точнее формулы «всё не браузерное». Поэтому публичный текст оставляет вопрос толкования, а не готовый вывод.
  • На 2 сентября 2026 года SC-106 была открытой Draft PR и отсутствовала на официальной странице ballots. Комментарии и протокол Токио показывают спор, но не решение группы.
  • Квитанция мандата должна назвать целевые классы, пункт устава, путь участия, общий инвариант, полномочия root/CT/path, данные реализации, альтернативный форум и условие пересмотра.

Кого называет потребность и кого называет голосование

Важнейшая фраза SC-106 находится не в таблице алгоритмов. PR утверждает, что многим relying parties недоступен практический путь к постквантовой аутентификации внутри существующей публичной инфраструктуры X.509. Затем он перечисляет их без абстрактного слова «экосистема»: сервисные клиенты на SDK, встраиваемые и IoT-системы, корпоративное middleware и приложения, проверяющие цепочки по trust stores поставщиков операционных систем.

Такое ПО действительно может аутентифицировать TLS-сервер и при этом не быть браузером. Устав Server Certificate Working Group использует для потребительского голоса иной критерий. Организация должна выпускать для широкой публики продукт, предназначенный для безопасного просмотра веба, регулярно обновлять его и публиковать правила root store и CA compliance. Голосующий Certificate Issuer должен выпускать сертификаты, которые считаются действительными браузером такого Consumer Member.

Одна компания может одновременно разрабатывать браузер, ОС и криптобиблиотеку. Это расширяет её знания, но не переписывает основание конкретного голоса. Наличие специалиста по IoT в обсуждении также не является делегацией от производителей и операторов устройств.

Разделение Lu Heng между stakeholder и principal здесь полезно именно своей строгостью. Участник даёт факты, экспертизу и возражение. Мандат показывает, кто разрешил кому устанавливать общее ограничение. Поэтому SC-106 должна определить, является ли она веб-минимумом с побочной пользой, ancillary activity по текущему уставу или профилем для нескольких групп публичной доверенности, часть которых не входит в класс голосующих потребителей.

Один commit содержит несколько материальных решений

Frozen head eefc670… добавляет три набора параметров FIPS 204, проверку encoding ключа, Key Usage для Subscriber Certificate и точные AlgorithmIdentifier. Параметры должны отсутствовать, HashML-DSA запрещается, допустим только «pure» ML-DSA.

Затем проект связывает ключ и подпись в обе стороны. ML-DSA subject public key можно сертифицировать только подписью ML-DSA. Подпись ML-DSA в сертификате или precertificate может сертифицировать только ключ ML-DSA. CRL и OCSP response исключены из второго правила, поскольку они не сертифицируют public key.

Преамбула одновременно ограничивает силу этих норм. Успех предложения не заставит Root Store Operator принимать ML-DSA hierarchy. Он не изменит алгоритм, которым CT log подписывает Signed Certificate Timestamp. Разрешённый CA profile, доверенный root, принятый журналом объект и выбранный клиентом path — четыре разных состояния.

Это хорошее разграничение. Но оно требует показать точный общий blocker. Нынешний BR мешает CA получить аудит на выпуск? Root program не принимает алгоритм? Библиотека не строит path? Trust store не распространяет anchor? Сервер не умеет выбрать credential? Источники не дают списка версий, числа затронутых клиентов или воспроизводимого теста, где одна pure-chain норма устраняет все препятствия.

Номер проекта не заменяет процесс

Заголовок репозитория содержит SC-106, а преамбула говорит о будущем ballot. На дату исследования GitHub показывал Open, Draft, один commit и отсутствие formal review. Официальная страница SCWG не включала SC-106 в Voting, IPR Review, Discussion, Draft / Under Consideration или историю.

Следовательно, доказанный статус — draft pull request. Нет публичного извещения с формальными proposer и endorsers, периодом обсуждения, голосованием, результатом, IPR review, Final Maintenance Guideline или датой вступления.

Ступени нельзя складывать в одно слово. Автор пишет diff. Working Group вводит определённую версию в formal process. Два класса голосуют. IPR рассматривает исключения. Финальный текст получает дату. После этого CAs, root programs, CT и клиенты принимают свои решения. Первый документ не обладает полномочиями всех последующих владельцев.

Immutable comparison служит другой цели: сохраняет точное предложение даже после его замены. Это историческое доказательство, не прогноз результата.

Устав широк по функции и узок по источнику голоса

Цитата только о браузере неполна. Раздел Scope разрешает SCWG устанавливать требования к выпуску и управлению TLS server certificates для аутентификации серверов, доступных через Интернет, обновлять их против emerging threats и вести ancillary activities. Это шире одного браузерного продукта.

Цитата только об Internet-accessible servers также неполна. Membership определяет, кто голосует как Consumer, через веб-браузинг. Issuer квалифицируется через принятие сертификатов браузером. Всё ПО, способное проверить X.509, не становится частью этой институциональной группы.

Out of Scope прямо исключает PKI, которой предприятие пользуется только внутри и чей Root Certificate не распространяется ни одним Certificate Consumer. Отдельно исключены основные случаи вроде S/MIME и code signing. Это не универсальный запрет не-браузерного TLS, но пример того, как устав устанавливает конкретные границы.

Поэтому честный вывод — наличие толковательной напряжённости, а не доказанное нарушение. Если профиль оправдан пунктом Internet server или ancillary, группа должна публично назвать пункт, владельца толкования и пределы. Технический redline не должен молча решать вопрос компетенции.

Токийский протокол сохранил незакрытый спор

В minutes F2F 64 за март 2025 года есть отдельный раздел об уточнении области TLS BR. Участники обсуждали browser/non-browser, OS trust stores, server-to-server, private PKI, agility и новый Working Group.

Одна позиция связывала реальную силу BR с browser root programs и не хотела, чтобы менее гибкие применения тормозили Web. Другая указывала, что ОС и приложения используют те же roots, не имеют равноценной альтернативы и могут столкнуться с фрагментацией из-за browser-specific rules.

Протокол зафиксировал обе перспективы, но не изменил устав и не объявил консенсус. Его ценность в том, что проблема SC-106 существовала до обсуждения ML-DSA.

В PR 2026 года шов снова стал видим. Один участник назвал целевые use cases non WebPKI. Ben Wilson связал assurance с path, который relying party построил и принял. Поздний комментарий участника Chrome разделил два направления mixed chain, поставил вопрос об уставе и предложил отдельную группу Forum.

Это атрибутированные позиции. Реакция GitHub не голос, а мнение одного поставщика не коллективная интерпретация.

Pure-chain правило затрагивает несколько владельцев

Обоснование Draft говорит: классическая подпись в представленном path ограничивает assurance этого path классическим уровнем. Из этого не следует автоматически запрет любого смешанного построения. Клиент может принять полностью PQ path и проигнорировать классическую альтернативу; существование альтернативы не меняет подписи в принятом пути.

RFC 5280 называет prospective certification path и trust-anchor information входами в validation. Выбор anchor — policy, разные paths могут начинаться с разных anchors. BR ограничивает issuance CA, но не выбирает путь за клиент.

Общее ограничение всё же может быть оправдано. Классическая CA, подписывающая PQ Subscriber key, создаёт большие объекты под существующим root и сохраняет классическую точку атаки. PQ CA, подписывающая классический ключ, может использоваться при переходе и защите от downgrade. Направления несут разные последствия для CT и compatibility.

Следовательно, надо назвать invariant: Web CT capacity, истинность метки PQ path, root signalling, legacy compatibility или non-Web migration. Одна формула «pure» не должна незаметно объединять решения пяти владельцев.

Running code демонстрирует несколько маршрутов

Roadmap Chromium описывает поэтапный Web-переход: certificate negotiation, параллельные классические/PQ credentials, downgrade protection и очень далёкое удаление классических вариантов. Для публичной Web PKI Chrome развивает Merkle Tree Certificates, а не немедленное доверие традиционным ML-DSA X.509.

Testing instructions Chrome Quantum-resistant Root Program проводят ещё одну границу. Chrome 150 поддерживает традиционные ML-DSA certificates в private PKI. Для MTC есть отдельный test root store, который надо включать явно; cosigners помечены как недоверенные для production. У профиля собственные правила logs, mirroring и алгоритмов.

Это не универсальная инструкция для embedded client. Это доказательство, что private, test и future production compatibility sets могут развиваться отдельно.

FIPS 204 определяет алгоритм. Certificate profile определяет encoding и issuance. Root policy определяет trust. CT определяет admission и transparency. Client определяет path. Deployment показывает результат. Дисциплина Minimum Initial Specification у Lu Heng полезна тем, что не даёт одному действию говорить за остальные.

Поля квитанции мандата

Первый блок: base, head, status, formal proposer/endorser, discussion, voting, результат по классам, IPR, финальная версия и дата. Второй: browser, OS validator, SDK, embedded, IoT, middleware, private/public PKI.

Для каждого класса указываются пункт устава, владелец интерпретации, путь голоса, консультативный путь или его отсутствие. Отсутствие голоса не создаёт veto, но запрещает утверждать, что группа уже представлена.

Технический блок разделяет encoding, path assurance, downgrade, CT capacity и root admission. Для каждой строки: invariant, decision owner, evidence, uncertainty, local option. Реализация добавляет test vector, library/version, размер, выбранный path, pilot и failure.

Последний блок сравнивает venue: SCWG с опубликованным толкованием; изменение устава; новая Non-Browser WG; root-specific pilots. Для переходных ограничений задаются review date, threshold и exit.

Чего доказательства не показывают

Нет принятого ballot, действующей Guideline, обязательства root store, итога CT или коллективного толкования устава. Нет census названных клиентов и публичного результата конкретного mixed path.

Нет и оснований объявлять предложение незаконным, ненужным или технически несостоятельным. Доказан точный Draft, реальная область применения и незакрытый вопрос мандата.

Сейчас исправить запись дёшево. После того как audits, procurement и tooling назовут профиль «industry standard», созданная зависимость может начать служить обратным доказательством полномочий исходного форума.

Ясный мандат делает профиль прочнее

SCWG может публично истолковать полномочие по Internet servers и ограничить заявление о представительстве. Forum может создать группу для системных и embedded clients. Root programs могут продолжить pilots до появления измеренного общего invariant.

Ни один путь не отвергает ML-DSA. Они лишь не позволяют месту хранения текста заменить полномочие.

SC-106 уже разделяет разрешение профиля, root trust и SCT signature. Теперь нужно разделить beneficiary и voter. Тогда технический документ получит ровно тот вес, который подтверждён его мандатом.

Источники

  1. Lu Heng, “The Multi-Stakeholder Mirage”
  2. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  3. CA/Browser Forum, pull request 679 — SC-106
  4. Неизменяемое сравнение SC-106
  5. Предлагаемые TLS Baseline Requirements
  6. Устав Server Certificate Working Group
  7. Протокол SCWG F2F 64
  8. Bylaws CA/Browser Forum
  9. Страница ballots SCWG
  10. NIST FIPS 204
  11. RFC 5280, раздел 6
  12. Chromium, Post-Quantum HTTPS Authentication Roadmap
  13. Testing instructions Chrome Quantum-resistant Root Program