На рис. 10.8 показаны пути сертификации, которые могут связывать пользователя А с пользователями B, C и D. Для пользователей C и D имеется не один путь. Каждый путь является валидным, но одни пути длиннее других. Как и в сетевой архитектуре, поиск кратчайшего пути значительно усложняет процесс построения пути.
Архитектура кросс-сертифицированных PKI - подходящее решение в том случае, когда отношения доверия устанавливаются между несколькими корпоративными PKI (их не должно быть много). Рис. 10.8 показывает, что для установления отношений, описанных в примере, потребовались три одноранговые связи и шесть сертификатов удостоверяющих центров. С увеличением числа корпоративных PKI количество связей и сертификатов быстро растет. Кросс-сертификация n-корпоративных PKI требует (n2 - n)/2 - одноранговых связей и (n2 - n) - сертификатов [70].
Рис. 10.9. Восемь кросс-сертифицированных PKI
На рис. 10.9 представлены восемь корпоративных PKI. Кросс-сертификация всех пар инфраструктур требует установления 28 одноранговых связей и выпуска 56 сертификатов удостоверяющих центров. В связи с тем, что установление этих связей требует длительного изучения политик и практической работы удостоверяющих центров, реализация этой архитектуры становится слишком трудоемкой задачей.
Архитектура мостового УЦ
Архитектура мостового УЦ разрабатывалась для преодоления недостатков архитектуры расширенного списка доверия и корпоративных PKI, связанных отношениями кросс-сертификации. С одной стороны, трудно было ожидать, что пользователи будут поддерживать в актуальном состоянии информацию о многих пунктах доверия. С другой стороны, администраторам УЦ был необходим более эффективный механизм установления отношений доверия с другими PKI. Поэтому был предложен мостовой УЦ, который удовлетворяет этим требованиям, действуя в некоторой степени в роли арбитра доверия.
В отличие от сетевого центра, мостовой УЦ не выпускает сертификаты непосредственно для пользователей, а, в отличие от головного УЦ, в иерархии мостовой УЦ не является пунктом доверия. Все пользователи PKI рассматривают мостовой УЦ в качестве посредника. Мостовой УЦ устанавливает одноранговые отношения с разными корпоративными PKI. Эти отношения принимают вид моста доверия, который связывает пользователей разных PKI [10]. Если домен доверия реализован как иерархическая PKI, мостовой УЦ устанавливает связь с головным УЦ иерархии. Если домен реализован как сетевая PKI, мостовой УЦ устанавливает связь только с одним из удостоверяющих центров сети. Удостоверяющий центр, который вступает в отношения с мостовым УЦ, называется главным УЦ .
Пример 10.7. На рис. 10.10 мостовой УЦ связан с тремя корпоративными PKI. Первая PKI - это УЦ пользователей А и В, вторая - иерархическая PKI пользователя С, и третья - сетевая PKI пользователя D. Никто из пользователей не доверяет непосредственно мостовому УЦ. Пользователи А и В доверяют УЦ "Альфа", который является издателем их сертификатов, они доверяют мостовому УЦ постольку, поскольку их собственный УЦ выпустил для него сертификат. Пункт доверия пользователя С - головной УЦ в его иерархии; пользователь С доверяет мостовому УЦ косвенно, потому что данный головной УЦ выпустил для того сертификат. Пользователь D доверяет издателю своего сертификата - УЦ3 компании "Гамма" и косвенно доверяет мостовому УЦ, потому что существует правильный путь сертификации от УЦ3 до мостового УЦ. Пользователи А и В могут использовать мост доверия для установления отношений с пользователями С и D.
Рис. 10.10. Связывание трех корпоративных PKI при помощи мостового УЦ и построение путей сертификации
Отношения доверия между мостовым УЦ и главными удостоверяющими центрами являются одноранговыми. Отношения доверия внутри корпоративных PKI, которые связывает мост, определяются их собственной архитектурой.
В связанные мостом инфраструктуры легко добавляются новые удостоверяющие центры или даже целые корпоративные PKI [100]. Изменения остаются прозрачными для пользователей, пока они не касаются пунктов доверия. По мере роста PKI число отношений доверия, которые должны быть установлены, начинает превышать разумное и поддающееся управлению. На рис. 10.10 для трех корпоративных PKI были установлены три отношения доверия, как и в примере кросс-сертификации (рис. 10.8). Рис. 10.11 иллюстрирует связывание восьми корпоративных PKI при помощи мостового УЦ. Это требует установления восьми отношений доверия, а не двадцати восьми, как требовалось в варианте кросс-сертификации (рис. 10.8).
Рис. 10.11. Связывание восьми корпоративных PKI при помощи мостового УЦ
Мостовой УЦ не решает проблем построения пути сертификации или валидации. Построение пути выполняется так же сложно, как и в сетевой PKI, поскольку некоторые из корпоративных PKI представляют собой сети. Сертификаты, выпускаемые самим мостовым УЦ и для него, могут быть слишком сложными, чтобы гарантировать точное установление отношений доверия. Это повышает сложность программной реализации алгоритма валидации пути.
Мостовая архитектура позволяет PKI легко восстанавливаться после компрометации. Если главный УЦ корпоративной PKI скомпрометирован, мостовой УЦ просто аннулирует его сертификат. Это разрывает отношения доверия между этой PKI и любой другой корпоративной PKI, но не влияет на остальные отношения доверия. Если скомпрометирован сам мостовой УЦ, он уведомляет об этом главные удостоверяющие центры. Так как пользователи не считают мостовой УЦ пунктом доверия, главные удостоверяющие центры просто аннулируют сертификаты, которые они выпустили для мостового УЦ. В свою очередь, мостовой УЦ также может опубликовать информацию об аннулировании сертификатов, которые им были выпущены для удостоверяющих центров. В результате образуется совокупность отдельных PKI, и их пользователи теряют возможность поддерживать между собой защищенные коммуникации. С другой стороны, после восстановления работы мостового УЦ достаточно просто полностью восстановить PKI.
Построение пути в мостовой PKI
Мостовой УЦ имеет ряд преимуществ по сравнению с кросс-сертифицированными PKI. Разные пользователи по-прежнему строят разные пути сертификации для одного и того же сертификата конечного субъекта, и путь сертификации начинается с пункта доверия пользователя, который желает построить путь до данного сертификата. Однако существует только один кросс-сертификат, связывающий данную PKI со всеми сторонними PKI. Это существенно упрощает построение пути сертификации. На рис. 10.10 показаны пути сертификации, которые связывают пользователя А и пользователей B, C и D. Пользователь D может построить не один путь, так как является участником сетевой PKI.
Когда простые и иерархические PKI связаны мостом доверия, построение пути сертификации лишь немного сложнее, чем в обычной иерархической PKI [101]. Внутри иерархии может быть использован простой способ построения пути, но когда он перестает работать, выбирается только один кросс-сертификат, который издан мостовым УЦ. Среди многих кросс-сертификатов, выпущенных для мостового УЦ, только один сертификат будет издан одиночным УЦ простой PKI или головным УЦ иерархической PKI. Нахождение пункта доверия на основе кросс-сертификатов, выпущенных для мостового УЦ, - достаточно простая задача. Когда мостом доверия связаны сетевые PKI, построение пути сертификации внутри сети остается сложным. Однако если каждая из сторонних PKI управляет отдельным пространством имен, предположения о том, какой сертификат является наиболее подходящим, обычно бывают правильными. Кроме того, введение мостового УЦ не приводит к образованию дополнительных петель, петли могут появляться только внутри сетевой PKI.
