Обработка пути сертификации заключается в нахождении пути, или цепочки, сертификатов между данным целевым сертификатом и доверенным ключом и проверке валидности каждого сертификата в этом пути. Под доверенным ключом понимается ключ пункта доверия субъекта, выполняющего построение и валидацию пути . Иными словами, окончательная цель одного пользователя заключается в проверке того, можно ли доверять открытому ключу в сертификате другого пользователя. Проверяемый сертификат (и, следовательно, соответствующий открытый ключ) является надежным, если обнаруживается, что каждый сертификат (и соответствующий открытый ключ) построенного пути является надежным.
Обработка пути сертификации состоит из двух этапов:
1 построение пути, которое заключается в агрегировании всех сертификатов, необходимых для формирования полного пути;
2 валидация пути, которая включает последовательную проверку каждого сертификата пути и определение надежности соответствующего открытого ключа.
Построение и валидация пути сертификации зависят от топологии PKI, часто они выполняются как два независимых шага, но могут быть и объединены.
Построение пути сертификации
Построение пути может быть очень сложной и трудоемкой задачей, особенно если требуется обработка большого количества сертификатов. Это связано с трудностями поиска сертификата субъекта, который подписал данный сертификат, если субъект находится вне данной локальной среды. Базовое допущение при построении пути заключается в том, что пользователь может найти или каким-то образом получить все сертификаты, необходимые ему для проверки, и сконструировать путь.
Рис. 10.1. Пример построения пути
Пример 10.1. Пусть пользователь А пытается проверить надежность сертификата пользователя В, с которым он желает взаимодействовать [44]. Предположим, что пользователь В сертифицирован УЦ3, УЦ3 кросс-сертифицирован с УЦ2 (наряду с другими удостоверяющими центрами), УЦ2 кросс-сертифицирован с УЦ1 (наряду с другими), а пользователь А владеет доверенной копией открытого ключа УЦ1 (см. рис. 10.1).
Так как пользователь А владеет сертификатом пользователя В, то знает, что последний сертифицирован УЦ3. В силу того, что УЦ3 кросс-сертифицирован с несколькими удостоверяющими центрами (в нашем примере - тремя), пользователю А необходимо определить, какой кросс-сертификат добавит связь в путь, который он строит. УЦ1 не подписывал никакой из сертификатов УЦ3 (ни УЦ2, ни УЦ6, ни УЦ7 ), поэтому пользователь А должен действовать путем проб и ошибок. Он проверяет каждый из кросс-сертификатов, связанных с УЦ2, УЦ6 и УЦ2, - не подписан ли какой-либо из них УЦ1. В данном примере УЦ2 владеет кросс-сертификатом, заверенным УЦ1, поэтому работа пользователя А по построению пути на этом завершается, поскольку УЦ1 является его пунктом доверия.
Очевидно, что это задание существенно усложняется, если УЦ3 и УЦ2 кросс-сертифицированы со многими другими удостоверяющими центрами и/или если путь между УЦ1 и УЦ3 содержит больше промежуточных удостоверяющих центров. В таких случаях для построения пути используются алгоритмы нахождения пути, базирующиеся на теории графов, включая такие алгоритмы поиска, как поиск преимущественно в глубину (не рекомендуемый из-за большого числа лишних вычислений в общем случае), поиск преимущественно в ширину и эвристический алгоритм.
Простая архитектура PKI
Архитектура PKI может быть очень простой, если у пользователей - простые требования. В этом разделе рассматриваются два типа простой архитектуры: одиночный УЦ и списки доверия УЦ. Простая архитектура достаточна для связывания пользователей одного и того же УЦ или нескольких удостоверяющих центров, которым нет необходимости устанавливать отношения доверия с другими центрами, причем сертификаты выпускаются только для пользователей.
Одиночный УЦ
Базовой архитектурой PKI является одиночный УЦ, который обеспечивает свое сообщество пользователей сертификатами и списками САС [97]. В этой конфигурации все пользователи доверяют одному УЦ, который выпускает сертификат сам для себя. По определению, новые удостоверяющие центры не могут добавляться в PKI. Поскольку в данной инфраструктуре имеется только один УЦ, здесь отсутствуют отношения доверия между несколькими удостоверяющими центрами. Пользователи принимают сертификаты и списки САС, выпущенные единственным УЦ. В результате пути сертификации строятся на основании одного сертификата и одного САС. В силу того, что все остальные сертификаты являются сертификатами пользователей, для анализа пути не используется информация, которая описывает или ограничивает отношения доверия УЦ.
На рис. 10.2 изображен одиночный УЦ, который выпускает сертификаты для служащих компании, в том числе для пользователей А и В. Пользователь А доверяет корпоративному УЦ, поэтому может легко строить и проверять путь сертификации пользователя В. Будучи самой простой в реализации, эта архитектура трудно масштабируется в условиях очень больших или разнородных сообществ пользователей. Когда у пользователей А и В по роду работы возникает необходимость защищенно связаться с пользователем P из другой компании, им необходима архитектура, объединяющая их собственный УЦ и внешние удостоверяющие центры, поскольку пользователь P, не являясь служащим компании, где работают пользователи А и В, имеет сертификат, изданный другим УЦ.
Рис. 10.2. Одиночный УЦ и пути сертификации
В PKI с одиночным УЦ существует только одна точка отказа. Компрометация УЦ делает недействительными все выпущенные им сертификаты и информацию о пункте доверия. Каждый пользователь такой PKI должен быть немедленно информирован о компрометации, в противном случае пользователи, доверяющие ненадежному УЦ, будут подвергаться риску. Для того чтобы восстановить работу УЦ, необходимо повторно выпустить все сертификаты и распространить новую информацию о пункте доверия среди всех пользователей.