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