Управление по сертификации DNS

Управление по сертификации DNS
Аббревиатура	CAA
Статус	Предложенный стандарт
Впервые опубликовано	18 октября 2010 г.
Последняя версия	RFC 8659 ; Ноябрь 2019 года
Организация	IETF
Авторы	Филипп Халлам-Бейкер ; Роб Стрейлинг ; Джейкоб Хоффман-Эндрюс ;

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

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

Фон

Серия неправильно выпущенных сертификатов с 2001 года ^{[ 1 ]}^{[ 2 ]} Поврежденное доверие к государственно надежному сертификационным властям, ^{[ 3 ]} и ускоренная работа по различным механизмам безопасности, включая прозрачность сертификата для отслеживания ошибочных выпусков, HTTP Public Key Pinning и датчанина для блокировки неправильно выпущенных сертификатов на стороне клиента и CAA для блокировки неправильного выпуска на стороне авторитета сертификата. ^{[ 4 ]}

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

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

По состоянию на июнь 2024 года ^[update], Qualys сообщает, что, тем не менее, только 15,4% из 150 000 самых популярных веб -сайтов TLS используют CAA Records. ^{[ 12 ]}

Записывать

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

флаг

Байт флагов , который реализует расширяемую систему сигнализации для будущего использования. По состоянию на 2018 год , был определен только критический флаг эмитента, который инструктирует власти сертификата, что они должны понимать соответствующую тег имущества перед выпуском сертификата. ^{[ 11 ]} Этот флаг позволяет расширить протокол в будущем с обязательными расширениями, ^{[ 4 ]} Аналогично критическим расширениям в сертификатах X.509 .

ярлык

Одно из следующих собственности:

проблема: Это свойство уполномочивает владелец домена, указанного в соответствующей стоимости недвижимости для выпуска сертификатов для домена, для которого публикация недвижимости.
IssueWild: Это имущество действует как проблема , но только разрешает выдачу сертификатов подстановочного знака и имеет приоритет над имуществом выпуска для запросов на сертификаты подстановочного знака.
iodef: Это свойство определяет метод для властей сертификата, чтобы сообщить о неверных запросах сертификации владельцу доменного имени, используя формат обмена объекта инцидента . По состоянию на 2018 год ^[update], не все сертификаты, власти поддерживают этот тег, поэтому нет никакой гарантии, что все выпуски сертификатов будут сообщены.
контакт: Все чаще контактная информация не доступна в WHOIS из -за опасений по поводу потенциальных нарушений GDPR. Это свойство позволяет владельцам домена публиковать контактную информацию в DNS. ^{[ 13 ]}^{[ 14 ]}
Контактный телефон: Как указано выше, для телефонных номеров. ^{[ 15 ]}

ценить: Значение, связанное с выбранным тегом свойства.

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

Третьи стороны мониторинга сертификата Поведение Управления могут проверить вновь выпущенные сертификаты против записей домена CAA. RFC 8659 штатов; Записи CAA могут использоваться оценщиками сертификатов в качестве возможного индикатора нарушения политики безопасности. Такое использование должно учитывать возможность того, что опубликованные записи CAA изменились между временем выдачи сертификата, и тем временем, когда сертификат наблюдался оценщиком сертификата. ^{[ 11 ]}

Расширения

RFC 8657 указывает "accounturi" и "validationmethods" Параметры, которые позволяют пользователям указывать желаемые методы проверки управления доменом, как определено в протоколе ACME . Например, администраторы веб -сайтов могут связать домен, который они контролируют с конкретной учетной записью, зарегистрированной в их желаемом органе сертификации.

История

Проект первого расширения на стандарт CAA был опубликован 26 октября 2016 года, в котором был представлен новый токен с учетной записью-URI с концом недвижимости , который связывает домен с конкретной учетной записью среды автоматизированного управления сертификатами . ^{[ 17 ]} Это было внесено в поправки 30 августа 2017 года, чтобы также включить новый токен методов проверки , который связывает домен с конкретным методом проверки, ^{[ 18 ]} а затем дополнительно внесены в изменения 21 июня 2018 года, чтобы удалить дефис в учетной записи и метеодах валидации, что делает их учетной записью и валидациями . ^{[ 19 ]}

Примеры

Чтобы указать, что только полномочия по сертификату, идентифицированное CA.Example.net , разрешено выпускать сертификаты, например. И все субдомены, можно использовать эту запись CAA: ^{[ 11 ]}

example.com.  IN  CAA 0 issue "ca.example.net"

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

example.com.  IN  CAA  0 issue ";"

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

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

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

example.com.  IN  CAA  0 issue "ca.example.net"
example.com.  IN  CAA  128 future "value"

Инциденты

В 2017 году было обнаружено, что Camerfirma неправильно проверяет CAA Records. Camerfirma утверждал, что неправильно понял базовые требования форума CA/браузера, описывающие валидацию CAA. ^{[ 20 ]}^{[ 4 ]}

В начале 2020 года Let's Encrypt сообщил, что их программное обеспечение неправильно запросило и подтверждено записи CAA, которые потенциально влияют на более 3 миллионов сертификатов. ^{[ 21 ]} Let's Encrypt работал с клиентами и операторами сайта, чтобы заменить более 1,7 миллиона сертификатов, но решил не отозвать остальные, чтобы избежать простоя клиента, и, поскольку все затронутые сертификаты истекают менее чем за 90 дней. ^{[ 22 ]}

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

Ссылки

^ Ристич, Иван. «SSL/TLS и PKI History» . Злющая утка . Получено 8 июня 2018 года .
^ Брайт, Питер (30 августа 2011 г.). «Другой мошеннический сертификат поднимает те же старые вопросы о властях сертификата» . Ars Technica . Получено 10 февраля 2018 года .
^ Ruohonen, Jukka (2019). «Эмпирическое исследование о раннем принятии разрешения DNS сертификации». Журнал технологий кибербезопасности . 3 (4): 205–218. Arxiv : 1804.07604 . doi : 10.1080/23742917.2019.16322249 . S2CID 5027899 .
^ Подпрыгнуть до: ^а ^{беременный} ^в ^{дюймовый} ^и Scheitle, Quirin; Чунг, Тэджун; и др. (Апрель 2018). «Первый взгляд на авторизацию Управления по сертификации (CAA)» (PDF) . ACM SigComm Computer Communication Review . 48 (2): 10–23. doi : 10.1145/3213232.3213235 . ISSN 0146-4833 . S2CID 13988123 .
^ Халлам-Бейкер, Филипп ; Стрэдлинг, Роб (18 октября 2010 г.). DNS сертификационный орган авторизации (CAA) . IETF . ID DRACK-HALLAMBAKER-DONOTISSUE-00.
^ Халлам-Бейкер, Филипп ; Стрейлинг, Роб; Бен, Лори (2 июня 2011 г.). DNS сертификационный орган авторизации (CAA) . IETF . ID DRACK-IETF-PKIX-CAA-00.
^ Халлам-Бейкер, Филипп ; Стрэдлинг, Роб (январь 2013 г.). DNS сертификационный орган авторизации (CAA) . IETF . doi : 10.17487/rfc6844 . ISSN 2070-1721 . RFC 6844 .
^ Холл, Кирк (8 марта 2017 г.). «Результаты на бюллетени 187 - Сделайте CAA проверить обязательную» . CA/Форум браузеров . Получено 7 января 2018 года .
^ Подпрыгнуть до: ^а ^{беременный} Битти, Даг (22 августа 2017 г.). "Что такое CAA (разрешение на авторитет сертификации)?" Полем Globalsign . Получено 2 февраля 2018 года .
^ Cimpanu, Каталин (11 сентября 2017 г.). «Комодо поймал, как разбил новый стандарт CAA через день после того, как он вступил в силу» . Пролавкованный компьютер . Получено 8 января 2018 года .
^ Подпрыгнуть до: ^а ^{беременный} ^в ^{дюймовый} ^и ^фон DNS сертификационный орган авторизации (CAA) . IETF . Ноябрь 2019. DOI : 10.17487/RFC8659 . ISSN 2070-1721 . RFC 8659 .
^ "SSL Pulse" . SSL Labs . Квалификация . 3 января 2020 года . Получено 31 января 2020 года .
^ «Инфраструктура открытого ключа с использованием параметров X.509 (PKIX)» . www.iana.org . Получено 22 августа 2020 года .
^ https://cabforum.org/wp-content/uploads/ca-browser-forum-br-1.6.3.pdf Архивировано 29 мая 2023 года на машине Wayback ^{[ только URL PDF ]}
^ Битти, Даг (7 января 2019 г.). «Избирательный бюллетень SC14: Свойство контакта CAA и связанные с ними методы проверки телефона» . CA/Форум браузеров (список рассылки) . Получено 19 октября 2020 года .
^ «Что такое разрешение на уполномоченность сертификации (CAA)?» Полем Symantec . Архивировано с оригинала 8 января 2018 года . Получено 8 января 2018 года .
^ Ландау, Хьюго (26 октября 2016 г.). Расширения записей CAA для привязки URI и метода ACME . IETF . ID DRACK-IETF-ACME-CAA-00.
^ Ландау, Хьюго (30 августа 2017 г.). Расширения записей CAA для привязки URI и метода ACME . IETF . ID DRACK-IETF-ACME-CAA-04.
^ Ландау, Хьюго (21 июня 2018 г.). Расширения записей CAA для привязки URI и метода ACME . IETF . ID DRACK-IETF-ACME-CAA-05.
^ «CA: Проблемы Camerfirma - Mozillawiki» . wiki.mozilla.org . Получено 27 апреля 2021 года .
^ Клаберн, Томас (3 марта 2020 г.). «Давайте зашифруем? Давайте отменим 3 миллиона сертификатов HTTPS в среду, больше похоже на: проверка цикла кода . www.theregister.com . Архивировано из оригинала 31 мая 2020 года . Получено 27 апреля 2021 года .
^ Барретт, Брайан (3 марта 2020 г.). «Интернет избежал незначительной катастрофы на прошлой неделе» . Проводной . ISSN 1059-1028 . Получено 27 апреля 2021 года .

Внешние ссылки

RFC 8659
Список идентификаторов CA для использования в CAA Records в базе данных Common CA

[feistyduck-1] Ристич, Иван. «SSL/TLS и PKI History» . Злющая утка . Получено 8 июня 2018 года .

[arstechnica2011-2] Брайт, Питер (30 августа 2011 г.). «Другой мошеннический сертификат поднимает те же старые вопросы о властях сертификата» . Ars Technica . Получено 10 февраля 2018 года .

[ruohonen2018-3] Ruohonen, Jukka (2019). «Эмпирическое исследование о раннем принятии разрешения DNS сертификации». Журнал технологий кибербезопасности . 3 (4): 205–218. Arxiv : 1804.07604 . doi : 10.1080/23742917.2019.16322249 . S2CID 5027899 .

[sigcomm2017-4] Подпрыгнуть до: ^а ^{беременный} ^в ^{дюймовый} ^и Scheitle, Quirin; Чунг, Тэджун; и др. (Апрель 2018). «Первый взгляд на авторизацию Управления по сертификации (CAA)» (PDF) . ACM SigComm Computer Communication Review . 48 (2): 10–23. doi : 10.1145/3213232.3213235 . ISSN 0146-4833 . S2CID 13988123 .

[draft-hallambaker-donotissue-00-5] Халлам-Бейкер, Филипп ; Стрэдлинг, Роб (18 октября 2010 г.). DNS сертификационный орган авторизации (CAA) . IETF . ID DRACK-HALLAMBAKER-DONOTISSUE-00.

[draft-ietf-pkix-caa-00-6] Халлам-Бейкер, Филипп ; Стрейлинг, Роб; Бен, Лори (2 июня 2011 г.). DNS сертификационный орган авторизации (CAA) . IETF . ID DRACK-IETF-PKIX-CAA-00.

[rfc6844-7] Халлам-Бейкер, Филипп ; Стрэдлинг, Роб (январь 2013 г.). DNS сертификационный орган авторизации (CAA) . IETF . doi : 10.17487/rfc6844 . ISSN 2070-1721 . RFC 6844 .

[cab2017-8] Холл, Кирк (8 марта 2017 г.). «Результаты на бюллетени 187 - Сделайте CAA проверить обязательную» . CA/Форум браузеров . Получено 7 января 2018 года .

[globalsign2017-9] Подпрыгнуть до: ^а ^{беременный} Битти, Даг (22 августа 2017 г.). "Что такое CAA (разрешение на авторитет сертификации)?" Полем Globalsign . Получено 2 февраля 2018 года .

[bleepingcomputer2017-10] Cimpanu, Каталин (11 сентября 2017 г.). «Комодо поймал, как разбил новый стандарт CAA через день после того, как он вступил в силу» . Пролавкованный компьютер . Получено 8 января 2018 года .

[rfc8659-11] Подпрыгнуть до: ^а ^{беременный} ^в ^{дюймовый} ^и ^фон DNS сертификационный орган авторизации (CAA) . IETF . Ноябрь 2019. DOI : 10.17487/RFC8659 . ISSN 2070-1721 . RFC 8659 .

[ssllabs-12] "SSL Pulse" . SSL Labs . Квалификация . 3 января 2020 года . Получено 31 января 2020 года .

[13] «Инфраструктура открытого ключа с использованием параметров X.509 (PKIX)» . www.iana.org . Получено 22 августа 2020 года .

[14] ttps://cabforum.org/wp-content/uploads/ca-browser-forum-br-1.6.3.pdf Архивировано 29 мая 2023 года на машине Wayback ^{[ только URL PDF ]}

[15] Битти, Даг (7 января 2019 г.). «Избирательный бюллетень SC14: Свойство контакта CAA и связанные с ними методы проверки телефона» . CA/Форум браузеров (список рассылки) . Получено 19 октября 2020 года .

[symantec-16] «Что такое разрешение на уполномоченность сертификации (CAA)?» Полем Symantec . Архивировано с оригинала 8 января 2018 года . Получено 8 января 2018 года .

[draft-ietf-acme-caa-00-17] Ландау, Хьюго (26 октября 2016 г.). Расширения записей CAA для привязки URI и метода ACME . IETF . ID DRACK-IETF-ACME-CAA-00.

[draft-ietf-acme-caa-04-18] Ландау, Хьюго (30 августа 2017 г.). Расширения записей CAA для привязки URI и метода ACME . IETF . ID DRACK-IETF-ACME-CAA-04.

[draft-ietf-acme-caa-05-19] Ландау, Хьюго (21 июня 2018 г.). Расширения записей CAA для привязки URI и метода ACME . IETF . ID DRACK-IETF-ACME-CAA-05.

[20] «CA: Проблемы Camerfirma - Mozillawiki» . wiki.mozilla.org . Получено 27 апреля 2021 года .

[21] Клаберн, Томас (3 марта 2020 г.). «Давайте зашифруем? Давайте отменим 3 миллиона сертификатов HTTPS в среду, больше похоже на: проверка цикла кода . www.theregister.com . Архивировано из оригинала 31 мая 2020 года . Получено 27 апреля 2021 года .

[22] Барретт, Брайан (3 марта 2020 г.). «Интернет избежал незначительной катастрофы на прошлой неделе» . Проводной . ISSN 1059-1028 . Получено 27 апреля 2021 года .

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]