Инфраструктуры открытых ключей - читать бесплатно онлайн полную версию книги автора Ольга Юрьевна Полянская (Лекция 12. Механизмы распространения информации PKI) #13

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

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

Частное распространение информации PKI

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

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

Несмотря на недостатки, частное распространение вполне подходит для небольших (и дружественных) сообществ пользователей, в которых любые два субъекта непосредственно знают друг друга или имеют узкий круг общих знакомых. Примером протокола, соответствующего этой модели, является протокол системы Pretty Good Privacy (PGP) или более поздний протокол Open PGP [40]. Использовать частное распространение в корпоративной сфере не рекомендуется по ряду причин, в частности из-за:

1 невозможности масштабирования (метод эффективно работает только в небольших сообществах пользователей);

2 ненадежности распространения информации об аннулированных сертификатах (неформальное уведомление об аннулировании в большом сообществе пользователей, скорее всего, не будет своевременно получено всеми доверяющими сторонами);

3 несоответствия модели доверия, центром которой является отдельный пользователь, модели централизованного управления действиями пользователей, характерной для большинства корпоративных доменов.

Публикация и репозитории

Публикация - это наиболее популярный метод распространения сертификатов и информации об аннулированных сертификатах в больших сообществах, где пользователи не знакомы друг с другом. Суть метода состоит в том, что информация PKI размещается в общеизвестном, открытом и легко доступном месте. Идея публикации в контексте криптографии с открытыми ключами впервые появилась в работе Диффи и Хэллмана "Новые направления в криптографии" [63]. Это была первая открытая работа по криптографии с открытыми ключами. Авторы предложили модель публикации и распространения открытых ключей, взяв за образец телефонный справочник.

Для современных PKI обычной практикой является публикация сертификатов и информации об аннулированных сертификатах в репозитории. В (лекции 3) была введена концепция репозитория. Вообще говоря, репозиторий - это общий термин, используемый для обозначения любой логически централизованной базы данных, способной хранить и распространять информацию о сертификатах по запросам [31]. В организации репозитории обычно размещаются на удаленных серверах, доступ к которым осуществляется по протоколу LDAP версий 2 и 3. Репозиторий часто базируется на информационной модели и протоколах, определенных рекомендациями X.500. Однако термин репозиторий можно применять к базе данных или любой другой форме хранения и распространения информации. Под определение репозитория попадают:

* серверы LDAP;

* агенты системы каталога X.500;

* OCSP-респондеры (серверы, обслуживающие запросы пользователей по онлайновому протоколу статуса сертификата); хотя, как установлено документом RFC 2560 [155], OCSP-респондер публикует только информацию об аннулировании;

* система доменных имен DNS (сертификаты и информация об аннулированных сертификатах поддерживаются в соответствии с документом RFC 2538 [153]);

* web-серверы (сертификаты и информация об аннулированных сертификатах поддерживаются в соответствии с документом RFC 2585 [156] и могут быть получены по протоколу передачи гипертекста HTTP);

* ftp-серверы (сертификаты и информация об аннулированных сертификатах поддерживаются в соответствии с документом RFC 2585);

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

Как следует из приведенного списка, клиентские системы могут получать информацию из этих репозиториев посредством разных протоколов доступа (хотя в корпоративных PKI доминирует протокол LDAP). В идеальном случае это позволяет практически любым конечным субъектам получать в ответ на запросы сертификаты и списки САС. В корпоративной сфере обычно поддерживается анонимный доступ к сертификатам и информации об аннулировании. Но при передаче сертификатов и списков САС в репозиторий важен контроль доступа, поскольку несанкционированный доступ может угрожать безопасности (например, один САС может быть подменен другим списком или сертификаты конечных пользователей могут быть заменены друг на друга).

Клиентское программное обеспечение может определять местонахождение репозитория несколькими способами. Например, файл конфигурации локального клиента может быть инициализирован по IP-адресу или DNS-именам основного и дополнительного LDAP-серверов. Для указания места, где размещается необходимая информация или сервис, могут также использоваться дополнения сертификатов. Частное дополнение Authority Information Access (доступ к информации об УЦ) может применяться в качестве указателя на OCSP-респондер, связанный с издателем сертификата, а частное дополнение Subject Information Access (доступ к информации о субъекте) может содержать указатель на репозиторий УЦ, являющегося субъектом. Местонахождение информации об аннулированных сертификатах также указывается в дополнении сертификата CRL Distribution Points (пункты распространения САС).

Итак, к основным характеристикам репозитория можно отнести [10]:

* прозрачность местонахождения;

* производительность и доступность;

* анонимность и возможность аутентификации доступа;

* функциональную совместимость.

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

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

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

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

Особенности использования корпоративного репозитория

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

Наконец, в силу того, что сертификаты и списки являются "самозащищенными" (то есть их целостность гарантируется цифровой подписью), сам механизм хранения ( репозиторий ) не нуждается в защите, с точки зрения целостности данных. Если же в репозитории хранится информация, которая не является "самозащищенной", то она должна быть защищена другими средствами. Например, ответы OCSP-респондера, содержащие информацию об аннулированных сертификатах, должны заверяться цифровой подписью для гарантии целостности ответов (включая целостность источника и данных). Более того, если репозиторий хранит обычные открытые ключи и/или списки САС, база данных репозитория должна быть защищена от несанкционированной модификации.

Отсутствие необходимости защищать репозиторий считается главным преимуществом при развертывании PKI. С другой стороны, развертывание онлайновых репозиториев связано с оперативным обслуживанием больших сообществ пользователей (порядка миллиона человек), поэтому количество необходимых организации репозиториев может быть значительным. Следовательно, могут возникнуть проблемы с репликацией информации через многие репозитории (например, снижение производительности, задержки распространения и проблемы синхронизации). К недостаткам можно отнести и то, что, хотя целостность PKI-информации, хранимой в репозитории, защищена, репозитории могут подвергаться атакам типа "отказ в обслуживании".

Хранимая в репозитории информация все же требует контроля доступа для предотвращения несанкционированной модификации данных, а также защиты конфиденциальности, когда это диктуется секретностью данных. Общедоступные корпоративные репозитории могут хранить и секретную информацию, особенно если она содержится в сертификатах и/или списках САС (хотя такое размещение не рекомендуется). Даже если в сертификатах не указывается ничего секретного, очевидно, что информация о внешних клиентах, инфраструктуре корпорации, именах и телефонах служащих, а также полученные на ее основании агрегированные данные носят конфиденциальный характер.

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

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

Иногда можно избежать распространения сертификатов и списков САС с конфиденциальной информацией. В относительно простой иерархии для предотвращения нежелательного раскрытия информации о корпоративной инфраструктуре может использоваться дерево информации каталога Directory Information Tree (DIT) [127], организованное на основе информационной базы объектов организации и знаний об их иерархии. В некоторых случаях также можно указывать в поле сертификата Distinguished Name ( отличительное имя ) локально уникальный идентификатор, имеющий значение в иерархии определенного УЦ, который по существу является отдельной доверяющей стороной. Тогда отличительное имя теряет смысл для стороннего наблюдателя, который может перехватить сертификат.

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

Варианты развертывания междоменного репозитория

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

Общий репозиторий

Общий репозиторий обеспечивает прием сертификатов и списков САС от доменов нескольких PKI. Хранение и управление данными в нем осуществляется таким образом, чтобы домены других PKI могли использовать эту информацию. Общий репозиторий может быть совместной собственностью двух или более доменов или функционировать под их общим управлением, а также может поддерживаться поставщиком услуг третьей стороны. Используемые доменами механизмы наполнения репозитория и поиска в нем различаются в зависимости от его структуры и частоты обновления (о чем должна быть взаимная договоренность), а также от способности общего репозитория поддерживать несколько протоколов доступа. При взаимодействии корпоративных доменов способ и частота передачи этой информации обычно являются предметом соглашений между парами доменов. Для защиты информации, хранимой в общем репозитории, должен быть организован контроль доступа, а безопасность передачи информации должны обеспечивать базовые средства поддержки конфиденциальности (например, протокол TLS).

