Кратко

  • Профиль RFC 5280 уже требовал keyUsage с cRLSign для ключа подписи CRL, но алгоритм велел проверять бит лишь при наличии расширения.
  • RFC 10007 делает наличие расширения и значение бита двумя обязательными проверками для v3. Совпавшее имя, правильный путь и верная подпись не заменяют разрешение на конкретное действие.
  • Проверяемая квитанция отдельно хранит версию и ключ, расширение, область и свежесть CRL, путь, подпись, результат для целевого сертификата и старое исключение.

Условие в алгоритме иногда опаснее явного запрета. Запрет приводит к отказу. Условие может сделать так, что отсутствие обязательного поля вообще не станет событием.

Именно такая асимметрия оставалась между профилем сертификата и проверкой CRL в RFC 5280. Профиль требовал keyUsage и cRLSign, однако алгоритм говорил: если key usage присутствует, проверить бит. Сертификат с расширением без нужного бита отклонялся; сертификат без расширения мог миновать проверку.

RFC 10007, опубликованный в июне 2026 года как Standards Track, устраняет этот разрыв. Авторы — Corey Bonnell, Tadahiko Ito и Tomofumi Okubo; Bonnell указан первым. Это точная атрибуция вклада в коллективный документ IETF, а не утверждение о единоличном авторстве или контроле над реализациями.

Одинаковый субъект не переносит назначение ключа

В примере RFC центр сертификации поручает субъекту X выпуск косвенных CRL. Ключ A получает сертификат с keyUsage и cRLSign. Сертификаты, статус которых сообщает X, указывают DN X в cRLIssuer своего distribution point.

Тот же центр выдаёт X сертификат для ключа B. B предназначен для обычной задачи, поэтому в сертификате нет keyUsage. DN остаётся тем же, и путь B тоже может завершаться тем же trust anchor.

Если X подпишет CRL ключом B, математическая проверка пройдёт. Имя издателя совпадёт. Но сертификат B не удостоверял право B подписывать CRL. Полномочие ключа A не следует из имени X для любого другого ключа.

Это не спор о поддельной личности. Оба сертификата могут быть законно выданы одному субъекту. Разница проходит между «этот публичный ключ сертифицирован для X» и «этот публичный ключ X сертифицирован для действия Y».

Проверка присутствия и проверка значения

Section 4.2.1.3 RFC 5280 требует включать keyUsage как critical, когда сертификат применяется для проверки подписей сертификатов или CRL. cRLSign обозначает использование публичного ключа субъекта для проверки подписи списка отзыва.

Старый шаг section 6.3.3 проверял cRLSign, если расширение было. В автоматизации это превращает позитивное требование в необязательный тест. Система не находит отрицательного значения и сообщает успех, хотя не нашла и положительного разрешения.

RFC 10007 переписывает шаг для v3: проверить, что keyUsage присутствует, и проверить, что cRLSign установлен. Журналу нужны оба результата. Отсутствие расширения указывает на неправильный профиль либо неправильный выбор сертификата. Расширение без бита явно задаёт иное назначение.

Сведение обоих случаев к «key failed» теряет путь исправления. В одном случае требуется перевыпуск нужного сертификата; в другом, вероятно, выбран сертификат другого назначения.

Исключение старого формата нельзя расширять

В X.509 v1 и v2 нет поля extensions. Поэтому новая проверка присутствия к ним не применяется. Это ограничение формата, а не общее правило, разрешающее отсутствие keyUsage у v3. Применение исключения должно сохранять версию, policy, владельца и срок пересмотра.

После обновления возможна реальная несовместимость. Старый v3-сертификат мог использоваться для подписи CRL без keyUsage. Прежний валидатор принимает список, новый — отклоняет те же данные. Подпись не стала неверной; новый код начал проверять сертифицированное назначение.

RFC 10007 рекомендует CA включать расширение. Если профиль невозможно обновить, управляющая policy инстанция PKI должна потребовать уникальные DN для сертификатов разного назначения. Раздельные имена уменьшают неоднозначность, но не исправляют уже выданный сертификат и не назначают срок миграции.

Новый отказ может обнаруживать profile debt, а не ломать отзыв. Но сам по себе он не доказывает атаку, компрометацию ключа или ложное содержимое CRL. Доказано только отсутствие требуемого представления полномочия.

cRLSign не заменяет проверку отзыва

Даже при правильном бите остаются выбор издателя, путь, алгоритм и подпись, distribution point, issuing distribution point, косвенная CRL, critical extensions, thisUpdate и nextUpdate. Для complete и delta CRL требуется правильная связь.

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

Обратное тоже неверно: отсутствие полномочия не означает автоматически подделку CRL. Каждый результат имеет собственную юрисдикцию.

Подход Heng Lu к agency распределяет решения. Авторы задают общую грамматику, CA выбирает профиль, разработчик пишет running code, policy authority утверждает исключения, сервис несёт последствия. Minimum specification координирует смысл проверки, а миграция остаётся локальным выбором. Ни один участник не передаёт свою власть следующему молча.

Сохранить квитанцию, а не цвет индикатора

Фиксируются целевой сертификат, trust anchor, URI и hash CRL, время загрузки, thisUpdate, nextUpdate, алгоритм и версия валидатора. Выбранный сертификат издателя идентифицируется по serial, Subject Key Identifier, связанному Authority Key Identifier, DN и версии.

Отдельно записываются путь, подпись, условие v3, наличие и criticality keyUsage, состояние cRLSign. Исключение v1/v2 содержит policy, владельца, охват и дату review.

Область хранится отдельным блоком: distribution point, cRLIssuer, косвенная CRL, issuing distribution point, причины, связь complete/delta. Итоговый блок хранит serial цели, дату и причину отзыва, просроченные или отсутствующие данные и действие приложения.

Если версии расходятся, квитанция покажет пропущенный новый тест, иной выбранный сертификат или отказ на другой стадии. Один красный сигнал этого не объясняет.

Итоговое утверждение может быть узким: указанный валидатор обработал точную CRL с конкретным v3-сертификатом; нашёл keyUsage и cRLSign; отдельно получил результаты для пути, подписи, области, свежести и serial. RFC 10007 усиливает доверие тем, что не позволяет отсутствию притвориться полномочием.

Источники