Добавить в закладки могут только зарегистрированные пользователи.
Архитектура PKI у нас построена просто из рук вон как плохо... 

Сергей Муругов10 марта 2015 г. 15:42

Собираю боекомплект из компонент ДТСа для заказчика, просматриваю доки и ловлю себя на мысли (в очередной раз), что-то, как построена архитектура PKI у нас просто из рук вон как плохо. В первую очередь это касается процедуре построения цепочки сертификации (как одного из этапов проверки ЭЦП).

Вопросы признания действительной цепочки сертификации автора ЭЦП или проверяемого сертификата тесно связаны с выбранной моделью организации доверия в конкретной PKI, в том числе ограничениями на промежуточные связи от проверяемого сертификата до издателя, который считается доверенным.
Чтоб было совсем наглядно покажу на прикреплённом рисунке – там нарисован Бридж, поскольку на этой модели распределения доверия наиболее явно видна проблема. К слову, на иерархии проблема тоже никуда не девается.

Из рисунка видно, что цепочка сертификации должна строиться с учетом всех четырех ограничений.
Другими словами, выбирая за якорь сертификаты различных УЦ, входящих в цепочку сертификации, можно получить разные результаты процедуры определения действительности сертификата автора ЭЦП.

А теперь смотрим что у нас на сейчас в квалифицированном домене. Выбрав за якорь самоподписанный сертификат автора подписи (а так оно по жизни и есть, и даже есть судебные решения (кому интересно могут поискать в постах Натальи Храмцовской) о том, что именно так и надо делать), мы, при проверке сертификата автора ЭЦП не учитываем ограничения, входящие в кросс от ГУЦ до аккредитованного УЦ, а там между прочим может быть что-то написано и по факту написано, например, глубина равная 1 уровню.

Поразмыслив и «посовещавшись с товарищами» родились некоторые тезисы, которые надо бы не забыть, тому, кому это поручат, раскрыть в НПА для вновь исправляемого 63-ФЗ:

1)     Зафиксировать профиль сертификата со всем возможным наполнением, зафиксировать строго, жестко, без возможности что-либо самолично на местах вписывать. Напомню, сейчас идет отсылка на RFC 5280, а там столько понаписано!!!

2)     Зафиксировать правила построения иерархии, включая необходимые ограничения в рамках обозначенных в п1 (на глубину, на дерево имен, на политики применения). Подразумеваются требования к сертификатам подчиненных издателей. Сюда же, добавить регламент по переходным процедурам смены главного корня; этот регламент возможно потребуется применить при переходе от текущей системы УЦ к новой, и потом, при внедрении новых алгоритмов, которое наверняка случится раньше, чем формально протухнут ключи ГУЦ-а (или нового корня).

3)     Зафиксировать процедуру шага проверки цепочки с учетом для расширений, отсутствующих в международных стандартах: как проверять ФСБшные issuerSignTool\subjectSignTool и т.п.

4)     Зафиксировать дополнительные ограничения на процедуру проверки в целом: что строить необходимо до реального корня иерархии, какие дополнительные параметры могут\должны передаваться на вход процедуре: ограничение на глубину, ограничение на список допустимых политик, запрет на спец-политику "anyPolicy", запрет на использование эквивалентных политик применения (запрет маппинга)

5)     Внятно прописать минимально-допустимый SLA (Service Level Agreement – соглашение о качестве обслуживания, которое по-хорошему должно быть частью CertificatePracticeStatement) для УЦ входящих в систему – в первую очередь по времени реакции системы на изменение статуса – от момента регистрации обращения пользователя, до момента публикации информации об изменении статуса (понятно, что время реакции в 24 часа это не серьёзно и влечёт огромнейшие риски).

 Оригинал поста в группе Facebook Новая стратегия развития госуслуг.

Источник:  LLC Top Cross

Тип: Записи блогов

 (4,31 - оценили 2 чел.)

Комментарии
  • Сохранить комментарий
  • Цитировать выделенное
  • Предпросмотр