Настоящий стандарт устанавливает протокол постановки штампа времени, который подтверждает факт существования данных к определенному моменту времени. Стандарт определяет форматы сообщений, которыми обмениваются стороны протокола, и действия сторон.

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

2 Нормативные ссылки

В настоящем стандарте использованы ссылки на следующие технические нормативные правовые акты в области технического нормирования и стандартизации (далее – ТНПА):

СТБ 34.101.19-2012 Информационные технологии и безопасность. Форматы сертификатов и списков отозванных сертификатов инфраструктуры открытых ключей

СТБ 34.101.23-2012 Информационные технологии и безопасность. Синтаксис криптографических сообщений

СТБ 34.101.65-2014 Информационные технологии и безопасность. Протокол защиты транспортного уровня (TLS)

СТБ 34.101.80-2019 Информационные технологии и безопасность. Расширенные электронные цифровые подписи

ГОСТ 34.973-91 (ИСО 8824-87) Информационная технология. Взаимосвязь открытых систем. Спецификация абстрактно-синтаксической нотации версии 1 (АСН.1)

ГОСТ 34.974-91 (ИСО 8825-87) Информационная технология. Взаимосвязь открытых систем. Описание базовых правил кодирования для абстрактно-синтаксической нотации версии 1 (АСН.1)

Примечание – При пользовании настоящим стандартом целесообразно проверить действие ТНПА по каталогу, составленному по состоянию на 1 января текущего года, и по соответствующим информационным указателям, опубликованным в текущем году. Если ссылочные ТНПА заменены (изменены), то при пользовании настоящим стандартом следует руководствоваться действующими взамен ТНПА. Если ссылочные ТНПА отменены без замены, то положение, в котором дана ссылка на них, применяется в части, не затрагивающей эту ссылку.

3 Термины и определения

В настоящем стандарте применяют термины, установленные в СТБ 34.101.19, СТБ 34.101.23, ГОСТ 34.973, ГОСТ 34.974, а также следующие термины с соответствующими определениями:

3.1 отметка времени (time-stamp): Последовательность символов, с некоторой точностью описывающая определенный момент времени.

3.2 поставщик услуг доверия (trust service provider): Сторона, которая помогает установить доверенные отношения между другими сторонами, предоставляя определенную информацию по их запросу.

3.3 служба штампов времени (time-stamping authority): Поставщик услуг доверия, который создает штампы времени для подтверждения существования данных к определенному моменту времени.

3.4 штамп времени (time-stamp token): Информационный объект, который связывает представление данных (как правило, хэш-значение) с определенным моментом времени, тем самым удостоверяя существование данных к этому моменту.

4 Обозначения и сокращения

В настоящем стандарте применяют следующие сокращения:

АСН.1 – абстрактно-синтаксическая нотация версии 1;

СОК – сертификат открытого ключа;

СОС – список отозванных сертификатов;

СШВ – служба штампов времени;

УЦ – удостоверяющий центр;

ЭЦП – электронная цифровая подпись.

Для определения типов АСН.1 применяют обозначения, заданные в ГОСТ 34.973.

Ключевое cлово «ДОЛЖЕН» означает, что действия, к которым применены данные ключевые слова, необходимо в точности выполнять. Ключевое слово «НЕЛЬЗЯ» выражает абсолютный запрет на выполнение соответствующих действий. Ключевые слова «СЛЕДУЕТ» и «РЕКОМЕНДУЕТСЯ» необходимо понимать так, что в некоторых случаях существует реальная причина их игнорировать, но последствия таких действий должны быть очевидными и хорошо взвешенными. Ключевое слово «НЕ СЛЕДУЕТ» применяется в тех случаях, когда действие, к которому применено данное ключевое слово, будет в некоторых случаях правильным и даже полезным, однако при этом его последствия должны быть очевидными и хорошо взвешенными. Ключевое слово «МОЖЕТ» применяется к действиям (предметам), выполнение или невыполнение (наличие или отсутствие) которых не влияет на ситуацию в целом. Это означает, что программы, работающие с чем-то, помеченным данными ключевыми словами, должны учитывать обе ситуации и корректно их обрабатывать.

5 Общие положения

Настоящий стандарт определяет протокол постановки штампа времени, соответствующий [1] с дополнениями из [2]. Форматы сообщений протоколов определяются на языке АСН.1, установленном в ГОСТ 34.973. Модуль АСН.1 с описанием форматов приведен в приложении А.

Использование штампа времени дает возможность доказать факт существования данных к определенному моменту времени. Одним из основных назначений штампа времени является его использование для фиксации времени выработки ЭЦП, например, с помощью атрибута SignatureTimeStamp (атрибут определен в СТБ.34.101.80). Даже если к моменту проверки подписи СОК подписанта отозван, штамп времени для ЭЦП позволяет определить, была ли данная ЭЦП выработана до или после отзыва СОК (см. СТБ.34.101.80 раздел 8). Штамп времени может также использоваться для указания времени получения данных, когда данное время критично, или времени совершения транзакции при ведении журнала аудита транзакций. Рассмотрение исчерпывающего списка ситуаций, в которых могут использоваться штампы времени, выходит за рамки настоящего стандарта.

Постановка штампа времени обеспечивается СШВ по корректному запросу, под которым понимается запрос, который соответствует определенному в настоящем стандарте формату.

СШВ, как правило, является поставщиком услуг доверия, но могут применяться и другие модели функционирования, например, информационные системы могут использовать СШВ только для своих внутренних целей.

