Иерархия

Иерархическая модель доверия наиболее проста для восприятия. Говоря простым языком, в данном случае вы доверяете человеку, который находится выше в иерархической цепи, так как от него было получено соответствующее указание о необходимости доверия. На рис. 6 изображена схема этой модели. Как видно из рисунка, пользователи User1 и User2 располагаются под CA1. Следовательно, если CA1 говорит, что сертификат открытого ключа принадлежит пользователю User1, пользователь User2 будет верить этому. На практике User2 передает пользователю User1 свой сертификат открытого ключа, подписанный CA1. Пользователь User1 проверяет подпись CA1 с использованием открытого ключа CA1. Так как CA1 находится в иерархии выше, чем User1, то User1 доверяет CA1 и, следовательно, доверяет сертификату пользователя User2.

Мы рассмотрели довольно простой случай. Если пользователю User1 нужно проверить информацию от пользователя User3, все несколько усложняется. CA1 не знает о пользователе User3, в отличие от CA2. Тем не менее, пользователь User1 не доверяет CA2, так как это бюро сертификатов напрямую не принадлежит цепочке пользователя User1. Следующий уровень вверх по цепочке - CA4. Пользователь User1 может верифицировать информацию от пользователя User3 посредством проверки с помощью CA4 следующим образом.

1. Пользователь User1 смотрит на сертификат пользователя User3. Он подписан в CA2.
2. Пользователь User1 получает сертификат пользователя CA2. Он подписан в CA4.
3. Так как пользователь User1 доверяет CA4, открытый ключ CA4 может использоваться для верификации сертификата CA2.
4. Как только сертификат CA2 верифицирован, пользователь User1 может верифицировать сертификат пользователя User3.
5. Как только будет верифицирован сертификат пользователя User3, пользователь User1 может использовать открытый ключ пользователя User3 для верификации данных.

Рис. 6. Иерархическая модель доверия

Как видно, все довольно быстро усложняется. Представьте себе, какой объем операций по верификации необходимо было бы производить, если бы пользователю User1 нужно было верифицировать данные, поступившие от пользователя User4. Две цепочки не пересекаются вплоть до CA9! Так реализована сертификация в X.509. Иерархия устанавливается таким образом, чтобы между любыми двумя нижними объектами могла быть создана цепочка сертификатов.

С теоретической точки зрения все выглядит неплохо. Однако на практике все иначе. Одной из причин, по которой данная технология не функционировала, заключается в том, что не существовало реальных CA корневого уровня. CA корневого уровня - это наивысшая точка в иерархии. В одно время было принято считать, что в каждой стране должно быть свое бюро сертификатов корневого уровня. Также предполагалось, что компании, выпускающие кредитные карты, должны стать корневыми CA, или что каждая организация должна иметь свое собственное CA. На практике почти ничего не было реализовано. Возникал еще один вопрос, который представлял собой потенциальную проблему: сколько CA должны сертифицировать каждого конечного пользователя? Если конечный пользователь живет в стране А, обладает кредитной картой компании B и работает в организации C, должны ли все три объекта подписывать один и тот же сертификат?