Архитектура расширенного списка доверия

Архитектура расширенного списка доверия

Архитектура расширенного списка доверия корректирует недостатки простого списка доверия. Каждый пункт доверия в списке идентифицирует PKI, которой доверяет данный пользователь. Эта инфраструктура может быть одиночным УЦ, иерархией или сетью. Пользователь доверяет путям сертификации, которые начинаются с сертификата, выданного любым УЦ из списка доверия.

Пример 10.5. Чтобы защищенно связываться с пользователями B, C и D, пользователь А должен включить в свой расширенный список доверия три удостоверяющих центра: по одному УЦ от каждой доверенной PKI (см. рис. 10.7). Пользователь А доверяет своему собственному УЦ "Альфа", головному УЦ иерархической PKI компании "Бета" и одному УЦ в сетевой PKI компании "Гамма". Внутри каждой корпоративной PKI удостоверяющие центры могут быть связаны одноранговыми или иерархическими связями. Пользователь А может легко добавить новый УЦ или целую корпоративную PKI в свой список доверия. Сложность сертификатов зависит от связей в каждой корпоративной PKI.

Эта архитектура сохраняет основное преимущество простого списка доверия. Если пользователю А в целях бизнеса необходимо доверять пользователям другой PKI, которая не имеет отношений доверия с УЦ пользователя А, список доверия позволяет быстро и просто решить эту проблему, а также использовать преимущества иерархической и сетевой инфраструктур. Чтобы обеспечить безопасность коммуникаций с другими сообществами пользователей, пользователь А может полагаться на надежность отношений доверия, установленных теми удостоверяющими центрами, которым он доверяет. Это позволяет уменьшить количество пунктов доверия, информацию о которых должен обновлять пользователь А.

Архитектура расширенных списков доверия не избавляет пользователей от необходимости поддерживать актуальность своих списков доверия и не решает проблемы компрометации УЦ. Что касается структуры списка доверия, то пользователь А, выбирая свои пункты доверия, может руководствоваться выгодой или целесообразностью, а вовсе не безопасностью. Длинный список доверия существенно труднее поддерживать, кроме того, как и в случае с простым списком доверия, работая с расширенным списком, пользователь А может вовремя не получить уведомление о компрометации какого-либо УЦ.

Архитектура расширенного списка доверия требует решения новых проблем. Построение пути становится более сложным, поскольку пользователь А не всегда может определить, от какого из доверенных центров следует начинать построение пути сертификации. Пользователь А не имеет возможность строить путь, начиная от своего доверенного УЦ, как это позволяет делать сетевая PKI, - тогда бы ему пришлось формировать цепочку сертификатов для каждого пункта доверия из списка. Поэтому при построении пути пользователю А следует начинать движение от сертификата пользователя, с которым он желает связаться, в направлении одного из доверенных удостоверяющих центров из своего списка доверия.