Штамп времени подписывается СШВ с помощью личного ключа, который предназначен исключительно для этой цели и в СОК которого указана соответствующая информация о его назначении. При использовании штампа времени СЛЕДУЕТ проверять действительность СОК СШВ (например, путем проверки соответствующего СОС). Штамп времени ДОЛЖЕН быть отклонен, если он выпущен после истечения срока действия или даты отзыва СОК СШВ. Дополнительные причины отклонения штампа времени, связанные с отзывом СОК СШВ, рассматриваются в разделе 9.

Настоящий стандарт не устанавливает полный список требований безопасности к СШВ. Предполагается, что СШВ доведет до сведения возможных пользователей политики, которые служба применяет при постановке штампов времени, и пользователи будут использовать данную СШВ только в том случае, если применяемые службой политики удовлетворяют их потребностям. Программному обеспечению при использовании штампа времени СЛЕДУЕТ проверять, что политика, с применением которой был выпущен штамп времени и идентификатор которой указан в штампе времени, является приемлемой.

6 Сообщения протокола

Для получения штампа времени сторона, которая его запрашивает, формирует и передает СШВ запрос со значением типа TimeStampReq (см. 7.1). Запрос содержит хэш-значение данных, для которых требуется выпустить штамп времени, а также другую информацию. Запрос на получение штампа времени не содержит информации, которая идентифицирует отправителя запроса, так как данная информация не проверяется СШВ. В случае, когда СШВ требует идентификации отправителя запроса, должны использоваться альтернативные способы идентификации или аутентификации (например, для идентификации может использоваться вложение запроса в криптографическое сообщение согласно СТБ 34.101.23, а для аутентификации – протокол TLS согласно СТБ 34.101.65).

При получении запроса СШВ обрабатывает его и возвращает ответ со значением типа TimeStampResp (см. 7.2). Ответ содержит статус обработки запроса и, при успешной обработке запроса, штамп времени. СШВ ДОЛЖНА выпускать штамп времени для каждого корректного запроса всегда, когда это возможно.

При получении ответа отправителю запроса СЛЕДУЕТ проверить в ответе статус обработки запроса. Если согласно статусу штамп времени включается в ответ, то отправитель запроса ДОЛЖЕН проверить корректность штампа времени, включая проверку ЭЦП штампа времени. В частности, отправитель ДОЛЖЕН проверить, что штамп времени содержит корректную ссылку на СОК СШВ и корректный идентификатор алгоритма хэширования, а также что хэш-значение, для которого выпущен штамп времени, соответствует хэш-значению из запроса. Затем отправитель запроса ДОЛЖЕН проверить своевременность ответа путем сравнения отметки времени, включенной в штамп времени, с локальным доверенным временем (если оно доступно) или путем сравнения значения компонента nonce, включенного в штамп времени, с соответствующим значением из запроса (подробнее см. раздел 9). Если любая из проверок, описанных выше, не выполняется, то штамп времени ДОЛЖЕН быть отклонен.

Сообщения протокола кодируются, в результате чего формируются строки октетов. Базовые правила кодирования определены в ГОСТ 34.974. Отличительные правила кодирования, которые уточняют базовые правила и обеспечивают однозначность кодового представления, определены в СТБ 34.101.19 (раздел Б.1).

Стандарт не устанавливает обязательные способы обмена сообщениями протокола. В разделе 8 приведены некоторые из возможных способов.

Для информирования о поддерживаемом СШВ способе обмена сообщениями ее СОК МОЖЕТ содержать расширение SubjectInfoAccessSyntax (см. СТБ 34.101.19 пункт 6.2.2). В этом случае компонент accessMethod данного расширения ДОЛЖЕН содержать идентификатор.

id-ad-timeStamping OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
  dod(6) internet(1) security(5) mechanisms(5) pkix(7) ad (48) 
  timestamping (3)}

При этом поддерживаемый СШВ способ обмена сообщениями указывается как значение компонента accessLocation данного расширения. Возможные значения компонента accessLocation не рассматриваются в настоящем стандарте.

7 Форматы запроса и ответа

7.1 Формат запроса

Запрос получения штампа времени определяется следующими типами АСН.1:

TimeStampReq ::= SEQUENCE {
  version         INTEGER { v1(1) },
  messageImprint  MessageImprint,
  reqPolicy       TSAPolicyId  OPTIONAL,
  nonce           INTEGER OPTIONAL,
  certReq         BOOLEAN DEFAULT FALSE,
  extensions [0]  IMPLICIT Extensions OPTIONAL }
MessageImprint ::= SEQUENCE {
  hashAlgorithm  AlgorithmIdentifier,
  hashedMessage  OCTET STRING }
TSAPolicyId ::= OBJECT IDENTIFIER

Компоненты типа TimeStampReq имеют следующее значение:

version определяет номер версии формата запроса на получение штампа времени. Для настоящей версии стандарта он должен быть равен 1;
messageImprint содержит хэш-значение, для которого требуется выпустить штамп времени, и определяет алгоритм хэширования, который использовался при вычислении данного хэш-значения;
reqPolicy является необязательным компонентом, который определяет идентификатор политики. При выпуске штампа времени СШВ СЛЕДУЕТ применять политику, соответствующую указанному в данном компоненте идентификатору;
nonce является необязательным компонентом, который определяет значение, используемое для проверки своевременности ответа в случае отсутствия у отправителя запроса локального источника времени. Вероятность повторения используемых для данного компонента значений должна быть пренебрежительно мала. В качестве значений компонента nonce РЕКОМЕНДУЕТСЯ использовать случайные значения, содержащие не менее 64 бит энтропии. Компонент nonce РЕКОМЕНДУЕТСЯ включать в запрос. При этом то же самое значение nonce ДОЛЖНО быть включено и в штамп времени, в противном случае штамп времени ДОЛЖЕН быть отклонен;
certReq определяет, необходимо ли включать в штамп времени СОК СШВ. Если данный компонент включен в запрос и имеет значение TRUE, то СОК СШВ ДОЛЖЕН включаться в штамп времени, иначе СОК СШВ НЕЛЬЗЯ включать в штамп (см. 7.2);
extensions является необязательным компонентом, который определяет в виде расширений дополнительную информацию, связанную с запросом. Тип Extensions данного компонента определен в СТБ 34.101.19. Настоящий стандарт не определяет расширения, которые могут быть включены в запрос. Если расширение, которое может быть как критическим, так и некритическим, включено в запрос и не может быть распознано СШВ, то СШВ НЕЛЬЗЯ выпускать штамп времени, при этом СШВ ДОЛЖНА вернуть ответ с ошибкой unacceptedExtension (см. 7.2).

Компоненты типа MessageImprint имеют следующее значение:

hashAlgorithm определяет идентификатор алгоритма хэширования, который использовался для вычисления хэш-значения данных. При получении запроса СШВ СЛЕДУЕТ проверить, что идентификатор, указанный в данном компоненте, соответствует алгоритму хэширования, определенному в действующем ТНПА. Если идентификатор не может быть распознан СШВ или соответствует алгоритму хэширования, который не определен в действующем ТНПА, то СШВ НЕ СЛЕДУЕТ выпускать штамп времени, при этом СШВ СЛЕДУЕТ вернуть ответ с ошибкой badAlg (см. 7.2). Тип AlgorithmIdentifier данного компонента определен в СТБ 34.101.19;
hashedMessage определяет хэш-значение данных. Длина указанного в компоненте hashedMessage хэш-значения ДОЛЖНА соответствовать алгоритму хэширования, определяемому в компоненте hashAlgorithm. При получении запроса СШВ ДОЛЖНА проверить данное соответствие. СШВ НЕЛЬЗЯ налагать другие ограничения на хэш-значения.

7.2 Формат ответа

Ответ на запрос получения штампа времени определяется следующими типами АСН.1:

TimeStampResp ::= SEQUENCE {
  status          PKIStatusInfo,
  timeStampToken  TimeStampToken OPTIONAL }
PKIStatusInfo ::= SEQUENCE {
    status        PKIStatus,
    statusString  PKIFreeText OPTIONAL,
    failInfo      PKIFailureInfo OPTIONAL }
PKIStatus ::= INTEGER {
    granted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4),
    revocationNotification (5) }
PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badRequest (2),
    badTime (3),
    badDataFormat (5),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17),
    systemFailure (25) }
TimeStampToken ::= ContentInfo

Компоненты типа TimeStampResp имеют следующее значение:

status содержит информацию о результате обработки СШВ запроса на получение штампа времени;
timeStampToken является необязательным компонентом, который определяет штамп времени. Данный компонент ДОЛЖЕН включаться в ответ, когда компонент status содержит значение granted или grantedWithMods (см. возможные значения компонента status, вложенного в тип PKIStatusInfo), и его НЕЛЬЗЯ включать в ответ в противном случае.

Компоненты типа PKIStatusInfo имеют следующее значение:

status определяет статус обработки запроса. Данный компонент ДОЛЖЕН принимать одно из следующих значений: granted – штамп времени предоставлен согласно запросу; grantedWithMods – штамп времени предоставлен с модификациями (штамп времени несущественно отличается от запрашиваемого, ответственность за определение различий несет отправитель запроса); rejection – запрос на получение штампа времени отклонен; waiting – запрос пока еще не был обработан, ожидается получение повторного запроса позже; revocationWarning – предупреждение, что СОК СШВ будет отозван; revocationNotification – уведомление, что СОК СШВ отозван. СШВ НЕ СЛЕДУЕТ использовать для определения статуса обработки запроса другие значения, кроме описанных выше. Программное обеспечение, выполняемое на стороне пользователя, ДОЛЖНО возвращать ошибку, если значение статуса, переданное в ответе, не может быть распознано;
statusString является необязательным компонентом, который определяет статус обработки запроса в удобном для восприятия пользователем виде. Данный компонент МОЖЕТ использоваться для указания причины отклонения запроса. Тип PKIFreeText данного компонента определен в [3];
failInfo является необязательным компонентом, который определяет дополнительную информацию о причине отклонения запроса. Данный компонент НЕЛЬЗЯ включать в ответ, если в ответ включается компонент timeStampToken. Если компонент failInfo присутствует, то он может принимать одно из следующих значений: badAlg – идентификатор алгоритма хэширования является некорректным или определяет неподдерживаемый алгоритм; badRequest – транзакция не разрешена или не поддерживается; badTime – время в запросе недостаточно близко к текущему; badDataFormat – запрос имеет некорректный формат; timeNotAvailable – источник времени недоступен; unacceptedPolicy – запрашиваемая политика не поддерживается; unacceptedExtension – запрашиваемое расширение не поддерживается; addInfoNotAvailable – запрашиваемая дополнительная информация неизвестна или недоступна; systemFailure – запрос не может быть обработан из-за сбоя системы. СШВ НЕ СЛЕДУЕТ использовать для failInfo другие значения, кроме описанных выше. Программное обеспечение, выполняемое на стороне пользователя, ДОЛЖНО возвращать ошибку, если значение failInfo, переданное в ответе, не может быть распознано.

