Установление сервером доверия
При применении иерархических и взаимных сертификатов используются следующие правила доверия публичным ключам.
1. Доверять любому публичному ключу, полученному из сертификатов-компонент иерархического сертификата, имеющегося в своем ID-файле.
2. Доверять любому публичному ключу, полученному из имеющего силу (т.е. уже прошедшего проверку) сертификата-компоненты.
Проиллюстрируем использование этих правил в процессе установления подлинности клиента, принадлежащего тому же дереву имен, что и сервер (Рис. 8.5).
Рис. 8.5 Установление подлинности с применением иерархических сертификатов: дерево имен компании Acme
· Клиент Alice/Sales/Acme пытается получить доступ к серверу SERVER1/Development/Acme. Клиент сообщает серверу свое полное имя и публичный ключ. Сервер начинает процесс установления подлинности публичного ключа клиента.
· Сравнением своего имени с именем клиента сервер выявляет наличие общего предка. Общий предок всегда существует, когда клиент и сервер из одного дерева имен. Очевидно, этот общий предок - /Acme. Сервер читает публичный ключ /Acme из сертификата-компоненты в своем ID-файле. Согласно правилу 1 сервер "уверенно знает" публичный ключ /Acme.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Acme создал для /Sales/Acme. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Acme. Если сертификат имеет силу, согласно правилу 2 сервер "уверенно знает" публичный ключ /Sales/Acme.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Sales/Acme
создал для Alice/Sales/Acme. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Sales/Acme. Если сертификат имеет силу, согласно правилу 2 сервер "уверенно знает" публичный ключ Alice/Sales/Acme.
· Проиллюстрируем использование правил доверия публичным ключам в процессе установления подлинности клиента, когда клиент и сервер принадлежат разным деревьям имен (Рис. 8.6).
Рис. 8.6 Установление подлинности с применением иерархических и взаимных сертификатов: деревья имен компаний Acme и Omega
В этом случае приходится использовать как иерархические сертификаты из ID-файлов, так взаимный сертификат из адресной книги. Предполагаем, что сертификатор /Acme создал взаимный сертификат для сертификатора /Omega. Этот взаимный сертификат хранится в локальной адресной книге сервера SERVER1/ Development /Acme.
· Клиент Jon/Marketing/Omega пытается получить доступ к серверу SERVER1/Development/Acme. Клиент сообщает серверу свое полное имя и публичный ключ. Сервер начинает процесс установления подлинности публичного ключа клиента.
· Поскольку общих предков у John/Marketing/Omega и SERVER1/Development/Acme нет, сервер вынужден обратиться к своей адресной книге в поисках взаимного сертификата. Этот взаимный сертификат должен быть выпущен от имени сервера SERVER1/Development/Acme или одного из его предков для пользователя John/Marketing/Omega или одного из его предков. По условию /Acme, предок SERVER1/Development/Acme, создал взаимный сертификат для /Omega, предка John/Marketing/Omega. Сервер извлекает из локальной адресной книги этот взаимный сертификат.
· Сервер читает публичный ключ создателя взаимного сертификата - /Acme - из сертификата-компоненты в своем ID-файле. Согласно правилу 1 сервер "уверенно знает" публичный ключ /Acme.
· Сервер проверяет взаимный сертификат, используя публичный ключ /Acme. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ /Omega.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Omega создал для /Marketing/Omega. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Omega. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ /Marketing/Omega.
· Сервер запрашивает у клиента сертификат-компоненту, которую /Marketing/Omega создал для John/Marketing/Omega. Клиент извлекает из своего ID-файла этот сертификат-компоненту и передает серверу. Сервер проверяет полученную сертификат-компоненту, используя публичный ключ /Marketing/Omega. Если сертификат имеет силу, cогласно правилу 2 сервер "уверенно знает" публичный ключ John/Marketing/Omega.
Отметим, что в этой процедуре происходила даже проверка взаимного сертификата, извлеченного "из собственной локальной" адресной книги. Следовательно, взаимный сертификат, как и всякий сертификат, "подписан" создавшим его сертификатором. Однако, изучив механизм "электронной подписи" (рассматривается в 9.5), любознательный читатель не обнаружит в документе Cross Certificate никаких следов ее применения. Все дело в "тонком" различии собственно публичного ключа и информации, которая хранится в поле с меткой Certified Public Key: некоторых документов, в том числе и документа Cross Certificate, из адресной книги - "сертифицированного публичного ключа". Обратим внимание, что "в дизайне" это поле имеет имя Certificate. Сертифицированный публичный ключ сам является сертификатом - в нем содержится вся та информация, которая входит в состав сертификата, в том числе и публичный ключ. Косвенным подтверждением этого является следующий факт. При продлении срока действия сертификата в ID-файле пользователя изменяется сертифицированный публичный ключ в документе Person. Однако при этом в ID-файле не происходит смены публичного ключа и связанного с ним личного ключа - пользователь сохраняет возможность читать шифрованную почту в своем почтовом ящике и работать с базами данных, для которых применено локальное шифрование.
