Кратко

  • EvidenceRecord сохраняет существование и целостность конкретных данных, однако вспомогательное поле cryptoInfos само не защищено архивной отметкой времени и требует внешней проверки.
  • RFC 5276 точно связывает доказательство с ответом SCVP, но не превращает вложенные сертификаты, якоря или вывод сервера в обязательную политику для любого приложения.

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

Но RFC 4998 проводит неудобную границу: cryptoInfos может хранить все эти полезные материалы, однако само поле не защищается отметкой времени. Его содержимое должно подтверждаться другими механизмами. Якорь в контейнере — это ещё не доказательство того, что именно этот якорь находился там в нужный момент, что он происходит из доверенного источника или что приложение обязано его принять.

RFC 5276 строит более строгую связь для ответов SCVP. EvidenceRecord должен покрывать конкретный сертификат, путь или сведения об отзыве. Эта точность позволяет увидеть, где доказательство заканчивается, а контекст начинается.

Карта покрытия важнее состава папки

SCVP использует WantBack, чтобы клиент запросил дополнительные материалы. RFC 5276 вводит запросы EvidenceRecord для конечного сертификата, полного пути, частичного пути и сведений об отзыве.

Для полного или частичного пути доказательство вычисляется по DER-кодированному CertBundle в соответствующем ответе. Для отдельного сертификата оно покрывает значение сертификата в CertReply. Для CRL и ответов OCSP требуется сопоставление каждого элемента с EvidenceRecord; один Record может покрывать несколько элементов, если хеш элемента найден в первой архивной отметке.

В сводной форме targetWantBack называет тип покрытого ответа. Между прочими ответами WantBack и элементами коллекции требуется соответствие один к одному. Поэтому аудитор может проверить не просто наличие доказательства, а его область.

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

Пустое поле сохраняет неопределённость

Если сервер не может вернуть запрошенный EvidenceRecord, RFC 5276 требует ответ соответствующего типа с пустым значением. В сводной форме поле доказательства для цели отсутствует. Если клиент запросил доказательство, но не запросил покрываемый материал, WantBack считается неудовлетворённым.

Это не отрицательный статус сертификата. Это отсутствие требуемого доказательства сохранности. И обратное тоже верно: успешно проверенный EvidenceRecord не отменяет отзыв и не делает путь приемлемым для приложения.

Система должна разнести статусы: запрос понят; материал возвращён; доказательство возвращено; доказательство проверено; путь принят по политике; действие разрешено приложением. Один итоговый флаг уничтожает смысл пустого поля и провоцирует ложный вывод.

Неопределённость здесь полезна. Она показывает, какую связь нужно восстановить или какую оговорку нужно донести, не объявляя весь архив достоверным или бесполезным.

Частичный путь не содержит конечный сертификат

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

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

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

Оптимизация хранения допустима только вместе с переносимой схемой сборки. Иначе система сохраняет компоненты, но теряет решение.

Якорь — вход политики

RFC 5280 определяет якорь доверия как вход алгоритма проверки пути. Разные приложения могут использовать разные якоря и дополнительные ограничения. Валидность пути под одним набором входов не является всемирным полномочием.

RFC 5055 позволяет запросу SCVP задавать политику, время, якоря, использование ключа, расширенное использование и параметры проверки отзыва. Короткий запрос может полагаться на настройки сервера. Для последующего воспроизведения необходимо сохранить полную политику или стабильную ссылку вместе с действовавшими параметрами.

RFC 5276 требует проверять подпись ответа SCVP открытым ключом, которому доверяет полагающаяся сторона. Ответ может содержать якоря для внутренних слоёв ERS, однако получатель вправе их игнорировать и использовать якоря из внешнего канала. Якоря в неподписанном ответе не следует принимать только по факту присутствия.

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

Исторический статус не закрывает поток знаний

validationTime позволяет SCVP оценить сертификат в прошлом. Если подходящих исторических данных нет, сервер должен вернуть ошибку. Это полезно для подписи, сделанной до истечения сертификата.

Однако RFC 5055 предупреждает: позднее может появиться сообщение об отзыве с invalidityDate, предшествующей исходному времени проверки. Старый положительный ответ может быть подлинным, корректно сохранённым и соответствовать знаниям того дня — и всё же перестать быть достаточным сегодня.

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

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

EvidenceRecord — обновляемая конструкция

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

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

Отдельно нужно инвентаризировать cryptoInfos: какие элементы там находятся, чем подтверждается их происхождение и какие из них действительно покрыты другим доказательством. Формулировка «хранится внутри EvidenceRecord» слишком широкая и может быть фактически неверной для области защиты.

Досье с явными краями

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

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

RFC 5276 не доказывает внедрение конкретного продукта, юридический эффект или распространённость SCVP. Он даёт проверяемый формат отношений, из которого нельзя честно вывести больше, чем покрыто.