Метка доверенного времени как выглядит

Доверенная среда хранения, доверенная третья сторона, метки доверенного времени. Использование для юридически значимого архивного хранения

Рассмотрим инструменты, которые можно будет использовать для сохранения юридической значимости электронных архивных документов в ближайшее время.

Михаил Александров, аналитик DIRECTUM

При оценке целесообразности перехода на электронный документооборот обязательно возникает вопрос организации архивного хранения документов. Особенно это актуально для кадрового делопроизводства, где некоторые документы нужно хранить по 50 и более лет. Помимо облегчения оперативной информационной системы, архив обеспечивает доступ к электронным документам на протяжении всего срока их хранения: они могут потребоваться как самому владельцу, так и регуляторам или сторонним организациям.

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

● Воспроизводимость документа обеспечивается конвертацией в новый формат;

● Целостность и юридическая значимость могут быть закрыты механизмами ЭП;

● Доступность данных – задача как прикладной логики системы, так и политик системного администрирования.

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

Доверенная среда хранения

В обязанности оператора ДСХ должен входить весь цикл архивных работ по принятию и дальнейшему сопровождению электронных документов:

● своевременная конвертация в актуальные форматы воспроизведения для обеспечения человекочитаемости документа;

● предоставление дубликатов хранимых документов как в электронном варианте, так и на материальных носителях;

● своевременное гарантированное уничтожение данных по требованию заявителя, согласно условиям договора или по истечении сроков хранения.

Таким образом, документы на обслуживании у оператора ДСХ должны сохранять свою юридическую значимость, а какими средствами планируется это обеспечивать – пока неизвестно. Операторы ДСХ, как и удостоверяющие центры, должны будут проходить государственною аккредитацию соответствия, иметь гарантийный капитал и нести ответственность за свою деятельность.

Однако готов ли бизнес доверить чувствительную документацию третьему лицу – открытый вопрос.

Доверенная третья сторона

Следующий инструмент, с помощью которого можно обеспечить юридическую значимость электронного документа – «оператор доверенной третьей стороны (ДТС)». Официально такое определение ещё не введено, в российской нормативной базе он должен появиться с введением правок в ФЗ-63 об ЭП вместе с «меткой доверенного времени» и «облачной ЭП».

Доверенная третья сторона – опыт не новый, практика уже наработана у наших партнеров по Таможенному союзу – Республик Беларусь и Казахстан. Изначально инструмент ориентирован на использование при трансграничном обмене электронными документами и используется для подтверждения действительности подписи, выданной удостоверяющим центром (УЦ) другой страны.

В качестве подтверждения операции проверки подписи ДТС генерирует и предоставляет DVCS-квитанцию (от англ. «Data Validation and Certification Server» – сервер сертификации и валидации данных). Это специальный электронный документ, сформированный и подписанный ДТС. Квитанция содержит сведения об исходном документе, результаты его проверки и данные о времени выполнения проверки (так называемая «метка времени ДТС»), информацию о подписанте и УЦ, то есть весь необходимый набор данных для проверки электронной подписи в документе.

Таким образом, DVCS-квитанции имеет смысл использовать для фиксации наличия юридической силы документа на момент проверки его доверенной третьей стороной. Согласно требованиям п.2, ст.11 ФЗ-63 «Об электронной подписи» усиленная квалифицированная электронная подпись (УКЭП) действительна либо на момент проверки, либо должны иметься доказательства её действительности на момент подписания. ДТС и будет выступать гарантом доверенного времени установки ЭП на документ. При необходимости длительного хранения, у ДТС можно запросить продление выданной им DVCS-квитанции на срок, не превышающий срок действия сертификата ключа проверки подписи сервиса ДТС.

Резюме: В отличие от доверенной стороны хранения, доверенная третья сторона передает не тела документов, а только контрольные суммы от них. С одной стороны, это повысит доверие к сервису, с другой, вопросы сохранности документов, предоставления и конвертации ложатся на владельца, его систему и инфраструктуру в целом.

Также стоит учесть, что поскольку ДТС – незаинтересованный внешний сервис, его услуги вряд ли будут бесплатными.

Метки доверенного времени

С помощью меток (или штампов) доверенного времени (timestamp) владелец документа может получить свидетельство того, что именно эти данные в этот момент времени у него есть — то есть наличие метки времени может выступать доказательством существования определённой информации на момент, зафиксированный поставщиком меток.

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

