Книга: Инфраструктуры открытых ключей

Инициативы по обеспечению функциональной совместимости PKI-продуктов

К числу наиболее известных национальных инициатив по обеспечению функциональной совместимости можно отнести инициативы США: Automotive Network eXchange, Bridge CA Demonstration, проект федеральной PKI, инициативу разработки спецификации минимальной функциональной совместимости MISPC, а также проект национальной ассоциации автоматизированных клиринговых палат США >[44].

Automotive Network eXchange

В рамках инициативы Automotive Network eXchange (ANX) на основе технологии виртуальных частных сетей была спроектирована общая сеть компаний-производителей автомобилей для обеспечения защищенных коммуникаций между ними. В ходе реализации проекта был разработаны профили сертификатов и списков САС, которые включены как приложение в документ, названный политикой применения сертификатов ANX >[94].

Bridge CA Demonstration

По инициативе правительства США в 1999-2001 гг. был реализован проект демонстрации мостового УЦ - Bridge CA Demonstration с целью показать возможности функциональной совместимости двух (или более) доменов PKI, основанных на разных моделях доверия. В ходе выполнения проекта была сделана попытка доказать, что один УЦ способен действовать как мост между несколькими доменами PKI. Деятельность по разработке профилей включала создание минимального профиля сертификата и САС, схемы каталога и профиля функциональной совместимости, были также утверждены процессы построения и валидации путей сертификации >[210].

Федеральная PKI

В октябре 1994 г. федеральное правительство США создало техническую рабочую группу по PKI (PKI-TWG) для решения проблем реализации федеральной инфраструктуры открытых ключей (FPKI). Рабочая группа действовала под руководством национального института по стандартам и технологии США - National Institute of Standards and Technology (NIST) и состояла из представителей федеральных агентств. Она разработала профиль дополнений сертификата и САС федеральной инфраструктуры, названный Federal Public Key Infrastructure Certificate and CRL Extensions Profile >[206].

Спецификация минимальной функциональной совместимости

В 1996 г. институт NIST совместно с рядом поставщиков продуктов, лидирующих на рынке PKI - AT&T, IREBBN, Motorola Certicom, Nortel (Entrust), Cylink, Spyrus, DynCorp и VeriSign, - выступил с инициативой разработки спецификации минимальной функциональной совместимости. Первая версия спецификации "Minimum Interoperability Specification for PKI components, Version 1" была опубликована в июне 1997 г. >[51] и содержала ссылку на реализацию, пригодную для тестирования соответствия компонентов PKI профилю минимальной функциональной совместимости. Этот документ позволил сообществу поставщиков демонстрировать соответствие их PKI-продуктов требованиям профиля.

Работа над спецификацией продолжалась, и в августе 2001 г. была опубликована вторая версия документа, названная "Minimum Interoperability Specification for PKI components, Version 2 - Second Draft" >[92]. Она объединяет некоторые работы группы IETF PKIX, опубликованные в 1998-2001 гг. (в частности, RFC 2459, RFC 2510 и RFC 2511), и дополняет первую версию положениями о поддержке сервисов конфиденциальности.

Проект национальной ассоциации автоматизированных клиринговых палат

Национальная ассоциация автоматизированных клиринговых палат США (National Automated Clearing House Association - NACHA) финансировала успешный проект функциональной совместимости удостоверяющих центров CA Interoperability Pilot, завершенный в октябре 1998 г. Участниками проекта были такие известные компании, как CertCo, Digital Signature Trust (DST), Entrust, GTE CyberTrust, IBM и VeriSign. В качестве базовой модели PKI в пилотном проекте была выбрана четырехсторонняя модель (см. лекцию 5), имитирующая приобретение товаров и услуг через Интернет. Посредниками сделок между покупателем и продавцом выступали банки каждой из сторон, которые действовали как самостоятельные удостоверяющие центры. Все решения относительно финансовых транзакций должны были инициироваться банками.

