Авторизация центра сертификации DNS - DNS Certification Authority Authorization

Авторизация центра сертификации DNS
Положение делПредлагаемый стандарт
Впервые опубликовано18 октября 2010 г. (2010-10-18)
Последняя версияRFC  8659
Ноябрь 2019
ОрганизацияIETF
Авторы
СокращениеCAA
Интернет-безопасность
протоколы
Ключевой менеджмент
Уровень приложения
система доменных имен
Интернет-уровень

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

Его разработали компьютерные ученые. Филлип Халлам-Бейкер и Роб Стрэдлинг в ответ на растущую обеспокоенность по поводу безопасности публично доверенных центров сертификации. Это Инженерная группа Интернета (IETF) предлагаемый стандарт.

Фон

А серия неправильно выданных сертификатов с 2001 г.[1][2] подорванное доверие к общественно доверенным центрам сертификации,[3] и ускорена работа над различными механизмами безопасности, в том числе Сертификат прозрачности для отслеживания неправильной выдачи, Закрепление открытого ключа HTTP и ДЕЙН блокировать неправильно выданные сертификаты на сторона клиента, и CAA, чтобы заблокировать неправильную выдачу на стороне центра сертификации.[4]

Первый проект CAA был написан Филлип Халлам-Бейкер и Роба Стрэдлинга, и представили как IETF Интернет-проект в октябре 2010 г.[5] Это было постепенно улучшено Рабочая группа PKIX,[6] и одобрено IESG так как RFC  6844, а Предлагаемый стандарт, в январе 2013 г.[7] CA / Форум браузеров обсуждение началось вскоре после этого,[4] а в марте 2017 года они проголосовали за то, чтобы к сентябрю 2017 года внедрение CAA стало обязательным для всех центров сертификации.[8][9] Как минимум один центр сертификации, Комодо, не удалось реализовать CAA до истечения крайнего срока.[10] Исследование 2017 г. Технический университет Мюнхена обнаружил много случаев, когда центры сертификации не смогли правильно реализовать некоторые части стандарта.[4]

В сентябре 2017 года Джейкоб Хоффман-Эндрюс представил Интернет-проект, призванный упростить стандарт CAA. Это было улучшено рабочей группой LAMPS и утверждено как RFC  8659, предлагаемый стандарт, в ноябре 2019 года.[11]

По состоянию на январь 2020 г., Qualys сообщает, что по-прежнему только 6,8% из 150 000 самых популярных TLS -поддерживающие веб-сайты используют записи CAA.[12]

Ошибка в соблюдении CAA привела к Давайте зашифровать вынужден отозвать миллионы сертификатов 3 марта 2020 г.[13]

Запись

Центры сертификации, реализующие CAA, выполняют DNS поиск для CAA записи ресурсов, и если таковые обнаружены, убедитесь, что они указаны в качестве уполномоченной стороны перед выдачей Цифровой сертификат. Каждая запись ресурса CAA состоит из следующих компонентов:[11]

флаг
А байт флагов который реализует расширяемый сигнальная система для будущего использования. По состоянию на 2018 год, только эмитент критический Был определен флаг, который указывает центрам сертификации, что они должны понимать соответствующий тег свойства перед выдачей сертификата.[11] Этот флаг позволяет в будущем расширять протокол обязательными расширениями,[4] похожий на критические расширения в сертификатах X.509.
тег
Одно из следующих свойств:
выпуск
Это свойство разрешает владельцу домена, указанного в значении связанного свойства, выдавать сертификаты для домена, для которого опубликовано свойство.
дикая
Это свойство действует как выпуск но разрешает только выдачу подстановочные сертификаты, и имеет приоритет перед выпуск свойство для запросов сертификатов с подстановочными знаками.
iodef
Это свойство определяет способ, с помощью которого центры сертификации могут сообщать владельцу доменного имени о недействительных запросах сертификатов с помощью Объект инцидента Описание Формат обмена. По состоянию на 2018 год, не все центры сертификации поддерживают этот тег, поэтому нет гарантии, что все выдачи сертификатов будут сообщены.
Почта для связи
Все чаще контактная информация недоступна в WHOIS из-за опасений по поводу возможных нарушений GDPR. Это свойство позволяет владельцам доменов публиковать контактную информацию в DNS.[14][15]
Контактный телефон
То же, что и выше, для номеров телефонов.[16]
ценить
Значение, связанное с выбранным тегом свойства.

Отсутствие каких-либо записей CAA разрешает нормальную неограниченную выдачу, а наличие единственного бланка выпуск тег запрещает любую выдачу.[11][9][17]

Третьи стороны, наблюдающие за поведением центра сертификации, могут проверять недавно выпущенные сертификаты по записям CAA домена, но должны знать, что записи CAA домена могли измениться между временем выпуска сертификата и временем их проверки третьей стороной. Клиенты не должны использовать CAA как часть процесса проверки сертификатов.[11]

Расширения

26 октября 2016 г. был опубликован проект первого расширения стандарта CAA, в котором предлагается новый аккаунт-ури токен до конца выпуск свойство, которое связывает домен с конкретным Автоматизированная среда управления сертификатами учетная запись.[18] 30 августа 2017 г. в него были внесены поправки, в которые также была включена новая методы проверки токен, который связывает домен с определенным методом проверки,[19] а затем 21 июня 2018 г. были внесены дополнительные поправки, убирающие дефис в аккаунт-ури и методы проверки делая их вместо Accounturi и методы проверки.[20]

Примеры

Чтобы указать, что только центр сертификации, указанный ca.example.net уполномочен выдавать сертификаты на example.com и все поддомены можно использовать эту запись CAA:[11]

example.com. В CAA 0 проблема "ca.example.net"

Чтобы запретить выпуск любого сертификата, можно разрешить выпуск только пустому списку издателей:

example.com. В CAA 0 проблема ";"

Чтобы указать, что центры сертификации должны сообщать о недействительных запросах сертификатов Адрес электронной почты и Межсетевая защита в реальном времени конечная точка:

example.com. В CAA 0 iodef "mailto: [email protected]" example.com. В CAA 0 iodef "http://iodef.example.com/"

Чтобы использовать будущее расширение протокола, например такое, которое определяет новый будущее свойство, которое должно быть понято центром сертификации, прежде чем они смогут безопасно продолжить, можно установить эмитент критический флаг:

example.com. В CAA 0 проблема "ca.example.net" example.com. В CAA 128 будущее "значение"

Смотрите также

Рекомендации

  1. ^ Ристич, Иван. «История SSL / TLS и PKI». Злая утка. Получено 8 июня, 2018.
  2. ^ Брайт, Питер (30 августа 2011 г.). «Другой поддельный сертификат вызывает те же старые вопросы о центрах сертификации». Ars Technica. Получено 10 февраля, 2018.
  3. ^ Руохонен, Юкка (2019). «Эмпирический обзор раннего принятия авторизации центра сертификации DNS». Журнал технологий кибербезопасности. 3 (4): 205–218. arXiv:1804.07604. Дои:10.1080/23742917.2019.1632249. S2CID  5027899.
  4. ^ а б c d Шейтле, Квирин; Чунг, Тэджун; и другие. (Апрель 2018 г.). «Первый взгляд на авторизацию центра сертификации (CAA)» (PDF). Обзор компьютерных коммуникаций ACM SIGCOMM. 48 (2): 10–23. Дои:10.1145/3213232.3213235. ISSN  0146-4833. S2CID  13988123.
  5. ^ Халлам-Бейкер, Филипп; Стрэдлинг, Роб (18 октября 2010 г.). Запись ресурса авторизации центра сертификации (CAA) DNS. IETF. I-D draft-hallambaker-donotissue-00.
  6. ^ Халлам-Бейкер, Филипп; Стрэдлинг, Роб; Бен, Лори (2 июня 2011 г.). Запись ресурса авторизации центра сертификации (CAA) DNS. IETF. И-Д черновик-ietf-pkix-caa-00.
  7. ^ Халлам-Бейкер, Филипп; Стрэдлинг, Роб (январь 2013 г.). Запись ресурса авторизации центра сертификации (CAA) DNS. IETF. Дои:10.17487 / RFC6844. ISSN  2070-1721. RFC 6844.
  8. ^ Холл, Кирк (8 марта 2017 г.). «Результаты бюллетеня № 187 - Сделать проверку ВГА обязательной». CA / Форум браузеров. Получено 7 января, 2018.
  9. ^ а б Битти, Дуг (22 августа 2017 г.). "Что такое CAA (авторизация центра сертификации)?". GlobalSign. Получено 2 февраля, 2018.
  10. ^ Чимпану, Каталин (11 сентября 2017 г.). «Comodo поймали на нарушении нового стандарта CAA через день после того, как он вступил в силу». Пищевой компьютер. Получено 8 января, 2018.
  11. ^ а б c d е ж Запись ресурса авторизации центра сертификации (CAA) DNS. IETF. Ноябрь 2019. Дои:10.17487 / RFC8659. ISSN  2070-1721. RFC 8659.
  12. ^ «Импульс SSL». SSL Labs. Qualys. 3 января 2020 г.. Получено 31 января, 2020.
  13. ^ в 19:44, Томас Клэберн в Сан-Франциско 3 марта 2020 года. «Давайте зашифровать? Давайте отзовем 3 миллиона сертификатов HTTPS в среду, скорее, как: проверка ошибок в цикле кода». www.theregister.co.uk. Получено 15 марта, 2020.
  14. ^ «Инфраструктура открытого ключа с использованием параметров X.509 (PKIX)». www.iana.org. Получено 22 августа, 2020.
  15. ^ https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.6.3.pdf
  16. ^ Битти, Дуг (7 января 2019 г.). «Бюллетень SC14: Контактная информация CAA и соответствующие методы проверки телефона». CA / Форум браузеров (Список рассылки). Получено 19 октября, 2020.
  17. ^ «Что такое авторизация центра сертификации (CAA)?». Symantec. Получено 8 января, 2018.
  18. ^ Ландау, Гюго (26 октября 2016 г.). Расширения записи CAA для привязки URI учетной записи и метода ACME. IETF. I-D draft-ietf-acme-caa-00.
  19. ^ Ландау, Гюго (30 августа 2017 г.). Расширения записи CAA для привязки URI учетной записи и метода ACME. IETF. I-D draft-ietf-acme-caa-04.
  20. ^ Ландау, Гюго (21 июня 2018 г.). Расширения записи CAA для привязки URI учетной записи и метода ACME. IETF. I-D draft-ietf-acme-caa-05.

внешняя ссылка