Метка времени не прошла проверку что это
Результат проверки ЭП : Метка времени не прошла проверку или один или несколько сертификатов не прошли проверку
Часто судебный пристав подписывает документы электронной подписью и нарушает условия которые делают документ действительным, что повышает шансы на его оспаривание. Данный текст позволяет понять, что нарушено.
Вопрос: «Не могу понять, где эта сама метка времени в документе, то есть видна ли она на бумажной распечатке. В документе стоит только дата, время не указано, на том же месте, где обычно в бумажных документах. Откуда система взяла дату и время в сформированном штампике?
Ответ: «При проставлении ЭЦП она ее взяла. Момент подписи гарантированно отмечается. И в штрихкоде точное время, скорее всего, есть. Но без системы считывания штрихкодов именно ФСП и судов узнать этого не получится)
Для суда достаточно того, что метка времени изменена. А на минуты или сутки-не важно, это делает недействительной подпись документа.
Вариантов «как было на самом деле» множество. Текст документа не менялся, но ему изменили дату или взяли ранее подписанный документ с верной датой и изменили текст. Дата и текст изменены вместе. В конце концов:все верно, только время локальное на компьютере отличалось от правильного на десяток минут.
Итог один-это не доверенная подпись и она не заверяет документ, а лишь позволяет точно идентифицировать носитель ЭЦП (заметьте-даже не собственно пристава, он может заявить, что дал носитель коллеге).»
Постановление судебного пристава подписанное ЭЦП (нормы закона)
Частью 2 статьи 14 Федерального закона «Об исполнительном производстве» установлены требования, предъявляемые к постановлениям судебного пристава.
Частью 2 данной статьи установлено, что в постановлении судебного пристава-исполнителя или иного должностного лица службы судебных приставов должны быть указаны:
1) наименование подразделения судебных приставов и его адрес;
2) дата вынесения постановления;
3) должность, фамилия и инициалы лица, вынесшего постановление;
4) наименование и номер исполнительного производства, по которому выносится постановление;
5) вопрос, по которому выносится постановление;
6) основания принимаемого решения со ссылкой на федеральные законы и иные нормативные правовые акты;
7) решение, принятое по рассматриваемому вопросу;
8) порядок обжалования постановления.
В соответствии с п. 2.1 ст. 14 Федеральный закон от 02.10.2007 №229-ФЗ «Об исполнительном производстве» Постановление судебного пристава-исполнителя или иного должностного лица службы судебных приставов может быть вынесено в форме электронного документа, подписанного усиленной квалифицированной электронной подписью судебного пристава-исполнителя или иного должностного лица службы судебных приставов в порядке, установленном законодательством Российской Федерации, и может быть направлено адресату в форме электронного документа, подписанного усиленной квалифицированной электронной подписью судебного пристава-исполнителя или иного должностного лица службы судебных приставов, в том числе с использованием Единого портала государственных и муниципальных услуг с учетом Правил оказания услуг почтовой связи. Требования к формату постановления судебного пристава-исполнителя или иного должностного лица службы судебных приставов, вынесенного в форме электронного документа, устанавливаются Федеральной службой судебных приставов.
Приказ от 19 апреля 2018 года №148 «Об утверждении требований к формату постановления судебного пристава-исполнителя или иного должностного лица Федеральной службы судебных приставов, вынесенного в форме электронного документа» ФССП Минюста РФ утверждены следующие требования:
Постановление судебного пристава-исполнителя или иного должностного лица Федеральной службы судебных приставов, вынесенное в форме электронного документа, представляет собой электронный документ:
содержащий корневой элемент (блок) О1р и вложенные в него элементы (блоки, реквизиты), принадлежащие пространству имен:
http://www.fssprus.ru/namespace/order/2015/1 и определенные в приложении к настоящим требованиям;
подписанный одной или несколькими усиленными квалифицированными электронными подписями должностных лиц Федеральной службы судебных приставов в формате РКСS#7 (отделенная электронная подпись);
содержащий метку времени, наложенную в соответствии со спецификацией Internet Х.509 Public Key infrastructure Time-Stamp Protocol (TSP) и в соответствии со спецификацией CAdES-T (ETSI TS 101 733 «CMS Advansed Electronic Signatures CadES).»
В соответствии с пунктом 1 статьи 2 Федерального закона от 06.04.2011г. № 63-ФЗ «Об электронной подписи» (далее – Закон об электронной подписи) под электронной подписью понимается информация в электронной форме, которая присоединена к другой информации в электронной форме (подписываемой информации) или иным образом связана с такой информацией и которая используется для определения лица, подписывающего информацию.
Одним из понятий, используемым в Законе об электронной подписи является сертификат ключа проверки электронной подписи, которым в силу пункта 2 статьи 2 Закона об электронной подписи является электронный документ или документ на бумажном носителе, выданные удостоверяющим центром либо доверенным лицом удостоверяющего центра и подтверждающие принадлежность ключа проверки электронной подписи владельцу сертификата ключа проверки электронной подписи.
Статьей 11 Закона об электронной подписи установлено, что квалифицированная электронная подпись признается действительной до тех пор, пока решением суда не установлено иное, при одновременном соблюдении следующих условий:
1) квалифицированный сертификат создан и выдан аккредитованным удостоверяющим центром, аккредитация которого действительна на день выдачи указанного сертификата;
2) квалифицированный сертификат действителен на момент подписания электронного документа (при наличии достоверной информации о моменте подписания электронного документа) или на день проверки действительности указанного сертификата, если момент подписания электронного документа не определен;
3) имеется положительный результат проверки принадлежности владельцу квалифицированного сертификата квалифицированной электронной подписи, с помощью которой подписан электронный документ, и подтверждено отсутствие изменений, внесенных в этот документ после его подписания. При этом проверка осуществляется с использованием средств электронной подписи, имеющих подтверждение соответствия требованиям, установленным в соответствии с настоящим Федеральным законом, и с использованием квалифицированного сертификата лица, подписавшего электронный документ;
4) квалифицированная электронная подпись используется с учетом ограничений, содержащихся в квалифицированном сертификате лица, подписывающего электронный документ (если такие ограничения установлены).
Минакова Юлия
бухгалтер
Метка времени не прошла проверку
Результат проверки ЭП: Метка времени не прошла проверку? Что это означает? Спасибо.
Добрый вечер, Наталья!
Это значит, что ЭП уже не действительна.
Кроме заверения документов электронной подписью, вы можете удостоверять точное время их создания.
Использование меток времени в электронном документообороте позволит вам создавать официальное доказательство факта существования документа на определённый момент времени.
Что такое метка времени
Метка времени — это подписанный ЭЦП документ, которым Служба метки времени удостоверяет, что в указанный момент времени ей было предоставлено значение хэш-функции от документа. Само значение хэш-функции также указывается в метке.
С помощью метки времени можно проверять:
Достоверность времени создания документа
Метка времени на документе удостоверяет точное время создания этого документа для того, чтобы в последующем разрешать конфликты, связанные с его использованием. Таким образом, с помощью метки времени вы обеспечиваете неотрекаемость автора документа от своей подписи.
Сохранность актуальности электронной подписи
Наличие метки времени в подписанном документе позволяет продлевать срок действия электронной подписи. Такой штамп удостоверяет, например, что подпись была создана до того, как сертификат ключа подписи был аннулирован (отозван). Таким образом, для проверки подписи, созданной до момента отзыва сертификата, вы можете использовать уже отозванный сертификат. Цепочка меток времени позволяет создавать системы архивного хранения электронных документов, сохраняющие актуальность ЭЦП в документах. В ином случае, актуальность подписанного документа ограничена сроком действия сертификата ключа подписи.
Усовершенствованная электронная подпись
Электронная подпись необходима для визирования различного рода документации. Усовершенствованная ЭП содержит данные о времени создания визирования (TSP) и статусе сертификата (OCSP) в момент его изменения (отозван он или находится в действующем состоянии).
Время подписи синхронизируется с сервером точного времени, который расположен в УЦ. Для того, чтобы это было возможно, в момент подписания документа посылается сигнал на сервер и формируется метка точного времени, которая фиксируется в подписи.
Усовершенствованная электронная подпись имеет правовую подоплеку, благодаря цифровой квитанции, которую выдает удостоверяющий центр. Данная квитанция формируется в момент подписи благодаря OCSP. В документе фиксируется статус и ставится отметка времени, которая подтверждает целостность файла на этапе проверки. Статус хранится в ЭП.
Для чего применяют усовершенствованную цифровую подпись?
Благодаря ЭП можно подтвердить юридический статус документа при возникновении различных споров. Такие ситуации чаще всего возникают, к примеру, для доказательства авторства или целостности файла. В таких случаях очень важно знать точное время подписания.
Подлинность усовершенствованной ЭП можно проверить даже спустя долгий период времени, кроме того, она действительна и по истечению срока действия сертификата.
В современном цифровом документообороте применение подписи с меткой времени считается необходимым условием для государственных служб, к примеру, для таможенного контроля Федерального значения.
Где применяют усовершенствованную электронную подпись?
Усовершенствованная ЭП используется в специально разработанных системах цифрового документооборота, где есть физическая возможность просмотра отметки времени.
Использование усовершенствованной электронной подписи сможет надежно защитить документы и разрешить любые спорные вопросы.
Сервер доверенного времени (TSA, timestamp)
Для получения доступа к серверу доверенного времени необходимо скачать TSA-клиент, заполнив форму ниже.
Доступ к сервису привязывается к Вашему внешнему IP-адресу.
При попытке подключиться с другого адреса доступ будет запрещён. В этом случае скачайте TSA-клиент заново из того места, откуда пытаетесь подключиться.
Для Вашего удобства Ваш текущий внешний IP-адрес показан на странице.
В настоящий момент доступ к серверу доверенного времени осуществляется бесплатно. Это продлится до окончания промо-периода, о завершении которого будет сообщено дополнительно. В этой связи убедительно просим указывать актуальный e-mail.
Что такое доверенное время?
Предположим, у Вас есть некоторые данные или файл. С помощью доверенного времени (TSA, timestamp) Вы можете получить свидетельство того, что именно эти данные в этот момент есть у Вас. В будущем наличие такого свидетельства поможет доказать, например, Ваше авторство этого файла. Поскольку Вы-автор, у Вас данный файл окажется раньше всех, и это будет подтверждено подписанной электронной подписью меткой времени, которая была получена от сервера доверенного времени. Если позже кто-то скопировал этот файл и также получил доверенный timestamp, в его метке будет указано более позднее время. Соответственно, при сравнении этих меток будет очевидно, что Ваш файл был создан раньше.
Другой пример использования — электронные аукционы. Нередко возникает ситуация, когда важно точно определить последовательность поданных заявок. От этого может решиться судьба лота или контракта. В этом случае метка доверенного времени позволит определить точную последовательность поданных заявок, своего рода фотофиниш.
Кроме того, метка доверенного времени (timestamp) стала неотъемлемой составляющей каждого запроса в систему Государственной информационной системы о государственных и муниципальных платежах (ГИС ГМП) Федерального казначейства России. Соответственно, Вы можете использовать нашу службу для выставления меток TSA. Однако следует учесть тот факт, что от нас Вы получаете только метку времени, составление же полноценного XAdES вверяется полностью Вам в руки.
Работает все это следующим образом. Сначала, с помощью специальных криптографических средств, вычисляется хэш от файла. Затем на основании этого хэша формируется запрос на получение метки времени. Запрос отправляется на сервер, который извлекает из него хэш, добавляет к нему точное время и подписывает всё это своим закрытым ключом. Полученный таким образом ответ возвращается пользователю.
Каким образом наличие метки доверенного времени доказывает наличие у Вас именно этого файла строго в определённый момент в прошлом? Дело в том, что внутри метки имеется уникальный хэш Вашего файла и точное время, которое указал сервер. «Неподдельность», фактически отсутствие изменений в метке после того, как она была сформирована сервером, доказывается его электронной подписью (ЭП) в метке — если метка будет изменена после подписания, подпись ей соответствовать не будет и факт подлога станет очевиден.
Насколько точно идут наши часы?
RFC 3161 требует наличия у сервера TSA источника точного времени. Поэтому наш сервер оборудован высокоточными часами, которые постоянно синхронизируются с сигналами точного времени, получаемыми от спутников навигационных систем ГЛОНАСС и GPS.
Получение метки времени
Метку доверенного времени можно получить от нашего сервера с помощью TSA-клиента, форма для скачивания которого находится в начале страницы. После скачивания Вам потребуется лишь запустить скрипт TSAreq.bat из командной строки Windows, указав ему в качестве параметра файл для подписи. Например, так: TSAreq.bat test.txt
Дальше TSA-клиент сделает всё сам. Метка времени будет записана в отдельный файл — tsreply.
Проверка подлинности метки времени
Для того, чтобы проверить, что метка времени не поддельная, а действительно была выдана сервером, Вам понадобится сертификат Удостоверяющего Центра, который выдал серверу сертификат его ключа (tsaca.crt, находится в подкаталоге crypto архива).
Для проверки подлинности метки нужно выполнить скрипт TSAverify.bat из командной строки Windows:
Появилась ошибка «Не удалось отправить запрос на штамп времени»
При работе с электронной подписью появилось сообщение «Не удалось отправить запрос на штамп времени».
Причина №1. Работу блокирует антивирусная программа
Настройте антивирусы и программы-блокировщики на работу со СБИС3 Плагином.
Причина №2. Не настроено (или настроено некорректно) подключение к прокси-серверу
Настройте прокси-сервер для работы со СБИС3 Плагином.
Причина №3. Работа https запрещена политиками безопасности
Причина №4. Не установлены обновления для ОС
Перейдите в «Панель управления/Система и безопасность/Центр обновления Windows» и установите все доступные обновления.
Причина №5. Установлены два криптопровайдера
На одном компьютере нельзя работать с несколькими СКЗИ. Удалите оба и заново установите основной криптопровайдер.
Решение №6. Повреждена СКЗИ
Переустановите СКЗИ, например, КриптоПро. При этом все поврежденные библиотеки, используемые для безопасности ОС, будут заменены. Прибегать к переустановке СКЗИ следует только в «крайнем» случае, когда вы испробовали все описанные способы ее устранения.
Использование ПАК «КриптоПро TSP» позволяет участникам информационных систем получать штампы времени, связанные с электронными документами. Штамп времени представляет из себя электронный документ, подписанный электронной цифровой подписью (электронной подписью), где подписанными данными являются значение хэш-функции электронного документа и время предоставления штампа времени. Таким образом, штамп времени однозначно связан с электронным документом, на который он выдается и обеспечивает его целостность.
Для реализации сервиса TSP необходимо на базе «КриптоПро TSP Server» организовать Сервер службы TSP и встроить «КриптоПро TSP Client» в программное обеспечение клиентских рабочих мест. Встраивание «КриптоПро TSP Client» осуществляется с использованием инструментария разработчика – «КриптоПро PKI SDK».
Для чего нужны штампы времени
Краткое описание протокола TSP
Протокол TSP (Time-Stamp Protocol) является протоколом типа «запрос-ответ». Весь обмен заключается в двух сообщениях. Клиент инициирует взаимодействие, посылая серверу запрос на штамп времени, на что сервер возвращает ответ, содержащий выпущенный штамп или не содержащий его в случае ошибки.
Запрос на штамп времени
Запрос на штамп времени включает следующие поля:
Идентификатор политики определяет, по какой политике должен быть выдан штамп времени. Политики штампов времени задаются сервером штампов времени и устанавливают набор правил, по которым выдаются штампы времени, а также области их применения.
Например, в системе может быть определено несколько политик с разными идентификаторами и следующим описанием:
Поле Nonce позволяет клиенту проверить своевременность полученного ответа, в котором сервер штампов времени должен разместить то же самое значение nonce, которое было в запросе.
Ответ сервера штампов времени
Ответ сервера штампов времени содержит следующие поля:
Штамп времени представляет собой CMS-сообщение (PKCS#7) типа SignedData (см. RFC 3369 «Cryptographic Message Syntax (CMS)»). Содержимым этого сообщения является структура со следующими полями:
Сервер штампов указывает признак ordering, если он работает в режиме строгой упорядоченности штампов. Т.е. сравнение времён двух выданных этим серверов штампов даже без учёта точности времени определяет порядок их выдачи.
Как хранить штампы времени совместно с документами
В RFC 3161 «Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)» описан вариант хранения штампа времени на документ с ЭЦП (ЭП) формата CMS SignedData в неподписанном атрибуте этого CMS-сообщения.
Для организации долговременного архивного хранения документов с ЭЦП (ЭП) могут использоваться штампы времени, а также дополнительные данные, необходимые для подтверждения подлинности ЭЦП (ЭП) – так называемые доказательства подлинности ЭЦП (ЭП). К таковым относятся:
Для обеспечения актуальности ЭЦП (ЭП) при долговременном хранении необходимо периодически получать новые штампы времени.
Возможный вариант форматов данных и идентификаторы атрибутов для долговременного хранения документов с ЭЦП (ЭП) на основе CMS-сообщений описаны в европейском стандарте CAdES (ETSI TS 101 733). Версия этого стандарта опубликована в виде RFC 5126 «CMS Advanced Electronic Signatures (CAdES)».
Time Stamp Protocol
Time stamp protocol (протокол штампа времени) или TSP — это криптографический протокол, позволяющий создавать доказательство факта существования электронного документа на определённый момент времени.
«Штамп времени» (англ. time-stamp) — это документ, подписанный электронной подписью (ЭП). Этим документом «центр штампов времени» удостоверяет, что в определённый момент времени ему был предоставлен результат вычисления хеш-функции от содержимого документа, факт существования которого необходимо подтвердить. Результат вычисления хеш-функции и момент времени указываются в «штампе».
«Центр штампов времени» (англ. time stamping authority, TSA) — доверенный субъект PKI, обладающий точным и надёжным источником времени и оказывающий услуги по созданию «штампов времени».
Результат вычисления хеш-функции от содержимого документа, на который получен «штамп времени», служит для связывания «штампа» с документом. «Центр штампов времени» не узнает содержимое документа, так как в «штамп времени» включается только результат вычисления хеш-функции от содержимого документа (сохраняется конфиденциальность документа).
Метка времени не прошла проверку что это
Об актуальных изменениях в КС узнаете, став участником программы, разработанной совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу выдаются удостоверения установленного образца.
Программа разработана совместно с АО «Сбербанк-АСТ». Слушателям, успешно освоившим программу, выдаются удостоверения установленного образца.
Обзор документа
Приказ Министерства цифрового развития, связи и массовых коммуникаций РФ от 6 ноября 2020 г. № 580 «Об утверждении порядка создания и проверки метки доверенного времени»
В соответствии с пунктом 19 статьи 2 Федерального закона от 6 апреля 2011 г. № 63-ФЗ «Об электронной подписи» (Собрание законодательства Российской Федерации, 2011, № 15, ст. 2036; 2019, № 52, ст. 7794) и пунктом 1 Положения о Министерстве цифрового развития, связи и массовых коммуникаций Российской Федерации, утвержденного постановлением Правительства Российской Федерации от 2 июня 2008 г. № 418 (Собрание законодательства Российской Федерации, 2008, № 23, ст. 27.08; 2018, № 40, ст. 6142), приказываю:
1. Утвердить прилагаемый порядок создания и проверки метки доверенного времени.
2. Направить настоящий приказ на государственную регистрацию в Министерство юстиции Российской Федерации.
3. Настоящий приказ вступает в силу с 1 января 2021 г. и действует до 1 января 2027 г.
Зарегистрировано в Минюсте РФ 28 декабря 2020 г.
УТВЕРЖДЕН
приказом Министерства цифрового
развития, связи и массовых
коммуникаций
Российской Федерации
от 06.11.2020 г. № 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 TSAPolicyId OPTIONAL,
nonce INTEGER OPTIONAL,
certReq BOOLEAN DEFAULT FALSE,
extensions [0] IMPLICIT Extensions OPTIONAL >
Поля структуры TimeStampReq должны быть заполнены следующим образом:
version | — | поле version описывает версию запроса штампа времени. Поле version должно иметь значение 1; | |
---|---|---|---|
messagelmprint | — | поле messagelmprint должно представлять собой структуру типа Messagelmprint. Структура Messagelmprint должна выглядеть следующим образом: Messagelmprint ::= SEQUENCE < | |
hashAlgorithm | Algorithmldentifier, | ||
hashedMessage | OCTET STRING> | ||
Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле PKIFailurelnfo, если хэш-алгоритм не распознан. Поле hashedMessage структуры Messagelmprint должно содержать хэш-значение от данных, для которых требуется штамп времени. Служба штампов времени проверяет совпадение длины хэш-значения с длиной, установленной примененным хэш-алгоритмом, идентификатор которого указан в поле Algorithmldentifier. По результатам такой проверки, в случае несовпадения указанных длин, служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение со значением badAlg в поле badDataFormat; | |||
reqPolicy | — | поле reqPolicy (при наличии) имеет тип TSAPolicyld и обозначает регламент службы штампов времени, согласно которому следует выдать TimeStampToken. TSAPolicyld определяется следующим образом: TSAPolicyld ::= OBJECT IDENTIFIER; | |
nonce | — | поле nonce (при наличии) имеет тип INTEGER и позволяет клиенту проверить актуальность ответа, когда локальное время недоступно. Значение поля nonce должно представлять собой уникальное 64-битное целое число, сгенерированное клиентом случайным образом. При отсутствии значения nonce в ответе, ответ клиентом должен отклонен; | |
certReq | — | поле certReq (при наличии) имеет тип BOOLEAN. Если поле certReq присутствует и имеет значение «true», сертификат ключа проверки подписи службы штампов времени должен быть помещен в поле certificates в структуре SignedData. Если поле certReq отсутствует и имеет значение «false», поле certificates в структуре SignedData в ответе службы штампов времени не указывается; | |
extensions | — | поле extensions (расширения) имеет тип Extensions и позволяет добавить дополнительную информацию в запрос. Служба штампов времени отказывает в выдаче штампа времени, возвращая сообщение об ошибке (unacceptedExtension), если поле Extensions не распознано. |
5) Ответ службы штампов времени должен представлять собой структуру
TimeStampResp и выглядеть следующим образом:
timeStampToken TimeStampToken OPTIONAL>
6) Структура PKIStatusInfo должна содержать информацию о статусе запроса к службе штампов времени и выглядеть следующим образом:
statusString PKIFreeText OPTIONAL,
failInfo PKIFailureInfo OPTIONAL >
Поле status имеет тип PKIStatus.
Поле statusString имеет тип PKIFreeText.
Поле failInfo имеет тип PKIFailureInfo.
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 содержит штамп времени и должна быть представлена следующим образом:
— должно содержать то же значение, что и поле TimeStampReq
— сторона, запрашивающая штамп времени, должна принимать целые числа
accuracy Accuracy OPTIONAL,
ordering BOOLEAN DEFAULT FALSE,
nonce INTEGER OPTIONAL,
— должно присутствовать, если аналогичное поле имеется в
— TimeStampReq. В этом случае поле должно иметь то же значение,
tsa [0] GeneralName OPTIONAL,
extensions [1] IMPLICIT Extensions OPTIONAL>
12) Поля структуры TSTInfo должны быть заполнены в соответствии со следующими требованиями:
13) Штамп времени не должен содержать иных подписей, кроме подписи службы штампов времени.
Идентификатор сертификата службы штампов времени ESSCertIDv2 должен быть включен в атрибут SigningCertificateV2.
Атрибут SigningCertificateV2 является подписанным атрибутом и должен быть включен в поле signedAttrs структуры Signerlnfo.
Обзор документа
Минцифры определило правила создания и проверки метки доверенного времени. Этот механизм внедряется в России с 1 января 2021 г. Метка доверенного времени представляет собой достоверную информацию в электронной форме о дате и времени подписания электронного документа электронной подписью.
Метка доверенного времени создается доверенной третьей стороной, удостоверяющим центром или оператором информационной системы с использованием программных и (или) аппаратных средств, прошедших процедуру подтверждения соответствия установленным требованиям.
Приказ вступает в силу с 1 января 2021 г. и действует до 1 января 2027 г.