Стандарты и спецификации PKI

PKCS#1
RSA Cryptography

PKCS #3
Diffie-Hellman Key Agreement

PKCS #5
Password-Based Cryptography

PKCS #6
Extended-Certificate Syntax

PKCS#7
Cryptographic Message Syntax

PKCS #8
Private-Key Information Syntax

PKCS #9
Selected Attribute Types

PKCS#10 (RFC2314)
Certification Request Syntax

PKCS#11
Cryptographic Token Interface (Cryptoki)

PKCS #12
Personal Information Exchange Syntax

PKCS #13
Elliptic Curve Cryptography

PKCS #15
Cryptographic Token Information Format

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

В четвертую группу объединены дополнительные связанные с PKI стандарты LDAP, S/MIME, S/HTTP, TLS, IPsec, DNS и SET (см. табл. 15.4). Стандарты LDAP описывают упрощенный протокол доступа, позволяющий вводить, удалять, изменять и извлекать информацию, которая содержится в каталогах X.500. В настоящее время LDAP является стандартным методом доступа к информации сетевых каталогов и играет важную роль во множестве продуктов, таких как системы аутентификации, PKI, приложения электронной почты и электронной коммерции.

Стандарты S/MIME (Secure/Multipurpose Internet Mail Extensions) предназначены для обеспечения защищенного обмена сообщениями в Интернете. Протокол защищенной электронной почты S/MIME базируется на технологии шифрования и цифровой подписи, разработанной компанией RSA Security Inc., и используется для предупреждения возможного перехвата или подделки почтовых сообщений [209]. Семейство стандартов S/MIME описывает синтаксис криптографических сообщений, управление сертификатами в среде S/MIME, процедуры и атрибуты дополнительных сервисов безопасности для почтовых приложений, к которым относятся заверенные цифровой подписью уведомления о приеме сообщений, метки безопасности и защищенные списки рассылки электронной почты.

К стандартам S/HTTP и TLS относятся документы, определяющие защищенный протокол передачи гипертекста HTTP и его расширения, протокол безопасности транспортного уровня TLS, его модификацию и использование в среде HTTP. TLS - открытый стандарт, разработанный на базе протокола защищенного обмена информацией между клиентом и сервером SSL (Secure Sockets Layer) в качестве его замены для защиты коммуникаций в Интернете. Протокол TLS обеспечивает конфиденциальность и целостность данных при коммуникации двух приложений и позволяет приложениям "клиент-сервер" взаимодействовать защищенным способом, предотвращающим перехват информации и подделку сообщений. Для взаимной аутентификации перед началом информационного взаимодействия приложениями используется технология PKI.

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
LDAP
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 2311 
S/MIME Version 2 Message Specification

RFC 2312 
S/MIMEv2 Certificate Handling

RFC 2630 
Cryptographic Message Syntax (CMS)

RFC 2632 
S/MIME V3 Certificate Handling

RFC 2633 
S/MIME V3 Message Specification

S/MIMERFC 2634 
Enhanced Security Services for S/MIME

RFC 2785 
Methods for Avoiding the "Small-
Subgroup" Attacks on the Diffie-Hellman
Key Agreement Method for S/MIME

RFC 3369 S/MIME Cryptographic Message
Syntax

RFC 2246 
TLS Protocol Version 1.0

RFC 2659 
Security Extensions For HTML

RFC 2660 
S/HTTP TLS
The Secure HyperText Transfer Protocol

RFC 2817 
Upgrading to TLS Within HTTP

RFC 2818 
HTTP Over TLS

RFC 2401 
Security Architecture for the Internet
Protocol

RFC 2402 
IP Authentication Header

IPsecRFC 2406
IP Encapsulating Security Payload (ESP)

RFC 2408
Internet Security Association and Key
Management Protocol (ISAKMP)

RFC 2137
Secure Domain Name System Dynamic Update

RFC 2535
Domain Name System Security Extensions

