Кратко

  • draft-ietf-tls-trust-anchor-ids-06 предлагает короткие идентификаторы, помогающие выбрать путь сертификата. Запрос клиента не обязан полностью или точно описывать его политику доверия.
  • Сервер и клиент могут по-разному ранжировать общие якоря. После отказа сервер способен сообщить доступные индивидуальные ID, а клиент — выполнить не более одного нового подключения с точным запросом.
  • Сигнал, запас путей, выбор, локальная проверка, восстановление, приватность и фактический результат должны оставаться разными объектами управления.

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

Revision 06 проекта Trust Anchor IDs даёт сторонам небольшой протокол для такого выбора. Версия обновлена 30 сентября 2026 года. В заголовке указан предполагаемый Standards Track, но в зафиксированной записи Datatracker поля intended_std_level и std_level равны null. Это Internet-Draft, а не RFC. Источники не доказывают внедрение, распространение или совместимость реализаций.

Сигнал не исчерпывает политику

У сервера могут быть несколько цепочек для одной прикладной идентичности. Расширение certificate_authorities передаёт имена допустимых центров, однако большой набор distinguished names занимает много места. Проект вводит короткие индивидуальные Trust Anchor IDs и групповые ID.

Клиент помещает неупорядоченный RequestedTrustAnchorList в ClientHello или CertificateRequest. Список может быть пустым. В нём разрешено не указывать доверенный якорь, указать недоверенный либо сослаться на группу, где доверены не все участники. Ограничение размера и защита от точного отпечатка хранилища объясняют, почему неточность может быть сознательной.

Сервер связывает каждый доступный путь с индивидуальным ID выпускающего якоря и групповыми шаблонами. Затем он ищет пересечение с запросом. Если присутствует и certificate_authorities, проект позволяет ориентироваться на совпадение любого из двух расширений. Без совпадения сервер может завершить handshake либо отправить резервный сертификат.

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

Готовый путь остаётся предметом проверки

Если выбранный сертификат совпал с запрошенным ID, сервер может включить пустое расширение trust_anchors в Certificate. Пустой маркер обязывает передать полный, правильно упорядоченный список без посторонних сертификатов.

Клиент может считать его готовым путём и не строить альтернативы. RFC 4158 описывает сложность построения, RFC 5280 — проверку. Первую задачу можно убрать, вторую нельзя. Аккуратная цепочка всё равно может заканчиваться недопустимым корнем, нарушать name constraints или использовать запрещённый алгоритм.

В наблюдаемости нужны две независимые записи: «путь выбран из-за совпадения ID» и «политика такой-то версии приняла или отклонила путь по такой-то причине». Если оставить лишь имя выданного CA, предпочтение сервера начинает выглядеть решением клиента.

Согласование после отказа

Сервер может передать в EncryptedExtensions непустой список доступных индивидуальных якорей, расположив их по собственному предпочтению. Если клиент затем отклонит сертификат, он ищет среди них реально доверенный вариант, учитывает оба порядка и открывает новое соединение, запрашивая только выбранный ID.

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

Здесь необходимо заранее решить, чьи предпочтения важнее. Сервер может ставить новый корень первым ради миграции. Клиент может выбрать старый ради стабильности. Простое пересечение не объясняет итоговый порядок. Эксплуатационный документ должен зафиксировать правило разрешения конфликта, владельца задержки и дату, после которой резервный путь перестанет быть нормой.

Группа скрывает перечень, но не разногласие

Групповой ID сжимает несколько якорей. Клиент не обязан доверять каждому. Сервер может правильно сопоставить группу и выбрать участника, который локальная политика правильно отвергнет.

Следовательно, группе нужны распределение ID, состав, версия, доставка изменений и вывод из обращения. Рассинхронизация не создаёт доверие, но создаёт предсказуемую недоступность. Сэкономленные байты превращаются в постоянную работу по координации.

Нельзя считать выбор цепочки одобрением CA. Это результат запаса сервера, описания путей, сигнала клиента и алгоритма предпочтений. Техническая координация не выдаёт институционального мандата.

Условие отправки определяет наблюдаемость

Проект различает клиентов, которые никогда, условно или всегда отправляют IDs. Для условного поведения обычно нужен активный зонд. Безусловный список виден пассивному наблюдателю. Уникальный для пользователя набор становится устойчивым отпечатком.

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

Серверу следует фильтровать список доступности под запрошенный сервис и SNI. Выдача всего запаса общей платформы раскрывает ненужные связи. Чувствительные якоря не должны участвовать в этом механизме.

Семь независимых свидетельств

Минимальная квитанция начинается с политики сигнала: отправленные индивидуальные и групповые IDs, условие, правило множества анонимности. Затем идёт запас путей: реальные цепочки, источник и версия их свойств. Третий раздел — выбор и fallback: совпавшее расширение, порядок, поведение без совпадения.

Четвёртым остаётся локальная проверка с версией хранилища и точной причиной. Пятый описывает восстановление, список, единственный повтор и задержку. Шестой фиксирует приватность, прежнее состояние и фильтр сервиса. Седьмой — результат: выданный путь, состояние TLS и наблюдаемый приложением эффект.

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

Источники