Тип TimeStampToken соответствует типу ContentInfo (см. СТБ 34.101.23 (раздел 6)) и определяет штамп времени. Для штампа времени компоненты contentType и content, содержащиеся в ContentInfo, должны принимать значение id-signedData и значение типа SignedData соответственно. Значение id-signedData, тип SignedData и типы компонентов, вложенных в SignedData, определяются в СТБ 34.101.23.

При формировании штампа времени компонент eContentType типа EncapsulatedContentInfo, вложенного в SignedData, должен принимать значение id-ct-TSTInfo, которое определяется следующим образом:

id-ct-TSTInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
  rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4 }

В свою очередь компонент eContent типа EncapsulatedContentInfo, вложенного в SignedData, ДОЛЖЕН содержать закодированное по отличительным правилам значение типа TSTInfo, который определяется следующими типами АСН.1:

TSTInfo ::= SEQUENCE {
  version         INTEGER { v1(1) },
  policy          TSAPolicyId,
  messageImprint  MessageImprint,
  serialNumber    INTEGER,
  genTime         GeneralizedTime,
  accuracy        Accuracy OPTIONAL,
  ordering        BOOLEAN DEFAULT FALSE,
  nonce INTEGER OPTIONAL,
  tsa         [0] GeneralName OPTIONAL,
  extensions  [1] IMPLICIT Extensions OPTIONAL }
Accuracy ::= SEQUENCE {
  seconds  INTEGER OPTIONAL,
  millis   [0] INTEGER (1..999) OPTIONAL,
  micros   [1] INTEGER (1..999) OPTIONAL }

Компоненты типа TSTInfo имеют следующее значение:

version определяет номер версии штампа времени. Для данной версии стандарта он должен быть равен 1;
policy определяет идентификатор политики, применяемой СШВ при выпуске штампа времени. Идентификатор ДОЛЖЕН однозначно идентифицировать применяемую СШВ политику. Если в запросе на выпуск штампа времени присутствовал компонент reqPolicy (см. 7.1), тогда значение компонента policy ДОЛЖНО совпадать со значением компонента reqPolicy, в противном случае ДОЛЖЕН быть возвращен ответ с ошибкой unacceptedPolicy. Политика МОЖЕТ определять, например, следующую информацию: условия, при которых штамп времени может использоваться; наличие протоколирования выпущенных значений штампов времени, позволяющее в будущем проверить, что штамп времени выпущен именно этой службой;
messageImprint содержит хэш-значение, для которого выпущен штамп времени. Данный компонент ДОЛЖЕН иметь то же самое значение, что и аналогичный компонент в запросе, при условии, что для компонента messageImprint запроса (см. 7.1) длина хэш-значения, указанного в компоненте hashedMessage, соответствует алгоритму хэширования, определяемому в компоненте hashAlgorithm. Тип MessageImprint данного компонента определен в 7.1;
serialNumber определяет целое число, которое СШВ назначает для каждого штампа времени. Данное число ДОЛЖНО быть уникальным для каждого штампа времени, выпускаемого одной и той же СШВ (т.е. имя СШВ и значение serialNumber однозначно идентифицируют штамп времени). Уникальность значений serialNumber ДОЛЖНА поддерживаться даже после возможного прерывания работы службы, например, по причине сбоя. Программное обеспечение, использующее штамп времени, ДОЛЖНО быть способно обрабатывать значения компонента serialNumber с длиной до 160 бит;
genTime определяет время создания штампа времени в виде отметки времени. При формировании отметки времени СШВ ДОЛЖНА использовать надежный источник времени. В качестве значения genTime ДОЛЖНО использоваться только достоверное значение отметки времени. Значение genTime ДОЛЖНО быть представлено в стандартном времени по Гринвичу (чтобы избежать возможных коллизий в связи с использованием различных временных зон), ДОЛЖНО включать секунды (даже когда значение секунд равно нулю) и МОЖЕТ включать дробные доли секунд, задаваемые после точки, т.е. время создания штампа времени должно представляться в формате 1YYYYMMDDhhmmss[.s…]Z. Для дробных долей секунд, при их наличии, незначащие нули ДОЛЖНЫ отсутствовать. Если значение дробных долей секунд равно нулю или если время создания штампа времени требуется представлять с точностью до одной секунды, то дробные доли секунд ДОЛЖНЫ опускаться вместе с точкой, т.е. время должно быть представлено в формате YYYYMMDDhhmmssZ. Полночь в стандартном времени по Гринвичу следует представлять в формате YYYYMMDD000000Z, где YYYYMMDD соответствует дню, следующему за полночью. Примерами корректного представления отметок времени являются: 20170125000000Z, 20170217123421Z, 20170325132100.3Z;
accuracy является необязательным компонентом, который определяет максимально возможное отклонение времени СШВ от точного времени. Добавляя значение компонента accuracy к значению компонента genTime может быть получена верхняя граница для точного времени создания штампа времени. Аналогично, вычитая значение компонента accuracy из значения компонента genTime может быть получена нижняя граница для точного времени создания штампа времени. Когда компонент accuracy отсутствует, значение для отклонения времени СШВ от точного времени может быть получено иным способом, например, через политику, определяемую значением компонента policy;
ordering является необязательным компонентом, который определяет, могут ли штампы времени быть упорядочены по значениям компонента genTime. Если компонент ordering присутствует и установлен в значение TRUE, то штампы времени, выпущенные одной и той же СШВ, могут быть упорядочены по значениям компонента genTime независимо от значений компонента accuracy. Если компонент ordering опущен или если он присутствует и установлен в значение FALSE, то упорядочивание штампов времени, выпущенных одной и той же СШВ или различными СШВ, возможно только тогда, когда разница между значением компонента genTime одного штампа времени и значением компонента genTime другого штампа времени больше, чем сумма значений компонента accuracy обоих штампов времени;
nonce является необязательным компонентом, который ДОЛЖЕН присутствовать, если аналогичный компонент присутствовал в запросе. Он ДОЛЖЕН иметь то же самое значение, что и аналогичный компонент в запросе;
tsa является необязательным компонентом, который определяет имя СШВ. В случае наличия он ДОЛЖЕН соответствовать одному из имен субъекта, которые указаны в СОК, предназначенном для проверки ЭЦП штампа времени. Целью включения данного компонента в штамп времени является предоставление подсказки по определению СОК СШВ;
extensions является необязательным компонентом, который определяет в виде расширений дополнительную информацию, связанную со штампом времени. Тип Extensions данного компонента определен в СТБ 34.101.19. Настоящий стандарт не определяет расширения, которые могут быть включены в штамп времени. СШВ НЕЛЬЗЯ включать в штамп времени расширения, которые идентифицируют запрашивающую сторону. Если в соответствии с запросом требуется включение в штамп времени расширения с определенной информацией и данное расширение поддерживается службой, то СШВ ДОЛЖНА включить данное расширение в штамп времени, а если это невозможно – вернуть ответ с ошибкой addInfoNotAvailable.

