Кратко

  • В базовом commit, указанном в SC-104, некритическое расширение Authority Information Access обязательно (MUST) для TLS Subscriber Certificate. Однако внутри него id-ad-caIssuers имеет уровень SHOULD, а id-ad-ocspMAY.
  • Неизменяемый redline делает ровно две правки: внешнее присутствие становится SHOULD, а требование одного или нескольких AccessDescription применяется только при наличии расширения. Уровни методов не меняются.
  • caIssuers указывает, где получить сертификат издателя для выбора или построения пути; OCSP указывает на онлайн-службу статуса. Общий ASN.1-контейнер не делает эти назначения взаимозаменяемыми.
  • Публичное извещение устанавливает окончание голосования 3 сентября 2026 года в 00:00 UTC. На дату исследования 2 сентября нельзя приписывать ballot итог, завершённую IPR-проверку или включение в опубликованную Guideline.
  • Полный журнал разделяет процедуру, правило профиля, правило метода, фактические байты сертификата и наблюдение клиента. Версии и fingerprint связывают эти слои, не позволяя одному доказывать другой.

Обязательная оболочка и негарантированный адрес

В исходном тексте есть необычная вложенность. Таблица расширений Subscriber Certificate требует authorityInformationAccess как MUST и помечает его некритическим. Следующий раздел требует, чтобы AuthorityInfoAccessSyntax содержал как минимум один AccessDescription. Но таблица допустимых методов не назначает ни одному из них MUST.

id-ad-caIssuersSHOULD. id-ad-ocspMAY. Все остальные методы — MUST NOT. Получается обязательная непустая оболочка, внутри которой не гарантирован один конкретный сервис.

Это не означает, что оболочка лишена смысла. Для содержимого действуют ограничения по способу, типу location, уникальности и порядку. SHOULD также имеет нормативную силу, которой нет у простой необязательной заметки. Но внешний MUST обещает больше определённости, чем каждая внутренняя строка по отдельности.

SC-104 ограничивается этой конструкцией. В таблице MUST меняется на SHOULD; перед условием о минимальном числе описаний добавляется «If present». Не меняются OID, функции, URI, множественность и уровни caIssuers и OCSP. Другие профили сертификатов массово не переписываются.

Поэтому формула «AIA становится необязательным» слишком груба. Точнее: внешняя норма станет рекомендацией с допустимыми обоснованными исключениями, а две внутренние нормы останутся различными.

У исключения из SHOULD должна быть квитанция

RFC 2119 допускает отступление от SHOULD, когда существуют веские причины, но требует понять и тщательно взвесить последствия. RFC 8174 уточняет применение ключевых слов в верхнем регистре.

Если SC-104 войдёт в действующую Guideline, сертификат без AIA перестанет нарушать внешний MUST. Тем не менее издатель будет принимать решение об исключении из SHOULD. Его можно сделать проверяемым: указать версию правил, причину, сертификатный продукт, версию шаблона, срок решения и матрицу клиентов.

Поле aia_present=false не различает обоснованное исключение, не завершённую миграцию и ошибку конфигурации. Поле allowed=true ещё хуже: оно превращает SHOULD в неограниченное MAY.

Практический реестр должен хранить хотя бы три локальных состояния: стандартное включение, утверждённое исключение и необъяснённое отклонение. Ослабление общей нормы не требует ослаблять локальную доказательность.

Метод нужно называть, а не прятать в AIA

RFC 5280 определяет AIA как последовательность описаний информации или сервисов издателя. id-ad-caIssuers обозначает место получения сертификатов издателя и может помогать relying party выбирать и строить путь сертификации. id-ad-ocsp обозначает онлайн-службу статуса сертификата.

Оба метода могут использовать HTTP URI и находиться в одном расширении. Но получение промежуточного сертификата не является проверкой статуса. Успешный OCSP-ответ не является источником недостающего промежуточного сертификата.

Различие читается и в других положениях Baseline Requirements. Некоторые условия по CRL зависят именно от того, содержит ли Subscriber Certificate метод OCSP в AIA. Поэтому агрегат «AIA есть» не позволяет полностью восстановить применимые правила. Нужны OID и location каждого метода.

Отсутствие caIssuers также не доказывает невозможность построить путь. TLS-сервер может отправить правильный intermediate. Клиент может иметь его в локальном хранилище или кэше. Поставщик может распространить его другим каналом. И наоборот, наличие URL не доказывает, что клиент выполнит запрос, ресурс доступен и полученный материал даст валидный путь.

Сертификат фиксирует указатель. Он не фиксирует маршрут выполнения.

Реализация начинается с версии и настройки

Microsoft документирует возможность Windows получать недостающий сертификат издателя через AIA. Там же описана возможность администратора отключить такое получение. Утверждение «проверено в Windows» поэтому неполно без версии, политики, хранилища, кэша, сети, URL и цепочки сервера.

Mozilla в 2020 году описала предварительную загрузку раскрытых промежуточных сертификатов CA в Firefox через Remote Settings. Одной из целей было сокращение ошибок unknown issuer, когда сайт не отправляет правильный intermediate. Это пример альтернативного источника материала для пути.

Он не является обещанием для всех версий Firefox, всех промежуточных сертификатов и всех конфигураций. Он не освобождает сервер от передачи подходящей цепочки. Функция Windows, в свою очередь, не доказывает всеобщую зависимость от сетевого AIA.

