Кратко

  • ES-T фиксировала раннее существование подписи; ES-C записывала ссылки на сертификаты и данные отзыва; ES-X сохраняла или защищала эти материалы; ES-A позволяла обновить оболочку до ослабления прежней защиты.
  • Долговечность зависела от точных байтов, сохранённых значений, применимой политики и своевременного обновления. Название формата не превращало метку времени в вечную истину.

Подпись оставалась, а среда проверки исчезала

Цифровые биты копируются без износа. Но сертификат истекает, старые CRL перестают публиковаться, OCSP-служба закрывается, сертификат TSA заканчивается, а алгоритм теряет приемлемость.

RFC 3126 вышла как Informational в сентябре 2001 года и поставила это расхождение в центр. Она продолжила policy-aware подпись RFC 3125 с помощью CMS, ESS, X.509, сведений отзыва и доверенных временных меток. Хранить требовалось не только значение подписи, но и причины первого решения о её действительности.

ES-T датировала существование, а не смысл

Базовая ES содержала подпись. ES-T добавляла к ней временную метку. Если подписант её не предоставлял, verifier должен был создать метку при первом получении либо сохранить защищённую запись времени первой проверки.

RFC 3161 ограничивает смысл: TSA подписывает message imprint и утверждает, что представленные данные существовали в определённый момент. Читать документ она не обязана. Поэтому метка не доказывает истинность текста, полномочия подписанта, соблюдение всей политики или результат сделки.

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

ES-C сохраняла рецепт проверки

ES-C строилась поверх ES-T и добавляла ссылки на путь сертификации и сведения отзыва. Поздний проверяющий мог определить, какие сертификаты, списки и ответы поддержали исходное решение.

Полный набор не всегда доступен в момент подписи. Публикация отзыва требует времени, временная приостановка — разрешения. Долговременное доказательство собиралось поэтапно.

Ссылка не равна значению. Если репозиторий исчез, идентификатор бесполезен. X-Long включала сами сертификаты и сведения отзыва. Это различие между каталогом и сохранённой книгой.

OCSP тоже давал узкий ответ. В RFC 2560 good, revoked и unknown описывали состояние в конкретное время. Good не доказывал остальные условия сертификата, полномочия подписанта или исполнение сделки.

ES-X защищала историю доказательств

ES-X решала задачи доступности и поздней компрометации. X-Long хранила значения. X-Time-Stamp типа 1 ставила метку на ES-C целиком, типа 2 — на ссылки сертификатов и отзыва; формы можно было сочетать.

Если ключ CA украли спустя годы, предъявленная во время спора цепочка сама по себе не показывала, существовала ли она до кражи. Ранняя временная оболочка вокруг validation data могла установить порядок при применимой политике.

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

ES-A превратила архив в обслуживание

ES-A учитывала старение самой защиты. До ослабления алгоритмов, ключей или сертификатов прежних меток подписанные данные, ES-C и ES-X следовало отметить вновь, желательно более сильным алгоритмом или длинным ключом. Процесс повторялся.

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

Бессмертия не было. Хранитель должен был обновить цепь, пока предыдущий слой ещё проверяем. Сломанный hash, скомпрометированный ключ TSA без надёжной временной границы или потерянные значения нельзя восстановить новой меткой. RFC 4998 позднее различила обычное обновление метки и обновление с новым хешированием.

Точные байты тоже были историческим объектом

RFC 3126 требовала одного и того же OCTET STRING при каждой проверке. Миграция архива могла разрушить доказательство без видимых изменений: нормализация строк, смена кодировки, утрата detached content или повторный экспорт меняли криптографический вход.

Долговременным объектом был комплект: байты, подпись, атрибуты, политика, путь, датированный статус, tokens, значения и обновления. Читаемый файл и поле «valid» не позволяли воспроизвести решение.

RFC 5126 заменила RFC 3126 и сохранила семейство CAdES-T, CAdES-C, CAdES-X и CAdES-A. Это показывает продолжение схемы, но не всеобщее внедрение версии 2001 года.

Долгий срок распределял ответственность

Подписант контролировал исходный акт. Verifier фиксировал время и данные. CA и status services давали ограниченные доказательства. TSA датировала imprint. Архивный хранитель сохранял и обновлял цепь. Поздний арбитр применял политику и внешний договорный или правовой инструмент.

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

Источники

  1. https://www.rfc-editor.org/rfc/rfc3126.txt
  2. https://www.rfc-editor.org/info/rfc3126
  3. https://datatracker.ietf.org/doc/rfc3126/
  4. https://www.rfc-editor.org/rfc/rfc3125.txt
  5. https://www.rfc-editor.org/rfc/rfc3161.txt
  6. https://www.rfc-editor.org/rfc/rfc2630.txt
  7. https://www.rfc-editor.org/rfc/rfc2634.txt
  8. https://www.rfc-editor.org/rfc/rfc2459.txt
  9. https://www.rfc-editor.org/rfc/rfc2560.txt
  10. https://www.rfc-editor.org/rfc/rfc4998.txt
  11. https://www.rfc-editor.org/rfc/rfc5126.txt
  12. https://www.rfc-editor.org/rfc/rfc5652.txt