Skip to main content

3.6 Key Management and Representation (密钥管理和表示)

3.6. Key Management and Representation (密钥管理和表示)​

签名应用程序需要某种程度的保证, 即验证公钥与声称的 Signer 相关联。许多应用程序通过使用由受信任的第三方颁发的公钥证书来实现这一点。然而, DKIM 可以通过简单地让 Verifier 查询声称的 Signer 的 DNS 条目 (或某个安全等效项) 来检索公钥, 从而实现足够的安全级别, 并显著增强可扩展性。

DKIM 密钥可以潜在地存储在多种类型的密钥服务器中, 并以多种格式存储。密钥的存储和格式与 DKIM 算法的其余部分无关。

密钥查找算法的参数包括查找类型 ("q=" 标签), Signer 的域 (DKIM-Signature 头字段的 "d=" 标签), 以及 selector (选择器, "s=" 标签)。

public_key = dkim_find_key(q_val, d_val, s_val)

本文档定义了一种绑定, 使用 DNS TXT RR 来分发密钥。将来可能会定义其他绑定。

3.6.1. Textual Representation (文本表示)​

预期许多密钥服务器会选择以非结构化文本格式呈现密钥 (例如, XML 格式不被视为本目的的非结构化文本)。以下定义必须用于以非结构化文本形式表示的任何 DKIM 密钥。

总体语法是 Section 3.2 中描述的 tag-list。当前有效的标签如下所述。可能存在其他标签, 任何不理解它们的实现必须忽略它们。

v= DKIM 密钥记录的版本 (纯文本; 推荐, 默认为 "DKIM1")。如果指定, 此标签必须设置为 "DKIM1" (不带引号)。此标签必须是记录中的第一个标签。以任何其他值开头的 "v=" 标签的记录必须被丢弃。请注意, 验证者必须对此值进行字符串比较; 例如, "DKIM1" 与 "DKIM1.0" 不同。

ABNF:

key-v-tag    = %x76 [FWS] "=" [FWS] %x44.4B.49.4D.31

h= 可接受的哈希算法 (纯文本; 可选, 默认为允许所有算法)。可能使用的哈希算法的冒号分隔列表。无法识别的算法必须被忽略。有关 Signer 和 Verifier 实现的哈希算法的讨论, 请参阅 Section 3.3。每个记录中此标签中列出的算法集是 Signer 做出的操作选择。

ABNF:

key-h-tag       = %x68 [FWS] "=" [FWS] key-h-tag-alg
                  *( [FWS] ":" [FWS] key-h-tag-alg )
key-h-tag-alg   = "sha1" / "sha256" / x-key-h-tag-alg
x-key-h-tag-alg = hyphenated-word   ; for future extension

k= 密钥类型 (纯文本; 可选, 默认为 "rsa")。Signer 和 Verifier 必须支持 "rsa" 密钥类型。"rsa" 密钥类型表示在 "p=" 标签中使用 ASN.1 DER 编码的 [ITU-X660-1997] RSAPublicKey (参见 [RFC3447], Sections 3.1 和 A.1.1)。(注意: "p=" 标签进一步使用 base64 算法对值进行编码。) 无法识别的密钥类型必须被忽略。

ABNF:

key-k-tag        = %x76 [FWS] "=" [FWS] key-k-tag-type
key-k-tag-type   = "rsa" / x-key-k-tag-type
x-key-k-tag-type = hyphenated-word   ; for future extension

n= 可能对人类有用的注释 (qp-section; 可选, 默认为空)。不会由任何程序进行解释。在具有空间限制的任何密钥服务器机制 (特别是 DNS) 中, 应谨慎使用此标签。这是供管理员使用的, 而不是最终用户。

ABNF:

key-n-tag    = %x6e [FWS] "=" [FWS] qp-section

p= 公钥数据 (base64; 必需)。空值表示此公钥已被撤销。在 base64 编码之前, 此标签值的语法和语义由 "k=" 标签定义。

信息性理由: 如果私钥已被泄露或以其他方式禁用 (例如, 外包合同已终止), Signer 可能希望明确声明它知道该 selector, 但使用该 selector 的所有消息应验证失败。Verifier 应对任何引用已撤销密钥的 selector 的 DKIM-Signature 头字段返回错误代码。(详见 Section 6.1.2。)

ABNF:

key-p-tag    = %x70 [FWS] "=" [ [FWS] base64string]

信息性注释: base64string 允许在任意位置包含空白 (FWS); 但是, 任何 CRLF 必须后跟至少一个 WSP 字符。实现者和管理员应注意确保 selector TXT RR 符合本规范。

s= 服务类型 (纯文本; 可选; 默认为 "*")。此记录适用的服务类型的冒号分隔列表。给定服务类型的 Verifier 必须忽略此记录, 如果未列出适当的类型。无法识别的服务类型必须被忽略。当前定义的服务类型如下:

  • * 匹配所有服务类型
  • email 电子邮件 (不一定限于 SMTP)

此标签旨在限制密钥用于其他目的, 如果将来 DKIM 被其他服务定义使用。

ABNF:

key-s-tag        = %x73 [FWS] "=" [FWS] key-s-tag-type
                   *( [FWS] ":" [FWS] key-s-tag-type )
key-s-tag-type   = "email" / "*" / x-key-s-tag-type
x-key-s-tag-type = hyphenated-word   ; for future extension

t= 标志, 表示为名称的冒号分隔列表 (纯文本; 可选, 默认为未设置标志)。无法识别的标志必须被忽略。定义的标志如下:

  • y 此域正在测试 DKIM。Verifier 必须不以不同于未签名电子邮件的方式对待来自测试模式中的 Signer 的消息, 即使签名验证失败。Verifier 可能希望跟踪测试模式结果以协助 Signer。

  • s 任何使用 "i=" 标签的 DKIM-Signature 头字段必须在 "i=" 标签中的 "@" 右侧与 "d=" 标签的值具有相同的域值。也就是说, "i=" 域必须不是 "d=" 的子域。建议使用此标志, 除非需要子域划分。

ABNF:

key-t-tag        = %x74 [FWS] "=" [FWS] key-t-tag-flag
                   *( [FWS] ":" [FWS] key-t-tag-flag )
key-t-tag-flag   = "y" / "s" / x-key-t-tag-flag
x-key-t-tag-flag = hyphenated-word   ; for future extension

3.6.2. DNS Binding (DNS 绑定)​

使用 DNS TXT RR 作为密钥服务的绑定在此定义。所有实现必须支持此绑定。

3.6.2.1. Namespace (命名空间)​

所有 DKIM 密钥存储在名为 "_domainkey" 的子域中。给定 DKIM-Signature 字段, "d=" 标签为 "example.com", "s=" 标签为 "foo.bar", DNS 查询将针对 "foo.bar._domainkey.example.com"。

3.6.2.2. Resource Record Types for Key Storage (用于密钥存储的资源记录类型)​

使用的 DNS 资源记录类型由查询类型 ("q=") 标签的选项指定。本基础规范中定义的唯一选项是 "txt", 表示使用 TXT RR。本标准的后续扩展可能会定义另一个 RR 类型。

TXT RR 中的字符串必须在使用前连接在一起, 不带任何中间空白。TXT RR 对于特定的 selector 名称必须是唯一的; 也就是说, 如果 RRset 中有多个记录, 则结果是未定义的。

TXT RR 按 Section 3.6.1 中的描述进行编码。

Last updated on