Про затвердження технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису

Чинний Наказ · Державний комітет України з питань науки_ інновацій та інформатизації · Адміністрація Державної служби спеціального зв'язку та захисту інформації України · від 13 серпня 2010 р. · № 8/229

Державна реєстрація: № 1052/18347 1053/18348 1054/18349 від 9 листопада 2010 р.
Внесено до реєстру: 12 листопада 2010 р.
Код у реєстрі: 53386/2010

Опубліковано: Офіційний вісник України від 22.11.2010, № 87, ст. 3089

об'єкти національної системи підпис цифровий електронний сертифікація

Зміст

Про затвердження технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису
Про затвердження технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису — Наказ Державного комітету України з питань науки, інновацій та інформатизації,
I. Загальні положення
II. Типи форматів ЕЦП
III. Процедура встановлення дійсності ЕЦП
IV. Атрибути, що включаються у формат ЕЦП
V. Порядок обчислення геш-значення
Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу)
I. Загальні положення
II. Процедура формування позначки часу
III. Процедура перевірки позначки часу
IV. Формати даних
Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката)
I. Загальні положення
II. Процедура інтерактивного визначення статусу сертифіката
III. Формати даних
IV. Транспортні протоколи

Про затвердження технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису

Про затвердження технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису

Наказ Державного комітету України з питань науки, інновацій та інформатизації,

Адміністрації Державної служби спеціального зв'язку та захисту інформації України

від 13 серпня 2010 року N 8/229

Зареєстровано в Міністерстві юстиції України

9 листопада 2010 р. за N 1052/18347

Зміст

1. Наказ Державного комітету України з питань науки, інновацій та інформатизації, Адміністрації Державної служби спеціального зв'язку та захисту інформації України "Про затвердження технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису" від 13 серпня 2010 року N 8/229.

- Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (формат підписаних даних).

2. Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу).

3. Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката).

Про затвердження технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису — Наказ Державного комітету України з питань науки, інновацій та інформатизації,

Наказ Державного комітету України з питань науки, інновацій та інформатизації,

Адміністрації Державної служби спеціального зв'язку та захисту інформації України

від 13 серпня 2010 року N 8/229

Зареєстровано в Міністерстві юстиції України

9 листопада 2010 р. за N 1052/18347

Відповідно до Порядку засвідчення наявності електронного документа (електронних даних) на певний момент часу, затвердженого постановою Кабінету Міністрів України від 26.05.2004 N 680, Порядку акредитації центру сертифікації ключів, затвердженого постановою Кабінету Міністрів України від 13.07.2004 N 903, підпункту 41 пункту 4 Положення про Державний комітет України з питань науки, інновацій та інформатизації, затвердженого постановою Кабінету Міністрів України від 21.07.2010 N 675, та з метою створення умов технологічної сумісності програмно-технічних комплексів акредитованих центрів сертифікації ключів та засобів електронного цифрового підпису НАКАЗУЄМО:

1. Затвердити такі, що додаються:

1.1. Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (формат підписаних даних).

1.2. Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу).

1.3. Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката).

2. Державному комітету України з питань науки, інновацій та інформатизації розмістити наказ на веб-сайті центрального засвідчувального органу.

3. Контроль за дотриманням вимог технічних специфікацій у програмно-технічних комплексах акредитованих центрів сертифікації ключів та засобах електронного цифрового підпису здійснює Адміністрація Державної служби спеціального зв'язку та захисту інформації України.

4. Цей наказ набирає чинності через 6 місяців після його державної реєстрації в Міністерстві юстиції України.

5. Контроль за виконанням наказу покласти на першого заступника Голови Державного комітету України з питань науки, інновацій та інформатизації Мєзєнцеву Н. Б. та першого заступника Голови Державної служби спеціального зв'язку та захисту інформації України Цуркана О. Г.

Голова Державного комітету

України з питань науки,

інновацій та інформатизації

В. П. Семиноженко

Голова Державної служби

спеціального зв'язку та захисту

інформації України

Л. І. Нетудихата

ПОГОДЖЕНО:

Виконуючий обов'язки

Міністра економіки України

А. А. Максюта

Голова Державного комітету

України з питань регуляторної

політики та підприємництва

М. Ю. Бродський

В. о. Голови Національної

комісії з питань регулювання

зв'язку України

В. П. Звєрєв

Міністр транспорту та

зв'язку України

К. О. Єфименко

В. о. Голови Державного комітету

архівів України

І. Б. Матяш

Начальник Головного управління

державної служби України

Т. Мотренко

Голова Державної митної

служби України

І. Г. Калєтнік

ЗАТВЕРДЖЕНО

Наказ Державного комітету України з питань науки, інновацій та інформатизації, Адміністрації Державної служби спеціального зв'язку та захисту інформації України

13.08.2010 N 8/229

Зареєстровано

в Міністерстві юстиції України

9 листопада 2010 р. за N 1052/18347

ТЕХНІЧНІ СПЕЦИФІКАЦІЇ

форматів представлення базових об'єктів національної системи електронного цифрового підпису (формат підписаних даних)

I. Загальні положення

1.1. Ці Технічні специфікації визначають вимоги до представлення електронного цифрового підпису у вигляді DER-кодованого блоку (далі - формат ЕЦП), який містить безпосередньо значення електронного цифрового підпису (далі - ЕЦП) як результату криптографічного перетворення набору електронних даних, а також набір додаткових даних, необхідних для перевірки електронного цифрового підпису та визнання його дійсності.

1.2. Формат ЕЦП представлено у нотації ASN.1,

визначеній у міжнародному стандарті ISO/IEC 8824 "Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)".

1.3. Усі структури даних формату ЕЦП кодують за правилами 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)" та AMD1:2004 "Support for EX-TENDED-XER".

1.4. Ці Технічні специфікації засновані на міжнародних стандартах RFC 3852 "Cryptographic Message Syntax (CMS)", RFC 5126 "CMS Advanced Electronic Signatures" та ETSI TS 101 733 "Technical Specification. Electronic Signatures and Infrastructures (ESI); CMS Advanced Electronic Signatures (CAdES)".

1.5. ЕЦП обчислюється за криптографічними алгоритмами, визначеними у ДСТУ 4145-2002 "Інформаційна технологія. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих". Геш-функція обчислюється за ГОСТ 34.311-95 "Информационная технология. Криптографическая защита информации. Функция хэширования" (далі - ГОСТ 34.311-95).

1.6. У одному форматі ЕЦП можливе використання декількох криптографічних алгоритмів згідно з національними стандартами, або які рекомендовані Адміністрацією Держспецзв'язку.

1.7. Вимоги цих Технічних специфікацій є обов'язковими для надійних засобів електронного цифрового підпису, програмно-технічних комплексів акредитованих центрів сертифікації ключів. Правильність реалізації наведених форматів у засобах ЕЦП повинна бути підтверджена сертифікатом відповідності або позитивним експертним висновком за результатами державної експертизи у сфері криптографічного захисту інформації. Тип формату ЕЦП обирається залежно від вимог до зберігання підписаних даних.

Структуру даних формату ЕЦП наведено у додатку.

1.8. У цих Технічних специфікаціях терміни вживаються у такому значенні:

атрибути, що не підписуються, - додаткові дані, які включаються до DER-кодованого блоку логічного представлення ЕЦП;

атрибути, що підписуються, - додаткові дані, які включаються до DER-кодованого блоку логічного представлення ЕЦП, стосовно якого разом з набором електронних даних, які підписуються, обчислюється ЕЦП за методикою, визначеною в цій специфікації;

верифікатор - особа, що перевіряє ЕЦП за допомогою надійного засобу ЕЦП;

значення цифрового підпису - DER-кодований блок, що містить результат криптографічного перетворення набору електронних даних, які підписуються;

набір додаткових даних (дані перевірки) - дані, необхідні для визнання дійсності (достовірності) ЕЦП, тобто кодовані за встановленими правилами поля даних ЕЦП, що призначені для встановлення дійсності ЕЦП, у тому числі в довгостроковому періоді.

Інші терміни застосовуються у значеннях, наведених у Законі України "Про електронний цифровий підпис", Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13.07.2004 N 903, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 13.01.2005 N 3 (у редакції наказу Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 10.05.2006 N 50), зареєстрованих у Міністерстві юстиції України 27.01.2005 за N 104/10384, інших нормативно-правових актах з питань криптографічного та технічного захисту інформації.

1.9. Для визначення алгоритму гешування поле "algorithm" повинно мати значення:

Gost34311 OBJECT IDENTIFIER::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-hash (2) 1}

Поле "parameters" повинно бути відсутнє, але для сумісності з попередніми рішеннями може також бути закодоване як ASN.1 NULL.

В операціях формування та перевіряння підпису при обчисленні значення геш-функції згідно з ГОСТ 34.311-95 повинен використовуватися довгостроковий ключовий елемент (далі - ДКЕ), що вказаний в параметрах ключа підпису.

В усіх інших операціях обчислення

значення геш-функції згідно з ГОСТ 34.311-95 повинен використовуватися ДКЕ N 1, наведений у додатку 1 до Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 12.06.2007 N 114, зареєстрованої в Міністерстві юстиції України 25.06.2007 за N 729/13996 (далі - ДКЕ N 1).

ДКЕ N 1 використовується як ДКЕ "за умовчанням".

II. Типи форматів ЕЦП

2.1. Цими Технічними специфікаціями визначаються такі типи форматів ЕЦП:

"Базовий ЕЦП" (CAdES Basic Electronic Signature - CAdES-BES, відповідно до ETSI TS 101 733);

"Базовий ЕЦП із визначеною політикою підпису" (Explicit Policy-based Electronic Signature - CAdES-EPES відповідно до ETSI TS 101 733);

