Кратко

  • Для сертификата с новой политикой v2 и новыми OID расширений RFC 8360 позволяет совместимому валидатору вычислить Verified Resource Set и продолжить работу с доказанной частью ресурсов, не отбрасывая автоматически всё поддерево из-за сверхзаявки CA.
  • Избыток не получает полномочий: все префиксы ROA должны входить в VRS-IP, все ASN сертификата маршрутизатора — в VRS-AS, а старый профиль RFC 6487 по-прежнему требует полного отказа при сверхзаявке.

Когда одна строка ломала наследование

Ресурсные сертификаты RPKI связывают открытые ключи с блоками IP-адресов и номерами автономных систем. Дочерний центр сертификации вправе передать лишь то, что подтверждается ресурсами его издателя и каждой следующей ступенью до якоря доверия. RFC 3779 задал ресурсные расширения, а RFC 6487 оформил профиль и процедуру проверки для RPKI.

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

Причина не обязательно злонамеренна. После передачи ресурсов набор родителя может уменьшиться раньше, чем ребёнок запросит замену сертификата. Система выпуска и управленческая база данных могут на время разойтись. В RFC 8360 авторы оценивали вероятность такого события в 2018 году как низкую, но потенциальный ущерб — как высокий. Требовалось отвергнуть лишнее, не уничтожая соседнее законное утверждение.

Документ совместно написали Geoff Huston, George Michaelson, Carlos Martinez, Tim Bruijnzeels, Andrew Newton и Donald Shaw. Их альтернативный алгоритм строится вокруг Verified Resource Set, или VRS. Валидатор не считает перечисленный в сертификате набор готовым полномочием, а берёт пересечение ресурсов, подтверждённых вдоль всего проверенного пути.

Пересечение задаёт верхнюю границу

Адресные и AS-ресурсы считаются раздельно. VRS-IP относится к IP-блокам, VRS-AS — к номерам автономных систем. Если сверхзаявки нет, новый и старый алгоритмы дают одинаковый результат. Если она есть, разность между заявленным набором и VRS точно показывает исключённую часть.

Новое поведение нельзя незаметно распространить на старые сертификаты. RFC 8360 ввёл политику сертификата версии 2 и новые OID ресурсных расширений. При таком профиле поддерживающая его relying party предупреждает о лишних ресурсах и продолжает проверку с VRS. При прежней политике RFC 6487 сертификат обязан быть отклонён. OID здесь обозначает не косметическую версию, а конкретную семантику и границу совместимости.

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

В примере спецификации дочерний CA заявляет подтверждённый 192.0.2.0/24 и неподтверждённый 198.51.100.0/24. Первый остаётся в VRS, второй исключается. ROA для первого может быть действительным, для второго — нет. Сохранение законной ветви не переносит через границу лишний префикс.

Подписанный объект проходит отдельную проверку

То, что сертификат CA сохранился, не делает все объекты под ним действительными. RFC 6482 определяет ROA, а RFC 8360 требует, чтобы каждый её префикс находился внутри VRS-IP сертификата конечного субъекта. ROA, объединившая допустимый и исключённый префиксы, всё равно может целиком провалить проверку.

Отсюда следует практический способ локализации. Раздельные ROA для независимых префиксов не позволяют потере одного ресурса уничтожить чужие разрешения на анонс. Для сертификатов маршрутизаторов BGPsec действует сходное правило: VRS-AS должен охватывать все заявленные ASN, а отдельные сертификаты по ASN могут уменьшить сопутствующий ущерб.

Область задачи также ограничена одним якорем доверия. Перекрывающиеся притязания нескольких якорей RFC 8360 не решает. И локальная настройка relying party не превращается в криптографическое владение. Алгоритм меняет размер отказа внутри одного пути, но не источник ресурсных полномочий.

Миграция начинается с проверяющей стороны

Новые OID создают порог совместимости. Старый валидатор, не знающий альтернативного профиля, отклонит такой сертификат. Поэтому RFC 8360 ставит обновление relying-party-инструментов раньше выпуска сертификатов v2 центрами сертификации. Возможность издателя создать новый объект ещё не означает готовность получателей его понять.

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

RFC 8488 сохранил исторический взгляд одной реализации 2018 года. Тогдашнее описание RIPE NCC Validator упоминало выбираемый оператором строгий режим и настроенное альтернативное поведение вне него. Это свидетельство о конкретном продукте того времени, а не обещание современных настроек и не замена нормативной сигнализации OID из RFC 8360.

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

Источники