Кратко

  • RFC 9919 разрешает заранее готовить ответы OCSP и кэшировать их у клиентов, прокси и серверов, но считает заголовки HTTP лишь подсказками: криптографической защиты на них нет.
  • Клиент связывает ответ с сертификатом, проверяет подпись и полномочия подписанта, затем сопоставляет подписанные thisUpdate и nextUpdate с точными локальными часами.
  • Свежее good — ограниченное свидетельство отсутствия отзыва. Оно само по себе не доказывает выдачу, полную действительность сертификата, прикладные полномочия или результат операции.

Экономия запроса не означает новый ответ

Подписывать отдельный ответ для каждого запроса дорого в среде с миллионами сертификатов. RFC 9919 заменяет RFC 5019 и опирается на предварительную подготовку, уменьшение сообщений, GET для коротких запросов и повторное использование одной подписанной копии в нескольких слоях.

В результате появляются две «свежести». HTTP определяет, можно ли снова отдать сохранённое представление. OCSP определяет, остаётся ли утверждение уполномоченного ответчика внутри подписанного временного интервала. Expires, ETag и Cache-Control помогают доставке, но не входят в подпись OCSP.

RFC 9919 прямо указывает: значения заголовков можно изменить, поэтому они служат только руководством для кэширования. Окончательное решение основывается на значениях внутри подписанного OCSPResponse. Попадание в кэш подтверждает источник байтов, но не повторную проверку статуса в этот момент.

Три поля времени и часы проверяющей стороны

thisUpdate показывает, когда ответчик знал указанный статус как правильный. nextUpdate обозначает время, когда или до которого появится более новая информация. producedAt — время подписи ответа. При предварительной подготовке значения могут совпасть, но их смысл остаётся разным.

Для лёгкого профиля nextUpdate обязательно. Клиент отвергает ответ без него и проверяет, что текущее GMT находится между thisUpdate и nextUpdate. После границы ответ устарел. Небольшой локальный допуск может учитывать расхождение часов, однако его выбирают по реальной точности синхронизации и фиксируют в журнале.

Спешащие часы слишком рано отвергают ещё свежий ответ и создают отказ в доступности. Отстающие продолжают принимать просроченное good, хотя новый ответ уже может содержать revoked. Подпись в обоих случаях бывает безупречной. Целостность сообщения не исправляет ошибочное текущее время.

Nonce криптографически связывает запрос с ответом. Но профиль должен поддерживать временную проверку и в предусмотренных случаях не отвергать ответ лишь из-за отсутствия ожидаемого nonce. Поэтому часы, смещение, допуск, окно и поведение nonce составляют одну воспроизводимую проверку.

max-age сдвигает обновление, nextUpdate закрывает окно

RFC 9919 помещает HTTP max-age после thisUpdate, но до nextUpdate. Клиенты начинают обновление заранее, а ответчик должен подготовить новую копию до этой точки. Так владельцы популярного сертификата не создают одновременный пик.

Это управление нагрузкой, а не продление статуса. Прокси способен изменить внешний заголовок, не затронув подписанный объект. После nextUpdate ответ нельзя использовать, каким бы свежим ни выглядел HTTP. Если промежуточный кэш продолжает отдавать просроченную копию, клиент может обойти его в новом запросе. Старый ответ от этого не обновляется.

При OCSP stapling в TLS действует та же граница. Вложение сокращает round trips и прямые обращения, но handshake не продлевает ответ. CertID, подписант, статус и интервал проверяются в самом объекте OCSP.

successful не означает good, а good не означает всё

Верхний successful говорит, что инфраструктура OCSP располагает авторитетными записями и может ответить. Для конкретного сертификата существуют good, revoked и unknown. Это разные уровни результата.

RFC 6960 ограничивает и good: как минимум не отозван сертификат с запрошенным серийным номером, находящийся в своём периоде действия. Это не обязательно доказывает, что сертификат вообще выдавался или что ответ создан в период его действия. Путь X.509, имя, назначение и локальная авторизация проверяются отдельно.

До принятия клиент подтверждает соответствие CertID, проверяет подпись и право подписанта отвечать за данный УЦ. Воспроизводимая квитанция хранит хэш ответа, подписанта и цепочку полномочий, алгоритм, индивидуальный статус, producedAt, thisUpdate, nextUpdate, время сравнения, смещение, допуск и nonce. HTTP age, max-age, Expires, ETag, ревалидация и обход кэша идут отдельной дорожкой. Решение приложения и фактический эффект — следующие записи.

RFC 9919 также требует SHA-256 для хэшей издателя в CertID. Старые клиенты RFC 5019 временно используют SHA-1, но должны перейти. Их доля показывает наследуемую зависимость, а не корректность свежести.

Источники