Инфраструктура Открытого Ключа (часть 6)

Протоколы PKI управления сертификатом

Введение

В этой лекции будут рассматриваться управляющие протоколы PKI.

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

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

Протоколы управления требуются для поддержки on-line взаимодействия между компонентами PKI. Например, протокол управления должен использоваться между СА и системой клиента, с которым связана пара ключей, или между двумя САs, которые выпустили кросс-сертификаты друг для друга.

Все конечные участники требуют локального безопасного доступа к некоторой информации – как минимум к своему собственному имени и закрытому ключу, имени СА, который является доверенным для данного участника, и открытому ключу СА (или дайджесту открытого ключа, если допустима самосертифицированная версия). Может использоваться локальное безопасное хранение и для большего количества информации (например, сертификата конечного участника или информации, относящейся к приложению). Форма хранения также может быть различной – от файлов до неподделываемых криптографических токенов. Такое локальное доверенное хранение мы будем определять как персональное безопасное окружение (Personal Security Environment – PSE) конечного участника.

Хотя форматы PSE находятся вне рассматриваемой предметной области (в частности, они очень зависят от оборудования), здесь мы определим общий формат обмена для PSEs.

Требования к управлению PKI

Рассматриваемые протоколы должны удовлетворять следующим требованиям к управлению PKI.

1. Управление PKI должно соответствовать стандарту ISO 9594-8 и связанным с ним расширениям сертификата.
2. Управление PKI должно соответствовать остальным частям стандарта Х.509 v3.
3. Должна быть возможность регулярного изменения любой пары ключей без влияния на какую-либо другую пару ключей.
4. Использование сервисов, обеспечивающих конфиденциальность, в протоколах управления PKI должно быть сведено к минимуму, чтобы уменьшить связанные с этим проблемы.
5. Протоколы управления PKI должны допускать использование различных криптографических алгоритмов, являющихся промышленными стандартами (специально включая только RSA, DSA, MD5, SHA-1). Это означает, что данный СА, RA или конечный участник могут в принципе использовать для своей пары ключей любой набор алгоритмов.
6. Протоколы управления PKI не должны препятствовать созданию пары ключей как конечным участником, так и RA или СА –ключ может создаваться где-то еще, но в целях управления PKI мы можем предполагать, что генерация ключа происходит в тот момент, когда он впервые передан конечному участнику, RA или СА.
7. Протоколы управления PKI должны поддерживать опубликование сертификатов, относящихся к конечным участникам, RA или СА.
8. Протоколы управления PKI должны поддерживать создание CRLs, позволяя сертифицированным конечным участникам посылать запросы на отмену сертификатов – это должно быть организовано так, чтобы невозможно было предпринять DoS-атаку.
9. Протоколы управления PKI должны использоваться поверх различных транспортных механизмов, включая LDAP, SMTP, HTTP, TCP/IP и FTP.
10. Конечным уполномоченным органом при создании сертификата является СА; предполагается, что оборудование ни конечного участника, ни RA не может выпустить сертификат – СА может изменить значения полей сертификата или может добавить, удалить или изменить расширения в соответствии со своей политикой функционирования. Например, СА может уменьшить запрошенный период действительности. Заметим, что политика может определять, что СА не должен публиковать или каким-то другим образом распределять сертификат, пока участник не просмотрит и не получит заново созданный сертификат (обычно с использованием PKIConfirm -сообщения).
11. Должна поддерживаться возможность гибкого изменения от одной нескомпрометированной пары ключей СА к следующей (заметим, что если ключ СА скомпрометирован, переинициализация должна выполняться для всех участников в домене данного СА). Конечный участник, чей PSE содержит новый открытый ключ СА (следуя изменению ключа СА ) должен также иметь возможность проверять сертификаты, с использованием старого открытого ключа. Конечные участники, которые непосредственно доверяют старой паре ключей СА, должны также иметь возможность проверять сертификаты, подписанные с использованием нового закрытого ключа СА. (Обычно это требуется в ситуациях, когда старый открытый ключ СА "встроен" в криптографическое оборудование конечного участника.)
12. Функции RA в некоторых реализациях или окружениях выполняются самим СА. Протоколы должны быть разработаны так, чтобы конечные участники могли использовать тот же протокол (но, конечно, не тот же ключ!) независимо от существующей взаимосвязи RA или СА.
13. При запросе конечным участником сертификата, содержащего данное значение открытого ключа, конечный участник должен быть готов продемонстрировать обладание соответствующим значением закрытого ключа. Это можно организовать по-разному, в зависимости от типа алгоритма открытого ключа.