Summary

  • Индивидуальный Internet-Draft предлагает /.well-known/company-certs для обнаружения по HTTPS частных якорей доверия, ограниченных конкретным приложением и не попадающих в глобальное хранилище ОС.
  • Аутентификация источника, корректность пути X.509 и выбор цепочки с самым поздним valid_from не доказывают, что замену разрешил компетентный орган компании. Во время перекрытия фактическое доверие может измениться раньше, чем появится проверяемый мандат.
  • Daniel Kade предлагает квитанцию смены якоря: точную эпоху метаданных, старый и новый отпечатки, область применения, окно перекрытия, утверждающую сторону, локальную политику, независимое подтверждение и откат. Это редакционная рекомендация, а не требование IETF.

Обычная ротация уже показывает разрыв

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

У схемы есть достоинства. Аутентифицированный источник лучше CA-файла из письма; хранилище одного приложения безопаснее глобальной установки; перекрытие защищает доступность. Но успешное получение доказывает лишь, что отдал origin и что выбрал клиент. Оно не называет владельца PKI, хозяина приложения или роль риска, санкционировавшую новый якорь.

Якорь доверия — не нейтральная настройка. Это локальный вход проверки пути. После его добавления ранее неприемлемые сертификатные цепочки могут стать допустимыми в заданном контексте. Поэтому право менять endpoint технически позволяет менять круг признаваемых приложением удостоверяющих полномочий.

Что именно предлагает черновик

draft-doehle-company-certs-discovery-00 — индивидуальный Internet-Draft от 22 июля 2026 года, задуманный для Standards Track. На дату исследования существует только редакция -00. Это не RFC, не консенсус IETF и не свидетельство внедрения.

Механизм размещает версионированный JSON по адресу /.well-known/company-certs. В нём есть authority_information и trust_anchors. Якорь связан с usage_context и одной или несколькими certificate_chains. Для цепочки можно указать valid_from, valid_until, HTTPS-адрес того же origin, материал X.509 в PEM, CRL, OCSP и отпечаток SHA-256.

Область ограничена. permitted_domains должны совпадать с DNS-идентификатором проверенного TLS-сертификата endpoint либо быть его поддоменами. isolated_store_required выражает намерение издателя удержать якорь в обособленном хранилище. Неспособный обеспечить изоляцию клиент должен отказать.

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

Проверка HTTPS обязательна. Контроль домена даёт право публиковать от этого origin. Сам текст подчёркивает: такое право не удостоверяет качество, безопасность или эксплуатационную надёжность частного УЦ. DNS, хостинг, CDN, ключ TLS, развёртывание и PKI могут находиться у разных команд.

Origin не заменяет карту полномочий

RFC 8615 упорядочивает пространство well-known URI и предупреждает: возможность записывать такой ресурс может означать власть над всем origin. В общей среде размещения или сложной модели доступов небольшое на вид разрешение получает большой институциональный эффект.

Это не обесценивает аутентификацию источника. Она точно отвечает, от чьего пространства имён пришло утверждение. Она не отвечает, кто внутри был вправе его одобрить. Web-команда может выкладывать файл, сетевая — управлять DNS, CDN — доставлять его, PKI-команда — строить цепочку, а владелец приложения — определять назначение. Фраза «компания опубликовала» скрывает передачи ответственности.

RFC 9525 помогает сопоставить TLS-идентичность с эталонным именем, к которому намеревался обратиться клиент. Успех означает достижение сервера, уполномоченного для имени, но не является протоколом внутреннего согласования. Правильный endpoint способен распространить изменение без доказанного мандата.

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

Поздняя дата задаёт порядок, а не право

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

RFC 3339 унифицирует запись времени. Корректная метка не объясняет, кто её поставил, зачем понадобилось окно и согласовали ли его ответственные команды. Законная, ошибочная и скомпрометированная публикации одинаково способны содержать синтаксически верную более позднюю дату.

RFC 5280 пробел не закрывает. Проверка пути получает якоря и политики как локальные исходные данные. Она может подтвердить новую цепочку при этих предпосылках, но не процесс включения якоря в набор.

Следовательно, правило новизны выполняет свою работу. Ошибка возникает, когда панель превращает «выбрано по политике клиента» в «утверждено организацией».

Изоляция должна проявляться в исполнении

isolated_store_required — намерение публикатора, а не технический барьер. Клиент сам определяет, способна ли его архитектура удерживать материал отдельно. Значение true не заканчивает аудит.

Нужно проверить фактическое хранилище, доступные к нему вызовы валидации и общие библиотеки, способные расширить область. После рефакторинга частная коллекция может оказаться в общем кеше без единого изменения JSON.

То же относится к permitted_domains. Парсер может сохранить поле, а построитель пути — не применить. Кеш может смешать контексты. Запись управления должна соединять объявленное ограничение с наблюдаемым поведением.

Изоляция — главное обещание безопасности проекта. Попадание прикладного якоря в общесистемный набор превращает ограниченное обнаружение в гораздо более широкое решение о доверии. Это изменение полномочий, не мелочь реализации.

Свежий HTTPS может нести просроченный мандат

