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.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) ua-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 допускається використання ДКЕ, що вказаний у параметрах ключа підпису.

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-відповіді;

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

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" містить дані про стан сертифіката: