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

Изменение ключа корневого СА

Данное обсуждение касается только САs, которые являются корневыми СА для некоторого конечного участника.

Основа описанной здесь процедуры состоит в том, что СА защищает свой новый открытый ключ, используя предыдущий закрытый ключ, и наоборот. Таким образом, если СА изменяет свою пару ключей, он должен создать два дополнительных значения атрибута сертификата cACertificate, если сертификаты доступны с использованием Х.500 директории (всего четыре сертификата: OldWithOld; OldWithNew; NewWithOld; NewWithNew).

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

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

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

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

Действия оператора СА

Для изменения ключа СА оператор СА должен сделать следующее:

1. Создать новую пару ключей;
2. Создать сертификат, содержащий старый открытый ключ, подписанный новым закрытым ключом ("старый с новым" сертификат);
3. Создать сертификат, содержащий новый открытый ключ СА, подписанный старым закрытым ключом ("новый со старым" сертификат);
4. Создать сертификат, содержащий новый открытый ключ СА, подписанный новым закрытым ключом ("новый с новым" сертификат).
5. Опубликовать эти новые сертификаты в директории и/или другими способами (возможно, с использованием CAKeyUpdAnn -сообщения);
6. Экспортировать новый открытый ключ СА так, чтобы конечные участники могли получить его, используя "внешний" механизм (если нужно).

Старый закрытый ключ СА более не требуется. Тем не менее старый открытый ключ еще некоторое время используется. Старый открытый ключ не будет требоваться, когда все конечные участники данного СА безопасно получат новый открытый ключ СА.

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

Сертификат "новый с новым" должен иметь период действительности, начинающийся со времени создания новой пары ключей и заканчивающийся временем следующего изменения СА своей пары ключей.

Проверка сертификатов

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

Проверка в случаях 1, 4, 5 и 8

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

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

Проверка в случае 2

В случае 2 проверяющий должен получить доступ к старому открытому ключу СА. Проверяющий делает следующее:

1. Смотрит атрибут caCertificate в директории и получает OldWithNew- сертификат (определяемый на основе периода действительности);
2. Проверяет, все ли в порядке, используя новый ключ СА (который он имеет локально);
3. Если все нормально, проверяет сертификат подписавшего, используя старый открытый ключ СА.

Случай 2 встречается, когда оператор СА выпустил сертификат подписывающего, затем изменил ключ и выпустил сертификат проверяющего; таким образом, это вполне типичный случай.

Проверка в случае 3

В случае 3 проверяющий должен получить доступ к новому открытому ключу СА. Проверяющий делает следующее:

1. Смотрит атрибут саCertificate в директории и получает NewWithOld- сертификат (определяемый на основе периода действительности);
2. Проверяет, корректен ли он, используя старый открытый ключ СА (который хранится локально);
3. В случае корректности проверяет сертификат подписавшего, используя новый открытый ключ СА.

Случай 3 имеет место, когда оператор СА выпускает сертификат проверяющего, затем изменяет ключ и выпускает сертификат подписавшего; таким образом, это вполне типичный случай.

Неудачная проверка в случае 6

В данном случае СА выпускает PSE проверяющего, содержащий новый ключ, без изменения атрибутов директории. Это означает, что проверяющий не может получить достоверную версию старого ключа СА, поэтому проверка не проходит.

Заметим, что невозможность проверки является ошибкой оператора СА.

Неудачная проверка в случае 7

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

Заметим, что невозможность проверки также является ошибкой оператора.

Отмена – изменение ключа СА

Как показано выше, проверка сертификата становится более сложной, так как допускается изменение ключа СА. Это также верно для проверок отмены, поскольку СА может подписать CRL, используя более новый закрытый ключ, чем тот, который применялся для пользовательского PSE.

Анализ возможных альтернатив аналогичен проверке сертификата.