RFC 9110 и RFC 9111 разделяют семантику HTTP, свежесть кеша и повторную проверку. Черновик рекомендует консервативное кеширование, периодическую валидацию и защиту от повтора или устаревших метаданных; клиент может установить собственный максимум.

Эти меры показывают, достаточно ли свежо представление origin. Они не продлевают организационное согласие. Двухчасовое аварийное разрешение может закончиться раньше кеша. Безопасность может отозвать решение, пока edge выдаёт старую эпоху. Только что загруженный JSON может никогда не быть одобрен владельцем приложения.

Первое получение — чувствительный bootstrap. До него канал не даёт якоря, после него приложение способно принимать новые пути. Первичную регистрацию, обновление, перекрытие, переключение, удаление и откат следует учитывать отдельно, а не как одинаковые успешные GET.

Запросы также могут раскрывать интерес к организации и контексту. Кеш полезен для приватности и доступности, но его горизонт становится частью политики доверия. Его задаёт допустимое время исправления, а не только экономия трафика.

Статус сертификата не объясняет статус решения

Метаданные могут указывать CRL и OCSP. RFC 6960 позволяет узнать состояние сертификата. Это важный элемент жизненного цикла, но не история утверждения якоря.

Новый УЦ способен выпускать неотозванные сертификаты, хотя его включение не было санкционировано. Старый якорь может оставаться криптографически пригодным после запланированного вывода. Статус подчинённых сертификатов не восстанавливает инициатора и цель перекрытия.

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

Квитанция смены якоря доверия

Daniel Kade предлагает квитанцию смены якоря доверия для каждого существенного перехода Company-Certs. Это не новое обязательное поле публичного JSON и не правило IETF. Это операционная связь между публикацией, мандатом и локальным решением.

Сначала квитанция фиксирует эпоху: точный digest объекта, origin, проверенную эталонную идентичность, время получения и состояние кеша. Добавляются контекст, домены и требование изоляции. Согласие на один digest не распространяется на всё, что URL опубликует позже.

Затем называется движение: старый и новый отпечатки, идентификаторы цепочек, интервалы, окно перекрытия и планируемое состояние. Добавление, предпочтение, удаление и аварийный откат — разные действия.

Раздел полномочий указывает роль, политику или ограниченную автоматику, утвердившую изменение, и защищённую ссылку на запись. Не нужно раскрывать имена или протоколы совещаний публично. Нужно уметь проверить мандат независимо от того же пути публикации.

Раздел клиента сохраняет правило выбора, дополнительное подтверждение, фактическую изоляцию, срок повторной проверки и поведение при недоступности. Исправление связывает CRL, OCSP, срочное удаление, откат, классы клиентов и максимум распространения. У квитанции есть собственный срок.

Подтверждение соразмерно последствиям

Для малозначимого внутреннего инструмента может хватить origin и подписанной проверки репозитория. Платёжной, подписывающей или управляющей системе может понадобиться отдельный ключ либо двойной контроль. Строгость должна следовать возможному ущербу.

Второй URL в той же CDN или сообщение от того же аккаунта мало независимы. Разделение дают PKI-система, подписанный манифест, защищённый журнал, аппаратный ключ или другой административный домен.

RFC 5011 — только ограниченное сравнение. В автоматическом обновлении якорей DNSSEC он хранит состояния добавления, выдержки и удаления. Эти правила не управляют Company-Certs. Узкий урок: программному изменению собственной основы доверия нужна память перехода, а не одно «текущее» значение.

Не смешивать глаголы

Ранний Internet-Draft не обязан описывать всё корпоративное управление. Аутентифицированный origin, доменная область, назначение, срок и сигнал изоляции уже лучше бесконтекстного CA-файла или глобальной установки.

Источники не подтверждают конкретное внедрение, инцидент или злоупотребление. Вводный эпизод — проверка конструкции по правилу нескольких цепочек, а не обвинение компании.

Зрелая практика сохраняет разные глаголы. HTTPS аутентифицирует получение. JSON представляет метаданные. X.509 проверяет путь при локальных вводах. Политика клиента выбирает. Организационная власть утверждает. Квитанция связывает факты, не позволяя одному подменять остальные.

Источники

  1. https://heng.lu/the-policy-mirror/
  2. https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
  3. https://heng.lu/on-why-btw-media-exists-and-why-reality-not-advocacy-is-the-product/
  4. https://datatracker.ietf.org/doc/html/draft-doehle-company-certs-discovery-00
  5. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/
  6. https://datatracker.ietf.org/doc/draft-doehle-company-certs-discovery/history/
  7. https://www.rfc-editor.org/rfc/rfc8615.html
  8. https://www.rfc-editor.org/rfc/rfc9525.html
  9. https://www.rfc-editor.org/rfc/rfc5280.html
  10. https://www.rfc-editor.org/rfc/rfc6960.html
  11. https://www.rfc-editor.org/rfc/rfc9110.html
  12. https://www.rfc-editor.org/rfc/rfc9111.html
  13. https://www.rfc-editor.org/rfc/rfc8259.html
  14. https://www.rfc-editor.org/rfc/rfc3339.html
  15. https://www.rfc-editor.org/rfc/rfc5011.html