Для обеспечения юридической значимости документов метки доверенного времени включают в состав усовершенствованных электронных подписей. Это ЭП, формируемые по стандартизированным форматам, например, CAdES для откреплённых ЭП или XAdES для XML-документов с встроенной ЭП.

Процесс формирования метки времени выглядит так:

1. Подписание электронного документа

2. Проверка ЭП по времени поставщика меток

3. Предоставление метки времени

4. Усовершенствование подписи с включением метки

Резюме: В отличие от применения доверенной третьей стороны, при работе с «сырыми» метками времени на владельца информации накладываются требования по получению этих меток и включению их в ЭП или иные электронные документы, используемые для обеспечения работы электронного архива.

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

Заключение

С учётом принятия новых законопроектов в части электронного документооборота спектр средств для работы с электронными документами и подписями официально расширится.

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

Источник

ФСБ объяснила, какой в России должна быть правильная электронная подпись

Цифровые «штампы времени»

Федеральная служба безопасности (ФСБ) России представила список новых и уточняющих требований, которые предъявляются к средствам электронной подписи и оборудованию удостоверяющих центров (УЦ). Проект соответствующего приказа выложен на портале правовых актов regulation.gov.ru.

Документ, в частности, дает определение службы «меток доверенного времени», которые также называют «цифровым штампом времени». Использование меток доверенного времени в электронной подписи определено законом №476-ФЗ «О внесении изменений в Федеральный закон «Об электронной подписи» от 27 декабря 2019 г. и вводится в России с 1 января 2021 г.

Структура меток и функции служб доверенного времени определены проектом указа Минцифры «Об утверждении порядка создания метки доверенного времени», который уже прошел публичное обсуждение и в настоящее находится на стадии формирования окончательного варианта текста правового акта.

Как работает метка доверенного времени

Обязательные требования к службе меток доверенного времени вводятся в России с 1 января 2021 г. в соответствии с требованиями ч 1.1 ст. 3 закона № 476-ФЗ «О внесении изменений в Федеральный закон «Об электронной подписи» от 27 декабря 2019 г. и ст. 1 закона «О защите прав юридических лиц и индивидуальных предпринимателей при осуществлении государственного контроля (надзора) и муниципального контроля».

Представленный в сентябре 2020 г. проект приказа «Об утверждении порядка создания метки доверенного времени», определяющий формат и структуру меток, был разработан Минцифры России в соответствии с п. 19 ст. закона №63-ФЗ «Об электронной подписи» ‎от 6 апреля 2011 г.

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

Техническая защита меток доверенного времени

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

Для механизмов формирования меток доверенного времени документом определяется возможность использования средств криптозащиты не ниже класса КС3, с защищенным хранением криптографических ключей в неэкспортируемом виде.

Дополнительная защита УЦ

Для УЦ также в обязательном порядке вводится механизм защиты от навязывания ложных сообщений и защита данных при передаче между физически разделенными компонентами с применением криптозащиты.

Для УЦ класса КА1 обязательным требованием отныне являются проверки техники иностранного производства на предмет «выявления устройств, предназначенных для негласного получения информации», поиск недекларированных возможностей оборудования, которые могли быть внесены на этапе разработки и производства, а также полная верификация аппаратной инфраструктуры УЦ для «исключения недекларированных возможностей».

Источник

Метка доверенного времени как выглядит

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

от 6 ноября 2020 года N 580

2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.

3. Настоящий приказ вступает в силу с 1 января 2021 г. и действует до 1 января 2027 г.

в Министерстве юстиции

28 декабря 2020 года,

регистрационный N 61867

УТВЕРЖДЕН
приказом Министерства цифрового
развития, связи и массовых
коммуникаций
Российской Федерации
от 6 ноября 2020 года N 580

Порядок создания и проверки метки доверенного времени

1. Настоящий Порядок определяет правила создания и проверки метки доверенного времени.

3. Создание метки доверенного времени осуществляется службой меток доверенного времени по запросу участников электронного взаимодействия путем подписания электронной подписью службы меток доверенного времени текущего достоверного значения времени в соответствии с требованиями к структуре метки доверенного времени.

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

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

