0

СценарийЗагрузка только третья сторона доверенных узлов в Application Server

Я хочу создать сервер, который загружает подключаемые сборки от сторонних поставщиков. Поставщику сторонних поставщиков необходимо выполнить некоторые контракты при внедрении подключаемых модулей. Плагины сторонних плагинов необходимо скопировать в указанную папку развертывания сервера. Сервер будет динамически загружать подключаемые сборки. Серверу необходимо загружать только те сборки, которые находятся в надежном источнике.

Возможное решение

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

alt text

Листок узел (выделено фиолетовым цветом) обозначает возможные случаи испытаний.

Мне нужно, чтобы получить идеи/обратная связь на следующем:

  • ли описанный выше механизм на основе цифровых сертификатов является достаточно хорошим для вышеупомянутого сценария?
  • Каковы другие альтернативы в дополнение к технологии цифровых сертификатов?
  • Есть ли отсутствующие тестовые примеры, которые не были рассмотрены (на основе приведенной выше диаграммы)?

Спасибо.

+0

Необходимо проверить механизм недействительности. Корневой ЦС должен содержать ссылку на службу, в которой перечислены запрещенные сертификаты. – mpapis

ответ

1

Только некоторые случайные мысли.

Хотя это не единственный способ сделать это (с верхней части моей головы вы могли бы, например, использовать HMAC с определенными ключами или просто алгоритм с открытым ключом, такой как RSA или DSA самостоятельно), это, вероятно, лучший способ достичь того, что вы хотите сделать с минимальными усилиями.

Конечно, я бы предположил, что вы будете действовать как СА в этом сценарии, и любая сторонняя сторона может получить сертификат, подписанный от вас? Если нет, и вы просто скажете, что это Verisign cert и т. Д., Вы можете рассмотреть возможность проверки использования ключа и расширенных полей использования ключа сертификата, чтобы убедиться, что он подходит для подписи двоичных файлов (чтобы остановить кого-то, например, с помощью SSL-сертификата) ,

Как указано в приведенном выше комментарии, вы хотите проверить списки аннулирования сертификатов, хотя это может быть указано в подписанном и неподписанном. Вероятно, вам также нужен отдельный тестовый сценарий между полностью неподписанным файлом, файл, который подписан, но неправильно (например, открытые ключи не совпадают), и тот, который подписан, но недействителен, например. подпись не имеет временного ограничения доверенным органом, и срок действия сертификата истек, или материал CRL.

Также вы исключаете возможность подписания сертификата CA? Это глупо, но технически нет ничего плохого в этом. Вы даже можете просто пропустить весь материал CA и получить третью сторону для создания собственного самозаверяющего сертификата и отправить его администратору сервера, который добавит его в список действительных сертификатов для использования.Единственная причина для ЦС заключается в том, что они должны проверять детали лица, который этого хочет, в зависимости от того, как вы планируете использовать эту систему, чем это может быть необязательно.

+0

Вы можете рассмотреть OCSP для обработки отзыва, я не использовал его напрямую, но я думаю, что это более новый подход к решению проблемы CRL. – Justin