Инфраструктуры открытых ключей

Кроме того, сертификаты, связанные с уникальной парой ключей, независимо конструируются: они могут соответствовать разным политикам, а также иметь разные сроки действия, назначения и процедуры управления. Один сертификат может устаревать или аннулироваться независимо от других сертификатов. Использование одного и того же открытого ключа в нескольких сертификатах усложняет управление сертификатами.

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

И наоборот, часто требуется, чтобы создавались резервные копии тех ключей, которые не используются для сервиса неотказуемости. Например, операционная политика любой компании обычно требует выполнения резервного копирования секретных ключей шифрования в течение срока их действия. Это объясняется тем, что компания просто не может себе позволить навсегда потерять доступ ко всем хранимым данным, зашифрованным служащими компании, которые в любой момент могут забыть свои пароли, потерять трудоспособность или уволиться. Такая потеря данных, по меньшей мере, создала бы неудобства, а в худшем случае нанесла бы компании существенный вред. Поэтому если компания стремится избежать серьезных потерь из-за неспособности восстановить критически важные данные, она должна обеспечить восстановление ключей шифрования. По истечении срока действия секретные ключи шифрования должны сохраняться в архиве, чтобы впоследствии их можно было использовать для расшифрования старых данных.

С другой стороны, требования к созданию резервных копий ключей подписи (особенно тех, которые должны использоваться для поддержки неотказуемости) не предъявляются; они должны принадлежать только тому субъекту, который указан в соответствующем сертификате открытого ключа. Если секретный ключ подписи утрачен, должна быть сгенерирована новая пара ключей. По истечении срока действия секретные ключи подписи не помещаются в архив, а безопасным образом уничтожаются.

Такие взаимоисключающие друг друга требования диктуют необходимость субъекту корпоративной PKI иметь, по крайней мере, две разные пары ключей (и связанных с ними сертификатов). Это установлено рядом требований и профилей в стандартах PKI (например, RFC 3280). В некоторых средах, например, в инфраструктуре ИТ-безопасности шведской некоммерческой организации Secure Electronic Information in Society, уже управляют тремя парами ключей: шифрования/расшифрования, подписи/верификации общего назначения и подписи/верификации для поддержки неотказуемости [68].

Жизненный цикл сертификатов и ключей

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

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

Рис. 7.3.  Жизненный цикл сертификата

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

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