7. Службы меток доверенного времени, создаваемые операторами информационных систем, получают информацию о дате и времени от технических средств передачи эталонных сигналов времени или от службы меток доверенного времени, указанных в пункте 6 настоящего Порядка, посредством информационно-телекоммуникационных сетей при условии обеспечения целостности передаваемой информации с использованием средств криптографической защиты информации, имеющих подтверждение соответствия требованиям, установленным согласно части 5 статьи 8 Федерального закона «Об электронной подписи».

8. Проверка метки доверенного времени осуществляется службой меток доверенного времени при проверке действительности электронной подписи с использованием средств, прошедших процедуру подтверждения соответствия требованиям, установленным согласно части 5 статьи 8 Федерального закона «Об электронной подписи» в следующем порядке:

1) служба меток доверенного времени проверяет математическую корректность электронной подписи;

2) служба меток доверенного времени проверяет применимость метки доверенного времени к электронной подписи, для которой данная метка доверенного времени создана;

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

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

9. Создание метки доверенного времени осуществляется в соответствии со следующими требованиями:

2) Служба штампов времени при создании метки времени должна:

использовать значение UTC;

включать достоверное значение времени в каждый штамп;

включать уникальное целое число в каждый новый штамп;

создавать штамп при получении запроса от запрашивающей стороны, когда это возможно;

включать в каждый штамп времени идентификатор политики безопасности (регламента), согласно которой он был создан;

ставить штамп времени только для хэш-значения, вычисленного с использованием устойчивой однонаправленной хэш-функции;

проверять соответствие длины хэш-значения длине, определенной в алгоритме хэширования, идентификатор которого указан в запросе к TSA;

не подвергать хэш-значение, которому присвоен штамп, какой-либо проверке (кроме проверки его длины, как это указано в предыдущем пункте);

не включать в штампы времени какую-либо информацию, идентифицирующую запрашивающую сторону;

подписывать каждый штамп времени ключом, сгенерированным специально для этой цели;

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

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

4) Запрос к службе штампов времени должен представлять собой структуру типа TimeStampReq:

— OID алгоритма хэширования и хэш-значение от данных, для которых

— требуется штамп времени

reqPolicy TSAPolicyld OPTIONAL,

nonce INTEGER OPTIONAL,

certReq BOOLEAN DEFAULT FALSE,

extensions [0] IMPLICIT Extensions OPTIONAL >

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

поле version описывает версию запроса штампа времени. Поле version должно иметь значение 1;

hashedMessage OCTET STRING >

Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле PKIFailurelnfo, если хэш-алгоритм не распознан.

Поле hashedMessage структуры Messagelmprint должно содержать хэш-значение от данных, для которых требуется штамп времени.

Служба штампов времени проверяет совпадение длины хэш-значения с длиной, установленной примененным хэш-алгоритмом, идентификатор которого указан в поле Algorithmldentifier.

По результатам такой проверки, в случае несовпадения указанных длин, служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле badDataFormat;

поле reqPolicy (при наличии) имеет тип TSAPolicyld и обозначает регламент службы штампов времени, согласно которому следует выдать TimeStampToken. TSAPolicyld определяется следующим образом:

TSAPolicyld ::= OBJECT IDENTIFIER;

поле nonce (при наличии) имеет тип INTEGER и позволяет клиенту проверить актуальность ответа, когда локальное время недоступно. Значение поля nonce должно представлять собой уникальное 64-битное целое число, сгенерированное клиентом случайным образом. При отсутствии значения nonce в ответе, ответ клиентом должен отклонен;

поле certReq (при наличии) имеет тип BOOLEAN. Если поле certReq присутствует и имеет значение «true», сертификат ключа проверки подписи службы штампов времени должен быть помещен в поле certificates в структуре SignedData.

Если поле certReq отсутствует и имеет значение «false», поле certificates в структуре SignedData в ответе службы штампов времени не указывается;

поле extensions (расширения) имеет тип Extensions и позволяет добавить дополнительную информацию в запрос.

Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение об ошибке (unacceptedExtension), если поле Extensions не распознано.

5) Ответ службы штампов времени должен представлять собой структуру TimeStampResp и выглядеть следующим образом:

timeStampToken TimeStampToken OPTIONAL >

6) Структура PKIStatusInfo должна содержать информацию о статусе запроса к службе штампов времени и выглядеть следующим образом:

statusString PKIFreeText OPTIONAL,

