Читать онлайн «Инфраструктуры открытых ключей». Страница 35

Дополнение Reason Code указывает причину аннулирования сертификатов. Издателем САС настоятельно рекомендуется включать в это дополнение значащие коды причин. В дополнении могут указываться следующие коды причин:

* 0 - неопределенная причина;

* 1 - компрометация ключа;

* 2 - компрометация УЦ;

* 3 - изменения в результате слияния компаний;

* 4 - замена сертификата;

* 5 - прекращение работы;

* 6 - приостановление сертификата и передача его на хранение;

* 8 - удаление сертификата из САС.

Дополнение Hold Instruction Code (код команды передачи сертификата на хранение) используется для временного приостановления сертификата. Оно содержит идентификатор зарегистрированной команды, указывающий действие, которое необходимо выполнить, если при обработке транзакции встречается сертификат, который должен быть приостановлен и передан на хранение. Документ RFC 3280 требует, чтобы поддерживалось несколько кодов команд, в том числе "позвонить издателю" и "отвергнуть сертификат". Это дополнение всегда помечается как некритичное. Оно имеет очень ограниченное применение, в частности, при выполнении финансовых транзакций. Например, если пользователь совершает покупку и при оплате предъявляет кассиру смарт-карту, на которой хранится секретный ключ его сертификата, то УЦ, выпустивший этот сертификат, может использовать команду "позвонить издателю", чтобы заставить кассира связаться с УЦ. Если сертификат пользователя был приостановлен, то при обращении к нему УЦ может потребовать от кассира конфисковать эту смарт-карту [70]. Приостановленный сертификат может быть в дальнейшем восстановлен или аннулирован.

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

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

Это дополнение всегда помечается как некритичное. Присутствие этого дополнения не влияет на принятие сертификата, однако информация о дате утраты валидности может использоваться при разрешении споров по поводу отказа субъекта аннулированного сертификата от своего участия в транзакции.

Формат САС X.509 v2 позволяет использовать частные дополнения для поддержки специфической для данного сообщества пользователей информации. В соответствии с рекомендациями X.509 частные дополнения могут задаваться для САС и для точек входа в САС. Документ RFC 3280 не дает описания частных дополнений, а в целях предупреждения проблем функциональной совместимости разных доменов не рекомендует использовать частные дополнения и тем более помечать их как критичные.

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

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

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

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

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

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

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

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

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

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