Книга: Инфраструктуры открытых ключей

Организация репозитория и протоколы доступа к нему

Традиционным вариантом организации репозитория PKI является каталог. Используются несколько типов систем каталога, но имеются и другие варианты поддержки PKI-информации. Для передачи сертификатов и данных об аннулировании могут использоваться любые протоколы, которые приняты для распространения двоичной информации. Обмен PKI-информацией может осуществляться при помощи электронной почты S/MIME версии 3, сетевых протоколов FTP, HTTP, TLS и IPSec (особенно протокола обмена ключами Internet Key Exchange - IKE) и даже системы доменных имен DNS.

В некоторых средах, например, в Интернете, обмен сертификатами и списками САС при помощи сетевых протоколов может быть единственным способом передачи этой информации пользователям PKI. Следует отметить, что обмен PKI-информацией на базе сетевых протоколов может лишь дополнить, а не полностью заменить использование репозитория.

Каталоги

Каталог - это онлайновая база данных, хранящая произвольную информацию. Информация об определенном человеке или объекте называется входом каталога. Каждый вход связан с классом объектов, описывающим атрибуты входа. Классы объектов, связанные с людьми, и классы объектов, связанные с компьютерным оборудованием, содержат разные атрибуты. Чтобы получить информацию из каталога, клиенты должны знать: куда отправить запрос, какой вход и какие атрибуты входа необходимы. Следует отметить, что поиск информации поддерживается даже тогда, когда точное имя входа неизвестно.

Каждый вход идентифицируется отличительным именем. Отличительные имена используются в сертификатах в качестве имен субъектов и издателей. Запросы клиентов различают атрибуты в зависимости от искомой информации (например, сертификат или САС). Атрибуты задаются несколькими спецификациями, рекомендуемыми организацией IETF, источником является документ RFC 2587 - схема протокола LDAP версии 2 >[157].

Атрибут userCertificate содержит сертификаты тех конечных субъектов, имена которых соответствуют отличительному имени входа.

Атрибут cACertificate содержит сертификаты тех удостоверяющих центров, имена которых соответствуют отличительному имени входа.

Атрибут certificateRevocationList содержит список аннулированных сертификатов.

Атрибут authorityRevocationList (ARL) содержит списки аннулированных сертификатов, выпущенных только для других удостоверяющих центров.

Атрибут deltaRevocationList содержит дельта-списки САС.

Атрибут crossCertificationPair содержит пару кросс-сертификатов удостоверяющих центров. Элементы этой пары могут быть прямыми и обратными. Прямой и обратный элементы представлены значением отдельного атрибута. Субъект одного сертификата и издатель другого сертификата соответствуют отличительному имени входа. Открытый ключ субъекта одного сертификата позволяет проверить цифровую подпись другого сертификата и наоборот. Пара кросс-сертификатов представлена на рис. 12.2.

Рис. 12.2.  Пара кросс-сертификатов

Документ RFC 2587 определяет три класса объектов PKI: пользователи pkiUser, удостоверяющие центры pkiCA и пункты распространения САС cRLDistributionPoint.

Класс объектов pkiUser используется для входов владельцев сертификатов. Входы должны содержать атрибуты сертификатов пользователей. Все сертификаты, имена субъектов которых соответствуют имени входа каталога, должны храниться в pkiUser.

Класс объектов pkiCA используется для входов удостоверяющих центров. Входы pkiCA могут содержать сертификат УЦ, САС КП, САС УЦ, пару кросс-сертификатов. Атрибут "сертификат УЦ" включает сертификаты удостоверяющих центров, имя субъектов которых связано с этим входом. Сертификаты могут быть, в том числе, и самоизданными. Атрибут ARL содержит списки аннулированных сертификатов только удостоверяющих центров. Атрибут crossCertificationPair содержит одну или несколько пар кросс-сертификатов. Прямые элементы этого атрибута входа каталога УЦ хранят сертификаты, выпущенные другими удостоверяющими центрами для данного УЦ. Обратные элементы этого атрибута могут содержать сертификаты, выпущенные данным УЦ для других удостоверяющих центров.

