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

ДЕРЖАВНИЙ КОМІТЕТ УКРАЇНИ

З ПИТАНЬ НАУКИ, ІННОВАЦІЙ ТА ІНФОРМАТИЗАЦІЇ

АДМІНІСТРАЦІЯ ДЕРЖАВНОЇ СЛУЖБИ СПЕЦІАЛЬНОГО ЗВ'ЯЗКУ

ТА ЗАХИСТУ ІНФОРМАЦІЇ УКРАЇНИ

ЗАТВЕРДЖЕНО

Наказ Державного комітету

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

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

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

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

та захисту інформації

України

13.08.2010 N 8/229

( z1052-10 )

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

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

9 листопада 2010 р.

за N 1054/18349

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Gost34311 OBJECT IDENTIFIER ::= {iso(1) member-body(2)

Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1)

pki-alg-hash (2) 1}

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

В операціях формування та перевіряння підпису при обчисленні значення геш-функції згідно з ГОСТ 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. Під час інтерактивного визначення статусу сертифіката користувач та OCSP-сервер виконують такі дії:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OCSPRequest ::= SEQUENCE {

tbsRequest TBSRequest,

optionalSignature [0] EXPLICIT Signature OPTIONAL}

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

TBSRequest ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

requestorName [1] EXPLICIT GeneralName OPTIONAL,

requestList SEQUENCE OF Request,

requestExtensions [2] EXPLICIT Extensions OPTIONAL}

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

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

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

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

Request ::= SEQUENCE {

reqCert CertID,

singleRequestExtensions [0] EXPLICIT Extensions OPTIONAL}

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

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

CertID ::= SEQUENCE {

hashAlgorithm AlgorithmIdentifier,

issuerNameHash OCTET STRING,

issuerKeyHash OCTET STRING,

serialNumber CertificateSerialNumber}

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

gost34311 OBJECT IDENTIFIER ::= {iso(1) member-body(2)

Ukraine(804) root(2) security(1) cryptography(1) pki(1) pki-alg(1)

pki-alg-hash (2) 1}

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

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

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

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

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

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

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

Signature ::= SEQUENCE {

signatureAlgorithm AlgorithmIdentifier,

signature BIT STRING,

certs[0] EXPLICIT SEQUENCE OF Certificate OPTIONAL}

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

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

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

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

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

OCSPResponse ::= SEQUENCE {

responseStatus OCSPResponseStatus,

responseBytes [0] EXPLICIT ResponseBytes OPTIONAL}

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

OCSPResponseStatus ::= ENUMERATED {

successful (0),

malformedRequest (1),

internalError (2),

tryLater (3),

sigRequired (5),

unauthorized (6)}

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

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

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

ResponseBytes ::= SEQUENCE {

responseType OBJECT IDENTIFIER,

response OCTET STRING}

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

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

id-pkix-ocsp-basic OBJECT IDENTIFIER::= ( id-pkix-ocsp 1 )

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

BasicOCSPResponse ::= SEQUENCE {

tbsResponseData ResponseData,

signatureAlgorithm AlgorithmIdentifier,

signature BIT STRING,

certs [0] EXPLICIT SEQUENCE OF Certificate

OPTIONAL}

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

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

ResponseData ::= SEQUENCE {

version [0] EXPLICIT Version DEFAULT v1,

responderID ResponderID,

producedAt GeneralizedTime,

responses SEQUENCE OF SingleResponse,

responseExtensions [1] EXPLICIT Extensions OPTIONAL}

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

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

ResponderID ::= CHOICE {

byName [1] Name,

byKey [2] KeyHash}

KeyHash::= OCTET STRING

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

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

................

Перейти до повного тексту