Следует отметить, что в настоящее время специалистами изучаются и предлагаются и другие методы создания отношений доверия между PKI-доменами:
* взаимное распознавание;
* использование списков доверия к сертификатам;
* применение сертификатов аккредитации.
Концепция взаимного распознавания (кросс-распознавания) предложена рабочей группой по телекоммуникациям организации экономического сотрудничества стран Азиатско-Тихоокеанского региона и заключается в том, что удостоверяющие центры могут распознавать друг друга среди многих PKI-доменов, будучи аккредитованными общим аккредитационным центром или доверенной третьей стороной.
Список доверия к сертификатам (Certificate Trust List - CTL), по определению специалистов корпорации Microsoft, является заверенным цифровой подписью списком сертификатов головных удостоверяющих центров, который признается администратором корпоративной сети пригодным для выполнения аутентификации клиентов и защиты электронной почты.
Концепция сертификата аккредитации впервые появилась в проекте PKI правительства Австралии (Gatekeeper) и заключается в том, что хорошо известные и надежные удостоверяющие центры при определенных условиях ручаются за другие удостоверяющие центры [44]. Использование сертификатов аккредитации можно сравнить с односторонней кросс-сертификацией в том смысле, что аккредитационный УЦ выпускает сертификаты для всех удостоверяющих центров, которые удовлетворяют требованиям аккредитации. При этом иерархия не поддерживается, и аккредитованные удостоверяющие центры могут быть полностью автономными субъектами. Сертификаты аккредитации можно использовать для реализации идеи взаимного распознавания.
Сетевая конфигурация
В сетевой конфигурации все головные удостоверяющие центры потенциально кросс-сертифицированы друг с другом. Два головных удостоверяющих центра устанавливают отношения кросс-сертификации, если их сообществам необходимо иметь защищенные коммуникации друг с другом. В полностью связанном случае, иногда называемом полной сетью, это требует установления (n2 - n) - кросс-сертифицированных соглашений при наличии n -головных удостоверяющих центров, хотя на практике чаще встречаются неполные сети. Рис. 5.2 иллюстрирует неполную сетевую гибридную архитектуру распределенного доверия. Она не является полной сетью, потому что между первым и третьим удостоверяющими центрами отсутствует прямое соглашение о кросс-сертификации.
Мостовая конфигурация (конфигурация hub-and-spoke)
В мостовой конфигурации каждый головной УЦ устанавливает отношения кросс-сертификации с единственным центральным УЦ, в чьи функции входит обеспечение таких взаимных связей [101]. Центральный УЦ иногда называют "втулкой" (hub), соединенной "спицами" (spoke) с различными головными удостоверяющими центрами, а иногда называют мостовым УЦ, устанавливающим связи между парами головных удостоверяющих центров. Преимущество этой конфигурации заключается в том, что в случае полной связи требуется заключение только n -соглашений о кросс-сертификации для n -головных удостоверяющих центров, потому что каждый головной УЦ кросс-сертифицируется только с центральным УЦ.
Мостовая конфигурация не создает иерархии, мостовой УЦ следует рассматривать как головной для всех систем, которые кросс-сертифицируются с ним. Фундаментальное различие между строгой иерархией и мостовой конфигурацией состоит в том, какими ключами владеют конечные субъекты. В строгой иерархии все субъекты владеют доверенной копией открытого ключа головного УЦ, обеспечивающего базу для валидации пути сертификации. В мостовой конфигурации конечные субъекты не владеют открытым ключом мостового УЦ, а имеют лишь копию открытого ключа головного УЦ в своем собственном домене. Каждый субъект, строя путь сертификации, при помощи этого ключа получает ключ мостового УЦ, затем ключ головного УЦ другого домена и, в конце концов, ключ конечного субъекта другого домена.
Четырехсторонняя модель доверия
Обоснованность четырехсторонней модели доверия была протестирована в пилотном проекте обеспечения функциональной совместимости удостоверяющих центров Национальной Ассоциации клиринговых палат (США) [90]. Четырехсторонняя модель доверия представлена на рис. 5.3. В качестве четырех сторон в модели выступают подписчик, доверяющая сторона и удостоверяющие центры подписчика и доверяющей стороны.
На первый взгляд может показаться, что эта модель не отличается от более традиционной web-модели, включающей подписчика, доверяющую сторону и УЦ подписчика. Однако главное отличие четырехсторонней модели заключается в том, что доверяющая сторона при принятии решения относительно конкретной транзакции всегда зависит от своего выпускающего УЦ.
Рис. 5.3. Четырехсторонняя модель доверия
Пример 5.2. Рассмотрим приобретение товара покупателем через коммерческий web-сайт. Как только покупатель принимает решение о покупке, то заполняет онлайновый запрос, подписывает его цифровой подписью и отправляет на web-сайт продавца. Оттуда запрос пересылается в банк продавца для одобрения. Любая проверка юридической значимости и статуса сертификата, одобрение кредита и т.п. должны выполняться банком, а не самим продавцом. Таким образом, все транзакции отслеживаются не доверяющей стороной (продавцом), а выпускающим УЦ (банком). Эта модель применима и к другим видам электронных транзакций.
Web-модель
Web-модель получила свое название, поскольку базируется на популярных браузерах Netscape Navigator и Microsoft Internet Explorer, используемых как средства навигации во Всемирной Паутине - World Wide Web. Эта модель предусматривает встраивание в готовый браузер набора открытых ключей головных удостоверяющих центров, которым пользователь браузера может изначально "доверять" при проверке сертификатов. Хотя браузер позволяет корректировать набор корневых ключей (удалять одни ключи и добавлять другие), очевидно, что лишь немногие пользователи имеют достаточное представление о PKI и проблемах безопасности, чтобы управлять этим режимом работы браузера.
На первый взгляд эта модель аналогична модели распределенного доверия, но по существу более похожа на модель строгой иерархии. Web-модель немедленно делает пользователя браузера доверяющей стороной всех PKI-доменов, представленных в браузере. Для всех практических нужд каждый производитель браузера имеет свой собственный головной УЦ, сертифицирующий "головные" удостоверяющие центры, открытые ключи которых физически встроены в программное обеспечение браузера. По существу это строгая иерархия с подразумеваемым корнем, то есть производитель браузера является виртуальным головным УЦ, а уровень, находящийся ниже, образуют встроенные в браузер открытые ключи удостоверяющих центров [44].
Web-модель обладает явными преимуществами: удобством использования и простотой обеспечения функциональной совместимости. Однако при принятии решения о развертывании PKI в каждом конкретном случае следует учитывать проблемы безопасности. Пользователи браузера автоматически доверяют всем удостоверяющим центрам, открытые ключи которых были заранее встроены в браузер, поэтому безопасность может быть полностью скомпрометирована, если хотя бы один из этих центров окажется "плохим". Например, пользователь А будет доверять сертификату пользователя В, даже если он содержит имя пользователя В, но открытый ключ пользователя C, и подписан "плохим" УЦ, открытый ключ которого был встроен в браузер. В этом случае пользователь А может непреднамеренно разгласить конфиденциальную информацию пользователю C или принять документ с его фальшивой подписью. Причина нарушения безопасности заключается в том, что у пользователя обычно нет уверенности, какой именно корневой ключ из большого числа ключей, встроенных в браузер, участвует в проверке сертификата. Некоторые версии наиболее популярных браузеров поддерживают порядка 100 корневых сертификатов, поэтому пользователю может быть известна лишь небольшая группа из представленных удостоверяющих центров. Кроме того, в этой модели клиентское программное обеспечение доверяет всем удостоверяющим центрам, открытые ключи которых встроены в браузер, в равной степени; таким образом, сертификат, заверенный одним из них, будет, безусловно, принят.
Отметим, что похожая ситуация может возникнуть и в некоторых других моделях доверия. Например, в модели распределенного доверия пользователь может не знать некоторый УЦ, но клиентское программное обеспечение пользователя будет доверять ключам этого центра, если соответствующий кросс-сертификат является валидным. В модели распределенного доверия пользователь соглашается доверить своему локальному УЦ осуществление всех необходимых мер PKI-безопасности, в том числе, кросс-сертификации с "подходящими" удостоверяющими центрами. В web-модели пользователь может приобрести браузер по ряду причин, не имеющих ничего общего с безопасностью, поэтому не следует рассчитывать, что браузер будет иметь ключи "подходящих" в смысле безопасности удостоверяющих центров.
