Кратко

  • RFC 10007 обновляет RFC 5280: для сертификата v3 издателя CRL валидатор должен потребовать наличие keyUsage и установленный бит cRLSign.
  • Совпавшее имя субъекта, путь к тому же якорю доверия и правильная подпись не переносят назначение ключа A на другой ключ B.
  • Строгая проверка может отвергнуть старые v3-сертификаты, предназначенные для CRL, но выпущенные без расширения; CA исправляет выпуск, а полагающаяся сторона управляет переходом и доказательством покрытия.

Когда откат возвращает не совместимость, а старую дыру

В примере RFC 10007 удостоверяющий центр выдает субъекту X сертификат ключа A с расширением keyUsage и битом cRLSign. Затем тот же X получает сертификат другого ключа B для обычной задачи, без keyUsage.

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

Карточка RFC 10007 фиксирует публикацию Standards Track в июне 2026 года и обновление RFC 5280. Старый текст RFC 5280 требовал проверять cRLSign, если расширение присутствует. При отсутствии расширения проверка назначения могла не выполняться. При этом информация о RFC 5280 относится к профилю, который уже обязывал совместимые CA добавлять расширение для ключей проверки подписей сертификатов или CRL.

RFC 10007 устраняет разрыв: для v3 проверяются и наличие расширения, и бит. У сертификатов v1 и v2 нет поля расширений, поэтому новая проверка наличия к ним не применяется.

Субъект — не отпечаток ключа

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

RFC 4514 задает строковое представление distinguished name для LDAP; его карточка не превращает DN в идентификатор открытого ключа. Под одним именем могут законно существовать сертификаты для почты, документов, аутентификации и отзыва.

RFC 5280 разделяет digitalSignature, keyCertSign и cRLSign. Последний предназначен для проверки подписей CRL, delta CRL и списков отзыва центров. Способность алгоритма создать подпись не заменяет сертифицированное назначение.

RFC 10007 в Datatracker, история документа, устав LAMPS и история группы подтверждают рассмотрение и публикацию. Они не показывают поддержку конкретным продуктом или распространенность внедрения.

Косвенный CRL соединяет несколько доказательств

Издатель косвенного CRL может отличаться от CA проверяемого сертификата. Точка распространения сертификата указывает cRLIssuer; критическое расширение списка issuingDistributionPoint утверждает indirectCRL и ограничивает область.

Полагающаяся сторона отдельно проверяет имя, косвенную роль, область, путь, якорь, подпись, назначение, время и покрытие причин. RFC 10007 исправляет назначение. Верный cRLSign не доказывает содержание, свежесть, полноту или доступность списка.

RFC 3647 разделяет CA, регистрационный центр, репозиторий, подписчика и полагающуюся сторону, а также политику, практику, аудит и сервис статуса. Его карточка не позволяет спрятать все эти обязанности за одной криптографической проверкой.

Исправление обнаруживает наследованный дефект

RFC 10007 прямо предупреждает: обновленное приложение не сможет проверить CRL, если сертификат v3 его издателя предназначался для этой работы, но был выпущен без keyUsage. Намерение могло быть законным; профиль сертификата — нет.

CA должна провести учет, исправить шаблон, перевыпустить сертификат, обеспечить период перекрытия и доказуемо вывести старый. Если профиль изменить невозможно, policy management authority должна развести DN по назначениям. Это уменьшает описанную коллизию, но не заменяет явное назначение, хранение ключа, область и свежесть.

Отказ CRL не доказывает отзыв целевого сертификата. Этот материал не принят, и статус может остаться неопределенным. Превращать такой результат всегда в «действителен» небезопасно, всегда в «отозван» — необоснованно.

У OCSP собственная делегация. RFC 6960 допускает подпись CA, локальную настройку или сертификат делегата с id-kp-OCSPSigning при заданной связи выпуска; его карточка описывает другой механизм. RFC 6818 и информация о нем показывают более раннее обслуживание RFC 5280, а не автоматическое обновление работающих систем.

Узкое правило и локальное внедрение

Принцип Lu Heng о приоритете работающего кода отделяет публикацию от эксплуатации. Его рамка минимальной спецификации, локализованного решения и добровольного принятия оставляет в общем слое детерминированные, локально проверяемые инварианты, а порядок внедрения — участникам.

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

Источники