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

Пример 9.2. Рассмотрим дерево аннулирования сертификатов, представленное на рис. 9.3 [44]. Крайние слева узлы представляют хэш-коды математических выражений, которые известны субъекту, генерирующему дерево. Как показано стрелками, каждая смежная пара узлов затем объединяется в один узел. Если пара существует, два узла объединяются и хэшируются. Результат хэширования - это значение нового сформированного узла справа. Если пары нет (когда на данном уровне имеется нечетное количество узлов), то непарный узел просто перемещается на следующий уровень дерева (как показано узлами N_2,2 и N_3,1 на рис. 9.3). Этот процесс повторяется до тех пор, пока не будет вычислен финальный "корень" (самый правый узел на рис. 9.3). Значение хэш-кода последнего узла в целях обеспечения целостности и аутентичности заверяется цифровой подписью.

Рис. 9.3.  Пример дерева аннулирования сертификатов

Чтобы определить, был ли сертификат аннулирован, доверяющая сторона проверяет, превышает ли серийный номер сертификата нижнюю границу ближайшего по значению нестрогого неравенства из последовательности выражений для данного УЦ. Если это так, то сертификат не был аннулирован, если нет - то был. Чтобы убедиться в том, что целостность не была нарушена, доверяющая сторона должна реконструировать корневой узел и сравнить его хэш-код со значением заверенного цифровой подписью хэш-кода корневого узла. Для этого субъект, сгенерировавший дерево, предоставляет доверяющей стороне информацию о выражении, ближайшем к серийному номеру проверяемого сертификата, значения хэш-кодов всех поддерживающих узлов и заверенный цифровой подписью хэш-код корневого узла. Генерация ДАС может выполняться уполномоченным субъектом внутри рассматриваемого множества PKI-сообществ или доверенной третьей стороной. Главное преимущество деревьев ДАС заключается в эффективном представлении большого объема информации об аннулировании. Фактически объем ДАС составляет log2N, где N - число аннулированных сертификатов.

Механизмы онлайновых запросов

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

Разработкой онлайновых протоколов статуса сертификата занималась рабочая группа IETF PKIX. В июне 1999 года онлайновый протокол статуса сертификата Online Certificate Status Protocol ( OCSP ) был предложен в качестве стандарта RFC 2560 [155]. Поскольку это был первый шаг в разработке протоколов такого рода, функциональность OCSP была намеренно ограничена его разработчиками.

Онлайновый протокол статуса сертификата

Онлайновый протокол статуса сертификата OCSP - относительно простой протокол (типа "запрос-ответ") для получения информации об аннулировании от доверенного субъекта, называемого OCSP-респондером . OCSP-запрос состоит из номера версии протокола, типа запроса на обслуживание и одного или нескольких идентификаторов сертификатов. Идентификатор сертификата включает хэш-коды отличительного имени и открытого ключа издателя сертификата, а также серийный номер сертификата. В запросе иногда могут присутствовать необязательные дополнения.

OCSP-ответ также достаточно прост и состоит из идентификатора сертификата, статуса сертификата ("нормальный", "аннулированный" или "неизвестный") и срока действия ответа, связанного с идентификатором каждого указанного в исходном запросе сертификата. Если сертификат имеет статус аннулированного, то отображается время аннулирования и может быть указана причина аннулирования (необязательно). Срок действия задается интервалом от текущего обновления (параметр This Update ) до следующего обновления (параметр Next Update ). Ответ может содержать необязательные дополнения, а также код ошибки, если обработка запроса не была завершена корректно.