6.2. Использование алгоритма ПрПП маршрута
Алгоритм ПрПП маршрута сертификации описывает операции обработки одиночного МС. Несмотря на то, что каждый МС начинается с ДЗУЦ, не существует требований, чтобы все МС, проверяемые на подлинность с помощью соответствующей системы, использовали совместно только одиночный ДЗУЦ. Выбор одного или более доверенных УЦ является локальной задачей. Система может назначать любой УЦ из числа доверенных в качестве ДЗУЦ для конкретного МС. Входные данные алгоритма ПрПП могут быть разными в зависимости от МС. Входные данные, используемые при обработке маршрута, могут отражать специфику требований прикладной системы или ИТС, а также ограничений, накладываемых на доверие в интересах реализации соответствующей политики сертификации. Например, доверенный УЦ может иметь статус доверенного только в интересах реализации соответствующей политики сертификации. Такое ограничение может быть реализовано с помощью используемых для ПрПП входных данных.
Прикладные системы и ИТС могут дополнить алгоритм, представленный в 6.1, с целью дополнительного ограничения совокупности приемлемых МС, которые начинаются с соответствующего ДЗУЦ. Например, прикладные системы и ИТС могут модифицировать алгоритм с целью использования последовательности «pathLenConstraint» (ограничение на длину маршрута) субполя «basicConstraints» в поле «Расширения» сертификата для конкретного ДЗУЦ в течении фазы инициализации, либо прикладная система может потребовать наличие соответствующего формата альтернативного имени в целевом сертификате, либо прикладная система может установить требования для конкретных прикладных расширений. Таким образом, алгоритм ПрПП, представленный в 6.1, устанавливает минимально необходимые условия для МС, который считается приемлемым.
Там, где УЦ распространяет само-подписанный сертификаты в целях определения информации о ДЗУЦ, для описания рекомендованных входных данных для ПрПП может использоваться поле «Расширения» сертификата. Например, субполе «policyConstraints» поля «Расширения» могло бы использоваться в само-подписанном сертификате для указания того, что МС, начинающиеся с этого ДЗУЦ, должны быть надёжными только для конкретных политик. Аналогично, субполе «nameConstraints» поля «Расширения» могло бы указывать на то, что МС, начинающиеся с этого ДЗУЦ, должны быть надёжными только для конкретных пространств имён. Алгоритм ПрПП маршрута, представленный в 6.1, не предполагает, что данные о ДЗУЦ предоставляются в само-подписанных сертификатах, и не устанавливает правил обработки дополнительной информации, представленной в таких сертификатах. Тем не менее, стандарт RFC-5914 устанавливает несколько форматов для кодирования информации о ДЗУЦ, включая само-подписанные сертификаты, а стандарт RFC-5937 приводит пример того, как такая информация может использоваться в качестве входных данных в фазе инициализации ПрПП маршрута. Прикладные системы и ИТС свободны в выборе варианта использования любой дополнительной информации, которая включена в структуру данных о ДЗУЦ, либо они в праве проигнорировать такую информацию.