Алгоритм проверки пути сертификации - Certification path validation algorithm

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

Проверка пути необходима для полагающаяся сторона для принятия обоснованного решения о доверии при представлении любого сертификата, который еще не является явно доверенным. Например, в иерархической PKI цепочка сертификатов, начинающаяся с сертификата веб-сервера, может вести к небольшому CA, затем к промежуточному CA, а затем к большому CA, чей якорь доверия присутствует в веб-браузере проверяющей стороны. В мостовой PKI цепочка сертификатов, начинающаяся с пользователя в компании A, может привести к сертификату CA компании A, затем к мостовому CA, затем к сертификату CA компании B, а затем к якорю доверия компании B, который является проверяющей стороной в компании B. можно было доверять.

RFC  5280[1] определяет стандартизированный алгоритм проверки пути для X.509 сертификаты с указанием пути к сертификату. (Обнаружение пути, фактическое построение пути, не рассматривается.) Алгоритм принимает следующие входные данные:

  • Путь к сертификату для оценки;
  • Текущая дата / время;
  • Список политика сертификатов идентификаторы объектов (OID), приемлемые для доверяющей стороны (или любой другой);
  • Якорь доверия пути к сертификату; и
  • Показывает, разрешено ли сопоставление политик и как / когда / есть ли политика "любая" OID следует терпеть.

В стандартизированном алгоритме следующие шаги выполняются для каждого сертификата в пути, начиная с якоря доверия. Если какая-либо проверка какого-либо сертификата завершается неудачно, алгоритм завершается и проверка пути не выполняется. (Это пояснительная сводка объема алгоритма, а не точное воспроизведение подробных шагов.)

  • Проверяются алгоритм и параметры открытого ключа;
  • Текущая дата / время сверяется со сроком действия сертификата;
  • Статус отзыва проверяется, CRL, OCSP или какой-либо другой механизм, гарантирующий, что сертификат не будет отозван;
  • Имя издателя проверяется, чтобы убедиться, что оно совпадает с именем субъекта предыдущего сертификата в пути;
  • Проверяются ограничения имени, чтобы убедиться, что имя субъекта находится в разрешенном списке поддеревьев всех предыдущих сертификатов CA, а не в списке исключенных поддеревьев любого предыдущего сертификата CA;
  • Утвержденный политика сертификатов OID проверяются на соответствие допустимым OID по состоянию на предыдущий сертификат, включая любые эквивалентности отображения политик, заявленные предыдущим сертификатом;
  • Проверяются ограничения политики и основные ограничения, чтобы убедиться, что любые явные требования политики не нарушены и что сертификат является сертификатом CA соответственно. Этот шаг имеет решающее значение для предотвращения некоторых человек посередине атакует;[2]
  • Длина пути проверяется, чтобы убедиться, что она не превышает максимальную длину пути, заявленную в этом или предыдущем сертификате;
  • Расширение использования ключа проверяется, чтобы убедиться, что ему разрешено подписывать сертификаты; и
  • Все другие критические расширения распознаются и обрабатываются.

Если эта процедура достигает последнего сертификата в цепочке без ограничения имени, нарушений политики или любых других условий ошибки, то алгоритм проверки пути сертификата успешно завершается.

внешняя ссылка

  1. ^ RFC  5280 (Май 2008 г.), глава 6., стандартизированный алгоритм проверки пути для X.509 сертификаты.
  2. ^ Мокси Марлинспайк, Новые приемы для победы над SSL на практике, Черная шляпа Конференция DC Briefings 2009.

Смотрите также