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

Spec Spec: ETSI EN 319 142-1 ETSI EN 319 142-1 Spec Spec: RFC 6960 RFC 6960 Spec Spec: ISO 32000-2, §12.8.4 ISO 32000-2 §12.8.4 Evidence § Standard-backed Evidence: Standard-backed

Кратко

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

Почему это важно

Опасное свойство цифровой подписи в том, что она может незаметно перестать быть проверяемой, хотя внешне останется неизменной. В самом файле ничего не меняется. Удостоверяющий центр перестаёт отвечать на запросы о давно истёкшем сертификате. Средство проверки, которому нужен этот ответ, уже не может его получить. Договор, который в день подписания был безусловно действительным, спустя десятилетие превращается в “невозможно определить”. Именно через десятилетие спор наиболее вероятен, а ставки выше всего. Если срок вашего обязательства по хранению измеряется годами, подпись без долгосрочной проверки — риск, который проявится только потом.

Если коротко

• Действительность подписи зависит от внешних фактов, привязанных ко времени: окна действия сертификата и статуса отзыва, получаемого с сервера.
• После истечения срока действия сертификата эти факты становятся недоступными — удостоверяющие центры не обязаны отвечать вечно.
• Долгосрочная проверка фиксирует свидетельства в момент подписания — сертификаты, ответы OCSP, списки CRL — и встраивает их в хранилище безопасности документа (DSS).
• Затем метка времени документа доказывает, что сами свидетельства существовали и были действительны в тот момент; её можно обновить, прежде чем ослабнет её собственная защита.
• В итоге документ несёт в себе собственное доказательство. Проверка больше не зависит от того, остался ли сервер доступным.

Как это устроено в NextPDF

Принцип таков: “соберите доказательства, пока ещё можете, а затем скрепите их”. Создавая долгосрочную подпись, NextPDF собирает цепочку сертификатов и ответы об отзыве, которые доказывают, что сертификат подписи был действителен в момент подписания. Они записываются в DSS как встроенные значения, а не как ссылки. Затем поверх всего этого добавляется метка времени документа. Смысл именно во встроенных значениях. Ссылка на сервер отзыва — та самая зависимость, ради устранения которой и существует долгосрочная проверка.

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

1. Sign The signature and its signed attributes are written (B-B).
2. Capture evidence Certificate chain, OCSP responses, and CRLs proving the certificate was valid at signing time are gathered.
3. Embed in the DSS The evidence is written into the document as embedded values, not links (B-LT).
4. Seal with a document timestamp A timestamp proves the embedded evidence existed and was valid at that moment (B-LTA).
5. Renew before it weakens Another timestamp is layered before the previous one’s protection ages, extending verifiability.

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

Что говорят стандарты

Evidence § Standard-backed Evidence: Standard-backed Эта необходимость прямо изложена в Spec Spec: RFC 6960, §4.4.4 RFC 6960 §4.4.4 : статус отзыва может сохраняться дольше окна действия сертификата, а механизм даты отсечения архива даёт средствам проверки исторический контекст, чтобы определить, была ли подпись надёжной в момент её создания, даже после истечения сертификата, использованного для проверки. Именно ради этого и существует долгосрочная проверка. Ответы об отзыве остаются доступными лишь ограниченное время, поэтому их нужно зафиксировать, пока оно не истекло.

Этот механизм описан в ETSI. Spec Spec: ETSI EN 319 142-2, §5.5 ETSI EN 319 142-2 §5.5 устанавливает, что долгосрочное поведение требует хранилища безопасности документа, где данные проверки хранятся как значения, а затем применяется метка времени документа. Spec Spec: ISO 32000-2, §12.8.3.3 ISO 32000-2 §12.8.3.3 связывает всё воедино: PAdES — это CAdES CMS в сочетании с долгосрочной проверкой (§12.8.4) и словарём метки времени документа (§12.8.5). А Spec Spec: ETSI EN 319 142-2, §6.3.2.2 ETSI EN 319 142-2 §6.3.2.2 объясняет, почему метку времени ставят рано: её следует применять сразу после подписания, чтобы зафиксированное время было как можно ближе к фактическому.

Движок NextPDF реализует это на уровнях B-LT и B-LTA: встроенные значения отзыва в DSS, метка времени документа, скрепляющая их, и архивный цикл, обновляющий печать, записываются как добавленные ревизии и оставляют байтовый диапазон исходной подписи нетронутым.

Human-factors note: Human-factors note

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

Практический пример

Выбранный вами уровень и есть долгосрочное решение. API делает требование явным ещё до выбора уровня.

<?php

declare(strict_types=1);

use NextPDF\Security\Signature\SignatureLevel;

// B-LT embeds validation material; B-LTA adds the renewable seal.
$level = SignatureLevel::PAdES_B_LTA;

$level->requiresDss();                // true  → certificates + revocation embedded
$level->requiresDocumentTimestamp();  // true  → a document timestamp seals the DSS