faillnfo PKIFailurelnfo OPTIONAL >

Поле status имеет тип PKIStatus.

Поле statusString имеет тип PKIFreeText.

Поле faillnfo имеет тип PKIFailurelnfo.

7) Тип PKIStatus структуры PKIStatusInfo должен представлять собой числовое значение, определяющее статус службы штампов времени. Если значение равно 0 или 1, штамп времени TimeStampToken должен присутствовать. Если присутствует иное значение (кроме 0 или 1), штамп времени TimeStampToken недолжен присутствовать.

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

— когда PKIStatus содержит значение 0, TimeStampToken

— присутствует, как и запрашивалось.

— когда PKIStatus содержит значение 1, TimeStampToken

Источник

Что такое метка доверенного времени

Метка доверенного времени — информация в электронной форме о дате и времени подписания документа электронной подписью, создаваемая и проверяемая доверенной третьей стороной, удостоверяющим центром или оператором информационной системы (ч. 19 ст. 2 закона «Об электронной подписи» от 06.04.2011 № 63-ФЗ, далее — закон об ЭП).

Метка доверенного времени — часть обновленной системы электронных подписей, вместе с доверенной третьей стороной. Узнать больше о доверенной третьей стороне для электронной подписи можно в системе КонсультантПлюс. Зайдите в систему с помощью ссылки на бесплатный пробный доступ или запросите прайс для постоянного использования полной версии системы.

Обратите внимание! Применение меток доверенного времени и обязательные требования к службе меток доверенного времени введены в России с 01.01.2021 (ч. 1.1 ст. 3 закона «О внесении изменений…» от 27.12.2019 № 476-ФЗ).

В последующем никто (в т. ч. владелец) не сможет внести изменение в метку доверенного времени после ее создания, при условии что ее целостность не будет нарушена.

Порядок создания и проверки метки регламентирован приказом Министерства цифрового развития, связи и массовых коммуникаций РФ от 06.11.2020 № 580.

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

Метка доверенного времени может быть присоединена к электронному документу или связана с ним иным способом.

Процесс формирования метки доверенного времени

Этот процесс с технической точки зрения выглядит так:

Проверка метки доверенного времени

Служба меток доверенного времени проводит проверку меток по следующей схеме:

Зачем нужна метка доверенного времени

Применение метки доверенного времени позволяет проверить правомерность и достоверность использования электронной подписи. Также подписант не сможет исправить вручную в электронном документе дату и время проставления подписи. Все это позволит минимизировать неправомерные действия с ЭП.

Когда уместно использовать метку доверенного времени:

Итак, метка доверенного времени — информация в электронной форме о дате и времени проставления в документе электронной подписи. Служит для удостоверения актуальности ЭП в документе. Положения о метке доверенного времени вступили в силу с 01.01.2021.

Источник

Приказ Министерства цифрового развития, связи и массовых коммуникаций РФ от 6 ноября 2020 г. N 580 «Об утверждении порядка создания и проверки метки доверенного времени»

В соответствии с пунктом 19 статьи 2 Федерального закона от 6 апреля 2011 г. N 63-ФЗ «Об электронной подписи» (Собрание законодательства Российской Федерации, 2011, N 15, ст. 2036; 2019, N 52, ст. 7794) и пунктом 1 Положения о Министерстве цифрового развития, связи и массовых коммуникаций Российской Федерации, утвержденного постановлением Правительства Российской Федерации от 2 июня 2008 г. N 418 (Собрание законодательства Российской Федерации, 2008, N 23, ст. 27.08; 2018, N 40, ст. 6142), приказываю:

1. Утвердить прилагаемый порядок создания и проверки метки доверенного времени.

2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.

3. Настоящий приказ вступает в силу с 1 января 2021 г. и действует до 1 января 2027 г.

Зарегистрировано в Минюсте РФ 28 декабря 2020 г.

Регистрационный N 61867

УТВЕРЖДЕН
приказом Министерства цифрового
развития, связи и массовых
коммуникаций
Российской Федерации
от 06.11.2020 г. N 580

Порядок
создания и проверки метки доверенного времени

1. Настоящий Порядок определяет правила создания и проверки метки доверенного времени.

3. Создание метки доверенного времени осуществляется службой меток доверенного времени по запросу участников электронного взаимодействия путем подписания электронной подписью службы меток доверенного времени текущего достоверного значения времени в соответствии с требованиями к структуре метки доверенного времени.

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

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

