Читать онлайн «Инфраструктуры открытых ключей». Страница 67

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

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

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

* защищенная связь;

* защищенное датирование;

* нотаризация ;

* неотказуемость;

* защищенный архив данных;

* управление полномочиями;

* приватность [44].

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

* защищенную электронную почту, использующую протоколы S/MIME v2 [169] и S/MIME v3 [158], [159];

* защищенный доступ к web-серверу на базе протокола TLS [142];

* защищенную виртуальную частную сеть, использующую протоколы IPSec [143] и IKE [147].

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

Защищенное датирование, или проставление меток времени , заключается в связывании доверенным центром датирования метки времени с определенной "порцией" данных при сохранении их аутентичности и целостности. Причем, важным является не столько само значение времени, сколько защищенность связывания данных с определенным временем (датой). В частности, в некоторых приложениях бывает важно зафиксировать не время совершения события, а последовательность событий, например, поступление в доверенный центр данного документа Y перед документом Z, но после документа X.

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