Класс объектов cRLDistributionPoint может включать атрибуты САС КП, САС УЦ и дельта-списки САС. Имя входа каталога должно соответствовать имени в дополнении "пункты распространения САС".

Каталог X.500

В документе RFC 2116 >[141] каталог X.500 описывается как распределенная база данных, в которой хранится информация о людях и объектах в различных узлах сети и на распределенных серверах. Различные серверы сети называются агентами сервера каталога (АСК), а клиенты - агентами пользователя каталога (АПК). АСК отвечает на запросы АПК. На рис. 12.3 представлен концептуальный вид каталога X.500 >[70].

Каталог использует два базовых протокола: протокол доступа к каталогу (Directory Access Protocol - DAP) и протокол сервиса каталога (Directory Service Protocol - DSP) >[126]. Протокол DAP поддерживает информационные запросы от АDК к АCК. Протокол DSP поддерживает информационные запросы между АСК. В общем, АСК объединяются для поддержки информации, разделяемой путем связывания. АСК могут дополнять протокол DSP протоколом дублирования информации каталога (Directory Information Shadowing Protocol - DISP). Протокол может использоваться для репликации контентов (или подмножества контентов) АСК. Эта операция обычно называется дублированием. С точки зрения АПК, вся база данных размещается в отдельной системе. Этой системой является АСК, который управляет информационными запросами АПК. Количество агентов АСК и способ их объединения невидимы для АПК. Ясно, что когда используется связывание, каталог X.500 обеспечивает прозрачность местонахождения репозитория.

Распределенный характер каталога X.500 обеспечивает также высокую доступность. Если один из агентов АСК становится недоступным, то теряется доступ только к той информации, которая физически размещается в этой системе. Безусловно, агенты АПК, которые обращаются с запросами к недоступному АСК, должны быть обслужены другим агентом или получить отказ в доступе к каталогу. Доступность можно в дальнейшем повысить путем дублирования информации на нескольких АСК.

Рис. 12.3.  Концептуальный вид каталога X.500

Производительность репозитория может варьироваться в зависимости от физического размещения информации и способа связывания агентов АСК. Рассмотрим подробнее рис. 12.3. Если пользователь А направляет свои запросы АСК 1, а пользователь B - АСК 5, то пользователи, получая одну и ту же информацию, будут обслуживаться с разной скоростью. Если информация размещается в системе АСК 1, то пользователь А получит информацию очень быстро, так как она размещена локально. Пользователь B должен будет ждать, пока его запрос будет направлен в АСК 2, затем в АСК 1, и только потом вернется ответ. Средняя производительность оптимизируется, если информация, которую часто используют, находится на ближайшем АСК.

Агенты АСК могут обслуживать анонимные запросы от АПК или выполнять аутентификацию запросов на базе паролей или цифровых подписей. Аутентифицируемые запросы поддерживают бизнес-модель возмещения затрат на развертывание PKI за счет доверяющих сторон. Аутентифицируемые запросы также важны для управления информированием об обновлении каталога. Удостоверяющие центры могли бы включать АПК для автоматической поддержки аутентифицируемых запросов о текущем состоянии каталога. Цифровые подписи могут использоваться для сильной аутентификации, а сертификаты и списки САС - отправляться без вмешательства операторов УЦ. Однако удостоверяющие центры обычно информируют о текущем состоянии каталога при помощи упрощенного протокола доступа к каталогу LDAP.

Упрощенный протокол доступа к каталогу LDAP

Использование протокола DAP оказалось слишком обременительным для многих клиентских приложений. В результате в Университете штата Мичиган был разработан упрощенный протокол доступа к каталогу LDAP. Протокол LDAP был усовершенствован и стандартизирован организацией IETF >[157]. Наиболее распространенным протоколом доступа к репозиторию является протокол LDAP второй версии.

