Полные списки САС
Купить SSL сертификат

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  •