Ветка чуть выше. Про расширение сертификатов. Чтобы корневой центр мог удостоверять только домены которые прописаны в его сертификате. По обычной маске.
Даже новых полей добавлять не надо. Все уже есть, надо просто начать их корректно обрабатывать.
Как я и думал, ничего нового придумать почти невозможно. Все уже было придумано, озвучено и не делается.
Или не будет, там с гарантиями слабенько все. Хочется нормальный RFC и его нормальную поддержку начиная с такой-то версии бла-бла-бла.
Минцифры это бюрократы в конце концов. Им не интересно делать фичи которые документами не обосновываются. Понятно что на них тот же Яндекс имеет влияние, но влиять надо на основе каких-то документов. А не рассуждений что вот тут вроде работает.
Был бы RFC с понятной поддержкой фичи, проблем не было бы. Просто делаем по стандартам. Наш бигтех правильные слова для бюрократов напишет.
Тогда у меня вон та хотелка к Минцифры расширяется. В начале додавить такое расширения, потом давить на внедрение национальных сертификатов. Они логично их него вытекают. Прямо нормальный план из двух последовательных этапов получается.
Это доработка которую в Хроме надо сделать. Она правильная и разумная. И для нее даже не надо менять что-то основополагающее в принципах сертификации. Пишем обычный RFC и реализуем. За год все делается.
Она вообще даст полезную фичу. Можно будет получить обычный *.vasya.com и спокойно самому генерить сертификаты pk1.vasya.com подписанные им. Децентрализация, передача возможностей владельцам имен и вообще одни плюсы.
Вот есть у вас корневой сертификат на *.ru в доверенных. На другие домены он все равно не подействует. Где от него ключ лежит в целом не имеет значения.
С железками сложно все на самом деле. Их надо три минимум, географически разнесенных. Они должны уметь вместе работать. Их надо обслуживать и иногда менять, все ломается. Это внезапно может стать проблемой, опять кто-нибудь объявит что не продаст ибо серьезная криптография и что дальше делать? Параллельно импортировать такую ключевую штуку так себе идея. Выглядит как лишнее усложнение на пустом месте.
CT логи достаточно хороши на самом деле. Они только с виду непонятны и бесполезны. На практике там правильная математика и они на самом деле работают и гарантируют.
Придумать можно много чего. Оно не взлетело и видимо уже не взлетит. Значит не очень.
DNS over TLS (DoT) гораздо более здравая и хорошая технология. Ничего нового не придумано, просто добавлено шифрование. Шифрование тоже стандартное. Вот эту технологию и оставляем. Получается пара аналогичная http+https. Простейший текстовый протокол и поверх слой шифрования.
Так никто не давит. Зачем Гуглу что-то менять? Их текущая система полностью устраивает.
Вообще мне больше нравитя unix way. Одно приложение - одна задача. Или один сервис - одна задача, если обобщить. Пусть ДНС отвечает только за резолв имен в адреса. Он прост и прекрасен. Хочется шифровать - ну накиньте стандартный ssl поверх. А сертификаты надо делать отдельно от него.
Я бы призвал весь российский бигтех, Китай, Индию, Пакистан и прочих желающих и их биг тех и написал бы драфт RFC. Без полного доверия корневым УЦ и с национальными зонами. И сильно давил бы на Гугл чтобы внедрили в Хром. Остальные быстро подтянутся.
Управлять этим можно посадить RIPE NCC, они себя неплохо зарекомендовали. Кто-то же должен подписывать национальные корневые сертификаты. Вот пусть и делают за какие-то небольшие взносы от стран.
Так они все равно не взлетели. Смысл был в том что магистр это другой уровень который по умолчанию должен проходиться в другом вузе и небольшим процентов от бакалавров. И все это так и не заработало.
Так что можно менять в целом ничего не изменится. Закопать неработающее решение в чем-то даже хорошо. На него деньги же тратятся впустую. Признание дипломов все равно не от названия программы зависит.
Мы тут про дефолты. Дефолты вообще правят миром.
Почему он не попал в доверенные по умолчанию и почему он не может заверить сайт Госуслуг чтобы все браузеры ему доверяли?
Кто сказал? Факты говорят сами за себя. И не надо говорить что он хуже или менее прозрачен чем море нонеймов в доверенных.
Ветка чуть выше. Про расширение сертификатов. Чтобы корневой центр мог удостоверять только домены которые прописаны в его сертификате. По обычной маске.
Даже новых полей добавлять не надо. Все уже есть, надо просто начать их корректно обрабатывать.
А почему тогда Минцифры не может? Стрелочка поворачивается?
Порочен механизм корневых центров.
Почему почта Гонконга может выпустить сертификат для Госуслуг, Минцифры не может? Сертификат которому будут доверять все браузеры по умолчанию.
А для этого нужно решение ВС. Чтобы любой суд следовал ему, а не писал глупости.
Это другое, понимать надо.
Как я и думал, ничего нового придумать почти невозможно. Все уже было придумано, озвучено и не делается.
Или не будет, там с гарантиями слабенько все. Хочется нормальный RFC и его нормальную поддержку начиная с такой-то версии бла-бла-бла.
Минцифры это бюрократы в конце концов. Им не интересно делать фичи которые документами не обосновываются. Понятно что на них тот же Яндекс имеет влияние, но влиять надо на основе каких-то документов. А не рассуждений что вот тут вроде работает.
Был бы RFC с понятной поддержкой фичи, проблем не было бы. Просто делаем по стандартам. Наш бигтех правильные слова для бюрократов напишет.
Тогда у меня вон та хотелка к Минцифры расширяется. В начале додавить такое расширения, потом давить на внедрение национальных сертификатов. Они логично их него вытекают. Прямо нормальный план из двух последовательных этапов получается.
Это доработка которую в Хроме надо сделать. Она правильная и разумная. И для нее даже не надо менять что-то основополагающее в принципах сертификации. Пишем обычный RFC и реализуем. За год все делается.
Она вообще даст полезную фичу. Можно будет получить обычный *.vasya.com и спокойно самому генерить сертификаты pk1.vasya.com подписанные им. Децентрализация, передача возможностей владельцам имен и вообще одни плюсы.
А что это даст?
Вот есть у вас корневой сертификат на *.ru в доверенных. На другие домены он все равно не подействует. Где от него ключ лежит в целом не имеет значения.
С железками сложно все на самом деле. Их надо три минимум, географически разнесенных. Они должны уметь вместе работать. Их надо обслуживать и иногда менять, все ломается. Это внезапно может стать проблемой, опять кто-нибудь объявит что не продаст ибо серьезная криптография и что дальше делать? Параллельно импортировать такую ключевую штуку так себе идея. Выглядит как лишнее усложнение на пустом месте.
CT логи достаточно хороши на самом деле. Они только с виду непонятны и бесполезны. На практике там правильная математика и они на самом деле работают и гарантируют.
Это прерогатива основного ВС, а не регионального. Дело больно знаковое и социально значимое. Его решения еще ждем.
Хочется верить что региональный заранее посоветовался у большого и их решения совпадут.
Так можно выкинуть все лишние звенья. Просто сделать корневой сертификат на *.ru и вперед. Все остальное не нужно и ничего не дает.
Придумать можно много чего. Оно не взлетело и видимо уже не взлетит. Значит не очень.
DNS over TLS (DoT) гораздо более здравая и хорошая технология. Ничего нового не придумано, просто добавлено шифрование. Шифрование тоже стандартное. Вот эту технологию и оставляем. Получается пара аналогичная http+https. Простейший текстовый протокол и поверх слой шифрования.
Такие железки работают строго оффлайн. Ну купил, ну показал. Дальше все равно генеришь что хочешь.
Внешней валидации у них бай дизайн нет. И ее нельзя делать. Могут отключить так же как сертификаты блокировали.
А вот это хорошая идея. Поддерживаю.
Так никто не давит. Зачем Гуглу что-то менять? Их текущая система полностью устраивает.
Вообще мне больше нравитя unix way. Одно приложение - одна задача. Или один сервис - одна задача, если обобщить. Пусть ДНС отвечает только за резолв имен в адреса. Он прост и прекрасен. Хочется шифровать - ну накиньте стандартный ssl поверх. А сертификаты надо делать отдельно от него.
Добавлю что я бы еще сделал на месте Минцифры.
Я бы призвал весь российский бигтех, Китай, Индию, Пакистан и прочих желающих и их биг тех и написал бы драфт RFC. Без полного доверия корневым УЦ и с национальными зонами. И сильно давил бы на Гугл чтобы внедрили в Хром. Остальные быстро подтянутся.
Управлять этим можно посадить RIPE NCC, они себя неплохо зарекомендовали. Кто-то же должен подписывать национальные корневые сертификаты. Вот пусть и делают за какие-то небольшие взносы от стран.
Так они все равно не взлетели. Смысл был в том что магистр это другой уровень который по умолчанию должен проходиться в другом вузе и небольшим процентов от бакалавров. И все это так и не заработало.
Так что можно менять в целом ничего не изменится. Закопать неработающее решение в чем-то даже хорошо. На него деньги же тратятся впустую. Признание дипломов все равно не от названия программы зависит.
Как предлагаете решать эту проблему? Допустим вы Минцифры со всеми их возможностями.
То что вся технология полного доверия любому корневому центру сертификации не очень это понятно.
CT логи говоря на админском. И естественно их сделали. Сделали абсолютно стандартным образом. Опять технологии не позволяют сделать лучше.
Смотрите на здоровье.
Так они абсолютно совпадают. Сразу говорили что делаем обычный корневой сертификат, его и сделали. Про это написали еще больше года назад.
Что-то другое сделать невозможно технически, технологии так устроены. Что вы проверять хотите?