Два официальных примера разрушают модель единого клиента. Корпоративный Windows с отключённым retrieval, Firefox с предварительно загруженным intermediate и встроенная TLS-библиотека без сетевого fetching могут дать разные результаты на одном сертификате.

В журнале нужно указывать фактический источник промежуточного сертификата: сервер, store, кэш, preload или caIssuers. Иначе успех, обеспеченный кэшем, будет ошибочно приписан сертификату, а изменение кэша позднее проявит скрытую зависимость.

Процедурный статус нельзя ускорить технической ясностью

Публичное извещение SC-104 называет Ethan Davis из Google Trust Services proposer, а Roman Fischer из SwissSign и Stephen Davidson из DigiCert — endorsers. В качестве базы указаны Baseline Requirements 2.2.9 и фиксированное сравнение commit ad77bf… с предлагаемым a0f9a7….

Период обсуждения был назначен с 20 по 27 августа 2026 года UTC, голосование — с 27 августа до 3 сентября, 00:00 UTC. На 2 сентября подтверждённый статус — голосование продолжается.

Открытый pull request не равен принятому ballot. Успешный ballot, если он состоится, не равен завершённой IPR-проверке. IPR-проверка не равна опубликованной Final Maintenance Guideline с датой вступления в силу. Каждый этап добавляет отдельную форму полномочия.

Процедурная запись должна хранить идентификатор, proposer и endorsers, базу, proposal, окна обсуждения и голосования, знаменатели имеющих право голоса, голоса, результат, IPR-статус, исключения, итоговую версию и effective date.

Более поздний результат не меняет задним числом статус 2 сентября. Если текст будет отклонён или заменён, frozen diff останется доказательством того, что именно рассматривалось, но не действовало.

Пять раздельных записей

Процедура. SC-104, commits, обсуждение, vote, IPR и публикация. Эта запись устанавливает происхождение и полномочие текста.

Профиль. Тип сертификата, версия Guideline, внешний уровень AIA, критичность и дата действия. Эта запись устанавливает применимое правило.

Метод. Отдельные строки caIssuers и OCSP с OID, назначением, уровнем, типом location, числом и порядком. Эта запись устанавливает внутреннюю матрицу.

Выдача. Издающая CA, продукт, версия шаблона или конфигурации, fingerprint, наличие AIA и фактические AccessDescriptions. Эта запись устанавливает байты.

Исполнение. Клиент, версия, платформа, политика, store, кэш или preload, цепочка сервера, сеть, fetching, источник intermediate, статусный механизм и результат. Эта запись устанавливает воспроизводимое наблюдение.

Версия Guideline связывает процедуру с профилем. Конфигурация выдачи связывает профиль с сертификатом. Fingerprint связывает сертификат с тестом. Но связи не дают права на подмену. Успешная проверка не доказывает AIA-запрос. Ошибка клиента не отменяет ballot. Публикация нормы не доказывает изменение выдачи.

Принцип Lu Heng о минимальной общей спецификации, локально проверяемых будущих решениях и различии публикации и принятия полезен именно как редакционная граница. Он не означает, что Lu Heng анализировал SC-104. Он не позволяет общему тексту присвоить факты локального исполнения.

Чего нет в открытом наборе

Исследованные источники не измеряют долю действующих Subscriber Certificates с AIA, caIssuers или OCSP. Они не показывают, какие CA изменят шаблоны. Они не оценивают размер, приватность, трафик, задержку, доступность, безопасность или частоту ошибок. Они не устанавливают, какой relying party просил изменения.

Нормативная аргументация при этом может быть логичной: внешний обязательный контейнер не гарантирует конкретный сервис, если внутренние уровни — SHOULD и MAY. Логическая согласованность не является измеренным операционным эффектом.

Сторонники не могут превратить Firefox preload в доказательство всеобщей независимости. Противники не могут превратить Windows retrieval в доказательство всеобщей зависимости. Нужны определённые выборки, версии, настройки и сертификаты с fingerprints.

Вывод не должен быть шире двух строк

SC-104 задаёт Working Group узкий вопрос: должен ли внешний уровень AIA стать SHOULD, пока caIssuers остаётся SHOULD, а OCSP — MAY? Процедура Forum может дать ответ.

После этого CA по-прежнему контролируют выдачу, поставщики — клиентскую реализацию, серверы — предъявляемую цепочку. Общая норма влияет на них, но не принимает их решения.

Пять состояний позволяют говорить точно: какая версия получила силу, какой метод закодирован в конкретном сертификате и что сделал конкретный клиент в конкретных условиях. Фраза «AIA больше не нужен» для этого не требуется.

Маленькое изменение заслуживает глубокого журнала и узкого вывода.

Источники

  1. Lu Heng, “Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption”
  2. CA/Browser Forum, servercert pull request 665 — SC-104
  3. Неизменяемое сравнение SC-104
  4. CA/Browser Forum, servercert issue 673
  5. Публичный архив извещения о голосовании SC-104
  6. TLS Baseline Requirements на базовом commit голосования
  7. Устав CA/Browser Forum
  8. RFC 5280, раздел 4.2.2.1
  9. RFC 2119
  10. RFC 8174
  11. Microsoft, получение через Authority Information Access
  12. Mozilla Security Blog, предварительная загрузка промежуточных сертификатов CA в Firefox