Ольга Полянская - Инфраструктуры открытых ключей

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

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

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

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

Протокол передачи файлов 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-серверов.