"ЕЦП з посиланням на повний набір даних перевірки" (ES with Complete validation data references (CAdES-C) відповідно до ETSI TS 101 733);

"ЕЦП з повним набором даних перевірки" (CAdES-X Long відповідно до ETSI TS 101 733).

2.2. Типи форматів ЕЦП наведено в порядку збільшення вимог до структури даних таким чином, що формат ЕЦП, наведений нижче, передбачає виконання вимог усіх наведених вище форматів.

2.3. Формат "Базовий ЕЦП":

2.3.1. Формат "Базовий ЕЦП" використовується для автентифікації підписувача та перевірки цілісності електронного документа в період чинності сертифіката (сертифікатів) відкритого ключа (далі - сертифікат). Формат "Базовий ЕЦП" може бути створений без доступу до on-line послуг центру сертифікації ключів, зокрема послуги фіксування часу. Формат "Базовий ЕЦП" не надає можливості встановити дійсність підпису у випадку, якщо ЕЦП перевіряється після закінчення терміну дії сертифіката або скасування сертифіката після формування ЕЦП.

2.3.2. Формат "Базовий ЕЦП" містить:

набір обов'язкових атрибутів, що підписуються;

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

електронні дані, стосовно яких здійснюється обчислення цифрового підпису (необов'язково).

Додатково формат "Базовий ЕЦП" може включати:

набір необов'язкових атрибутів, що підписуються;

набір необов'язкових атрибутів, що не підписуються, відповідно до CMS (RFC 3852).

2.3.3. Перелік обов'язкових атрибутів, що підписуються:

"Content-Type" - атрибут, що визначає тип структури "EncapsulatedContentInfo", за значенням якого обчислюється підпис;

"Message-digest" - атрибут, що містить геш-значення структури "eContent OCTET STRING" в "encapContentInfo", за значенням якого обчислюється цифровий підпис;

"ESS signing-certificate v2" - атрибут, що містить посилання на сертифікат підписувача.

2.3.4. Перелік необов'язкових атрибутів, що підписуються:

"Signing-time" - атрибут, що містить час обчислення цифрового підпису, який заявляється підписувачем;

"content-time-stamp" - атрибут, що містить позначку часу відносно даних, що підписується. Зазначений атрибут дозволяє забезпечити доказ того, що дані, стосовно яких обчислюється підпис, існували до моменту формування підпису;

"signature-policy-identifier" - атрибут, що вказує на політику підпису, дотримання якої є обов'язковим під час формування та перевірки ЕЦП.

2.4. Формат "Базовий ЕЦП із визначеною політикою підпису" (CAdES-EPES) включає всі дані формату "Базовий ЕЦП" та додатково містить обов'язковий атрибут "signature-policy-identifier", що вказує на політику підпису, дотримання якої є обов'язковим під час формування та перевірки ЕЦП.

2.5. Формати "ЕЦП з посиланням на повний набір даних перевірки" (CAdES-C) та "ЕЦП з повним набором даних перевірки" (CAdES-X Long) забезпечують можливість встановлення дійсності ЕЦП у довгостроковому періоді (після закінчення терміну дії сертифіката).

Ці формати додатково містять дані, що забезпечують встановлення дійсності підпису у довгостроковому періоді:

позначку часу відносно цифрового підпису;

сертифікати або посилання на сертифікати;

інформацію про статус для кожного сертифіката або посилання на таку інформацію.

Зазначені дані включаються до формату підписувачем або верифікатором та

визначаються атрибутами, що не підписуються. Такі атрибути додаються до формату "Базовий ЕЦП". Використання позначки часу забезпечує доказ того, що цифровий підпис був обчислений до певного часу та дозволяє встановити дійсність сертифіката на момент обчислення цифрового підпису. Інформація про статус сертифікатів може бути представлена у формі списків відкликаних сертифікатів або відповідей на інтерактивну перевірку статусу сертифіката згідно з Технічними специфікаціями форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката), затвердженими наказом Державного комітету України з питань науки, інновацій та інформатизації, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 13.08.2010 N 8/229.

2.5.1. Формат "ЕЦП з посиланням на повний набір даних перевірки" формується шляхом додавання до формату "Базовий ЕЦП" таких атрибутів, що не підписуються:

"signature-time-stamp" - атрибут, що містить позначку часу відносно цифрового підпису;

"complete-certificate-references" - атрибут, що містить ідентифікаційні дані всіх сертифікатів, які використовуються для перевірки підпису, крім сертифіката підписувача;

"complete-revocation-references" - атрибут, що містить ідентифікаційні дані списків відкликаних сертифікатів або відповідей за протоколом OCSP щодо сертифікатів, які використовуються для перевірки підпису, крім сертифіката підписувача.

Дата та час, які вказані у позначці часу, не повинні перевищувати строк дії сертифіката (сертифікатів) або дату та час його скасування.

За умови, що необхідні дані перевірки, які забезпечують встановлення дійсності підпису у довгостроковому періоді, доступні верифікатору, він може сформувати формат "ЕЦП з посиланням на повний набір даних перевірки" на основі отриманого від підписувача ЕЦП у форматі "Базовий ЕЦП" з дотриманням періоду відстрочки з моменту авторизації підписувача, що звертається до ЦСК з метою скасування сертифіката, до часу, коли оновлена інформація про статус сертифіката стає доступною для використання. У випадку, якщо підписувач ініціює процедуру скасування сертифіката, інформація про статус сертифіката протягом періоду відстрочки може не відповідати інформації, що доступна для верифікатора.

2.5.2. Формат "Розширений довгостроковий підпис" формується шляхом додавання до формату "Базовий ЕЦП" таких атрибутів, що не підписуються:

"certificate-values" - атрибут містить всі сертифікати, крім сертифіката підписувача, необхідні для перевірки підпису;

"revocation-values" - атрибут містить списки відкликаних сертифікатів або відповіді за протоколом OCSP щодо сертифікатів, які використовуються для перевірки підпису (крім сертифіката підписувача).

III. Процедура встановлення дійсності ЕЦП

3.1. ЕЦП вважається дійсним у разі, якщо:

формат ЕЦП відповідає вимогам цих Технічних специфікацій;

за результатами перевірки цифрового підпису встановлено, що цифровий підпис вірний;

ЕЦП підтверджено з використанням сертифіката (сертифікатів), чинного (чинних) на момент накладення ЕЦП.

Якщо під час перевірки у верифікатора відсутні необхідні дані перевірки, зокрема сертифікати, інформація про їх статус, або якщо період відстрочки не закінчився, він повинен утриматися від перевірки ЕЦП до отримання цих даних або закінчення періоду відстрочки.

3.2. ЕЦП вважається недійсним у разі, якщо:

формат ЕЦП не відповідає вимогам цих Технічних специфікацій;

за результатами перевірки цифрового підпису встановлено, що цифровий підпис невірний;

ЕЦП підтверджено з використанням сертифіката (сертифікатів), що на момент накладання ЕЦП не був чинним (був скасованим, блокованим або термін його дії закінчився);

тип даних, на які поставлено підпис, не відповідає зазначеному в атрибуті "content-type";

геш-значення даних (інкапсульованих або зовнішніх) не відповідає зазначенню, наведеному в атрибуті "message-digest".

3.3. Перевірка декількох підписів здійснюється у випадку, коли підписаний документ містить декілька підписів, кожен підпис перевіряється окремо. Результат

перевірки такого документа формується з урахуванням пріоритетів результатів для кожного ЕЦП: результат "підпис недійсний" має найвищий пріоритет, результат "неможливо встановити дійсність підпису" - середній, результат "підпис дійсний" - найнижчий.

Якщо хоча б один підпис є недійсним, підписаний документ також вважається недійсним.

Якщо недійсних підписів нема, але хоча б для одного підпису неможливо встановити його дійсність, підписаний документ також вважається таким, дійсність якого неможливо встановити.

IV. Атрибути, що включаються у формат ЕЦП

4.1. Тип "ContentInfo":

Тип "ContentInfo" використовується для інкапсульованих даних разом з ідентифікатором типу даних.

ContentInfo ::= SEQUENCE {

contentType

ContentType,

content

[0] EXPLICIT ANY DEFINED BY contentType}

ContentType ::= OBJECT IDENTIFIER

4.1.1. Поле "contentType" містить об'єктний ідентифікатор, що ідентифікує тип даних, що містяться в полі "content". Цією специфікацією визначаються два типи даних: "дані" та "дані з ЕЦП".

Тип даних "дані" має об'єктний ідентифікатор:

id-data OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

Тип даних "дані з ЕЦП" має об'єктний ідентифікатор:

id-signedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

4.1.2. Поле "content" містить дані, тип яких вказано в полі "contentType".

Якщо поле "contentType" типу "ContentInfo" містить об'єктний ідентифікатор "id-signedData", то поле "content" цього типу містить тип "SignedData", що визначає "дані з ЕЦП". Ця структура відповідає формату "Базовий ЕЦП".

4.2. Тип "SignedData":

SignedData ::= SEQUENCE {

version

CMSVersion,

digestAlgorithms

DigestAlgorithmIdentifiers,

encapContentInfo

EncapsulatedContentInfo,

certificates

[0] IMPLICIT CertificateSet OPTIONAL,

crls

[1] IMPLICIT RevocationInfoChoices OPTIONAL

signerInfos

SignerInfos}

4.2.1. Поле "version" містить версію формату підписаних даних. Якщо у полі сертифіката відсутні атрибути сертифіката та якщо значення поля "encapContentInfo" в полі "eContentType" дорівнює "id-data" і всі елементи "signerInfos" мають значення поля "version" рівне 1, тоді "version" дорівнює 1. Якщо атрибути сертифіката присутні, якщо значення поля "encapContentInfo" в полі "eContentType" відрізняється від "id-data" та будь-які елементи "signerInfos" мають значення поля "version" рівне 3, то поле "version" дорівнює 3.

