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

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

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

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

Протокол передачи гипертекста 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 в качестве эксперимента начала процесс стандартизации данного подхода.

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

Пока наиболее практичным решением для организации репозитория PKI является каталог . Каталог X.500 с LDAP обеспечивает максимум масштабируемости и функциональной совместимости. Прозрачность местонахождения упрощает работу клиентов. В случае усложнения PKI и появления необходимости обмениваться кросс-сертификатами с другими PKI, которые поддерживают стандарт X.500, клиенты непрерывно будут иметь доступ ко всем необходимым сертификатам. Каталог X.500 поддерживает аутентифицируемый доступ, обеспечивая бизнес-модель возмещения затрат при обслуживании запросов доверяющих сторон к репозиторию . Но следует учитывать, что процесс аутентификации доступа к общедоступным данным снижает производительность системы. Небольшие изолированные PKI могут применять каталог LDAP v2. В настоящее время используются каталоги LDAP v3, предоставляющие более гибкие возможности для крупномасштабных PKI.