Полные списки САС

Большинство удостоверяющих центров выпускают свои собственные списки САС, то есть одновременно являются издателями и сертификатов, и списков САС. Список, который охватывает всю совокупность сертификатов, выпускаемых данным УЦ и содержит всю наиболее свежую информацию об аннулировании, называют полным САС . Поддержка полного списка - наиболее простой способ обработки сертификатов. Его легко реализовать, однако поддержка полных списков САС порождает три серьезных проблемы:

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

2 проблема своевременности получения информации из списков САС. Очевидно, что с увеличением размера САС валидация сертификатов будет занимать больше времени, и это безусловно отразится на скорости доставки информации о статусе сертификатов;

3 проблема избыточной частоты генерации списков и обращения к ним. Если, например, политика применения сертификатов требует, чтобы аннулирование сертификатов из-за компрометации ключа выполнялось в течение дня, то очередной полный САС должен выпускаться каждый день. Соответствующая информация в поле сертификата Next Update вынудит пользователей сертификата получать новый полный список каждый день.

Полные списки САС целесообразно использовать лишь в доменах некоторых удостоверяющих центров с относительно небольшим количеством конечных субъектов.

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

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

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

Списки САС КС идентифицируются при помощи дополнений Issuing Distribution Point и/или CRL Scope. Отдельный САС КС должен содержать всю информацию об аннулировании сертификатов конечных субъектов домена данного УЦ или может быть разбит на несколько списков разными способами, которые обсуждаются ниже.

 

Пункты распространения САС

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

1 позволяют разбивать всю информацию об аннулировании на более управляемые части, не допуская чрезмерного разрастания списков САС;

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

Синтаксис дополнения CRL Distribution Point позволяет идентифицировать местонахождение соответствующей части САС: это может быть определенный сервер, заданный при помощи DNS-имени или IP-адреса, или определенное место на сервере (например, дерево информации каталога общедоступного репозитория или файл на web-сервере). иллюстрирует понятие пункта распространения САС .

Рис. 9.1.  Пункт распространения САС

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

 

Переадресующие списки САС

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

Для реализации такого механизма рабочая группа IETF PKIX разработала концепцию динамического разбиения, которая была формально стандартизована в версии 2000 года рекомендаций X.509 , и ввела в профиль списков САС дополнения CRL Scope и Status Referrals. Дополнение Status Referrals позволяет переадресовать доверяющую сторону к фактическому местонахождению информации искомого САС, не изменяя в сертификатах дополнение CRL Distribution Point. Как показано на , дополнение CRL Distribution Point указывает на промежуточный САС, который, в свою очередь, содержит дополнение Status Referral со ссылкой на искомый САС. Промежуточный САС называется переадресующим списком .

Рис. 9.2.  Переадресующий САС

Отметим, что при движении от переадресующего списка к искомому должны выполняться проверки согласованности, чтобы предотвратить попытки "спуфинга", то есть подмены САС. Переадресующий САС фактически содержит не список аннулированных сертификатов, а только указатели на искомые списки САС. Это позволяет частичным спискам САС изменяться во времени, не влияя на содержание существующих сертификатов. Даже если схема разбиения САС меняется, в сертификатах не приходится корректировать поля дополнения CRL Distribution Point.

Синтаксис дополнения аналогичен синтаксису дополнения Issuing Distribution Point, но в нем присутствуют несколько новых атрибутов - такие как имя УЦ (атрибут необходим, если это имя отличается от имени издателя списка, указанного в дополнении Status Referral ), ранг серийного номера или идентификатора открытого ключа субъекта, ограничения имен поддеревьев. Поскольку в дополнениях Issuing Distribution Point и CRL Scope могут встречаться одинаковые атрибуты (например, оба дополнения могут идентифицировать имя пункта распространения и включать признаки "содержит только сертификаты пользователей", "содержит только сертификаты удостоверяющих центров", "содержит только причины аннулирования"), эти дополнения могут конфликтовать друг с другом. Поэтому, если они используются одновременно, следует проверять их согласованность.

 

