Кратко

  • CTT в RFC 9921 передаёт TSA хеш закодированного поля COSE-подписи; TTC сначала метит хеш полезной нагрузки, а затем помещает токен и нагрузку под новую COSE-подпись.
  • Защищённый 3161-ttc не делает подпись старше. Он показывает, что последующий подписант включил старый токен, а не то, что TSA видел будущую подпись.

В архивной карточке стояли три отметки: токен выдан до отзыва, подпись проверена, объект сохранён без изменений. Из них вывели четвёртую: подпись была создана до отзыва. Именно эта четвёртая отметка не следовала из первых трёх.

Порядок мог быть иным. Во вторник автор отправил в Time Stamping Authority, TSA, хеш данных и получил токен. В среду его сертификат отозвали. В четверг он включил вторничный токен в защищённый COSE-заголовок и подписал объект. Четверговая подпись действительно охватывает и токен, и данные. Вторничный токен действительно подтверждает прежнее существование данных. Но TSA во вторник не получала байтов четверговой подписи. Нельзя незаметно сменить предмет временного утверждения.

RFC 9921 вводит для COSE_Sign и COSE_Sign1 два способа включения TimeStampToken из RFC 3161. Это не универсальное поле «дата документа». Стандарт задаёт два разных порядка сборки, два разных входа MessageImprint и два разных алгоритма проверки. В разделе безопасности прямо сказано: проверяющий не должен принимать временную метку нагрузки в защищённом заголовке за доказательство времени создания подписи, иначе возможна ошибочная приёмка подписи после отзыва ключа.

Сначала надо назвать объект временного доказательства

В режиме COSE, Then Timestamp (CTT) сначала создаётся COSE-подпись. Затем в TSA посылается хеш CBOR-кодированного поля signature для COSE_Sign1 либо CBOR-кодированного поля signatures для COSE_Sign. Полученный токен размещается в незащищённом параметре заголовка 3161-ctt.

Следовательно, TSA получает представление именно байтов подписи в предписанном RFC 9921 кодировочном охвате. После проверки COSE-подписи, токена, сертификата TSA и применимой политики можно сделать ограниченный вывод: подпись уже существовала к времени TSA. Поэтому CTT предназначен для долгосрочной подписи, когда последующее истечение или отзыв сертификата не должны уничтожать правильно зафиксированный факт прежнего подписания.

В Timestamp, Then COSE (TTC) сначала вычисляется хеш байтов полезной нагрузки COSE. CBOR-обёртка bstr и ещё не созданная подпись в MessageImprint не входят. Токен помещается в защищённый параметр 3161-ttc; после этого COSE-подпись покрывает защищённый заголовок и полезную нагрузку.

TTC решает другую задачу: сохраняет ранний временной след данных внутри позднее подписанного заявления. В сценарии прозрачности/нотариального подтверждения RFC 9921 это позволяет не потерять токен до регистрации подписанных частей заявления в append-only журнале. Такая цепочка полезна, но не исчерпывающа. Для доверия к заявлению отдельно нужны доказательства включения и согласованности журнала, личность издателя, последовательность сведений об отзыве и политика полагающейся стороны. А время создания COSE-подписи остаётся тем фактом, который TTC не доказывает.

Защищённый заголовок защищает связь, а не прошлое

Слово protected в TTC имеет точный смысл: после подписи нельзя заменить токен, не нарушив COSE-подпись. Из него не следует, что токен когда-либо включал в свою хешированную входную величину подпись, созданную потом.

У CTT обратная внешняя форма по понятной причине. Подпись уже создана, когда приходит ответ TSA, и не может задним числом охватить этот ответ. Поэтому 3161-ctt находится в незащищённом заголовке. RFC 9921 предупреждает, что его можно удалить или заменить, и требует компенсировать это защитой целостности всей COSE Signed Message при передаче и хранении.

Для архива это означает не просто хранить статус «ok». Нужны хеш полного объекта, режим CTT/TTC, точные байты входа imprint, сертификат и политика TSA, доказательства статуса сертификатов и слой хранения, сохранивший связь подписи с токеном. Если CTT-токен исчез после миграции, исторического доказательства времени больше нет. Старое зелёное решение не может пережить потерю его основания.

Проверка метки — только середина цепочки

RFC 3161 описывает TSA как службу, метящую хеш-представление, а не оценивающую смысл данных. Клиент обязан проверить статус ответа, идентичность и сертификат TSA, требуемый imprint, алгоритм, своевременность по nonce или доверенному местному времени, статус сертификата TSA и приемлемость политики. genTime — момент, когда TSA создала токен; точность, разрешение, задержка и политика ограничивают интерпретацию.

RFC 9921 добавляет критическую операцию: заново посчитать MessageImprint на точных байтах, которые предписывает выбранный режим. Для CTT это поле подписи; для TTC — полезная нагрузка. Наличие валидного CMS-токена рядом с объектом не заменяет эту проверку и не связывает токен с тем утверждением, которое использует решение.

Поэтому рабочий журнал должен перечислять режим, байтовый охват, результаты проверки COSE и TSA, допущения по точности и политике, правило отзыва, а при прозрачности — доказательства inclusion и consistency, затем владельца решения и наблюдаемый эффект. Принцип Heng Lu о работающем коде здесь практически применим: действительна не надпись в интерфейсе, а исполняемый путь, который сделал эти проверки и записал их результат. Синтаксически распознанный объект, криптографический факт, разрешение и реальное последствие — разные уровни.

Sources