Кратко

  • В примере RFC 5217 инфраструктура PKI2 входит в два домена. Поэтому можно построить путь от PKI1 через PKI2 к PKI3, однако проверка по политике домена 1 не должна завершиться успешно: крайние участники не состоят в нём вместе.
  • Кросс-сертификаты и Bridge CA создают подписанную связность. Для принятия всё ещё нужны якорь доверия, отображения и ограничения политик и имён, актуальная принадлежность к доменам, сведения об отзыве и решение конкретной полагающейся стороны.

Отказ при безупречной цепочке

Движок нашёл все сертификаты, проверил подписи и довёл кандидата до настроенного якоря доверия. Никакого отсутствующего файла или испорченной подписи в журнале не было. Последней строкой стоял отказ.

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

PKI2 одновременно участвует в доменах 1 и 2. От PKI1 до PKI2 есть путь, как и от PKI2 до PKI3. Построитель способен соединить участки. Однако PKI1 и PKI3 не имеют общей принадлежности к домену 1. При проверке по его политике цепочка не должна быть принята.

Граф доказал возможность перехода. Он не доказал право полагаться на результат.

Построение находит кандидата

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

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

RFC 5217 оставляет каждой PKI собственные OID политики и Principal CA. Перед внешним доверием стороны изучают документы политики и управления и решают, какие уровни гарантий сопоставимы. Кросс-сертификат технически оформляет ограниченный вывод, а не сливает институты.

Двойное членство создаёт боковой проход

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

RFC 5217 помещает границу в подписанные кросс-сертификаты: отображения политик, policy constraints и name constraints должны исключать проверку вне нужного домена. Нельзя надеяться только на одинаковую локальную настройку у всех полагающихся сторон.

Членство меняется во времени. Вход PKI в другой домен или выход из него меняет множество доступных путей. Об изменении нужно уведомить участников, ограничения пересмотреть, а при изменении допустимого графа старый сертификат отозвать и выпустить заново.

Подпись защищает формулировку, но не замораживает описанные ею отношения.

Bridge CA не становится общим корнем

Bridge CA сокращает число двусторонних кросс-сертификатов и сопоставляет политики. RFC 5217 запрещает использовать её как якорь доверия участвующего домена и выдавать обычные сертификаты конечным субъектам.

Так координационный центр не превращается в верховный источник полномочий. Полагающаяся сторона начинает со своего якоря, а при проходе через мост обрабатывает подписанные условия обеих сторон. Центральное место в топологии не означает право определять риск для всех.

У списка доверия есть хозяин

Локальный список поддерживает одна полагающаяся сторона. Он прост и может обходиться без кросс-сертификации, но обновляется отдельно. Trust Authority ведёт общий список для нескольких сторон и централизует работу.

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

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

Квитанция полномочия на принятие

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

В ней остаются точный путь, все обработанные отображения и ограничения, снимок членства, статусы кросс-сертификатов, версия списка, свежесть CRL или OCSP, конечный результат и причина, а также фактически разрешённое либо запрещённое действие.

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

Граница вывода

RFC 5217 носит информационный характер и допускает иные архитектуры. Та же цепочка может быть допустима с другим якорем, назначением или сообществом. Здесь не утверждается дефект конкретного CA, продукта или внедрения.

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

Источники

Дополнительный реестр стандартов

  1. RFC 5217 в текстовом формате
  2. Информационная запись RFC 5217
  3. Запись IETF Datatracker
  4. История IETF Datatracker
  5. RFC 4949: глоссарий безопасности Интернета
  6. RFC 5914: формат якоря доверия
  7. RFC 5934: требования к управлению якорями
  8. RFC 6024: требования к протоколу управления якорями
  9. RFC 5055: серверная проверка сертификатов
  10. RFC 6818: обновления RFC 5280
  11. RFC 6960: протокол OCSP
  12. RFC 5019: облегчённый профиль OCSP
  13. RFC 6962: прозрачность сертификатов
  14. RFC 7030: регистрация через защищённый транспорт