Инфраструктуры открытых ключей - Ольга Полянская

Стандарт RFC 3039 Qualified Certificates Profile описывает формат сертификата ограниченного использования. Владельцем этого сертификата может быть только физическое лицо. Термин "ограниченное использование" трактуется в общепринятом для государственного права смысле. Пока стандарт определяет основной синтаксис сертификата ограниченного использования без учета особенностей законодательства разных стран.

Стандарт RFC 3279 Algorithms and Identifiers for the Internet X.509 Public Key In-frastructure Certificate and Certificate Revocation List (CRL) Profile определяет идентификаторы алгоритмов и форматы шифрования используемых в PKIX открытых ключей и цифровых подписей, односторонние хэш-функции для генерации ЭЦП сертификатов и САС. Стандарт описывает шифрование цифровых подписей, сгенерированных при помощи криптографических алгоритмов RSA, DSA и алгоритма эллиптических кривых (ECDSA), задает форматы шифрования открытых ключей, используемых в криптографических алгоритмах RSA, DSA, Диффи-Хеллмана и алгоритма шифрования ключей (KEA).

Второе направление представлено документами RFC 2510 [150], RFC 2511 [151], RFC 2560 [155] и RFC 2797 [160]. Стандарты RFC 2510 Certificate Management Protocols (CMP) и RFC2511 Certificate Request Protocol определяют соответственно сообщения протоколов для процессов создания и управления сертификатами и синтаксис запроса на выпуск сертификата формата X.509.

Стандарт RFC 2560 Online Certificate Status Protocol (OCSP) предлагает онлайновый протокол для определения статуса сертификата без использования САС. По замыслу разработчиков, этот протокол должен удовлетворять операционным требованиям более своевременного поступления информации об аннулировании, чем это возможно при помощи САС. Протокол управляет обменом данными между OCSP-клиентами, проверяющими статус сертификата, и OCSP-исполнителем, информирующим об этом статусе.

Стандарт RFC 2797 Certificate Management Messages over CMS определяет протокол управления сертификатами на основе сообщений управления сертификатами. Документ разрабатывался для решения двух важных проблем сообщества PKI в Интернете:

1 реализации интерфейса с продуктами и сервисами PKI, базирующимися на сообщениях управления сертификатами и стандарте синтаксиса запроса на сертификат - PKCS#10;

2 использования стандарта SMIME v3 в протоколе регистрации сертификатов открытых ключей (Диффи-Хеллмана), подписанных при помощи алгоритма DSA.

К третьему направлению можно отнести документы RFC 2559 [154], RFC 2587 [157] и RFC 2585 [156].

Стандарт RFC 2559 LDAP V2 Operational Protocols закрепляет использование протокола LDAP v2 для обеспечения доступа к репозиторию с целью поиска сертификатов и другой релевантной PKI информации и управления ими.

Стандарт RFC 2587 LDAP V2 Schema описывает минимально необходимую схему поддержки PKIX в среде LDAP v2 (как этого требует документ RFC 2559) и определяет только специфические PKIX-компоненты. В соответствии с этим документом серверы LDAP, действующие как хранилища (репозитории) PKIX, должны поддерживать вспомогательные классы объектов, определенные данным стандартом, и интегрировать эту схему с общими и специфическими для приложений схемами в зависимости от сервисов, предоставляемых сервером.

Документ RFC 2585 HTTP/FTP Operations описывает применение протоколов HTTP/FTP для получения сертификатов и списков аннулированных сертификатов из репозитория УЦ.

Четвертое направление представлено одним базовым стандартом RFC 2527 Certificate Policy and Certification Practices Framework [152], определяющим политику применения сертификатов и структуру регламента УЦ и подробно описанным в лекции 14.

К пятому направлению стандартизации относятся документы RFC 3029 [163], RFC 2875 [162], RFC 3161 [165]. Стандарт RFC 3029 Data Validation and Certification Server Protocols вводит понятие сервера сертификации и проверки достоверности данных для обеспечения надежности сервисов неотказуемости и предлагает протоколы для взаимодействия с этим сервером. На сервер возлагаются функции доверенной третьей стороны, проверяющей подлинность сертификатов открытых ключей и документов с цифровой подписью.

Стандарт RFC 2875 Diffie-Hellman Proof-of-Possession (POP) Algorithms описывает два метода получения значения проверки целостности на основе пары ключей Диффи-Хэллмана. В документе предлагаются два алгоритма доказывания владения, использующие процесс согласования ключей Диффи-Хеллмана для получения разделенного секрета на основе значения проверки целостности. В первом алгоритме значение формируется для конкретного получателя/верификатора при помощи открытого ключа этого верификатора. Во втором алгоритме значение формируется для произвольного верификатора. Документ RFC 3161 Time-Stamp Protocol (TSP) описывает протокол проставления метки времени.

Роль стандартов, профилей и тестирования функциональной совместимости

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

В мире существует большое количество организаций, занимающихся разработкой стандартов в сфере информационных технологий, появляются все новые и новые стандарты. Цель любого стандарта - обеспечить общее описание (спецификацию) его синтаксиса и семантики, которые могут быть использованы как основа для реализации стандарта. Однако иногда некоторые семантические правила отсутствуют или не полностью определены, что приводит к неоднозначному толкованию стандартов и проблемам функциональной совместимости продуктов, разработанных на базе таких стандартов. На качество стандартов влияют не только детальность их проработки и отсутствие ошибок, но и ряд других обстоятельств:

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

2 часто в стандартах делается попытка объединить несколько точек зрения разных специалистов, и компромисс достигается либо за счет спецификации опций, либо за счет рассмотрения ряда вопросов на обобщенном уровне;

3 иногда существует очень небольшой или противоречивый опыт реализации в сфере приложения стандарта, поэтому он не может быть должным образом учтен в стандарте;

4 не все подразделения органов стандартизации способны разрабатывать документы равного качества, важную роль играет состав и правила участия специалистов, утвержденные главным государственным органом стандартизации;

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

6 иногда некоторые положения стандартов неправильно интерпретируются и/или даже стандарт неправильно реализуется;

7 наиболее сложные проблемы совместимости порождает общепринятая практика включения в стандарты механизмов расширения их возможностей, с тем чтобы стандарты сохраняли адекватность при изменении обстоятельств и возникновении новых потребностей реальной жизни.

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

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

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