Среди необязательных компонентов штампа времени версии 1 только компонент nonce ДОЛЖЕН поддерживаться СШВ. Остальные необязательные компоненты МОГУТ поддерживаться СШВ. Запрашивающие штамп времени стороны ДОЛЖНЫ быть способны распознавать штампы времени версии 1, в том числе штампы времени со всеми необязательными компонентами. При этом они не обязаны распознавать расширения, включаемые в штамп времени.

Компоненты типа Accuracy имеют следующее значение:

seconds является необязательным компонентом, который определяет количество секунд;
millis является необязательным компонентом, который определяет количество миллисекунд (от 1 до 999);
micros является необязательным компонентом, который определяет количество микросекунд (от 1 до 999).

Если в значении типа Accuracy какой-либо компонент опущен, то для него ДОЛЖНО приниматься нулевое значение.

Для подписи штампа времени СШВ ДОЛЖНА использовать личный ключ, специально предназначенный для этой цели. Вырабатываемая ЭЦП включается в штамп времени как значение компонента signature, вложенного в значение типа SignerInfo (см. СТБ 34.101.23 (подраздел 8.4)). Штамп времени ДОЛЖЕН содержать только ЭЦП, выработанную данной СШВ.

СШВ МОЖЕТ использовать для подписи штампов времени разные личные ключи, которые, например, могут иметь разную длину, использоваться для применения различных политик, алгоритмов выработки подписи или для увеличения производительности обработки запросов.

СОК СШВ ДОЛЖЕН содержать только один экземпляр расширения ExtKeyUsageSyntax со значением id-kp-timeStamping компонента типа KeyPurposeId (см. СТБ 34.101.19 (пункт 6.2.1)). Данное расширение ДОЛЖНО быть критическим.

Штамп времени ДОЛЖЕН содержать ссылку на СОК СШВ, представленную значением типа ESSCertID или ESSCertIDv2 в атрибуте SigningCertificate (см. СТБ 34.101.80 (пункт 9.2.4), атрибут описывается либо одноименным типом АСН.1, либо типом SigningCertificateV2). При формировании значения типа ESSCertIDv2 ДОЛЖЕН использоваться алгоритм хэширования, определенный в действующем ТНПА. Атрибут SigningCertificate ДОЛЖЕН включаться в значение типа SignerInfo как подписываемый атрибут. Данный атрибут МОЖЕТ в дополнение к ссылке на СОК СШВ содержать ссылки на другие СОК (например, ссылку на СОК УЦ). В случае если атрибут содержит список ссылок на СОК, ссылка на СОК СШВ ДОЛЖНА быть первой в списке.

Если в запрос был включен компонент certReq со значением TRUE (см. 7.1), то СОК СШВ, который соответствует ссылке, заданной в штампе времени значением типа ESSCertID или ESSCertIDv2 в атрибуте SigningCertificate, ДОЛЖЕН быть представлен в компоненте certificates, вложенном в SignedData (см. СТБ 34.101.23 ( подраздел 8.4)). При этом компонент certificates может также содержать и другие СОК (например, СОК УЦ). Если же компонент certReq не был включен в запрос или был включен в запрос со значением FALSE, то компонент certificates НЕЛЬЗЯ включать в SignedData.

8 Способы обмена сообщениями

8.1 Обмен сообщениями с использованием электронной почты

При обмене сообщениями протокола постановки штампа времени с использованием электронной почты для передачи запроса используется объект MIME, у которого заголовки Content-Type и Content-Transfer-Encoding содержат значения application/timestamp-query и base64 соответственно (см. [4]), а телом является запрос, закодированный по отличительным правилам и преобразованный после кодирования по правилам base64 (см. [5]). В свою очередь, для передачи ответа используется объект MIME, у которого заголовки Content-Type и Content-Transfer-Encoding содержат значения application/timestamp-reply и base64 соответственно, а телом является ответ, закодированный по отличительным правилам и преобразованный после кодирования по правилам base64. Данные объекты MIME могут быть отправлены и получены с помощью обычных обработчиков MIME. Они предоставляют возможность обмена сообщениями протокола постановки штампа времени с использованием электронной почты через интернет.

