Инфраструктуры открытых ключей - Ольга Полянская

Доверяющая сторона может определить, поддерживаются ли дельта-списки, несколькими способами. Во-первых, информацию об этом можно найти в опубликованном регламенте УЦ, связанном с определенной политикой применения сертификатов, идентификатор которой указывается в любом сертификате. Во-вторых, для прямого указания на дельта-список обычно используется дополнение сертификата Freshest CRL точно так же как для указания на часть определенного САС применяется дополнение CRL Distribution Point.

Косвенные списки САС

В версии 2000 года стандарта X.509 [78] появилась концепция косвенных дельта-списков. Подобно дельта-спискам, косвенные списки содержат сведения об изменениях ранее опубликованной информации об аннулировании сертификатов. Однако косвенные дельта-списки могут использоваться для корректировки нескольких списков САС, выпущенных одним издателем (например, один косвенный дельта-список может обеспечить обновление информации обо всех пунктах распространения списков САС, изданных данным УЦ). Они также могут предоставлять последнюю информацию об обновлении списков САС, выпущенных несколькими издателями.

Косвенные списки позволяют объединять в одном САС информацию об аннулировании сертификатов, полученную от нескольких удостоверяющих центров, и таким образом уменьшать общее количество списков САС, необходимых доверяющим сторонам для валидации сертификатов [67]. Например, если в состав одного PKI-домена входит несколько удостоверяющих центров, то вся информация об аннулировании сертификатов внутри данного домена может быть объединена в одном косвенном списке, что избавляет доверяющие стороны от необходимости искать несколько списков САС (по одному для каждого УЦ). Эта возможность особенно актуальна при взаимодействии нескольких PKI-доменов, поскольку косвенные списки позволяют уменьшить нагрузку на сетевые ресурсы и снизить стоимость приема сообщений. Поддержка косвенных списков САС может осуществляться на коммерческой основе доверенной третьей стороной. В любом случае доверяющая сторона должна полагаться на издателя косвенного списка в той же степени, в которой она доверяет УЦ, выпустившему проверяемый сертификат.

Информация о косвенных списках указывается в компоненте Indirect CRL дополнения сертификата Issuing Distribution Point. Если он принимает значение TRUE, то САС может содержать информацию об аннулировании из нескольких источников. Для реализаций, которые согласуются со стандартом X.509 (версии 2000 г.), косвенные списки САС также могут поддерживаться путем указания в поле Authority Name нескольких атрибутов Per Authority Scopes с именами разных удостоверяющих центров.

Деревья аннулирования сертификатов

Деревья аннулирования сертификатов, ДАС (Certificate Revocation Trees - CRTs) - это технология аннулирования, разработанная американской компанией Valicert. Деревья ДАС базируются на хэш-деревьях Merkle, каждое дерево позволяет отобразить всю известную информацию об аннулировании, релевантную некоторому множеству PKI-сообществ [83].

Чтобы создать хэш-дерево, генерируется последовательность выражений для каждого УЦ, входящего в данное множество. Каждая последовательность ранжируется по возрастанию серийных номеров аннулированных сертификатов данного УЦ. Выражение может иметь, например, следующий вид: УЦ1 = УЦn и 1155 < X < 1901, где X - серийный номер сертификата, изданного УЦ1. Это означает, что:

1 сертификат с серийным номером 1155, изданный УЦ1, был аннулирован;

2 сертификаты, изданные УЦ1, с серийными номерами от 1156 до 1900 (включительно) не аннулированы.

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

Пример 9.2. Рассмотрим дерево аннулирования сертификатов, представленное на рис. 9.3 [44]. Крайние слева узлы представляют хэш-коды математических выражений, которые известны субъекту, генерирующему дерево. Как показано стрелками, каждая смежная пара узлов затем объединяется в один узел. Если пара существует, два узла объединяются и хэшируются. Результат хэширования - это значение нового сформированного узла справа. Если пары нет (когда на данном уровне имеется нечетное количество узлов), то непарный узел просто перемещается на следующий уровень дерева (как показано узлами N2,2 и N3,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 ). Ответ может содержать необязательные дополнения, а также код ошибки, если обработка запроса не была завершена корректно.