4.2.2. Поле digestAlgorithms містить перелік алгоритмів гешування, що були використані під час формування ЕЦП.

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

Поле "digestAlgorithms" повинно містити лише один алгоритм гешування за ГОСТ 34.311-95. Об'єктний ідентифікатор алгоритму (поле "algorithm" типу "AlgorithmIdentifier") повинен мати таке значення:

gost34311 OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-hash (2) 1}

Поле "parameters" є необов'язковим та містить елемент OCTET STRING, що містить ДКЕ для функції гешування.

При обчисленні значення геш-функції (у тому числі при обчисленні ЕЦП) значення стартового вектора H функції гешування за ГОСТ 34.311-95 встановлюється рівним 256 нульовим бітам.

4.2.3. Поле "encapContentInfo" містить інкапсульовані дані, що були підписані.

Тип "EncapsulatedContentInfo" використовується для зберігання даних, що підписані.

EncapsulatedContentInfo ::= SEQUENCE {

eContentType

ContentType,

eContent

[0] EXPLICIT OCTET STRING OPTIONAL}

Поле "eContentType" містить об'єктний ідентифікатор типу даних.

Поле "eContent" є необов'язковим та може містити дані, що підписуються. Якщо це поле відсутнє, то вважається, що дані зберігаються окремо від логічного блоку ЕЦП (зовнішні дані).

4.2.4. Поле "certificates" є необов'язковим та може містити перелік сертифікатів, необхідних для перевірки ЕЦП.

CertificateSet ::= SET OF Certificate

Для форматів CAdES-C та CAdES-X Long це поле повинно бути присутнє та

містити сертифікат підписувача.

4.2.5. Поле "crls" є необов'язковим та може містити набір списків відкликаних сертифікатів, необхідних для визначення статусу сертифіката.

RevocationInfoChoices ::= SET OF CertificateList

Для формату CAdES-X Long це поле повинно бути відсутнім; всю необхідну інформацію для визначення статусу треба розташовувати в атрибуті "revocation-values".

4.2.6. Поле "signerInfos" містить інформацію про осіб, що підписали дані.

SignerInfos ::= SET OF SignerInfo

4.3. Тип "SignerInfo" використовується для зберігання даних про підписувача та додаткових даних:

SignerInfo ::= SEQUENCE {

version

CMSVersion,

sid

SignerIdentifier,

digestAlgorithm

DigestAlgorithmIdentifier,

signedAttrs

[0] IMPLICIT SignedAttributes OPTIONAL,

signatureAlgorithm

SignatureAlgorithmIdentifier,

signature

OCTET STRING,

unsignedAttrs

[1] IMPLICIT UnsignedAttributes OPTIONAL}

4.3.1. Поле "version" містить версію формату типу "SignerInfo". Це поле повинно мати значення 1.

4.3.2. Поле "sid" містить ідентифікаційну інформацію про підписувача.

SignerIdentifier ::= CHOICE {

issuerAndSerialNumber

IssuerAndSerialNumber,

subjectKeyIdentifier

[0] SubjectKeyIdentifier }

"SignerIdentifier" надає два варіанти щодо визначення відкритого ключа підписувача.

"IssuerAndSerialNumber" визначає сертифікат підписувача за розпізнавальним ім'ям центру сертифікації ключів ("distinguished name"), що сформував сертифікат, та серійним номером сертифіката ("CertificateSerialNumber").

"SubjectKeyIdentifier" визначає сертифікат підписувача за ідентифікатором ключа.

IssuerAndSerialNumber ::= SEQUENCE {

issuer

Name,

serialNumber

CertificateSerialNumber }

"Name" кодується відповідно до Технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису (формат посиленого сертифіката відкритого ключа), затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України, Державного департаменту з питань зв'язку та інформатизації Міністерства транспорту та зв'язку України від 11.09.2006 N 99/166.

CertificateSerialNumber ::= INTEGER

4.3.3. Поле "digestAlgorithm" містить дані алгоритму гешування. Значення цього поля повинно відповідати значенню поля "digestAlgorithms" типу "SignedData".

4.3.4. Поле "signedAttrs" містить підписані атрибути з додатковими даними.

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

4.3.5. Поле "signatureAlgorithm" містить ідентифікатор алгоритму цифрового підпису.

Поле "algorithm" поля "signatureAlgorithm" для алгоритму цифрового підпису ДСТУ-4145:2002 може мати два значення:

Dstu4145PBAlgo OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-sym(3) Dstu4145WithGost34311(1) PB(1)}

для поліноміального базису та:

Dstu4145ONBAlgo OBJECT IDENTIFIER ::= { iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-sym(3) Dstu4145WithGost34311(1) ONB(2)}

для оптимального нормального базису.

В обох випадках поле parameters поля signatureAlgorithm відсутнє.

4.3.6. Поле "signature" містить безпосередньо цифровий підпис.

4.3.7. Поле "unsignedAttrs" містить непідписані атрибути з додатковими даними.

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

Attribute ::= SEQUENCE {attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue }

AttributeValue ::= ANY

4.4. Атрибут "message-digest" містить геш-значення даних, що підписуються (encapContentInfo eContent OCTET STRING в "signed-data" - тип формату "криптографічне повідомлення"), або файлу, що підписується (тип формату "зовнішній підпис"). Порядок обчислення геш-значення здійснюється згідно з розділом V цих Технічних специфікацій.

Об'єктний ідентифікатор, що визначає атрибут "message-digest":

id-messageDigest OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4}

Значення атрибута "message-digest" має тип "MessageDigest":

MessageDigest ::=

OCTET STRING

Атрибут "message-digest" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

4.5. Атрибут визначає тип електронних даних ("Content Type"), що підписуються. Значення атрибута "content-type" повинно збігатися із значенням "eContentType" структури "encapContentInfo" в "signed-data".

Об'єктний ідентифікатор, що визначає атрибут "content-type":

id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3}

Значення атрибута "content-type" має тип "ContentType"

ContentType ::= OBJECT IDENTIFIER

Атрибут "content-type" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

4.6. Об'єктний ідентифікатор, що визначає атрибут "ESS signing-certificate v2":

id-aa-signingCertificateV2 OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)smime(16) id-aa(2) 47}

Значення атрибута "ESS signing-certificate v2" має тип:

SigningCertificateV2 ::= SEQUENCE {certs SEQUENCE OF ESSCertIDv2, policies SEQUENCE OF PolicyInformation OPTIONAL}

Структура "certs" повинна містити посилання на сертифікат підписувача.

ESSCertIDv2 ::= SEQUENCE {

hashAlgorithm

AlgorithmIdentifier

certHash

Hash,

issuerSerial

IssuerSerial}

Hash ::= OCTET STRING

IssuerSerial ::= SEQUENCE {

issuer

GeneralNames,

serialNumber

CertificateSerialNumber}

Значення поля "issuerSerial" повинно відповідати значенню "serialNumber" структури "issuerAndSerialNumber" в "SignerIdentifier" (SignerInfo).

"hashAlgorithm" містить об'єктний ідентифікатор алгоритму, що використовується для обчислення геш-значення DER-кодованного сертифіката.

"certHash" містить геш-значення сертифіката підписувача.

4.7. Атрибут "signature-policy-identifier" визначає об'єктний ідентифікатор.

id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= {iso(1)member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)smime(16) id-aa(2) 15}

Значення атрибута "signature-policy-identifier" має тип "SignaturePolicyIdentifier"

SignaturePolicyIdentifier ::=CHOICE {

signaturePolicyId SignaturePolicyId }

SignaturePolicyId ::= SEQUENCE {

sigPolicyId

SigPolicyId,

sigPolicyHash

SigPolicyHash OPTIONAL,

sigPolicyQualifiers

SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL}

Поле "SigPolicyId" містить об'єктний ідентифікатор, який унікально ідентифікує конкретну версію політики підпису. Синтаксис цього поля такий:

SigPolicyId ::= OBJECT IDENTIFIER

Поле "sigPolicyHash" є опціональним та містить ідентифікатор геш-алгоритму та геш-значення політики підпису.

Якщо політика підпису визначена з використанням структури ASN.1, то геш-значення обчислюється із кодованого значення політики підпису (за вилученням байтів тегу та довжини) та алгоритм гешування повинен бути таким, як вказано в полі "sigPolicyHash".

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

SigPolicyHash ::= OtherHashAlgAndValue

OtherHashAlgAndValue ::= SEQUENCE {

hashAlgorithm

AlgorithmIdentifier,

hashValue

OtherHashValue }

OtherHashValue ::= OCTET STRING

Ідентифікатор політики підпису може бути пов'язаний з іншою інформацією щодо специфікатора. Семантика і синтаксис специфікатора пов'язані з об'єктним ідентифікатором у полі "sigPolicyQualifierId".

Загальний синтаксис специфікатора такий:

SigPolicyQualifierInfo ::= SEQUENCE {

sigPolicyQualifierId

SigPolicyQualifierId,

sigQualifier

ANY DEFINED BY sigPolicyQualifierId}

У цих Технічних специфікаціях визначаються такі специфікатори:

"spuri": містить "web URI" або "URL" посилання на політику підпису;

"sp-user-notice": містить повідомлення для користувача, що повинно відображатися кожного разу, коли перевіряється підпис.

SigPolicyQualifierId ::= OBJECT IDENTIFIER

id-spq-ets-uri OBJECT IDENTIFIER ::= {

iso(1)member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)smime(16) id-spq(5) 1}

SPuri ::= IA5String

id-spq-ets-unotice OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2}