В общем случае, каталоги LDAP v2 непосредственно не связаны между собой. Если каталог LDAP получает запрос на вход, который размещается в другом месте, то проверяет таблицу удаленных каталогов. Если один из этих каталогов содержит искомый вход, то каталог возвращает ссылку другим каталогам. Ссылка содержит имя каталога и систему, которая его поддерживает. Это упрощает реализацию каталога и не требует поддержки протокола DSP. Однако эта архитектура не обеспечивает прозрачность местонахождения репозитория. Прежде чем получить любую информацию, клиент должен определить физическое местонахождение репозитория. Более того, имеются реализации клиентов LDAP, которые фактически управляют ссылками. Если сертификаты или списки САС недоступны в первом проверяемом каталоге, они не будут найдены.

Репозиторий PKI на базе протокола LDAP обычно представляет собой отдельный репозиторий или репозиторий, информация которого распределена между несколькими пунктами распространения САС. Информация о пунктах распространения САС, о доступе к информации УЦ и доступе к информации субъекта содержится в дополнениях сертификатов. Для систем с большим количеством пользователей несколько пунктов распространения необходимы для сокращения времени отклика и повышения отказоустойчивости. При этом все серверы распространения САС могут находиться в непосредственной близости друг от друга и управляться централизованно, а могут быть территориально распределены. В распределенной системе возникают проблемы запаздывания и дороговизны трафика при обращении с запросом в территориально отдаленный сегмент сети. Масштабирование каталогов LDAP достигается при помощи более мощных и быстродействующих серверов.

Большинство программных продуктов поддержки удостоверяющих центров включают LDAP-клиента и могут автоматически выполнять аутентификацию запросов об обновлении каталога. Аутентификация базируется на имени и пароле пользователя. Сертификаты и списки САС могут быть отправлены без вмешательства операторов УЦ.

Серьезным недостатком каталога X.500 было использование протокола DAP. Протокол работал, но признавался слишком громоздким. В результате большинство клиентских приложений поддерживали протокол LDAP, а не DAP. Современные реализации каталога X.500 ориентируются на протокол LDAP. Это решение обладает всеми атрибутами мощного механизма репозитория: прозрачностью размещения и масштабируемостью с целью удовлетворения возрастающих требований организации к производительности и доступности.

Организация IETF продолжила работу над протоколом LDAP. В результате была создана третья версия протокола. В настоящее время разрабатывается ряд дополнений. После завершения работы эти дополнения обеспечат средства поддержки связывания и репликации. Переход от второй версии репозитория LDAP v2 к третьей версии LDAP v3 может потребовать некоторой дополнительной настройки.

FTP

Протокол передачи файлов File Transfer Protocol (FTP) описывается в документе RFC 959 >[131]. Серверы FTP давно используются для распространения информации в Интернете, они могут предоставлять информацию по анонимным запросам или после предъявления пользователем имени и пароля.

Документ RFC 2585 >[156] определяет типы данных и правила образования имен для передачи сертификатов и списков САС с использованием FTP. Файлы с расширением .cer содержат только сертификаты, а файлы с расширением .crl - только списки САС. Имена файлов задаются как унифицированные идентификаторы ресурсов в дополнениях сертификатов и списков САС. Например, ftp://ftp.alpha.com/pki/id48.cer задает отдельный сертификат, доступный анонимно с ftp.alpha.com. Документ RFC 2585 не описывает типы данных, которые содержат множественные значения или пары кросс-сертификатов.

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

Рис. 12.4.  Двухшаговая публикация сертификата

FTP-серверы могут отслеживать активность пользователей, требуя от них введения имени и пароля. Из-за сложности управления большим количеством учетных записей пользователей FTP-серверы не способны обслуживать крупномасштабные PKI. Для наполнения FTP- репозитория требуется двухшаговый процесс, как показано на рис. 12.4 >[70]. УЦ публикует информацию в каталоге, а затем программа-утилита копирует сертификаты и списки САС из каталога в файловую систему FTP-сервера. FTP-серверы с анонимным доступом лучше подходят в качестве репозитория, но не позволяют поддерживать в PKI бизнес-модель возмещения затрат за счет доверяющих сторон, поскольку не способны генерировать счета для всех систем, которые запрашивают данные (даже если IP-адреса систем регистрируются).

Функциональная совместимость также является проблемой. Лишь немногие коммерческие программные продукты, реализующие работу удостоверяющих центров, могут автоматически наполнять FTP-сервер сертификатами и списками САС.

