Если установить корневой сертификат в системное хранилище, то любые браузеры будут доверять любым сертификатам, которые были подписаны этим корневым. Это противоречит смыслу нашего текущего решения:
1. Мы доверяем только тем сертификатам, которые доступны для публичного аудита через логи.
Яндекс точно не хочет сам хостить УЦ, как участник процесса, обладающий браузером. Иметь несколько центров сертификации в принципе скорее хорошо, чем плохо, и мы готовы обсуждать с индустрией разнообразные решения.
Про "выписывание" имеется в виду создание на стороне клиента ключа, формирование на стороне клиента подписанного CSR и рассмотрение заявки на госуслугах. Клюс создается владельцем и остается у него, да.
В систему не тащим из принципа (и сверху написаны резоны). Мы не хотим делать system-wide изменений. В локальном хранилище лежит один сертификат - текущего НУЦ. Имеет смысл этот список (сейчас из одного элемента) сделать видимым пользователю, да
Яндекс Браузер пользуется системным списком доверенных сертификатов УЦ, но с осторожностью — у нас есть фича (https://habr.com/ru/company/yandex/blog/326796/), которая предупреждает, если сертификат сайта, на который вы заходите, подписан неизвестным нам, но установленным в систему корневым сертификатом.
Сертификат НУЦ мы в систему не устанавливаем, в частности, по причинам, описанным в посте — он приносится внутренними механизмами браузера в собственное хранилище, и используется с ограниченным доверием — только на сайтах из опубликованного (и верифицированного нами) списка.
Все появляющиеся изменения этого списка проходят через наш собственный контроль явных ошибок. Мы уверены, что появление gmail и подобных адресов в этом списке возможно только по ошибке, так что мы не пропустим такой измененный список к пользователям и начнем выяснять причины появления этого домена.
Если установить корневой сертификат в системное хранилище, то любые браузеры будут доверять любым сертификатам, которые были подписаны этим корневым. Это противоречит смыслу нашего текущего решения:
1. Мы доверяем только тем сертификатам, которые доступны для публичного аудита через логи.
2. Мы не вмешиваемся в работу других браузеров.
Яндекс точно не хочет сам хостить УЦ, как участник процесса, обладающий браузером. Иметь несколько центров сертификации в принципе скорее хорошо, чем плохо, и мы готовы обсуждать с индустрией разнообразные решения.
Про "выписывание" имеется в виду создание на стороне клиента ключа, формирование на стороне клиента подписанного CSR и рассмотрение заявки на госуслугах. Клюс создается владельцем и остается у него, да.
В систему не тащим из принципа (и сверху написаны резоны). Мы не хотим делать system-wide изменений. В локальном хранилище лежит один сертификат - текущего НУЦ. Имеет смысл этот список (сейчас из одного элемента) сделать видимым пользователю, да
Яндекс Браузер пользуется системным списком доверенных сертификатов УЦ, но с осторожностью — у нас есть фича (https://habr.com/ru/company/yandex/blog/326796/), которая предупреждает, если сертификат сайта, на который вы заходите, подписан неизвестным нам, но установленным в систему корневым сертификатом.
Сертификат НУЦ мы в систему не устанавливаем, в частности, по причинам, описанным в посте — он приносится внутренними механизмами браузера в собственное хранилище, и используется с ограниченным доверием — только на сайтах из опубликованного (и верифицированного нами) списка.
Да CSR есть, он подписывается УКЭП юрлица. За имейл спасибо - первый баг, найденный из-за открытости системы.
Поэтому мы и работаем над Certificate Transparency. Это позволит построить внешний аудит.
Все появляющиеся изменения этого списка проходят через наш собственный контроль явных ошибок. Мы уверены, что появление gmail и подобных адресов в этом списке возможно только по ошибке, так что мы не пропустим такой измененный список к пользователям и начнем выяснять причины появления этого домена.