Для объектов MIME, у которых заголовок Content-Type, определяющий тип содержимого, содержит значение application/timestamp-query или application/timestamp-reply, СЛЕДУЕТ включать необязательные параметры name (см. [6]) и filename (см. [7]). Включение параметра filename, определяющего имя файла, позволит сохранить тип передаваемой информации, когда запросы и ответы протокола постановки штампа времени сохраняются в файлы. Если параметры name и filename включаются в объект MIME, то для объекта с типом содержимого application/timestamp-query СЛЕДУЕТ задавать имя файла с расширением «.TSQ», а для объекта с типом содержимого application/timestamp-reply – имя файла с расширением «.TSR». Кроме того, имя файла СЛЕДУЕТ ограничивать восемью символами с последующими тремя символами расширения. Восемь символов основы имени файла могут быть любым уникальным именем.

8.2 Обмен сообщениями с использованием файлов

Обмен сообщениями протокола постановки штампа времени может производиться посредством передачи файлов, например, по протоколу FTP [8]. Файл с сообщением протокола постановки штампа времени ДОЛЖЕН содержать только закодированное по отличительным правилам сообщение протокола, т.е. в данном файле не должно быть какой-либо дополнительной информации кроме запроса или ответа протокола.

Запрос протокола постановки штампа времени СЛЕДУЕТ размещать в файле с расширением «.tsq», а ответ – в файле с расширением «.tsr».

8.3 Обмен сообщениями с использованием сокетов

Обмен сообщениями протокола постановки штампа времени с использованием сокетов основан на протоколе TCP [9]. Данный способ обмена, как правило, предполагает, что на СШВ запущен процесс, который ожидает получения сообщений протокола постановки штампа времени на известный IP-порт (обычно с номером 318). Сторона, инициирующая выполнение протокола, связывается с этим IP-портом и направляет запрос протокола постановки штампа времени. После получения запроса СШВ возвращает ответ протокола постановки штампа времени и/или ссылочный номер, который может быть использован позже для получения от СШВ необходимого ответа.

Если в ответ на запрос от СШВ должна быть возвращена последовательность сообщений (например, если до формирования и возврата ответа протокола постановки штампа времени требуется отправка квитанции), то вместе с требуемыми данными возвращается и новый ссылочный номер. При этом новый ссылочный номер не возвращается, если передается результирующее сообщение протокола постановки штампа времени.

Сообщения, которыми обмениваются стороны с использованием сокета, включают следующие последовательные поля: длину (4 октета), флаг (1 октет), данные (переменной длины). Поле длины содержит число октетов оставшейся части сообщения (т.е. число октетов данных, увеличенное на единицу). Для значений, состоящих из 4 октетов, первый октет считается старшим, последний – младшим. Такой порядок октетов называется сетевым или «от старших к младшим» (big-endian). Обозначение сообщений, а также описание используемых для них флагов и данных приведено в таблице 1.

Таблица 1 – Сообщения и их значения

Наименование сообщения	Флаг	Данные	Примечание
`tsaMsg`	0	Закодированный по отличительным правилам запрос протокола постановки штампа времени	Запрос на получение штампа времени
`pollRep`	1	Ссылочный номер (4 октета), время до отправки следующего сообщения (4 октета)	Ответное сообщение, когда ответ протокола пока не может быть возвращен. Для повторного запроса штампа времени необходимо использовать указанный ссылочный номер
`pollReq`	2	Ссылочный номер (4 октета)	Повторный запрос на получение штампа времени
`negPollRep`	3	Значение 0 (1 октет)	Ответное сообщение, когда данные для отправки отсутствуют (т.е. транзакция уже завершена)
`partialMsgRep`	4	Ссылочный номер (4 октета), время до отправки следующего сообщения (4 октета), часть ответа протокола постановки штампа времени (ответ предварительно кодируется по отличительным правилам)	Ответное сообщение, когда передается часть ответа протокола и новый ссылочный номер. Для получения следующей части ответа необходимо использовать указанный ссылочный номер
`finalMsgRep`	5	Заключительная часть ответа протокола постановки штампа времени или ответ протокола постановки штампа времени целиком (ответ предварительно кодируется по отличительным правилам)	Ответное сообщение, когда передается заключительная часть ответа протокола или ответ протокола целиком
`errorMsgRep`	6	Сообщение об ошибке в удобном для восприятия пользователем виде	Ответное сообщение, когда обнаружена ошибка (например, в случае получения некорректного ссылочного номера)

При выполнении протокола постановки штампа времени с использованием сокетов возможны следующие последовательности сообщений:

а) сторона, инициирующая протокол, посылает сообщение tsaMsg и получает в ответ одно из следующих сообщений: pollRep, negPollRep, partialMsgRep или finalMsgRep;

б) сторона, инициирующая протокол, посылает ранее полученное сообщение pollReq и получает в ответ одно из следующих сообщений: negPollRep, partialMsgRep, finalMsgRep, errorMsgRep.

В сообщениях pollRep и partialMsgRep время до отправки следующего сообщения представляется как беззнаковое целое число из четырех октетов и определяет минимальный интервал в секундах, по прошествии которого клиенту СЛЕДУЕТ отправить следующее сообщение.

8.4 Обмен сообщениями с использованием протокола HTTP

При обмене сообщениями протокола постановки штампа времени с использованием протокола HTTP [10] для передачи запроса используется объект MIME, у которого заголовок Content-Type содержит значение application/timestamp-query (см. [4]), а телом является передаваемый запрос, закодированный по отличительным правилам. В свою очередь, для передачи ответа используется объект MIME, у которого заголовок Content-Type содержит значение application/timestamp-reply, а телом является возвращаемый ответ, закодированный по отличительным правилам. Данные объекты MIME могут быть отправлены и получены с помощью обычных обработчиков HTTP через интернет. Они предоставляют возможность обмена сообщениями протокола постановки штампа времени с использованием браузеров. При получении корректного запроса СШВ ДОЛЖНА возвратить либо корректный ответ протокола постановки штампа времени в виде объекта MIME с заголовком Content-Type, содержащим значение application/timestamp-reply, либо ошибку HTTP.