SPUserNotice ::= SEQUENCE {

noticeRef

NoticeReference OPTIONAL,

explicitText

DisplayText OPTIONAL}

NoticeReference ::= SEQUENCE {

Organization

DisplayText,

noticeNumbers

SEQUENCE OF INTEGER }

DisplayText ::= CHOICE {

visibleString

VisibleString (SIZE (1..200)),

bmpString

BMPString (SIZE (1..200)),

utf8String

UTF8String (SIZE (1..200))}

4.8. Атрибут "signing-time" містить час формування цифрового підпису, який заявляється підписувачем.

Об'єктний ідентифікатор, що визначає атрибут "signing-time":

id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5}

Значення атрибута "signing-time" має тип "SigningTime"

SigningTime ::= Time

Time ::= CHOICE {

utcTime

UTCTime,

generalizedTime

GeneralizedTime}

В ЕЦП, що формується до 2049 року включно, поле "SigningTime" кодується у форматі "UTCTime". В ЕЦП, що формуватиметься з 2050 року, поле "SigningTime" кодується у форматі "GeneralizedTime".

"UTCTime" значення повинно бути представлено у формі "YYMMDDHHMMSSZ". Наприклад, північ повинна бути представлена як "YYMMDD000000Z".

Століття представляється не явно та повинно визначатися за такими правилами:

якщо "YY" більше або дорівнює 50, рік повинен інтерпретуватися як 19YY;

якщо "YY" менше 50, рік повинен інтерпретуватися як "20YY".

Атрибут "signing-time" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

4.9. Атрибут "content-time-stamp" містить позначку часу для даних, що підписуються. Позначка часу повинна існувати до початку формування блоку ЕЦП.

Об'єктний ідентифікатор, що визначає атрибут "content-time-stamp":

id-aa-ets-ContentTimeStamp OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 20}

Значення атрибута "content-time-stamp" має тип "ContentTimeStamp".

ContentTimeStamp ::= TimeStampToken

Формат представлення структури "TimeStampToken" визначається згідно з підпунктом 4.2.2 пункту 4.2 розділу II Технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу), затверджених наказом Державного комітету України з питань науки, інновацій та інформатизації, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 13.08.2010 N 8/229.

Значення "messageImprint" структури "TimeStampToken" є геш-значенням даних атрибута "message-digest".

Незважаючи на те, що синтаксисом "attrValues" передбачено як "SET OF AttributeValue", атрибут "content-time-stamp" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

4.10. Атрибут "signature-time-stamp" містить значення "TimeStampToken", яке обчислюється стосовно цифрового підпису.

Об'єктний ідентифікатор, що визначає атрибут "signature-time-stamp":

id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14}

Значення атрибута "signature-time-stamp" має тип "SignatureTimeStampToken".

SignatureTimeStampToken ::= TimeStampToken

У складі "unsignedAttributes" може бути довільна кількість атрибутів типу "signature-time-stamp" (наприклад, від різних центрів сертифікації ключів, що надають послугу фіксування часу).

Позначка часу може бути отримана після формування цифрового підпису.

13.08.2010 N 8/229.

Значенням "messageImprint" структури "TimeStampToken" є геш-значення даних поля "signature" структури "SignerInfo" (із вилученням байтів тегу та довжини) цифрового підпису, до складу структури "unsignedAttributes" якого він входить.

4.11. Атрибут "complete-certificate-references" містить посилання на всі сертифікати центрів сертифікації ключів, що використовуються для перевіряння підпису. Посилання на сертифікат підписувача у зазначений атрибут не включається. Посилання на сертифікат підписувача включається до атрибута "ESS signing-certificate v2".

Об'єктний ідентифікатор визначає атрибут "complete-certificate-references":

id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}

Значення атрибута "complete-certificate-references" має тип "CompleteCertificateRefs".

CompleteCertificateRefs ::= SEQUENCE OF OtherCertID

OtherCertID ::= SEQUENCE {

otherCertHash OtherHash,

issuerSerial IssuerSerial OPTIONAL }

OtherHash ::= CHOICE {

sha1Hash OtherHashValue,

otherHash OtherHashAlgAndValue}

OtherHashValue ::= OCTET STRING

OtherHashAlgAndValue ::= SEQUENCE {

hashAlgorithm AlgorithmIdentifier,

hashValue OtherHashValue }

Атрибут "complete-certificate-references" може містити посилання на сертифікати, що використовуються для перевірки позначки часу. В цьому випадку атрибут повинен включатися у поле "signedData" позначки часу як "unsignedAttrs" структури "signerInfos".

4.12. Атрибут "complete-revocation-references" містить посилання на всі списки відкликаних сертифікатів або відповіді за протоколом OCSP, які використовуються для перевірки сертифікатів центрів сертифікації ключів.

Об'єктний ідентифікатор, що визначає атрибут "complete-revocation-references":

id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= {iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}

Значення атрибута "complete-certificate-references" має синтаксис "CompleteRevocationRefs":

CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef

CrlOcspRef ::= SEQUENCE {

crlids

[0] CRLListID OPTIONAL,

ocspids

[1] OcspListID OPTIONAL,

otherRev

[2] OtherRevRefs OPTIONAL

}

"CompleteRevocationRefs" повинен містити один "CrlOcspRef" для "signing-certificate". Другий та наступні атрибути "CrlOcspRef" повинні бути розміщені у послідовності у тому самому порядку, що і "OtherCertID", з якими вони пов'язані. Для кожного сертифіката, окрім кореневого, "CrlOcspRef" має містити хоча б одне з полів "crlids" або "ocspids".

CRLListID ::= SEQUENCE {

crls SEQUENCE OF CrlValidatedID}

CrlValidatedID ::= SEQUENCE {

crlHash OtherHash,

crlIdentifier CrlIdentifier OPTIONAL}

CrlIdentifier ::= SEQUENCE {

crlissuer Name,

crlIssuedTime UTCTime,

crlNumber INTEGER OPTIONAL

}

OcspListID ::= SEQUENCE {

ocspResponses SEQUENCE OF OcspResponsesID}

OcspResponsesID ::= SEQUENCE {

ocspIdentifier OcspIdentifier,

ocspRepHash OtherHash OPTIONAL

}

OcspIdentifier ::= SEQUENCE {

ocspResponderID ResponderID,

producedAt GeneralizedTime

}

OtherRevRefs ::= SEQUENCE {

otherRevRefType OtherRevRefType,

otherRevRefs ANY DEFINED BY otherRevRefType

}

OtherRevRefType ::= OBJECT IDENTIFIER

До ідентифікаторів СВС можуть включатися посилання як на власне СВС, так і на дельта-списки.

Під час створення "crlValidatedID" значення атрибута "crlHash" обчислюється стосовно повного DER кодованого списку відкликаних сертифікатів (CRL), включає його підпис.

"crlIdentifier" призначений для ідентифікації списку відкликаних сертифікатів (CRL) за реквізитами центру сертифікації ключів, що сформував цей CRL, а також за часом формування CRL, який повинен відповідати часу, зазначеному в атрибуті "thisUpdate" списку відкликаних сертифікатів, та за полем "crlNumber" у разі його наявності.

"OcspIdentifier" призначений для ідентифікації OCSP-відповіді за реквізитами центру сертифікації ключів, що сформував цю OCSP-відповідь, а також за часом формування OCSP-відповіді, який повинен відповідати часу,

зазначеному в атрибуті "producedAt" OCSP-відповіді.

Зазначений атрибут може містити посилання на CRL, OCSP-відповіді, що використовуються для перевірки сертифікатів для позначки часу. В цьому випадку атрибут, що не підписується, повинен включатися у поле "signedData" позначки часу як "unsignedAttrs" структури "signerInfos".

4.13. Атрибут "certificate-values" містить значення сертифікатів, посилання на які знаходяться в атрибуті "complete-certificate-references".

Об'єктний ідентифікатор, що визначає атрибут "certificate-values":

id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}

Значення атрибута "certificate-values" має синтаксис "CertificateValues":

CertificateValues ::= SEQUENCE OF Certificate

4.14. Атрибут "revocation-values" містить значення CRL та OCSP відповідей, посилання на які знаходяться в атрибуті "complete-revocation-references".

Об'єктний ідентифікатор, що визначає атрибут "revocation-values":

id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24}

Значення атрибута "revocation-values" має синтаксис "RevocationValues":

RevocationValues ::= SEQUENCE {

crlVals

[0] SEQUENCE OF CertificateList OPTIONAL,

ocspVals

[1] SEQUENCE OF BasicOCSPResponse OPTIONAL,

otherRevVals

[2] OtherRevVals OPTIONAL}

OtherRevVals ::= SEQUENCE {

otherRevValType OtherRevValType,

otherRevVals ANY DEFINED BY OtherRevValType}

OtherRevValType ::= OBJECT IDENTIFIER

V. Порядок обчислення геш-значення

5.1. Процедура обчислення геш-значення здійснюється за даними, що підписуються (значення "eContent" структури "encapContentInfo" в "signed-data" або зовнішнім файлом), або за даними, що підписуються разом із підписаними атрибутами ("signedAttrs") у разі їх наявності.

5.2. Якщо підписані атрибути відсутні, то геш-значення обчислюється за даними, що підписуються, розміщеними у "eContent" структури "encapContentInfo" в "signed-data", або за зовнішнім файлом, для якого формується ЕЦП. При цьому у першому випадку вхідними даними для геш-алгоритму є тільки октети, що містять значення "eContent OCTET STRING". Октети DER-кодування тегу та довжини типу не використовуються. Отримане геш-значення використовується в алгоритмі формування ЕЦП.

5.3. Якщо підписані атрибути наявні, то обчислення геш-значення здійснюється у такому порядку:

