Certificate Revocation List

История создания PKI (Инфраструктура открытых ключей) восходит к оригинальной работе Уитфилда Диффи и Мартина Хеллмана по криптографии с открытым ключом, в которой предлагается каталог открытых файлов, который пользователи могли бы использовать, чтобы найти открытые ключи других пользователей.

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

Спустя несколько лет после того, как Конфельдер опубликовал свою диссертацию, разработчики включили использование сертификата в X.500, глобальный каталог названных объектов, управляемых монопольными телекоммуникационными компаниями. В каталоге X.500 предлагается иерархическая модель базы данных, причём путь через каталог определяется рядом компонентов относительного отличительного имени (RDN), которые вместе образуют отличительное имя (DN). Чтобы защитить доступ к каталогу, его разработчики предложили различные механизмы контроля доступа, начиная от простых основанных на пароле мер и заканчивая относительно новым подходом к использованию цифровых подписей. Этим стандартом, включённым в X.500, был стандарт X.509v1. На данный момент существует версия x.509v3.

Разработчики основывали концепцию СОС на чёрных списках кредитных карт, которые использовались в 1970-х годах. Компании, выпускающие кредитные карты, периодически печатали буклеты с номерами аннулированных карт и распространяли их среди продавцов, ожидая, что они проверят все карты, с которыми взаимодействуют, в чёрном списке, прежде чем их принять. Те же проблемы, которые затрагивали чёрные списки кредитных карт, сегодня влияют на СОС.

Удостоверяющий центр периодически выдаёт список, который он публикует в хранилище. Каждый СОС включает поле nextUpdate, которое указывает время, когда будет выпущен следующий СОС. Любая проверяющая сторона, которой требуется информация о статусе сертификата и у которой ещё нет текущего СОС, получает текущий список из хранилища. Если сертификат, который проверяет клиент, не находится в списке, то работа продолжается в нормальном режиме и ключ считается подтверждённым сертификатом. Если же сертификат присутствует, то ключ считается недействительным и ему нельзя доверять.

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

Существует также механизм дельта-СОС, который является необязательным механизмом, указанным в RFC 2459, который может использоваться для улучшения распространения информации об аннулировании. Списки дельта-СОС являются сравнительно небольшими по объёму, содержащими только те изменения в перечнях аннулированных сертификатов, которые имели место с момента формирования центром CA последней версии абсолютного списка (complete CRL). Поскольку списки дельта-СОС невелики, клиенты PKI могут загружать их чаще, чем списки complete CRL, соответственно, при этом центр УЦ обеспечивает своих клиентов более точной информацией об аннулированных сертификатах.

Некоторые проблемы затрудняют работу с СОС. СОС в некоторых случаях оказывается ненадежным в качестве механизма распространения статуса сертификата. Критические приложения требуют немедленного отзыва — или, точнее, информации о статусе сертификата в реальном времени — и списки отзыва сертификатов не всегда решают эту основную проблему по нескольким причинам.

Основные проблемы СОС:

• СОС выдаются недостаточно часто, чтобы быть эффективными против злоумышленника, получившего чужой закрытый ключ
• атака типа «отказ в обслуживании» легко делает их неэффективными (существует решение в виде зеркал)

СОС страдают от нескольких других практических проблем. Чтобы гарантировать своевременное обновление статуса, сервер должен выдавать СОС как можно чаще. Тем не менее, выдача СОС увеличивает нагрузку на сервер и сеть, которая его передает, и, в меньшей степени, на клиента, который его получает. Например 10 млн клиентов загружают 1 МБ СОС, выдаваемых раз в минуту, = трафик ~ 150 ГБ/с. Следовательно это дорогая операция. Выдача СОС раз в минуту обеспечивает умеренно своевременный отзыв за счет огромных накладных расходов, поскольку каждая проверяющая сторона загружает новый СОС (во многих случаях эта задача ложится на Дельта-СОС и проблема решается). С другой стороны, задержка выдачи до одного раза в час или день не обеспечивает своевременного отзыва при условии, что в этот период некоторые сертификаты были отозваны.

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

На данный момент существует несколько аналогов СОС, которые не имеют недостатков СОС, но при этом имеют собственные.

Одним из аналогов является OCSP — Online Certificate Status Protocol. Данное решение проблемы предоставляет ответ сервера о данном конкретном запрашиваемом сертификате в режиме реального времени. Этот подход решает многие проблемы, присущие СОС, создавая одноразовый, свежий СОС с одиночной записью в ответ на запрос. В отличие от этого модель на основе СОС требует, чтобы проверяющие стороны неоднократно получали огромное количество не относящихся к делу записей, чтобы получить информацию о состоянии для одного сертификата, который им нужен. Однако OCSP имеет свою стоимость. Вместо подготовки СОС в качестве фоновой автономной операции УЦ теперь должен выполнять поиск сертификата и операцию создания псевдо-СОС для каждого запроса. Чтобы сделать OCSP экономически целесообразным, УЦ должен взимать плату за каждую проверку отзыва. OCSP решает эту проблему, подписывая запросы на идентификацию отправителя для выставления счетов.

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

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

Также OCSP раскрывает историю подключений клиента третьей стороне (УЦ).

Обновление OCSP — это OCSP stapling. Он избавляет от необходимости повторно отправлять запрос OCSP, выдавая ответ OCSP вместе с самим сертификатом. Это называется OCSP Stapling, потому что сервер должен «скрепить» (staple) ответ OCSP с сертификатом и выдать их вместе. При установке соединения сервер передаёт клиенту свою цепочку сертификатов вместе с соответствующими ей OCSP-ответами. Ответ OCSP действует только короткий промежуток времени и подписан УЦ точно так же, как сертификат. Это также устраняет проблему конфиденциальности OCSP, поскольку респондент не имеет доступа к сведениям о посетителях веб-сайта. К сожалению, это широко не реализовано, только 3 % серверов поддерживают OCSP Stapling.

Одним из возможных применений инфраструктуры открытых ключей является HTTPS. Многие браузеры используют 2 основных подхода: СОС и OCSP. Mozilla Firefox не загружает СОС автоматически. Браузер использует OCSP для проверки того, был ли сертификат отозван. Internet Explorer, и Opera делают гораздо более тщательную работу; они оба поддерживают OCSP и CRL и выполняют подходящие проверки для всех типов сертификатов. Но СОС применяется, в основном, как запасной вариант в данной проверке.

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

Алгоритм проверки заключается в следующем:

• Получатель принимает сообщение, электронную подпись и ссылку на сертификат, которая в большинстве своём является частью электронной подписи.
• С помощью открытого ключа субъекта получатель расшифровывает электронную подпись, а также сам вычисляет контрольную сумму сообщения. Получатель сравнивает контрольные суммы.
• Далее получатель находит сертификат автора электронной подписи, по цепочке сертификатов (далее, переходим к издателю сертификата и его сертификату) происходит спуск вниз, до УЦ, которому доверяет получатель ЭП.
• Происходит проверка всех сертификатов в цепочке в СОС. Если хеши совпадают и все сертификаты в цепочке действительны, происходит подтверждение целостности и авторства документа.

• А. И. Колыбельников. Новый алгоритм формирования списков отозванных сертификатов
• P. Gutmann. PKI: it’s not dead, just resting
• David A. Cooper. A Model of Certificate Revocation
• Michael Cobb. How do different browsers handle SSL certificate revocation?
• Emin Topalovic, Brennan Saeta. Towards Short-Lived Certificates
• Peter Gutmann. Everything you Never Wanted to Know about PKI but were Forced to Find Out

• RFC 5280