9 Рассмотрение вопросов безопасности

Факторы, влияющие на безопасность протокола постановки штампов времени, рассматриваются в различных разделах настоящего стандарта. В данном разделе рассматриваются дополнительные факторы безопасности, которые влияют на доверие к штампам времени.

Если личный ключ, используемый СШВ для подписи штампов времени, был скомпрометирован, то соответствующий СОК ДОЛЖЕН быть отозван. При отзыве расширение reasonCode может включаться или не включаться в СОС для СОК СШВ. Если оно включается, то кодом причины отзыва ДОЛЖНО указываться значение keyCompromise (1). Учитывая, что с использованием скомпрометированного личного ключа СШВ могут быть выпущены штампы времени на дату в прошлом, любые штампы времени, подписанные скомпрометированным личным ключом, ДОЛЖНЫ признаваться недействительными за исключением случаев, указанных в СТБ 34.101.80 (подразделе 8.2). В связи с этим, личный ключ, используемый СШВ для подписи штампов времени, должен храниться и использоваться с соблюдением высоких мер безопасности с целью минимизации вероятности его компрометации. В случае компрометации личного ключа СШВ для различия подлинных и ложных штампов времени МОЖЕТ использоваться журнал аудита, в котором фиксируются выпущенные службой штампы. Другим способом решения проблемы различия подлинных и ложных штампов является одновременное использование нескольких штампов, выданных различными СШВ.

В случае если дальнейшее использование СШВ не предполагается, СОК СШВ ДОЛЖЕН быть отозван. Если при отзыве расширение reasonCode (см. СТБ 34.101.19 (подраздел 7.3)) включается в СОС для соответствующего СОК СШВ, то кодом причины отзыва ДОЛЖНО указываться одно из следующих значений: unspecified (0), affiliationChanged (3), superseded (4) или cessationOfOperation (5). В этом случае, в любой момент времени в будущем, штампы времени, подписанные соответствующим личным ключом, будут признаваться недействительными, но штампы времени, выпущенные до момента отзыва СОК СШВ, будут оставаться действительными. Если расширение reasonCode не включается в СОС для СОК СШВ, то все штампы времени, подписанные соответствующим личным ключом, ДОЛЖНЫ обрабатываться таким же образом, как при отзыве СОК СШВ по причине компрометации личного ключа. В связи с этим, при отзыве СОК СШВ РЕКОМЕНДУЕТСЯ включать расширение reasonCode в соответствующую запись СОС.

Личный ключ, используемый СШВ для подписи штампов времени, ДОЛЖЕН иметь длину, которая бы позволяла использовать ключ достаточно длительное время. Но даже при этом данный ключ будет иметь ограниченный срок действия. Для продления доверия к штампу времени СШВ СЛЕДУЕТ выпустить новый штамп времени, который может быть как связан, так и не связан с ранее выпущенным штампом времени (связывание старого штампа времени с новым может производиться, например, путем включения старого штампа времени в виде определенного расширения нового штампа времени).

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

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

Отправитель запроса может получить несколько ответов на свой запрос. Повторы ответов могут происходить непреднамеренно или умышленно. Непреднамеренные повторы возникают, например, при сбоях в сетевом оборудовании, приводящих к отправке в СШВ более одной копии одного и того же запроса. Умышленные повторы совершаются злоумышленником, который, например, повторно отправляет ответ СШВ. Для обнаружения повторов могут применяться различные способы. Одним из таких способов является включение в запрос компонента nonce. Другим способом обнаружения повторов является использование значения локального времени и определение для запроса временного интервала, в течение которого отправитель запроса хранит у себя включенное в запрос хэш-значение. При получении ответа отправитель запроса проверяет, что время получения ответа располагается в пределах заданного временного интервала и что для данного временного интервала получен только один ответ, который содержит штамп времени с хэш-значением, указанным в запросе. Если для некоторого временного интервала получено несколько штампов времени с одним и тем же хэш-значением, вычисленным с использованием одного и того же алгоритма хэширования, то для определения соответствия ответа запросу отправителю запроса следует либо использовать значение компонента nonce, либо подождать, пока данный временной интервал не закончится, и выполнить повторный запрос.

Приложение А (обязательное)

Модуль АСН.1

