Приказ Минцифры России от 06.11.2020 № 580

«Об утверждении порядка создания и проверки метки доверенного времени»

(Зарегистрировано в Минюсте России 28.12.2020 № 61867)

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

ПРИКАЗ от 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 г.

Министр М. И. Шадаев

и массовых коммуникаций Российской Федерации от 06.11.2020 № 580

ПОРЯДОК СОЗДАНИЯ И ПРОВЕРКИ МЕТКИ ДОВЕРЕННОГО ВРЕМЕНИ

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

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

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

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

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

6. Службы меток доверенного времени, создаваемые доверенной третьей стороной или удостоверяющим центром, при создании метки доверенного времени должны получать информацию о точном значении времени с учетом часового пояса и календарной дате от технических средств передачи эталонных сигналов времени и частоты, а также информацию о точном значении времени и календарной дате (далее — технические средства передачи эталонных сигналов времени), функционирующих в соответствии с Положением о Государственной службе времени, частоты и определения параметров вращения Земли, утвержденным постановлением Правительства Российской Федерации от 23 марта 2001 г. № 225 (Собрание законодательства Российской Федерации, 2001, № 14, ст. 1361; 2018, № 49, ст. 7600). В метку времени заносятся значения о точном значении времени в соответствии со всемирным координированным временем (далее — UTC).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. В первом сообщении обмена в рамках данного протокола запрашивающая сторона посылает в службу штампов времени запрос на штамп времени (далее — TimeStampReq). Во втором сообщении служба штампов времени отвечает запрашивающей стороне сообщением (далее — TimeStampResp).

При получении TimeStampResp, содержащего штамп времени (далее — TimeStampToken), запрашивающая сторона должна проверить ответ на ошибки о состоянии и, если их нет, проверить различные поля в TimeStampToken, а также действительность электронной подписи, которой подписан TimeStampToken, и убедиться, что данные с проставленным штампом времени соответствуют отправленным данным. Запрашивающая сторона должна проверить, что TimeStampToken содержит правильный идентификатор сертификата службы штампов времени (ESSCertIDv2), правильное хэш-значение (hashedMessage) и правильный идентификатор алгоритма хэширования (hashAlgorithm) в поле messageImprint.

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

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

TimeStampReq::= SEQUENCE {

version          INTEGER { v1(1)},
messageImprint      MessageImprint,

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

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

reqPolicy       TSAPolicyId           OPTIONAL,
nonce          INTEGER               OPTIONAL,
certReq         BOOLEAN               DEFAULT FALSE,
extensions      [0] IMPLICIT Extensions OPTIONAL}

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

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

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

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

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

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

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

Поле failInfo имеет тип PKIFailureInfo.

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

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

PKIStatus::= INTEGER {

granted

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

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

grantedWithMods

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

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

rejection

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

waiting

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

revocation Warning

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

revocationNotification

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

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

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

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

PKIFailureInfo::= BIT STRING {

badAlg

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

badRequest

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

badDataFormat

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

timeNotAvailable

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

unacceptedPolicy

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

unacceptedExtension

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

addlnfoNotAvailable

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

systemFailure

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

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

TimeStampToken::= ContentInfo

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

-- content is SignedData (P 1323565.1.025-2019)

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

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

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

• в поле eContentType — следующий объектный идентификатор штампа времени:

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 — штамп времени в виде строки октетов (OCTET STRING). Значение поля eContent должно быть результатом DER-кодирования структуры TSTInfo.

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

TSTInfo::= SEQUENCE {

 version         INTEGER { v1(1)},
 policy          TSAPolicyId,
 messageImprint     MessageImprint,

-- должно содержать то же значение, что и поле TimeStampReq

 serialNumber      INTEGER,
 -- сторона,  запрашивающая  штамп  времени,  должна  принимать целые числа

длиной до 160 бит.

 genTime           GeneralizedTime,
 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 структуры SignerInfo.