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

Концепция 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-совместимом каталоге;