PKIXTSP {iso(1) identified-organization(3) dod(6) internet(1)
  security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-tsp(13)}
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
  -- EXPORTS ALL --
  IMPORTS
    Extensions, AlgorithmIdentifier 
      FROM PKIX1Explicit88 {iso(1) identified-organization(3) dod(6) 
        internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
        id-pkix1-explicit-88(1)}
    GeneralName 
      FROM PKIX1Implicit88 {iso(1) identified-organization(3) dod(6) 
        internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) 
        id-pkix1-implicit-88(2)}
    ContentInfo 
      FROM CryptographicMessageSyntax {iso(1) member-body(2) us(840) 
        rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) modules(0) cms(1)}
    PKIFreeText 
      FROM PKIXCMP {iso(1) identified-organization(3) dod(6) internet(1) 
       security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-cmp(9)};

  id-ct-TSTInfo OBJECT IDENTIFIER ::= {iso(1) member-body(2)
    us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

  TimeStampReq ::= SEQUENCE {
    version         INTEGER { v1(1) },
    messageImprint  MessageImprint,
    reqPolicy       TSAPolicyId OPTIONAL,
    nonce           INTEGER OPTIONAL,
    certReq         BOOLEAN DEFAULT FALSE,
    extensions      [0] IMPLICIT Extensions OPTIONAL
  }

  MessageImprint ::= SEQUENCE {
    hashAlgorithm  AlgorithmIdentifier,
    hashedMessage  OCTET STRING
  }

  TSAPolicyId ::= OBJECT IDENTIFIER

  TimeStampResp ::= SEQUENCE {
    status          PKIStatusInfo,
    timeStampToken  TimeStampToken OPTIONAL
  }

  PKIStatusInfo ::= SEQUENCE {
    status        PKIStatus,
    statusString  PKIFreeText OPTIONAL,
    failInfo      PKIFailureInfo OPTIONAL
  }

  PKIStatus ::= INTEGER {
    granted (0),
    grantedWithMods (1),
    rejection (2),
    waiting (3),
    revocationWarning (4),
    revocationNotification (5)
  }

  PKIFailureInfo ::= BIT STRING {
    badAlg (0),
    badRequest (2),
    badDataFormat (5),
    timeNotAvailable (14),
    unacceptedPolicy (15),
    unacceptedExtension (16),
    addInfoNotAvailable (17),
    systemFailure (25)
  }

  TimeStampToken ::= ContentInfo

  TSTInfo ::= SEQUENCE {
    version         INTEGER {v1(1)},
    policy          TSAPolicyId,
    messageImprint  MessageImprint,
    serialNumber    INTEGER,
    genTime         GeneralizedTime,
    accuracy        Accuracy OPTIONAL,
    ordering        BOOLEAN DEFAULT FALSE,
    nonce           INTEGER OPTIONAL,
    tsa             [0] GeneralName OPTIONAL,
    extensions      [1] IMPLICIT Extensions OPTIONAL
  }

  Accuracy ::= SEQUENCE {
    seconds  INTEGER OPTIONAL,
    millis   [0] INTEGER (1..999) OPTIONAL,
    micros   [1] INTEGER (1..999) OPTIONAL
  }
END

Библиография

[1] Adams C., Cain P., Pinkas D., Zuccherato R. Internet X.509 Public Key Infrastructure. Time-Stamp Protocol (TSP). Request for Comments: 3161, 2001 (Интернет-инфраструктура открытых ключей X.509. Протокол постановки штампа времени)

[2] Santesson S., Pope N. ESSCertIDv2 Update for RFC 3161. Request for Comments: 5816, 2010 (Обновление ESSCertIDv2 для RFC 3161)

[3] Adams C., Farrell S. Internet X.509 Public Key Infrastructure. Certificate Management Protocols. Request for Comments: 2510, 1999 (Интернет-инфраструктура открытых ключей X.509. Протоколы управления сертификатом)

[4] Freed N., Borenstein N. Multipurpose Internet Mail Extensions (MIME). Part One: Format of Internet Message Bodies. Request for Comments: 2045, 1996 (Универсальные расширения интернет-почты (MIME). Часть 1: Формат содержимого интернет-сообщений)

[5] Josefsson S. The Base16, Base32, and Base64 Data Encodings. Request for Comments: 4648, 2006 (Системы кодирования Base16, Base32 и Base64)

[6] Masinter L. Returning Values from Forms: multipart/form-data. Request for Comments: 7578, 2015 (Возвращаемые из форм значения: multipart/form-data)

[7] Troost R., Dorner S., Moore K. Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field. Request for Comments: 2183, 1997 (Передача информации о представлении данных в интернет-сообщениях: заголовок Content-Disposition)

[8] Postel J., Reynolds J. File transfer protocol (FTP). Request for Comments: 959, 1985 (Протокол передачи файла (FTP))

[9] Transmission control protocol. Request for Comments: 793, 1981 (Протокол TCP)

[10] Fielding R., Gettys J., Mogul J., Frystyk H., Masinter L., Leach P., Berners-Lee T. Hypertext Transfer Protocol – HTTP/1.1. Request for Comments: 2616, 1999 (Протокол передачи гипертекста – HTTP/1.1)

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

tsp.md

tsp.md

Содержание

1 Область применения

2 Нормативные ссылки

3 Термины и определения

4 Обозначения и сокращения

5 Общие положения

6 Сообщения протокола

7 Форматы запроса и ответа

7.1 Формат запроса

7.2 Формат ответа

8 Способы обмена сообщениями

8.1 Обмен сообщениями с использованием электронной почты

8.2 Обмен сообщениями с использованием файлов

8.3 Обмен сообщениями с использованием сокетов

8.4 Обмен сообщениями с использованием протокола HTTP

9 Рассмотрение вопросов безопасности

Приложение А (обязательное)

Модуль АСН.1

Библиография

Files

tsp.md

Latest commit

History

tsp.md

File metadata and controls

Содержание

1 Область применения

2 Нормативные ссылки

3 Термины и определения

4 Обозначения и сокращения

5 Общие положения

6 Сообщения протокола

7 Форматы запроса и ответа

7.1 Формат запроса

7.2 Формат ответа

8 Способы обмена сообщениями

8.1 Обмен сообщениями с использованием электронной почты

8.2 Обмен сообщениями с использованием файлов

8.3 Обмен сообщениями с использованием сокетов

8.4 Обмен сообщениями с использованием протокола HTTP

9 Рассмотрение вопросов безопасности

Приложение А (обязательное)

Модуль АСН.1

Библиография