Жилищный адвокат

Вимоги до формату підписаних даних, Міністерство юстиції УкраїниЗАТВЕРДЖЕНОЗАТВЕРДЖЕНО Наказ Міністерства юстиції України, Адміністрації Державної служби спеціального зв’язку та захисту інформації України 20.08.2012  № 1236/5/453

    Зареєстровано в Міністерстві юстиції України 20 серпня 2012 р. за № 1401/21713

    ВИМОГИ до формату підписаних даних

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

    1.1. Ці Вимоги визначають формат підписаних даних — відображення електронного цифрового підпису (далі — ЕЦП) у вигляді DER-кодованого блоку (далі — формат ЕЦП), який містить безпосередньо значення ЕЦП як результат криптографічного перетворення набору електронних даних, а також набір додаткових даних, необхідних для перевірки ЕЦП та визнання його дійсності.

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

    атрибути, що не підписуються, — додаткові дані, які включаються до DER-кодованого блоку логічного представлення ЕЦП;

    атрибути, що підписуються, — додаткові дані, які включаються до DER-кодованого блоку логічного представлення ЕЦП, стосовно якого разом з набором електронних даних, які підписуються, обчислюється ЕЦП за методикою, визначеною в цих Вимогах;

  1. верифікатор — особа, що перевіряє ЕЦП за допомогою надійного засобу ЕЦП;
  2. значення цифрового підпису — DER-кодований блок, що містить результат криптографічного перетворення набору електронних даних, які підписуються;

    набір додаткових даних (дані перевірки) — дані, необхідні для визнання дійсності (достовірності) ЕЦП, тобто кодовані за встановленими правилами поля даних ЕЦП, що призначені для встановлення дійсності ЕЦП, у тому числі в довгостроковому періоді.

    Інші терміни застосовуються у значеннях, наведених у Законі України "Про електронний цифровий підпис"( 852-15 ), Порядку акредитації центру сертифікації ключів( 903-2004-п ), затвердженому постановою Кабінету Міністрів України від 13 липня 2004 року № 903, Правилах посиленої сертифікації( z0104-05 ), затверджених наказом Департаменту спеціальних телекомунікаційних систем та захисту інформації Служби безпеки України від 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 (із змінами).

    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)" та AMD1:2004 "Support for EX-TENDED-XER".

    1.5. Ці Вимоги засновані на стандартах RFC 5652 "Cryptographic Message Syntax (CMS) — September 2009", RFC 3126 "Electronic Signature Formats for long term electronic signatures" та ДСТУ ETSI TS 101 733:2009 "Електронні підписи та інфраструктури (ESI). Розширені електронні CMS-підписи (CAdES) (ETSI TS 101 733:2008, IDT)" (далі — ДСТУ ETSI TS 101 733:2009), затвердженому наказом Державного комітету України з питань технічного регулювання та споживчої політики від 15 грудня 2009 року № 452( v0452609-09 ).

    1.6. Ці Вимоги не дублюють стандарти ДСТУ ETSI TS 101 733:2009, RFC 5652 та RFC 3126, а описують положення цих стандартів та формати полів. У разі виникнення розбіжностей між положеннями зазначених стандартів та положеннями цих Вимог застосовуються положення цих Вимог.

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

    Тип формату ЕЦП обирається залежно від порядку зберігання підписаних даних. Структуру даних формату ЕЦП наведено в додатку до цих Вимог.

    1.8. ЕЦП обчислюється за криптографічними алгоритмами, визначеними у ДСТУ 4145-2002 "Інформаційна технологія. Криптографічний захист інформації. Електронний цифровий підпис, що ґрунтується на еліптичних кривих", затвердженому наказом Державного комітету України з питань технічного регулювання та споживчої політики від 28 грудня 2002 року № 31 (далі — ДСТУ 4145-2002). Геш-функція обчислюється за ГОСТ 34.311-95 "Информационная технология. Криптографическая защита информации. Функция хэширования", затвердженим наказом Державного комітету України з питань технічного регулювання та споживчої політики від 21 жовтня 1997 року № 640 (далі — ГОСТ 34.311-95).

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

    1.10. Для визначення алгоритму гешування згідно з ГОСТ 34.311-95 поле "algorithm" типу "AlgorithmIdentifier" повинно мати значення:

    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 до Інструкції( z0729-07 ) про порядок постачання і використання ключів до засобів криптографічного захисту інформації( z0729-07 ), затвердженої наказом Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 12 червня 2007 року № 114, зареєстрованої в Міністерстві юстиції України 25 червня 2007 року за № 729/13996 (із змінами) (далі — ДКЕ № 1).

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

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

    II. Типи форматів ЕЦП

    2.1. Цими Вимогами визначаються такі типи форматів ЕЦП:

    "Базовий ЕЦП" (CAdES Basic Electronic Signature — CAdES-BES відповідно до ДСТУ ETSI TS 101 733:2009);

    "Базовий ЕЦП із визначеною політикою підпису" (Explicit Policy-based Electronic Signature — CAdES-EPES відповідно до ДСТУ ETSI TS 101 733:2009);

    "ЕЦП з посиланням на повний набір даних перевірки" (ES with Complete validation data references (CAdES-C) відповідно до ДСТУ ETSI TS 101 733:2009);

    "ЕЦП з повним набором даних перевірки" (CAdES-X Long відповідно до ДСТУ ETSI TS 101 733:2009).

    2.2. Типи форматів ЕЦП наведено в порядку збільшення кількості додаткових даних.

    2.3. Формат "Базовий ЕЦП":

    2.3.1. Формат "Базовий ЕЦП" використовується для автентифікації підписувача та перевірки цілісності електронного документа в період чинності сертифіката (сертифікатів) відкритого ключа (далі — сертифікат). Формат "Базовий ЕЦП" може бути створений без доступу до on-line послуг акредитованого центру сертифікації ключів (далі — Центр). Формат "Базовий ЕЦП" не надає можливості встановити дійсність підпису у випадку, якщо ЕЦП перевіряється після закінчення строку чинності сертифіката або скасування сертифіката після формування ЕЦП.

    2.3.2. Формат "Базовий ЕЦП" містить:

  3. набір обов’язкових атрибутів, що підписуються;
  4. цифровий підпис, обчислений за електронними даними та набором атрибутів, що підписуються;
  5. електронні дані, стосовно яких здійснюється обчислення цифрового підпису (необов’язково).
  6. Додатково формат "Базовий ЕЦП" може включати:

  7. набір необов’язкових атрибутів, що підписуються;
  8. набір необов’язкових атрибутів, що не підписуються, відповідно до CMS (RFC 5652).
  9. 2.3.3. Перелік обов’язкових атрибутів, що підписуються:

    "Сontent-Type" — атрибут, що визначає тип структури "EncapsulatedContentInfo", за значенням якої обчислюється підпис;

    "Message-digest" — атрибут, що містить геш-значення структури "eContent OCTET STRING" в "encapContentInfo", за значенням якої обчислюється цифровий підпис;

    "ESS signing-certificate v2" — атрибут, що містить посилання на сертифікат підписувача.

    2.3.4. Перелік необов’язкових атрибутів, що підписуються:

    "Signing-time" — атрибут, що містить час обчислення цифрового підпису, який заявляється підписувачем;

    "content-time-stamp" — атрибут, що містить позначку часу відносно даних, що підписуються. Зазначений атрибут дозволяє забезпечити доказ того, що дані, стосовно яких обчислюється підпис, існували до моменту формування підпису;

    "signature-policy-identifier" — атрибут, що вказує на політику підпису, дотримання якої є обов’язковим під час формування та перевірки ЕЦП.

    2.4. Формат "Базовий ЕЦП із визначеною політикою підпису" (CAdES-EPES) включає всі дані формату "Базовий ЕЦП" та додатково містить обов’язковий атрибут "signature-policy-identifier", що вказує на політику підпису, дотримання якої є обов’язковим під час формування та перевірки ЕЦП.

    2.5. Формати "ЕЦП з посиланням на повний набір даних перевірки" (CAdES-C) та "ЕЦП з повним набором даних перевірки" (CAdES-X Long) забезпечують можливість встановлення дійсності ЕЦП у довгостроковому періоді (після закінчення строку чинності сертифіката).

    Ці формати додатково містять дані, що забезпечують встановлення дійсності підпису у довгостроковому періоді:

  10. позначку часу відносно цифрового підпису;
  11. сертифікати або посилання на сертифікати;
  12. інформацію про статус для кожного сертифіката або посилання на таку інформацію.

    Зазначені дані включаються до формату підписувачем або верифікатором та визначаються атрибутами, що не підписуються. Такі атрибути додаються до формату "Базовий ЕЦП" або "Базовий ЕЦП із визначеною політикою підпису". Використання позначки часу забезпечує доказ того, що цифровий підпис був обчислений до певного часу, та дозволяє встановити дійсність сертифіката на момент обчислення цифрового підпису. Інформація про статус сертифікатів може бути представлена у формі списків відкликаних сертифікатів або відповідей на інтерактивну перевірку статусу сертифіката згідно з Вимогами до протоколу визначення статусу сертифіката, затвердженими наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 20 серпня 2012 року № 1236/5/453, зареєстрованими у Міністерстві юстиції України 20 серпня 2012 року за № 1403/21715 (далі — Вимоги до протоколу визначення статусу сертифіката).

    2.5.1. Формат "ЕЦП з посиланням на повний набір даних перевірки" формується шляхом додавання до формату "Базовий ЕЦП" таких атрибутів, що не підписуються:

    "signature-time-stamp" — атрибут, що містить позначку часу відносно цифрового підпису;

    "complete-certificate-references" — атрибут, що містить ідентифікаційні дані всіх сертифікатів, які використовуються для перевірки підпису, крім сертифіката підписувача;

    "complete-revocation-references" — атрибут, що містить ідентифікаційні дані списків відкликаних сертифікатів або відповідей за протоколом OCSP щодо сертифікатів, які використовуються для перевірки підпису, крім сертифіката підписувача.

    Дата та час, які вказані у позначці часу, не повинні перевищувати строку чинності сертифіката (сертифікатів) або дату та час його скасування.

    У випадку, коли необхідні дані перевірки, які забезпечують встановлення дійсності підпису у довгостроковому періоді, доступні верифікатору, він може сформувати формат "ЕЦП з посиланням на повний набір даних перевірки" на основі отриманого від підписувача ЕЦП у форматі "Базовий ЕЦП" з дотриманням періоду відстрочки з моменту авторизації підписувача, що звертається до Центру з метою скасування сертифіката, до часу, коли оновлена інформація про статус сертифіката стає доступною для використання.

    Якщо підписувач ініціює процедуру скасування сертифіката, інформація про статус сертифіката протягом періоду відстрочки може не відповідати інформації, що доступна для верифікатора.

    2.5.2. Формат "Розширений довгостроковий підпис" формується шляхом додавання до формату "Базовий ЕЦП" таких атрибутів, що не підписуються:

    "certificate-values" — атрибут містить всі сертифікати, крім сертифіката підписувача, необхідні для перевірки підпису;

    "revocation-values" — атрибут містить списки відкликаних сертифікатів або відповіді за протоколом OCSP щодо сертифікатів, які використовуються для перевірки підпису (крім сертифіката підписувача).

    III. Процедура перевірки ЕЦП

    3.1. ЕЦП вважається таким, що пройшов перевірку, у випадку, якщо виконуються всі наведені умови:

  13. формат ЕЦП відповідає положенням цих Вимог;
  14. за результатами перевірки цифрового підпису встановлено, що цифровий підпис вірний;
  15. ЕЦП підтверджено з використанням сертифіката (сертифікатів), чинного (чинних) на момент накладення ЕЦП;

  16. тип даних, на які поставлено підпис, відповідає зазначеному в атрибуті "content-type";
  17. геш-значення даних (інкапсульованих або зовнішніх) відповідає значенню, наведеному в атрибуті "message-digest".

    Якщо під час перевірки у верифікатора відсутні необхідні дані перевірки, зокрема сертифікати, інформація про їх статус, або якщо період відстрочки не закінчився, він повинен утриматися від перевірки ЕЦП до отримання цих даних або закінчення періоду відстрочки.

    3.2. ЕЦП вважається таким, що не пройшов перевірку, у випадку, якщо є хоча б одна з наведених умов:

  18. формат ЕЦП не відповідає положенням цих Вимог;
  19. за результатами перевірки цифрового підпису встановлено, що цифровий підпис невірний;
  20. ЕЦП підтверджено з використанням сертифіката (сертифікатів), що на момент накладання ЕЦП не був чинним (був скасованим, блокованим або строк чинності його закінчився);

  21. тип даних, на які поставлено підпис, не відповідає зазначеному в атрибуті "content-type";
  22. геш-значення даних (інкапсульованих або зовнішніх) не відповідає значенню, наведеному в атрибуті "message-digest".

    3.3. Якщо під час перевірки верифікатор не може встановити, чи пройшов ЕЦП перевірку, чи ні, то підпис вважається таким, що не пройшов перевірку на даний момент часу.

    3.4. Перевірка декількох підписів здійснюється у випадку, коли підписаний документ містить декілька підписів, кожен підпис перевіряється окремо. Підписаний кількома ЕЦП електронний документ (електронні дані) вважається дійсним виключно у випадку, коли всі ЕЦП пройшли перевірку.

    IV. Атрибути, що включаються у формат ЕЦП

    4.1. Тип "ContentInfo".

    Тип "ContentInfo" використовується для інкапсульованих даних разом з ідентифікатором типу даних.

    ContentInfo ::= SEQUENCE {

    contentType

    ContentType,

    content

    [0]EXPLICIT ANY DEFINED BY contentType}

    ContentType ::= OBJECT IDENTIFIER

    4.1.1. Поле "contentType" містить об’єктний ідентифікатор, що ідентифікує тип даних, що містяться в полі "content". Цими Вимогами визначаються два типи даних: "дані" та "дані з ЕЦП".

    Тип даних "дані" має об’єктний ідентифікатор:

    id-data OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

    Тип даних "дані з ЕЦП" має об’єктний ідентифікатор:

    id-signedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

    4.1.2. Поле "content" містить дані, тип яких вказано в полі "contentType".

    Якщо поле "contentType" типу "ContentInfo" містить об’єктний ідентифікатор "id-signedData", то поле "content" цього типу містить тип "SignedData", що визначає "дані з ЕЦП". Ця структура відповідає формату "Базовий ЕЦП".

    4.2. Тип "SignedData":

    SignedData ::= SEQUENCE {

    version

    CMSVersion,

    digestAlgorithms

    DigestAlgorithmIdentifiers,

    encapContentInfo

    EncapsulatedContentInfo,

    certificates

    [0]IMPLICIT CertificateSet OPTIONAL,

    crls

    [1]IMPLICIT RevocationInfoChoices OPTIONAL

    signerInfos

    SignerInfos}

    4.2.1. Поле "version" містить версію формату підписаних даних. Якщо значення поля "eContentType" в полі "encapContentInfo" дорівнює "id-data", то значення поля "version" дорівнює "1". Якщо значення поля "eContentType" в полі "encapContentInfo" відрізняється від "id-data", то значення поля "version" дорівнює "3".

    4.2.2. Поле "digestAlgorithms" містить алгоритми гешування, що були використані під час формування ЕЦП.

    DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

    DigestAlgorithmIdentifier ::= AlgorithmIdentifier

    Поле "digestAlgorithms" повинно містити лише один об’єктний ідентифікатор алгоритму гешування за ГОСТ 34.311-95.

    4.2.3. Поле "encapContentInfo" містить інкапсульовані дані, що були підписані.

    Тип "EncapsulatedContentInfo" використовується для зберігання даних, що підписані.

    EncapsulatedContentInfo ::= SEQUENCE {

    eContentType

    ContentType,

    eContent

    [0]EXPLICIT OCTET STRING OPTIONAL}

    Поле "eContentType" містить об’єктний ідентифікатор типу даних.

    Поле "eContent" є необов’язковим та може містити дані, що підписуються. Якщо це поле відсутнє, то вважається, що дані зберігаються окремо від логічного блоку ЕЦП (зовнішні дані).

    4.2.4. Поле "certificates" є необов’язковим та може містити перелік сертифікатів, необхідних для перевірки ЕЦП.

    CertificateSet ::= SET OF Certificate

    Для форматів CAdES-C та CAdES-X Long це поле повинно бути присутнє та містити сертифікат підписувача.

    4.2.5. Поле "crls" є необов’язковим та може містити набір списків відкликаних сертифікатів, необхідних для визначення статусу сертифіката.

    RevocationInfoChoices ::= SET OF CertificateList

    Для формату CAdES-X Long це поле повинно бути відсутнім; усю необхідну інформацію для визначення статусу треба розміщувати в атрибуті "revocation-values".

    4.2.6. Поле "signerInfos" містить інформацію про осіб, що підписали дані.

    SignerInfos ::= SET OF SignerInfo

    4.3. Тип "SignerInfo" використовується для зберігання даних про підписувача та додаткових даних:

    SignerInfo ::= SEQUENCE {

    version

    CMSVersion,

    sid

    SignerIdentifier,

    digestAlgorithm

    DigestAlgorithmIdentifier,

    signedAttrs

    [0]IMPLICIT SignedAttributes OPTIONAL,

    signatureAlgorithm

    SignatureAlgorithmIdentifier,

    signature

    OCTET STRING,

    unsignedAttrs

    [1]IMPLICIT UnsignedAttributes OPTIONAL}

    4.3.1. Поле "version" містить версію формату типу "SignerInfo". Це поле повинно мати значення "1".

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

    SignerIdentifier ::= CHOICE {

    issuerAndSerialNumber

    IssuerAndSerialNumber,

    subjectKeyIdentifier

    [0]SubjectKeyIdentifier }

    "SignerIdentifier" надає два варіанти щодо визначення відкритого ключа підписувача.

    "IssuerAndSerialNumber" визначає сертифікат підписувача за розпізнавальним ім’ям Центру ("distinguished name"), що сформував сертифікат, та серійним номером сертифіката ("CertificateSerialNumber").

    "SubjectKeyIdentifier" визначає сертифікат підписувача за ідентифікатором ключа.

    IssuerAndSerialNumber ::= SEQUENCE {

    issuer

    Name,

    serialNumber

    CertificateSerialNumber }

    "Name" кодується відповідно до Вимог до формату посиленого сертифіката відкритого ключа, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 20 серпня 2012 року № 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за № 1398/21710 (далі — Вимоги до формату посиленого сертифіката відкритого ключа).

    CertificateSerialNumber ::= INTEGER

    4.3.3. Поле "digestAlgorithm" містить дані алгоритму гешування. Цей алгоритм повинен бути включений до поля "digestAlgorithms" типу "SignedData".

    4.3.4. Поле "signedAttrs" містить підписані атрибути з додатковими даними.

    SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

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

    Поле "algorithm" поля "signatureAlgorithm" для алгоритму цифрового підпису ДСТУ-4145:2002 може мати такі значення:

  23. для поліноміального базису:
  24. Dstu4145PBAlgo OBJECT IDENTIFIER ::= {iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) pki(1) alg(1) sym(3) Dstu4145WithGost34311(1) pb(1)}

  25. для оптимального нормального базису:
  26. Dstu4145ONBAlgo OBJECT IDENTIFIER ::= { iso(1) member-body(2) Ukraine(804) root (2) security(1) cryptography(1) pki(1) alg(1) sym(3) Dstu4145WithGost34311(1) onb(2)}

    В обох випадках поле "parameters" поля "signatureAlgorithm" відсутнє.

    Поле "algorithm" поля "signatureAlgorithm" для алгоритму цифрового підпису за ГОСТ 34.310-95 з геш-функцією за ГОСТ 34.311-95 має таке значення:

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

    В цьому випадку поле "parameters" поля "signatureAlgorithm" відсутнє.

    4.3.6. Поле "signature" містить безпосередньо цифровий підпис.

    4.3.7. Поле "unsignedAttrs" містить непідписані атрибути з додатковими даними.

    UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

    Attribute ::= SEQUENCE {attrType OBJECT IDENTIFIER, attrValues SET OF AttributeValue }

    AttributeValue ::= ANY

    4.4. Атрибут "message-digest" містить геш-значення даних, що підписуються ("encapContentInfo eContent OCTET STRING" в "signed-data" — тип формату "криптографічне повідомлення"), або файлу, що підписується (тип формату "зовнішній підпис"). Порядок обчислення геш-значення здійснюється згідно з розділом V цих Вимог.

    Об’єктний ідентифікатор, що визначає атрибут "message-digest":

    id-messageDigest OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 4}

    Значення атрибута "message-digest" має тип "MessageDigest":

    MessageDigest ::= OCTET STRING

    Атрибут "message-digest" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

    4.5. Атрибут "content-type" визначає тип електронних даних ("Content Type"), що підписуються. Значення атрибута "content-type" повинно збігатися із значенням "eContentType" структури "encapContentInfo" в "signed-data".

    Об’єктний ідентифікатор, що визначає атрибут "content-type":

    id-contentType OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 3}

    Значення атрибута "content-type" має тип "ContentType"

    ContentType ::= OBJECT IDENTIFIER

    Атрибут "content-type" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

    4.6. Атрибут "ESS signing-certificate v2" надає інформацію, що ідентифікує сертифікат підписувача.

    Об’єктний ідентифікатор, що визначає атрибут "ESS signing-certificate v2":

  27. значення атрибута "ESS signing-certificate v2" має тип:
  28. SigningCertificateV2 ::= SEQUENCE {

    certs SEQUENCE OF ESSCertIDv2,

    policies SEQUENCE OF PolicyInformation OPTIONAL}

    Структура "certs" повинна містити посилання на сертифікат підписувача.

    ESSCertIDv2 ::= SEQUENCE {

    hashAlgorithm

    AlgorithmIdentifier

    certHash

    Hash,

    issuerSerial

    IssuerSerial}

    Hash ::= OCTET STRING

    IssuerSerial ::= SEQUENCE {

    issuer

    GeneralNames,

    serialNumber

    CertificateSerialNumber}

    Значення полів структури "issuerSerial" повинно відповідати значенням полів структури "issuerAndSerialNumber" в "SignerIdentifier" ("SignerInfo"). Поле "issuer" повинно містити ім’я типу "directoryName", значенням якого є поле "Subject" сертифіката Центру, формат якого визначено Вимогами до формату посиленого сертифіката відкритого ключа.

    Поле "hashAlgorithm" містить об'єктний ідентифікатор алгоритму, що використовується для обчислення геш-значення DER-кодованного сертифіката.

    Поле "certHash" містить геш-значення сертифіката підписувача.

    Формат поля "policies" цими Вимогами не визначається.

    4.7. Атрибут "signature-policy-identifier" визначає політики, що застосовувались підписувачем під час накладання ЕЦП. Цей атрибут визначається об’єктним ідентифікатором:

    id-aa-ets-sigPolicyId OBJECT IDENTIFIER ::= {iso(1)member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)smime(16) id-aa(2) 15}

    Значення атрибута "signature-policy-identifier" має тип "SignaturePolicyIdentifier"

    SignaturePolicyIdentifier ::=CHOICE {

    signaturePolicyId SignaturePolicyId }

    SignaturePolicyId ::= SEQUENCE {

    sigPolicyId

    SigPolicyId,

    sigPolicyHash

    SigPolicyHash OPTIONAL,

    sigPolicyQualifiers

    SEQUENCE SIZE (1..MAX) OF SigPolicyQualifierInfo OPTIONAL}

    Поле "SigPolicyId" містить об’єктний ідентифікатор, який унікально ідентифікує конкретну версію політики підпису. Синтаксис цього поля такий:

    SigPolicyId ::= OBJECT IDENTIFIER

    Поле "sigPolicyHash" є опціональним та містить ідентифікатор геш-алгоритму та геш-значення політики підпису.

    Якщо політика підпису визначена з використанням структури ASN.1, то геш-значення обчислюється із кодованого значення політики підпису (з вилученням байтів тегу та довжини) та алгоритм гешування повинен бути таким, як вказано в полі "sigPolicyHash".

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

    SigPolicyHash ::= OtherHashAlgAndValue

    OtherHashAlgAndValue ::= SEQUENCE {

    hashAlgorithm

    AlgorithmIdentifier,

    hashValue

    OtherHashValue }

    OtherHashValue ::= OCTET STRING

    Ідентифікатор політики підпису може бути пов’язаний з іншою інформацією щодо специфікатора. Семантика і синтаксис специфікатора пов’язані з об’єктним ідентифікатором у полі "sigPolicyQualifierId".

    Загальний синтаксис специфікатора такий:

    SigPolicyQualifierInfo ::= SEQUENCE {

    sigPolicyQualifierId

    SigPolicyQualifierId,

    sigQualifier

    ANY DEFINED BY sigPolicyQualifierId}

    У цих Вимогах визначаються такі специфікатори:

    "spuri": містить "web URI" або "URL" посилання на політику підпису;

    "sp-user-notice": містить повідомлення для користувача, що повинно відображатися кожного разу, коли перевіряється підпис.

    SigPolicyQualifierId ::= OBJECT IDENTIFIER

    id-spq-ets-uri OBJECT IDENTIFIER ::= { iso(1)member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9)smime(16) id-spq(5) 1}

    SPuri ::= IA5String

    id-spq-ets-unotice OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-spq(5) 2}

    SPUserNotice ::= SEQUENCE {

    noticeRef

    NoticeReference OPTIONAL,

    explicitText

    DisplayText OPTIONAL}

    NoticeReference ::= SEQUENCE {

    Organization

    DisplayText,

    noticeNumbers

    SEQUENCE OF INTEGER }

    DisplayText ::= CHOICE {

    visibleString

    VisibleString (SIZE (1..200)),

    bmpString

    BMPString (SIZE (1..200)),

    utf8String

    UTF8String (SIZE (1..200))}

    4.8. Атрибут "signing-time" містить час формування цифрового підпису, який заявляється підписувачем.

    Об’єктний ідентифікатор, що визначає атрибут "signing-time":

    id-signingTime OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) 5}

    Значення атрибута "signing-time" має тип "SigningTime"

    SigningTime ::= Time

    Time ::= CHOICE {

    utcTime

    UTCTime,

    generalizedTime

    GeneralizedTime}

    В ЕЦП, що формується до 31 грудня 2049 року включно, поле "SigningTime" кодується у форматі "UTCTime". В ЕЦП, що формуватиметься з 01 січня 2050 року, поле "SigningTime" кодується у форматі "GeneralizedTime".

    "UTCTime" значення повинно бути представлено у формі "YYMMDDHHMMSSZ". Наприклад, північ повинна бути представлена як "YYMMDD000000Z".

    Століття представляється не явно та повинно визначатися за такими правилами:

  29. якщо "YY" більше або дорівнює "50", рік повинен інтерпретуватися як "19YY";
  30. якщо "YY" менше "50", рік повинен інтерпретуватися як "20YY".
  31. Атрибут "signing-time" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

    4.9. Атрибут "content-time-stamp" містить позначку часу для даних, що підписуються. Позначка часу повинна існувати до початку формування блоку ЕЦП.

    Об’єктний ідентифікатор, що визначає атрибут "content-time-stamp":

    id-aa-ets-ContentTimeStamp OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) id-aa(2) 20}

    Значення атрибута "content-time-stamp" має тип "ContentTimeStamp".

    ContentTimeStamp ::= TimeStampToken

    Формат представлення структури "TimeStampToken" визначається згідно з підпунктом 4.2.2 пункту 4.2 розділу IV Вимог до протоколу фіксування часу, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 20 серпня 2012 року № 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за № 1402/21714 (далі — Вимоги до протоколу фіксування часу).

    Значення "messageImprint" структури "TimeStampToken" є геш-значенням даних, яке наведене в атрибуті "message-digest".

    Незважаючи на те, що синтаксисом "attrValues" передбачено як "SET OF AttributeValue", атрибут "content-time-stamp" повинен мати єдине значення. Нульове або множинне значення "AttributeValue" не допускається.

    4.10. Атрибут "signature-time-stamp" містить значення "TimeStampToken", яке обчислюється стосовно цифрового підпису.

    Об’єктний ідентифікатор, що визначає атрибут "signature-time-stamp":

    id-aa-signatureTimeStampToken OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14}

    Значення атрибута "signature-time-stamp" має тип "SignatureTimeStampToken".

    SignatureTimeStampToken ::= TimeStampToken

    У складі "unsignedAttributes" може бути довільна кількість атрибутів типу "signature-time-stamp" (наприклад, від різних Центрів, що надають послугу фіксування часу).

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

    Формат представлення структури "TimeStampToken" визначається згідно з підпунктом 4.2.2 пункту 4.2 розділу IV Вимог до протоколу фіксування часу.

    Значенням "messageImprint" структури "TimeStampToken" є геш-значення даних поля "signature" структури "SignerInfo" (з вилученням байтів тегу та довжини) цифрового підпису, до складу структури "unsignedAttributes" якого він входить.

    4.11. Атрибут "complete-certificate-references" містить посилання на всі сертифікати Центрів, що використовуються для перевірки підпису. Посилання на сертифікат підписувача у зазначений атрибут не включається. Посилання на сертифікат підписувача включається до атрибута "ESS signing-certificate v2".

    Об’єктний ідентифікатор визначає атрибут "complete-certificate-references":

    id-aa-ets-certificateRefs OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 21}

    Значення атрибута "complete-certificate-references" має тип "CompleteCertificateRefs".

    CompleteCertificateRefs ::= SEQUENCE OF OtherCertID

    OtherCertID ::= SEQUENCE {

    otherCertHash OtherHash,

    issuerSerial

    IssuerSerial OPTIONAL }

    OtherHash ::= CHOICE {

    otherHash OtherHashAlgAndValue}

    OtherHashValue ::= OCTET STRING

    OtherHashAlgAndValue ::= SEQUENCE {

    hashAlgorithm AlgorithmIdentifier,

    hashValue OtherHashValue }

    Значення типу OtherHashAlgAndValue обмежується використанням функції гешування згідно з ГОСТ 34.311-95.

    4.12. Атрибут "complete-revocation-references" містить посилання на всі списки відкликаних сертифікатів або відповіді за протоколом OCSP, які використовуються для перевірки сертифікатів Центрів.

    Об’єктний ідентифікатор, що визначає атрибут "complete-revocation-references":

    id-aa-ets-revocationRefs OBJECT IDENTIFIER ::= {iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 22}

    Значення атрибута "complete-certificate-references" має синтаксис "CompleteRevocationRefs":

    CompleteRevocationRefs ::= SEQUENCE OF CrlOcspRef

    CrlOcspRef ::= SEQUENCE {

    crlids

    [0]CRLListID OPTIONAL,

    ocspids

    [1]OcspListID OPTIONAL,

    otherRev

    [2]OtherRevRefs OPTIONAL

    }

    У структурі "CompleteRevocationRefs" перший атрибут "CrlOcspRef" повинен стосуватись сертифіката підписувача ("signing-certificate").

    Другий та наступні атрибути "CrlOcspRef" повинні бути розміщені у послідовності у тому самому порядку, що і "OtherCertID", з якими вони пов’язані. Для кожного сертифіката, окрім кореневого, "CrlOcspRef" має містити хоча б одне з полів "crlids" або "ocspids".

    CRLListID ::= SEQUENCE {

    crls SEQUENCE OF CrlValidatedID}

    CrlValidatedID ::= SEQUENCE {

    crlHash OtherHash,

    crlIdentifier CrlIdentifier OPTIONAL}

    CrlIdentifier ::= SEQUENCE {

    crlissuer Name,

    crlIssuedTime UTCTime,

    crlNumber INTEGER OPTIONAL

    }

    OcspListID ::= SEQUENCE {

    ocspResponses SEQUENCE OF OcspResponsesID}

    OcspResponsesID ::= SEQUENCE {

    ocspIdentifier OcspIdentifier,

    ocspRepHash OtherHash OPTIONAL

    }

    OcspIdentifier ::= SEQUENCE {

    ocspResponderID ResponderID,

    producedAt GeneralizedTime

    }

    OtherRevRefs ::= SEQUENCE {

    otherRevRefType OtherRevRefType,

    otherRevRefs ANY DEFINED BY otherRevRefType

    }

    OtherRevRefType ::= OBJECT IDENTIFIER

    До ідентифікаторів списку відкликаних сертифікатів (CRL) можуть включатися посилання як на власне CRL, так і на дельта-списки.

    Під час створення "crlValidatedID" значення атрибута "crlHash" обчислюється стосовно повного DER-кодованого списку відкликаних сертифікатів (CRL), включаючи його підпис.

    "crlIdentifier" призначений для ідентифікації списку відкликаних сертифікатів (CRL) за реквізитами Центру, що сформував цей CRL, а також за часом формування CRL, який повинен відповідати часу, зазначеному в атрибуті "thisUpdate" списку відкликаних сертифікатів, та за полем "crlNumber" у разі його наявності.

    "OcspIdentifier" призначений для ідентифікації OCSP-відповіді за реквізитами Центру, що сформував цю OCSP-відповідь, а також за часом формування OCSP-відповіді, який повинен відповідати часу, зазначеному в атрибуті "producedAt" OCSP-відповіді.

    Зазначений атрибут може містити посилання на CRL, OCSP-відповіді, що використовуються для перевірки сертифікатів для позначки часу. В цьому випадку атрибут, що не підписується, повинен включатися у поле "signedData" позначки часу як "unsignedAttrs" структури "signerInfos".

    4.13. Атрибут "certificate-values" містить значення сертифікатів, посилання на які містяться в атрибуті "complete-certificate-references".

    Об’єктний ідентифікатор, що визначає атрибут "certificate-values":

    id-aa-ets-certValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 23}

    Значення атрибута "certificate-values" має синтаксис "CertificateValues":

    CertificateValues ::= SEQUENCE OF Certificate

    Тип "Certificate" визначено у Вимогах до формату посиленого сертифіката відкритого ключа.

    4.14. Атрибут "revocation-values" містить значення CRL та OCSP-відповідей, посилання на які містяться в атрибуті "complete-revocation-references".

    Об’єктний ідентифікатор, що визначає атрибут "revocation-values":

    id-aa-ets-revocationValues OBJECT IDENTIFIER ::= { iso(1) member-body(2)us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 24}

    Значення атрибута "revocation-values" має синтаксис "RevocationValues":

    RevocationValues ::= SEQUENCE {

    crlVals

    [0] SEQUENCE OF CertificateList OPTIONAL,

    ocspVals

    [1] SEQUENCE OF BasicOCSPResponse OPTIONAL,

    otherRevVals

    [2] OtherRevVals OPTIONAL}

    OtherRevVals ::= SEQUENCE {

    otherRevValType

    OtherRevValType,

    otherRevVals

    ANY DEFINED BY OtherRevValType}

    OtherRevValType ::= OBJECT IDENTIFIER

    Тип "CertificateList" визначено у Вимогах до формату списку відкликаних сертифікатів, затверджених наказом Міністерства юстиції України, Адміністрації Державної служби спеціального зв’язку та захисту інформації України від 20 серпня 2012 року № 1236/5/453, зареєстрованих у Міністерстві юстиції України 20 серпня 2012 року за № 1400/21712.

    Тип "BasicOCSPResponse" визначено у Вимогах до протоколу визначення статусу сертифіката.

    Цими Вимогами не визначаються типи та формати інших джерел визначення статусу сертифікатів (поле "OtherRevVals").

    V. Порядок обчислення геш-значення

    5.1. Процедура обчислення геш-значення здійснюється за даними, що підписуються (значення "eContent" структури "encapContentInfo" в "signed-data" або зовнішній файл), або за даними, що підписуються разом із підписаними атрибутами ("signedAttrs") у разі їх наявності.

    5.2. Якщо підписані атрибути відсутні, то геш-значення обчислюється за даними, що підписуються, розміщеними у "eContent" структури "encapContentInfo" в "signed-data", або за зовнішнім файлом, для якого формується ЕЦП. При цьому у першому випадку вхідними даними для геш-алгоритму є тільки октети, що містять значення "eContent OCTET STRING". Октети DER-кодування тегу та довжини типу не використовуються. Отримане геш-значення використовується в алгоритмі формування ЕЦП.

    5.3. Якщо підписані атрибути наявні, то обчислення геш-значення здійснюється у такому порядку:

    5.3.1. Обчислюється геш-значення за даними, що підписуються, які розміщуються у "eContent" структури "encapContentInfo" в "signed-data", або за зовнішніми даними. При цьому у першому випадку вхідними даними для геш-алгоритму є тільки октети, що містять значення "eContent OCTET STRING". Октети DER-кодування тегу та довжини типу не використовуються.

    5.3.2. Здійснюється DER-кодування структури "signedAttrs", в яку в атрибут "message-digest" поміщається геш-значення, отримане на попередньому кроці.

    5.3.3. Обчислюється геш-значення DER-кодованої структури "signedAttrs", включаючи октети тегу та довжини. Отримане геш-значення є вхідним значенням для алгоритму обчислення ЕЦП.

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

    Директор Департаменту нотаріату, банкрутства та функціонування центрального засвідчувального органу Міністерства юстиції України

    К.І. Чижмарь

    Директор Департаменту криптографічного захисту інформації Адміністрації Державної служби спеціального зв’язку та захисту інформації України

    А.І. Пушкарьов

    Додаток до Вимог до формату підписаних даних

    СТРУКТУРА даних формату електронного цифрового підпису

    id-data OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1}

    id-signedData OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs7(7) 2 }

    ContentInfo ::= SEQUENCE {

    contentType

    ContentType,

    content

    [0] EXPLICIT ANY DEFINED BY contentType }

    ContentType ::= OBJECT IDENTIFIER

    SignedData ::= SEQUENCE {

    version

    CMSVersion,

    digestAlgorithms

    DigestAlgorithmIdentifiers,

    encapContentInfo

    EncapsulatedContentInfo,

    certificates

    [0] IMPLICIT CertificateSet OPTIONAL,

    signerInfos

    SignerInfos }

    CMSVersion ::= INTEGER {v0(0), v1(1), v2(2), v3(3), v4(4), v5(5)}

    DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

    DigestAlgorithmIdentifier ::= AlgorithmIdentifier

    EncapsulatedContentInfo ::= SEQUENCE {

    eContentType

    ContentType,

    eContent

    [0] EXPLICIT OCTET STRING OPTIONAL}

    CertificateSet ::= SET OF Certificate

    SignerInfos ::= SET OF SignerInfo

    SignerInfo ::= SEQUENCE {

    version

    CMSVersion,

    sid

    SignerIdentifier,

    digestAlgorithm

    DigestAlgorithmIdentifier,

    signedAttrs

    [0] IMPLICIT SignedAttributes OPTIONAL,

    signatureAlgorithm

    SignatureAlgorithmIdentifier,

    signature

    OCTET STRING,

    unsignedAttrs

    [1] IMPLICIT UnsignedAttributes OPTIONAL }

    SignerIdentifier ::= CHOICE

    {

    issuerAndSerialNumber

    IssuerAndSerialNumber}

    IssuerAndSerialNumber ::= SEQUENCE {

    issuer

    Name,

    serialNumber

    INTEGER}

    SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

    UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

    SignatureAlgorithmIdentifier ::= AlgorithmIdentifier

    Юридичний портал Справедливість

    Рейтинг: 4.8/5, основан на 25 голосах.


    Вам это будет интересно:

    Юрій Сьомін не збирається у відставку

    Головний тренер київського Динамо Юрій Сьомін прокоментував поразку від Шахтаря в 1/16 Кубка України.

    Ю.Тимошенко обязана явиться в суд по делу ЕЭСУ – прокурор Харьковской области

    Осужденная Юлия Тимошенко и подозреваемая по делу о незаконной деятельности корпорации ЕЭСУ, по мнению прокурора Харьковской области Геннадия Тюрина, может быть доставлена на заседание 12 апреля ...

    У Німеччині озброєний ножем чоловік увірвався до дитсадка

    У західнонімецькому Кельні невідомий чоловік у п'ятницю вчинив збройний напад на дитячий садок, взявши у заручники його керівника.

    Консультации по недвижимости
    Адвокат по ЖКХ
    Рекомендовано !
    Киевские судебные решения

    №910/22831/14

    Судья: Васильченко Т.В.
    07.01.2015

    №757/24024/14-ц

    Судья: Цокол Л. І.
    07.01.2015
    Новости жилищных адвокатов
    Упрощено таможенное оформление для товаров, которые ...

    Упрощено таможенное оформление для товаров, которые не содержат озоноразрушающих веществ Отныне для субъектов хозяйственной деятельности, импортирующих и экспортирующих товары, в которых отсутствуют озоноразрушающие вещества, их таможенное оформление осуществляется без лицензии. ...

    На Черкащині працівники ДАІ затримали автомобіль ...

    На Черкащині працівники ДАІ  затримали автомобіль з 170 літрами прозорої рідини невідомого походження Днями, близько восьмої години ранку, під час несення служби на стаціонарному посту Золотоноша, інспектори взводу із забезпечення супроводження відділу ДАІ з обслуговування міста Черкаси, зупинили ...

    На Київщині нетверезий водій збив пішоходів та ...

    На Київщині нетверезий водій збив пішоходів та зник з місця ДТП Днями, близько о 20-й годині, в місті Васильків, невстановлений водій, керуючи автомобілем МОСКВИЧ 412, допустив наїзд на 27-річну місцеву мешканку та з місця пригоди зник. Жінка переходила проїзну ...

    Об Адвокате
    Благодарим всех, от кого зависит работа этого портала.

    Большущее спасибо. Очень благодарны! Ребята - просто молодцы.

    Огромнейшее спасибо. С Вами приятно работать! Ребята - Вы действительно умнички.
    Публикации о недвижимости
    О налогообложении операции с недвижимостью ...

    О налогообложении операции с недвижимостью в Украине Сегодня, как и после принятия нового налога на недвижимость, эта тема широко обсуждается среди всех заинтересованных в этом ...

    Что лучше агент по недвижимости или адвокат

    Что лучше агент по недвижимости или адвокат Разграничение полномочий риелтора (агента), нотариуса и адвоката по вопросам недвижимости.

    fd88152c669729fa70f5fe095f45fa66