Алгоритм проверки пути сертификации является алгоритмом , который проверяет , что данный путь сертификата действителен при данной инфраструктуре открытого ключа (PKI). Путь начинается с сертификата Субъекта и проходит через ряд промежуточных сертификатов до доверенного корневого сертификата , который обычно выдается доверенным центром сертификации (ЦС).
Проверка пути необходима проверяющей стороне для принятия обоснованного решения о доверии при представлении любого сертификата, который еще не является явно доверенным. Например, в иерархической PKI цепочка сертификатов, начинающаяся с сертификата веб-сервера, может вести к небольшому ЦС, затем к промежуточному ЦС, а затем к большому ЦС, чей якорь доверия присутствует в веб-браузере проверяющей стороны. В мостовой PKI цепочка сертификатов, начинающаяся с пользователя в компании A, может привести к сертификату CA компании A, затем к мостовому CA, затем к сертификату CA компании B, затем к якору доверия компании B, который является проверяющей стороной в компании B можно было доверять.
RFC 5280 [1] определяет стандартизированный алгоритм проверки пути для сертификатов X.509 с учетом пути сертификата. (Обнаружение пути, фактическое построение пути, не рассматривается.) Алгоритм принимает следующие входные данные:
- Путь к сертификату для оценки;
- Текущая дата / время;
- Список идентификаторов объектов политики сертификатов (OID), приемлемых для доверяющей стороны (или любой другой);
- Якорь доверия пути к сертификату; а также
- Указывает, разрешено ли отображение политик и как / когда / следует ли допускать OID «любой» политики .
В стандартизированном алгоритме следующие шаги выполняются для каждого сертификата в пути, начиная с якоря доверия. Если какая-либо проверка какого-либо сертификата завершается неудачно, алгоритм завершается и проверка пути не выполняется. (Это пояснительное резюме объема алгоритма, а не точное воспроизведение подробных шагов.)
- Проверяются алгоритм и параметры открытого ключа;
- Текущая дата / время сверяется со сроком действия сертификата;
- Статус отзыва проверяется CRL , OCSP или каким-либо другим механизмом, чтобы гарантировать, что сертификат не отозван;
- Имя издателя проверяется, чтобы убедиться, что оно совпадает с именем субъекта предыдущего сертификата в пути;
- Проверяются ограничения имени, чтобы убедиться, что имя субъекта находится в списке разрешенных поддеревьев всех предыдущих сертификатов CA, а не в списке исключенных поддеревьев любого предыдущего сертификата CA;
- Заявленная политика сертификата OID , проверяется на допустимые OIDs от предыдущего сертификата, включая любые отображения политики эквивалентности , заявленные предыдущий сертификат;
- Проверяются ограничения политики и основные ограничения, чтобы убедиться, что любые явные требования политики не нарушены и что сертификат является сертификатом CA, соответственно. Этот шаг имеет решающее значение для предотвращения атак человека посередине ; [2]
- Длина пути проверяется, чтобы убедиться, что она не превышает максимальную длину пути, заявленную в этом или предыдущем сертификате;
- Расширение использования ключа проверяется, чтобы убедиться, что ему разрешено подписывать сертификаты; а также
- Все другие критические расширения распознаются и обрабатываются.
Если эта процедура достигает последнего сертификата в цепочке без ограничения имени, нарушений политики или любых других условий ошибки, то алгоритм проверки пути сертификата успешно завершается.
Внешние ссылки [ править ]
- ^ RFC 5280 (май 2008 г.), глава 6., стандартизированный алгоритм проверки пути для сертификатов X.509 .
- ^ Мокси Марлинспайк, Новые приемы для победы над SSL на практике ,конференция Black Hat DC Briefings 2009.
См. Также [ править ]
