Ольга Полянская - Инфраструктуры открытых ключей
В сертификатах должно присутствовать дополнение 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 связано не только с техническими, но и с правовыми и человеческими аспектами, от которых также может зависеть совместимость инфраструктур открытых ключей.
Лекция 16. Сервисы, базирующиеся на PKI
Рассматриваются дополнительные сервисы 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.
Доверенный центр датирования не является строго необходимым компонентом этого сервиса. Любой субъект может поддерживать надежное время в своей локальной среде и в случае необходимости связывать метки времени со своими собственными данными. На практике, однако, трудно поддерживать надежное время для локальных сред (например, настольных систем) многих пользователей, поэтому прибегают к помощи доверенных центров датирования, которые обрабатывают запросы субъектов на проставление меток времени.