7. Службы меток доверенного времени, создаваемые операторами информационных систем, получают информацию о дате и времени от технических средств передачи эталонных сигналов времени или от службы меток доверенного времени, указанных в пункте 6 настоящего Порядка, посредством информационно-телекоммуникационных сетей при условии обеспечения целостности передаваемой информации с использованием средств криптографической защиты информации, имеющих подтверждение соответствия требованиям, установленным согласно части 5 статьи 8 Федерального закона «Об электронной подписи».

8. Проверка метки доверенного времени осуществляется службой меток доверенного времени при проверке действительности электронной подписи с использованием средств, прошедших процедуру подтверждения соответствия требованиям, установленным согласно части 5 статьи 8 Федерального закона «Об электронной подписи» в следующем порядке:

1) служба меток доверенного времени проверяет математическую корректность электронной подписи;

2) служба меток доверенного времени проверяет применимость метки доверенного времени к электронной подписи, для которой данная метка доверенного времени создана;

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

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

9. Создание метки доверенного времени осуществляется в соответствии со следующими требованиями:

2) Служба штампов времени при создании метки времени должна:

использовать значение UTC;

включать достоверное значение времени в каждый штамп;

включать уникальное целое число в каждый новый штамп;

создавать штамп при получении запроса от запрашивающей стороны, когда это возможно;

включать в каждый штамп времени идентификатор политики безопасности (регламента), согласно которой он был создан;

ставить штамп времени только для хэш-значения, вычисленного с использованием устойчивой однонаправленной хэш-функции;

проверять соответствие длины хэш-значения длине, определенной в алгоритме хэширования, идентификатор которого указан в запросе к TSA;

не подвергать хэш-значение, которому присвоен штамп, какой-либо проверке (кроме проверки его длины, как это указано в предыдущем пункте);

не включать в штампы времени какую-либо информацию, идентифицирующую запрашивающую сторону;

подписывать каждый штамп времени ключом, сгенерированным специально для этой цели;

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

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

4) Запрос к службе штампов времени должен представлять собой структуру типа TimeStampReq:

— OID алгоритма хэширования и хэш-значение от данных, для которых

— требуется штамп времени

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

поле version описывает версию запроса штампа времени. Поле version должно иметь значение 1;

поле messagelmprint должно представлять собой структуру типа Messagelmprint. Структура Messagelmprint должна выглядеть следующим образом:

Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле PKIFailurelnfo, если хэш-алгоритм не распознан.

Поле hashedMessage структуры Messagelmprint должно содержать хэш-значение от данных, для которых требуется штамп времени. Служба штампов времени проверяет совпадение длины хэш-значения с длиной, установленной примененным хэш-алгоритмом, идентификатор которого указан в поле Algorithmldentifier.

По результатам такой проверки, в случае несовпадения указанных длин, служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле badDataFormat;

поле reqPolicy (при наличии) имеет тип TSAPolicyld и обозначает регламент службы штампов времени, согласно которому следует выдать TimeStampToken. TSAPolicyld определяется следующим образом:

TSAPolicyld ::= OBJECT IDENTIFIER;

поле nonce (при наличии) имеет тип INTEGER и позволяет клиенту проверить актуальность ответа, когда локальное время недоступно. Значение поля nonce должно представлять собой уникальное 64-битное целое число, сгенерированное клиентом случайным образом. При отсутствии значения nonce в ответе, ответ клиентом должен отклонен;

поле certReq (при наличии) имеет тип BOOLEAN. Если поле certReq присутствует и имеет значение «true», сертификат ключа проверки подписи службы штампов времени должен быть помещен в поле certificates в структуре SignedData.

Если поле certReq отсутствует и имеет значение «false», поле certificates в структуре SignedData в ответе службы штампов времени не указывается;

поле extensions (расширения) имеет тип Extensions и позволяет добавить дополнительную информацию в запрос.

Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение об ошибке (unacceptedExtension), если поле Extensions не распознано.

5) Ответ службы штампов времени должен представлять собой структуру

6) Структура PKIStatusInfo должна содержать информацию о статусе запроса к службе штампов времени и выглядеть следующим образом:

