Кратко

  • RFC 9654 требует от современного клиента nonce длиной не менее 32 октетов, созданный криптографически стойким генератором; точное эхо связывает ответ с данным запросом и мешает подменить его старым ответом с другим значением.
  • Совпадение не доказывает, что ответчик получил новейшие сведения об отзыве, что подписант уполномочен, CertID указывает нужный сертификат, временное окно приемлемо или приложение должно разрешить соединение.
  • Воспроизводимая квитанция раздельно хранит байты запроса и ответа, генерацию и сравнение nonce, полномочие подписанта, идентификатор сертификата, подписанные времена, водяной знак источника, политику валидатора и действие приложения.

Доказанное и недоказанное после инцидента

Совпавший nonce отвечает на важный вопрос: этот ответ относится к этому запросу или является другой сохранённой копией? RFC 9654 помещает значение в requestExtensions, а при возврате — в responseExtensions, под OID 1.3.6.1.5.5.7.48.1.2.

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

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

Диапазон 1–128 состоит из разных зон

Тип Nonce допускает от 1 до 128 октетов. Клиент, реализующий RFC 9654, обязан использовать минимум 32. Поддерживающий расширение ответчик обязан принимать от 16 до 32. При длине 1–15 или 33–128 он может ответить без nonce. Ноль или больше 128 требует malformedRequest.

Следовательно, 128 — верхняя граница синтаксиса, а не обязательная рекомендация. RFC 8954 ограничивал значение 32 октетами, и старую реализацию нельзя считать совместимой с более длинными вариантами.

Матрица испытаний должна включать 16, 32, 33 и 128, а также недопустимые 0 и 129. Для каждого случая сохраняются три возможных результата: ответ с эхом, ответ без эха, отказ. Общий показатель «успех» уничтожает смысл границ.

Внешний OCTET STRING и внутренний Nonce

RFC 9654 уточняет кодирование. extnValue расширения — внешний OCTET STRING, внутри которого закодирован Nonce, тоже OCTET STRING. Пример на 32 октета показывает обе оболочки.

Парсер может обнаружить правильный OID, но сравнить внешнюю структуру с внутренним значением. Журнал может усечь шестнадцатеричную строку. Текстовый адаптер может нормализовать представление и потерять исходные байты. Поэтому факт присутствия расширения слабее точной проверки.

Квитанция хранит полный DER запроса и ответа, их хеши, смещения расширения, внешнюю и внутреннюю длину и результат побайтового сравнения. Реестр IANA фиксирует идентификаторы ASN.1-модулей 111 и 112, но не подтверждает поведение конкретной загруженной библиотеки.

Длина не создаёт непредсказуемость

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

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

«32 байта» подтверждает формат. «Новое непредсказуемое значение для этой операции» подтверждает защитное свойство. Примат работающего кода требует фактической телеметрии второго утверждения.

Новый ответ может основываться на старом снимке

RFC 9654 говорит, что включение nonce клиента обеспечивает самый свежий ответ сервера, а не старую копию. Речь идёт об ответе данного сервера. Состояние канала, по которому сервер получает сведения от CA, этим не удостоверяется.

RFC 6960 различает producedAt, thisUpdate, nextUpdate и revocationTime. Время подписи, время известной корректности статуса, обещание новой информации и время отзыва — разные факты. CertID связывает запись с хешами издателя и серийным номером.

Если CA публикует отзыв в 15:00, а реплика ответчика получает его в 15:09, в 15:04 ответчик может создать новый подписанный ответ с правильным nonce из своей запаздывающей базы. Обмен свежий; источник отстаёт. Для доказательства актуальности нужны курсор ленты, версия пакета, время применения или эквивалентная квитанция.

Полномочие подписи тоже независимо. По RFC 6960 подписывает выдающая CA, прямо доверенный ответчик либо делегат с нужным сертификатом от CA. Nonce не создаёт это полномочие. Статус good не доказывает факт выдачи, период действия, имя сервиса или разрешение приложения.

Отсутствие запускает временной путь

RFC 5019 рассчитан на большие объёмы, предварительное производство и кеширование. Уникальный ответ на каждый запрос уменьшает повторное использование. Поэтому ответчик может не вернуть nonce, даже если клиент его отправил.

Если клиент не знает наверняка о поддержке, он не должен отвергать ответ только из-за отсутствия, а переходит к проверке подписанного времени. RFC 9654 указывает остаточную атаку: посредник может вернуть прежний ответ сервера без nonce. Короткий интервал между thisUpdate и nextUpdate сужает окно.

Это отдельный режим, а не совпадение. Мониторинг различает точное эхо, допустимое отсутствие с временным fallback, несовпадение и ошибку формата. Для каждой ветви сохраняется дальнейший результат проверки и действие приложения.

Восстановимая цепочка решения

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

Слой связывания содержит присутствие и точное равенство. Слой статуса — CertID, статус, времена и поля отзыва. При возможности отдельно хранится водяной знак исходной ленты. Локальное решение добавляет часы, неопределённость, допуск, сборку и версию политики. Приложение завершает запись результатом пути, имени, допуска или отказа и действием сессии.

Слои реальности не позволяют одному убедительному факту заменить последующие. Минимальная начальная спецификация стандартизирует только необходимые общие правила, оставляя загрузку данных, масштабирование и принятие риска видимым ответственным сторонам.

Источники