[devel] X509v3: CRL Distribution Points: help is needed

[Alexey V. Vissarionov]

On 2018-08-08 18:43:25 +0300, manowar на altlinux.org wrote:

 > поле distributionPoint.fullName может, в свою очередь, быть
 > представлено _списком_ типа GeneralNames. Тогда получается, что
 > для каждого объекта DistributionPoint задать _несколько_ адресов
 > одновременно.

Да. И это будут несколько адресов _одного_ CRL.

 > Возможность и смысл указания нескольких адресов подтверждается
 > наличием в документе следующих слов: "each name describes a
 > different mechanism to obtain the same CRL.
				^^^^^^^^^^^^^
 > т.е. каждый адрес, входящий в состав distributionPoint.fullName,
 > вроде бы является _альтернативой_ для получения _одного и того
 > же_ списка отзыва.

Да.

 > Вот как выглядит в разобранном виде та часть файла подписи,
 > которая отвечает за CRL: [...]
 > Теперь, собственно, сам вопрос: структура выше соответствует
 > двум разным CRL?

Нет - это один CRL, для которого предусмотрена возможность взять
его как с локального зеркала (pki-lan), так и снаружи у ГРЧЦ.

 > или же это всё-таки два варианта получения одного и того же CRL?

Да.

 > Иными словами, что перед нами: два объекта типа DistributionPoint
 > или же две строки, относящиеся к одному такому объекту?

Это два места, откуда можно взять один и тот же CRL.

 > Сам я склоняюсь к первому варианту --- формально заявлено два
 > _разных_ CRL. Однако меня смущает указание на количество elem,
 > которое я не совсем понимаю как читать.

Список из двух списков, в каждом из которых по одному элементу.

 > Предыстория же моего вопроса связана с тем, что первый из
 > указанных адресов --- это, очевидно, адрес внутренней сети, а
 > не Интернет. А это значит, что издатель подписи (сертификата)
 > рассчитывал на то, что оба указанных им адреса будут расценены
 > как альтернативные и, при недоступности первого, проверяющий
 > перейдёт по второму.

Именно так. Локальное зеркало - best practice, ибо недоступность
CRL может привести к тому, что отозванный сертификат будет принят
как рабочий.

 > Но dirmngr (из пакета gnupg2) считает иначе: он расценивает
 > указанную информацию как список из двух различных CRL, которые,
 > следовательно, оба требуются для проверки подписи.

Идея здравая, но реализована, мягко говоря, per rectum.

 > Невозможность получить CRL по первому адресу в результате
 > приводит к невозможности подтвердить подпись.

Выражусь дипломатично: д, б.

Проверять, действительно, нужно все источники (на случай, если
какое-то свежее изменение в апстриме не доехало до зеркала), но
отваливаться по UTV (unable to verify|validate) следует только
когда недоступны _все_ источники.

 > Короче говоря, мне нужно понять кто не прав: GnuPG или grfc.ru.

Головожопы из GnuPG, которым стандарты не писаны.

 > В пользу последнего как будто бы говорит его официальный статус
 > УЦ.

Главное - в их пользу явно гласит стандарт.

 > Но с другой стороны, знаем мы эти статусы.

Плохо знаешь. У них за прошедшие лет 10 очень многое поменялось,
и прежде всего - они почти всех дедов-пердунов на пенсию выгнали.


-- 
Alexey V. Vissarionov
gremlin ПРИ altlinux ТЧК org; +vii-cmiii-ccxxix-lxxix-xlii
GPG: 0D92F19E1C0DC36E27F61A29CD17E2B43D879005 @ hkp://keys.gnupg.net
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : signature.asc
Тип     : application/pgp-signature
Размер  : 801 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20180808/0040f41e/attachment-0001.bin>