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