// The high-level seam produces the level end to end: it embeds the DSS
// dictionary and appends the DocTimeStamp revision in one call.
$document
    ->setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)
    ->save();

// The engine produces this only if the deployment can supply what it needs
// (a TSA, and revocation data reachable at signing time). It fails with an
// actionable error rather than embedding nothing and reporting success.

Высокоуровневый шов, показанный выше, — setSignature($cert, SignatureLevel::PAdES_B_LTA, $tsaClient)->save() — теперь связан сквозным образом; в более ранних выпусках было доступно перечисление уровней, но не шов, который его создаёт. Он записывает именно структуру: словарь DSS и ревизию DocTimeStamp, описанные в Spec Spec: ISO 32000-2, §12.8 ISO 32000-2 §12.8 . Эта структура не проверяется на соответствие профилю, и шов ничего не утверждает о соответствии ETSI или о юридической действительности. Уровни B-LT и B-LTA требуют изданий Pro и Enterprise; на любом другом тарифе шов отказывает в работе закрыто, а не выдаёт частичный результат. Зашифрованный документ также вызывает закрытый отказ для B-LT и B-LTA; DSS и метка времени документа не записываются поверх зашифрованного содержимого, потому что это привело бы к некорректной записи.

Этот выбор нельзя дёшево внедрить задним числом. Свидетельства об отзыве нужно фиксировать в момент подписания, пока ответы ещё существуют. Решение “мы добавим долгосрочную проверку позже” обычно означает “у нас не будет свидетельств, когда они понадобятся”.

Распространённое заблуждение

Заблуждение состоит в том, что “долгосрочная проверка делает подпись действительной навсегда”. Она ничего не делает действительным. Она сохраняет возможность проверить действительность, которая была установлена в момент подписания. Если сертификат уже был отозван на момент подписания документа, встраивание этого факта не спасает подпись. Вместо этого оно навсегда документирует сбой. Долгосрочная проверка — это механизм сохранения доказательства, а не его создания. Второе заблуждение — считать, что B-LTA работает по принципу “настроил и забыл”. Архивная метка времени защищает с помощью алгоритмов, которые сами устаревают. Без обновления файл B-LTA со временем наследует ту же уязвимость, от которой должен был защитить.

Ограничения и границы

NextPDF собирает и встраивает свидетельства и записывает метки времени. Он не отвечает за достоверность свидетельств и график их обновления. Ответы об отзыве настолько надёжны, насколько надёжны выдавший их удостоверяющий центр и момент, когда они были получены. Связь с этим удостоверяющим центром в момент подписания — зона ответственности развёртывания. Движок не может выдумать ответ об отзыве, который не удалось получить. Архивное обновление — это эксплуатационный процесс. Движок может добавить ещё одну метку времени, но не может решить, когда этого требует ваша политика хранения. Будут ли встроенные данные впоследствии сочтены достаточными — вопрос средства проверки и политики, который рассматривается в разделе “Правильная проверка подписи”. Эта страница не утверждает юридическую допустимость, которая зависит от юрисдикции, подписанта и сертификата.

Доступность долгосрочной проверки по тарифам:

Долгосрочная проверка (встраивание DSS и архивный цикл меток времени) — edition availability

Edition	Availability
Core	○ Not in this edition
Pro	○ PAdES B-T — доверенная метка времени на значении подписи — доступна, но встроенный материал проверки (DSS) не входит в B-T.
Enterprise	○ PAdES B-LT и B-LTA: встроенные значения сертификата и отзыва в DSS, скрепляющая метка времени документа и обновляемый архивный цикл.

Связанные документы

• Базовые профили PAdES — где B-LT и B-LTA находятся в иерархии уровней и что добавляет каждый из них.
• “Метки времени и доверенное время” — метка времени документа, которая скрепляет встроенные свидетельства.
• “Правильная проверка подписи” — как средство проверки использует встроенный материал и почему одного слова “действительна” недостаточно.
• “Рабочий процесс подписанных соглашений” — сквозной рабочий процесс, в котором материал долгосрочной проверки применяется на практике.

Глоссарий

• Долгосрочная проверка (LTV) — встраивание свидетельств, необходимых для проверки подписи, чтобы последующая проверка не зависела от внешних служб.
• Хранилище безопасности документа (DSS) — структура PDF, которая хранит встроенные сертификаты и данные об отзыве для долгосрочной проверки.
• Ответ OCSP — подписанное утверждение о статусе отзыва сертификата на определённый момент времени (Online Certificate Status Protocol, RFC 6960).
• CRL — Certificate Revocation List, список отзыва сертификатов; подписанный список отозванных сертификатов.
• Метка времени документа — метка времени по RFC 3161, применяемая ко всему документу и доказывающая, что встроенные свидетельства существовали и были действительны в тот момент.
• Архивный цикл — повторное добавление новой метки времени документа до того, как ослабнет защита предыдущей, что продлевает проверяемость.