Використання електронного цифрового підпису у електронному документообігу

Якщо формування запиту здійснюється користувачем самостійно, то на цьому етапі формування запиту закінчується. Користувачеві необхідно (не зводячи прапор відправлення запиту в ЗЦ) зробити Експорт запиту з бази запитів і на транспортному носії доставити в служби ЗЦ.

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

З цього моменту можна користуватися знову створеним сертифікатом. Використання PKCS#10 запиту не є безпечним (мається на увазі не безпека ключової інформації, а істинність введеної інформації про суб'єкта) для ON-LINE режиму - користувачі самостійно заповнюють інформаційну частину сертифіката без контролю Адміністратора взаємодії з користувачами. Порозумівається це тим, що сам PKCS#10 має ЕЦП на ключі який тільки що був локально створений і про нього "нічого не знають" служби ЗЦ, інформацію, що знаходиться усередині запиту і підписану на "раніше невідомому для ЗЦ" ключі неможливо змінити - порушиться цілісність запиту, тому те, що було введено при заповненні форм майстри запиту, є винятковою відповідальністю користувача (і формально може суперечити політиці безпеки PKI системи в цілому), що є потенційною погрозою для всієї PKI системи. Дата дії сертифіката, отриманого на такий запит, проставляється автоматично й обчислюється як поточна дата плюс один рік. Для прийняття хоч яких те заходів для забезпечення істинності й адресності переданого в режимі ON-LINE запиту використовується захищений транспортний протокол TLS з авторизацією по персональному сертифікаті в момент утворення з'єднання, однак CMC запис, утворений з PKCS#10 запиту в базі "історій" сертифікатів на ЗЦ не буде (і технічно не може) мати ЕЦП адміністратора, що відповідальний за інформацію представлену в запиті, що може викликати значні труднощі при розборі можливих конфліктних ситуацій зв'язаних саме з цим сертифікатом у службі Арбітражу ЗЦ. 

Більш безпечної є режим ON-LINE перевидання власного сертифіката, при якому інформаційна частина витягається з уже перевіреного Службою адміністраторів ЗЦ сертифіката, а сама CMC запис має ЕЦП раніше виданого діючого сертифіката користувача.

 

 

На відміну від запиту у форматі PKCS#10 даний вид запиту позбавлений описаних вище недоліків, більш того він дозволяє описати вимогу на створення ключової інформації засобами (сертифікованими) ЗЦ. 

Форми, пропоновані до заповнення Адміністратором ЗЦ по представленню інформації кінцевого користувача майже аналогічні з формами запиту PKCS#10. Користувачем заповнюється запропонований ланцюжок форм, деякі полючи в аркушах ланцюжка є недоступними для даного виду запиту. 

Якщо у формі майстра запитів був зведений додатковий прапор "Зробити перевидання існуючого сертифіката" (сертифікат повинний мати статус - Особисті сертифікати), то дані будуть включені в запит зі складу обраного сертифіката. Такий режим корисний для систем, у яких регламентом допускається перевидання власних сертифікатів самостійно самим користувачем минаючи службу Адміністраторів взаємодії з користувачами. 

1.необхідно вказати яким кореневим сертифікатом ЗЦ буде завірений сертифікат, для якого готується запит (від якого кореня буде видаватися даний сертифікат);

2.необхідно вказати сертифікат з бази "Особисті сертифікати", ключ якого буде брати участь у виробленні ЕЦП на CMC запиті, тобто сертифікат Адміністратора;

3.необхідно вказати для яких задач буде використані створюваний сертифікат і визначити області і порядок застосування сертифіката, для яких його використання буде вважатися дійсним;

4.Адміністратор може керувати періодом дії створюваного сертифіката. Але в будь-якому випадку період дії сертифіката не може перевищувати дати припинення дії кореневого сертифіката ЗЦ, від якого видається користувальний сертифікат. 

На цьому кроці Адміністратор може визначити мітки мандатної політики розмежування доступу, їхній рівень. Види доступу і максимальний рівень доступу визначені в кореневому сертифікаті, від якого видається користувальний сертифікат. 

Адміністратор може створювати сертифікати інших адміністраторів із указівкою спеціальних мандатних міток. Автоматично відслідковується ланцюжок підпорядкування значень міток, не можна створити мітку, зі значенням перевищуючому або рівним значенню мітки в кореневому сертифікаті видавця або мітки із сертифіката Адміністратора, що підписує поточний CMC запит. Молодші розряди Ідентифікатора політики розмежування доступу можуть вводиться в додатковому вікні через роздільник "+". У системі зареєстровані два молодших розряди: 

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

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

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

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

6.Указати пароль, що буде брати участь у шифруванні (розшифрування) секретного