7) Тип PKIStatus структуры PKIStatusInfo должен представлять собой числовое значение, определяющее статус службы штампов времени. Если значение равно 0 или 1, штамп времени TimeStampToken должен присутствовать. Если присутствует иное значение (кроме 0 или 1), штамп времени TimeStampToken не должен присутствовать.

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

— когда PKIStatus содержит значение 0, TimeStampToken

— присутствует, как и запрашивалось.

— когда PKIStatus содержит значение 1, TimeStampToken

— присутствует с изменениями.

— штамп времени не получен, причина указана в информационном сообщении

— запрос штампа времени еще не обработан, дополнительная информация ожидается позже,

— это сообщение предупреждает о том, что аннулирование неизбежно revocationNotification

— уведомление о том, что аннулирование имело место.

8) Тип PKIFreeText структуры PKIStatusInfo должен представлять собой объяснение причины отклонения запроса штампа времени в виде текста.

9) Тип PKIFailurelnfo структуры PKIStatusInfo должен представлять собой числовое значение, определяющее тип произошедшей ошибки. Если TimeStampToken отсутствует, PKIFailurelnfo показывает причину отклонения запроса штампа времени.

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

PKIFailurelnfo ::= BIT STRING <

— нераспознанный или неподдерживаемый идентификатор алгоритма

— транзакция не разрешена или не поддерживается

— отправленные данные имеют неверный формат

— источник времени в службе штампов времени недоступен

— служба штампов времени не поддерживает запрашиваемую политику безопасности

— служба штампов времени не поддерживает запрашиваемое расширение

— запрашиваемая дополнительная информация не распознается или недоступна

— запрос не может быть обработан вследствие ошибки системы.

10) Структура TimeStampToken содержит штамп времени и должна представлять собой структуру типа Contentlnfo, где поле contentType должно содержать идентификатор типа содержимого «Подписанные данные» signed-data, а поле content должно содержать соответствующую структуру SignedData. Штамп времени TimeStampToken должен выглядеть следующим образом:

— contentType is id-signedData (P 1323565.1.025-2019)

— content is SignedData (P 1323565.1.025-2019)

Настоящие требования определяют дополнительные условия к содержимому следующих полей структуры SignedData:

— поля signedAttrs, входящего в структуру Signerlnfo, включающего в себя подписанный атрибут, содержащий идентификатор сертификата TSA.

11) Поле encapContentlnfo структуры SignedData должно представлять собой структуру типа EncapsulatedContentlnfo. В него необходимо включать следующие значения:

us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4>;

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

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

поле version имеет тип INTEGER и описывает версию запроса штампа времени. Поле version должно иметь значение 1.

Запрашивающая сторона должна распознавать штампы времени версии 1;

поле policy имеет тип TSAPolicyId и должно обозначать политику безопасности (регламент службы штампов времени, в рамках которой был дан ответ). Если в TimeStampReq присутствует поле reqPolicy, оно должно иметь то же значение, иначе должна быть возвращена ошибка unacceptedPolicy.

Поле policy содержит:

— условия использования штампа времени;

— информацию о доступности журнала штампов времени для проверки подлинности штампа времени;

поле messagelmprint имеет тип MessageImprint и должно иметь то же значение, что и поле messagelmprint в TimeStampReq;

поле serialNumber имеет тип INTEGER и является уникальным целым числом, присвоенным данной службой штампов времени каждому штампу времени TimeStampToken. Служба штампов времени обеспечивает уникальность этого числа в том числе в случаях сбоя в работе штампов времени;

поле genTime имеет тип GeneralizedTime и обозначает время создания штампа времени соответствующей службой, должно быть выражено в UTC.

Значения GeneralizedTime должны включать секунды. Следует использовать GeneralizedTime с точностью до секунд. В отличие от ограничений, поле GeneralizedTime может содержать и доли секунд.

Используется следующий синтаксис:

Предусмотрены следующие ограничения к DER-кодированию: 1) результат кодирования должен оканчиваться на Z. При этом десятичный знак, если он присутствует, представляется в виде точки.

2) полночь представляется в следующей форме: ГГГГММДД000000Z, где ГГГГММДД обозначает наступивший день;

поле accuracy должно представлять собой структуру типа Accuracy и обозначает отклонение времени от времени, значение которого содержится в поле GeneralizedTime. Структура Accuracy выглядит следующим образом:

Источник