3.2.5.3. Особливість

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

3.2.5.4. Створення проксі-сертифіката

Проксі-сертіфікат може використовуватися для делегації особи користувача до іншого користувача. Як можна це досягти в безпечній формі? Наприклад, припустимо що B потрібне посвідчення особи А, щоб виконати запит до C. Тому B потрібний проксі-сертифікат, підписаний А. Процесс створення цього сертифікату буде наступним:

• B створює відкриту/приватну пару ключів для проксі-сертифіката.

• B використовує пару ключів, щоб створити запит сертифікату, який буде відправлений А використовуючи безпечний канал. Цей запит сертифікату включає відкритий ключ проксі, але не приватний ключ.

• Імовірно А згоден делегувати його посвідчення особи до B, Організація А використовує приватний ключ, щоб підписати запит свідоцтва в цифровій формі.

• А посилає підписаний сертифікат назад до B, використовуючи безпечний канал.

• Тепер B може використовувати проксі-сертифікат, щоб діяти на користь A.

Важливе те, що приватний ключ проксі ніколи не передається між А і B. Це також торкається щодо приватного ключа A.

3.2.5.5. Підтвердження проксі-сертифіката

Звернемо увагу на C. Коли B посилає запит від імені А, і посилає C проксі-сертифікат, як може C перевірити правильність сертифікату? Іншими словами, як може C бути абсолютно упевнений, що B діє на користь A?

Процес перевірки достовірності прокси-сертификата практично ідентичний процесу перевірки достовірності звичайного сертифікату. Основна різниця в тому, що проксі-сертифікат не підписується у Центрі Сертифікації (CA), його підписує користувач. У даному прикладі, проксі-сертифікат підписаний А, який означає, що необхідний відкритий ключ A, щоб перевірити його достовірність. Оскільки С навряд чи має сертифікат A, запит, який використовує проксі-сертифікат зазвичай посилає сертифікат делегатора, щоб можна було перевірити правильність проксі-сертифіката. Коли сертифікат делегатора буде підписаний Центром Сертифікації, залишиться тільки перевірити правильність підпису Центру Сертифікації. На рис.№15 показано ланцюжок підписів проксі-сертифіката.

Рисунок 15. Підтвердження проксі-сертифіката

3.2.5.6. Додатково про проксі-сертификати

Існує безліч операцій, що виконуються з допомогою проксі-сертифікатів крім тих, що вже розглядалися. Наприклад, є можливість використовувати проксі-сертифікати для підпису інших проксі-сертификатів. Для детальнішого вивчення проксі-сертифікатів рекомендується прочитати RFC 3820, InternetX.509 Public Key Infrastructure Proxy Certificate Profile, доступний за адресою http://www.ietf.org/rfc/rfc3820.txt.

3.2.5.7. Контейнер, служба, і захист ресурсу

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