|
|
| МІНІСТЕРСТВО ЮСТИЦІЇ УКРАЇНИ |
| НАКАЗ |
| 20.08.2012 № 1236/5/453 |
|
| Зареєстровано в Міністерстві |
Прозатвердження вимог до форматів, структури та протоколів, що реалізуються унадійних засобах електронного цифрового підпису
На виконання пункту 3
1. Затвердити такі, щододаються, вимоги до форматів, структури та протоколів, що реалізуються унадійних засобах електронного цифрового підпису (далі - Вимоги):
1.1.
1.2.
1.3.
1.4.
1.5.
1.6.
2. Установити, що:
2.1. Акредитовані центрисертифікації ключів, замовники, розробники, виробники та організації, якіексплуатують надійні засоби електронного цифрового підпису в системахелектронного документообігу, що створюються на виконання
2.2. Акредитовані центрисертифікації ключів, замовники, розробники, виробники та організації, якіексплуатують надійні засоби електронного цифрового підпису, крім визначених упідпункті 2.1 пункту 2 цього наказу, забезпечують застосування упрограмно-технічних комплексах акредитованих центрів сертифікації ключів танадійних засобах електронного цифрового підпису положень Вимог з 01 червня 2013року.
2.3. Акредитовані центрисертифікації ключів, які здійснили заходи, визначені у підпунктах 2.1, 2.2пункту 2 цього наказу, надають послуги електронного цифрового підпису з моментупроходження повторної акредитації відповідно до пункту 13
3. Адміністрації Державноїслужби спеціального зв’язку та захисту інформації України вжити заходів длявпровадження Вимог у програмно-технічних комплексах акредитованих центрівсертифікації ключів та надійних засобах електронного цифрового підпису встроки, визначені у підпунктах 2.1, 2.2 пункту 2 цього наказу.
4. Департаменту нотаріату,банкрутства та функціонування центрального засвідчувального органу Міністерстваюстиції України (Чижмарь К.І.) розмістити цей наказ на офіційному веб-сайтіМіністерства юстиції України.
5. Цей наказ набирає чинності здня його офіційного опублікування.
6. Контроль за виконанням цьогонаказу покласти на заступника Міністра юстиції України Ворону М.Д. та першогозаступника Голови Державної служби спеціального зв’язку та захисту інформаціїУкраїни Цуркана О.Г.
| Міністр юстиції України | О.В. Лавринович |
| Голова Державної служби |
|
|
| ЗАТВЕРДЖЕНО |
|
| Зареєстровано в Міністерстві |
ВИМОГИ
до формату посиленого сертифіката відкритого ключа
І.Загальні положення
1.1. Ці Вимоги визначаютьформат посиленого сертифіката відкритого ключа (далі - сертифікат).
1.2. Формати даних представленоу нотації ASN.1, визначеній у міжнародному стандарті ISO/IEC 8824 “Informationtechnology - Open Systems Interconnection - Specification of Abstract SyntaxNotation One (ASN.1)” / ДСТУ ISO/ІЕС 8824-3:2008 “Інформаційні технології.Нотація абстрактного синтаксису 1 (ASN.1)” - частина 3. Специфікація обмежень(ISO/IEC 8824-3:2002, IDT), затвердженому
1.3. Усі структури данихкодують за правилами DER згідно з міжнародним стандартом ISO/IEC 8825-1:2002“Information technology - ASN.1 encoding Rules - Part 1: Specification of BasicEncoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished EncodingRules (DER)” & AMD1:2004 “Support for EX-TENDED-XER”.
1.4. Ці Вимоги засновані нанаціональному стандарті України ДСТУ ISO/IEC 9594-8:2006 “Інформаційнітехнології. Взаємозв'язок відкритих систем. Каталог. Частина 8. Основніположення щодо сертифікації відкритих ключів та атрибутів”, затвердженому
1.5. Ці Вимоги не дублюютьстандарт ДСТУ ISO/IEC 9594-8:2006, а описують положення цього стандарту таформати полів. У разі виникнення розбіжностей між положеннями зазначеногостандарту та положеннями цих Вимог застосовуються положення цих Вимог.
1.6. Положення цих Вимог єобов’язковими для програмно-технічних комплексів акредитованих центрівсертифікації ключів та надійних засобів електронного цифрового підпису.Правильність реалізації формату посиленого сертифіката відкритого ключа унадійних засобах електронного цифрового підпису підтверджується сертифікатомвідповідності або позитивним експертним висновком за результатами державноїекспертизи у сфері криптографічного захисту інформації.
ІІ.Подання сертифіката
Сертифікат ключа подається втакому вигляді:
| Certificate ::= SEQUENCE { | ||
|
| tbsCertificate | TBSCertificate, |
|
| signatureAlgorithm | AlgorithmIdentifier, |
|
| signatureValue | BIT STRING } |
Поле “TBSCertificate” - цечастина сертифіката, на яку за допомогою особистого ключа центральногозасвідчувального органу, засвідчувального центру, акредитованого центрусертифікації ключів (далі - Центр) накладається електронний цифровий підпис(далі - ЕЦП) за криптографічним алгоритмом (далі - криптоалгоритм), об’єктнийідентифікатор якого міститься у полі “signatureAlgorithm”. Значення ЕЦП міститьполе “signatureValue”.
Для усіх строкових даних таполів сертифіката, що мають універсальний тип “DirectoryString”,використовується кодування UTF-8. Для набору символів ASCII може використовуватисякодування PrintableString. Символ “;” використовується як роздільник даних уполі сертифіката.
ІІІ.Основні поля сертифіката
3.1. Основні поля сертифікатанаведено в таблиці 1.
Таблиця 1
3.2. Поле “Номер версіїсертифіката” (“version”) повинно містити значення “2” (1 байт), яке означає, щоформат сертифіката відповідає версії 3 згідно з національним стандартом ДСТУISO/IEC 9594-8:2006.
Version ::= INTEGER {v3 (2)}
3.3. Значення поля “Унікальнийреєстраційний номер сертифіката” (“serialNumber”) повинно бути додатним цілимчислом, розмір якого не перевищує 20 байт (0<serialNumber<2
Унікальність реєстраційногономера сертифіката повинна дотримуватися у рамках всіх сертифікатів,сформованих Центром.
CertificateSerialNumber::=INTEGER
3.4. Поле “Найменування тареквізити Центру” (“issuer”) повинно містити найменування та реквізити Центру.
3.5. У полі “Найменування тареквізити Центру” (“issuer”) повинні міститися реквізити Центру, що наведені утаблиці 2.
Таблиця 2
3.5.1. Поля “Найменування тареквізити Центру” (“issuer”) та “Унікальний реєстраційний номер сертифіката”(“serialNumber”) у структурі “TBSCertificate” разом ідентифікують унікальнийсертифікат.
3.5.2. Реквізит “Унікальнийреєстраційний номер сертифіката” (“serialNumber”) у таблиці 2 міститьунікальний реєстраційний номер Центру.
Формування унікальногореєстраційного номера здійснюється згідно з нижченаведеними правилами.
Реквізит містить цифри “0”-“9”,великі латинські літери “А”-“Z” та символ “-”;
UA-[Код Установи] {-[Додаток]},де:
Код Установи - 8, 9 або 10цифр, що містять код за ЄДРПОУ організації - юридичної особи або реєстраційнийномер облікової картки платника податку - фізичної особи, яка є суб'єктомпідприємницької діяльності за установчими документами або відомостями про державнуреєстрацію;
Додаток - необов’язковапослідовність від 1 до 4 цифр, що містить додаткову частину ідентифікатора. Уразі використання Додатка він відокремлюється від реквізиту [Код Установи]символом “-”.
Вищезазначений реквізит шляхомйого додавання до розпізнавального імені Центру забезпечує унікальність йогорозпізнавального імені в межах України. Унікальність цього розпізнавальногоімені забезпечується центральним засвідчувальним органом.
3.6. Поле “Алгоритм ЕЦП”(“signature”) повинно містити тільки об’єктний ідентифікатор криптоалгоритму,що використовується Центром для накладання електронного цифрового підпису насертифікат ключа.
| AlgorithmIdentifier ::= SEQUENCE { | ||
|
| algorithm | OBJECT IDENTIFIER, |
|
| parameters | ANY DEFINED BY algorithm OPTIONAL } |
Значення поля “Алгоритм ЕЦП”(“signature”) повинно співпадати із значенням, що міститься у полі“Найменування криптоалгоритму, що використовується Центром”(“signatureAlgorithm”).
Поле “parameters” повинно бутивідсутнє.
3.7. Поле “Строк чинностісертифіката” (“validity”) повинно містити значення дати і часу початку тазакінчення строку чинності сертифіката.
| Validity ::= SEQUENCE { | ||
|
| notBefore | Time, |
|
| notAfter | Time} |
| Time ::= CHOICE { | ||
|
| utcTime | UTCTime, |
|
| generalTime | GeneralizedTime} |
Поле “Time” зі значенням до 31грудня 2049 року (включно) кодується у форматі “UTCTime”; починаючи з 01 січня2050 року - у форматі “GeneralizedTime”.
3.8. Поле “Підписувач”(“subject”) повинно містити реквізити підписувача, що наведені у таблиці 3.
Таблиця 3
3.8.1. Реквізити юридичноїособи-підписувача визначаються в таких атрибутах поля “Підписувач” (“subject”):
organizationName,
countryName,
stateOrProvinceName,
localityName,
commonName.
3.8.2. Реквізити фізичної особи- підписувача (прізвище, ім’я та по батькові за паспортними даними)визначаються в таких атрибутах поля “Підписувач” (“subject”):
commonName,
givenName,
surname.
Обов’язково повинні бутивизначені дані в атрибутах “countryName” та “serialNumber” (унікальнийреєстраційний номер підписувача).
3.8.3. Реквізити фізичної особи- підписувача, що представляє юридичну особу (або фізичну особу - суб’єктапідприємницької діяльності), визначаються в таких атрибутах поля “Підписувач”(“subject”):
commonName,
givenName,
surname,
organizationName,
organizationalUnitName,
localityName,
stateOrProvinceName,
Title.
Обов’язково повинні бути визначенідані в атрибутах “countryName” та “serialNumber” (унікальний реєстраційнийномер підписувача).
3.8.4. Інші реквізитипідписувача можуть бути зазначені у розширеннях (extensions) “Додаткові даніпідписувача“ (“subjectAltName”) або “Персональні дані підписувача“(“subjectDirectoryAttributes”) залежно від типу реквізиту.
3.9. Додаткові дані пропідписувача можуть бути зазначені в інших полях згідно з форматом, визначеним унаціональному стандарті ДСТУ ISO/IEC 9594-8:2006.
3.10. Поле “Інформація про відкритийключ підписувача” (“subjectPublicKeyInfo”) повинно містити ідентифікаторкриптоалгоритму, що використовується підписувачем, а також відкритий ключ, якийвідповідає особистому ключу підписувача у DER-кодуванні.
| SubjectPublicKeyInfo ::= SEQUENCE { | ||
|
| Algorithm | AlgorithmIdentifier, |
|
| subjectPublicKey | BIT STRING } |
Ідентифікатор криптоалгоритму(поле “AlgorithmIdentifier”) містить об’єктний ідентифікатор (поле “algorithm”)та відповідні параметри криптоалгоритму.
| AlgorithmIdentifier ::= SEQUENCE { | |
|
| algorithm OBJECT IDENTIFIER, |
|
| parameters ANY DEFINED BY algorithm OPTIONAL} |
Об’єктний ідентифікатор (поле“algorithm”) повинен вказувати на один з криптоалгоритмів:
ДСТУ 4145-2002 “Інформаційнатехнологія. Криптографічний захист інформації. Електронний цифровий підпис, щоґрунтується на еліптичних кривих”, затвердженого наказом Державного комітетуУкраїни з питань технічного регулювання та споживчої політики від 28 грудня2002 року № 31 (далі - ДСТУ 4145-2002);
ГОСТ 34.310-95 “Информационнаятехнология. Криптографическая защита информации. Процедуры выработки и проверкиэлектронной цифровой подписи на базе асимметричного криптографическогоалгоритма”, затвердженого наказом Державного комітету України з питаньтехнічного регулювання та споживчої політики від 21 жовтня 1997 року № 640(далі - ГОСТ 34.310-95).
Структура параметрівкриптоалгоритму (поле “parameters”) та структура відкритого ключа (поле“subjectPublicKey”) визначаються об’єктним ідентифікатором криптоалгоритму.
3.11. Параметрикриптоалгоритмів
3.11.1. Параметрикриптоалгоритму ДСТУ 4145-2002
Значення довгостроковогоключового елемента (далі - ДКЕ) повинні відповідати правилам постачання ДКЕ,які визначаються Інструкцієюпро порядок постачання і використання ключів до засобів криптографічногозахисту інформації ( z0729-07 )
3.11.1.1. Допускаєтьсякодування полів (розташування внутрішньої послідовності байтів) параметрівеліптичної кривої, що мають тип OCTET STRING, зокрема коефіцієнта В еліптичноїкривої, базової точки еліптичної кривої bp, а також відкритого ключа“subjectPublicKey” за двома форматами:
Little-Endian - прямий порядокпредставлення байтів;
Big-Endian - зворотний порядокпредставлення байтів (відповідно до правил кодування, визначених в ДСТУ4145-2002).
3.11.1.2. Об’єктніідентифікатори для ДСТУ 4145-2002.
Для формату Little-Endian (привизначенні параметрів еліптичної кривої у сертифікаті):
| поліноміальний базис | 1.2.804.2.1.1.1.1.3.1.1 |
| оптимальний нормальний базис | 1.2.804.2.1.1.1.1.3.1.2. |
Для формату Big-Endian:
| поліноміальний базис | 1.2.804.2.1.1.1.1.3.1.1.1.1 |
| оптимальний нормальний базис | 1.2.804.2.1.1.1.1.3.1.2.1.1. |
3.11.1.3. Базова точка ДСТУ4145-2002.
Для зображення базової точкивикористовується формат:
bp OCTET STRING
Базова точка ДСТУ 4145-2002 -це послідовність байтів, яка являє собою елемент основного поля (згідно зпунктом 5.3 ДСТУ 4145-2002), який є стиснутим зображенням (згідно з пунктом 6.9ДСТУ 4145-2002) точки на еліптичній кривій (залежить від базису, щовикористовується). Розмір зображення в байтах дорівнює m/8, заокругленому донайближчого цілого у більшу сторону.
3.11.1.4. Коефіцієнт Веліптичної кривої.
Для зображення коефіцієнта Bеліптичної кривої згідно з ДСТУ 4145-2002 використовується формат:
b OCTET STRING
Коефіцієнт B еліптичної кривоїДСТУ 4145-2002 - це послідовність байтів, яка являє собою елемент основногополя (згідно з пунктом 5.3 ДСТУ 4145-2002). Розмір зображення в байтах дорівнюєm/8, заокругленому до найближчого цілого у більшу сторону.
3.11.1.5. Відкритий ключ ДСТУ4145-2002.
Для зображення відкритого ключазгідно з ДСТУ 4145-2002 використовується формат (інкапсульовано у поле“subjectPublicKey”):
PublicKey:: = OCTET STRING
Відкритий ключ ДСТУ 4145-2002 -це послідовність байтів, яка являє собою елемент основного поля (згідно зпунктом 5.3 ДСТУ 4145-2002), який є стиснутим зображенням (згідно з пунктом 6.9ДСТУ 4145-2002) точки на еліптичній кривій, що відображає відкритий ключ ЕЦП.Розмір зображення в байтах дорівнює значенню m/8, заокругленому до найближчогоцілого у більшу сторону.
3.11.1.6. ЕЦП за ДСТУ4145-2002.
ЕЦП за ДСТУ 4145-2002 - церядок октетів OCTET STRING (інкапсульовано у поле “signatureValue”), що міститьцифровий підпис, зображений згідно з пунктами 5.7 та 5.10 ДСТУ 4145-2002:
DSTU4145Signature::= OCTETSTRING
Для зберігання зображення ЕЦПвикористовується мінімально можлива довжина зображення для відповідного ступеняm.
3.11.2. Параметрикриптоалгоритму ГОСТ 34.310-95.
| Gost34310Params::=SEQUENCE {SEQUENCE { | |||
|
| p | INTEGER, | характеристика основного поля |
|
| q | INTEGER, | порядок циклічної підгрупи |
|
| a | INTEGER }, | твірний елемент циклічної підгрупи |
|
| dke | OCTET STRING OPTIONAL } | ДКЕ. |
3.11.2.1. Об’єктнийідентифікатор для ГОСТ 34.310-95.
Об’єктний ідентифікатор дляГОСТ 34.310-95: 1.2.804.2.1.1.1.1.3.2.
3.11.2.2. Відкритий ключ ГОСТ34.310-95.
Для зображення відкритого ключазгідно з ГОСТ 34.310-95 використовується формат (інкапсульовано у поле“subjectPublicKey”):
PublicKey:: = INTEGER
3.11.2.3. ЕЦП за ГОСТ34.310-95.
ЕЦП згідно з ГОСТ 34.310-95 маєвигляд (інкапсульовано у поле “signatureValue”):
| Gost34310Signature ::= SEQUENCE { | ||
|
| r | INTEGER, |
|
| s | INTEGER}, |
де r та s обчислюються згідно зГОСТ 34.310-95.
3.12. ДКЕ - таблиці заповненнявузлів заміни блоків підстановки для алгоритму ДСТУ ГОСТ 28147:2009 “Системыобработки информации. Защита криптографическая. Алгоритмы криптографическогопреобразования”, затвердженого
Кодування ДКЕ виконується як:
dke OCTET STRING
ДКЕ може кодуватися врозгорнутому або упакованому форматі залежно від алгоритму:
для ДСТУ 4145-2002 - упакованийформат;
для ГОСТ 34.310-95 -розгорнутий формат.
У разі відсутності ДКЕ впараметрах криптоалгоритму використовується ДКЕ № 1, що наведено у додатку 1 доІнструкції № 114 ( z0729-07 )
Упакований формат ДКЕ (масив 64байт).
Формат розташування елементівДКЕ - масив фіксованої довжини розміром 64 байт.
ДКЕ - це матриця, що маєстовпці К1…К8 (р1…р
К1.0, К1.1 … К1.15, К2.0, К2.1… К2.15, …… К8.0, К8.1 … К8.15
Для блоку підстановки ДКЕ № 1,що наведений у додатку 1 до Інструкції№ 114 ( z0729-07 ), маєвигляд:
ДКЕ в упакованому форматі(масив 64 байт) має вигляд:
jpg
3.12.2. Розгорнутий формат ДКЕ(масив 128 байт).
Формат розташування елементівДКЕ - масив фіксованої довжини в 128 байт. ДКЕ - це матриця стовпців К1…К8 (р
К1.0, К1.1 … К1.15, К2.0, К2.1… К2.15, …… К8.0, К8.1 … К8.15
Приклад кодування ДКЕ №1, щонаведено в додатку 1 до Інструкції№ 114 ( z0729-07 ), врозгорнутому форматі (масив 128 байт) для блоку підстановки:
jpg
3.13. Стартовий вектор дляобчислення значення геш-функції ГОСТ 34.311-95.
Для обчислення значеннягеш-функції використовується алгоритм згідно із стандартом ГОСТ 34.311-95. Приобчисленні електронного цифрового підпису значення стартового вектора H функціїгешування за ГОСТ 34.311-95 встановлюється рівним 256-ти нульовим бітам.
3.14. Порядок кодування окремихпараметрів криптографічних алгоритмів.
При кодуванні реквізитівкриптографічних алгоритмів ДСТУ 4145-2002 та ГОСТ 34.310-95 застосовуються такіправила:
3.14.1. Значення типу“INTEGER”.
Всі значення типу “INTEGER” дляалгоритмів ДСТУ 4145-2002 та ГОСТ 34.310-95 кодуються як цілі числа >=0.
Наприклад, значення для типу“INTEGER” кодуються такою послідовністю байтів:
а) позитивне число 18А3hкодується в DER як послідовність байтів 02 02 18 А3;
б) позитивне число FA10hкодується як послідовність байтів 02 03 00 FA 10 (додається 00 як додатковийстарший байт, оскільки старший біт старшого байта FAh дорівнює 1);
в) число 0 кодується в DER якпослідовність байтів 02 01 00.
3.14.2. Кодування двійковихрядків в складі ASN.1-типу OCTET STRING у форматі Little-Endian.
Математичне кодування двійковихрядків (бітових послідовностей) виконується за схемою - молодший байт (щомістить менші за номерами біти) за молодшою адресою (ближче до початку потоку).
Біти в байті нумеруються від 0до 7 за вагою розряду: біт i має вагу 2
Наприклад: біт 0 має вагу 1(01h), біт 1 має вагу 2 (02h), біт 7 має вагу 128 (80h).
Біт n двійкового рядкакодується як біт i байта j, де i та j обчислюються за формулами:
|
| i = n mod 8, | |
|
| j = n div 8, | |
|
| де: | |
|
| x mod y | - операція обчислення залишку від ділення x на y, |
|
| x div y | - операція ділення x на y із заокругленням до найближчого цілого в меншу сторону. |
Якщо кількість бітів удвійковому рядку не кратна 8, біти останнього байта, які не використовуються,мають містити нульове значення.
Наприклад:
бітовий рядок 11100011кодується як байт E3h;
бітовий рядок 1111000110111кодується як послідовність байт 37h 1Eh.
ІV.Розширення сертифіката (extensions)
4.1. Формат розширеньсертифіката має такий вигляд:
| Extensions ::= SEQUENCE SIZE (1…MAX) of Extension | ||
| Extension ::= SEQUENCE { | ||
|
| extnID | OBJECT IDENTIFIER, |
|
| critical | BOOLEAN DEFAULT FALSE, |
|
| extnvalue | OCTET STRING} |
Базовий об’єктний ідентифікаторрозширень сертифіката має такий вигляд:
id-ce OBJECT IDENTIFIER::= {joint-iso-ccitt(2) ds (5) 29}
Сертифікат може міститибудь-які додаткові розширення, які не визначені в цьому документі, за умови, щовони визначені як некритичні. Об’єктні ідентифікатори таких розширень повиннібути зареєстровані у встановленому порядку.
4.2. Розширення сертифікатанаведені у таблиці 4.
Таблиця 4
4.3. Розширення “Ідентифікаторвідкритого ключа Центру” (“authorityKeyIdentifier”) використовується дляідентифікації відкритого ключа, що відповідає особистому ключу, яким підписаносертифікат або список відкликаних сертифікатів.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
Атрибут “KeyIdentifier” повиненобов’язково бути присутнім.
Поле “authorityKeyIdentifier”не повинно визначатися як критичне.
4.4. Розширення “Ідентифікаторвідкритого ключа підписувача” (“subjectKeyIdentifier”) використовується дляідентифікації відкритого ключа, що відповідає особистому ключу, за допомогоюякого підписувач здійснює накладання електронного цифрового підпису.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
| id-ce-subjectIdentifier OBJECT IDENTIFIER :: = (id-ce 14) |
| SubjectKeyIdentifier ::= KeyIdentifier |
Поле “Ідентифікатор відкритогоключа підписувача” (“subjectKeyIdentifier”) не повинно визначатися як критичне.
4.5. Обчислення “keyIdentifier”для алгоритмів ДСТУ 4145-2002 та ГОСТ 34.310-95.
Значення “keyIdentifier” врозширеннях “subjectKeyIdentifier” та “authorityKeyIdentifier” обчислюютьсявідповідно засобами ЕЦП підписувача та Центром під час генерації та обробкизапиту на формування сертифіката таким чином.
Із кодованого як BIT STRINGзображення відкритого ключа вилучаються байт, що містить ознаку типу даних,байти, що містять довжину блоку даних, та байт, що містить число невикористанихбітів.
Обчислюється значеннягеш-функції за ГОСТ 34.311-95 від отриманої на попередньому етапі послідовностібайтів. Як стартовий вектор геш-функції використовується нульовий вектор.
Якщо параметри криптоалгоритмуу полі “Інформація про відкритий ключ підписувача” (“subjectPublicKeyInfo”)містять таблицю заповнення вузлів заміни блоку підстановки (ДКЕ), то приобчисленні геш-функції використовується саме цей ДКЕ, інакше використовуєтьсяДКЕ № 1, що наведений у додатку 1 до
4.6. Розширення “Призначеннявідкритого ключа” (“keyUsage”) визначає призначення відкритого ключа, щоміститься в сертифікаті та повинно визначатися як критичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
Для сертифіката, що формуєтьсяпідписувачу, повинні бути встановлені біти “digitalSignature” (0) та“nonRepudiation” (1).
Для сертифіката Центру повиннібути встановлені біти “keyCertSign” (5) та “crlSign” (6).
4.7. Розширення “Уточненепризначення відкритого ключа” (“extendedKeyUsage”) може бути визначено яккритичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
id-ce-extKeyUsage OBJECTIDENTIFIER::= {id-ce 37}
ExtKeyUsageSyntax ::= SEQUENCESIZE (1.. MAX) OF KeyPurposeId
KeyPurposeId ::= OBJECTIDENTIFIER
id-kp OBJECT IDENTIFIER ::={iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5)pkix(7) 3}
Для сертифіката Центру, щовикористовується для перевірки підпису OCSP-відповідей та позначок часу,повинні бути зазначені об’єктні ідентифікатори {id-kp 8} або {id-kp 9}.
Для сертифіката підписувача,якщо ЕЦП застосовується як електронна печатка, розширення “Уточнене призначеннявідкритого ключа” (“extendedKeyUsage”) повинно містити об’єктний ідентифікатор1.2.804.2.1.1.1.3.9.
Для сертифікатів підписувача,які використовуються для перевірки ЕЦП у визначенихінформаційно-телекомунікаційних системах, в розширенні “Уточнене призначеннявідкритого ключа” (“extendedKeyUsage”) можуть використовуватись відповідніоб’єктні ідентифікатори за умови, що ці об’єктні ідентифікатори зареєстровані увстановленому порядку.
4.8. Розширення “Політикасертифікації” (“certificatePolicies”) містить посилання на політикусертифікації, відповідно до якої Центр сформував сертифікат. Розширення повинновизначатися як критичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
4.9. Розширення “Додаткові даніпідписувача” (“subjectAlternativeName”) використовується для розширення межіідентифікації підписувача (адреса електронної пошти, DNS, IP-адреса, URL).
Об’єктний ідентифікатор даногорозширення має такий вигляд:
4.10. Розширення “Додатковідані Центру” (“issuerAlternativeName”) дозволяє розширити межі ідентифікаціїЦентру (адреса електронної пошти, DNS, IP-адреса, URL). Розширення повинно бутивизначено як некритичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
id-ce-issuerAltName OBJECTIDENTIFIER::= {id-ce 18}
IssuerAltName::= GeneralNames
4.11. Розширення “Основніобмеження” (“basicConstraints”) дозволяє визначити, що сертифікат сформованийдля Центру або підписувача. Розширення повинно визначатися як критичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
Поле “pathLenConstraint”використовується, якщо поле сA встановлено в TRUE. У цьому разі воно визначаємаксимально допустиму кількість проміжних сертифікатів, що знаходяться між цимсертифікатом та сертифікатом підписувача.
У сертифікаті акредитованогоцентру сертифікації ключів розширення “pathLenConstraint” повинно мати значення“0”.
У сертифікаті засвідчувальногоцентру розширення “pathLenConstraint” повинно мати значення “1”.
У сертифікаті центральногозасвідчувального органу розширення “pathLenConstraint” повинно мати значення“2”.
4.12. Розширення “Персональнідані підписувача” (“subjectDirectoryAttributes”) може містити додатковіперсональні дані підписувача та повинно бути визначено як некритичне. Поле неповинно використовуватись для зберігання даних про підписувача, що визначені вполі “subject”.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
Кодування національних реквізитіву розширенні “Персональні дані підписувача” (“subjectDirectoryAttributes”)виконуються за такими правилами:
1) реквізит коду за ЄДРПОУюридичної особи (код за ДРФО фізичної особи - суб’єкта підприємницькоїдіяльності) використовується для сертифікатів електронних печаток юридичнихосіб та для сертифікатів ключів посадових осіб. Для сертифікатів посадових осібв цьому реквізиті вказується код юридичної особи (суб’єкта підприємницькоїдіяльності), представником якого (в межах своїх повноважень) є посадова особа.Для кодування цього реквізиту використовується об’єктний ідентифікатор1.2.804.2.1.1.1.11.1.4.2.1. Формат реквізиту - “PrintableString”, що містить 8,9 або 10 цифр;
2) реквізит коду за ДРФОфізичної особи - підписувача використовується для сертифікатів ключів,підписувачем у яких є фізичні особи (зокрема для сертифікатів ключів посадовихосіб). У цьому реквізиті вказується код за ДРФО підписувача. Для кодуванняцього реквізиту використовується об’єктний ідентифікатор1.2.804.2.1.1.1.11.1.4.1.1. Формат реквізиту - “PrintableString”, що містить 10цифр. Реквізит вказується за бажанням підписувача.
4.13. У розширенні “Точкидоступу до списків відкликаних сертифікатів” (“CRL Distribution Points”)повинна зазначатися принаймні одна загальнодоступна точка розповсюдженнясписків відкликаних сертифікатів (CRL), яка визначається http (http://) абоldap (ldap://). Розширення не повинно визначатися як критичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
Дозволяється використання лишеатрибута “distributionPoint” і тільки у форматі URI, який вказує на відповіднийCRL.
4.14. Якщо Центр разом ізбазовим CRL формує і частковий CRL, то посилання на нього вказується урозширенні “Точка доступу до часткового списку відкликаних сертифікатів”(“Freshest CRL”). Розширення не повинно визначатися як критичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
id-ce-freshestCRL OBJECTIDENTIFIER ::= {id-ce 46}
FreshestCRL ::=CRLDistributionPoints
Формування цього розширенняздійснюється за правилами формування розширення “Точки доступу до списківвідкликаних сертифікатів” (“CRL Distribution Points”).
Це розширення не єобов’язковим. Якщо посилання на частковий CRL не вказується в сертифікаті, товоно обов’язково вказується у відповідному розширенні в структурі базового CRL.
Вимоги щодо формату CRLвизначені у Вимогах до форматусписку відкликаних сертифікатів ( z1400-12 )
4.15. Розширення “Ознакипосиленого сертифіката” (“qualified certificate statement”) повинно бутивизначено як критичне.
Об’єктний ідентифікатор даногорозширення має такий вигляд:
4.15.1. Ознака того, щосертифікат сформований як посилений:
ua-qcStatement-1 QC-STATEMENT::= {IDENTIFIED BY id_ua-diglow-qcs-QcCompliance}
id-ua-diglaw-qcs-QcComplianceOBJECT IDENTIFIER ::= {1.2.804.2.1.1.1.2.1}
Для зазначення того, щосертифікат є посиленим, використовується таке заповнення реквізитів сертифікатапідписувача:
обов’язково: в розширенні“Політика сертифікації” (“certificate policies”) вказується об’єктнийідентифікатор політики посиленої сертифікації 1.2.804.2.1.1.1.2.2, якийвизначає, що сертифікат сформовано як посилений згідно із
додатково: може бути присутнімрозширення “qualified certificate statement”, у якому за допомогою стандартногооб’єктного ідентифікатора 1.2.804.2.1.1.1.2.1 (“Qualified certificate statementid-ua-diglow-qcs-QcCompliance”) позначено відповідність
14.15.2. Ознака наявностіобмеження максимальної суми, на яку вчиняється правочин з використаннямелектронного цифрового підпису органу державної влади, органу місцевогосамоврядування, підприємства, установи та організації державної формивласності:
| Директор |
|
| Директор Департаменту |
|