С технологической точки зрения, главной целью проекта была демонстрация пригодности PKI-продуктов многих поставщиков для реализации предложенной модели, поэтому банки-участники проекта использовали разные программные продукты для поддержки УЦ, предоставленные поставщиками технологии. В дальнейшем поставщики - участники проекта совместно работали над созданием профилей сертификата и САС, и тестирование функциональной совместимости выполнялось для этих профилей. Результаты этой работы были опубликованы в документе "Функциональная совместимость удостоверяющих центров: от концепции к реальности" >[90].

Апробация концепции SIRCA

Апробация концепции головного УЦ отрасли средств безопасности Securities Industry Root CA (SIRCA) >[110] выполнялась Ассоциацией отрасли средств безопасности США Securities Industry Association вместе с компаниями Digital Signature Trust (DST) и ABAecom. УЦ отрасли действовал как головной центр в двухуровневой иерархии и служил источником доверия для доверяющих сторон - фирм, занимающихся бизнесом в сфере средств безопасности. Каждая из двадцати фирм - участников проекта организовала свой УЦ, связанный с головным УЦ отрасли, а затем выпускала и подписывала цифровые сертификаты для своих служащих, для того чтобы они могли защищенно обмениваться сообщениями электронной почты с партнерами по бизнесу из других фирм.

Концепция SIRCA, аналогичная концепции мостового УЦ, по-своему реализовала установление отношений доверия между многими доменами PKI, которое, в противном случае, потребовало бы заключения двусторонних соглашений о кросс-сертификации каждого домена с каждым. В ходе апробации использовался относительно простой профиль сертификатов: приложение защищенной электронной почты S/MIME v2 профилировалось в том смысле, что выполнялось требование, чтобы в каждое заверенное цифровой подписью сообщение включался полный список сертификатов, необходимых для проверки пути сертификации.

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

Международные инициативы

PKI X.509

Как уже отмечалось выше, ведущим центром по выпуску согласованных стандартов в области PKI является рабочая группа PKIX организации IETF. Профиль сертификата и САС, который был описан в документе RFC 2459, известном как первая часть PKIX, стал предложенным стандартом в январе 1999 года, а затем дополнен и заменен в апреле 2002 года документом RFC 3280. RFC 3280 ввел в формат сертификата и САС дополнения, которые содержат информацию, позволяющую клиентскому программному обеспечению определять местонахождение УЦ и репозитория. Многие специалисты в области PKI признают разработку стандарта RFC 2459 поворотным моментом в развитии инфраструктур открытых ключей, способствовавшим созданию функционально совместимых PKI-продуктов (более подробная информация о документах группы PKIX приведена в разделе "Стандарты Internet X.509 PKI").

Проект EEMA PKI Challenge

Европейский Форум по электронному бизнесу (European Forum for Electronic Business - EEMA) с начала января 2001 года выполнял двухлетний проект PKI Challenge (pkiC), который финансировали Европейский Союз и правительство Швеции >[211]. К участию в проекте помимо 13 организаций, входящих в состав Форума, были привлечены поставщики PKI-продуктов, пользователи, консультанты, академические институты, поставщики услуг по выпуску и поддержке цифровых сертификатов для выработки решений по обеспечению функциональной совместимости PKI-продуктов. Рекомендации, выработанные в результате реализации проекта, приведены в табл. 15.8.

|Компонент PKI | Рекомендация |

|УЦ | УЦ должен публиковать списки аннулированных сертификатов (САС) в соответствии со стандартом X.509 v2.

В сертификатах должно присутствовать дополнение CRL Distribution Points, где перечислены пункты распространения САС.

Все действия, выполняемые УЦ, должны регистрироваться в контрольных журналах.

Для автоматической регистрации конечных пользователей должен поддерживаться, по крайней мере, протокол Simple CMP

|

|Репозиторий | Предпочтительно использование репозитория типа X.500, доступ к которому осуществляется по протоколу LDAP.

Поставщикам следует ориентироваться на поддержку LDAP v3.

Необходимо поддерживать следующий минимальный набор компонентов отличительного имени Distinguished Name (DN):

* C (страна);

* L (местонахождение);

* O (организация);

* OU (подразделение организации);

* CN (общее имя);

