Опубликован: 15.11.2006 | Уровень: специалист | Доступ: платный | ВУЗ: Национальный исследовательский ядерный университет «МИФИ»
Лекция 12:

Механизмы распространения информации PKI

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), репозиторий может аутентифицировать и лицо, обращающееся с запросом. Аутентификация позволяет поддерживать бизнес-модель оплаты за обслуживание запросов.

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

Жанар Каппасова
Жанар Каппасова

было бы удобнее если после вопроса было написано сколько вариантов ответа требуется указать. к примеру один вариант или несколько. прошла тест оказалось что нужно несколько а я ответила по одному на каждый вопрос. как то не удобно. 

Владислав Лагвинович
Владислав Лагвинович

Прошел 5 или 6 тестов по курсу Инфраструктура открытых ключей, а сейчас курс в состоянии не готов. Что случилось?

Алексей Хохлов
Алексей Хохлов
Россия, Балашиха
Константин Нестеренко
Константин Нестеренко
Россия, Волгоград