ЗАТВЕРДЖЕНО |
{Вимоги втратили чинність на підставі Наказу Міністерства юстиції № 3563/5/610 від 18.11.2019}
ВИМОГИ
до протоколу фіксування часу
{Із змінами, внесеними згідно з Наказами Міністерства юстиції
№ 914/5/268 від 17.05.2013
№ 1017/5/206 від 29.03.2017
№ 3599/5/618 від 17.11.2017}
1.1. Ці Вимоги визначають процедури формування та перевірки позначки часу, формати даних та протоколи взаємодії суб’єктів у сфері послуг електронного цифрового підпису (далі - ЕЦП) під час надання послуги фіксування часу.
1.2. У цих Вимогах терміни вживаються у такому значенні:
верифікатор позначки часу - особа, яка виконує перевірку дійсності вже сформованої позначки часу електронного документа з метою отримання інформації про дійсність чи недійсність позначки часу;
користувач - особа, яка користується послугою фіксування часу з метою засвідчення наявності електронного документа (електронних даних) на певний момент часу (запитувач позначки часу);
позначка часу - сукупність електронних даних, створена за допомогою технічних засобів та засвідчена електронним цифровим підписом Центру, яка підтверджує наявність електронного документа (електронних даних) на певний момент часу;
послуга фіксування часу - процедура засвідчення наявності електронного документа (електронних даних) на певний момент часу шляхом додання до нього або логічного поєднання з ним позначки часу.
Інші терміни застосовуються у значеннях, наведених у Законі України “Про електронний цифровий підпис”, Порядку засвідчення наявності електронного документа (електронних даних) на певний момент часу, затвердженому постановою Кабінету Міністрів України від 26 травня 2004 року № 680, Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13 липня 2004 року № 903, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 13 січня 2005 року № 3 (у редакції наказу Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 10 травня 2006 року № 50), зареєстрованих у Міністерстві юстиції України 27 січня 2005 року за № 104/10384, інших нормативно-правових актах з питань криптографічного та технічного захисту інформації.
1.3. Формати даних представлено у нотації ASN.1, визначеній у міжнародному стандарті ISO/IEC 8824 “Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)” / ДСТУ ISO/ІЕС 8824-3:2008 “Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1)” - частина 3. Специфікація обмежень (ISO/IEC 8824-3:2002, IDT), затвердженому наказом Державного комітету України з питань технічного регулювання та споживчої політики від 26 грудня 2008 року № 508 (із змінами).
Формати даних у нотації ASN.1, що застосовуються при реалізації протоколу фіксування часу, наведено у додатку 1 до цих Вимог.
1.4. Усі структури даних кодують за правилами DER згідно з міжнародним стандартом ISO/IEC 8825-1:2002 “Information technology - ASN.1 Encoding Rules - Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)”.
1.5. Ці Вимоги засновані на стандарті RFC 5652 “Cryptographic Message Syntax (CMS)”, а також RFC 3161 “Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)” та національному стандарті України ДСТУ ISO/ІЕС 18014-1:2006 “Інформаційні технології. Методи захисту. Послуги штемпелювання часу. Частина 1. Основні положення” (ISO/ІЕС 18014-1:2002, IDT), затвердженому наказом Державного комітету України з питань технічного регулювання та споживчої політики від 27 грудня 2006 року № 375 (із змінами) (далі - ISO/ІЕС 18014).
1.6. Ці Вимоги не дублюють стандарти ISO/ІЕС 18014, RFC 5652 та RFC 3161, а описують положення цих стандартів та формати полів. У разі виникнення розбіжностей між положеннями зазначених стандартів та положеннями цих Вимог застосовуються положення цих Вимог.
1.7. Положення цих Вимог є обов’язковими для програмно-технічних комплексів акредитованих центрів сертифікації ключів та надійних засобів електронного цифрового підпису. Правильність реалізації протоколу фіксування часу у надійних засобах електронного цифрового підпису підтверджується сертифікатом відповідності або позитивним експертним висновком за результатами державної експертизи у сфері криптографічного захисту інформації.
1.8. Геш-функція обчислюється одним з криптоалгоритмів за:
ГОСТ 34.311-95 «Информационная технология. Криптографическая защита информации. Функция хэширования», затвердженим наказом Державного комітету України з питань технічного регулювання та споживчої політики від 21 жовтня 1997 року № 640 (далі – ГОСТ 34.311-95);
ДСТУ 7564:2014 «Інформаційні технології. Криптографічний захист інформації. Функція гешування», затвердженим наказом Міністерства економічного розвитку і торгівлі України від 02 грудня 2014 року № 1431 (далі - ДСТУ 7564-2014).
{Пункт 1.8 розділу I в редакції Наказу Міністерства юстиції № 1017/5/206 від 29.03.2017}
1.9. В операціях формування та перевіряння підпису при обчисленні значення геш-функції згідно з ГОСТ 34.311-95 повинен використовуватися довгостроковий ключовий елемент (далі - ДКЕ), зазначений у параметрах ключа підпису.
В усіх інших операціях обчислення значення геш-функції згідно з ГОСТ 34.311-95 повинен використовуватися ДКЕ № 1, наведений у додатку 1 до Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 12 червня 2007 року № 114 зареєстрованої в Міністерстві юстиції України 25 червня 2007 року за № 729/13996 (із змінами) (далі - ДКЕ № 1).
ДКЕ №1 використовується як ДКЕ “за умовчанням”.
Для сумісності з попередніми рішеннями при перевірці значення геш-функції згідно з ГОСТ 34.311-95 допускається використання ДКЕ, що вказаний у параметрах ключа підпису.
1.10. Для визначення алгоритму гешування згідно з ДСТУ 7564-2014 поле «algorithm» може мати такі значення:
Dstu7564(256) OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) alg(1) hash(2) Dstu7564(2) 1}
Dstu7564(384) OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) alg(1) hash(2) Dstu7564(2) 2}
Dstu7564(512) OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) alg(1) hash(2) Dstu7564(2) 3}
Поле «parameters» повинно бути відсутнє.
{Розділ I доповнено новим пунктом 1.10 згідно з Наказом Міністерства юстиції № 1017/5/206 від 29.03.2017}
1.11. При використанні функції гешування за ДСТУ 7564-2014 в операціях формування та перевіряння електронного цифрового підпису режим обчислення геш-значення визначається відповідно до Вимог до формату посиленого сертифіката відкритого ключа, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 20 серпня 2012 року № 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за № 1398/21710.
В усіх інших операціях обчислення значення геш-функції згідно з ДСТУ 7564-2014 рекомендується використовувати режим гешування з формуванням геш-значення завдовжки 256 бітів.
{Розділ I доповнено новим пунктом 1.11 згідно з Наказом Міністерства юстиції № 1017/5/206 від 29.03.2017}
II. Процедура формування позначки часу
2.1. Під час формування позначки часу користувач та Центр виконують такі дії:
2.1.1 користувач обчислює геш-значення від електронного документа (електронних даних), на який необхідно сформувати позначку часу;
2.1.2 користувач формує запит на формування позначки часу, який містить:
об’єктний ідентифікатор політики формування позначки часу (необов’язково);
ідентифікатор алгоритму гешування, що використовувався;
унікальний ідентифікатор запиту (необов’язково);
2.1.3 користувач передає сформований запит до Центру;
2.1.4 Центр перевіряє правильність формату запиту та виконує його обробку, формує позначку часу та відповідь, що містить цю позначку, чи відповідь з інформацією про відмову у формуванні позначки часу;
2.1.5 позначка часу містить такі дані:
об’єктний ідентифікатор політики формування позначки часу, що була використана;
геш-значення електронного документа (електронних даних), для яких було сформовано позначку;
додаткову інформацію про позначку часу;
електронний цифровий підпис (далі - ЕЦП), сформований за допомогою особистого ключа Центру сертифікації ключів, накладений на позначку часу;
2.1.6 Центр пересилає відповідь, що містить позначку часу, користувачеві;
2.1.7 користувач після отримання відповіді від Центру виконує такі дії:
перевіряє результат обробки у відповіді;
перевіряє, чи відповідає ім’я суб’єкта, що підписав позначку часу, імені Центру;
перевіряє, чи призначений сертифікат відкритого ключа Центру для формування позначки часу;
перевіряє чинність сертифіката відкритого ключа Центру;
перевіряє ЕЦП, що був накладений на позначку часу;
перевіряє відповідність даних електронного документа та даних, для яких була сформована позначка часу (шляхом порівняння обчисленого геш-значення електронного документа (електронних даних) та геш-значення, що записане у позначці часу);
додає позначку часу до електронного документа.
III. Процедура перевірки позначки часу
3.1. Перевірка позначки часу виконується верифікатором за допомогою сертифіката відкритого ключа Центру автономно, без взаємодії з Центром.
3.2. Верифікатор здійснює перевірку позначки часу, виконуючи при цьому такі дії:
отримує ідентифікаційну інформацію з позначки часу про Центр (інформацію, що однозначно ідентифікує сертифікат Центру);
за допомогою чинного (на момент формування позначки) сертифіката відкритого ключа Центру перевіряє ЕЦП, що був накладений на позначку часу;
перевіряє відповідність позначки часу та електронного документа (електронних даних), до якого вона була прикріплена (шляхом порівняння обчисленого геш-значення електронного документа (електронних даних) та геш-значення, що зберігається у позначці часу).
4.1. Запит на формування позначки часу має такий формат:
TimeStampReq ::= SEQUENCE { | ||
version | INTEGER { v1(1) }, | |
messageImprint | MessageImprint, | |
reqPolicy | TSAPolicyId OPTIONAL, | |
nonce | INTEGER OPTIONAL, | |
certReq | BOOLEAN DEFAULT FALSE, | |
extensions | [0] IMPLICIT Extensions OPTIONAL} | |
4.1.1. Поле “version” визначає версію формату запиту на формування позначки часу. Значення цього поля дорівнює “1”.
4.1.2. Поле “messageImprint” містить геш-значення від електронного документа (електронних даних), на які отримується позначка часу, та ідентифікатор алгоритму гешування.
Геш-значення від електронного документа (електронних даних), на які отримується позначка часу, має такий формат:
Поле “hashAlgorithm” визначає ідентифікатор алгоритму, за допомогою якого було отримано геш-значення.
Поле “hashedMessage” містить безпосередньо байти обчисленого гешу.
4.1.3. Поле «reqPolicy» містить об’єктний ідентифікатор політики формування позначок часу:
TSAPolicyId::=OBJECT IDENTIFIER
Можливі ідентифікатори для «TSAPolicyId» щодо застосування криптографічних алгоритмів підпису у відповіді на запит позначки часу:
ua-pki-TSPpolicyDSTU4145WithGost34311(PB) ::= OBJECT IDENTIFIER
{ua-pki(1.2.804.2.1.1.1) cp(2) TSPpolicy(3) 1} - для формування відповіді з цифровим підписом згідно з ДСТУ 4145-2002 «Інформаційні технології. Криптографічний захист інформації. Цифровий підпис, що ґрунтується на еліптичних кривих. Формування та перевіряння», затвердженим наказом Державного комітету України з питань технічного регулювання та споживчої політики від 28 грудня 2002 року № 31 (далі - ДСТУ 4145-2002) (поліноміальний базис), та геш-функцією згідно з ГОСТ 34.311-95;
{Абзац п’ятий підпункту 4.1.3 пункту 4.1 розділу IV із змінами, внесеними згідно з Наказом Міністерства юстиції № 3599/5/618 від 17.11.2017}
ua-pki-TSPpolicyDstu4145WithGost34311(ONB) ::= OBJECT IDENTIFIER
{ua-pki (1.2.804.2.1.1.1) cp(2) TSPpolicy(3) 3} - для формування відповіді з цифровим підписом згідно з ДСТУ 4145-2002 (оптимальний нормальний базис) та геш-функцією згідно з ГОСТ 34.311-95;
ua-pki- TSPpolicyDstu4145WithDstu7564(256) ::= OBJECT IDENTIFIER
{ua-pki(1.2.804.2.1.1.1) cp(2) TSPpolicy(3)
TSPpolicyDstu4145WithDstu7564(4) 1} - для формування відповіді з цифровим підписом згідно з ДСТУ 4145-2002 та геш-функцією згідно з ДСТУ 7564-2014 у режимі формування геш-значення завдовжки 256 бітів;
ua-pki- TSPpolicyDstu4145WithDstu7564(256) ::= OBJECT IDENTIFIER
{ua-pki(1.2.804.2.1.1.1) cp(2) TSPpolicy(3)
TSPpolicyDstu4145WithDstu7564(4) 2} - для формування відповіді з цифровим підписом згідно з ДСТУ 4145-2002 та геш-функцією згідно з ДСТУ 7564-2014 у режимі формування геш-значення завдовжки 384 біти;
ua-pki- TSPpolicyDstu4145WithDstu7564(256) ::= OBJECT IDENTIFIER
{ua-pki(1.2.804.2.1.1.1) cp(2) TSPpolicy(3)
TSPpolicyDstu4145WithDstu7564(4) 3} - для формування відповіді з цифровим підписом згідно з ДСТУ 4145-2002 та геш-функцією згідно з ДСТУ 7564-2014 у режимі формування геш-значення завдовжки 512 бітів;
«За умовчанням» використовується політика:
до 31 грудня 2021 року «ua-pki-TSPpolicyDstu4145WithGost34311(PB)»;
з 01 січня 2022 року «TSPpolicyDstu4145WithDstu7564(256)PB», або «TSPpolicyDstu4145WithDstu7564(384)PB», або «TSPpolicyDstu4145WithDstu7564(512)PB» відповідно до вимог Регламенту роботи центрального засвідчувального органу.
При обробці запиту позначки часу Центр визначає можливість застосування вказаного у запиті алгоритму та формує відповідь, якщо зазначений алгоритм (політика) підтримується, або помилку, якщо алгоритм не підтримується.
Якщо у запиті алгоритм не вказано або відсутнє поле «reqPolicy», відповідь формується за алгоритмом, що визначений як алгоритм «за умовчанням».
{Підпункт 4.1 3 пункту 4.3 розділу ІV в редакції Наказу Міністерства юстиції № 1017/5/206 від 29.03.2017}
4.1.4. Поле “nonce” містить унікальний ідентифікатор запиту.
4.1.5. Якщо в запиті на формування позначки часу присутнє поле “certReq” із значенням “TRUE”, Центр у відповіді повинен надати призначений для формування позначки часу сертифікат відкритого ключа Центру.
4.1.6. Поле “extensions” може містити розширення з додатковою інформацією про запит.
4.2. Формат відповіді на запит на формування позначки часу має такий вигляд:
4.2.1. Поле “status” містить результат обробки запиту на формування позначки часу.
PKIStatusInfo ::= SEQUENCE { | ||
status | PKIStatus, | |
statusString | PKIFreeText OPTIONAL, | |
failInfo | PKIFailureInfo OPTIONAL} | |
Тип “PKIStatusInfo” містить поля, що визначають результат формування (чи відмови у формуванні) позначки часу.
Поле “status” містить код операції формування позначки часу.
Можливі значення для типу “PKIStatus” наведені у додатку 2 до цих Вимог.
Необов’язкове поле “statusString” може містити текстовий опис статусу.
Необов’язкове поле “failInfo” може містити код помилки.
Можливі значення для типу “PKIFailureInfo” наведено у додатку 3 до цих Вимог.
4.2.2. Поле “timeStampToken” містить сформовану позначку часу або є відсутнім (у разі помилки або відмови у формуванні позначки часу).
Позначка часу зберігається у форматі “CMS ContentInfo” (відповідно до RFC 5652):
TimeStampToken ::= ContentInfo
Поля типу “ContentInfo” для зберігання позначки часу мають такі значення:
поле “contentType” містить об’єктний ідентифікатор:
id-signedData OBJECT IDENTIFIER::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7)2},
що визначає зміст поля “content” як поля, що містить дані з ЕЦП (тип “CMS SignedData”).
Поля типу “EncapsulatedContentInfo”, що містяться в типі “SignedData”, мають такі значення:
поле “eContentType” містить об’єктний ідентифікатор даних, що міститься в полі “content”. Для позначки часу це поле повинно мати таке значення:
id-ct-TSTInfo OBJECT IDENTIFIER::={iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1)4}
Поле “content” містить строку байтів, у якій міститься така структура (у DER-кодуванні):
TSTInfo ::= SEQUENCE { | ||
version | INTEGER { v1(1)}, | |
policy | TSAPolicyId, | |
messageImprint | MessageImprint, | |
serialNumber | INTEGER, | |
genTime | GeneralizedTime, | |
accuracy | Accuracy OPTIONAL, | |
nonce | INTEGER OPTIONAL, | |
tsa | [0]GeneralName OPTIONAL | |
extensions | [1]IMPLICIT Extensions OPTIONAL} | |
Поле “version” містить номер версії формату позначки часу (завжди дорівнює “1”).
Поле “policy” містить об’єктний ідентифікатор політики формування позначок часу.
Поле “messageImprint” містить геш-значення електронного документа (електронних даних), на які була отримана позначка часу. Значення поля “messageImprint” повинно відповідати значенню відповідного поля запиту на отримання позначки фіксування часу.
Поле “serialNumber” містить серійний номер позначки часу.
Поле “genTime” містить час формування позначки часу у форматі GMT.
Поле “nonce” може містити унікальний ідентифікатор (маркер) запиту, на який була сформована позначка часу. Це поле повинно бути присутнім у відповіді, якщо воно було присутнє у відповідному запиті.
Поле “extensions” може містити розширення із додатковою інформацією про позначку часу.
4.3. Рекомендовані політики формування позначки часу наведено у підпункті 4.1.3 пункту 4.1 розділу IV цих Вимог.
Позначка часу повинна бути сформована з використанням алгоритму відповідно до ідентифікатора політики, вказаного у запиті. Якщо ідентифікатор політики не визначено у запиті, то повинна використовуватися політика, яка визначена як політика “за умовчанням”.
4.4. Джерелом визначення точного часу є сервери точного часу, що пройшли відповідну атестацію органами державного контролю.
Час визначається з точністю не менше 1 секунди.
Час у позначці часу (поле “genTime”) кодується у форматі “GeneralizedTime” у вигляді рядка YYYYMMDDhhmmss[.s…]Z, де YYYYMMDD - дата (рік-місяць-день), а hhmmss - час (години-хвилини-секунди). Якщо потрібна точність більша ніж одна секунда, до запису додається дробова частина (десятковий запис долі однієї секунди). В записі дробової частини потрібно вилучати всі праві нулі; якщо дробова частина складається тільки з нулів, її потрібно пропускати разом із десятковою крапкою.
Запис часу обов’язково завершується літерою “Z” - вказівкою, що час записано відповідно до всесвітнього координованого часу (UTC).
4.5. Сертифікат відкритого ключа Центру, що використовується для формування позначок часу, повинен містити розширення “Уточнене призначення відкритого ключа” (“extendedKeyUsage”), в якому повинен бути зазначений лише один об’єктний ідентифікатор id-kp-timeStamping (id-kp 8).
id-kp-timeStamping OBJECT IDENTIFIER::={iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-kp(3) 8}
Зазначене розширення повинно бути критичним.
5.1. Для передачі запитів на формування позначок часу та отримання відповідей повинен застосовуватися транспортний протокол НТТP. У разі використання інших транспортних протоколів формати повідомлень цими Вимогами не регламентуються.
5.1.1. Передача запиту на формування позначки часу відбувається за допомогою методу POST протоколу HTTP.
5.1.2. Тип контента запиту формується таким чином:
Content-Type: application/timestamp-query
Блоки даних передаються як байти DER-кодування. Тип кодування контента запиту формується таким чином:
Content-Transfer-Encoding: binary
5.1.3. Тип контента відповіді формується таким чином:
Content-Type: application/timestamp-reply
Блоки даних передаються як байти DER-кодування. Тип кодування контента відповіді формується таким чином:
Content-Transfer-Encoding: binary
Директор Департаменту |
|
Директор Департаменту |
|
ФОРМАТИ
даних у нотації ASN.1, що застосовуються при реалізації протоколу фіксування часу
ua-PKI-TSP-policy ::=OBJECT IDENTIFIER {ua-pki(1.2.804.2.1.1.1) cp(2) TSPpolicy(3)}
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, | |
nonce | INTEGER OPTIONAL, | |
tsa | [0] GeneralName OPTIONAL, | |
extensions | [1] IMPLICIT Extensions OPTIONAL} | |
МОЖЛИВІ ЗНАЧЕННЯ
для типу “PKIStatus”
Константа | Числове значення | Опис |
granted | 0 | Позначку часу сформовано |
grantedWithMods | 1 | Позначку часу сформовано з модифікаціями |
rejection | 2 | У формуванні позначки часу було відмовлено |
waiting | 3 | Запит неможливо обробити у зв’язку із перенавантаженням |
revocationWarning | 4 | (Не використовується) |
revocationNotification | 5 | (Не використовується) |
МОЖЛИВІ ЗНАЧЕННЯ
для типу “PKIFailureInfo”
Константа | Номер біта | Опис |
badAlg | 0 | Невідомий алгоритм гешування або такий, що не підтримується |
badRequest | 2 | Запит такий, що не підтримується, або недозволений |
badDataFormat | 5 | Запит пошкоджений |
timeNotAvailable | 14 | Неможливо визначити точний час |
unacceptedPolicy | 15 | Політика формування позначок часу така, що не підтримується |
unacceptedExtension | 16 | Розширення таке, що не підтримується |
addInfoNotAvailable | 17 | Відсутня необхідна додаткова інформація |
systemFailure | 25 | Системна помилка |