* DC (компонент домена).

Поставщикам следует реализовать и протестировать дополнения, введенные стандартом RFC 3280, которые содержат информацию о местонахождении удостоверяющих центров Authority Information Access и репозиториев Subject Information Access

|

|OCSP-респондер | Ответ OCSP-респондера может быть подписан одним из следующих ключей:

1 ключом, которым подписан проверяемый сертификат, то есть ключом того УЦ, который выпустил сертификат, подлежащий валидации;

2 ключом, выпущенным для OCSP-респондера вместе с соответствующим сертификатом открытого ключа, который имеет в поле дополнения Extended Key Usage параметр OCSP-Signing. Этот сертификат должен быть выпущен тем же УЦ, который издал сертификат, подлежащий валидации;

3 ключом, который является действующим внутри локальной конфигурации центра подписания OCSP-ответа для сертификата, подлежащего валидации.

Те поставщики, которые пока не реализовали поддержку OCSP-ответа, должны ориентироваться на второй вариант

|

|Клиентское ПО | Клиентское ПО конечного субъекта должно иметь возможность:

* генерировать пару ключей для регистрации;

* управлять содержимым локального репозитория, предназначенного для хранения копий сертификатов корневого УЦ, списков САС и сертификатов корреспондентов;

* локально управлять идентификационными данными субъекта, а также предлагать средства дистанционного управления ими через УЦ

|

|PKI-совместимые приложения | Приложения, использующие PKI, должны:

* работать с файловыми форматами PKCS#10, PKCS#7 и PKCS#11, а также поддерживать либо протокол PKIX-CMP, либо CMC;

* иметь возможность выполнять поиск в каталоге LDAP или любом LDAP-совместимом каталоге;

* понимать дополнения сертификатов, связывающих сертификат с той PKI, которая его поддерживает (т.е. crl Distribution Point, authority Information Access, Subject Information Access)

|

Таблица 15.8.Рекомендации проекта pkiC Европейского Форума по электронному бизнесу

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

|Стандарты PKIX |

RFC 2459/RFC 3280: Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile
RFC 2510: Internet X.509 Public Key Infrastructure
Certificate Management Protocols
RFC 2511: Internet X.509 Certificate Request Message
Format
RFC 2511 bis Internet X.509 Certificate Request
Message Format
RFC 2797: Certificate Management Messages over
CMS
RFC 2559: Internet X.509 Public Key Infrastructure
Operational Protocols - LDAP v2
RFC 2587: Internet X.509 Public Key Infrastructure
LDAP v2 Schema
RFC 3279: Algorithms and Identifiers for the Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile

|

|Стандарты PKCS |

PKCS#1: RSA Cryptography Standard
PKCS#7: Cryptographic Message Syntax Standard
PKCS#10: Certification Request Syntax Standard
PKCS#11: Cryptographic Token Interface Standard
PKCS#12: Personal Information Exchange Syntax
Standard
PKCS#15: Cryptographic Token Information Format
Standard

|

|Дополнительные стандарты |

RFC 1777: Lightweight Directory Access Protocol
RFC 1823: The LDAP Application Program Interface
RFC 2251: Lightweight Directory Access Protocol (v3)
RFC 2252: Lightweight Directory Access Protocol
(v3): Attribute definition
RFC 2253: Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names
RFC 2254: Lightweight Directory Access Protocol (v3)
The String Representation of LDAP Search Filters
RFC 2255: Lightweight Directory Access Protocol (v3)
The LDAP URL Format
RFC 3369: S/MIME Cryptographic Message Syntax

|

|Проекты стандартов |

Draft RFC2510 bis: Internet X.509 Public Key
Infrastructure Certificate Management Protocols
Draft: Internet X.509 Public Key Infrastructure LDAP
v2 Schema for X.509 CRLs
Draft: Internet X.509 Public Key Infrastructure LDAP
v2 Schema for X.509 Attribute Certificates
Draft: LDAP v3 DN strings for use with PKIs

|

Таблица 15.9.Рекомендуемый список поддерживаемых стандартов

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

Оглавление книги