RFC 2536 
DSA KEYs and SIGs in the Domain Name
System

RFC 2537 
RSA/MD5 KEYs and SIGs in the Domain
Name System

DNSRFC 2538
Storing Certificates in the Domain
Name System

RFC 2539
Storage of Diffie-Hellman Keys in the
Domain Name System

RFC 2540
Detached Domain Name System Information

RFC 2541
DNS Security Operational Considerations

Secure Electronic Transaction 
Specification The Business Description

Secure Electronic Transaction 
The Specification Programmer's Guide
SET

Secure Electronic Transaction 
Specification Formal Protocol Definition

Стандарты семейства IPsec описывают архитектуру безопасности Интернет-протоколов (IP), регламентируют контроль целостности на уровне IP-пакетов, аутентификацию источника данных и защиту от воспроизведения ранее посланных IP-пакетов, обеспечение конфиденциальности при помощи шифрования содержимого IP-пакетов, а также частичную защиту от анализа трафика путем применения туннельного режима [216]. Документы RFC, относящиеся к IPsec, содержат описания протокола аутентифицирующего заголовка, протокола инкапсулирующей защиты содержимого IP-пакетов и протокола управления ключами и контекстами безопасности. Стандарты IPsec обеспечивают конфиденциальность, целостность и достоверность данных, передаваемых через открытые IP-сети.

Стандарты DNS определяют механизмы, обеспечивающие безопасность данных инфраструктуры системы доменных имен DNS. Документы описывают операционные требования безопасности системы, методы хранения сертификатов и ключей Диффи-Хэллмана, динамическое обновление защищенной системы DNS, механизм защиты передаваемых данных с помощью алгоритма MD5, DSA и RSA-ключей и цифровых подписей. Для обеспечения достоверной передачи DNS-данных в масштабе Интернета в систему DNS вводятся расширения DNSSEC, задаваемые соответствующим стандартом.

Спецификация SET предлагает инфраструктуру для защиты от подделок платежных карт, используемых для транзакций электронной коммерции в Интернете, описывает систему аутентификации участников расчетов, которая базируется на PKI [2]. Принципы SET излагаются в трех книгах, содержащих сведения о правилах ведения бизнеса на базе защищенных электронных транзакций, руководство программиста и формальное описание протокола SET. Рис. 15.1 иллюстрирует взаимосвязь стандартов в области PKI [10].

Итак, базой для разработки стандартов в области PKI стали стандарты серии X.500 (хотя не все их наименования начинаются с X.5xx) Международного союза электросвязи (ITU), предложившие стандартную структуру баз данных, записи в которых содержали информацию о пользователях [3]. Стандарт X.509 ITU-T является фундаментальным стандартом, который лежит в основе всех остальных, используемых в PKI. Однако X.509 ITU-T не описывает полностью технологию PKI. В целях применения стандартов X.509 в повседневной практике комитеты по стандартизации, пользователи, поставщики программных продуктов и сервисов PKI обращаются к семейству стандартов PKIX.

Стандарты Internet X.509 PKI (PKIX)

Терминология и концепции PKIX

Стандарты PKIX для описания инфраструктур используют сходные понятия " инфраструктура открытых ключей PKI " и " инфраструктура управления привилегиями PMI " (Privilege Management Infrastructure). Главное отличие между ними заключается в том, что PKI управляет сертификатами открытых ключей, а PMI - атрибутными сертификатами. Сертификат открытого ключа можно сравнить с паспортом субъекта, а атрибутный сертификат - с визой, первый обеспечивает идентификацию личности, а второй дает определенное разрешение. Основные термины и аббревиатуры, используемые в стандартах PKIX, а также их аналоги на русском языке приведены в табл. 15.5.

Системы, использующие сертификаты, и PKI

Результатом усилий технических специалистов по повышению безопасности Интернета стала разработка группы протоколов безопасности, таких как S/MIME, TLS и IPsec. Все эти протоколы используют криптографию с открытыми ключами для обеспечения сервисов конфиденциальности, целостности данных, аутентификации источника данных и неотказуемости.

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

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

