Почему привязка доверия не должна быть включена в путь сертификации PKIX?

#java #security #encryption #ssl #ssl-certificate

#java #Безопасность #шифрование #ssl #ssl-сертификат

Вопрос:

В документации PKIX упоминается:

  1. Сертификат, представляющий TrustAnchor, не должен быть включен в путь сертификации

Мой вопрос в том, откуда взялось это ограничение? В RFC 5280 я нашел только:

  1. Сертификат НЕ ДОЛЖЕН появляться более одного раза в предполагаемом пути сертификации.

Подразумевает ли оператор (2) в RFC каким-либо образом оператор (1)? Потому что я этого не вижу.

Какую проблему создало бы наличие привязки доверия также в пути? В конце концов, сертификат TA может проверить себя.

Кто-нибудь, пожалуйста, может объяснить это?

Ответ №1:

Это скорее определение, IIUC. Допустимый путь сертификации определен в RFC 5280, и одним из условий является то, что его первый сертификат подписан привязкой доверия (и что имя эмитента сертификата совпадает с именем привязки доверия). (Привязки доверия не обязательно должны быть сертификатами.)

Комментарии:

1. Вы правы. Объект TA в java может быть инициализирован с помощью открытого ключа и имени. Но если первым в пути указан фактический сертификат TA (согласно 5280) Я не вижу проблемы. Он по-прежнему будет использовать свой собственный ключ для проверки. Причина, по которой я спрашиваю об этом, заключается в том, что в конкретном случае, использующем PKIX api, у меня оказался сертификат TA в качестве первого и единственного сертификата в пути проверки, а также тот же сертификат, переданный в качестве параметра TrustAnchor. Я получил исключение «Не удалось найти допустимый путь». Но сертификат был тем же самым! На этом этапе я теряюсь

2. Я предполагаю, что это просто так: привязка доверия может не быть частью пути сертификации. Я не вижу никакой проблемы в библиотеке, разрешающей это (и просто игнорирующей сертификат привязки доверия, если он является частью пути сертификации), но, похоже, что используемые вами API этого не разрешают. Я не думаю, что происходит что-то особенно глубокое; просто некоторое желание поддерживать соответствие API самим себе и стандартам.