Да, все так.
По поводу добавления новых УЦ: если не ошибаюсь на e-trust.gosuslugi.ru есть выгрузка исчерпывающего списка с сертификатами и адресами. Можно ее разобрать и тогда не придется вручную добавлять адреса, боясь опечататься.
По разным интервалам УЦ: в принципе важно какой интервал Вам покажется безопасным. Списки отзыва по сути меняются при событии отзыва, а не по расписанию. Нет никакой гарантии, что следующий опубликованный через час список отзыва будет содержать хотя бы одно изменение и нет никакой гарантии, что изменение будет только одно. Поэтому на то расписание, которое предлагает УЦ можно просто начхать. Важно на какой риск в бизнес-процессах Вы готовы пойти. Чем больше интервал кэширования - тем больше риск, вот и все. Когда очередь большая можно интервал увеличивать.
С другой стороны, если обновления в разное время, это как раз может быть использовано как шанс разгрузить канал. Нужно только придумать интеллектуальный планировщик, не допускающий скоплений или скачивающий списки преимущественно ночью к утру. Задача распределения нагрузки не такая редкая, наверняка уже что-то есть, пусть и не для списков отзыва, что можно адаптировать.
У нас вот есть аккредитованный УЦ, который публикует списки отзыва раз в три месяца. Понятно что отзывы фактически происходят чаще, но те списки доступны только внутри сети, а в Интернете для сервиса проверки для МКС список меняется раз в три месяца. Замечательно, правда? Хоть каждые 10 минут можно проверять, но меняется вручную раз в 90 суток.
Еще вариант - вроде поднимали такую тему в связи с тем, что через 10 минут начинала тормозить проверка подписи - теоретически возможно неявно кэшировать результат проверки конкретного сертификата, то есть грубо говоря, запускать все подписи от одного клиента (контрагента) в отдельный поток, в котором уже будет "кэширован" в неких объектах КриптоПро результат от первой проверки сертификата клиента. Так повторная проверка будет без запроса списка отзыва. Тоже вроде можно было регулировать интервал до перепроверки списка, по умолчанию только 10-15 минут, но при большом потоке подписей одного клиента такой ход может очень даже снизить количество попыток скачивания CRL. Надо только разобраться какие объекты не уничтожать, а использовать повторно.
К сожалению, с веб-технологиями такое обычно не работает, так как веб-сервер периодически перезапускает рабочий процесс и это обычно чаще чем происходит повтор, но есть над чем подумать. При выполнении проверки внешней консольной программой очевидно тоже не работает, так как программа завершается после каждой проверке и освобождает объекты. Вот некая программа относительно постоянно висящая в памяти и разделяюшая подписи контрагентов по сертификатам в разные потоки (конкретный сертификат если уже был в каком-то потоке - то идет в него же, если сертификат попался первый раз - то создается новый поток) - хорошо бы подошла. Да, затратно по ресурсам, но плюс по скорости проверки. Для разумного баланса между ресурсами и скоростью, допустим, только раз в полчаса освобождать неиспользуемые потоки с "кэшированными" проверками конкретного сертификата (так как кэш уже истечет).