Сертификаты открытых ключей используются в процессе валидации (подтверждения) заверенных цифровой подписью данных, когда получатель проверяет, чтобы:

После валидации получатель может принять данные, подписанные отправителем.

Общая схема функционирования PKI представлена на рис. 15.2. Конечный субъект отправляет запрос на сертификат в РЦ (транзакция управления). Если запрос фактически одобрен, то направляется непосредственно в УЦ для заверения цифровой подписью. УЦ проверяет запрос на сертификат, и если тот проходит верификацию, то подписывается и выпускается сертификат. Сертификат публикуется в репозитории; в зависимости от конкретной конфигурации PKI, эта функция может быть возложена на регистрационный или удостоверяющий центр.

На рис. 15.2 показаны все возможные коммуникации между конечным субъектом и УЦ. Процесс аннулирования сертификата аналогичен процессу его генерации. Конечный субъект запрашивает УЦ об аннулировании своего сертификата, РЦ принимает решение и направляет запрос об аннулировании в УЦ. УЦ вносит изменения в список аннулированных сертификатов и публикует его в репозитории. Конечные субъекты могут проверить статус конкретного сертификата через операционный протокол.

Операционные протоколы - это протоколы для доставки сертификатов (или информации об их статусе) и списков аннулированных сертификатов к клиентским системам, использующим сертификаты. Существуют разнообразные механизмы распространения сертификатов и САС с использованием протоколов LDAP, HTTP и FTP. Например, поиск САС для проверки статуса сертификата осуществляет операционный протокол.

Протоколы управления необходимы для поддержки взаимодействий в онлайновом режиме между пользователем PKI и субъектами управления.

Протоколы управления поддерживают:

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

Системы, использующие сертификаты, и PMI

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

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

Формат атрибутного сертификата позволяет связать любую дополнительную информацию о владельце с сертификатом открытого ключа, включая в структуру данных, заверенных цифровой подписью, ссылку на один или несколько сертификатов открытых ключей одного и того же субъекта. Атрибутный сертификат может иметь несколько назначений (например, предназначаться для доступа к web-серверу и хосту электронной почты).

Согласно стандартам PKIX, PMI представляет собой комплекс программного и аппаратного обеспечения, кадров, а также политик и процедур, необходимых для создания, управления, хранения и аннулирования атрибутных сертификатов. Компоненты PMI представлены в табл. 15.7.

Направления стандартизации

Группа PKIX IETF разрабатывает документы для следующих направлений стандартизации:

К первому направлению относятся стандарты RFC 3280 [167], RFC 3281 [168], RFC 3039 [164] и RFC 3279 [166]. Стандарт RFC 3280 (бывший RFC 2459) Certificate CRL Profile предлагает форматы сертификатов версии X.509 v3 и списка аннулированных сертификатов версии X.509 v2 для использования в Интернете, детализирует информацию, относящуюся к формам имен и стандартным дополнениям. Документ описывает алгоритм проверки цепочек сертификатов и форматы открытых ключей и электронной цифровой подписи для алгоритмов шифрования ключей RSA, DSA и Диффи-Хэллмана.

Стандарт RFC 3281An Internet Attribute Certificate Profile for Authorization определяет профиль атрибутного сертификата для использования в Интернет-протоколах. Атрибутный сертификат подобен сертификату открытого ключа, но в отличие от него содержит не открытый ключ, а атрибуты, характеризующие его владельца: принадлежность к какой-либо группе, роль, полномочия, уровень прозрачности информации о владельце и т.п. Стандарт обеспечивает поддержку атрибутных сертификатов для электронной почты в Интернете, протокола IPsec, приложений безопасности World Wide Web.

Стандарт 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 в Интернете:

К третьему направлению можно отнести документы 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 лекции 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-систем могут также привести к несовместимости отдельных реализаций.

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

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

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

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

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

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#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

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