УВАГА! ДОКУМЕНТ ВТРАЧАЄ ЧИННІСТЬ.
ДЕРЖАВНИЙ КОМІТЕТ УКРАЇНИ
З ПИТАНЬ НАУКИ, ІННОВАЦІЙ ТА ІНФОРМАТИЗАЦІЇ
АДМІНІСТРАЦІЯ ДЕРЖАВНОЇ СЛУЖБИ СПЕЦІАЛЬНОГО ЗВ'ЯЗКУ
ТА ЗАХИСТУ ІНФОРМАЦІЇ УКРАЇНИ
ЗАТВЕРДЖЕНО
Наказ Державного комітету
України з питань науки,
інновацій та інформатизації,
Адміністрації Державної
служби спеціального зв'язку
та захисту інформації
України
13.08.2010 N 8/229
( z1052-10 )
Зареєстровано в Міністерстві
юстиції України
9 листопада 2010 р.
за N 1054/18349
ТЕХНІЧНІ СПЕЦИФІКАЦІЇ
форматів представлення базових об'єктів національної системи електронного цифрового підпису (протокол визначення статусу сертифіката)
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-сервер) - спеціальна служба центру сертифікації ключів (далі - ЦСК), яка за запитами користувачів визначає статус сертифікатів та надсилає відповідь, де зазначається статус сертифіката, який перевіряється, на даний момент.
Інші терміни застосовуються у значеннях, наведених у Законі України "Про електронний цифровий підпис" (
852-15)
, Порядку акредитації центру сертифікації ключів, затвердженому постановою Кабінету Міністрів України від 13.07.2004 N 903 (
903-2004-п)
, Правилах посиленої сертифікації, затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 13.01.2005 N 3 (
z0104-05)
(у редакції наказу Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 10.05.2006 N 50 (
z0568-06)
) , зареєстрованих у Міністерстві юстиції України 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 (
z0729-07)
, зареєстрованої в Міністерстві юстиції України 25.06.2007 за N 729/13996 (далі - ДКЕ N 1).
ДКЕ N 1 (
z0729-07)
використовується як ДКЕ "за умовчанням".
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-кодування.
|
Заступник Голови Державного
комітету України з питань науки,
інновацій та інформатизації
Директор Департаменту
регулювання діяльності
у сфері криптографічного
захисту інформації
Адміністрації Державної служби
спеціального зв'язку
та захисту інформації України
|
С.О.Колобов
В.І.Бондаренко
|
Додаток 1
до Технічних специфікацій
форматів представлення
базових об'єктів
національної системи
електронного цифрового
підпису (протокол визначення
статусу сертифіката)
ФОРМАТИ ДАНИХ
у нотації 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
Додаток 2
до Технічних специфікацій
форматів представлення
базових об'єктів
національної системи
електронного цифрового
підпису (протокол визначення
статусу сертифіката)
ОПИС
числових значень поля "responseStatus"
------------------------------------------------------------------
| Константа |Числове | Опис |
| |значення| |
|----------------+--------+--------------------------------------|
|successful | 0 |Операція завершилась успішно |
|----------------+--------+--------------------------------------|
|malformedRequest| 1 |Пошкоджений або недозволений запит |
|----------------+--------+--------------------------------------|
|internalError | 2 |Внутрішня помилка |
|----------------+--------+--------------------------------------|
|tryLater | 3 |Сервер перенавантажений |
|----------------+--------+--------------------------------------|
|sigRequired | 5 |Сервер обробляє лише підписані запити |
|----------------+--------+--------------------------------------|
|unauthorized | 6 |Запит від неавторизованого користувача|
------------------------------------------------------------------
Додаток 3
до Технічних специфікацій
форматів представлення
базових об'єктів
національної системи
електронного цифрового
підпису (протокол визначення
статусу сертифіката)
ФОРМАТИ ПОВІДОМЛЕННЯ
------------------------------------------------------------------
| Назва блоку |Розмір | Примітки |
| |(байт) | |
|----------------------------+-------+---------------------------|
|Розмір основного блоку | 4 |У форматі "Little-Endinan" |
|(запиту чи відповіді) | | |
|----------------------------+-------+---------------------------|
|Основний блок |Змінний|DER-кодування блоку (запиту|
| | |чи відповіді) |
------------------------------------------------------------------