Дельта-списки и косвенные дельта-списки САС

Назначение дельта-списка - информировать об изменениях в САС, произошедших с момента его выпуска или с некоторого заданного момента времени, другими словами, о приращении САС (как известно, приращение обозначается символом , отсюда и название списка) . Если дельта-список ссылается на базовый САС, то базовый список и дельта-список вместе предоставляют всю информацию об аннулировании внутри указанной области, известную на момент выпуска дельта-списка. В этом случае дополнение Delta CRL Indicator используется для указания номера базового САС. В качестве альтернативы для указания того, что САС является дельта-списком, может использоваться компонент Base Revocation Information дополнения CRL Scope. В этом случае Base Revocation Information задает момент времени, начиная с которого корректировку информации об аннулировании обеспечивает дельта-список. Он может содержать ссылку на полный САС для данной области, но может и не содержать ее, а ссылаться на другой дельта-список. Отметим, что разрешается применять только один из двух способов: либо дополнение Delta CRL Indicator, либо компонент Base Revocation Information в дополнении CRL Scope.

Дельта-списки были впервые предложены в версии 1997 г. стандарта X.509 , но тогда четко не объяснялось, как их следует применять. Например, предполагалось, что полный САС должен публиковаться при каждом выпуске дельта-списка, а это противоречило самой идее дельта-списков. В версии 2000 г. стандарта X.509 появилось уточнение относительно применения дельта-списков и была введена концепция косвенных списков САС. Косвенные списки предназначаются для более своевременной доставки информации об аннулировании, их обработка не увеличивает нагрузку на сетевые ресурсы.

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

Пример 9.1. Рассмотрим корпоративный домен PKI, в котором разрешено выпускать полные списки САС не чаще чем раз в неделю. Политикой безопасности этого домена установлено, что информация об аннулировании должна распространяться не позднее 5 часов с момента аннулирования сертификата. Очевидно, что в этом случае требования регулярности выпуска полного САС и своевременности доставки информации противоречат друг другу. Решение проблемы заключается в выпуске базового САС раз в неделю, а дельта-списков САС - каждые 5 часов. Таким образом, более объемный САС выгружается и размещается в кэш-памяти раз в неделю, а относительно небольшие дельта-списки распространяются по мере необходимости. Дельта-списки также могут размещаться в кэш-памяти до тех пор, пока не истечет их срок действия. Если кэширование запрещено, необходимо выполнять поиск дельта-списка САС всякий раз, когда выполняется валидация сертификата, - тогда и только тогда информация об аннулировании будет актуальной.

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

 

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

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

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

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

 

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

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

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

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

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

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

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

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

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

 

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

 

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

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

 

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

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

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

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

Рис. 9.4.  Взаимодействие OCSP-компонентов

В любом случае доверяющая сторона должна доверять ответу на запрос, что подразумевает доверие к тому, кто подписал ответ. Следовательно, доверяющая сторона должна получить копию сертификата открытого ключа OSCP-респондера, и этот сертификат должен быть подписан доверенным источником. Запросы также могут заверяться цифровой подписью (например, если OCSP-респондер действует как платный сервис), но это - необязательная опция протокола OCSP. Информация о местонахождении OCSP-респондера, отвечающего на запросы о статусе данного сертификата, содержится в самом сертификате в дополнении Authority Information Access . Дополнение Distribution Points используется для указания на часть САС.

протокол OCSP разрабатывался исключительно для поддержки сообщений о статусе сертификатов и не позволяет определять валидность сертификата. Другими словами, протокол OCSP не подтверждает, что сертификат не был просрочен, и не гарантирует, что сертификат используется в точном соответствии с назначением, которое обычно указывается в дополнениях данного сертификата: Key Usage, Extended Key Usage или Policy Qualifier. Кроме того, доверяющим сторонам не стоит переоценивать возможности протокола доставлять самую "свежую" информацию об аннулировании сертификатов в режиме реального времени. Даже если сам протокол предлагает ответ на запрос в режиме реального времени (в предположении, что OCSP-респондер доступен в онлайновом режиме для обслуживания запросов), это не обязательно означает, что протокол OCSP -ответ о текущем состоянии сертификата придет без задержки, особенно если сервисы УЦ и OCSP-респондера реализованы на одном сервере. То есть доверяющим сторонам не стоит полагаться на то, что по протоколу OCSP автоматически доставляется самая "свежая" информация, даже если считается, что информирование о статусе сертификатов - это сервис реального времени.

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

 

Простой протокол валидации сертификатов

Простой протокол валидации сертификатов (Simple Certificate Validation Protocol - SCVP) разрабатывался рабочей группой PKIX для обеспечения делегирования процессов валидации и обнаружения пути сертификации доверенным сторонам в среде Интернет . Делегированная валидация пути (Delegated Path Validation - DPV) позволяет доверяющей стороне переложить процесс валидации пути сертификации на доверенную третью сторону. Это имеет смысл в тех средах, где локальная валидация пути невозможна или нежелательна, а также в случае поддержки в среде централизованной политики валидации. По аналогии с DVP делегированное обнаружение пути (Delegated Path Discovery - DPD) позволяет доверяющей стороне поручить трудоемкий процесс построения пути сертификации доверенной третьей стороне. Это избавляет доверяющую сторону от необходимости поиска сертификатов, составляющих путь сертификации.

 

Другие режимы аннулирования

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

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

 

Сравнительная характеристика разных схем аннулирования

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

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

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

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

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

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

|Схема | Основное описание | Примечания |

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

|Списки САС удостоверяющих центров | Тип САС, который предназначен исключительно для информации об аннулировании, относящейся к удостоверяющим центрам; определен стандартом X.509 | На практике обычно разделяется информация об аннулировании сертификатов удостоверяющих центров и конечных субъектов |

|Списки САС конечных субъектов | Тип САС, который предназначен исключительно для информации об аннулировании относящейся к конечным субъектам; определен стандартом X.509 | На практике обычно разделяется информация об аннулировании сертификатов удостоверяющих центров и конечных субъектов |

|Пункты распространения САС | Используются для статичес-кого разбиения списков САС на части; определены стандартом X.509 | Позволяет статически разбивать информацию об аннулировании сертификатов на более управляемые части |

|Дельта-списки и косвенные списки САС | Используются для распространения небольших дельта-списков ; определены стандартом X.509 | Могут использоваться для существенного повышения скорости обработки и поддержки своевременности. Комбинируются с другими формами списков САС |

|Косвенные списки САС | Используются для объединения в одном списке информации об аннулировании от нескольких удостоверяющих центров; определены стандартом X.509 | Могут использоваться для повышения скорости обработки при условии, что объединение информации из нескольких источников не требует больших затрат, чем поиск информации в каждом отдельном источнике |

|Онлайновый протокол статуса сертификата - OCSP | Возможность онлайновых запросов используется для получения информации о статусе одного или нескольких сертификатов; определен в документе RFC 2560 | Несмотря на то, что протокол предназначен для ответов в режиме реального времени, "свежесть" предоставляемой информации зависит от ее источника |

|Переадресующие списки САС | Используются для динамического разбиения информации об аннулировании; определены в документе RFC 2560 | Относительно новая концепция, которая совершенствует схему пунктов распространения САС |

|Деревья аннулирования сертификатов CRT | Позволяют отображать информацию об аннулировании при помощи деревьев двоичных хэш-кодов; соответствующий метод разработан компанией Valicert | Могут стать одним из альтернативных способов, применяемых сторонними поставщиками услуг для представления информации об аннулировании |

|Другие способы | Используются, если доставка информации об аннулировании не требуется или реализуются по-другому | Альтернативные способы подходят, если авторизация всех транзакций выполняется общим центром |

Таблица 9.4.Схемы аннулирования сертификатов