ВИМОГИ
до протоколу визначення статусу сертифіката

{Із змінами, внесеними згідно з Наказом Міністерства юстиції
№ 1716/5/667 від 22.11.2012}

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

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

1.2. У цих Вимогах терміни вживаються у такому значенні:

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

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

Інші терміни застосовуються у значеннях, наведених у Законі України “Про електронний цифровий підпис”, Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13 липня 2004 року № 903, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 13 січня 2005 року № 3 (у редакції наказу Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 10 травня 2006 року № 50), зареєстрованих у Міністерстві юстиції України 27 січня 2005 року за № 104/10384, інших нормативно-правових актах з питань криптографічного та технічного захисту інформації.

1.3. Формати даних представлено у нотації ASN.1, визначеній у міжнародному стандарті ISO/IEC 8824 “Information technology - Open Systems Interconnection - Specification of Abstract Syntax Notation One (ASN.1)” / ДСТУ ISO/ІЕС 8824-3:2008 “Інформаційні технології. Нотація абстрактного синтаксису 1 (ASN.1)” - частина 3. Специфікація обмежень (ISO/IEC 8824-3:2002, IDT), затвердженому наказом Державного комітету України з питань технічного регулювання та споживчої політики від 26 грудня 2008 року № 508 (із змінами).

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

{Абзац другий пункту 1.3 розділу I із змінами, внесеними згідно з Наказом Міністерства юстиції № 1716/5/667 від 22.11.2012}

1.4. Усі структури даних кодують за правилами DER згідно з міжнародним стандартом ISO/IEC 8825-1:2002 “Information technology - ASN.1 Encoding Rules - Part 1: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)” (далі - ISO/IEC 8825-1:2002).

1.5. Ці Вимоги засновані на міжнародному стандарті RFC 2560 “Internet X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP”.

1.6. Ці Вимоги не дублюють стандарт ISO/IEC 8825-1:2002, а описують положення цього стандарту та формати полів. У разі виникнення розбіжностей між положеннями зазначеного стандарту та положеннями цих Вимог застосовуються положення цих Вимог.

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

1.8. Для визначення алгоритму гешування згідно з ГОСТ 34.311-95 “Информационная технология. Криптографическая защита информации. Функция хэширования”, затвердженим наказом Державного комітету України з питань технічного регулювання та споживчої політики від 21 жовтня 1997 року № 640 (далі - ГОСТ 34.311-95), поле “algorithm” повинно мати значення:

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

Поле “parameters” повинно бути відсутнє.

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

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

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

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

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

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-сервера призначений для перевірки ЕЦП на OCSP-відповіді;

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

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

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

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

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

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

Поле “requestorName” може містити ім’я користувача. Поле присутнє у випадку, якщо запит підписано, та відсутнє в іншому випадку.

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

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

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

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

Поле “algorithm” типу поля “hashAlgorithm” повинно мати значення, визначене у пункті 1.8 розділу І цих Вимог.

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

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

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

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

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

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

Поле “parameters” повинно бути відсутнє.

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

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

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

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

Опис числових значень поля “responseStatus” наведено в додатку 2 до цих Вимог.

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

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

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

Цими Вимогами визначається тип відповіді - “BasicOCSPResponse”.

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

id-pkix-ocsp 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 OBJECT IDENTIFIER ::= {id-pkix-ocsp 1}

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

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

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

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

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

OCSP-сервер може бути ідентифікований за ім’ям (“byName”) або гешем ключа (“byKey”), що містить геш-значення, яке обчислюється від відкритого ключа OCSP-сервера.

У разі використання імені у полі “ResponderID” (“byName”) вказується повне ім’я OCSP-сервера (поле “Subject” сертифіката OCSP-сервера).

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

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

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

Поле “certID” містить ідентифікаційні дані сертифіката, статус якого перевіряється. Значення цього поля повинно відповідати значенню поля “certID” відповідного запиту.

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

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

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

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

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

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

У разі відсутності підпису у запиті відповідь повинна формуватися з використанням алгоритму ДСТУ 4145-2002 “Інформаційна технологія. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих”, затвердженого наказом Державного комітету України з питань технічного регулювання та споживчої політики від 28 грудня 2002 року № 31 (далі - ДСТУ 4145-2002 (ПБ)), як алгоритму “за умовчанням”.

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

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

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

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

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

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

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

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”:

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

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

3.5. Сертифікат OCSP-сервера повинен містити розширення “Уточнене призначення відкритого ключа” (“extendedKeyUsage”), в якому повинен бути зазначений лише один об’єктний ідентифікатор id-kp-OCSPSigning(id-kp 9).

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

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

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

4.1. Для передачі запиту на формування статусу сертифіката та отримання відповіді повинен застосовуватися транспортний протокол НТТP. У разі використання інших транспортних протоколів формати повідомлень цими Вимогами не регламентуються.

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

4.2.1. Тип контента запиту формується таким чином:

Content-Type: application/ocsp-request

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

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

Content-Transfer-Encoding: binary

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

4.2.2. Тип контента відповіді формується таким чином:

Content-Type: application/ocsp-response

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

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

Content-Transfer-Encoding: binary

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

ФОРМАТИ
даних у нотації 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) }

ОПИС
числових значень поля “responseStatus”