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

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

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

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

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

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

Поле "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 його сертифіката).

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

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

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

SingleResponse ::= SEQUENCE { 

certID  

CertID, 

certStatus  

CertStatus, 

thisUpdate  

GeneralizedTime, 

nextUpdate  

[0] EXPLICIT GeneralizedTime OPTIONAL, 

singleExtensions 

[1] EXPLICIT Extensions OPTIONAL} 

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

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

CertStatus ::= CHOICE { 

good  

[0] IMPLICIT NULL, 

revoked  

[1] IMPLICIT RevokedInfo, 

unknown 

[2] IMPLICIT UnknownInfo} 

RevokedInfo ::= SEQUENCE { 

revocationTime  

GeneralizedTime, 

revocationReason 

[0] EXPLICIT CRLReason OPTIONAL} 

UnknownInfo ::= NULL 

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

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

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

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

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

Формат алгоритму ЕЦП відповідає вимогам пункту 3.2 цього розділу.

У разі відсутності підпису у запиті відповідь повинна формуватися з використанням алгоритму ДСТУ 4145-2002 (ПБ) як алгоритму "за умовчанням".

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

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

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

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

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

Ідентифікатори розширень, що є специфічними для протоколу OSCP, визначаються через кореневий ідентифікатор "id-pkix-ocsp":

id-pkix-ocsp OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) ad(48) ocsp(1) }

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

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

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:

id-pkix-ocsp-crl  

OBJECT IDENTIFIER::= { id-pkix-ocsp 3 } 

CrlID ::= SEQUENCE { 

  

crlUrl [0] EXPLICIT IA5String OPTIONAL, 

  

crlNum 

[1] EXPLICIT INTEGER OPTIONAL, 

  

crlTime  

[2] EXPLICIT GeneralizedTime OPTIONAL } 

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

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

3.5. Сертифікат OCSP-сервера повинен містити розширення "ExtendedKeyUsage", в якому повинен бути зазначений такий об'єктний ідентифікатор, що визначає право підписувати OCSP-відповіді:

id-kp-OCSPSigning OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-kp(3) 9 }

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

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

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

4.1. Для передачі запитів на формування позначок часу та отримання відповідей повинен застосовуватися транспортний протокол HTTP та може застосовуватися транспортний протокол TCP-IP. У разі використання інших транспортних протоколів формати повідомлень не регламентуються.

4.2. Передача запитів на формування позначок часу та отримання відповідей із застосуванням транспортного протоколу TCP-IP відбуваються із встановленням TCP-з'єднання через IP-порт 340. Усі повідомлення мають формати, наведені в додатку 3.

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

4.3.1. Метод GET протоколу HTTP застосовується, якщо загальна довжина запиту не перевищує 255 байт.

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

GET {url}/{url-encoding of base-64 encoding of the DER encoding of the OCSPRequest}.

4.3.2. Якщо загальна довжина запиту перевищує 255 байт, то застосовується метод POST протоколу HTTP.

Для методу POST протоколу HTTP запит формується таким чином:

Content-Type: application/ocsp-request.

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

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

Content-Type: application/ocsp-response.

"Content-Length" вказує на довжину відповіді. Блоки даних передаються як байти їх 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) } 

OCSPRequest ::= SEQUENCE { 

tbsRequest 

TBSRequest, 

optionalSignature 

[0] EXPLICIT Signature OPTIONAL} 

Signature ::= SEQUENCE { 

signatureAlgorithm 

AlgorithmIdentifier, 

signature 

BIT STRING} 

TBSRequest ::= SEQUENCE { 

version 

[0] EXPLICIT Version DEFAULT v1, 

requestorName 

[1] EXPLICIT GeneralName OPTIONAL, 

requestList 

SEQUENCE OF Request, 

requestExtensions 

[2] EXPLICIT Extensions OPTIONAL} 

Request ::= SEQUENCE { 

reqCert 

CertID, 

singleRequestExtensions 

[0] EXPLICIT Extensions OPTIONAL} 

CertID ::= SEQUENCE { 

hashAlgorithm 

AlgorithmIdentifier, 

issuerNameHash 

OCTET STRING, 

issuerKeyHash 

OCTET STRING, 

serialNumber 

CertificateSerialNumber} 

OCSPResponse ::= SEQUENCE { 

responseStatus 

OCSPResponseStatus, 

responseBytes 

[0] EXPLICIT ResponseBytes OPTIONAL} 

OCSPResponseStatus ::= ENUMERATED { 

successful 

(0), 

malformedRequest 

(1), 

internalError 

(2), 

tryLater 

(3), 

sigRequired 

(5), 

unauthorized 

(6)} 

ResponseBytes ::= SEQUENCE { 

responseType 

OBJECT IDENTIFIER, 

response 

OCTET STRING} 

BasicOCSPResponse ::= SEQUENCE { 

tbsResponseData 

ResponseData, 

signatureAlgorithm 

AlgorithmIdentifier, 

signature 

BIT STRING, 

certs 

[0] EXPLICIT SEQUENCE OF Certificate OPTIONAL} 

ResponseData ::= SEQUENCE { 

version 

[0] EXPLICIT Version DEFAULT v1, 

responderID 

ResponderID, 

producedAt 

GeneralizedTime, 

responses 

SEQUENCE OF SingleResponse, 

responseExtensions 

[1] EXPLICIT Extensions OPTIONAL} 

ResponderID ::= CHOICE { 

byName 

[1] Name, 

byKeyHash 

[2] KeyHash } 

SingleResponse ::= SEQUENCE { 

certID 

CertID, 

certStatus 

CertStatus, 

thisUpdate 

GeneralizedTime, 

nextUpdate 

[0] EXPLICIT GeneralizedTime OPTIONAL, 

singleExtensions 

[1] EXPLICIT Extensions OPTIONAL} 

CertStatus ::= CHOICE { 

good 

[0] IMPLICIT NULL, 

revoked 

[1] IMPLICIT RevokedInfo, 

unknown 

[2] IMPLICIT UnknownInfo} 

RevokedInfo ::= SEQUENCE { 

revocationTime 

GeneralizedTime, 

revocationReason 

[0] EXPLICIT CRLReason OPTIONAL} 

UnknownInfo ::= NULL 

 

Опис числових значень поля "responseStatus"

Константа 

Числове значення 

Опис 

successful 

Операція завершилась успішно 

malformedRequest 

Пошкоджений або недозволений запит 

internalError 

Внутрішня помилка 

tryLater 

Сервер перенавантажений 

sigRequired 

Сервер обробляє лише підписані запити 

unauthorized 

Запит від неавторизованого користувача 

 

Формати повідомлення

Назва блоку 

Розмір (байт) 

Примітки 

Розмір основного блоку (запиту чи відповіді) 

У форматі "Little-Endinan" 

Основний блок 

Змінний 

DER-кодування блоку (запиту чи відповіді) 

____________

Опрос