DKIM: Могу ли я просто изменить ключ RSA, используемый в DKIM, без изменения селектора DKIM?
Могу ли я просто изменить ключ RSA, используемый в DKIM (запись DNS TXT), без изменения селектора DKIM, или это приведет к каким-либо проблемам?
Если нет, то для чего они предназначены для селектора DKIM?
КСТАТИ: 20120113
это селектор, о котором я говорю в 20120113._domainkey.gmail.com
3 ответа
Как вы можете прочитать здесь "...... к имени домена добавлен селектор, используемый для поиска информации открытого ключа DKIM...".
Кроме того, в терминах Википедии: "... Получающий SMTP-сервер использует доменное имя и селектор для выполнения поиска в DNS [...], селектор - это простой метод, позволяющий подписывающим сторонам добавлять и удалять ключи в любое время, когда они захотят."
Другими словами, если вы отправляете электронную почту с подписью DKIM, вы должны сообщить внешним почтовым серверам, КАК они могут получить ваш ключ RSA, чтобы проверить действительность вашей электронной почты. RSA-ключ опубликован в вашем DNS, хорошо, но ГДЕ? Какой DNS-запрос будет его получать? Как они узнают, какой DNS-запрос / запись разрешается? Вот где селектор играет свою роль: если вы отправляете почту с example.com
домен, и в вашей почте вы объявляете whatever
в качестве селектора тогда:
- в заголовке исходящей почты вы должны указать свой домен и соответствующий селектор, например:
DKIM-подпись [...] d=example.com; [...] s= что угодно
- в вашем DNS вы должны предоставить
TXT
запись дляwhatever._domainkey.example.com
опубликовать свой ключ RSA, как в:
what._domainkey.example.com IN TXT "k=rsa\; t=s\; p=MIGfMA[...]AQAB"
Как видите, DNS-запрос имеет вид
Исходя из этого, мы можем сказать, что:
RSA-ключ может быть заменен / обновлен без какого-либо влияния на селектор. Очевидно, что очень важно, чтобы при обновлении одной стороны ключа (общедоступной, опубликованной в DNS) вы также меняли другую сторону (ту, которая использовалась для "подписи" исходящей почты);
если вы оставляете селектор неизменным при обновлении RSA-ключа, то побочным эффектом является то, что.... удаленные клиенты (не серверы; я говорю о MUA), которые по тем или иным причинам хотят проверять DKIM-подпись, включенную в их старые / заархивированные электронные письма не пройдут процесс проверки (так как заархивированное электронное письмо было подписано с помощью закрытого ключа, открытый-тот, который опубликован в DNS, был обновлен и теперь отличается!).
Я хочу добавить, что по своему опыту я привык думать, что DKIM-подписывание / проверка - это процесс, нацеленный на передачу электронной почты, а не на проверку клиента. Поэтому я готов поспорить, что обновлять KEYs довольно безопасно, оставляя селектор без изменений.
Я также думаю, что.... если вы собираетесь обновить KEYs, вам нужно изменить как код подписи (который должен указывать на новый закрытый ключ), так и DNS (чтобы опубликовать новый открытый ключ). ключ в записи TXT). Итак, почему бы не изменить также селектор (опять же с обеих сторон?). В итоге вы получите ДВУХ селекторов, опубликованных в DNS, один из которых будет указывать на старый ключ, а другой - на новый. Таким образом, все будет хорошо во время SMTP-транспорта, а также MUA сможет проверять старые / архивированные электронные письма, так как старый ключ, связанный со старым селектором, все еще доступен.
Могу ли я просто изменить ключ RSA, используемый в DKIM (запись DNS TXT), без изменения селектора DKIM, или это приведет к каким-либо проблемам?
Да, вы можете, но без уважительной причины я бы настоятельно рекомендовал не делать этого.
Вот несколько причин, почему повторное использование селектора не будет хорошей идеей:
- Изменения DNS могут занять некоторое время для распространения. Если селектор повторно используется после смены ключа, это может привести к сбою проверки электронных писем, отправленных вскоре после смены ключа.
- Вы не знаете, сколько времени пройдет между отправкой и проверкой. Это может привести к тому, что старые сообщения не пройдут проверку после смены ключа. Некоторые возможные причины задержки:
- Сообщение застревает во время транзита.
- Хотя я думаю, что это очень необычно, проверка также может происходить внутри MUA ( существует дополнение для Thunderbird, которое делает это)
- Из RFC: "Повторное использование селектора с новым ключом (например, изменение ключа, связанного с именем пользователя) делает невозможным различие между сообщением, которое не было проверено, поскольку ключ больше не действителен, и сообщением это на самом деле подделка. По этой причине подписантам не рекомендуется повторно использовать селекторы для новых ключей. Лучшая стратегия - назначать новые ключи новым селекторам ".
Какова цель селектора DKIM?
Msgstr "Для поддержки нескольких одновременных открытых ключей на подписывающий домен". Вот несколько вариантов использования для одновременных ключей:
- "Помимо административного удобства, селекторы позволяют беспрепятственно заменять открытые ключи на регулярной основе".
- Разрешить различным организациям подписывать ваши электронные письма (с другим ключом и селектором) без необходимости делиться личным ключом. Это полезно для:
- делегирование подписи сторонней организации
- административно распределенные организации
- Сделайте возможным явное отзыв ключа (оставив данные открытого ключа (тег "p=") пустыми).
Все цитаты взяты из RFC 6376.
Вы можете сделать это. Это не обязательно BCP, хотя.
Причина наличия нескольких селекторов заключается именно в том, чтобы ключ оставался действительным в течение некоторого времени после поворота.
Например, если вы измените ключ RSA, используемый в селекторе 20120113, то любое сообщение, которое все еще находилось где-то в очереди и было доставлено позже, завершится ошибкой DKIM, поскольку ключ изменился.
В идеале вы должны опубликовать новый ключ, 20160106, если бы сделали это сегодня, и добавить его в качестве дополнительного селектора. Таким образом, сообщения, использующие оба ключа, могут быть проверены. По истечении разумного периода времени, скажем, двух недель, вы можете повторно опубликовать старый ключ.
(Я предполагаю, что вы на самом деле не имеете в виду ключ 20120113._domainkey.gmail.com буквально? Если вы действительно говорите о ключе Gmail, остановитесь и поговорите с Джоном Р.Г., прежде чем что-либо менять.)