HTTP

Протокол передачи гипертекста HTTP определяется в документе RFC 2068 >[140]. Документ RFC 2585 описывает типы данных и правила образования имен для передачи сертификатов и списков САС с использованием протокола HTTP. Правила образования имен подобны правилам, принятым для протокола FTP. Имена файлов задаются как унифицированные идентификаторы ресурсов в дополнениях сертификатов и списков САС, например, http://www.alpha.com/pki/id48.cer.

Протокол HTTP может обеспечить прозрачность размещения репозитория, а также может применяться для автоматической переадресации запроса к системе, в которой хранится необходимая информация. Широко распространена практика создания виртуальных web-серверов, которые фактически состоят из многих отдельных серверов. Поскольку все клиенты используют один и тот же хорошо известный URL (например, http://www.cnn.com), разные запросы могут обслуживаться разными серверами. Этот процесс прозрачен для клиента. Подобная схема позволяет администратору HTTP- репозитория выполнять масштабирование системы для обеспечения адекватной производительности и доступности. Если HTTP-сервер поддерживает протокол SSL или TLS с аутентификацией клиента, то может идентифицировать или аутентифицировать источник каждого запроса. В этом случае в PKI возможна реализация бизнес-модели оплаты за обслуживание запросов.

Однако функциональная совместимость является проблемой. Немногие программные продукты, реализующие работу удостоверяющих центров, имеют функции автоматического наполнения HTTP- репозитория сертификатами и списками САС.

Электронная почта

Документ RFC 822 задает формат другого широко распространенного протокола передачи данных: протокола электронной почты >[130]. Почти каждая компания имеет серверы электронной почты. Практически каждая клиентская система поддерживает электронную почту. Клиент может запросить сертификат или список САС через субъект или тело почтового сообщения. Сертификаты и списки САС могут быть возвращены как вложения в ответе на почтовое сообщение типа MIME, определенном в документе RFC 2585. Подобное решение привлекает своей простотой, однако почтовый репозиторий не обладает необходимыми свойствами.

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

Удостоверяющие центры могут наполнять почтовый репозиторий за два шага. Источник каждого запроса достаточно легко аутентифицировать. Если запросы к репозиторию передаются в виде подписанных цифровой подписью сообщений электронной почты (например, S/MIME), репозиторий может аутентифицировать и лицо, обращающееся с запросом. Аутентификация позволяет поддерживать бизнес-модель оплаты за обслуживание запросов.

Пока не существует улучшенного стандарта распространения сертификатов и списков САС по электронной почте. В отсутствие правил образования имен и утвержденного протокола электронная почта не может использоваться в качестве основного механизма распространения сертификатов и списков САС. Однако передача последних версий списков САС по электронной почте очень удобна для пользователей.

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

Одной из наиболее удачных распределенных информационно-поисковых систем является система доменных имен (DNS) Интернета. Система DNS описывается в документах RFC 1034 >[132] и RFC 1035 >[133]. Документ RFC 1035 утверждает, что целью доменных имен является обеспечение такого механизма именования, чтобы имена могли использоваться разными хостами, локальными и глобальными сетями, семействами протоколов и организациями. Система DNS обеспечила реализацию этих целей, и исследователи постоянно ищут новые способы совершенствования ее возможностей.

Ведется много дискуссий о возможном использовании системы DNS для унификации многих разрозненных каталогов и разработке соответствующих протоколов доступа в помощь клиентам. Эта концепция требует новых типов данных, идентифицирующих репозиторий некоторого домена, а не предполагает использования системы DNS для транспортировки сертификатов и списков САС. Пусть, например, клиент обрабатывает сообщение электронной почты от домена alpha.com. Он должен создать запрос к системе DNS. Если бы в ответе указывался общий репозиторий для PKI компании "Альфа", это позволило бы упростить сертификаты, исключив из них указатели на местонахождение репозитория. Тогда можно было бы менять протоколы доступа к репозиторию PKI без повторного выпуска сертификатов. Эта идея пока не реализована, но организация IETF в качестве эксперимента начала процесс стандартизации данного подхода.

Оглавление книги