RFC 3161

RFC 3161 — это стандарт Интернета, описывающий протокол службы штампов времени (Time-Stamp Protocol, TSP). Он был опубликован в августе 2001 года Инженерным советом Интернета (IETF) и определяет формат запросов и ответов для получения доверенной метки времени, связывающей цифровые данные с конкретным моментом времени. Основная цель RFC 3161 — обеспечение доказательства существования цифрового документа на определённую дату и время, что критически важно для электронной подписи, аудита и юридической значимости электронных документов.

История и предпосылки создания

До появления RFC 3161 проблема доверенного времени в цифровой среде решалась фрагментарно. Развитие криптографии, в частности асимметричных алгоритмов и хеш-функций, позволило создавать цифровые подписи, но без привязки к времени они не могли гарантировать, что документ существовал до определённого момента. В 1990-х годах возникла потребность в стандартизированном механизме, который бы позволял получать криптографически заверенные метки времени от доверенной третьей стороны — службы штампов времени (Time-Stamp Authority, TSA).

Работа над протоколом велась в рамках рабочей группы IETF PKIX (Public Key Infrastructure using X.509). RFC 3161 стал результатом этой работы, заменив более ранние проекты и предложения, такие как RFC 1423. Он был разработан для интеграции с инфраструктурой открытых ключей (PKI) и сертификатами X.509, что обеспечило его совместимость с существующими системами электронной подписи.

Основные понятия и архитектура

Служба штампов времени (TSA)

TSA — это доверенный сервер, который принимает запросы на штампы времени и выдаёт ответы, содержащие криптографически защищённую метку времени. TSA должна быть надёжной, точной и защищённой от подделок. В России требования к TSA регулируются Федеральным законом № 63-ФЗ «Об электронной подписи» и ГОСТ Р 34.10-2012, которые во многом гармонизированы с международными стандартами, включая RFC 3161.

Запрос на штамп времени (TimeStampReq)

Клиент (например, программа для создания электронной подписи) формирует запрос, который включает:

• Хеш-значение (hash) — результат применения криптографической хеш-функции (например, SHA-1, SHA-256 или ГОСТ Р 34.11-2012) к документу или его части. Хеш-функция необратима и уникальна для каждого документа, поэтому TSA не видит содержимого документа.
• Идентификатор алгоритма хеширования (hashAlgorithm).
• Необязательные поля: запрос на определённую политику штампов времени (policy), идентификатор сертификата TSA, дополнительные данные.

Ответ на штамп времени (TimeStampResp)

Ответ TSA содержит:

• Статус обработки (status) — код успеха или ошибки.
• Токен штампа времени (TimeStampToken, TST) — основной элемент. TST представляет собой подписанное TSA сообщение, которое включает:
• Исходное хеш-значение из запроса.
• Время (в формате UTC) — точный момент, когда TSA получила запрос.
• Серийный номер токена.
• Идентификатор политики TSA.
• Необязательные расширения (например, имя TSA, данные о точности времени).
• Цифровую подпись TSA, созданную с использованием её закрытого ключа. Подпись заверяет все перечисленные данные.

Формат данных

RFC 3161 использует кодировку ASN.1 (Abstract Syntax Notation One) и её двоичное представление DER (Distinguished Encoding Rules). Это обеспечивает компактность и однозначность интерпретации данных. Для описания структуры запросов и ответов применяется синтаксис ASN.1, что делает протокол совместимым с другими стандартами PKI, такими как X.509 и PKCS#7.

Процесс получения штампа времени

1. Подготовка документа: Клиент вычисляет хеш-значение документа с помощью выбранного алгоритма (например, ГОСТ Р 34.11-2012 для российских систем).
2. Формирование запроса: Клиент создаёт TimeStampReq, содержащий хеш и идентификатор алгоритма.
3. Отправка запроса: Запрос передаётся TSA по протоколу HTTP, TCP или через другие транспортные механизмы. RFC 3161 не ограничивает транспорт, но на практике часто используется HTTP POST.
4. Обработка запроса TSA: TSA проверяет корректность запроса (например, поддерживается ли алгоритм хеширования), фиксирует текущее время по своим часам, формирует TST и подписывает его.
5. Ответ клиенту: TSA отправляет TimeStampResp, содержащий TST.
6. Верификация: Клиент может проверить подпись TSA, используя её сертификат открытого ключа, и убедиться, что хеш в TST совпадает с хешем документа. Это подтверждает, что документ существовал на момент, указанный в штампе.

Применение

Электронная подпись (ЭП)

RFC 3161 широко используется в системах электронного документооборота (ЭДО) для привязки подписи к времени. Например, в России при создании усиленной квалифицированной электронной подписи (УКЭП) по ГОСТ Р 34.10-2012 часто применяются штампы времени, соответствующие RFC 3161, чтобы обеспечить юридическую значимость подписи после истечения срока действия сертификата ключа подписи.

Аудит и логирование

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

Защита от подделки дат

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

Блокчейн и распределённые реестры

Некоторые блокчейн-проекты используют штампы времени RFC 3161 для подтверждения времени транзакций или хранения данных вне цепочки.

Критика и ограничения

Зависимость от доверенной третьей стороны

TSA является централизованным элементом, что создаёт риски: если TSA скомпрометирована или её часы неточны, все выданные штампы могут быть признаны недействительными. Для снижения риска применяются политики TSA, аудит и синхронизация времени с эталонными источниками (например, GPS или NTP).

Срок действия сертификата TSA

Сертификат TSA имеет ограниченный срок действия. После его истечения подпись TST может считаться недействительной, если не используется механизм продления (например, повторное штампование TST). RFC 3161 не определяет процедуры долговременного хранения, что привело к появлению дополнительных стандартов, таких как RFC 4998 (Evidence Record Syntax) и RFC 6283 (Long-term Archive Service).

Производительность

Вычисление хеша и подпись каждого запроса требуют вычислительных ресурсов. При высокой нагрузке TSA может стать узким местом. Для масштабирования используются кластерные решения и аппаратные модули безопасности (HSM).

Совместимость с российскими стандартами

В России применение RFC 3161 сопряжено с необходимостью использования криптографических алгоритмов, соответствующих ГОСТ. Хотя стандарт RFC 3161 допускает любые алгоритмы, на практике требуется поддержка ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012. Многие российские TSA (например, аккредитованные Минцифры) реализуют именно такие алгоритмы, что обеспечивает совместимость с национальными стандартами.

Связанные стандарты

• RFC 5816 — уточнения к RFC 3161, касающиеся использования алгоритмов хеширования и подписи.
• RFC 5652 (Cryptographic Message Syntax, CMS) — формат, на котором основан TST в RFC 3161.
• RFC 4998 — Evidence Record Syntax (ERS) для долговременного хранения доказательств.
• ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012 — российские криптографические стандарты, используемые в реализации TSP.
• ISO 18014 — международный стандарт, описывающий службы штампов времени, частично пересекающийся с RFC 3161.

Интересные факты

• RFC 3161 был опубликован 21 августа 2001 года, за несколько недель до терактов 11 сентября, что не повлияло на его дальнейшее развитие.
• Протокол TSP изначально разрабатывался для использования с сертификатами X.509, но может применяться и с другими системами PKI.
• В России первая коммерческая TSA, соответствующая RFC 3161, была запущена в 2005 году компанией «КриптоПро».
• Штампы времени RFC 3161 используются в системе «Госуслуги» для подтверждения времени подписания электронных документов.