Кратко

  • Новые клиенты облегчённого профиля RFC 9919 обязаны применять SHA-256 к хешам имени и ключа издателя в CertID; старые клиенты, совместимые с RFC 5019, должны уйти с SHA-1, как только это практически возможно.
  • На переходный период респондер может поместить в один ответ SingleResponse с SHA-1 и SHA-256. Журнал алгоритмов клиентских запросов способен помочь решить, когда старый вариант больше не нужен.
  • Такой журнал видит лишь запросы, дошедшие до измеряемого входа. Клиентский и прокси-кэш, заранее выпущенные ответы, stapling, другой респондер и внепротокольные соглашения могут оставить зависимость за границей измерения.
  • SHA-1 в CertID используется для идентификации контекста издателя проверяемого сертификата, а не как алгоритм подписи OCSP-ответа.
  • Для завершения нужен проверяемый акт: точки наблюдения, знаменатель, политика двойного ответа, критерий остановки, владелец решения, canary, fallback, срок исключения и результат после переключения.

Когда источник молчит

Точный смысл нулевого показания ограничен: за выбранный интервал классификатор не увидел SHA-1 на выбранной точке. Вывод о нуле старых клиентов требует доказать, что вся аудитория могла появиться в этой точке и что каждое использование ответа порождало новое обращение.

RFC 9919 проектировался с противоположной целью — уменьшить число обращений. Ответы могут выпускаться заранее. Клиент хранит авторитетный ответ локально, HTTP-посредник переиспользует его, сервер раздаёт подготовленный объект. При stapling или piggybacking ответ приходит внутри другого протокольного обмена, без отдельной HTTP-сессии с OCSP-респондером.

Потоки также расходятся по регионам, резервным инстансам, закрытым сетям и fallback-маршрутам. Сам OCSP не сообщает возможности респондера внутри протокола, поэтому профиль иногда выбирают по внепротокольной договорённости операторов. Эти договорённости и редко активные устройства не перечислены в access log.

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

Какую именно совместимость снимает RFC 9919

RFC 5019 требовал SHA-1 для issuerNameHash и issuerKeyHash. RFC 9919 отменяет старый профиль и требует SHA-256 от новых соответствующих клиентов. Старые клиенты могут временно продолжать SHA-1 ради совместимости, но должны перейти при первой практической возможности.

Респондер может обслужить обе стороны. Обычно ответ содержит один SingleResponse, однако дополнительные элементы допускаются ради предварительного выпуска, эффективности кэша и обратной совместимости. Прямой пример RFC 9919 — один CertID с SHA-1 и второй с SHA-256. Если клиентов SHA-1 больше нет, старый вариант не следует распространять. Алгоритм, замеченный в запросах, можно учитывать при принятии решения.

Стандарт не задаёт универсального числа тихих дней, доли остаточного трафика или глобального знаменателя. Эти параметры должен обосновать оператор, который меняет production.

Структура RFC 6960 предотвращает ещё одну ошибку. CertID.hashAlgorithm задаёт хеширование имени и открытого ключа издателя, а серийный номер обозначает сертификат. BasicOCSPResponse.signatureAlgorithm — отдельное поле. Раздел 8.7 RFC 9919 не считает SHA-1 в таком расчёте CertID самостоятельной криптографической угрозой. Издержка состоит в необходимости сохранять программную поддержку, сложность и потенциальную поверхность атаки.

Поэтому снятие этой ветки нельзя без дополнительного доказательства называть прекращением подписей OCSP на SHA-1.

Инвентаризация видимости

В знаменатель входят инстансы, hostnames, регионы, сетевые пути, семейства сертификатов и группы клиентов. Для каждого нужно отметить видимость прямых запросов, revalidation кэша, прокси-доставки, stapling, offline-использования и fallback. «Не наблюдается» не превращается в «мигрировал».

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

Неизмеряемую группу можно исключить лишь явно: с ответственным лицом, основанием и датой повторной проверки. Тогда неизвестность остаётся видимой для принимающего решение.

Акт, который завершает исключение

В документе фиксируются scope и владелец; точки наблюдения и знаменатель; перечень SHA-1-исключений; политика одного или двух ответов; охват кэшей и stapling; интервал и критерий остановки. Затем — аудитория и срок canary, условие rollback, рабочий fallback и дата автоматического окончания исключения без нового одобрения.

После cutover в акт добавляются вернувшиеся SHA-1-запросы, ошибки респондера, сбои проверки, активация fallback, затронутые сертификаты и влияние на сервис. Только результат превращает разрешение на изменение в завершённую запись.

IETF задаёт совместимое поведение, но не управляет каждой производственной средой. Владелец изменения должен владеть доказательством и последствиями. Совместимость не должна жить вечно из-за отсутствия хозяина — и не должна исчезать из-за одного тихого графика.

Источники