Кратко

  • Токен RFC 3161 связывает хеш данных со временем, политикой и ключом, но не содержит полного доказательства того, как служба соблюдала эту политику в момент подписи.
  • RFC 3628 разделил политику и практику, потребовал прослеживаемость до UTC(k), остановку при потере синхронизации, один активный ключ на TSU, аудит и раскрытие инцидентов. Действующий ETSI сохраняет эту границу.
  • Для долгой проверки нужны точные байты токена, версия практики, история часов и ключа, граница затронутых меток, состояние доверенного списка, оценка алгоритмов и события сохранения.

Зелёный результат имеет дату

RFC 3161 задаёт строгую структуру. messageImprint должен совпадать с хешем запроса. Серийный номер обязан быть уникальным у TSA даже после перебоя. genTime фиксирует время создания токена службой. Поле политики называет набор правил. Запрошенный nonce возвращается. Подпись и идентификатор сертификата подписанта привязывают ответ к ключу.

Это доказывает существование представления данных не позднее заявленного времени в пределах описанных условий. Но токен не подтверждает истинность, полноту, законность или авторство исходного материала. genTime не является временем создания у клиента, приёма другим сервером или принятия приложением. Необязательная точность превращает момент в интервал. Если ordering не установлен, порядок двух токенов одной TSA надёжен лишь тогда, когда интервалы точности не пересекаются.

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

После срока действия доказательство меняет форму

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

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

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

Политика называет, практика объясняет

RFC 3628 опубликован как Informational RFC в 2003 году и был технически эквивалентен спецификации ETSI своего времени. Он не является текущим Internet Standard и не охватывает в одиночку современное соответствие. Но его центральное разделение остаётся полезным: политика говорит, что должно соблюдаться; заявление о практике TSA описывает, как конкретный поставщик делает это в своей организации, помещениях и системах.

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

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

Буква Z не сохраняет UTC(k)

RFC 3628 требовал, чтобы время токена было прослеживаемо к значению реального времени, распространяемому лабораторией UTC(k), и находилось в пределах заявленной точности. Национальные институты и назначенные лаборатории поддерживают локальные реализации UTC(k). BIPM вычисляет UTC и публикует разности UTC и UTC(k) в ежемесячном Circular T — окончательном источнике прослеживаемости.

Rapid UTC, или UTCr, выходит еженедельно и помогает оперативному управлению. BIPM подчёркивает, что UTCr дополняет UTC, но не заменяет окончательные результаты и прослеживаемость Circular T. Быстрый ориентир и окончательное сравнение — разные доказательства.

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

Ссылки тоже стареют. RFC 3628 ссылался на ITU-R TF.460-5, которая заменена; действует TF.460-6. ETSI EN 319 421 V1.3.1, принятый в 2025 году, использует актуальную редакцию. Неизменный номер политики не останавливает эволюцию зависимостей.

Потеря синхронизации должна лишать права подписи

RFC 3628 требовал обнаруживать дрейф или скачок за пределы заявленной точности. После обнаружения TSU должна прекратить выпуск и восстановиться до возобновления. Текущий ETSI сохраняет это: защита от незамеченных изменений, журнал нормальной синхронизации, перекалибровки и её потери, остановка выдачи и проверенное восстановление.

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

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

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

Один активный ключ — факт эксплуатации

RFC 3628 определил Time-Stamping Unit как совместно управляемые аппаратные и программные средства с одним активным ключом подписи меток в каждый момент. TSA может иметь несколько различимых TSU, но у каждой своя граница. ETSI EN 319 421 V1.3.1 сохраняет один активный ключ, доверенные роли, двойной контроль, защищённое криптографическое устройство, исключительное назначение и автоматический отказ после окончания эксплуатационного срока закрытого ключа.

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

RFC 5816 добавил ESSCertIDv2 и обновил привязку к сертификату подписанта для современных хешей. Это важное обслуживание криптографии, но церемония, исключительность и история ключа остаются вне токена.

Инциденту нужна граница населения

RFC 3628 требовал сообщать о компрометации, подозрении на неё или потере калибровки, прекращать выпуск до восстановления и по возможности давать сведения для определения затронутых токенов. ETSI EN 319 421 V1.3.1 продолжает ту же логику и отдельно требует журналы ключей, сертификатов, нормальной синхронизации, перекалибровки и потери синхронности.

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

Журнал аудита способен отделить настоящие токены от ложных задним числом после утечки ключа. Две независимые TSA дают дополнительное наблюдение. Но независимость нужно доказывать: они могут пользоваться одним источником времени, криптопоставщиком или оценщиком.

Квалифицированный статус тоже историчен

Regulation (EU) No 910/2014 даёт квалифицированной электронной метке презумпцию точности даты и времени и целостности связанных данных. Commission Implementing Regulation (EU) 2025/1929 называет, с адаптациями, ETSI EN 319 421 V1.3.1 и EN 319 422 V1.1.1 опорными стандартами презумпции соответствия.

Но квалифицированное утверждение в токене — лишь указание на заявление. ETSI ожидает, что relying party установит статус через соответствующий доверенный список. Надзорный статус, оценка соответствия и снимок списка на нужную дату находятся вне токена.

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

Минимальный архив больше самого токена

Долговечный набор включает точные байты токена и их хеш; версии политики, практики и раскрытия; цепочку сертификатов и доказательства статуса; источник UTC(k), измерения синхронизации и Circular T; жизненный цикл ключа; сообщения об инцидентах; доверенный список при квалификации; оценку алгоритмов; последующие события сохранения; собственное решение relying party.

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

Когда сертификат истёк, проверка не закончилась. Просто изменился вопрос: теперь нужно доказать, почему старому результату всё ещё можно доверять после исчезновения первоначального оперативного контекста.

Источники

  1. RFC 3628 — Policy Requirements for Time-Stamping Authorities
  2. RFC 3628 plain text
  3. RFC Editor information for RFC 3628
  4. IETF Datatracker record for RFC 3628
  5. RFC 3628 errata search
  6. RFC 3161 — Time-Stamp Protocol
  7. RFC Editor information for RFC 3161
  8. IETF Datatracker record for RFC 3161
  9. RFC 3161 with inline errata
  10. RFC 5816 — ESSCertIDv2 Update for RFC 3161
  11. RFC Editor information for RFC 5816
  12. IETF Datatracker record for RFC 5816
  13. ETSI EN 319 421 V1.3.1
  14. ETSI EN 319 422 V1.1.1
  15. BIPM Circular T
  16. BIPM Coordinated Universal Time
  17. BIPM Rapid UTC
  18. ITU-R Recommendation TF.460
  19. ITU-R Recommendation TF.536-2
  20. Consolidated Regulation (EU) No 910/2014
  21. Commission Implementing Regulation (EU) 2025/1929
  22. Lu Heng — Running Code Primary
  23. Lu Heng — Minimum Initial Specification
  24. Lu Heng — On Reality Layers
  25. Lu Heng — On Authority and Belief