Я именно об этом и написал, отвечая на ваш вопрос номер 277, а именно, якорь домена, т.е. самый страшный секрет домена в виде самоподписанного сертификата надо распространять доверенным образом, например, (как тут писалось) при продаже СКЗИ, при продаже ЕЕ-сертификата. TSL список (если выбрана именно такая технология доставки в ИС промежуточных сертификатов, а не заполнения AIA из состава ЕЕ-сертификата, что на мой взгляд много проще для ИС) не должен содержать самоподписанные сертификаты, защита которых основана на производных ключах от него самого.
Теперь по поводу построения цепочки до сертификата ГУЦа от пользовательского. Тут тоже не так всё просто у нас в РФ сделано, я об этом уже на форуме не раз писал. По стандарту и по Приказу ФСБ 795 (п.24) невозможно построить действительную цепочку сертификации если посередине существует однонаправленный кросс-сертификат, которые выпускает МКС. На практике на это все закрывают глаза, что понятно, работать то как то надо, но формально это риски УЦ, которые работают из-под самоподписанного ими сертификата, а кросс, полученный от МКС, просто прибили в рамочке на стену. До тех пор пока не видна явно выгода как использовать этот косяк архитектуры, можно конечно работать и так, но если на кону будут большие деньги, суд УЦ проиграет точно, поскольку в этой ситуации его вынудили нарушить закон (и он об этом знает исходно) и выпускаемые им сертификаты для конечных пользователей формально находятся вне дерева квалифицированных и можно совершить атаку на вид подписи.

DNS тут не при чём. Повторяю, если сертификат ГУЦ распространять доверенно, то осуществить атаку на сертификат цепочки невозможно, у вас просто цепочка не построится вот и всё.
Если почитаете про AIA то в его состав не включается самоподписанный корень, и это правильно.


Сертификат ГУЦ является самоподписанным и не участвует в построении цепочки для самого себя, поэтому на него п. 24 Приказа не распространяется.
По поводу "И в суде, имхо, достаточно установить соответствие самоподписанного сертификата УЦ, на котором выпускаются пользовательские, кросс-сертификату, выданному МКС, например, по соответствию значения открытого ключа, который как мы знаем должен быть уникальным." если посмотреть 63-ФЗ, то там в разделе про описание что такое головной УЦ (Ст. 13 п.4), разговор идёт именно о сертификате , а не о ключах. Так что формально этот пункт не выполняется просто по буквам которые написаны в законе. Сертификат и открытый ключ - это разные сущности и определения у них разные в том же 63-ФЗ. Ну а уж как решит суд - это ответственность суда :-)
И ещё немного техники, если пользовательские сертификаты выпускать от самоподписанного УЦ и если у пользователя в хранилище присутсвует этот самоподписанный, то цепочка сертификации будет строится не до ГУЦ , а до этого самоподписанного аккредитованного УЦ. В этом случае появляется другая опасность: даже если ГУЦ отзовёт аккредитацию и следом отзовёт кросс, то цепочка всё равно будет продолжать строится на раб месте пользователя. Т.е. понимаете в чём дыра? Атака на статус сертификата.

Это очевидно. Такой подход был оправдан когда жили одновременно и 1-ФЗ и 63-ФЗ. Но сейчас то 1-ФЗ уже нет, а МКС видать просто прохлопало это событие и не сменила технологию публикации сертификатов. Так что беда присутствует и техническая и нормативная. Осталось подождать, кому будет выгодно попользовать эти косяки реализации.

В AIA по стандарту не может быть размещён самоподписанный сертификат. Т.е. если , с ваших слов, так делалось раньше, то это не соответствовало стандарту. Опять же понятно почему не надо размещать этот самоподписанный сертификат, логика атаки точно такая же как и атака на TSL, запросто возможно создание "дубликата" пользовательского сертификата с информационным наполнением от оригинального, но с управляемой атакующим ключевой парой, включая и УЦ.

Вопрос риторический. Дело в том что безопасность это компромис между удобством (или вообще возможностью работать ИТ) и приемлемостью рисков от атак. Если эту грань не регулирует закон (который как известно в РФ не сильно любят исполнять), то каждый волен выбирать как ему удобнее.

Попробую повторить ещё разок.
1. Сетевая (не защищённая) загрузка самоподписанных (т.е. ни чем не защищённых) подвержена атаки на навязывание ложной информации. Если хотите можете этот риск принять, только если что случится, и дело дойдёт до суда, вы вряд ли выкрутитесь, поскольку проблема очевидна. При такой загрузке целостность обеспечить просто невозможно, поскольку не ясен вопрос - целостность чего обеспечивать? Ложного сертификата или истинного - они оба целые и не битые.
2. Доверенное распространение совсем не сложно обеспечить, тут уже пару раз предлагались решения: распространять вместе с СКЗИ, распространять вместе с получением персонального сертификата, явное-личное обращение в УЦ, ГУЦ и т.д.
3. Самое правильное - ничего не выдумывать и следовать международным стандартам и опыту. Мы вот тут в лёгкую без всяких глубоких исследований выяснили, что построенный PKI квалифицированный домен в РФ подвержен целому ряду атак, такой дырявой реализации я не видел ни где в Европе. В свете этого совсем не удивительно, что банки шарахаются от квалифицированных сертификатов как черт от ладана, что понятно, там деньги по сети летают и реальные риски, которые можно подсчитать в рублях. Об этом, в частности очень долго говорили, кто был слышал, на секции «Безопасность национальной платежной системы: как создать атмосферу доверия к компонентам инфраструктуры применения электронных подписей?» ИНФОФОРУМА-2014 в январе которую вел Тимур Аитов.