Междоменная репликация

Междоменная репликация означает копирование сертификатов и информации об аннулированных сертификатах из одного домена в другой и наоборот. Способность автоматически выполнять междоменную репликацию зависит от используемых протоколов. Если оба домена поддерживают сервисы каталога стандарта X.500, то репликация выполняется на базе существующих протоколов, в частности, протокола для создания "теневой" копии данных каталога Directory Information Shadowing Protocol (DISP) [37]. Для случая, когда единственным общим протоколом доступа двух доменов к данным друг друга является упрощенный протокол доступа к каталогу LDAP, пока не существует стандартного протокола репликации. Рабочая группа LDUP (LDAP Duplication/ Replication/ Update Protocol) организации инженерной поддержки Интернета IETF (Internet Engineering Task Force) в настоящее время работает над этой проблемой, и можно ожидать введения нового протокола репликации на базе LDAP [44]. Другой временной альтернативой может быть передача файлов на базе формата обмена данными LDAP (LDIF - LDAP Data Interchange Format) [161]. В любом случае должен быть защищен базовый сеанс копирования данных из одного корпоративного домена в другой.

Пограничный репозиторий

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

Пограничный репозиторий может быть развернут для поддержки всей PKI или для отдельных подразделений или организаций внутри данной PKI. Иногда пограничный и внутренний репозитории связываются при помощи соответствующего механизма или протокола системы каталога X.500 Directory System Protocol (DSP). Спецификации упрощенного протокола доступа к репозиторию LDAP не поддерживают связывание явным образом.

Управление внешним доступом к пограничному репозиторию зависит от политики PKI и уровня конфиденциальности хранимой информации. В любом случае удаленные клиенты должны иметь возможность получать доступ к необходимым сертификатам и информации об аннулированных сертификатах без "блуждания" по корпоративной сети и, соответственно, без прямого доступа к конфиденциальной информации корпоративной базы данных. Рис. 12.1 иллюстрирует ряд возможных конфигураций сети, связанных с развертыванием междоменного репозитория [44].

Вариант А соответствует использованию прямого доступа внешних субъектов к корпоративному репозиторию через корпоративный межсетевой экран, защищающий внутреннюю сеть. Вариант прямого доступа позволяет клиентскому программному обеспечению конечного пользователя одного домена получать прямой доступ к репозиторию другого домена и наоборот; или позволяет внешнему репозиторию напрямую обращаться к внутрикорпоративному репозиторию. Этот вариант может использоваться тогда, когда между доменами установлены двусторонние отношения доверия и/или репозиторий защищен от несанкционированного доступа.

Рис. 12.1. Варианты развертывания междоменного репозитория

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

Помимо управления доступом может потребоваться поддержка сервиса конфиденциальности. Предотвращение несанкционированного ознакомления с информацией, передаваемой от одного корпоративного домена к другому, может быть достигнуто при помощи протоколов безопасности, таких как протокол безопасности транспортного уровня Transport Layer Security (TLS), протокол инкапсулирующей защиты содержимого IP-пакетов Encapsulating Security Payload (ESP) или посредством некоторых протоколов уровня приложений, например X.500 Directory Access Protocol (DAP).

Концепция пограничного репозитория впервые была разработана в рамках инициативы федерального мостового УЦ США (U.S. Federal Bridge CA). Там же была предложена концепция мостового репозитория, который может использоваться для взаимосвязи многих пограничных репозиториев [210]. Возможности пограничного репозитория используются в некоторых реализациях PKI, в частности, в PKI правительства Канады.

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

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