Кратко

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

Подлинный ответ, утративший право решать

Кэш может вернуть ответ OCSP без единого изменённого бита. Подпись проверяется, структура правильная, состояние равно good. Но если локальное время позже nextUpdate, RFC 9919 требует считать ответ устаревшим.

Профиль рассчитан на PKI с миллионами сертификатов и ещё большим числом полагающихся сторон. Предварительное производство, уменьшение сообщений, кэширование у клиента и в сети, а также передача ответа внутри другого протокола сокращают нагрузку и количество соединений. Респонденту не приходится генерировать отдельный ответ для каждого сеанса.

Масштабирование опирается на ограниченный срок. thisUpdate — последнее время, когда респондент знал состояние как верное. producedAt — время подписи. nextUpdate — срок появления более новой информации. В RFC 9919 он обязателен: без него ответ отвергается, после него — тоже.

Криптографическая подпись может оставаться корректной годами. Она связывает уполномоченного подписанта с содержанием, но не превращает прошлое состояние в постоянное разрешение. Между выпуском и повторным использованием сертификат мог быть отозван.

good не равен полной пригодности сертификата

RFC 6960 определяет good, revoked и unknown. Минимальный смысл good: респондент не знает сертификат с запрошенным серийным номером в пределах срока действия как отозванный. Ответ не обязательно доказывает, что сертификат вообще был выдан. Он не заменяет проверку срока сертификата, цепочки, имени сервиса или авторизации приложения.

До принятия подписанного ответа клиент сопоставляет идентификатор с нужным сертификатом, проверяет подпись, полномочие подписанта отвечать за соответствующий CA и временную актуальность. Остальная проверка сертификата и приложения остаётся отдельной.

Фраза «OCSP прошёл» скрывает эти переходы. Доступность сервиса, окончательный статус, корректная подпись, полномочие респондера, свежесть, принятие сертификата и открытие сеанса — разные факты. Одного зелёного показателя недостаточно для расследования.

Часы клиента входят в доказательство

Nonce на каждый запрос мешает предварительному производству и общему кэшу. Поэтому RFC 9919 обычно не рекомендует расширения запроса. Если клиент послал nonce, а ответ его не содержит, он, как правило, не отклоняет ответ только поэтому, если поддержка nonce респондентом не известна; вместо этого проверяет время.

Клиент обязан иметь точный источник времени и определить, что текущий момент находится между thisUpdate и nextUpdate. Небольшой допуск возможен для расхождения часов, но выбирается по реальной точности среды. Это не универсальный бесплатный запас.

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

У HTTP и OCSP разные понятия свежести

Небольшие запросы используют GET, чтобы кэширование работало. Респондент добавляет Date, Last-Modified, Expires, ETag и Cache-Control. max-age распределяет обновления до nextUpdate, а must-revalidate не позволяет кэшу намеренно выдавать устаревшее представление.

RFC 9919 прямо говорит: HTTP-заголовки не защищены криптографически. Они управляют доставкой. Авторитет состояния определяется подписанными полями OCSP. Более поздний Expires не переносит nextUpdate, а HTTP-свежесть не отменяет проверку приложением.

Если посредник застрял на старом объекте, клиент может повторить запрос в обход кэша. Новый ответ всё равно проходит сопоставление сертификата, проверку полномочия, подписи, состояния и времени.

TLS stapling также меняет лишь путь доставки. TLS-сервер приносит ответ клиенту, но не становится автором статуса. Решение остаётся локальным.

SHA-256 исправляет один участок

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

Однако SHA-256 не доказывает свежесть. Ответ с современным идентификатором может истечь. Сильная подпись может принадлежать респонденту без полномочия для этого CA. Исправный кэш может доставить данные клиенту с неверными часами. Миграция алгоритма не является приёмкой всей цепочки.

Сохранить квитанцию решения

Квитанция включает отпечаток и серийный номер сертификата, хэши имени и ключа издателя и алгоритмы, точные байты OCSP и их хэш, идентификатор респондера, цепочку и полномочие подписанта, producedAt, thisUpdate, nextUpdate, состояние и поля отзыва.

К ней добавляются время приёма, источник и неопределённость локальных часов, допуск, обработка nonce, версия и политика валидатора, причина принятия или отказа и последующее действие приложения. Узел кэша, Age, ETag, Expires, обход и повторный результат остаются доказательством доставки, а не подписанного статуса.

Уровни не смешиваются: HTTP показывает путь байтов; OCSP — что и на какой срок заявил уполномоченный респондент; локальный журнал — почему принято решение; приложение — что произошло дальше. Счётчик успеха не заменяет ни одной связи.

Источники