Идет загрузка документа (68 kByte)
Главный правовой
портал Украины
Главный правовой
портал Украины
Остаться Попробовать

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

Государственный комитет Украины по вопросам науки; инноваций и информатизации, Администрация Государственной службы специальной связи и защиты информации Украины
Приказ от 13.08.2010 № 8/229
Утратил силу

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

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

Зареєстровано в Міністерстві юстиції України
9 листопада 2010 р. за N 1052/18347

Рішення про державну реєстрацію наказу скасовано наказом 
Міністерства юстиції України від 10 травня 2011 року N 1304/5
 згідно з
Висновком Міністерства юстиції України 
від 10 травня 2011 року N 2/105
 
Наказ виключено з Державного реєстру нормативно-правових актів міністерств 
та інших органів виконавчої влади 
1 червня 2011 року 

Відповідно до Порядку засвідчення наявності електронного документа (електронних даних) на певний момент часу, затвердженого постановою Кабінету Міністрів України від 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. Контроль за виконанням наказу покласти на першого заступника Голови Державного комітету України з питань науки, інновацій та інформатизації Мєзєнцеву Н. Б. та першого заступника Голови Державної служби спеціального зв'язку та захисту інформації України Цуркана О. Г.

 

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

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

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

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

ПОГОДЖЕНО: 

  

Виконуючий обов'язки
Міністра економіки України
 

 
А. А. Максюта
 

Голова Державного комітету
України з питань регуляторної
політики та підприємництва
 

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

В. о. Голови Національної
комісії з питань регулювання
зв'язку України
 

 
 
В. П. Звєрєв
 

Міністр транспорту та
зв'язку України
 

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

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

 
І. Б. Матяш
 

Начальник Головного управління
державної служби України
 

 
Т. Мотренко
 

Голова Державної митної
служби України
 

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

 

ТЕХНІЧНІ СПЕЦИФІКАЦІЇ
форматів представлення базових об'єктів національної системи електронного цифрового підпису (формат підписаних даних)

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" (наприклад, від різних центрів сертифікації ключів, що надають послугу фіксування часу).

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

Формат представлення структури "TimeStampToken" визначається згідно з підпунктом 4.2.2 пункту 4.2 розділу II Технічних специфікацій форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол фіксування часу), затверджених наказом Державного комітету України з питань науки, інновацій та інформатизації, Адміністрації Державної служби спеціального зв'язку та захисту інформації України від 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 

____________

Опрос