5.3.1. Обчислюється геш-значення за даними, що підписуються, які розміщуються у "eContent" структури "encapContentInfo" в "signed-data", або за зовнішніми даними. При цьому у першому випадку вхідними даними для геш-алгоритму є тільки октети, що містять значення "eContent OCTET STRING". Октети DER-кодування тегу та довжини типу не використовуються.

5.3.2. Здійснюється DER-кодування структури "signedAttrs", в яку в атрибут "message-digest" поміщається геш-значення, отримане на попередньому кроці.

5.3.3. Обчислюється геш-значення DER-кодованої структури "signedAttrs", включаючи октети тегу та довжини. Отримане геш-значення є вхідним значенням для алгоритму обчислення ЕЦП.

5.3.4. При обчисленні значення геш-функції згідно з ГОСТ 34.311-95 як стартовий вектор геш-функції використовується нульовий вектор та ДКЕ "за умовчанням" згідно з пунктом 1.9 розділу I цих Технічних специфікацій.

Заступник Голови Державного

комітету України з питань науки,

інновацій та інформатизації

С. О. Колобов

Директор Департаменту

регулювання діяльності у сфері

криптографічного захисту інформації

Адміністрації Державної служби

спеціального зв'язку та захисту

інформації України

В. І. Бондаренко

ПОГОДЖЕНО:

Перший заступник Голови

Державного комітету України

з питань технічного регулювання

та споживчої політики

В. В. Арєфьєв

Додаток

до Технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису (формат підписаних даних)

Структура даних формату електронного цифрового підпису

id-data OBJECT IDENTIFIER

::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1}

id-signedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

ContentInfo ::= SEQUENCE {

contentType

ContentType,

content

[0] EXPLICIT ANY DEFINED BY contentType }

ContentType ::= OBJECT IDENTIFIER

SignedData ::= SEQUENCE {

version

CMSVersion,

digestAlgorithms

DigestAlgorithmIdentifiers,

encapContentInfo

EncapsulatedContentInfo,

certificates

[0] IMPLICIT CertificateSet OPTIONAL,

signerInfos

SignerInfos }

CMSVersion ::= INTEGER {v0(0), v1(1), v2(2), v3(3), v4(4), v5(5)}

DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

DigestAlgorithmIdentifier ::= AlgorithmIdentifier

EncapsulatedContentInfo ::= SEQUENCE {

eContentType

ContentType,

eContent

[0] EXPLICIT OCTET STRING OPTIONAL}

CertificateSet ::= SET OF Certificate

SignerInfos ::= SET OF SignerInfo

SignerInfo ::= SEQUENCE {

version

CMSVersion,

sid

SignerIdentifier,

digestAlgorithm

DigestAlgorithmIdentifier,

signedAttrs

[0] IMPLICIT SignedAttributes OPTIONAL,

signatureAlgorithm

SignatureAlgorithmIdentifier,

signature

OCTET STRING,

unsignedAttrs

[1] IMPLICIT UnsignedAttributes OPTIONAL }

SignerIdentifier ::= CHOICE {

issuerAndSerialNumber

IssuerAndSerialNumber}

IssuerAndSerialNumber ::= SEQUENCE {

issuer

Name,

serialNumber

INTEGER}

SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу)

ЗАТВЕРДЖЕНО

13.08.2010 N 8/229

Зареєстровано

в Міністерстві юстиції України

9 листопада 2010 р. за N 1053/18348

ТЕХНІЧНІ СПЕЦИФІКАЦІЇ

форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу)

I. Загальні положення

1.1. Ці Технічні специфікації визначають процедури формування та перевірки позначки часу, формати даних та протоколи взаємодії органів державної влади та органів місцевого самоврядування у сфері послуг електронного цифрового підпису під час надання послуги фіксування часу.

1.2. Формати даних представлено у нотації ASN.1, визначеній у міжнародному стандарті ISO/IEC 8824 "Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)".

1.3. Усі структури даних кодують за правилами 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.4. Ці Технічні специфікації розороблено відповідно до міжнародних стандартів RFC 3852 "Cryptographic Message Syntax (CMS)", RFC 3161 "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)" та ISO/IEC 18014 "Information technology - Security techniques - Time-stamping services".

1.5. Вимоги цих Технічних специфікацій є обов'язковими для надійних засобів електронного цифрового підпису, програмно-технічних комплексів акредитованих центрів сертифікації ключів. Правильність реалізації протоколу та наведених форматів у засобах ЕЦП повинна бути підтверджена сертифікатом відповідності або позитивним експертним висновком за результатами державної експертизи у сфері криптографічного захисту інформації.

Формати даних у нотації ASN.1, що застосовуються при реалізації протоколу фіксування часу, наведено у додатку 1

1.6. У цих Технічних специфікаціях терміни вживаються у такому значенні:

послуга фіксування часу - процедура засвідчення наявності електронного документа (електронних даних) на певний момент часу шляхом додання до нього або логічного поєднання з ним позначки часу;

позначка часу - сукупність електронних даних, створена за допомогою технічних засобів та засвідчена електронним цифровим підписом центру сертифікації ключів, яка підтверджує наявність електронного документа (електронних даних) на певний момент часу.

Інші терміни застосовуються у значеннях, наведених у Законі України "Про електронний цифровий підпис", Порядку засвідчення наявності електронного документа (електронних даних) на певний момент часу, затвердженому постановою Кабінету Міністрів України від 26.05.2004 N 680, Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13.07.2004 N 903, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 13.01.2005 N 3 (у редакції наказу Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 10.05.2006 N 50), зареєстрованих у Міністерстві юстиції України 27.01.2005 за N 104/10384, інших нормативно-правових актах з питань криптографічного та технічного захисту інформації.

1.7. Для визначення алгоритму гешування поле "algorithm" повинно мати значення

Gost34311 OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-hash (2) 1}

Поле "parameters" повинно бути відсутнє, але для сумісності з попередніми рішеннями також може бути закодоване як ASN.1 NULL.

1.8. В операціях формування та перевіряння підпису при обчисленні значення геш-функції згідно з ГОСТ 34.311-95 повинен використовуватися довгостроковий ключовий елемент (далі - ДКЕ), зазначений в параметрах ключа підпису.

В усіх інших операціях обчислення значення геш-функції згідно з ГОСТ

34.311-95 повинен використовуватися ДКЕ N 1, наведений у додатку 1 до Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 12.06.2007 N 114, зареєстрованої в Міністерстві юстиції України від 25.06.2007 N 729/13996 (далі - ДКЕ N 1).

ДКЕ N 1 використовується як ДКЕ "за умовчанням".

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. Перевірка виконується таким чином:

3.2.1 верифікатор витягує позначку часу з електронного документа, до якого вона була прикріплена;

3.2.2 верифікатор здійснює перевірку позначки часу, виконуючи при цьому такі дії:

отримує ідентифікаційну інформацію з позначки часу про центр сертифікації ключів (інформацію, що однозначно ідентифікує сертифікат центру сертифікації ключів);

за допомогою чинного (на момент формування позначки) сертифіката відкритого ключа центру сертифікації ключів перевіряє ЕЦП, що був накладений на позначку часу;

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

IV. Формати даних

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" містить геш-значення від даних, на які отримується позначка часу, та ідентифікатор алгоритму гешування.

Геш-значення даних, на які отримується позначка часу, має такий формат:

MessageImprint ::= SEQUENCE {

hashAlgorithm

AlgorithmIdentifier,

hashedMessage

OCTET STRING }

Поле "hashAlgorithm" визначає ідентифікатор алгоритму, за допомогою якого було отримано геш-значення.

Поле "algorithm" типу поля "hashAlgorithm" повинно мати значення:

Gost34311 OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-hash (2) 1}

При обчисленні значення геш-функції значення стартового вектора H функції гешування за ГОСТ 34.311-95 встановлюється рівним 256 нульовим бітам. ДКЕ використовується як ДКЕ "за умовчанням" згідно з пунктом 1.8 розділу I цих Технічних специфікацій.

Поле "hashedMessage" містить безпосередньо байти обчисленого гешу.

4.1.3. Поле "reqPolicy" містить об'єктний ідентифікатор політики формування позначок часу.

TSAPolicyId ::= OBJECT IDENTIFIER

Можливі ідентифікатори для TSAPolicyId щодо застосування криптографічних алгоритмів підпису у відповіді на запит позначки часу:

ua-PKI-TSP-policy-DSTU-PB ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 1} - для формування відповіді з цифровим підписом згідно з ДСТУ 4145-2002 (ПБ);

ua-PKI-TSP-policy-GOST ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 2} - для формування відповіді з цифровим підписом згідно з ГОСТ 34.310-95;

ua-PKI-TSP-policy-DSTU-ONB ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 3} - для формування відповіді з цифровим підписом згідно з ДСТУ 4145-2002 (ОНБ);

ua-PKI-TSP-policy-SHA1withRSA ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 4} - для формування відповіді з цифровим підписом SHA1withRSA;

ua-PKI-TSP-policy-SHA224withRSA ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 5} - для цифрового підпису SHA224withRSA;

ua-PKI-TSP-policy-SHA256withRSA ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 6} - для цифрового підпису SHA256withRSA;

ua-PKI-TSP-policy-SHA384withRSA ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 7} - для цифрового підпису SHA384withRSA;

ua-PKI-TSP-policy-SHA512withRSA ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(3) 8} - для цифрового підпису SHA512withRSA.

"За умовчанням" використовується політика "ua-PKI-TSP-policy-DSTU-PB".

При обробці запиту позначки часу TSP-служба визначає можливість застосування вказаного у запиті алгоритму та формує відповідь, якщо зазначений алгоритм (політика) підтримується, або помилку, якщо алгоритм не підтримується.

Якщо у запиті алгоритм не вказано або відсутнє поле "reqPolicy", то відповідь формується за алгоритмом, який визначений як алгоритм "за умовчанням", тобто "ua-PKI-TSP-policy-DSTU-PB".

4.1.4. Поле "nonce" містить унікальний ідентифікатор запиту.

4.1.5. Якщо в запиті на формування позначки часу присутнє поле "certReq", сервер у відповіді повинен розмістити з позначкою часу сертифікат, яким було підписано позначку часу.

4.1.6. Поле "extensions" може містити розширення з додатковою інформацією про запит.

4.2. Формат відповіді на запит на формування позначки часу має такий вигляд:

TimeStampResp ::= SEQUENCE {

status

PKIStatusInfo,

timeStampToken

TimeStampToken OPTIONAL }

4.2.1. Поле "status" містить результат обробки запиту на формування позначки часу.

PKIStatusInfo ::= SEQUENCE {

status

PKIStatus,

statusString

PKIFreeText OPTIONAL,

failInfo

PKIFailureInfo OPTIONAL}

Тип "PKIStatusInfo" містить поля, що визначають результат формування (чи відмови у формуванні) позначки часу.

Поле "status" містить код операції формування позначки часу.

PKIStatus ::= INTEGER {

granted

(0),

grantedWithMods

(1),

rejection

(2),

waiting

(3),

revocationWarning

(4),

revocationNotification

(5)}

Можливі значення для типу "PKIStatus" наведені у додатку 2.

Необов'язкове поле "statusString" може містити текстовий опис статусу.

Необов'язкове поле "failInfo" може містити код помилки.

PKIFailureInfo ::= BIT STRING {

badAlg

(0),

badRequest

(2),

badDataFormat

(5),

timeNotAvailable

(14),

unacceptedPolicy

(15),

unacceptedExtension

(16),

addInfoNotAvailable

(17),

systemFailure

(25)}

Можливі значення для типу "PKIFailureInfo" наведено у додатку 3.

4.2.2. Поле "timeStampToken" містить сформовану позначку часу або є відсутнім (у разі відмови у формуванні позначки часу).

Позначка часу зберігається у форматі "CMS ContentInfo" (відповідно до RFC 3852):

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" містить геш-значення даних, на які була отримана позначка часу.

Поле "serialNumber" містить серійний номер позначки часу.

Поле "genTime" містить час формування позначки часу у форматі GMT.

Поле "nonce" може містити унікальний ідентифікатор запиту, на який була сформована позначка часу.

Поле "extensions" може містити розширення із додатковою інформацією про позначку часу, службу фіксації часу центру сертифікації ключів тощо.

4.3. Рекомендовані політики служби фіксування часу наведено у підпункті 4.1.3 пункту 4.1 цього розділу.

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

Час визначається з точністю до 1 секунди.

Позначка часу повинна бути підписана алгоритмом відповідно до ідентифікатора політики, вказаного у запиті. Якщо ідентифікатор політики не визначено у запиті, то повинна використовуватися політика, яка визначена як політика "за умовчанням".

4.4. Час у позначці часу (поле genTime) кодується у форматі GeneralizedTime - у вигляді рядка YYYYMMDDhhmmss[.s…]Z, де YYYYMMDD - дата (рік-місяць-день), а hhmmss - час (години-хвилини-секунди). Якщо потрібна точність більша ніж одна секунда, до запису додається дробова частина (десятковий запис долі однієї секунди). В записі дробової частини потрібно вилучати всі праві нулі; якщо дробова частина складається тільки з нулів, її потрібно пропускати разом із десятковою крапкою.

Запис часу обов'язково завершується літерою "Z" - вказівкою, що час записано відповідно до всесвітнього координованого часу (UTC).

4.5. Сертифікат центру сертифікації ключів, що використовується для фіксування часу, повинен містити розширення "ExtendedKeyUsage", в якому повинен бути зазначений такий об'єктний ідентифікатор, що визначає право підписувати позначки часу:

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. Для передачі запитів на формування позначок часу та отримання відповідей повинен застосовуватися транспортний протокол HTTP та може застосовуватися транспортний протокол TCP-IP. У разі використання інших транспортних протоколів формати повідомлень не регламентуються.

5.2. Транспортний протокол TCP-IP:

Передача запитів на формування позначок часу та отримання відповідей відбуваються зі встановленням TCP-з'єднання через IP-порт 318 (pkix-timestamp).

Усі повідомлення мають формат, наведений у додатку 4.

Поле "Флаг" може мати значення, наведені в додатку 5.

5.2. Транспортний протокол HTTP:

Передача запиту на формування позначки часу відбувається за допомогою методу POST протоколу HTTP.

Content-Type: application/timestamp-query.

Отримання відповіді у форматі HTTP-відповіді.

Content-Type: application/timestamp-reply.

Усі блоки передаються як байти їх DER-кодування.

5.3. Транспортний протокол, що базується на файловому обміні:

Файли з повідомленнями протоколу фіксування часу повинні містити лише DER-кодовані дані відповідних структур. Не дозволяється додавати до таких файлів будь-яку іншу інформацію (наприклад, у заголовок або у кінець файлу).

Файли, що містять запити на фіксування часу (структура "TimeStampRequest"), повинні мати розширення ".tsq". Файли, що містять відповіді центру сертифікації ключів (структура "TimeStampResponse"), повинні мати розширення ".tsr". Іменами файлів можуть бути довільні дозволені комбінації символів.

5.4. Транспортний протокол, що базується на електронній пошті:

Обмін повідомленнями протоколу фіксування часу через електронну пошту здійснюється за допомогою таких MIME-об'єктів:

Content-Type: application/timestamp-query;

Content-Transfer-Encoding: base64

(base64-кодована DER-структура запиту на фіксування часу);

Content-Type: application/timestamp-reply;

Content-Transfer-Encoding: base64

(base64-кодована DER-структура відповіді на запит фіксування часу).

Рекомендується також включати необов'язкові параметри "name" та "filename". Для імен файлів рекомендується обирати розширення, наведені у пункті 5.3 цього розділу.

Заступник Голови Державного

комітету України з питань науки,

інновацій та інформатизації

С. О. Колобов

Директор Департаменту

регулювання діяльності у сфері

криптографічного захисту інформації

Адміністрації Державної служби

спеціального зв'язку та захисту

інформації України

В. І. Бондаренко

Додаток 1

до Технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу)

Формати даних у нотації ASN.1, що застосовуються при реалізації протоколу фіксування часу

ua-PKI-TSP-policy ::= OBJECT IDENTIFIER {root(1.2.804.2.1.1.1) pki-alg(1) pki-cp (2) tsp-policy(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}

Додаток 2

Можливі значення для типу "PKIStatus"

Константа

Числове значення

Опис

granted

Позначку часу сформовано

grantedWithMods

Позначку часу сформовано з модифікаціями

rejection

У формуванні позначки часу було відмовлено

waiting

Сервер ЦСК перенавантажено

revocationWarning

(Не використовується)

revocationNotification

(Не використовується)

Додаток 3

Можливі значення для типу "PKIFailureInfo"

Константа

Номер біта

Опис

badAlg

Невідомий алгоритм гешування або такий, що не підтримується

badRequest

Запит такий, що не підтримується, або недозволений

badDataFormat

Запит пошкоджений

timeNotAvailable

Неможливо визначити точний час

unacceptedPolicy

Політика формування позначок часу така, що не підтримується

unacceptedExtension

Розширення таке, що не підтримується

addInfoNotAvailable

Відсутня необхідна додаткова інформація

systemFailure

Системна помилка

Додаток 4

Формат повідомлень

Назва блоку

Розмір (байт)

Примітки

Розмір основного блоку (запиту чи відповіді)

Містить розмір полів "Флаг" та "Основний блок". У форматі "network order (big endian)"

Флаг

(наведені у додатку 5 цих Технічних специфікацій)

Основний блок

Змінний

Дані

Додаток 5

Значення поля "Флаг"

Назва флагу

Числове значення

Опис формату поля "Дані"

tsaMsg

DER-кодовані запит чи відповідь

pollRep

Відповідь з даними для опитування на готовність.

Містить 2 поля розміром 4 байти (network order):

ідентифікатор опитування;

час наступного опитування (в секундах).

Ці дані використовуються для подальшого опитування сервера

pollReq

Запит на отримання початкового повідомлення

Містить ідентифікатор опитування (4 байти)

negPollRep

Немає подальших опитувань (транзакція закінчена). Містить 1 байт із значенням "00"

partialMsgRep

Часткова відповідь.

Містить: ідентифікатор наступного опитування (4 байти);

час наступного опитування (в секундах, 4 байти);

DER-кодовану відповідь

finalMsgRep

Остання (можливо єдина) відповідь. Містить DER-кодовану відповідь

errorMsgRep

Помилка. Містить рядок з описом помилки

Технічні специфікації форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката)

ЗАТВЕРДЖЕНО

13.08.2010 N 8/229

Зареєстровано

в Міністерстві юстиції України

9 листопада 2010 р. за N 1054/18349

ТЕХНІЧНІ СПЕЦИФІКАЦІЇ

форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката)

I. Загальні положення

1.1. Ці Технічні специфікації визначають процедуру інтерактивного визначення статусу сертифіката та формати даних.

1.4. Ці Технічні специфікації засновані на міжнародному стандарті RFC 2560 "Internet X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP".

1.6. У цих Технічних специфікаціях терміни вживаються у такому значенні:

користувач - особа, що користується послугою інтерактивного визначення статусу сертифіката і взаємодіє з OCSP-сервером;

служба інтерактивного визначення статусу сертифіката (OCSP-сервер) - спеціальна служба центру сертифікації ключів (далі - ЦСК), яка за запитами користувачів визначає статус сертифікатів та надсилає відповідь, де зазначається статус сертифіката, який перевіряється, на даний момент.

1.7. Для визначення алгоритму гешування поле "algorithm" повинно мати значення

Gost34311 OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-hash (2) 1}

В усіх інших операціях обчислення значення геш-функції згідно з ГОСТ 34.311-95 повинен використовуватися ДКЕ N 1, наведений у додатку 1 до Інструкції про порядок постачання і використання ключів до засобів криптографічного захисту інформації, затвердженої наказом Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 12.06.2007 N 114, зареєстрованої в Міністерстві юстиції України 25.06.2007 за N 729/13996 (далі - ДКЕ N 1).

ДКЕ N 1 використовується як ДКЕ "за умовчанням".

II. Процедура інтерактивного визначення статусу сертифіката

2.1. Під час інтерактивного визначення статусу сертифіката користувач та OCSP-сервер виконують такі

дії:

2.1.1. Користувач формує запит на інтерактивну перевірку статусу сертифіката (далі - запит) та надсилає його до OCSP-сервера.

Запит включає:

версію протоколу;

службовий запит;

ідентифікатор необхідного сертифіката;

необов'язкові розширення, які може обробляти OCSP-сервер;

2.1.2. OCSP-сервер отримує запит і перевіряє, чи:

повідомлення правильно сформоване;

запит містить всю необхідну для обробки інформацію.

Якщо будь-яка з перерахованих умов не виконується, то OCSP-сервер формує повідомлення про помилку.

Якщо запит сформовано вірно, OCSP-сервер повертає відповідь на запит з інформацією про статус сертифіката (далі - відповідь). Відповідь містить:

версію синтаксису відповіді;

ім'я OCSP-сервера;

відповідь для сертифіката в запиті;

необов'язкові розширення;

тип алгоритму підпису;

ЕЦП, що обчислений від геш-значення відповіді.

Відповідь для сертифіката в запиті складається з:

ідентифікатора необхідного сертифіката;

значення статусу сертифіката;

інтервалу часу дійсності відповіді;

необов'язкових розширень;

2.1.3. Після накладання OCSP-сервером ЕЦП відповідь направляється користувачеві;

2.1.4. Отримавши відповідь, користувач має перевірити, що:

сертифікат, вказаний в отриманій відповіді, відповідає вказаному у відповідному запиті;

ЕЦП відповіді дійсний;

ім'я суб'єкта, що підписав відповідь, збігається з іменем OCSP-сервера, до якого був направлений запит;

OCSP-сервер має право підписувати відповідь;

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

III. Формати даних

3.1. Формат запиту та формат відповіді визначені на основі міжнародного стандарту RFC 2560 (OCSP).

3.2. Запит на інтерактивну перевірку статусу сертифіката представляється у вигляді повідомлення "OCSPRequest":

OCSPRequest ::= SEQUENCE {

tbsRequest

TBSRequest,

optionalSignature

[0] EXPLICIT Signature OPTIONAL}

3.2.1. Поле "tbsRequest" містить безпосередньо дані запиту. Дані запиту містяться в типі "TBSRequest" та мають такий формат:

TBSRequest ::= SEQUENCE {

version

[0] EXPLICIT Version DEFAULT v1,

requestorName

[1] EXPLICIT GeneralName OPTIONAL,

requestList

SEQUENCE OF Request,

requestExtensions

[2] EXPLICIT Extensions OPTIONAL}

Поле "version" містить версію формату запиту.

Поле "requestorName" може містити ім'я користувача. Поле присутнє у випадках, якщо запит підписано.

Поле "requestList" містить інформацію про сертифікати, статус яких підлягає перевірці.

Тип "Request" містить ідентифікаційну інформацію про сертифікат, статус якого буде необхідно перевірити.

Request ::= SEQUENCE {

reqCert

CertID,

singleRequestExtensions

[0] EXPLICIT Extensions OPTIONAL}

Поле "reqCert" містить ідентифікаційну інформацію про сертифікат.

Поле "singleRequestExtensions" може містити додаткову інформацію про сертифікат, що перевіряється.

CertID ::= SEQUENCE {

hashAlgorithm

AlgorithmIdentifier,

issuerNameHash

OCTET STRING,

issuerKeyHash

OCTET STRING,

serialNumber

CertificateSerialNumber}

Поле "hashAlgorithm" містить об'єктний ідентифікатор алгоритму гешування даних про сертифікат. Об'єктний ідентифікатор алгоритму повинен мати значення:

gost34311 OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1) pki-alg-hash (2) 1}

Поле "issuerNameHash" містить геш-значення, що обчислюється від DER-кодування повного імені ЦСК (поле "Subject" сертифіката ЦСК), що випустив сертифікат, статус якого перевіряється.

При обчисленні значення геш-функції значення стартового вектора H функції гешування згідно з ГОСТ 34.311-95 встановлюється рівним 256 нульовим бітам. Як ДКЕ використовується ДКЕ "за умовчанням" згідно з пунктом 1.7 розділу I цих Технічних специфікацій.

Поле

"issuerKeyHash" містить геш-значення, що обчислюється від відкритого ключа ЦСК (поле "SubjectPublicKey" сертифіката ЦСК із вилученими байтами тегу та довжини), що випустив сертифікат, статус якого перевіряється.

При обчисленні значення геш-функції значення стартового вектора H функції гешування за ГОСТ 34.311-95 встановлюється рівним 256 нульовим бітам. Як ДКЕ використовується ДКЕ за умовчанням, як визначено у пункті 1.7 розділу I цих Технічних специфікацій.

Поле "serialNumber" містить серійний номер сертифіката, що перевіряється.

Поле "requestExtensions" може містити розширення з додатковою інформацією.

3.2.2. Поле "optionalSignature" є необов'язковим та може містити ЕЦП даних запиту.

Signature ::= SEQUENCE {

signatureAlgorithm

AlgorithmIdentifier,

signature

BIT STRING,

certs[0]

EXPLICIT SEQUENCE OF Certificate OPTIONAL}

Поле "signatureAlgorithm" містить ідентифікатор алгоритму електронного цифрового підпису.

Поле "parameters" поля "signatureAlgorithm" заповнюється відповідно до визначеного ідентифікатора алгоритму електронного цифрового підпису.

Поле "signature" містить безпосередньо байти ЕЦП.

Поле "certs" є необов'язковим та містить сертифікати, які можуть допомогти OCSP-серверу перевірити запит.

3.3. Відповідь на інтерактивну перевірку статусу сертифіката представляється у вигляді повідомлення "OCSPResponse":

OCSPResponse ::= SEQUENCE {

responseStatus

OCSPResponseStatus,

responseBytes

[0] EXPLICIT ResponseBytes OPTIONAL}

3.3.1. Поле "responseStatus" містить інформацію про статус обробки запиту.

OCSPResponseStatus ::= ENUMERATED {

successful

(0),

malformedRequest

(1),

internalError

(2),

tryLater

(3),

sigRequired

(5),

unauthorized

(6)}

Опис числових значень поля "responseStatus" наведено в додатку 2.

3.3.2. Поле "responseBytes" може містити інформацію про статус сертифіката. Це поле має бути обов'язково присутнє, якщо статус обробки запиту дорівнює нулю, та має бути відсутнім в інших випадках.

Тип "ResponseBytes" містить ідентифікатор типу даних та безпосередньо дані відповіді.

ResponseBytes ::= SEQUENCE {

responseType

OBJECT IDENTIFIER,

response

OCTET STRING}

Поле "responseType" містить об'єктний ідентифікатор типу даних, що містяться в полі "response".

Для типу даних "BasicOCSPResponse" поле "responseType" має об'єктний ідентифікатор "id-pkix-ocsp-basic".

id-pkix-ocsp-basic OBJECT IDENTIFIER::= { id-pkix-ocsp 1 }

Тип "BasicOCSPResponse" має такий формат:

BasicOCSPResponse ::= SEQUENCE {

tbsResponseData

ResponseData,

signatureAlgorithm

AlgorithmIdentifier,

signature

BIT STRING,

certs

[0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}

Поле "tbsResponseData" містить відповідь про стан сертифіката.

Тип "ResponseData" містить дані про стан сертифіката:

ResponseData ::= SEQUENCE {

version

[0] EXPLICIT Version DEFAULT v1,

responderID

ResponderID,

producedAt

GeneralizedTime,

responses

SEQUENCE OF SingleResponse,

responseExtensions

[1] EXPLICIT Extensions OPTIONAL}

Поле "version" містить версію формату відповіді (дорівнює 1).

Поле "responderID" містить ідентифікаційну інформацію про сервер, що сформував відповідь.

ResponderID ::= CHOICE {

byName

[1] Name,

byKey

[2] KeyHash}

KeyHash::= OCTET STRING

Сервер-підписувач може бути ідентифікований за ім'ям або гешем ключа KeyHash, що містить геш-значення, яке обчислюється від відкритого ключа сервера-підписувача статусу сертифіката (служби) OCSP ЦСК (поле "SubjectPublicKey" сертифіката сервера/служби OCSP із вилученими байтами тегу та довжини).

У разі використання імені у полі "ResponderID" (byName) вказується повне ім'я сервера (поле Subject його сертифіката).

В разі використання гешу ключа у полі "ResponderID" (byKeyHash) вказується геш-значення відкритого ключа підписувача (поля "SubjectPublicKey" його сертифіката із вилученими байтами тегу та довжини).

Поле "producedAt" містить час формування відповіді.

Поле "responses" містить набір відповідей про статус сертифікатів.

SingleResponse

::= SEQUENCE {

certID

CertID,

certStatus

CertStatus,

thisUpdate

GeneralizedTime,

nextUpdate

[0] EXPLICIT GeneralizedTime OPTIONAL,

singleExtensions

[1] EXPLICIT Extensions OPTIONAL}

Поле "certID" містить ідентифікаційні дані сертифіката.

Поле "certStatus" містить дані про статус сертифіката.

CertStatus ::= CHOICE {

good

[0] IMPLICIT NULL,

revoked

[1] IMPLICIT RevokedInfo,

unknown

[2] IMPLICIT UnknownInfo}

RevokedInfo ::= SEQUENCE {

revocationTime

GeneralizedTime,

revocationReason

[0] EXPLICIT CRLReason OPTIONAL}

UnknownInfo ::= NULL

Поле "thisUpdate" містить час, на який було визначено статус сертифіката.

Поле "nextUpdate" є необов'язковим та може містити час наступного оновлення інформації про статус сертифіката.

Поле "singleExtensions" може містити додаткову інформацію про статус сертифіката.

Поле "responseExtensions" може містити додаткову інформацію про відповідь.

Поле "signatureAlgorithm" містить алгоритм ЕЦП.

Формат алгоритму ЕЦП відповідає вимогам пункту 3.2 цього розділу.

У разі відсутності підпису у запиті відповідь повинна формуватися з використанням алгоритму ДСТУ 4145-2002 (ПБ) як алгоритму "за умовчанням".

При формування відповіді повинен використовуватися той алгоритм ЕЦП, який було використано при формуванні запиту.

Якщо сервер не підтримує алгоритм ЕЦП, використаний у запиті, то OCSP-сервер може повернути помилку "malformedRequest" (пошкоджений або недозволений запит) або сформувати відповідь з використанням алгоритму ДСТУ 4145-2002 (ПБ).

Поле "signature" містить значення ЕЦП.

Поле "certs" є необов'язковим та може містити набір сертифікатів для перевірки ЕЦП відповіді.

3.4. Розширення, які можуть бути використані як користувачем, так і OCSP-сервером не повинні бути критичними.

Ідентифікатори розширень, що є специфічними для протоколу OSCP, визначаються через кореневий ідентифікатор "id-pkix-ocsp":

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

3.4.1. Маркер - спеціальна мітка, яку користувач може додати до запиту, щоб запобігти атакам дублювання запитів. Для кожного запиту маркер повинен бути унікальним; сервер у свою відповідь повинен включити такий самий маркер.

Розширення із маркером визначається таким об'єктним ідентифікатором:

id-pkix-ocsp-nonce

OBJECT IDENTIFIER::= { id-pkix-ocsp 2 }

Значення маркера вказується безпосередньо у полі "extnValue" розширення без попереднього DER-кодування.

3.4.2. Користувач може зазначити у запиті, які можливі типи відповідей він може обробити. Перелік допустимих типів визначається розширенням "AcceptableResponses":

id-pkix-ocsp-responce

OBJECT IDENTIFIER::= { id-pkix-ocsp 4 }

AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

Це розширення може використовуватись тоді, коли OCSP-сервер підтримує декілька типів відповідей. Коли таке розширення відсутнє, сервер повинен повертати відповідь "BasicOCSPResponse".

3.4.3. Під час посилання на список відкликаних сертифікатів OCSP-сервер може включити у "singleExtensions" посилання на список відкликаних сертифікатів, з якого був одержаний статус вказаного сертифіката. Це може бути зручно для організації робіт між різними ЦСК та проведення аудиту. Для цього використовується розширення CrlID:

id-pkix-ocsp-crl

OBJECT IDENTIFIER::= { id-pkix-ocsp 3 }

CrlID ::= SEQUENCE {

crlUrl [0] EXPLICIT IA5String OPTIONAL,

crlNum

[1] EXPLICIT INTEGER OPTIONAL,

crlTime

[2] EXPLICIT GeneralizedTime OPTIONAL }

Список відкликаних сертифікатів може бути зазначений через URL, за яким його можна одержати, через його номер та/або через дату його публікації.

3.4.4. OCSP-сервер може включити у "singleExtensions" будь-яке розширення, що міститься у відповідному елементі списку відкликаних сертифікатів.

3.5. Сертифікат OCSP-сервера повинен містити розширення "ExtendedKeyUsage", в якому повинен бути зазначений такий об'єктний ідентифікатор, що визначає право підписувати OCSP-відповіді:

id-kp-OCSPSigning OBJECT

IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-kp(3) 9 }

Зазначене розширення повинно бути критичним.

Сертифікат OCSP-сервера повинен бути виданий безпосередньо тим центром сертифікації ключів, що видав і сертифікат, статус якого перевіряється.

IV. Транспортні протоколи

4.1. Для передачі запитів на формування позначок часу та отримання відповідей повинен застосовуватися транспортний протокол HTTP та може застосовуватися транспортний протокол TCP-IP. У разі використання інших транспортних протоколів формати повідомлень не регламентуються.

4.2. Передача запитів на формування позначок часу та отримання відповідей із застосуванням транспортного протоколу TCP-IP відбуваються із встановленням TCP-з'єднання через IP-порт 340. Усі повідомлення мають формати, наведені в додатку 3.

4.3. Передача запиту на перевірку статусу сертифіката із застосуванням транспортного протоколу HTTP відбувається за допомогою методу GET або POST протоколу HTTP.

4.3.1. Метод GET протоколу HTTP застосовується, якщо загальна довжина запиту не перевищує 255 байт.

Для методу GET запит формується таким чином:

GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}.

4.3.2. Якщо загальна довжина запиту перевищує 255 байт, то застосовується метод POST протоколу HTTP.

Для методу POST протоколу HTTP запит формується таким чином:

Content-Type: application/ocsp-request.

Тіло повідомлення повинно містити байти DER-кодування структури "OCSPRequest".

Для методу POST протоколу HTTP відповідь формується таким чином:

Content-Type: application/ocsp-response.

"Content-Length" вказує на довжину відповіді. Блоки даних передаються як байти їх DER-кодування.

Заступник Голови Державного

комітету України з питань науки,

інновацій та інформатизації

С. О. Колобов

Директор Департаменту

регулювання діяльності у сфері

криптографічного захисту інформації

Адміністрації Державної служби

спеціального зв'язку та захисту

інформації України

В. І. Бондаренко

Додаток 1

до Технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката)

Формати даних у нотації ASN.1, що застосовуються при реалізації протоколу визначення статусу сертифіката

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

OCSPRequest ::= SEQUENCE {

tbsRequest

TBSRequest,

optionalSignature

[0] EXPLICIT Signature OPTIONAL}

Signature ::= SEQUENCE {

signatureAlgorithm

AlgorithmIdentifier,

signature

BIT STRING}

TBSRequest ::= SEQUENCE {

version

[0] EXPLICIT Version DEFAULT v1,

requestorName

[1] EXPLICIT GeneralName OPTIONAL,

requestList

SEQUENCE OF Request,

requestExtensions

[2] EXPLICIT Extensions OPTIONAL}

Request ::= SEQUENCE {

reqCert

CertID,

singleRequestExtensions

[0] EXPLICIT Extensions OPTIONAL}

CertID ::= SEQUENCE {

hashAlgorithm

AlgorithmIdentifier,

issuerNameHash

OCTET STRING,

issuerKeyHash

OCTET STRING,

serialNumber

CertificateSerialNumber}

OCSPResponse ::= SEQUENCE {

responseStatus

OCSPResponseStatus,

responseBytes

[0] EXPLICIT ResponseBytes OPTIONAL}

OCSPResponseStatus ::= ENUMERATED {

successful

(0),

malformedRequest

(1),

internalError

(2),

tryLater

(3),

sigRequired

(5),

unauthorized

(6)}

ResponseBytes ::= SEQUENCE {

responseType

OBJECT IDENTIFIER,

response

OCTET STRING}

BasicOCSPResponse ::= SEQUENCE {

tbsResponseData

ResponseData,

signatureAlgorithm

AlgorithmIdentifier,

signature

BIT STRING,

certs

[0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}

ResponseData ::= SEQUENCE {

version

[0] EXPLICIT Version DEFAULT v1,

responderID

ResponderID,

producedAt

GeneralizedTime,

responses

SEQUENCE OF SingleResponse,

responseExtensions

[1] EXPLICIT Extensions OPTIONAL}

ResponderID ::= CHOICE {

byName

[1] Name,

byKeyHash

[2] KeyHash }

SingleResponse ::= SEQUENCE {

certID

CertID,

certStatus

CertStatus,

thisUpdate

GeneralizedTime,

nextUpdate

[0] EXPLICIT GeneralizedTime OPTIONAL,

singleExtensions

[1] EXPLICIT Extensions OPTIONAL}

CertStatus ::= CHOICE {

good

[0] IMPLICIT NULL,

revoked

[1] IMPLICIT RevokedInfo,

unknown

[2] IMPLICIT UnknownInfo}

RevokedInfo ::= SEQUENCE {

revocationTime

GeneralizedTime,

revocationReason

[0] EXPLICIT CRLReason OPTIONAL}

UnknownInfo ::= NULL

Додаток 2

Опис числових значень поля "responseStatus"

Константа

Числове значення

Опис

successful

Операція завершилась успішно

malformedRequest

Пошкоджений або недозволений запит

internalError

Внутрішня помилка

tryLater

Сервер перенавантажений

sigRequired

Сервер обробляє лише підписані запити

unauthorized

Запит від неавторизованого користувача

Додаток 3

Формати повідомлення

Назва блоку

Розмір (байт)

Примітки

Розмір основного блоку (запиту чи відповіді)

У форматі "Little-Endinan"

Основний блок

Змінний

DER-кодування блоку (запиту чи відповіді)

Джерело: Єдиний державний реєстр нормативно-правових актів Міністерства юстиції України · картка акта · текст у реєстрі