Кратко
- Дерево политик RFC 5280 копирует одно логическое состояние, когда к нему ведут несколько отображений; потомки копий снова дублируются, поэтому худший случай растёт экспоненциально.
- RFC 9618 хранит отношения в ориентированном ациклическом графе с общими узлами. Валидность пути и итоговый набор политик не меняются, а размер структуры линейно связан с политиками и отображениями во входе.
- Надёжная миграция требует двух доказательств: семантического равенства на сложных случаях и измеренной границы памяти, процессора и очередей на враждебных входах.
В штатном режиме служба подтверждения сертификатов отвечала быстро. Во время инцидента несколько коротких клиентских цепочек заняли все рабочие процессы. Они не получили доступ и не подделали подписи. Они заставили проверяющую программу развернуть слишком много комбинаций политик до ожидаемого отказа.
Вход использовал не полномочие доверия, а вычислительное полномочие. RFC 9618 устраняет конкретный источник такого усиления, не меняя смысл решения, которое должен вернуть корректный валидатор.
Где возникает дерево
Расширение политик сертификата содержит OID политик и необязательные квалификаторы. Сертификат центра сертификации может ограничивать допустимые политики и отображать OID из домена издателя в OID подчинённого домена. Приложение задаёт исходный набор приемлемых политик.
RFC 5280 обрабатывает эти данные при проверке уже составленного сертификационного пути. Это не поиск пути. RFC 4158 описывает построение кандидата от целевого сертификата до якоря доверия; RFC 9618 относится к оценке политик после получения такого кандидата.
Старый алгоритм использовал valid_policy_tree. Каждому пути через отображения соответствовала отдельная ветвь. Если две политики издателя отображались в одну политику субъекта, дерево создавало две копии одного состояния. На следующем уровне потомки каждой копии дублировались снова.
В примере RFC каждый промежуточный сертификат содержит два OID и полный набор отображений каждого из них в оба OID следующего уровня. На каждой глубине число путей удваивается. Объём кодированной цепочки растёт умеренно, внутренняя структура — экспоненциально.
Для отказа в обслуживании этого достаточно. TLS-сервер, проверяющий клиентские сертификаты, или шлюз идентификации может потратить намного больше ресурсов, чем отправитель. Успешная аутентификация атакующему не нужна: цель — лишить проверки остальных.
Документ связывает модель с реальными исправлениями. Запись OpenSSL описывает экспоненциальное потребление ресурсов при проверке политик в CVE-2023-0464 и ограничение числа узлов. Бюллетень Apple указывает, что обработка вредоносного сертификата в CVE-2023-23524 могла привести к отказу в обслуживании. История OpenSSL фиксирует эту меру.
Общий узел вместо перечисления всех маршрутов
valid_policy_graph из RFC 9618 содержит не более одного узла для каждого OID на данной глубине. Если к политике ведут несколько предыдущих политик, у узла несколько родителей. Потомки хранятся один раз.
Смысл не теряется. Старое дерево — это перечисление всех путей от корня к листьям графа. Чтобы определить достижимые итоговые политики, материализовать все одинаковые маршруты не требуется. Поэтому новый алгоритм сохраняет и валидность сертификационного пути, и конечный набор допустимых политик.
Меняется предел. Размер графа линейно ограничен общим числом политик и отображений в цепочке. Большой вход по-прежнему стоит ресурсов, но компактная комбинаторная конструкция больше не порождает экспоненциально больший внутренний объект.
Так выглядит минимальный общий контракт. Стандарт фиксирует смысл anyPolicy, счётчиков, отображений, отсечения и результата. Реализация выбирает собственные структуры, пока не меняет решение и не оставляет работу неограниченной.
Устаревший выход возвращает уязвимость
RFC 5280 называл полное valid_policy_tree результатом проверки. Старый потребитель может потребовать дерево даже от валидатора, который внутри использует граф. Разворачивание общих узлов по всем путям снова создаёт экспоненциальную структуру.
RFC 9618 объявляет этот вывод устаревающим и рекомендует возвращать наборы политик, ограниченные центрами и пользователем. Приложению обычно нужен итог — какие политики действуют, — а не полный перечень эквивалентных доказательных маршрутов.
Ленивое восстановление дерева допускается ради совместимости, но не делает его ограниченным. Оно только переносит оплату. Если такой потребитель действительно существует, реконструкцию следует вынести из общего пути допуска, квотировать, наблюдать и закрепить за владельцем риска.
Совместимость здесь становится вопросом управления. Диагностический интерфейс без владельца не должен определять доступность всех аутентификаций. Требование обязано называть потребителя, необходимый результат и допустимый ресурсный бюджет.
Ограничения создают новую границу отказа
До полной миграции можно ограничить глубину цепочки или число узлов дерева. Слишком малая глубина отвергает легитимные пути; большая оставляет пространство для ветвления. RFC 9618 отмечает, что увеличение политик в сертификате может сохранить рост порядка O(N^(глубина/2)) даже при ограничении глубины.
Лимит узлов полезен, только если срабатывает предсказуемо до истощения. Протокол испытания должен показывать точку остановки, память, CPU, ошибку, повторные попытки и задержку чужих запросов. Одно число в конфигурации ничего этого не доказывает.
Отключение политик также не разрешает молча игнорировать критические расширения. Если реализация их не понимает, она должна отвергнуть сертификат как содержащий неизвестное критическое расширение. Подписанный смысл нельзя обменять на экономию вычислений.
Один журнал для смысла и стоимости
Семантический набор покрывает обычные политики, множественные отображения, anyPolicy, требование явной политики, запрет отображений, запрет anyPolicy, отсечение и пустой итог. Сравниваются не только успех или отказ, но и конечный пользовательский набор. Быстрый отказ от всех сложных легитимных случаев не является эквивалентом.
Нагрузочный набор независимо меняет глубину, число OID на сертификат и плотность отображений. Он фиксирует байты, узлы, рёбра, пиковую память, выделения, CPU, реальное время, причину остановки и очередь при параллельной работе.
Доказательства должны пересекаться. Каждый функциональный случай получает ресурсную трассу, каждый враждебный случай — точный вердикт. Иначе можно принять ускорение ценой смысла или совместимость ценой сохранённого отказа в обслуживании.
Последний уровень — фактическое исполнение: загруженная библиотека, параметры сборки, активная настройка политик, вызовы старого API дерева и идентичность процесса. Публикация RFC или наличие пакета не доказывают, какой код принял производственное решение.
RFC 9618 не ограничивает все расходы X.509. Построение пути, подписи, отзыв, парсинг и прикладная авторизация имеют отдельные границы. Документ убирает одно определённое усиление, сохраняя обещанный результат. Именно поэтому его можно проверить точно.
Источники
- RFC 9618 — Updates to X.509 Policy Validation
- Статус RFC 9618
- История IETF Datatracker
- Канонический текст RFC 9618
- Канонический XML RFC 9618
- RFC 5280 — профиль сертификатов и CRL X.509
- RFC 4158 — построение сертификационного пути
- Исправление OpenSSL для CVE-2023-0464
- История выпусков OpenSSL
- Бюллетень безопасности Apple
- Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
- Running-Code Primacy
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров

